From a service-oriented architecture (SOA) to a microservices one.

It’s been five years since software developer Martin Fowler described the concept of a microservices architecture (MSA), which in theory goes further than a service-oriented architecture (SOA). In this approach, the design of software applications is broken down from monolithic structures to “suites of independently deployable services”, as Fowler has described it, or small groups of services that each execute their own processes and are able to communicate. Because that’s also the premise of a service-oriented architecture – a distributed architecture that breaks down the project into different services – it’s legitimate to ask if there are any relevant differences between the two. Is a microservices architecture simply the next step of a service-oriented architecture?

Yes, and no. To understand both the similarities and differences at stake here, it’s worth it to look back at why SOAs were introduced in 1998. At the time, the idea was to solve problems arising from object-oriented programming, which prevented communication between applications. The SOA style of organizing software couples services loosely and has provided a number of great benefits in middleware development. Among the advantages of this architecture is the flexibility with which companies are able to manage their IT infrastructure, the way it simplifies the transition to cloud-based solutions, and the fast delivery of new implementations.

SOA experts will also tell you that the architecture is simple to maintain, can be scaled at will with immediate availability, increases the middleware experts’ productivity, makes applications more reliable, and overall means very high-quality software implementations.

That’s why it has steadily increased in popularity. Even though a lot of project managers resisted the approach at first, the advantages of adopting SOAs became inescapable. It continues to grow and drive the market, according to TechNavio’s latest report on the global system infrastructure market. The report shows the segment’s revenue will grow at an average annual rate of 5.57% till 2021, and the “increasing shift toward service-oriented architectures” is mentioned as a key element of that growth.

All of the previously mentioned key characteristics are transposable from SOA to microservices and the two architectures are not necessarily competing, but they differ in a number of ways.

The first is the fact that an SOA defines 4 service types: Functional, Enterprise, Application, and Infrastructure. A microservices architecture divides simply between Functional services and Infrastructure services. SOA looks to share as much as possible, MSA does the opposite; the first goes for multi-threaded and heavily resourced, the second goes for single-threaded. In SOA services are coarse-grained, in microservices, they are fine grained.

If you envision a graphic display of both architectures, an SOA would have the database at the bottom, a couple of services on top of it and the Enterprise Svc Bus linking the services to the user interface. With an MSA, you’d have multiple databases at the bottom, multiple microservices on top of them, and independent connections (using language-agnostic APIs) to the user interface.

Speed, agility, lower costs and little impact in the legacy infrastructure are some of the most important characteristics of a microservices architecture, which further distinguishes it from SOA. It allows services to evolve independently, works with different technologies and frameworks and makes testing and debugging much easier.

It’s easy to understand that moving from a monolithic system to an SOA or microservices architecture would have enormous implications (and pitfalls). But what about between SOA and MSA? Specialists warn that there is a risk of going too far on the tech and language diversity and maintaining such diversity might become a headache. There is also the danger of losing track of what the standard quality level is, due to the inherent independence of deployment and versioning. And that goes to the overall scalability of the enterprise platform as a whole, too.

While it’s hard to say which one is best, it’s clear microservices architectures have gained momentum, and not only because it’s a fad or because SOAs have failed in the past. It’s the architecture used by Netflix and Spotify, two giants with massive requirements and resources. It all comes down to what the goals are and what’s already in place. Success doesn’t come from scratch and no architecture is deployed in a vacuum.

However, this is not a case of either or. There’s no inevitable evolution from SOA to a microservices architecture. Companies who have been successful with a SOA implementation don’t have to choose between what they’ve been doing and the new way of thinking their software design. They’re not mutually exclusive and they’re not competing against each other. One doesn’t even replace the other, contrary to what you might’ve heard. A much more valid approach is looking at the situation at hand and assessing what has worked and what hasn’t. Maybe, just maybe, a blended approach will be the winner – for everybody.