The microservice architecture has recently been gaining traction, with many companies sharing their positive experiences with applying it. The early adopters have been tech behemoths such as Amazon and Netflix, or companies with huge user bases like SoundCloud. Based on the profiles of these companies and the assumption that there’s more complexity to running and deploying many things than to deploying a single application, many people understand microservices as an interesting idea that does not apply to them. It’s something that mere mortals could qualify for in the far distant future, if ever.
“The forces that call for microservices” are explained in the very second sentence:
tech behemoths such as Amazon and Netflix, or companies with
huge user bases like SoundCloud
While you’re quick and eager to diss monolithic apps, you’re kinda forgetting to list microservices’ disadvantages.
No, a better sentence to quote would be:
A monolithic application grows multiple applications within itself, and it meets high traffic and large volumes of data.
When you face this and the problems I outlined, then it really doesn’t matter what the size your company or user base are. You have to find a way to solve these technical problems — for example, by replacing 10-20% of a monolith’s functionality with microservices. Going all-in to replace an existing monolith is not a good idea.
I’m a junior dev who could have to work with microservices soon, that was an interesting reading. If anyone is interested with making Spring Boot-based microservices easily, I recommend checking out JHipster (https://jhipster.github.io/).