The Reality of Microservices: Trends vs Hype

Rewind 5 years and micro-services were the talk of the town. The developer conference circuit was awash with speakers espousing the benefits of micro-service architectures. Stories about their success in Netflix and Starbucks built the business case, while advances in scriptable infrastructure such as Docker built the technology case.

Then the cracks started to appear. Some of the teams adopting this approach reported mixed results – horror stories about complexity, difficulty in evolving the domain, refactoring and rapidly accumulating technical debt led to a general view that micro-service architectures weren’t quite as broadly applicable as we had hoped.

Conference talks shifted to Serverless, in part a reaction to the orchestration complexities of micro-services. The newly accepted wisdom was that micro-services probably shouldn’t be considered for greenfield applications, culminating in the recent removal of micro-services from the ThoughtWorks “Should Adopt” technology list.

So what’s going on with micro-services? What are the advantages and disadvantages? Should you be considering their use? At Patient Zero we now have several micro-service projects that we’ve worked on, across Node, .Net core and Ruby. Some of these we inherited the architecture, some we built ourselves. Our journey went from loving the idea of micro-services, to hating their implementation and delivery, back to understanding and appreciating how they can be used effectively. This is the first of 3 posts distilling our current thinking on micro-services.

There is one question you must answer to decide whether or not you should even consider a micro-service architecture, that is “How well do we do CICD?” Most teams are now well and truly on the dev-ops bandwagon, “we’ve had a build pipeline for years, we have automated tests, we have automated deployments – we’ve got CICD nailed!”

Try this with an existing application from the team (it doesn’t have to use micro-services):

1. Create a new tenancy/subscription/area with your cloud or hosting provider
2. Modify your CICD pipeline to use the new tenancy
3. Give a developer a blank workstation / laptop and have them clone the repo, build and successfully launch the application locally
4. Have them check in a change to a feature branch
5. Ensure the change is automatically built, tested and deployed to the new tenancy. All Infrastructure required is automatically provisioned.
6. UI Tests automatically execute and report results in the new environment
7. All infrastructure is automatically disposed at the end of the test

If you can get from 2-7 in under 30 minutes, then it’s definitely worth considering a micro-service architecture. If not, then you are probably going to find micro-services are a significant burden on development team productivity.

To be continued. Stay tuned for our second post on Micro-Services – Advantages of Micro-Service Architectures.