F5 Synthesis: Software Defined Application Services
#SDN #Devops #Cloud #SDAS Completing the #SDDC stack Everything as a Service has become nearly a synonym for cloud computing. That's unsurprising, as the benefits of cloud - from economy of scale to increased service velocity - are derived mainly from the abstraction of network, compute and storage resources into services that can be rapidly provisioned, elastically scaled and intelligently orchestrated. We've come to use "Everything as a Service" and "Software Defined Data Center" nearly interchangeably, because the goal of both is really to drive toward IT as a Service. A world in which end-users (application owners and administrators) can provision, scale and orchestrate the resources necessary to deliver applications from app dev through devops to the network. This journey, in part, gave rise to SDN as a means to include the network in this new service-oriented data center. But SDN focused on only a subset of the network stack, leaving critical layer 4-7 services behind. Needless to say, such services are critical. Elastic scale is impossible without a combination of visibility and load balancing, after all, and a plethora of performance, security and even identity management focused services have become integral to modern data center architectures attempting to address pressures arising from trends like the Internet of Things, mobility, a steady stream of attacks, and an increasingly impatient consumer base. The problem of what to do about layer 4-7 services has been bandied about and given a lot of lip service, but no one really had a good solution - not one that integrated both with application (cloud and virtualization orchestration) and network orchestration solutions. Given F5's long-standing leadership in the realm of layer 4-7 services, we bent our heads together and found a solution. One that integrates and interoperates with SDN and compute orchestration solutions. One that applies SDN principles to application service networks. One that abstracts the application network resources necessary to deliver application services in a way that fills that gap between the network and compute orchestration layers. That solution is F5 Synthesis, and what it enables is Software Defined Application Services (SDAS). SDAS is the result of delivering highly flexible and programmatic application services from a unified, high-performance application service fabric. Orchestrated intelligently by BIG-IQ, SDAS can be provisioned and architected to solve significant pain points resulting from the whirling maelstrom of trends driving IT today. SDAS relies on abstraction; on the ability to take advantage of resources pooled from any combination of physical, virtual and cloud deployed F5 platforms. End-users are empowered to provision services instead of devices, and to leverage the visibility inherent in F5's full proxy-based platform approach. SDAS are highly flexible, owing to programmatic interfaces at not just the control (iControl, REST APIs) and data plane (iRules, node.js, Groovy) layers, but also at the configuration layer (iCall and iApps) to enable real-time, event-driven changes in behavior at the service level. SDAS is the next phase in the lengthy evolution of application delivery. As the approach to data centers becomes increasingly software-defined, so must the components that comprise the data center. That certainly must include the application service that have become so critical to ensuring the reliability, security and performance of the growing catalog of applications delivered to employees and consumers and, of course, "things" that make up the Internet today. Additional Resources: F5 Synthesis: The Time is RightF5 Synthesis: The Time is Right
#SDN #Devops #Cloud #SDAS #SDDC The time is right for an answer to the layer 4-7 services question. "If you look at the standard SDN model, [Layer 4-7 services] are applications that can basically run on the [SDN] controller platform. But that's not the only way to do them. We'll hear about different approaches. Network services for SDN are going to be a big story in 2013." -- Brad Casemore, IDC I love this quote from Brad (in fact this is the second time I've used it) because I've held the same opinion since SDN first burst onto the scene. At the time, the belief that layer 4-7 services were applications that could be deployed on the SDN controller seemed reasonable. Since that time, however, it's become accepted reality that an SDN controller built to manage and direct flows and packets - and the data path elements that carry out its commands - are not built to manage and direct streams and messages nor support a model that essentially forces it to participate in the data path. But that's not to say that the SDN principles can't be applied to layer 4-7 services, or that SDN is the only way to improve service velocity and achieve the economy of scale necessary to enable every application to take advantage of application services to improve performance, security or reliability. Remember that SDN (or something like it) was inevitable. Pressure mounting to increase service velocity and align with devops and app dev meant something had to change in the network. SDN appears to be that change for layer 2-3. And the time is right for a complementary change for layer 4-7 services. We call it Synthesis™. F5 Synthesis is an architectural vision for delivering device, network, and application services without constraints. The result is Software Defined Application Services™ (SDAS) delivered by a high-performance, all-active service fabric that when combined with new licensing models dramatically changes the economy of scale for application services. Applications previously unable to find room in their budget for pairs of dedicated hardware to enable services will be able to benefit from Synthesis' service-centric approach. Service velocity is improved by automation and orchestration at every layer, from fabric instances to the services provisioned for each application. F5 Synthesis comprises three core components: High Performance Fabric – F5 physical and virtual products form an elastic, multi-tenant service fabric that delivers Software Defined Application Services. The service fabric can cluster up to 32 F5 devices deployed across any combination of hardware, software or cloud and supports up to 80* unique instances per device. The result is a combined throughput of 20 TB and connection capacity of 9.2 billion (that's more than 3 times the capacity needed to connect every Internet user in the world**). The service fabric is application-driven; its core services of availability, failover and clustering are focused on and driven by application requirements and needs. It is also highly programmable across configuration, control and data planes, with REStful APIs, data path scripting languages (iRules, node.js, Groovy) and event-based configuration scripting (iCall, TMSH) to ensure a highly responsive, extensible system. Intelligent Services Orchestration – To realize the economy of scale necessary to enable a "leave no application behind" strategy, automated provisioning and orchestration is a must. F5’s architectural vision enables enterprises and service providers to seamlessly manage, scale, and automate the richest set of application services spanning device, network and application requirements for reliability, security and performance. Complementing the service fabric's multi-tenancy is a multi-tenant approach to management, enabling organizations to move closer to IT-as-a-Service without concern it might impact stability or security of the service fabric. Simplified Business Models – To better support the deployment of flexible services with cloud, hybrid, and usage-based IT models, F5 is simplifying its licensing and product bundling practices. Combined with a highly elastic service fabric and Intelligent Services Orchestration, simplified business models, F5 Synthesis enables organizations to achieve new economies of scale from both a cost savings and operational perspective. In much broader terms, F5 Synthesis is the next evolution for application delivery. The changing application and network architecture landscape requires such an evolution. It is, after all, an application-driven world, and an application world needs solutions that better enable IT and business stakeholders to align technology to meet today's most pressing challenges: cloud enablement, security and mobility of devices, networks and applications.The application services that have become critical to ensuring the reliability, security and performance of a wide variety of applications must be provisioned, managed and scaled in a way that aligns with an application-driven world. That way is F5 Synthesis and Software Defined Application Services. You can learn more about Synthesis here. *40,000 when combining administrative instances with vCMP ** Based on Sept 2013 Internet user population of 2.4B http://www.internetworldstats.com/stats.htmWhy SDN (or something like it) was Inevitable: Service Velocity
#Agile #Devops #SDN All three core IT groups must align with similar approaches to succeed - and we aren't done yet. Once upon a time, there was a movement in IT called "agile". Developers adopted it in response to complaints from the business that they needed applications, that applications were everything, that without new applications the business would surely dry up. Dev then began tossing code over the wall faster and more frequently. At some point, the operations folks responsible for herding these applications and application updates through the road to production decided that if they were going to keep up with development, they needed a new approach. Enter devops. Operations version of agile as applied to deployment processes. Where app dev focuses on continuous development, operations tries to match their velocity with continuous deployment. You can see where this is going, right? Exactly. The next (hopefully last but perhaps only penultimate) obstacle is the network. It is not yet agile, nor has it fully embraced the notion it needs to be. But it does, because network service velocity is currently a growing issue for organizations, because it is vastly slower than app dev and operations rate of execution. Thus, SDN (or something like it) was inevitable. Interestingly enough, InformationWeek's most recent SDN survey showed overwhelmingly that improving service velocity - "a more efficient and flexible network that speeds service delivery" - is used to justify investments in SDN by 76% of respondents. That may because app dev and devops are already running at full tilt but the network? Not so much. Something had to change, and given that service velocity is significantly impeded today by the network, it just makes sense that it was going to have to change to accommodate the rest of the IT organization. How SDN Addresses Service Velocity. Or Doesn't As the Case May Be. If you consider the five key characteristics defined by the ONF as being core to SDN you'll find that all of them directly or indirectly (by enabling other technologies) address this need for service velocity. ONF Characteristic Address Need for Service Velocity by Directly programmable Enabling automation Agile Improving responsiveness of netops Centrally managed Reduces complexity of the network, which can impede provisioning of services Open standards-based and vendor-neutral Can reduce complexity by ensuring consistency of interfaces used for automation and provisioning Programmatically configured Assists in automation SOURCE: Open Networking Foundation Unfortunately, the classical SDN architecture as defined by ONF (and used by most people as the common definition) is very focused on service velocity of layer 2-3 forwarding functions and some layer 4 services, but not very good at improving service velocity rates for higher order services. Service Chaining on the Horizon The reality that SDN's network focus (L2-3) does not adequately address the challenges posed by application layer services (L7) meant some other approach was necessary to complete the full "network" implied by the "N" in SDN. That some other approach appears to be service chaining. Use Case Purpose Benefit Service Insertion (or Service Chaining) To create dynamic chains of L4-7 services on a per tenant basis to accommodate self-service L4-7 service selection or policy-based L4-7 (e.g. turning on DDoS protection in response to attacks, self-service firewall, IPS services in hosting environments, DPI in mobile WAN environments) Provisioning times reduced from weeks to minutes, improved agility and self-service allows for new revenue and service opportunities with substantially lower costs to service From SDNCentral "SDN Use Cases" There are already a variety of approaches bubbling to the surface with respect to how best to implement service chaining in conjunction with (and sometimes separately from) SDN architectures. In general, however, the concept is fairly simple. Applications have a need for application services that operate at L4-7. A reactive SDN architecture is not well-suited to dealing with the requirements to operate said services. Service chaining assumes that all L2-3 traffic routing and switching is managed by the SDN controller, and when an application has need of these services, the SDN controller will ensure that traffic is forwarded to the appropriate service(s), chaining them (in a manner similar to orchestration) if there are more than one that need to be invoked. Some proposals suggest using a new protocol that "tags" (yes, much like VXLAN and NVGRE tag packets for routing purposes) packets and flows in order to enforce execution order, others suggest using policy, others still simply hard coding the order of invocation. Regardless of the implementation details, the concept of service chaining remains fairly close no matter who is proposing the solution. Rather than coding the "next hop" in each application service, it's software defined so that it can be programmatically and dynamically, if necessary, modified to fit the application. The good news is that Service Chaining in theory appears to address service velocity needs for application services. Which means in conjunction with an SDN implementation, service chaining provides a full network stack that is software-defined and improves service velocity to match that of the network group's app dev and devops counterparts. Which is what we need to happen to prevent dev and ops from viewing the provisioning of application services in the network in the same light as booking a cruise with Odysseus. .F5 Synthesis: Integration and Interoperability
#SDN #OpenStack #Cloud #devops #SDAS #SDDC How F5 synthesizes third-party network and orchestration technologies The silos within IT are breaking down, at least in terms of awareness of each other and the need to coordinate provisioning and orchestration of compute, network and application services. No longer is it acceptable to simply provide a solution; that solution must integrate, collaborate and interoperate with a plethora of existing and emerging data center technologies such as SDN, cloud management platforms, and virtualization frameworks. After all, part of the raison d'être for SDN is the need to enable the network with the agility and flexibility of its counterparts- devops and application development - necessary to improve service velocity. That goal cannot be realized by enabling just the underlay networks addressed by SDN architectures. The application service layers (4-7) must also support the programmability, dynamism, and flexibility promised by SDN guiding architectural principles. F5 Synthesis follows those guiding principles, and enables the automated provisioning and orchestration of application service layers, but it does not do so in a vacuum. Careful attention to interoperability with SDN architectures, overlay network protocols, traditional network technologies and cloud environments ensures the ability to deploy the high-performance service fabric in any environment. But more than interoperability is required today, as the need to provision and orchestrate the entire data center is the goal. That requires open APIs but it also requires integration. While there are certainly some organizations who prefer to build their own software-defined data center by leveraging open APIs, there are others who desire a more packaged approach and expect a certain level of integration work to exist already. F5 supports both with equal alacrity. For those rolling their own systems, F5 Synthesis exposes open APIs at the fabric, platform, service and management layers. Both control and data plane are equally programmatic, with a variety of options available for automating and orchestration everything from configuration and policy management, monitoring and reporting, provisioning and elasticity to programmatically participating in the data path. Figure 1: F5 platforms are programmatically enabled at the control, configuration and data path planes. For those desiring a more packaged approach, F5 has paid especial attention to integration with key SDN and cloud partners such as Insieme, BigSwitch, Arista, VMware and Amazon, Rackspace and Microsoft (Azure). F5 is also an active participant in ONF, ETSI NFV ISG and IETF as well as OpenStack. F5 Synthesis' integration with these partners and support for developing standards is designed to provide a holistic, data center solution capable of automatically provisioning and orchestrating the entire data center stack from layer 2-7 networking and services to applications and compute. For example: BigSwitch leverages the F5 BIG-IQ™ Cloud REST API to integrate the Big Virtual Switch network virtualization application, BIG-IP® Application Delivery Networking (ADN) services and OpenStack into a flexible and unified cloud orchestration framework. BIG-IQ Cloud connects with Amazon Web Services to enable provisioning and orchestration of F5 BIG-IP in AWS. BIG-IQ Cloud connects with VMware vCloud Director and VMware vCloud Networking and Security to enable two-way communication between BIG-IQ Cloud and the VMware vCloud Director portal, so you can configure application networking services directly from VMware vCloud Director. BIG-IQ Cloud also integrates directly with VMware NSX, enabling automated network and service provisioning via F5 iApps. Arista EOS interacts with F5's iControl API to dynamically update the state of servers participating in a server load balancing pool during switch-level fault detections to ensures the highest levels of application availability and performance. The open API framework on the Insieme controller integrates with F5 BIG-IP via iApps to automate network and service provisioning, providing the best user experience without compromising on performance. Insieme Application-Centric Infrastructure defines a policy-based service insertion mechanism for both physical and virtual ADC appliances The F5 Synthesis partner ecosystem include a growing number of application and security partners like WebSense and WebRoot as well. We've always believed that in order to truly help customer's succeed in delivering applications we had to play nice with both applications and the network. Our view remains the same today as it has been in that respect. We're committed to ensuring F5 Synthesis can integrate and interoperate north and south, east and west, in ways that enables organizations to realize a truly software-defined data center. Additional Resources: F5 Synthesis: The Time is Right F5 and Cisco: Application-Centric from Top to Bottom and End to End F5 Synthesis: Software Defined Application Services
SDN: An architecture for operationalizing networks
As we heard at last week’s Open Networking Summit 2014, managing change and complexity in data centers is becoming increasingly difficult as IT and operations are constantly being pressured to deliver more features, more services, and more applications at ever increasing rates. The solution is to design the network for rapid evolution in a controlled and repeatable manner similar to how modern web applications are deployed. This is happening because it is no longer sufficient for businesses to deliver a consistent set of services to their customers. Instead, the world has become hyper-competitive and it has become necessary to constantly deliver new features to not only capture new customers but to retain existing customers. This new world order poses a significant conflict for the operations side of the business as their charter is to ensure continuity of service and have traditionally used careful (often expensive) planning efforts to ensure continuity of service when changes are needed. The underling problem is that the network is not operationalized and instead changes are accomplished through manual and scripted management. The solution for operations is to move towards architectures that are designed for rapid evolution and away from manual and scripted processes. Software Defined Networking address these challenges by defining a family of architectures for solving these types operational challenges and operations teams are latching on with a rarely seen appetite. The key to the success of SDN architectures is the focus on abstraction of both the control and data planes for the entire network via open APIs (not just the stateless Layer 0-4 portions). The first layer of abstraction allows for a centralized control plane system called an SDN Controller, or just Controller, that understands the entire configuration of the network and programmatically configures the network increasing the velocity and fidelity of configurations by removing humans from configuration loop – humans are still needed to teach the Controller what to do. These Controllers allow for introspection on the configuration and allow for automated deployments. As Controllers mature, I expect them to gain the capabilities of a configuration management system (CMS) allowing for network architects to rapidly revert changes virtually instantaneously. The second layer of abstraction allows for network architects or third parties to programmatically extend the capabilities of a data path element. This can be as seemingly simple as adding a match-and-forward rule to a switch (e.g., OpenFlow) or as seemingly complex as intercepting a fully parsed HTTP request, parsing an XML application object contained within, and then interrogating a database for a forwarding decision (e.g., LineRate and F5) based on the parsed application data. However, realizing the fully operational benefits of SDN architectures requires that the entire network be designed with SDN architectural principles including both the stateless components (e.g., switching, routing, and virtual networking) and the stateful components (e.g., L4 firewalls, L7 application firewalls, and advanced traffic mangement). Early on SDN proponents, as SDN evolved from a university research project, proposed pure stateless Layer 2-3 networking ignoring the complexities of managing modern networks that call for stateful L4-7 services. The trouble with this approach is that every additional operational domain disproportionately increases operational complexities, as the domains need to be “manually” kept in sync. Recognizing this need, major Layer 2-4 vendors, including Cisco, have formed partnerships with F5 and other stateful Layer 4-7 vendors to complement their portfolios. With the goal of helping customers operationalize their networks, I offer the following unifying definition of SDN for discussion: “SDN is a family of architectures (not technologies) for operationalizing networks with reduced operating expenses, reduced risks, and improved time to market by centralizing control into a control plane that programmatically configures and extends all network data path elements and services via open APIs.” Over the next few months I’ll dig deeper into different aspects of SDN – stay tuned!F5 and Cisco: Application-Centric from Top to Bottom and End to End [End of Life]
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. #SDN #SDDC #SDAS #ACI The meteoric rise of the application as one of the most important - if not the most important - factor contributing to business success today should not be surprising. In response, businesses continue to build newer, better and more mobile-friendly applications to support the nearly insatiable appetite for apps. And it's not just consumers, either. The average Fortune 500 Company supports thousands of applications with increasing pressure to support more in mobile and cloud form. If that's not daunting enough, we have only begun to enter era of the Internet of Everything (IoE), with even more devices and applications needing to be connected and secured. These increases putincredible pressure on IT to operationalize. Organizations have responded withnew approaches to application development (Agile) and operations (devops), but in many cases the network remainsas manually managed as ever. Given the importanceof network andapplication services to delivering and securingapplications, it is imperative that IT be afforded the means to operationalize it, too, lest it becomethe immovable object in the path of an irresistible force. We believe Cisco and F5 share a common vision for simplifying networking end to end and enabling rapid network service provisioning by taking an application-centric approach to solving key pain points in customer’s next generation data centers while meeting their critical data center requirements today. F5's strategy is embodied in Synthesis, Cisco in its Application Centric Infrastructure (ACI). These strategies together can help customers to realize at a system level improved service velocity, best-in-class performance and reduced complexity, capabilities considered vital for data centers today to support a diverse and growing number of applications. Figure 1: Cisco APIC manages and distributes application policies that automate and orchestrate network and application services to enable an application centric infrastructure. Cisco ACI provides a groundbreaking service insertion framework that allows automated service injection, network stitching and orchestration that reduces the complexity and brittle nature of traditional architectures. The Application Policy Infrastructure Controller (APIC) provides centralized service automation and policy control for network and F5 Software Defined Application Services TM (SDAS) delivered via F5 Synthesis TM . An integration of APIC and F5 Synthesis, could help IT organizations to deliver application centric, service enabled network and application service automation in existing and next-generation data centers. A joint solution would support virtual workload mobility and continuous delivery of applications without compromising on consistent, scalable network and application services. A Unified, Comprehensive Solution for the Data Center Cisco APIC enables a unified, application-driven policy approach for infrastructure that aligns with F5's own application-aware service model, supporting a more comprehensive application-focused data center solution. Cisco APIC empowers administrators to define an application-specific policy, which is then distributed across the ACI network fabric - including services deployed on F5's high performance services fabric. This allows the chaining of network and application services critical to the successful delivery of applications. Cisco's ACI architecture is built on a fabric foundation delivering best-in-class infrastructure that, like F5's service fabric, can be composed of hardware, software and virtual components without sacrificing the benefits realized through a unified, consistent policy automation framework. The combination of a network and service fabric supporting emerging industry standards as well as traditional architectures allows organizations to transition to new data center models based on their own technology and business requirements. F5's application-driven service model is able to consume Cisco APIC policies through its own open API framework, supporting automated provisioning across the F5 high performance services fabric. The result is end-to-end visibility of applications and tenants. The APIC acts as a centralized point of configuration management and automation for application services, and tightly coordinates service delivery with network automation. The APIC creates a logical topology model that simplifies complicated service chains and supports rapid service insertion to dramatically improve application service velocity. By delivering end-to-end dynamic service chaining with granular application telemetry, the Cisco ACI and F5 Synthesis solutions allows IT to operationalize key data center network and application services necessary to meet business and consumer demands for application performance, security and reliability. It will help businesses realize cost savings and greater levels of agility through automation, operational simplicity and improved performance. You can learn more about Synthesis hereand Cisco ACI here.If apps incur technical debt then networks incur architectural debt
#devops #sdn #SDDC #cloud 72%. That's an estimate of how much of the IT budget is allocated to simply keeping the lights on (a euphemism for everything from actually keeping the lights on to cooling, heating, power, maintenance, upgrades, and day to day operations) in the data center. In a recent Forrester Research survey of IT leaders at more than 3,700 companies, respondents estimated that they spend an average 72% of the money in their budgets on such keep-the-lights-on functions as replacing or expanding capacity and supporting ongoing operations and maintenance, while only 28% of the money goes toward new projects. How to Balance Maintenance and IT Innovation This number will not, unfortunately, significantly improve without intentionally attacking it at its root cause: architectural debt. Data Center Debt The concept of "debt' is not a foreign one; we've all incurred debt in the form of credit cards, car loans and mortgages. In the data center, this concept is applied in much the same way as our more personal debt - as the need to "service" the debt over time. Experts on the topic of technical debt point out that this "debt' is chiefly a metaphor for the long-term repercussions arising from choices made in application architecture and design early on. Technical debt is a neologistic metaphor referring to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy. Wikipedia This conceptual debt also occurs in other areas of IT, particularly those in the infrastructure and networking groups, where architectural decisions have long lasting repercussions in the form of not only the cost to perform day-to-day operations but in the impact to future choices and operational concerns. The choice of a specific point product today to solve a particular pain point, for example, has an impact on future product choices. The more we move toward software-defined architectures - heavily reliant on integration to achieve efficiencies through automation and orchestration - the more interdependencies we build. Those interdependencies cause considerable complexity in the face of changes that must be made to support such a loosely coupled but highly integrated data center architecture. We aren't just maintaining configuration files and cables anymore, we're maintaining the equivalent of code - the scripts and methods used to integrated, automate and orchestrate the network infrastructure. Steve McConnell has a lengthy blog entry examining technical debt. The perils of not acknowledging your debt are clear: One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. Debt must be serviced, which is why the average organization dedicates so much of its budget to simply "keeping the lights on." It's servicing the architectural debt incurred by a generation of architectural decisions. Refinancing Your Architectural Debt In order to shift more of the budget toward the innovation necessary to realize the more agile and dynamic architectures required to support more things and the applications that go with them, organizations need to start considering how to shed its architectural debt. First and foremost, software-defined architectures like cloud, SDDC and SDN, enable organizations to pay down their debt by automating a variety of day-to-day operations as well as traditionally manual and lengthy provisioning processes. But it would behoove organizations to pay careful attention to the choices made in this process, lest architectural debt shift to the technical debt associated with programmatic assets. Scripts are, after all, a simple form of an application, and thus bring with it all the benefits and burdens of an application. For example, the choice between a feature-driven and an application-driven orchestration can be critical to the long-term costs associated with that choice. Feature-driven orchestration necessarily requires more steps and results in more tightly coupled systems than an application-driven approach. Loose coupling ensures easier future transitions and reduces the impact of interdependencies on the complexity of the overall architecture. This is because feature-driven orchestration (integration, really) is highly dependent on specific sets of API calls to achieve provisioning. Even minor changes in those APIs can be problematic in the future and cause compatibility issues. Application-driven orchestration, on the other hand, presents a simpler, flexible interface between provisioning systems and solution. Implementation through features can change from version to version without impacting that interface, because the interface is decoupled from the actual API calls required. Your choice of scripting languages, too, can have much more of an impact than you might think. Consider that a significant contributor to operational inefficiencies today stems from the reality that organizations have an L4-7 infrastructure comprised of not just multiple vendors, but a wide variety of domain specificity. That means a very disparate set of object models and interfaces through which such services are provisioned and configured. When automating such processes, it is important to standardize on a minimum set of environments. Using bash, python, PERL and juju, for example, simply adds complexity and begins to fall under the Law of Software Entropy as described by Ivar Jacobson et al. in "Object-Oriented Software Engineering: A Use Case Driven Approach": The second law of thermodynamics, in principle, states that a closed system's disorder cannot be reduced, it can only remain unchanged or increased. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, always increases. This is known as software entropy. Entropy is the antithesis of what we're trying to achieve with automation and orchestration, namely the acceleration of application deployment. Entropy impedes this goal, and causes the introduction of yet another set of systems requiring day-to-day operational attention. Other considerations include deciding which virtual overlay network will be your data center standard, as well as the choice of cloud management platform for data center orchestration. While such decisions seem, on the surface, to be innocuous, they are in fact significant contributors to the architectural debt associated with the data center architecture. Shifting to Innovation Every decision brings with it debt; that cannot be avoided. The trick is to reduce the interest payments, if you will, on that debt as a means to reduce its impact on the overall IT budget and enable a shift to funding innovation. Software-defined architectures are, in a way, the opportunity for organizations to re-finance their architectural debt. They cannot forgive the debt (unless you rip and replace) but these architectures and methodologies like devops can assist in reducing the operational expenses the organization is obliged to pay on a day-to-day basis. But it's necessary to recognize, up front, that the architectural choices you make today do, in fact, have a significant impact on the business' ability to take advantage of the emerging app economy. Consider carefully the options and weigh the costs - including the need to service the debt incurred by those options - before committing to a given solution. Your data center credit score will thank you for it.F5 Synthesis: Now with more VMware than ever!
Whether you've bought into DevOps or NetOps or SDN or SDDC (or all of them) as a way to operationalize the data center, one thing is clear: organizations are desirous of ways to deliver applications and their infrastructure faster with fewer disruptions and with greater consistency. Automation and orchestration frameworks offer IT operations groups of all kinds - from storage to compute to network to security - a means to accomplish that task. That means every one who provides enterprise solutions in one of those four IT areas needs to support those efforts through APIs and, more importantly, pre-validated integration with the frameworks and tools customers want to use. When we asked over 300 customers about the tools and frameworks they use and want to use to automate and orchestrate their application infrastructure deployment experience the overwhelming answer was VMware. That was a pleasant result to hear, given that we've been partnering with VMware for many years, bringing to market architectures, automation packages and integration with our F5 Synthesis architecture. So it's probably no surprise that this post brings news of new and expanded offerings with VMware available in VMware's vCloud Marketplace. Availability and security services delivered through BIG-IP Local Traffic Manager ™ , Global Traffic Manager ™ , and Application Security Manager ™ software are now available, having achieved vCloud Air “Elite” certification for all three. With F5 Synthesis Simplified Business Model, customers can take a "bring your own license" approach when deploying VMware vCloud with F5's Good, Better, and Best packages. F5 also continues its history of contributing at VMware industry and partner events by sponsoring and exhibiting (booth #209) at this year's VMware Partner Exchange (PEX) conference. We'll also be participating in a variety of activities including: Providing Automated Failover and Reliable Business Continuity with F5 and VMware vCloud Air vCloud Air Product Line Manager Yatin Chalke and F5 Business Development Manager Matt Quill discuss how F5 brings advanced application services to vCloud Air to automate disaster recovery/business continuity, hybrid cloud application deployments, cloud bursting, and global application availability. F5 and VMware’s Horizon – Perfect Together In this breakout session, F5 Sr. Solution Architect Justin Venezia explains integration methods between F5 and each of VMware's End User Computing products. The program includes a deep-dive into sample BIG-IP configurations and a demo of combined load balancing and remote access solutions with VMware Horizon. Boost Your Opportunity by Selling Integrated Solutions with VMware and F5 F5 Regional VP of Channel Sales Keith McManigal and VMware Channel Sales Director Troy Wright outline the ways that F5’s BIG-IP application delivery platform and VMware solutions complement each other. Real-world examples are used to clearly demonstrate the benefits of combining F5 with VMware products such as NSX, Horizon, AirWatch, vRealize, and vCloud Air. If you're attending VMware PEX be sure to stop by (that's booth #209). If you aren't (or even if you are) you can follow along on Twitter @f5networks for live updatesF5 Synthesis: Open, Secure and Production-Ready SDDC
#vmworld #SDDC #NSX #SDAS #cloud VMware and F5 offer up a production-ready L2-7 SDDC Many of us may recall from our school days some fairly typical "word problems" in math class. Consider for a moment this familiar pattern: If it takes Bob 27 hours to complete a job, how long will it take Bob and Alice to complete the job working together? The premise is that by adding more people to work on the same "job", it will get done faster. Mathematically, we can prove that this is true. But in the real world, we know that it isn't. Adding more people is, at some point, actually a negative. Brook's Law, which is something most developers are familiar with thanks to The Mythical Man-Month, tells us that there is a tipping point at which adding a to a project makes it take more, not less time. This is often illustrated through the analogy that "Nine women can't make a baby in one month." Thus, the pressure on operations coming from an increase in devices, application and service mobility and an increase in new services to deploy and manage can't necessarily be effectively addressed by simply throwing more people at the problem. The overhead from communications that occurs when additional people must synchronize and track efforts becomes, at some point, an impediment to forward progress. So if operations and networking teams can't scale effectively to meet rising demand by incremental increases in staff, how can they manage? This is the conundrum software-defined technologies are attempting to address with automation and orchestration. Standardization of the interfaces between systems through software-defined techniques using open standards (APIs and protocols) enables operations and networking teams to more seamlessly orchestrate provisioning workflow processes. Doing so relieves pressure on both teams, enabling them to effectively increase their deployment throughput - without compromising on stability or security. The Software Defined Data Center VMware promotes the notion of a Software Defined Data Center (SDDC) as a solution to this growing challenge. The answer is the software-defined data center (SDDC): the ideal architecture for private, public, and hybrid clouds. Pioneered by VMware and recognized by the industry and analysts alike, SDDC extends the virtualization concepts you know— abstraction, pooling and automation — to all data center resources and services. - http://www.vmware.com/software-defined-datacenter#sthash.S7uusVif.dpuf Extending virtualization concepts to the network isn't necessarily the same as turning network services into virtual machines, but is rather about abstracting the network into composable services that can be rapidly provisioned, easily migrated and software-defined. Virtualization is, primarily, about abstraction; about decoupling hardware from software, applications from networks, and businesses from physical locations. F5 continues its 7 year history of partnering with VMware to provide secure, integrated and seamless solutions that enable the next-generation architectures necessary to meet existing and future challenges associated with delivering applications anywhere, to anyone, at any time. Together, VMware and F5 are offering a production-ready L2-7 SDDC without compromising on key IT concerns like security and control. Today we're announcing general availability of the software components that allow for the integration between VMware NSX and BIG-IQ which will enable an application-driven approach to provisioning Software Defined Application Services (SDAS) using F5 iApps. Along with the availability of these components is a ready for implementation Synthesis Reference Architecture offering organizations guidance on enabling seamless service insertion for application delivery, security and network services as well as operational agility for application services such as acceleration, availability and security. This solution is intended to allow VMware environments (using either vSphere + vCNS, or vSphere + vCNS + vCloud Director) to provision the necessary L4-7 application services much more rapidly and efficiently than before. Organizations can use physical or virtual BIG-IP editions to deliver all the F5 Synthesis Software Defined Application Services desired using VMware-driven orchestration. A Software Defined Data Center requires a collaborative, ecosystem approach inclusive of all the services across the network necessary to successfully deliver applications. Like F5 Synthesis, VMware NSX uses open standards and cultivates a healthy, robust ecosystem. The nature of the SDDC demands an open, standards-based approach to enable organizations the option of selecting the solutions and services they need without being required to figure out how to integrate them into a comprehensive data center wide system. With VMware and F5, organizations can scale operations and networking to deliver a full complement of those services without compromise - or running afoul of Brook's Law. Additional Resources: F5 Synthesis F5 VMware NSX Reference ArchitectureTotally Unscientific SDN and Cloud Survey Results
#SDN #Cloud #F5 #agility2013 #SDDC #devops We did some question asking during SDN sessions at F5's Agility conference. Here's what we discovered about ... everything that's a buzzword Before you get any further, let me reiterate - these are totally unscientific and the sample size is rather small as it was taken from two sessions at the conference focusing on SDN and application services. The good news is that the results pretty much mirror every other survey and research with respect to devops, cloud, and SDN. One of my favorite questions is to determine whether cloud is being adopted because it makes sense or because it's a mandate from on high. As expected, the majority (62%) of respondents indicated the adoption of cloud in their organization was... a company mandate. Some interesting points I pulled out specifically around current data center initiative priorities: 25% of respondents are migrating to a devops model of application deployment 50% of respondents are incorporating SaaS offerings into solutions sold by the organization 65% of respondents are focused on implementing a software defined data center (SDDC) using virtualized resources Despite all the hype around mobile applications, only 20% of respondents have a mobile "first" strategy for applications and infrastructure When looking at responses with regard to private cloud deployments: 24% say a full service deployment is in place 17% of respondents have a pilot deployment in place 19% of respondents are putting plans together with no solid timeline for deployment Only 12% had no plans at all for private cloud Of the popular private cloud platforms: 86% indicated they were using VMware 22% are adopting OpenStack 11% have elected to use CloudStack And of course the one you've been waiting for: SDN A whopping 41% have no plans to deploy SDN 36% of respondents are putting plans together but have no solid timeline for deployment A somewhat surprising 10% of respondents have a pilot SDN deployment in place
