Where networks and application architecture converge lies Devops
#SDN #devops On this side is a variant of SDN: network service virtualization (NSV). On the other side is an emerging application architecture: microservices. Where they meet lies devops. One of the most fascinating things to watch in the technological shifts occurring today is to see them all converging on a singular point: applications. Whether it's securing or delivering, deploying or access, all key areas of IT are all converged on a singular focus: applications. From a developer-turned-network-geek perspective, that's doubly interesting. That's because one impacts the other, and vice-versa. One of the trends in application architecture today is a shift toward microservices. I'll oversimplify for a moment and explain that as SOA without all the baggage. A recent post on High Scalability explains the architecture - and the impact on infrastructure requirements: Where a monolithic application might have been deployed to a small application server cluster, you now have tens of separate services to build, test, deploy and run, potentially in polyglot languages and environments. All of these services potentially need clustering for failover and resilience, turning your single monolithic system into, say, 20 services consisting of 40-60 processes after we've added resilience. Throw in load balancers and messaging layers for plumbing between the services and the estate starts to become pretty large when compared to that single monolithic application that delivered the equivalent business functionality! Microservices - Not A Free Lunch! Now let's shift gears and peek at what's going on over in network land. You might recall we recently discussed network service virtualization. If not, here's a quick summary from Nick Lippis: NSV seeks to virtualize enterprise appliances, such as firewalls, load balancers, application accelerators, application delivery controllers, Intrusion Protection Systems, WAN optimizers, call managers, etc., instantiated for each application. Each instance of each NSV is created for a specific application. That is, if there are 10 applications that require network services, then each application will be configured with its own instantiation of that service. That is, 10 applications, then 10 NSV firewalls. In short, NSV seeks to virtualize network services by creating an instance of the network service for each application versus virtualizing a network service once for all applications. NSV hopes to present significant capex and opex relief from hardware appliances, as well as an efficient way of applying network services to applications without chaining or tagging packets and rapid automated, on-demand application deployment. Lippis Report 217: It’s Network Service Virtualization in the Enterprise rather than Network Function Virtualization Reading both, one might assume some level of collusion between the two but that's unlikely to be the case. The divide between application architects and networky groups is well established; they really don't play well together. And yet both these trends recognize the need to meet in the middle, in the L4-7 service layer, to provide for scalability and other "plumbing" services. From a scalability perspective, this is very much a verticle partitioning-based scalability pattern, where load is spread across distinct functional boundaries of a problem space, each handled by different processing units. Those functional boundaries in today's architectures are embodied by microservice definitions. One service is responsible for a discrete function, as the point of microservices is, to a large extent, to decompose monolithic applications into individual, domain (functional) specific services. Overall, this means services can be scaled individually on-demand, which is far more efficient than scaling a monolithic application. But it does introduce complexity, as there are necessarily more moving parts, and it does tend to complicate monitoring and force the need for more application-centric monitoring. A Symbiotic Relationship The application architect recognizes the need and, to some extent, laments the complexity it will introduce. Network service virtualization, on the other side, offers to fulfill the need and recognizes the need for efficiency and, ultimately, simplification in providing them in a "rapid automated, on-demand" fashion. These issues - the plumbing and the monitoring - fall squarely into the realm of issues that can be resolved by applying devops to operations. Automated provisioning, treating infrastructure as code, and enabling a more holistic view of "applications" are all enabling capabilities of what devops aims to achieve. For one of the first times I can remember, the operational burden imposed by technological shifts in application architecture is nearly simultaneously being addressed by the technological shifts in the network. In fact, one could argue that the shifts occurring in the network toward network service virtualization are actually enabling the shift in application architecture. Being able to rapidly provision, manage and monitor the L4-7 services necessary to deliver microservices increases the ability to take advantage of the architecture. Like the question of the chicken and the egg, it really doesn't matter which came first. What matters is that they're complementary and both driving toward the same goal: accelerated application deployment and delivery of an exceptional end user experience.Service Fabrics Enable Network Service Virtualization
#SDN #Devops #Cloud You gots to have some management .... Nick Lippis, who writes the eponymously named Lippis Report, had a fascinating report on the differences between enterprise and service provider environments with respect to network <something> virtualization. He observes, through a survey of the ONUG (Open Networking User Group) membership, that what the enterprise needs is Network Service Virtualization (NSV), which he and ONUG define as the virtualization of "enterprise appliances, such as firewalls, load balancers, application accelerators, application delivery controllers, Intrusion Protection Systems, WAN optimizers, call managers, etc., instantiated for each application." (Lippis Report 217: It’s Network Service Virtualization in the Enterprise rather than Network Function Virtualization ) This model, which results in a per-application service instance (e.g. "if there are 10 applications that require network services, then each application will be configured with its own instantiation of that service. That is, 10 applications, then 10 NSV firewalls."), is markedly different from the service provider model, network function virtualization (NFV), which instantiates instances based on service needs. For example, a video optimization service may be offered to either application providers or subscribers. Its provisioning and scalability model is based on demand for that service and is not provisioned per-application being optimized. According to Lippis, "NSV hopes to present significant capex and opex relief from hardware appliances, as well as an efficient way of applying network services to applications without chaining or tagging packets and rapid automated, on-demand application deployment." This is a goal that's shared by many emerging technologies like SDN and cloud computing. Service Fabrics Enable NSV A service fabric enables network service virtualization by decoupling the service platform from the underlying hardware. This is accomplished via virtualization techniques and, when associated with COTS hardware generally means an industry recognized hypervisor. The use of virtualization implies rapid provisioning and the ability to leverage commoditized hardware. This process can be automated and integrated with other systems, enabling capabilities such as auto-scaling and high availability. A service fabric goes beyond the cost and time savings realized by service virtualization by embracing programmability at the service instantiation layers. The potential risk of a NSV approach without an accompanying automation and orchestration strategy is service sprawl and its negation of cost and time savings by the need to individually configure by hand each service provisioned. If an application is going to have 10 times the services, it's going to have 10 times the configuration needed. The advantage service providers have is that its services are not driven by the application, but rather by the service definition. In the enterprise, a per-application service implies per-service configuration, tailored to the application's unique needs and requirements. That could complexify the environment. That's not desirable when one of the goals is to reduce costs, because complexity has the opposite effect. The inclusion of flexible, programmatic control and application service planes can mitigate this potential pitfall. A unified framework with appropriate templates, scripting and APIs along with a strong portal-based management system can result in continued operational savings through automation and orchestration. Such a framework also lays the foundation for IT as a Service (or Software Defined Data Center (SDDC) if you prefer), with the goal of enabling application and business stakeholders the ability to self-service applications through simple, automated provisioning and management portals. Network Service Virtualization would certainly be a step in the right direction for organizations seeking goals of either SDDC or cloud computing. The abstraction of the resource layer from the service platform and, subsequently, the automation and orchestration of services can create a rapid, cost-effective yet application-driven service infrastructure, ensuring that every application can take advantage of performance, security and reliability services that live at layers 4-7.
