It hasn’t gone unnoticed that Microservices are the next big thing companies are looking into. We are often asked by our clients to explain and demonstrate some of the benefits of Microservices and in some cases this has proven rather a challenge.
Why is it a challenge? Not because it is hard to prove the value of adopting Microservices, there certainly is value in this, but rather showing our clients how this architecture style could fit the organization.
“Microservices is not just an architecture style, but also an organizational structure. Adopting the one without the other is like buying new running shoes and wearing them just to watch Netflix.“
The post-SOA era
Despite all media hypes on Microservices, many organizations have only recently put the ‘Service Oriented Architecture phase’ behind them. These organizations are looking at their Enterprise Service Bus with mixed feelings. Its promises that SOA would bring loosely-coupled interfaces that could support reuse and provide shorter time to market: they didn’t really pay out. It still takes a significant amount of effort and labour to make seemingly small changes let alone develop new products. Chances are that the same old monolith that existed before the Enterprise Service Bus is still humming in the datacenter.
Why would Microservices work now?
So why did these promises not work out for these organizations? One theorem, the one proposed here, is that the organization wasn’t aligned and therefore not everybody was in on the game. More bluntly: the team that developed the services on the ESB was not the same that developed corresponding features on the monolith. And the same goes for the smaller monoliths.
This separation of ownership and responsibility is sometimes referred to as ‘Design by Committee’, and has lead to suboptimal results. Nevertheless, it was a best practice which was often formalized in an ‘Integration Competence Center’ or such.
Microservices do offer a solution to this caveat and they do so by organizing around business functionalities rather than technologies. The old Unix philosophy ‘do one thing and do it well’ certainly applies to Microservices where the aim is to build smaller and clearer bits of functionality that are functioning very well.
So, microservices should be developed by the team that has the domain knowledge and will maintain them too (‘You build it, you run it’). In case of legacy applications, this team should consist of members of, or actually be the team owning the legacy application. This is to ensure that the domain knowledge required to build the correct and understandable functionality is incorporated into the microservices. With the addition of DevOps and a CI/CD (Continuous Improvement/Continuous Deployment) toolchain the team’s set!
Microservices: An organizational structure
Microservices are often advertised as an architecture style/pattern. What is hardly ever mentioned is that the organization needs to be supportive of this style as well.
The main takeaway is that Microservices is not just an architecture style, but also an organizational structure. Adopting the one without the other is like buying new running shoes and wearing them just to watch Netflix.
For questions about this blog you are able to contact Stephan Ansems, Senior Consultant at Devoteam Netherlands (stephan.ansems@devoteam.com). If you are interested in Microservices as a solution for your business, feel free to contact Ratko Popovski, director Architecture & Implementation at Devoteam Netherlands (ratko.popovski@devoteam.com).
More about Microservices
Check out our previous blogposts and white paper:
