Why you shouldn’t use microservices
Before digging into the topic, I would just make clear that I’m not against microservices. Actually, it’s the opposite: I love them. However, I’m just almost 100% sure that you won’t need them at first.
It’s been a few years that the word “microservice” came up. Since then I’ve seen a lot of developers and software architectures talking about it. By the time, it was fascinating (and it still is). The possibility of building an application into small parts; deliver small services (microservices) that are self-capable; the ability of small deployments to fix bugs and delivery new functionalities…
Yes, I know. It sounds amazing. And it is. What they don’t tell us, though, is the necessary effort to build that. And, you may not need that for your applications.
Recently, I found out that technology giants such as Amazon and SoundCloud didn’t start using microservices at their first pitch. Overtime, with the increase of issues with having a monolithic application they migrated from a monolithic application to microservices. So, if services like Amazon and SoundCloud didn’t need that at first, do you think you really need that? That’s my point.
Microservices are amazing. They enable you to develop, test and deploy the small parts of the application independently. Besides, they allow you to easily escalate just a part of your application. The problem is that microservices will require way more work than you think they will. Build well decoupled services, make them totally independent, make them talk to each other (most of times you will need that), join their information to make that available, organize the teams to work separately and at the same time together – all these points require a very mature team with a very good knowledge on DevOps practices. And what happens most times is the teams end up creating a coupled dependent microservices, making them work very similar to a monolithic.
Most of times, building a well decoupled application will give you everything you need. And if it won’t, that’s the time to start separating your well decoupled monolith. But again, I’m not saying that you should break your whole application into microservices. Definitely not. You should start thinking about what part of your application would make sense to be separated. If it’s worth to create a totally decoupled service, or maybe just create a independent service using the same data store. It will depend a lot of what is your goal.
So, when you are architecting a new application, you should first think about what your goal is, and manly, if your team is capable of creating that architecture. For most cases, I’m totally in favor of a very well decoupled monolithic first. After that, the team may know what needs to be microservice and what does not.
About the author
Luis Eduardo Lanfredi is a Software Engineer at Poatek. He holds a BSc in Information Systems. Most of the time he works with Microsoft Technologies and web applications.