Twitter served me this ad:
Is a transition to microservices right for your organization? Learn the benefits and challenges.— Kong (@thekonginc) May 24, 2019
I don’t have anything against Kong, I have never used their product myself and I hear it’s pretty good. This question though, rubbed me a little:
Is a transition to microservices right for your organization?
I wrote on when not to use microservices almost a year ago. It seemed only fair to follow up with the opposite question: when to use microservices?.
Microservices architecture is a tool
I have frequently seen microservices being used for the wrong reasons. Amongst these: decoupling things, releasing faster, increasing code quality, enhancing the code review process, containerizing the app, modernizing it. The most common reason though, that people rarely admit but almost always transpires, is that everyone else is doing it, and it seems nice. This is microservice envy.
Microservices are a tool in the architect’s toolbox. Tools have an appropriate use. Choosing the tool is driven by the task at hand, not the attractiveness of the tool.
You would not ask whether you should replace your ¾ hex-key by a torx screwdriver. This would be a silly question. The question you would ask is “do I have to screw ¾ hex-screws, or torx-screws”, and use the natural tool for the natural screw.
So why asking whether to transition to microservices then? And what is the right question?
Drive the decision with the organizational layout
Consider first and foremost Conway’s law: to be natural, the architecture has to match the organization.
So the right question is: what architecture best fits my organization and product domain? Is it microservices?
What if the organization is too small to be split into smaller teams? Microservices are probably not a great choice. Rather favor a monolithic approach with clearly decoupled layers (like the onion architecture) to keep microservices as an option for the future.
What if the organization is not organized like this, but there are plans to transform it into value-stream teams, such as “shopping”, “order management”, “fulfilment”? Then yes, transitioning to microservices as part of the re-organization is probably right. But the re-organization should not be driven by microservices envy. It should be driven by the fact that value-stream oriented teams can set their own path into maximizing value-creation. It should happen because the application domain is large enough and there are clearly defined value-streams. It should be preceded by some mapping of the domain, like DDD or event-modeling.
Then if this is the logical evolution for the team, microservices are the logical technical tool for them.
Driving a re-organization with microservices?
Discussing this topic with one of my brilliant colleagues, their first objection was that there’s a school of thought that adoption of a DevOps culture can be forced in by adoption of DevOps practices. Couldn’t the same be true from microservices?
I doubt it, but this is my opinion. There are several differences between those two cases:
- DevOps practices are organizational and additional. They include things like source-control organization, continuous delivery, review processes, testing, monitoring, etc. If the transformation of teams to DevOps “fails”, then reverting to the old way is “simply” getting rid of the changes. Microservices are a layout of the application. They replace how it is built. If the microservice implementation fails, the process yields the horrors I mentioned before.
- Even badly implemented DevOps practices are better than “the old way”1. Badly implemented microservices can be orders of magnitude worse than whatever is currently in place.
To summarize my opinion: “wanting” micro-services is a sign of microservice envy. Microservices adoption is a logical consequence of transitioning the organization to teams aligned on value-stream.
Any other motivation should trigger very careful consideration of the implications before going down that road.
I’m sure I can be proven very, very wrong there. ↩