I want to address a misconception I’m hearing at meetups & discussions with other developers on the topic of waste with respect to microservice architectures.
The more I hear about microservices, the more I hear about overlapping efforts or lack of re-use, however this is both missing the point and untrue, and I’ll briefly discuss why in this article. This is not to say that they don’t have their tradeoffs and pitfalls – they absolutely do – but this is true with any software engineering decision, particularly when it relates to architecture.
Reuse is still possible by the use of shared libraries
Just because you are building many small services doesn’t mean you can’t share things!
When recently proposing to use microservices in an ESB-centric organisation, one of the first oppositions was this point – “But we have throttling, limiting, monitoring…[insert orthogonal features here] built into the framework, if you create your own you’ll have to write all of this again”, and so on.
This point is somewhat true, but there are at least 2 ways to address this:
1. Automation of environment build
if the (ESB) setup can be automated (Puppet, Chef, Ansible, Salt, Cloudformation… etc.) then that takes a lot of the pain away from re-building.
And this is where we hit another key realisation: you can’t do microservices without solid ‘DevOps’ practices. You simple can’t manage this many systems by hand, it doesn’t scale.
2. Split the Framework code from the Application into logical components
Those things should be in smaller, re-usable modules anyway. They are parts of a framework used by the application. Throttling, Monitoring, Logging, Security etc. are for the most part orthogonal concerns and are great candidates for splitting out from the mainline.
Value time-to-market over duplication of effort
You’ve heard it everywhere, if you are to succeed in today’s’ world you need to innovate, and to innovate you need to ‘fail fast’ – you need to reduce your time-to-market so that you can test your new product (hypothesis), measure, learn and repeat until you have a successful product. This in no small part is related to how nimble a development team is at releasing working software.
I recently attended a session on delivery with the then CTO of REA Richard Durnall (amongst others equally talented individuals) and remarking on a question on scaling an agile organisation, restructured as completely independent, cross-functional teams, a question came from the audience “At what point do the bean counters notice you have duplication across those teams? How do you continue to scale this way?” at which point the reply went something along the lines of “Whilst we care about saving money, we value time-to-market above anything else”. And this is the point.
Use of microservices architecture does not imply less reuse, and the real aim of microservices is increasing a company’s agility and time to market, whilst creating a stable future architecture.