How Microservices are breaking (up) the Network

It's not just apps that are decomposing, it's the network, too.

The network is bifurcating. On the one side is rock solid reliability founded on the premise of permanence and infrequent change. On the other is flexibility borne of transience, immutability and rapid change.

There are, by virtue of this change in application architecture from the monolithic to the microservice model, changes necessary in the network. Specifically to the means by which the network delivers the application services upon which apps rely to be themselves delivered in a way that meets the performance, security and availability expectations of business and consumers alike.

Jeff Sussna explains in his post, "Microservices, have you met ...DevOps?" 

Numerous commentators have remarked that microservices trade code complexity for operational complexity. Gary Oliffe referred to it as “services with the guts on the outside”. It is true that microservices potentially confront operations with an explosion of moving parts and interdependencies. The key to keeping ops from being buried under this new-found complexity is understanding that microservices represent a new organizational model as much as a new architectural model. The organizational transformation needed to make microservices manageable can’t be restricted to development; instead, it needs to happen at the level of DevOps.

Microservices work by reducing the scope of concern. Developers have to worry about fewer lines of code, fewer features, and fewer interfaces. They can deliver functional value more quickly and often, with less fear of breaking things, and rely on higher-order emergent processes to incorporate their work into a coherent global system.

This new architectural model extends into the network and continues to draw deeper the line between the core, shared network and the application network that began with the explosion of virtualization.

This new per-app infrastructure model relies heavily on software and virtual solutions; no hardware here can keep up with the rate of change. Solutions which are not API-enabled and easily orchestrated are to be eschewed in favor of those that do. Immutable or disposable, this per-app service infrastructure must support hundreds or thousands of applications and do so at a cost that won't break the budget (or the bank).

Services which have a greater natural affinity to the application - load balancing, application security, performance - are migrating closer to the app not only in topology but in form factor, with virtual machines and software preferred. This is partially due to the affinity that model shares with cloud, and begins to paint a better picture of what a truly hybrid architecture inclusive of cloud may look like in the future. Virtual and software-based per-app service infrastructure fits more naturally in a cloud than does its hardware-tethered counterparts, and provides the ability to more specifically tune and tweak services to the application to ensure the highest levels of availability, security and performance.

This is, no doubt, why we see such a significant emphasis on programmability of application services as it relates to those who view DevOps as strategic.  Every manual change required to a service configuration is pure overhead that can be eliminated; an obstacle removed in the path to speedier deployment. The ability to programmatically modify such services inclusive of treating that infrastructure as code through templates and configuration artifact versioning is imperative to maintaining stability of the entire infrastructure in the face of frequent change.

DevOps responsibility will no doubt expand to include the infrastructure delivering per-app services. A DZone report backs this up, showing increasing expansion and desire to expand beyond the app. What this means is more careful attention paid to that infrastructure, especially in terms of how supportive it is of integration with other toolsets, capabilities to fit within a model that treats infrastructure as code (templates and APIs), as well as its licensing model, which must support an economy of scale that matches well with cloud and similarly hyper-scaled environments, such as those implementing microservice-based architectures.