Let’s just nip the conflation of these terms in the bud, shall we?
“MIcro” is big these days. Both microservices and microsegmentation are having and will continue to have an impact on data center architecture, but not necessarily for the same reasons. There’s a growing trend in which folks – particularly those with a network background – conflate the two and use them to mean the same thing.
They are not.
One is about the application. The other, the network. There is a relationship, but it’s a voluntary one. They are two very different things and we need to straighten out the misconceptions that are rapidly becoming common.
Microservices
Microservices are the resulting set of services (mini applications, if you will) that arise from the process of decomposing an application into smaller pieces. If you take a monolithic application and segment it into many pieces, you end up with microservices. It is an application architecture; an approach to designing applications.
This architectural approach has a significant impact on the network architecture, as it forces broader distribution of application-affine services like load balancing, caching and acceleration to be located closer to the individual service. Microservices as an approach is a forcing factor in the bifurcation of the network as it separates application-affine services from corporate-affine services.
Microservice architectures are beneficial in that they are highly efficient; it separates functional or object domains and thus lends itself well to a more targeted and efficient scalability model. It is particularly useful when designing APIs, as in addition to the scalability benefits it also localizes capabilities and enables isolated upgrades and new features without necessarily disrupting other services (and the teams developing other services). This lends itself well to agile methodologies while enabling a greater focus on API development as it relates to other services as well as the applications that will use the service.
Microsegmentation
Microsegmentation is about the network; to be precise, at the moment it’s about the security functions in the network and where they reside. It’s a network architecture that, like microservices, breaks up a monolithic approach to something (in this case security) and distributes it into multiple services. You could say that microsegmentation is micro-security-services, in that it decomposes a security policy into multiple, focused security policies and distributes them in an resource-affine manner. That is, security policies peculiar to an application are physically located closer to that application, rather than at the edge of the network as part of a grandiose, corporate policy.
This approach, while initially focusing on security, can be applied to other services as well. As noted above, a result of a microservice approach to applications the network naturally bifurcates and application-affine services (like security) move closer to the application. Which is kind of what microsegmentation is all about; smaller, distributed “segments” of security (and other application-affine services like load balancing and caching) logically deployed close to the application.
Thus, if there is any relationship between the two approaches, it is that microservices tend to create an environment in which microsegmentation occurs.
There are other reasons for microsegmentation, including the reality that the scale required at the edge to support every application-specific service is simply pushing IT to the edge of its wits (pun only somewhat intended). The other driving factor (or maybe it’s a benefit?) is that of service isolation, which provides for fewer disruptions in the event of changes occurring in a single service. For example, a change to the core firewall is considered potentially highly disruptive because if it goes wrong, every thing breaks. Changing the firewall rules on a localized, isolated service responsible for serving two or three applications, has a much lower rate of disruption should something go wrong.
This is highly desirable in a complex environment in which stability is as important as agility.
COHABITATION
In a nutshell, microservices are to applications what microsegmentation is to network services. Both are about decomposing a monolithic architecture into its core components and distributing them topologically in a way that enables more scalable, secure and isolated domains of control.
The thing to remember is that just because dev has decided to leverage microservices does not in turn mean that the network somehow magically becomes microsegmented or that if microsegmentation is used to optimize the network service architecture that suddenly apps become microservices. Microsegmentation can be used to logically isolate monolithic applications as easily as it can microservices.
Either approach can be used independently of one another, although best practices in networking seem to indicate that if dev decides to go with microservices, microsegmentation is not going to be far behind. But the use of microsegmentation in the network does not mean dev is going to go all in with microservices.