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: To boldly go where no ADC has gone before
#SDAS #cloud #DDoS #infosec It's an application world. But it's also a hybrid cloud, very mobile world, too. Applications might be on-premise, in the cloud or delivered as a SaaS application. Users might be at home, on the road or in the office using a laptop, a tablet a phone or, increasingly, a wearable device. The complex combinations of device, network and application is growing and business, employees and consumers alike expect the same level of performance, security and reliability regardless of where they - and their applications - might be right now. That means application delivery has to change, too. The same services that ensure performance, enhance security and assure availability must be as mobile and location-agnostic as the apps and users they serve. It's no longer enough just to support service delivery from a cloud environment - though that's certainly a requirement - it's also imperative that application services be able to move along both axes - the cloud continuum and the app-user continuum. That's because some services naturally gravitate toward the application like the moon to the earth; services like SSL and SLB and web application firewalls. Others, like SSO, GSLB and secure web gateways, are naturally pulled toward the users because ultimately it is a user-oriented service they are performing. So it's not enough to say services must be deployable from one end of the cloud axis to the other, from private cloud and traditional on-premise to the ultimate abstraction, as a service. Services must also be flexible enough to move closer to the app or the user, depending on their designated purpose. In much the same way that certain types of ADC capabilities, such as caching, were placed around the Internet and called CDNs in an effort to move content closer to users, the services traditionally delivered by an on-premise ADC must do the same; a service delivery network, if you like. That is, they must be able to be placed "around the Internet". They must go, as Star Trek fans say, where no ADC has gone before... We can simply call it "hybrid" but really, the new model is a combination of not just traditional and cloud, or multiple cloud models, or some combination thereof - it's delivering services across both axes; north and south, east and west, cloud and user and app and device. What We (that's the corporate we today) have announced today is the delivery of Software Defined Application Services (SDAS) from traditional, cloud and as a service offerings. We're laying the foundation for organizations to move services like DDoS protection and web application firewalling closer to the users or apps that need them with F5 Silverline. F5 Synthesis is focused on delivering applications without constraints. Some of those constraints include the inability to deploy the services apps need to remain available, fast and secure and are purely based on the fact that apps and users are on the move, sometimes frequently. Applications shouldn't be constrained and neither should users. Productivity and competitive advantage depends today on applications and that means applications anywhere. Whether in the cloud or on premise, as a Service or as part of an integrated system, F5 Synthesis delivers the software-defined application services that applications need and businesses rely on to meet and exceed user expectations.Operationalizing The Network now available with F5 and Cisco ACI [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. #ACI #SDN With the availability of the F5 device package for Cisco APIC, you can now rapidly provision the (entire) network from top to bottom. A key concern of IT continues to center on provisioning of network services. Whether eliminating the time consuming task of manually provisioning network attributes network device by device or trying to eliminate inefficiencies within the broader "network" service provisioning process, the goal is the same: increase the speed and accuracy with which network services are provisioned. SDN and related technologies promise to do just that by operationalizing the network. Last fall Cisco announced its Application Centric Infrastructure (ACI) vision and then focused on the network by bringing its Application Policy Infrastructure Controller ™ (APIC) to fruition. Seeing our visions align fully on the need for operationalization of the network with a focus on the application, F5 committed to supporting Cisco APIC by delivering a device package to enable the rapid provisioning of F5's Software Defined Application Services (SDAS). Today we're pleased to announce the availability - at no charge - of that device package. The availability lets customers configure application policies and requirements for F5 services across the L2-7 fabric and subsequently automatically provision the services necessary to ensure the entire stack of network services - from top to bottom, layer 2 through layer 7 - are available when applications need them. You can download the F5 Device Package for Cisco APIC todayand learn more about how F5 and Cisco work together: Cisco Alliance Cisco Resources on DevCentralSDN Prerequisite: Stateful versus Stateless
#SDN #SDAS #cloud Things you need to know before diving into SDN... We've talked before about the bifurcation of the network, which is driven as much by the evolution of network services from "nice to have" to "critical" as it is by emerging architectures. The demarcation line in the network stack has traditionally been - and remains - between layers 3 and 4 in the OSI model. The reason for this is that there is a transition as you move from layer 3 to layer 4 from stateless networking to stateful networking. This is important to emerging architectures like SDN because this characteristic determines what level of participation in the data path is required. Stateless networking requires very little participation. It's limited to evaluating network protocol frames and headers for the purpose of determining where to forward any given packet. The information extracted from the packet is not saved; it is not compared to previous packets.This is why it's stateless, because no information regarding the state of the communication is retained. It is evaluated and the packet is forwarded out the appropriate port based on what's in the FIB (Forwarding Information Base) or what's more commonly referred to as the "forwarding table." Stateful networking, which begins at layer 4, retains certain information extracting from frames and packets and, as you move up the stack, from the application layer. It does this because protocols like TCP are connection-oriented and try to maintain guaranteed delivery. This is achieved through the use of sequence numbers in the TCP headers that, when out of order or lost cause the network to retransmit the packets. There is state associated with TCP, i.e. "I have received packet 1 and am waiting for packet 2 in this connection." This is readily seen in the use of ACKnowledgment packets associated with TCP. There is a pre-designated flow associated with TCP that depends on the state of the end-points involved in the connection. When a networking service operating at layer 4 or higher is inserted into this communication flow, it must also maintain the connection state. This is particularly true of staple stateful services such as security and load balancing, which rely on state to provide stateful failover services (i.e. without simply dropping connections) or to detect attacks based on state, such as SYN floods. The higher a network service operates in the network stack, the more participation is required. For example, application routing based on HTTP headers (the URI, the hostname, cookie values, etc... ) rely on the ability of an intermediate network device maintaining state as well as extracting data from within the payload of a message (which is not the same as a packet). A message might actually require 2 or 3 or more packets, as data transferred by modern web applications is often larger than the network MTU of 1500 bytes. This means the intermediate device operating at the application layer must be stateful, as it must act as the end point for the connection in order gather all the packets that make up a message before it can extract the data and then execute its policies. This is why we also emphasize that layer 2-3 is "fixed" and layer 4-7 is "variable." Networking protocols at layer 2-3 are governed by standards that clearly define the layout of Ethernet frames and IP packets. Devices operating at those layers have highly optimized algorithms for extracting the information needed from frames and packet headers in order to determine how to forward the packet. TCP affords the same luxury at layer 4, but as networking moves up the stack the exactly location of information necessary to make a forwarding decision become highly variable. Even with a clearly defined protocol like HTTP, there is a wide variation in where certain data might be in the header. This is because not all headers are required and unlike Ethernet and IP and even TCP, where options may not be specified, there is still room reserved for those values. HTTP does not require that space be reserved for optional headers. They are simply left out, which can dramatically change the location (and thus the method of extraction by the intermediate device) of the data necessary to formulate a forwarding decision. Say you had a form to fill out and, depending on the answer to question 2 you might go on to question 3 or skip to question 8. If that form were layer 2 or 3, each question would be clearly numbered. Skipping to question 8 would be quick and easy. But if that form were layer 7, the questions are not labeled, and to get to question 8 you have to count each of the questions manually. That's the difference between "fixed" and "variable". It's why compute resource requirements are more important to layer 7 than they are to layer 2 or 3. Why this matters to SDN This matters a great deal to SDN architectures because of how it impacts the control-data plane separation architecture. Stateless networking is perfectly suited to an architecture that places responsibility for making forwarding decisions on a centralized controller because the frequency with which those decisions must be made is relatively low. Conversely, stateful networking requires more participation and more frequent decisions as well as requiring the maintenance of state for each and every connection. This has serious implications for the controller in such a model, as it forces issues of controller scalability and resource requirements into the equation as the controller more actively participates (and stores more information) with stateful networking than it does with stateless networking. This is not to say that SDN architecture is incompatible with higher order network services. It just means that the SDN solution you choose for stateless networking will almost certain not be the same SDN solution you choose for stateful networking. That means it's important to investigate solutions that address both of your "networks" with an eye toward integration and interoperability.Should you focus on consolidation or standardization?
There is a difference. One is strategic, one is tactical. One lays the foundation for the future, the other sweeps the past under the rug. There is a move (again) in technology that pits consolidation as the be-all and end-all of tactical maneuvers in the data center to reduce operating expenses. The hue and cry is not surprising. Many of us have seen it before. An onslaught of technology in the forms of solutions and services rains down upon the data center, promising to solve this pain point and the next. Eventually, overwhelmed by the unmanageable number of devices, appliances and servers needed to support all these disparate solution, consolidation arrives on a white horse to save the day. Get rid of all the boxen! Save money on power, on cooling, on management. Simplify your architecture! It's a message that does not go unheard in the upper ranks of IT. Reducing operating expenses is a C-level priority, taking number 7 on the CIO top ten according to the "35th Annual SIM IT Trends Study" announced by The Society for Information Managementand discussed on CIOinsight.com. Consolidation isn't a bad approach at all. It certainly will reduce the pain point foot print, which in turn reduces operating costs. But it's a tactical approach, not a strategic one. When you consolidate functions onto a single device, you're essentially just making room for more boxes that, one day, will have to be consolidated again. It's transferring architectural debt to a single system, simply transferring the debt from multiple credit cards to another one. Sure, it has a lower interest rate, but you're still just kicking the can down the road so you can (more than likely) make the same architectural choices that got you into debt in the first place. Standardization, on the other hand, is based on a platform approach which is strategic (i.e. forward) looking. A platform is built to be expanded; to include related and adjacent service deployment now and in the future. You aren't just transferring the debt, you're laying a foundation for being able to keep that debt down in the future by ensuring operational commonality across services now and in the future. Standardization says "let's use the same platform, the same management, the same systems to support as many services as possible." That means lower operational costs across the entire network because skills and knowledge become applicable to a wider range of technologies. It isn't about cramming as much as you can onto a single box, it's about optimizing skills, systems and knowledge across broader sets of services. That being said, one solution to this dilemma [the need to show real value to the business while reducing operating costs] is for IT organizations to focus more on enterprise optimization: standardizing processes, data, technology and applications wherever possible across the enterprise. Benchmarking data shows that standardization can reduce the support and operations cost associated with the IT landscape, and the impact can be dramatic. For instance, top performing IT organizations that drive enterprise optimization have on an average 26 percent higher allocation of their IT spend toward strategic initiatives. -- Monday Metric: Benefits of IT Standardization SDN and SDAS offer standardization at the technology layers. Not just consolidation, standardization. DevOps encourages standardization across processes and (if its paying attention, at the technology layer responsible for automation and orchestration). Combining these technologies and approaches to architecture, management and automation offer IT the means to optimize the data center and reduce operating costs that ultimately enable IT to focus more on strategic initiatives that offer value to (and in many cases, enable) the business. It isn't that there's a single box upon which to consolidate all these services (there is, but that's not the strategic value) but that the underlying platform is standardized and provides the same APIs, templates and command and control console through which all the services are provisioned, configured and managed across their respective lifecycles. That commonality, that standardization, means improved efficiency that translates into reduced operating costs. But more than that, it's a platform that can (and will) be extended to include additional services, making it possible to consume new technology as its introduced without new training, skills or management systems to learn. That's what makes it strategic: a platform approach to standardization. You can certainly gain some of these same benefits by simply consolidating services and functions onto a box. But to realize benefits today and in the future you should really be looking at standardizing on a platform instead. Otherwise you're just robbing Peter to pay Paul.F5 Synthesis: What about SDN?
#SDN #SDAS How does Synthesis impact and interact with SDN architectures? With SDN top of mind (or at least top of news feeds) of late, it's natural to wonder how F5's architecture, Synthesis, relates to SDN. You may recall that SDN -or something like it - was inevitable due to increasing pressure on IT to improve service velocity in the network to match that of development (agile) and operations (devops). The "network" really had no equivalent, until SDN came along. But SDN did not - and still does not - address service velocity at layers 4-7. The application layers where application services like load balancing, acceleration, access and identity (you know, all the services F5 platforms are known for providing) live. This is not because SDN architectures don't want to provide those services, it's because technically they can't. They're impeded from doing so because the network is naturally bifurcated. There's actually two networks in the data center - the layer 2-3 switching and routing fabric and the layer 4-7 services fabric. One of the solutions for incorporating application (layer 4-7) services into SDN architectures is service chaining. Now, this works well as a solution to extending the data path to application services but it does very little in terms of addressing the operational aspects which, of course, are where service velocity is either improved or not. It's the operational side - the deployment, the provisioning, the monitoring and management - that directly impacts service velocity. Service chaining is focused on how the network makes sure application data traversing the data path flows to and from application services appropriately. All that operational stuff is not necessarily addressed by service chaining. There are good reasons for that but we'll save enumerating them for another day in the interests of getting to an answer quickly. Suffice to say that service chaining is about execution, not operation. So something had to fill the gap and make sure that while SDN is improving service velocity for network (layer 2-3) services, the velocity of application services (layer 4-7) were also being improved. That's where F5 Synthesis comes in. We're not replacing SDN; we're not an alternative architecture. Synthesis is completely complementary to SDN and in fact interoperates with a variety of architectures falling under the "SDN" moniker as well as traditional network fabrics. Ultimately, F5's vision is to provide application-protocol aware data path elements (BIG-IP, LineRate, etc..) that can execute programmatic rules that are pushed by a centralized control plane (BIG-IQ). A centralized control-decentralized execution model implementing a programmatic application control plane and application-aware data plane architecture. Bringing the two together offers a comprehensive, dynamic software-defined architecture for the data center that addresses service velocity challenges across the entire network stack (layer 2-7). SDN automates and orchestrates the network and passes the right traffic to Synthesis High-Performance Services Fabric, which then does what it does best - apply the application services critical to ensuring apps are fast, secure and reliable. In addition to service chaining scenarios there are orchestration integrations (such as that with VMware's NSX) as well as network integrations such as a cooperative effort between F5, Arista and VMware. You might have noticed that we specifically integrate with leading SDN architectures and partners like Cisco/Insieme, VMware, HP, Arista, Dell and BIgSwitch. We're participating in all the relevant standards organizations to help find additional ways to integrate both network and application services in SDN architectures. We see SDN as validating what We (and that's the corporate we) have always believed - networks need to be dynamic, services need to be extensible and programmable, and all the layers of the network stack need to be as agile as the business it supports. We're fans, in other words, and our approach is to support and integrate with SDN architectures to enable customers to deploy a fully software-defined stack of network and application services. 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 F5 Synthesis: Integration and Interoperability F5 Synthesis: High-Performance Services Fabric F5 Synthesis: Leave no application behind F5 Synthesis: The Real Value of Consolidation Revealed F5 Synthesis: Reference Architectures - Good for What Ails Your AppsF5 Synthesis: SDN Services
#SDN #SDAS There's a whole lot more to software-defined networking than OpenFlow... There's a lot of gnashing of teeth and gnawing at industry reports over the apparent reluctance of organizations to jump with both feet into the SDN ring. According to a new QuinStreet Enterprise Executive Brief, SDN deployment among enterprises today stands at only 14 percent. The 2014 Data Center Outlook: Data Center Transformation - Where Is Your Enterprise? results also found that 15 percent of the surveyed enterprises were planning to deploy SDN within the next 12 months. Additionally, 33 percent of respondents indicated they are considering SDN. Thirty-nine percent indicated that they had no plans to deploy SDN. SDN in 2014: More Adoption and More Money for Vendors This perceived reluctance is likely due to a variety of factors including the dizzying around of "SDN" options available to organizations. One of the more prevalent technologies related to SDN is virtual overlay networks. Virtual Overlay Networks While there are many who might argue that virtual overlay networks are not SDN (and just as many who will), suffice to say that they are considered at large to be a part of the SDN technology family. A variety of options are available, including the recognizable such as VXLAN and NVGRE and the less recognizable, like NVo3 and MPLSoGRE. Options in core networking, however, are not always a good thing - particularly when they interfere with interoperability across technologies, as noted by ONUG in its recent white paper on Open Networking: Unfortunately, there are too many different tunneling protocols and no multi-vendor interoperability between virtual overlay vendors. The lack of interoperability and scalability data across vendors implementing overlay technologies is casting a shadow of doubt on the real capacity to deliver the required scalability. -- Open Networking Challenges and Opportunities, July 2014, ONUG GENEVE is the latest proposal put forth in this arena in the hopes of arriving at a common, multi-vendor supported virtual overlay network. The standards process being what it is, however, leaves organizations today with a set of perhaps unappealing choices: standardize on a single protocol now or wait. The former is unappealing because it's fairly certain that what exists today won't be the standard in the long run and the latter because it can impede progress on cloud and software-defined initiatives today. Enter F5 SDN Services F5 being strategically located where it is in the network - between users and applications - has always been able to act as a gateway for a variety of protocols. Being a full proxy-based platform means being able to act as an application protocol gateway, as a transport protocol gateway (SSL and TLS, anyone?) as well as a network protocol gateway (IPv4 to IPv6). It should be no surprise, then, that F5 Synthesis SDN services include the ability to act as a virtual network overlay protocol gateway (that's a mouthful, isn't it?). What's perhaps more important than being able to effectively bridge between virtual network overlay protocols like NVGRE and VXLAN is the ability to simultaneously support traditional virtual network and tunneling protocols such as VLAN and EtherIP. Given that IT network professionals are as unlikely to rip and replace the core network as app dev is to rip and replace legacy applications, it should be a requirement that any infrastructure supporting the delivery of applications is also able to deal with the variety of networking protocols over which such applications might be transported. F5 Synthesis SDN Services does just that by-ensuring not just interoperability but the ability to simultaneously support both legacy and modern application networking needs. Because we know that while emerging network technology may be disruptive to the market, that doesn't mean that supporting it in the network should be disruptive to the business. For more information on F5 Synthesis you can visit: http://synthesis.f5.com or read more here on DevCentral.F5 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.htmNetwork Virtualization: Instances versus Tenants
#SDN #Cloud #VCMP #SDAS #IoT Technology shifts are creating a lot of chaos, including the way we use words. Cloud. SDN. Multi-tenant. Instances. They're all inter-related and seem to have different meanings depending on who's trying to sell you what today. That's more than a tad bit disconcerting, because you know what you mean when you say "multi-tenant" but other people (trying to sell you stuff) may have a different definition. And that means when you ask about it and they say yes, you may not be getting what you expected - and that's not good for either end of the transaction. So let's talk network virtualization today, particularly with respect to the difference between "instances" and "tenants." Instance An instance, made a common part of technology's growing vernacular, stems from the need to separate the physical from the virtual, a la server virtualization. Because "server" is used to describe about fifty different things - all in the realm of technology - it became necessary to distinguish between an application "server" and an application "instance" to avoid confusion. Thus, an instance is often shorthand for virtual machine or virtual instance and essentially describes a container of functionality. For example, if I refer to an "instance" of BIG-IP I mean a virtual machine in which the BIG-IP platform is running. Note that this says nothing about the underlying hardware, which could be COTS or cloud or purpose-built hardware. That's because one of the characteristics of virtualization is abstraction, and its benefits are generally derived from the fact that it decouples the "solution" from the underlying resource provider (the hardware). Now, that's an instance. Confusion generally comes in when we start adding multi-tenancy to the discussion which, of course, is a requirement for modern architectures and deployment environments. Multi-tenancy The basic principles of multi-tenancy are similar to that of an apartment complex. Multiple tenants, all with their own isolated "living space" cohabitate within the same physical space. This enables the tenants to share the cost of the infrastructure (the physical structure) and thus lower the overall costs of living. In technological terms, the same concept applies. We want to allow multiple tenants (applications) to share the cost of the infrastructure and thus lower the overcall costs of delivery (all the services you have to have to make sure the application is secure, reliable and available). Multi-tenancy in infrastructure enables multiple tenants to cohabitate while being assured they can manage their own space in an isolated, secure fashion. The way this is achieved is to segment each instance into isolated domains, usually on a per-application basis. Depending on specific architectural, regulatory or business requirements, a single instance can be treated as equal to a single tenant. But more often than not a single instance is segmented into multiple tenant domains to enable greater sharing of costs. The end result should be the more tenants, the lower the costs*. The reason this is important is because applications require greater diversity in network policies with respect to performance, availability and access. The days of applying the same set of network policies to web application A and B are pretty much over. The coming of the Internet of Things is going to force highly differentiated policies to be put in place on a per-application basis. That means that infrastructure needs to provide multi-tenant instances able to go far beyond the simple "tenant = instance" assumption that is frequently made when discussing network virtualization because the number of applications that will be rising to support new business models and take advantage of opportunities is only going to increase in the next few years. So be careful with your words as you start to lay the network foundation you're going to need to succeed in the coming years. Make sure you know exactly what the person on the other side of the table means when they say "multi-tenant instance" and make sure it will be able to support the way in which you're going to need to deliver all those new applications. * Assuming the business model associated can achieve the economies scale required by modern architectures. Many cannot.The IoT Ready Platform
Over the last couple months, in between some video coverage for events, I've been writing a series of IoT stories. From the basic What are These "Things”? and IoT Influence on Society to the descriptive IoT Effect on Applications and the IoT Ready Infrastructure. I thought it only fair to share how F5 can play within an IoT infrastructure. Because F5 application services share a common control plane—the F5 platform—we’ve simplified the process of deploying and optimizing IoT application delivery services. With the elastic power of Software Defined Application Services (SDAS), you can rapidly provision IoT application services across the data center and into cloud computing environments, reducing the time and costs associated with deploying new applications and architectures. The beauty of SDAS is that it can provide the global services to direct the IoT devices to the most appropriate data center or hybrid cloud depending on the request, context, and application health. Customers, employees, and the IoT devices themselves receive the most secure and fastest experience possible. F5's high-performance services fabric supports traditional and emerging underlay networks. It can deployed a top traditional IP and VLAN-based networks, works with SDN overlay networks using NVGRE or VXLAN (as well as a variety of less well-known overlay protocols) and integrates with SDN network fabrics such as those from Cisco/Insieme, Arista and BigSwitch among others. Hardware, Software or Cloud The services fabric model enables consolidation of services onto a common platform that can be deployed on hardware, software or in the cloud. This reduces operational overhead by standardizing management as well as deployment processes to support continuous delivery efforts. By sharing service resources and leveraging fine-grained multi-tenancy, the cost of individual services is dramatically reduced, enabling all IoT applications - regardless of size - to take advantage of services that are beneficial to their security, reliability and performance. The F5 platform: Provides the network security to protect against inbound attacks Offloads SSL to improve the performance of the application servers Not only understands the application but also know when it is having problems Ensures not only the best end user experience but also quick and efficient data replication F5 Cloud solutions can automate and orchestrate the deployment of IoT application delivery services across both traditional and cloud infrastructures while also managing the dynamic redirection of workloads to the most suitable location. These application delivery services ensure predictable IoT experiences, replicated security policy, and workload agility. F5 BIG-IQ™ Cloud can federate management of F5 BIG-IP® solutions across both traditional and cloud infrastructures, helping organizations deploy and manage IoT delivery services in a fast, consistent, and repeatable manner, regardless of the underlying infrastructure. In addition, BIG-IQ Cloud integrates or interfaces with existing cloud orchestration engines such as VMware vCloud Director to streamline the overall process of deploying applications. Extend, Scale - and Secure F5 Cloud solutions offer a rapid Application Delivery Network provisioning solution, drastically reducing the lead times for expanding IoT delivery capabilities across data centers, be they private or public. As a result, organizations can efficiently: Extend data centers to the cloud to support IoT deployments Scale IoT applications beyond the data center when required. Secure and accelerate IoT connections to the cloud For maintenance situations, organizations no longer need to manually redirect traffic by configuring applications. Instead, IoT applications are proactively redirected to an alternate data center prior to maintenance. For continuous DDoS protection, F5 Silverline DDoS Protection is a service delivered via the F5 Silverline cloud-based platform that provides detection and mitigation to stop even the largest of volumetric DDoS attacks from reaching your IoT network. The BIG-IP platform is application and location agnostic, meaning the type of application or where the application lives really does not matter. As long as you tell the BIG-IP platform where to find the IoT application, the BIG-IP platform will deliver it. Bringing it all together, F5 Synthesis enables cloud and application providers as well as mobile network operators the architectural framework necessary to ensure the performance, reliability and security of IoT applications. Connected devices are here to stay—forcing us to move forward into this brave new world where almost everything generates data traffic. While there’s much to consider, proactively addressing these challenges and adopting new approaches for enabling an IoT-ready network will help organizations chart a clearer course toward success. An IoT-ready environment enables IT to begin taking advantage of this societal shift without a wholesale rip-and-replace of existing technology. It also provides the breathing room IT needs to ensure that the coming rush of connected devices does not cripple the infrastructure. This process ensures benefits will be realized without compromising on the operational governance required to ensure availability and security of IoT network, data, and application resources. It also means IT can manage IoT services instead than boxes. However an IoT ready infrastructure is constructed, it is a transformational journey for both IT and the business. It is not something that should be taken lightly or without a long-term strategy in place. When done properly, F5-powered IoT ready infrastructure can bring significant benefits to an organization and its people. ps Related: The Digital Dress Code Is IoT Hype For Real? What are These "Things”? IoT Influence on Society IoT Effect on Applications CloudExpo 2014: The DNS of Things Intelligent DNS Animated Whiteboard The Internet of Me, Myself & I Technorati Tags: f5,iot,things,sensors,silverline,big-ip,scale,sdas,synthesis,infrastructure Connect with Peter: Connect with F5:
