Smash all the monoliths – again
As Eric Knorr notes, the concept of distributed, componentized applications has been kicking around for a while – most famously demonstrated in the Service-Orientated Architecture (SOA) trend, which peaked around 2007/2008.
Yes, we know, peak-SOA was (mostly) a disaster – largely thanks to a whole hash of managerial failings, concomitant with a vendor feeding frenzy that served to deepen the misunderstanding of the concept – but the basic principles behind it remain as relevant as ever.
Perhaps that’s why, in spite of the Pavlovian twitch many devs experience when the term rears its head, microservices architectures have become such a hot topic in the past year, accelerated by the boom in continuous delivery, cloud, and DevOps services to enable such an approach.
peak-SOA was (mostly) a disaster
As Martin Fowler and James Fowler wrote this spring, whilst there’s no precise definition for microservices architectures, “there are certain common characteristics…around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”
Although microservices architectures and SOA aren’t exactly the same, both are founded on one essential design concept: code that’s housed in individual suites, as opposed to the traditional dirty great monolith found is Java, is far easier to manage, allowing you to refactor and redeploy select services as opposed to having to go in and tool then re-release the whole shebang. This is particularly useful for things like internet apps which run 24/7.
The big difference is that, unlike SOA, microservices comes without the standard dependency on ESB and centralized governance. It’s also much more of a grassroots developer led trend, as opposed to the top-down manner in which many SOA projects were implemented (or rather imposed) by managers frustrated with siloed teams spending valuable time pointlessly reduplicating threads of code.
a grassroots developer led trend
Other factors by which we can characterise microservices into a concrete framework are summarised by JavaWorld thusly:
- Componentization via services
- Organized around business capabilities
- Products not projects
- Smart endpoints and dumb pipes
- Decentralized governance
- Decentralized data management
- Infrastructure automation
- Design for failure
- Evolutionary design
Fundamentally, SOA wasn’t a terrible idea. Netflix, aka “the largest pure cloud service”, beautifully utilises the “loose coupling” inherent within SOA to ensure minimal dependency induced downtime, and let’s not forget former bookshop nemesis Amazon, which, within a few short years, under the auspices of a mandate pushing for structural reform by Jeff Bezos, evolved into the prime billion dollar web services powerhouse we know today.
It must be noted that asynchronous architectures aren’t without their own inherent challenges. Compared to monoliths, you’ve got a good deal more overhead ops to think about, creating potentially “tens of separate services to build, test, deploy and run, potentially in polyglot languages and environment.” You’ll also need a team with a high caliber of DevOps skills to run the whole production, and both manual and automatic testing is a good deal more complicated when you’re trying to recreate all the environments in a consistent way.
Microservices architectures aren’t radically different to SOA. Where they overreach SOA is in their implementation. It’s largely devs, the people with an implicit understanding of the tech operating in this system, who are employing them, using native internet solutions in place of the big bloated vendor locked tech that helped to sink SOA. In fact, perhaps the best definition for the approach would be SOA with common sense – and that’s a welcome addition to any operation.
Image by Joe Miserendino