It is not hyperbolic to state that today’s web services deal in hyperscale realms when one considers stats such as
- The Amazon cloud can handle up to 1 million transactions per second during peak loads
- Facebook was managing 890 million daily active users on average for December 2014
- There are 500 million tweets sent per day and 80 percent of those are sent from mobile devices
Ironically, the move to hyperscale web services has been made possible by applications going micro, as in microservices as commonly defined as “small, independent processes communicating with each other using language-agnostic APIs.” The emergence of microservices based application architectures is a revolutionary departure from monolithic app development, which was purpose-built around a single service, e.g. storage management, CRM, etc. In its place now are 10 or more modular, reusable services each owning a limited and specific set of functionality in what might be best illustrated as replacing a singular black box with a set of Lego blocks.
In turn, this has led directly to key advancements in the application development process, evolving from start-to-finish programming to agile, continuous integration/continuous development (CICD). This model offers two major advantages over the waterfall development approach:
- One, decreasing software development time to align to the “speed of business” dictated by market factors and not by IT processes.
- Two, enabling specific modules of an application to achieve “autonomous elastic scale” where instances can be scaled up or down dynamically and on an as-needed basis.
The software world and its professionals are intimately familiar with these application megatrends, of course. They live it every day. However, they may be less familiar with what’s happening — or to be more precise what’s not happening — with the evolution of networking, specifically in the layer that manages server load balancing or application delivery control (ADC).
This is so because legacy ADCs were built and optimized for applications that resided in a single hardware platform and at a single location. With the advent of Microservices, the days of a cozy 1-to-1 relationship between the ADC and a monolithic application is quickly becoming a thing of the past. A useful analogy here is to equate the management of these resources with how humans treat cattle vs. pets.
Application microservices are like cattle in that while these resources are valuable, each resource can be easily replaced. Legacy ADCs are like pets in that they’re not easily replaceable and, at times, require painstaking levels of care and attention. Indeed, it is clear that the pace of innovation for these networking devices has not kept pace with the requirements of application microservices in their current forms as either hardware appliances or as self-contained VM appliances.
Though legacy ADCs may be upgraded to be microservice “aware” and even provide certain levels of integration; they are not optimized to support an application architecture that’s built on microservices written in different programming languages and distributed across many different hardware platforms, clouds, and even data center locations.
The solution requires ADCs and load balancers to evolve to take on more of the characteristics microservices possess (be more like cattle and less like pets), namely:
- Being tightly aligned with each app microservice and not with the entire monolithic app;
- Delivering a consistent set of network services in a location-agnostic way, whether the app location is on-premises in a data center or distributed across private and public clouds;
- Being hardware agnostic, whether the app is on bare metal, in VMs, or even in containers – without requiring additional configuration tools; and
- Achieving autonomous and elastic scale to support each microservice throughout its useful lifecycle.
Further, this evolution must be true and profound and not a mere incremental advancement, which has hindered the adoption of software-defined data centers among the large enterprise segments thus far.
Specifically, ADCs must achieve the concept of “application affinity” which is based on the app-world concept of “processor affinity” where resources are aligned/pinned for specific functions. There are two major benefits to this approach. First, having the ADC resource side-by-side, the microservice will improve the application response time. The application delivery follows the “destiny” of the microservice – it grows, shrinks and moves with the app itself.
Second, this tight alignment (affinity) enables ADC resources to achieve automatic lifecycle management of microservices without manual intervention, which reduces management complexity significantly.
In summary, it’s been said that best things tend to come in small packages. Such is the case with the emergence of application microservices, which has paved the way for agile, continuous application development and hyperscale web services.
It’s time for the ADC to undergo a similar evolutionary path in order to maintain its strategic value as the gateway between the network and application layers.
About the Author/ Dhritiman Dasgupta
Dhritiman Dasgupta the VP of Marketing Avi Networks.Prior to joining the Avi Networks team, Dhritiman Dasgupta (aka DD) was a Vice President at Juniper Networks where he headed up the data center, security, and SDN marketing efforts. He launched the award-winning QFabric and MetaFabric systems. Prior to Juniper, DD spent 9 years at Cisco Systems in the LAN and Data Center switching divisions heading up product management for several multi-billion dollar platforms including the Catalyst series switches. https://twitter.com/mandhriti