|
Microservices make sense in some scenarios. I work at a large retail company with who knows how many developers. We have different teams for payment, promotions, product search, account, shipping and more. All of them working on a single codebase with coordinated deployments would be a nightmare. Previously, I joined a startup (previous coworkers of mine), a developer and a business guy. The developer "drank the microservices kool-aid", and came up with (in theory) super scalable solutions and like a dozen of microservices. It was difficult to keep things in mind, the tech stack was way too complicated for two developers. It was also less performant and more costly. The added complexity was totally unnecessary, especially because we never got neither tons of users, nor more developers. The business guy trusted the developer, so the company never worked enough on their product and USP. I guess the developer just didn't want to accept that the fancy tech solutions won't bring success. Yet another time, we were a small team (5-ish devs, product owner, and a designer). We started with a monolith and we paid attention to software design and moved quickly. Also, for some reason it's often overlooked, that you can make your monolith modular and design it so that when the day comes, you can split it up into smaller services. You don't need to start with microservices, you can start with a monolith and figure out later how to split it up (if necessary). Microservices and "monoliths" have their place, you just need to know when to use which. |
The main problem I have with microservice marketing:
It is often promoted to clients that do not have applications that are large or critical enough to warrant leveraging them.
That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily.
And clients are often not aware of the operational costs that can rise over time for each component of the distributed architecture.
"Monolithic" solutions have also not stagnated... They can be run in distributed methods, they can leverage microservices in parts, they can also leverage containers, they are far from obsolescence because they are using the same languages that microservice architectures use, just with less distribution overall.
The term monolithic is often used to indicate that less-distributed solutions are somehow "out of date", "obsolete" and "not innovating" inaccurately, when the real story is that the business case usually dictates which solution will fit best.