You have a monolithic architecture and three million lines of code. Finding the mistake that is causing the code to break is a huge task.
What should you do? How about adapting to a Microservices architecture?
You might ask me the advantages, so here I have a list.
Top comments (3)
Let's not forget about the increased complexity on governance you get when migrating to microservices, since instead of a single app in a single server you now have multiple apps on multiple servers. Even though server administration is not a big issue nowadays, the regular app monitoring still needs to be done and is multiplied by quite a lot in this scenario.
Also take in account that "easier to track bugs" might not be the case if the process that caused it triggers multiple events in multiple servers, a situation where usual debugging cannot be used, and you actually need a culture of logging everything in order to actually be able to find the error right away (and a particularly good use case for monitoring tools that centralize all the logs in one place).
It's not my intention to stop people from trying a distributed architecture, these advantages are true, but only mentioning the good parts may lead to some huge disappointments...
Agreed with your perspective. Microservices are very attractive on paper but it also comes with a cost. If you have more than 3 services per developers I think you'll start to see some new pains emerging (testing, monitoring, restoring a new stack, managing dependencies, feature flags...).
I would recommend not diving too far too fast, moving a few isolated components out of the monolith (auth or audit logs can be good candidates) will help understand the new practices to adopt.
There are great benefits to embracing Microservices and I'm a huge proponent of it. Just make sure you go at your own pace, it took Netflix years to get to the level of maturity they have.
I do recommend going into this one service at a time as you split up your large monolith. Also picking and sticking to one general architecture and way of doing things allows developers to more easily move between projects built on different services.
Funny enough and having done both I would actually say it makes the application as a whole more complicated and sometimes slower then an equivalently well designed monolith because a monolith can be internally segmented as well without the internal communication overhead. The main advantage is that it forces well defined interfaces between services and it is clear that you can upgrade one at a time.
An example of things being slow in a micro service architecture is realizing you need to collect data from multiple services due to a new requirement. Since making many calls can be slower we tend to need to create purpose built interfaces. In the end the amount of implementation time seems to be higher then it was for the monolith and also because of communication between teams that had to work together on the interfaces but could be protective of their respective services.
People keep saying a monolith can't scale but I think it depends on the application design, we just deploy a whole copy of the main code base on a bunch of servers at the same time.
Currently we still have a large main application but have been able to split a bunch of it off into smaller services, I just thought I would share some of our issues along he way.