Three Reasons Why Not to do Microservices

You probably heard that microservices are very cool and it's very nice to use them in all new projects and we should always refactor monolithic to microservices! But this is not whole story! sit tight!

1.Expensive

Microservices are expensive tool to develop enterprise systems. The cost of DevOps in microservice architecture is at least 2x what you did for your average monolith and hosting a platform with a mountain of moving parts in the cloud with multiple environments has more costs. There is generally more inefficiencies of teams working on disparate domains, while still expecting a seamless user experience. Also consider the inefficiencies of bug remediation and testing in a distributed platform and the costs begin to pile up.

2.Too complex

I know the sad old monolithic architecture is everyone's favorite punching bag these days. It's gotten to the point that if you actually design an application in this manner, you feel as though you're doing something wrong. Well, you aren't. Not always anyway.

There are plenty of scenarios where a good old-fashioned monolithic application is probably the most cost effective and pragmatic approach to a business problem. Rolling out a multi-service, event-driven architecture using domain events and event sourcing databases for your upcoming book club seminar registration database, while fun, is probably not a good place to stick your toes in the water, and you'll quickly find yourself in the deep end of the pool. You might stick with a traditional MVC-omatic templated app for that one.

There are also times when microservices just don't make sense. There may just be no way to split up business logic into a subset of services cleanly without so much functional service coupling that it becomes a monolith. Maybe your application will not be around very long. Why go through the trouble of implementing and managing all those cloud assets for something that will disappear in a year? Or maybe your domain is static and never changes. Why bother with microservices if you don't need the flexibility that the pattern affords over time?

3. Not for small teams

Sadly, microservices do not work in every environment and you have to be sure that they provide the value you need before blindly going for them. I’ve seen typical projects where there are 4–6 developers — basically one team. The customer wants the application to be built with microservices because they are great. The IT manager agrees. And so the team starts designing the application.

User management? Yep, that’s a microservice. Access rights management? Microservice as well. Managing and booking appointments? Microservice! Managing and sending orders by connecting to several 3rd party APIs? Definitely a microservice. Great, now everyone gets a microservice! Sometimes, you may inverse the rules of physics and have multiple microservices per person.

As you embark on this great journey, your team will need to make sure every microservice can be developed independently. Every microservice will have it’s own CI/CD pipeline, it’s own database and it’s own versioned API.

Now, when starting a new project, you might just have one team. All of these microservices will be built within the same team. It usually happens that one person takes on multiple microservices to implement a new feature. Let’s call her Ellie. Ellie needs to make a few adjustments here and there and test them at the same time. If she runs into problems, she may start debugging two microservices in parallel, trying to make sense of the communication between them. If this was actually part of one application, Ellie would have a much simpler working environment and would be able to debug it directly within the application. She also wouldn’t need to write a lot of definitions and code just for the distributed and probably asynchronous communication between these microservices.

Microservices are very modern and good but probably for Google, Amazon , Microsoft or at least for organizations with technical teams of at least 20 developer