Dude! I’ve written a lot of code for a lot of monolithic programs/apps that ran on desktops, devices, and servers. Somewhere close to 2 million lines of code or more, easily over my startup companies. I've evolved over time, by myself and with others, through experience and research to be now fully microservice oriented.
Microservices are the way and in a sense always have been to me. Whether it’s defining a C++/Swift class method at a file-level or server-side function the smaller and more focused ‘code’ you have the better. Anyone who has designed and written code of any language knows the pain of the growing monolith. It starts out small, slowly adding functionality over time, sometimes making sense, sometimes because you don’t want to create a new class or module, but no matter what it grows and grows...
This monolith growth is ever so more dangerous on servers. As these machines are very powerful and now readily available (via EC2 spin up) it’s so easy to have unlimited functions added to a server. Complicating the monolith even further is the fact that they are almost always implemented by many people/companies. This leads to inevitable complex version dependency and overly complicated software. Always the monolith, hard to test, deploy, rollback etc… Powerful machines almost call out to place more software on them. InstallShield installation exists because of these problems.
Microservices, functionality at a specific level, with almost singular functionality is the way to the future. It has always been true at a class method level but certainly more so at the server level due to the added complexity of a backend solution. Single operations with clear methods for validation, testing, versioning etc… make it ideal and less prone to big monolithic problems. Much like a C++ class method ‘contract’ these microservices are awesome at being clear and unambiguous. Due to their limitations, they allow for more dev-ops type development which is great. With cloud services like AWS Lambda, there is almost no reason for monoliths anymore. We can focus on the microservice and keep them simple. It's a beautiful thing.
Having developers ‘think’ and design ‘microservices is essential. It is a ‘different’ way of thinking but it is something we all as computer scientists have been taught to do in our class design/implementations. The key is to not be lazy and to create the new microservice as a separate independent entity. Don’t let functions blob into the nearest convenient monolith.