Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News SOA versus Microservices?

SOA versus Microservices?

This item in japanese

Over the last year or so we've seen a lot of articles and presentations on microservices including some on anti-patterns, various principles and how microservices relates to SOA. Recently Matt Brasier, Head of Consulting at C2B2 joined the latter category of discussion.

There is much discussion recently regarding the concept of microservices, and much discussion of how this fits in with SOA – whether it is the final nail in the coffin of SOA, or the latest cure-all panacea that will save software engineering.

Matt's article gives a basic outline of the reasons behind the drive towards microservices as well as SOA principles. The overall aim of the article is to show that these two are very similar in principle but products that are either targetting SOA or microservices do have differences which make them suitable for different use cases. In his microservices overview Matt has this to say:

Separating out components allows them to have separate lifecycles, and to scale as required, it also breaks many of the technology dependencies between components, allowing each service to be implemented in the most appropriate technology. Breaking down the larger problem into several smaller ones makes each individual problem easier to analyse, making it easier for developers to come up with the most suitable solution.

However, there are various disadvantages with microservices and whilst these may well be understood by many people working in the area, they are much less publicised and discussed:

Breaking down the problem like this increases the complexity of the overall solution, especially if different technologies or approaches are used to build different services. By pushing the integration points to be at interfaces between services, it is important that these interfaces are well defined, and have agreed service levels and other non-functional requirements defined.

Now it is true that because of the relative recency of microservices, tools that would normally assist architects and developers are in the infancy so some of these problems will probably be addressed sooner or later. However, there is one key problem with microservices for Matt, and that's data management and ownership:

When something that would previously have been a monolithic application is broken down into a number of smaller services, it often becomes the case that data that would be stored in one place in the monolithic application is stored in multiple places for the microservice applications. This presents challenges in maintaining data consistency.

Matt notes that microservices-related products tend to focus on the lifecycle of service components, encouraging developers to continue to use a range of implementation approaches for the actual service, such as docker, and protocols used to interact with them, which typically are RESTful in nature.

While RESTful services are generally best focussed on providing CRUD operations for a data model, it is often the case that the services in a microservice architecture can easily be broken down into these CRUD type services where RESTful is a good fit. For other services, it is often still appropriate to look at RESTful-like services, where HTTP is the transport protocol, but the service doesn’t necessarily stick 100% to the RESTful principles.

In terms of SOA, he immediately dives into the associations with microservices:

It is common to talk about the disadvantages of SOA these days, but when you really look into it, most of the disadvantages of SOA are the same as those of microservices, but with more concrete examples behind them. The same can be said for the advantages, because fundamentally what we are doing is the same thing – taking a big problem and breaking it down into smaller problems.

And he goes on to point out that the companies which are often held up as leaders in adopting or pushing microservices are happy to also describe their architectures as service-oriented. However, in order to accomplish what they did they've tended to ignore traditional SOA products, which in Matt's view are focussed on approaches based around the Enterprise Service Bus. However, in his opinion these SOA products get a bad reputation because people on some projects have used them to build an application rather than an enterprise-wide architecture and not because they are inherently poor at delivering on assisting the development of service-oriented architectures.

As such the features are focussed primarily on this enterprise use-case, with ways of tracking business-unit level SLAs. Most SOA products will mandate that services communicate using one, or a small number of protocols and message formats, such as HTTP, FTP, SOAP, JMS etc, and provide a library of connectors that enable this.

In fact Kai Wähner believes that the ESB is not dead and still has a role to play with microservices.

You use an ESB for what it is built for: Integration, orchestration, routing, (some kinds of) event processing / correlation / business activity monitoring. You can also build applications via (micro)services, which implement your requirements and solve your business problems. Deploy these services independently from each other with a standardised interface to a scalable runtime platform – automatically. The services are decoupled and scale linearly across commodity hardware.

It appears that many people, not just Matt, believe that SOA and microservices use the same set of principles but applied at different layers in an organisation. SOA is about orchestrating "large services", but those services could be implemented from a composition of microservices. Although of course as we reported earlier, perhaps size isn't a good way of defining a microservice:

