Are microservices more like SOA or MVC architecture?

Monolith to microservices, a very popular concept when looking at modern development practices. But is it new? Didn't service-oriented architectures seek to do exactly the same thing? Yes and no. I will explore the details of that here, including how it compares to MVC architecture.

SOA is like microservices in the same way that a microservices architecture is like a model-view controller (MVC) software architecture. The ideas are the same: breaking applications down into smaller, more discrete and easier-to-manage components. The biggest difference, however, is the focus and timing of their respective introductions. SOA came first, then MVC architecture and, finally, microservices. It would seem that if their objectives are the same the timing would not matter, but it does.

SOA is purely a software term. It seeks to enforce a better design pattern in application development. But that is where coverage stops, because it does not affect infrastructure. The reason this matters is because applications have become so complex that they occupy the entire stack, even entire data centers (see: data center operating systems). The idea of microservices is to extend the implementation of these smaller units and isolation techniques to infrastructure as well as application design.

SOA generally applies to a single application that is comprised of several internal services. This is why I would say it's similar to MVC architecture. But there is a big difference: MVC creates a divide between application components of three types. It does not give them full autonomy; in fact, the relationships are dictated. SOA mandates autonomy and only requires that applications share a schema, making the services more portable and building new applications even easier. But the modern API largely does the same thing by building a services layer for more logic to be offloaded too. SOA was coined in a time when APIs were not where the application building process started.

SOA is a practice that the developer would execute within one or more application codes, whereas microservices even dictates team structure and IT roles: development teams will be separated by the services they build. This also can be true for SOA applications, but in SOA, the developer is required to have deeper knowledge of each service. Because microservices also can act as an infrastructure delivery mechanism, they have a greater effect on deployment and infrastructure.

Microservices is as much an infrastructure architecture as it is a software one. Actually, one could make the assumption that the code in the service is built with SOA-like principles, implying that it does not actually replace it. But with microservices the implication is that the infrastructure each service runs on is independent from each other, therefore maintaining its autonomy on the server layer as well as in code. It also implies that load balancing can happen on a service-by-service basis, giving teams more options to optimize application performance than SOA usually provides. This means that increasing capacity for a pegged service is a matter of spinning up new instances of that service independently, providing faster scaling. It also provides faster issue resolution, because it's likely in such a model that services will go down, not entire applications with it.

The microservice benefits to infrastructure also give parallel benefits to deployments. Deployments are faster because you are deploying individual services. You do not need to deploy the entire application, just the services that are updated. And this supports continuous delivery and deployment as the smaller units can all be deployed independently with less risk.

Another benefit that is rarely actualized is that when properly configured and containerized, the services can live in any cloud while still remaining a part of one cohesive application. You could have a service that handles user logins living in an Amazon data center in eastern U.S., and the same service running in an Azure data center running in Europe. The flexibility is amazing.

But there are also some serious considerations. The additional overhead microservices requires over SOA is huge. It requires stronger monitoring, better release automation and much more disciplined IT and development teams. SOA can be a practice that developers follow, whereas microservices affect the entire pipeline.

The evolution of software development has been built on one abstraction after another. The next step is to abstract infrastructure so that it gets out of the way. SOA might be a dated concept, but the spirit is very much alive. It is not likely that we will continue to use the term only because it is assumed that these types of design patterns are used by good developers.

However, SOA stops at the application, and as application complexity increases, you have to think beyond those bounds. A microservices strategy takes the idea of applications consisting of many small mutually exclusive components and expands it to infrastructure as well. In a microservices model, the coherence of functionality, schemas and back ends is what makes the application.