In defense of the monolith
The spirit of the times is to separate codebases along team lines. According to "service oriented architecture", if you have a UI team, a C team, and an app team, you should have three or more separate codebases.
In the worst case, this means that every team has to come up with their own deployment and serving solutions, spend time debugging those things when they fail (because they will never work right the first time), and learn what it means to host a reliable service. Is this really the best way for everyone to be spending their time?
The monolith is your friend
Your code serves tens or hundreds of different needs, and there is nothing wrong with that. But if you go full SOA, with each team independently coming to conclusions on language, framework, and operations, you're going to have a bad time.
The fear of working from a monolithic codebase is that it will become a ball of mud. Naively, it seems like divide-and-conquer might fix this problem: maybe N smaller codebases are simpler to maintain than one large codebase. In fact, since often those N codebases are written by different people, sometimes in different languages, you end up with ~N times more complexity than you started with. If your organization can't cope with the complexity of one large codebase, it won't fare better with N smaller codebases.
Another aspect that I don't think is discussed enough is how when you have a monolithic codebase, you develop the sense of working as a big team on a common set of problems, rather than N isolated teams working on bespoke solutions to seemingly different (but not) problems.
The monolith isn't great, but the alternative is even worse.