Published on 14 June 2016 , last updated on 1 August 2018
Everyone is talking about microservices. And many people are betting on it. At this year’s Voxxed Days Vienna over 60% of the submissions contained the word microservices. At JAX 2016 in Mainz, the word microservices was spoken out aloud on average 40 times per minute accross the entire venue. It’s hard to go one day on Twitter without seeing microservices in the stream.
In this post I’ll first try to answer the question of why there is a need for microservices (in some settings) and then I’d like to talk a bit about what I think is a neglected issue in all the hype surrounding the topic these days: the feasability of organizational adoption of microservices. It is one thing to have the tools to microservice and another one entirely to be able to get an organization to think and act in terms compatible with the vision promised by the microservice architecture.
Why microservices? There are several reasons, but if I was to pick only one of them to to answer the question, it would be velocity at scale. Scale in this context means human scale. Thanks to microservices, a large amount of people can work on the same system without creating “islands”.
If you haven’t been working in an enterprise setting then it might not be obvious why this makes any sense. Picture this: for most of the large system landscapes out there, cutting a release is a process that takes months. Releases are things that happen a few times a year, with code freezes before the release. If a new small feature needs to go in fast and all the right strings are being pulled, then it’s disguised as a hotfix. And then there’s this small startup somewhere in Palo Alto / Berlin / Amsterdam / Helsinki that seems to come out of nowhere and manages to offer a product that can compete with one part of your business and churns out new features so fast it makes your head spin. And it’s not like business people in your organization have not thought of those features before. They probably have already thought of those nice features 5 years ago, but “IT wasn’t able to deliver”. Because you’re stuck with your giant cobweb of a system landscape. Only instead of being a spider that reaps the benefits of catching everything with the cobweb, you’re like a spider that can’t get out of the cobweb it built (I don’t think that this happens too often in nature, but who knows).
Even if you really really wanted to, you couldn’t operate at the speed of this startup. Not with 200+ people working on that giant and old cobweb at the same time, trying to somehow get some work done despite all of the meetings, emails and phone calls.
The most important principle of microservices is that they are entirely autonomous in all aspects. This autonomy ranges from the technology in which they are implemented to the database they are using. Microservices do not share databases, each service has its own database. This sounds silly at first but when you take a step back it starts to make sense: some microservices may not need a database, some microservices may need Oracle 11g and some other microservices may need a document-oriented database. Updating Oracle 11g to a newer version only affects that one microservice. If you say that you have a microservice architecture but some services share the same database, then you don’t have a microservice architecture, end of the story.
The only shared element is the API. Microservices expose their API and vow to provide the functionality exposed by that API. Changes in the API are reflected through a new microservice (with a similar name), dependent microservices migrating to it as they see fit (check out Petter Måhlén’s excellent talk at JFokus on this topic).
And that’s how microservices enable velocity for large organizations. By providing autonomy to each microservice and to the people responsible for that microservice, all the overhead of communication, synchronization, scheduling, release planning, etc. is thrown right out of the window (well, maybe not all of it entirely, but a big part nonetheless).
There are other benefits to a microservices architecture, such as:
- each microservice can be scaled independently, vertically and/or horizontally, depending on its needs. Not all microservices need to be deployed on 10 servers to offer the highest possible SLA.
- reduced risk / errors are inexpensive: if the new version of one microservice has a problem, it can easily be rolled back to its previous version
- it gets much easier to keep track and to retire functionality that is no longer needed
A word of caution: when not to microservice
DHH wrote an excellent piece appropriately called The Majestic Monolith on the topic of microservices vs. monoliths. The marketing campaigns around microservices have been painting monoliths as those bad, bad things that need to go away at all costs but this is not always true:
- if you have a fast pace of deployment (fast enough for you), or even better, continuous deployment in place, you’re already there. You already have all the velocity.
- if you have a small team, microservices are likely an overkill. You have to be big enough to need microservices. If you have a small team and you can’t get enough velocity, then you have another set of problems than the ones microservices are meant to address and using microservices won’t likely fix those.
Microservices are an organizational problem
The stories shared at conferences are tales of great success. Names such as Netflix, Gilt and Spotify are often cited as organizations that have successfuly adopted microservices. Gilt’s story is particularly interesting as it shows that microservices are something that “emerges” rather than something that is designed upfront.
This property of “emergence” is the one that, in my opinion, is going to be the hardest nut to crack when it comes to adopting microservices in enterprise settings. When I talk about enteprise settings, I’m talking about companies that are much older than Netflix, Gilt, Spotify and friends. These organizations need to answer roughly the following question:
How do we turn our 6 Enterprise System Buses, our 4 Data Stores, our 12684221 lines of Java code and 3126735 lines of PL/SQL stored procedures into shiny microservices?
All of this, it goes without saying, without creating a “microservices” technology landscape in addition of what’s already there. As every vendor out there is jumping on the bandwagon to offer a “microservices” stack or solution of some kind, which are technical solutions in nature, I fear that the lack of focus on the organizational aspect is going to result in the creation of said “microservices islands”.
What I can say at this point is that in order to make this kind of adoption happen in an organization, the following ingredients are required:
- organizational Inversion of Control. Microservices are meant to be built bottom-up by small teams with autonomy, therefore there must be enough autonomy given to those teams (as opposed to top-down architecture or management decisions).
- top-management buy-in and commitment. Whilst microservices are built bottom-up, it isn’t possible to build them without decision makers understanding the benefits and committing to a change that will take years to go through and represent a significant investment before seeing any benefits. Given that more often than not the focus is on short-term goals, this is a hard sell.
- endurance. I do see microservices as a possible salvation for companies that are stuck with large legacy codebases, but adopting them is going to take a long time. Driving such a change does require many years of commitment.
I would love to hear stories of organizations that have started to embark on this journey. If you are in this situation, write me).
Liked this article? Subscribe to the mailing list to get regular updates on similar topics.