Before I get too deep into my thoughts on this topic, let me reference some definitions of what microservices are from some of the top players in the microservice space.
"A microservices architecture is a type of application architecture where the application is developed as a collection of services. It provides the framework to develop, deploy, and maintain microservices architecture diagrams and services independently." - Google
"Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams." - Amazon
Now that I've laid out some definitions, I can explain what I see all too often. I talk to software engineers or a manager of a team of software engineers and they claim to be using microservices. They have services that they have containerized and deploy to some flavor of Kubernetes. While this looks like they're using microservices from a tech stack perspective, I find that they are usually missing something more subtle that is robbing them of being able to realize the benefits of a true microservice architecture.
What these teams are missing is service independence. All too often what you find when you look closer is a suite of containerized services that are tightly coupled with each other and require lock step deployment. Lock step deployment here refers to the inability to support multiple major versions of a service running simultaneously at the same time. If you can't deploy multiple major versions of a service at the same time then when inevitably you need to make an API breaking change, all consuming services need to update at the same time. I would argue that this trait means that the services are not independent as specified in the definitions that I referenced.
This is what I would define as a distributed monolith. Don't get me wrong, distributed monoliths can have some of the same valuable traits such as being able to horizontally scale your applications to match with the load. What they fail to provide though is the ability to make changes as fast as the owning team/developer is able to. Changes are only able to be made at the speed of the slowest consumer. This issue can be exacerbated greatly if various team priorities don't line up or conforming to the breaking changes proves to be difficult for that team or developer to accommodate in a reasonable time frame.
Top comments (0)