Microservices may be dangerous for your team
Last week, Zend by Perforce wrote a blog post about when and how to migrate from a monolithic application to a microservices architecture. For those that haven’t read the post, the TL;DR is that as your application grows, it makes sense to migrate to microservices in order to streamline development.
I find this advice to be dangerous, for a number of reasons.
Microservices as architecture
Microservices were never meant as a purely architectural pattern; rather, they were meant as a team organization structure. While the pattern is generally considered architectural, the problem that the developers were trying to solve was velocity and code reliability. This led to the development of the microservices architecture, which was expanded upon over the years.
The problem with microservices as architecture is that it tends to lead to microservices for microservices’ sake. This means that developers often resort to microservices, even if they have very small teams that can easily collaborate. Microservices make sense in a large organization like it’s origin, Hewlett Packard, but make little to no sense in teams where collaboration is between three to seven developers.
Monolithic Microservices
Astute readers might wonder why I am against microservices, since I have a talk called In Defense Of “Monolithic Microservices”. The truth is, I am. not against microservices at all. I’m against their overuse.
As I mentioned, microservices make sense in the context of large teams. Where the paradigm breaks down is in small ones: teams that have only a few developers end up maintaining multiple code bases that do discrete things, and the deployment and development load overwhelms them quickly.
Instead, I recommend (for small teams) that developers create discrete boundaries between services. For example, an API might do a number of different things but is discretely separate from a frontend which the end user views. API calls are made to populate that front end. In this way, a skilled frontend developer can embrace a contract established by backend developers, and design the frontend any way she pleases, even without new API calls being implemented or backend changes being made. Meanwhile, backend engineers are free to internally refactor or start adding new features without risk of breaking the existing contract.
Because these services do more than a single discrete thing, they’re more akin to monoliths than microservices. Yet, they’re separated by boundary concerns, which results in several services being created.
Final Thoughts
Microservices are not an upgrade as your application grows; they’re a tool to use depending on your circumstances. If your team is huge and globally distributed, true microservices architectures likely make sense. At the same time, if your team is small, or colocated, or closely collaborative, true microservices are probably overkill. The Zend article doesn’t make a distinction between these concepts, which I think is dangerous; while the article is aimed at enterprise-level organizations, small teams will read it, too, and may take its advice as gospel because the Zend name carries a lot of weight in the PHP community.