You have seen several reasons to choose microservices. Now, let's look at reasons why not to choose microservices. As with everything, the strengths of microservices are also their weakness. While this book is about writing microservices, you should not think that microservices are the answer to every problem. There are many examples of why microservices are actually the wrong choice for certain problems. Here is a list of some of the reasons why not to choose microservices.
Understanding why not to choose microservices
Initially more work
The first and most obvious reason why you would not want to choose microservices is that it is usually a bit more work initially. To set up the entire system and connect the services and get them all up and running the way you need to often requires more work than with a monolithic application.
It starts by setting everything up and building a working environment. A monolithic application will require you to run the application only. So, once you start your main application, you are good to go.
A microservices application, however, requires a setup in which multiple applications are running at the same time. Alternatively, you could design your application to receive test data from static files; this, however, does not replace testing with the actual services. You can archive such a setup easily in a deployment situation; cloud providers are doing an excellent job in helping us here. However, when you start developing, it can be a good amount of work to set everything up. In the next chapter, you will set up your own workspace.
Additionally, microservices demand planning. You cannot perform some changes as quickly as you would in a monolithic application. If you are only building a simple proof-of-concept for your backend, you might be better off starting as a monolith. If you need something implemented that is critical in timing, microservices might not be your best option.
So, a good thing to keep in mind when working with microservices is that microservices demand some planning and often take longer to start.
Increased complexity
When developing monolithic applications, you usually have everything in the same code base. As long as a project is small, the lack of complexity makes it easier for you to maintain it. Additional features and changes can be implemented with the same stack, language, and frameworks you have been using so far.
Microservices, on the other hand, can be a bit more complex (or messy even). Adding a new feature is not always trivial and may require changes in numerous services. The services themselves may also have different stacks. You may have a legacy service running PHP combined with a Swift Vapor service for another part of the app. Adding a feature requires you to work in PHP as well as Swift.
If you know your exact scope for a project and don't expect any changes, there is no reason not to implement it like a monolithic application.
Microservices can increase the complexity of a project, compared to traditional technologies such as PHP, which you should keep in mind. The same can be said about most microservice technologies though, regardless of programming language. Let's take a look at troubleshooting and debugging now.
Debugging and troubleshooting
Debugging and troubleshooting is yet another issue you will need to consider. It can be quicker and easier to debug one application as opposed to two or more microservices. Debugging goes hand in hand with complexity; bugs will not be found as quickly as they can be in a monolithic application. As a matter of fact, this topic is important enough for this book to have an entire chapter on it.
If you are dealing with an application that is limited in scope and functionality is not expected to grow, a monolithic approach might be better than a microservice approach. That said, I have personally seen many projects start as "small and manageable" pretty suitable for monolithic applications. But then they grow, and the benefits quickly turn into serious problems. If you think all of your applications should be suitable for growth, take a microservice approach.
It can take more time to find bugs. Because services are often somehow connected, it can be pretty hard to boil a symptom down to a bug. I have seen a small symptom come out of many unrelated errors.
To conclude, debugging a microservice backend is more complex and time-consuming than for monolithic applications, however, there are also great benefits with using them. This is why we will look at a list of companies that are using microservices and have switched away from monoliths.