Microservices: Storm in a teacup, or teacups in a storm?
Somehow, the buzz surrounding microservices has us believing that every single employee and enterprise must break up their monolith empires and follow the microservices trend. But it’s not everyone’s cup of tea, says JAX London speaker Holly Cummins.
Folks, we have reached a new phase on the Microservices Hype Cycle. Discussion of the microservices hype has overtaken discussion of the actual microservices technology. We’re all talking about microservices, and we’re all talking about how we’re all talking about microservices. This article is, of course, contributing to that cycle. Shall we call it the checkpoint of chatter?
Let’s step back. I think we’re all now agreed on some basic principles. Distributing congealed tea across lots of teacups doesn’t make it any more drinkable; microservices are not a substitute for getting your codebase in order. Microservices aren’t the right fit for everyone. On the other hand, microservices do encourage many good engineering practices, such as clean interfaces, loose coupling, and high cohesion. They also encourage practices that are a bit newer, but seem pretty sensible, such as scalability through statelessness and development quality through accountability (“you write it, you make it work in the field”).
Many of these architectural practices are just good software engineering. You’ll get a benefit from adopting them – but if you haven’t already adopted them, will you be able to do that along with a shift to microservices? A big part of the microservices debate now centres on the best way to transition to microservices. Should it be a big bang, or a gradual peeling of services off the edge, or are microservices something which should be reserved for greenfield projects?
SEE ALSO: Microservices – why would I even care?
I’m part of the team that writes WebSphere Liberty. As a super-lightweight application server, we’re more of an enabler of microservices than a direct consumer. However, we have experience of a similar internal transformation. We had a legacy codebase that was awesome in many ways, but it was pretty monolithic and pretty big. We needed to break it up, without breaking it. We knew we could become more modular by rebasing on OSGi services, a technology which shares many characteristics (and sometimes even a name) with microservices. OSGi services allow radical decoupling, but their dynamism can cause headaches for the unwary. What worked for us was writing a brand new kernel, and adapting our existing libraries to the new kernel one by one.
Thinking about failure is critical. Imagine a little microservice teacup, bobbing along in those rough network waters, with occasional hardware lightning strikes. Not only is failure a possibility, it’s practically a certainty. Tolerance for failure needs to be built in at every level, and it needs to be exercised at every stage of testing. Don’t get too attached to any particular service instance. This was one of our biggest lessons along the way. We made sure our design ensured that code had the framework support to consume services in a robust way, even though they were liable to appear and disappear. Along the way, we discovered that many of our tests, and some of our code, made assumptions about the order in which things happened, or the timing of services becoming available. These assumptions were inevitably proved wrong, usually at 1 am when we were trying to get a green build.
The human implications of microservices
Although we tend to talk about the technological implications of microservices, it’s important to think about the human implications, too. Not everyone is comfortable coding to cope with services dropping in and out of existence, so you may find you end up jettisoning some people along with the monolith. Build in a period of adjustment and education, and remember to take time to develop new skills as well as new code. By the time most of our team shifted to service-oriented development, we had a beta which clearly demonstrated how well the new model worked. The coolness of where we were going was a good compensation for occasional 1am head-scratching over unexpected behaviour.
What I find exciting about the microservices discussion is how it’s making us think about architectural patterns, team organisation, fault tolerance, and the best way to write code and deliver services. That’s got to be a good thing, even if microservices themselves don’t end up being everyone’s cup of tea.