BT

Your opinion matters! Please fill in the InfoQ Survey!

About the SOA Heritage Impact on Microservices

| by Jan Stenberg Follow 10 Followers on Nov 15, 2017. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

The heritage from SOA impacts the approach and design of a microservices architecture, how we select technology, and also the organisational aspects, Tareq Abedrabbo claimed at the recent Microservices Conference µCon London 2017. One example from his experience is that many organisations still have a separation between enterprise architects and developers where developers implement specifications created by architects.

Abedrabbo, CTO at OpenCredo, has personal experiences working both with very large organisations and with smaller ones. Many of these organisations have some form of SOA heritage which affects their move to microservices; in his talk he discussed some of the more interesting aspects when comparing SOA with microservices. He emphasized though that he is not blaming SOA for all the problems he sees.

Reuse vs. Managing change. The reason reuse was such a big deal for SOA, is for Abedrabbo the lack of maturity in the tooling to manage change. Once a service was deployed, often manually, you didn’t want to change it because of the cost involved. The main reason for using microservices on the other hand is managing change, which is not a problem since the cost of change is now much smaller.

Integration vs. Composition. SOA is about integration which means a client can send anything it likes, including a massive XML payload, to a service, and then it's up to the service to interpret and make sense of the data it receives. In the microservices world the responsibility is reversed; here it’s about composing services which means it’s the responsibility of the caller to call a service in a sensible way. Abedrabbo summaries this by claiming that integration drives complexity and composition simplicity.

Technical vs. Functional reuse. In SOA it’s all about technical reuse; we want to use a service as much as possible, even though the resistance against change in a service makes it harder. In the microservices world reuse is encouraged by smaller services that each target one specific business function.

Static vs. Dynamic. SOA has a very static view of the world where everything has to be done in one point in the system, which means that a SOAP call has to carry not only the business message, but at the same time also express concerns like security and transactions. Microservices are by nature more dynamic and we accept the fact that different parts will have different responsibilities. 

One anti-pattern Abedrabbo often has experienced when developers with a SOA background builds microservices is the distributed monolith where services within a natural boundary are artificially separated. This is common when you start with a monolith and decouple things without respect for the boundaries that exists. Integrating with legacy systems but with too much focus on the underlying mechanics of decoupling, and forgetting about challenges like delivery guarantees, idempotency and so on, are also something he often encounters. As a result, this often creates a system that does not have the benefits of microservices, but does have the complexity.

To work around the issues he has pointed out, Abedrabbo mentioned some recommendations:

  • Keep it domain-driven. Express the concerns of the domain with a microservices implementation supporting these concerns. Avoid designing reusable microservices by having a technical perspective.
  • Do not use canonical data models. They prevent a microservices system from evolving and changing easily. Instead use views of the data that are local to different parts of the system.
  • Normalise the meta data, and separate it from the rest of the data.
  • Use the right tool for the job. One example is if a microservice should have its own database. Using one database for integrating two services is an old anti-pattern, but when using a graph database it may be a good solution.

Next year’s conference is scheduled for November 5-6, 2018.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT