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.
