Are microservices just “SOA done properly”?
There’s nothing really new about many of the ideas that underpin microservices. After all, componentised services, strong agile teams, continuous delivery and decentralised governance have all been around in some form or another for some time.
The term "microservice" can feel like an agile re-branding of service orientated architecture (SOA). Many of the patterns and approaches associated with microservices are regular features of SOA for years, e.g. composing applications via autonomous services, organising around business capabilities and using an event-based fabric to manage service collaboration.
This explains some of the more sceptical responses to microservices, i.e.
"Microservices is SOA, for those who know what SOA is." (Steve Jones)
"It is easier to use a new name (Microservices) rather than say that this is what SOA actually meant." (@arnonrgo)
"Microservices are just SOA done properly." (@randyshoup)
"SOA for hipsters." (Brent Smithurst)Advocates of microservices often use a direct comparison with monolithic systems to illustrate the benefits. This is a false dichotomy as there are many ways of distributing a system to provide greater resilience, easier scaling and flexibility of implementation.
If microservices describe anything new, then it’s a form of highly decentralised SOA with a special emphasis on agile and devops. It’s this difference in style and intent that marks microservices out in several important ways.
Decentralised design and governance
Microservices are heavily decentralised compared with more "traditional" SOA in terms of technology, data and process.
There is no enterprise service bus lurking in the middle of things to manage collaboration and become a well for stray business logic. Service communication is facilitated through a "dumb pipe" such as a simple RPC-style protocol or lightweight messaging fabric.
The service becomes king as data ownership is completely devolved down to each implementation. Techniques such as tolerant readers and consumer-driven contracts allow service contracts to be evolved separately without the need for a centralised governance operation.
This technical decentralisation is reinforced by also an emphasis on decentralised governance. You standardise on the integration but not on the implementation. There is no over-arching framework that asserts the same technologies and patterns across every service. Teams can select technologies and optimise according to specific needs.
Focus on agile and devops
A key enabler of this decentralised service development is strong agile teams who fully own a service for its entire lifetime. This involves the Amazon-inspired “you build it, you run it” approach where a development team takes full operational responsibility for a service in production.
The idea is that by giving a team responsibility for managing services in production the overall quality will be improved as they will have day-to-day exposure to the way that customers use their services. There’s nothing like getting a call at 3am to make you more aware of the need for quality.
This full ownership of services creates a significant operations burden that can be mitigated through infrastructure automation. Devops skills need to be a standard part of a developer’s weaponry as continuous delivery techniques become embedded into teams.
Ultimately, microservices require more experienced developers who embrace the empowerment afforded by decentralised governance. Some developers never look back once they are handed full ownership of their services, but less certain developers who have been institutionalised by years of governance frameworks will find it much more difficult to adapt.
Conway’s law in reverse
Microservice development cannot be considered in isolation to the composition and organisation of development teams. Teams have to accept a greater burden of ownership and acquire a broader range of operational skills. The organisation has to accept strong, self-organising teams that take complete ownership of service implementations.
The implication is that team organisation needs to be matured along agile and devops lines. This can give rise to "Conway’s law in reverse" where the organisation of development is evolved to meet the needs of a chosen architecture.
This is not necessarily a bad thing, though it makes a move to microservices so much more than changing the form of service design. Agile adoption can mean a far-reaching transformation that affects every aspect of a business. Unless you are already a fair distance down this road then a microservice architecture may be a little ambitious.