It’s time to stop making “Microservices” the goal of modernization.
For the past three years, I have been helping clients with some modernization effort. These projects are almost always associated with either “rewriting applications using microservices” or refactoring existing code (and sometimes data…) into mircoservices. Martin Fowler describes microservices architecture here. There are tons of other articles out there that have since described microservices, some written by myself.
In addition, the term microservices, like many popular technical terms, has expanded/abused by many characters to mean a bunch of other things (Apps, components, libraries, etc….). I was on a call recently, and someone told me they build client side microservices. When i probed what they meant by that, it came down to being a library being pulled into a web app, but was very insistent on that code being a “client side microservice.”
I have had some recent examples of client work:
- I was put on a project taking over another vendor’s work for a digital project (web app, moble app, etc..), with “60 different microservices.” When I looked deeply, all 60 were deployed with a single Jenkins Job, which by the very definition of a microservices, would disqualify it.
- On another project, I reviewed a design for a system that defined 6 microservices. When I looked deeper, the reason why they were 6 was unclear other than standard OO (Object Oriented) type thinking. In the end, we built and deployed 2 applications.
As i talk to more and more customers that want to refactor into mircoservices, and when i query, what they really mean is they want to:
- Deploy things faster
- Get new features out quicker
- Control scaling
So make those the goals, and solve for them. Somehow, “refactor to microservices” mantra diluted that.
I think we need stop talking so much about” microservices.” Instead we should focus in on specifics:
- I need to adopt automation at all levels. Then solve for automation. Automate testing from day one.
- I need to change the way you organize your teams and remove walls/silos. No amount of architecture can solve the job security mentality.
- Focus on drivers that lead to individual applications (Different release cycle needs, different scaling needs, parallel development, data patterns)
- Invest in modernizing operations teams. Everyone is so focused on modern developers, because it is easier to do that.
- Containerizing existing middleware is a good step in modernizing your operations and devops team. It maybe the only step you need.
I really liked this blog: The death of microservices by Dave Kerr, he talks a lot about the complexities around microservice projects.