Microservices versus Microsegmentation

Author: Lori MacVittie

“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 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 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.

Full article: soa.sys-con.com/node/3336488

You may also like...

Leave a Reply