Using only size for defining microservices is a poor measure and useless for determining whether a service has the right responsibilities, Jeppe Cramon states in a series of blog posts clarifying his view on microservices and the coupling problems he finds in synchronous two-way communication.

In fact Matt believes that microservices owe their existence to the success of SOA principles (others have found it easier to understand service-orientation through adopting microservices), concluding with:

If you are developing an application, then a microservice framework is going to be more agile and give you greater control as a developer. If what you are trying to do is orchestrate a number of business processes across your whole enterprise, then a SOA product probably provides a better set of tools.

Now back in 2014 we reported on a discussion between Cap Gemini's Steve Jones and others around how microservices aren't really new at all. As Steve said at the time:

This for me is why Microservices is just a Service Oriented Delivery approach for a well architected SOA solution.  SOA provides the contextual framework, provides most of the rules that Microservices aims to adhere to but more over gives a broader context within which Microservices fit within a complex enterprise.  Calling out WS-* for the one millionth time or 'big' ESB and talking about massively complex projects is simply a shot at a different challenge.

So Matt isn't alone in thinking that SOA and microservices are tied closely together, but these discussions are often driven by people who have a deep SOA background. Perhaps those microservices proponents who haven't been so immersed in SOA over the years, or have found SOA, or maybe specifically the tools aimed at aiding in developing with a SOA methodology, lacking have a different perspective? For instance, earlier this year Bob Rhubart quoted Eberhard Wolff, a freelance consultant and trainer and head of the technology advisory board for adesso AG, when he had this to say about SOA and microservices:

SOA is a strategic initiative to change the IT of the whole enterprise, separating it into different services, thereby allowing the enterprise to be more flexible. [...] Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths. So while the technologies are to some extent similar, SOA and microservices are really different beasts.

However, in the same article Oracle ACE Director Torsten Winterberg said that in his view "Microservices are the kind of SOA we have been talking about for the last decade". This debate about any relationship between SOA and microservices is likely to rage for a long time, perhaps similar to how REST versus SOA debates went on. In fact Kevin Pool, CTO for TIBCO in Asia, called it The Great Debate:

What’s different about Microservices? In Microservices, each operation (or method) is developed separately. The single customer SOA service described [earlier in his article] would be implemented separately as dozens of separate Microservices. No formal interface is defined, or perhaps a very flat and simple interface is defined. No central data model is defined with complex schema hierarchies and structures. Well, perhaps a common data dictionary may be defined, but that is not programmatically enforced on each Microservice; each Microservice is free to independently incorporate changes only when needed. Each Microservice can be independently deployed, stopped, or restarted. In many situations there is a common platform that executes the individual Microservices.

Now Kevin took a very implementation specific view when comparing and contrasting SOA with microservices, one which centred on ESBs, SOAP and WSDL. But perhaps Coert van den Thillart summarised it best in his article from earlier this year:

How much the Microservices architectural style differs from SOA depends on who you talk to. If nothing else, MSA offers a clearer and better defined approach on setting up an architecture built around services. The key differentiator being the focus on autonomously adding value.

As well as comparing and contrasting various aspects and approaches to SOA and microservices, George Lawton believes that microservices brings agility to SOA as well as "rectifying the SOA legacy":

Microservice principles align closely with trends in Agile software development and perhaps the evolution of SOA principles, minus the heavy weight of traditional enterprise service busses.

And certainly at least one of the commenters on his article seems to agree:

I agree [with another comment] that the idea of microservices is not necessarily a new idea. I see it more as a refinement of an idea that makes better use of current technologies, such as containers and automation, to better solve a problem.

So what do you think? Are microservices and SOA related? Is this really a discussion about technological (implementation) approaches to support them both rather than architectural differences? Perhaps as Matt suggests, the real difference is with data management and ownership? Is this a debate that needs to be had at all? Or is it possible that, as George Santayana said "Those who cannot remember the past are condemned to repeat it"?

Rate this Article