Clearly, startups can use either approach with success. I’ve interviewed dozens of startup CTOs for our upcoming eBook, which has helped me discern the key pros and cons to consider when deciding which architecture to use.
Fewer Cross-cutting Concerns: A major advantage associated with monolithic architecture is that you need only to worry about cross-cutting concerns, such as logging or caching, for one application.
Less Operational Overhead: Focusing your finances on one application means that there’s only one application for which you need to set up logging, monitoring, and testing. A monolith is also generally less complex to deploy because you aren’t organizing multiple deployments.
Easier Testing: With a monolith, automated tests are easier to setup and run because, once again, everything is under the same roof. With microservices, tests will need to accommodate for different applications on different runtime environments, which can get complex.
Performance: A monolith can also provide performance advantages when compared to microservices. This boost is often down to a monolith using local calls instead of an API call across a network.
Overly Tight Coupling: While a monolith can help you avoid entanglement as previously mentioned, it becomes more vulnerable to entanglement the larger it grows. Because everything is coupled so tightly, isolation of services within the monolith becomes arduous, making life difficult when it comes to independent scaling or code maintenance.
Harder to Understand: Finding that monoliths are more difficult beasts to understand in comparison to microservices is common, and this is a problem that rears its head when onboarding new team members. This difficulty is sometimes a direct result of the tight coupling, as well as that you may find dependencies and side-effects that are not obvious when you’re looking at a particular service or controller.
More Organization: Microservices are separated by function, making them easier to organize because each microservice has a specific job and location. Plus, if your team is large enough, you’ll ideally allocate a small team to each microservice, giving you better control over each service.
Decoupled Services: With microservices, you can wave goodbye to tightly coupled applications. Instead, your services are decoupled, making life easier when you have to reconfigure them to serve different apps (for example, serving both the web clients and public API). They also allow for rapid, independent delivery of individual applications or services within larger systems
Enhanced Autonomy: You can craft each service using different technologies and frameworks, giving you more freedom to innovate. With a monolith, you have to design everything using the same tech stack.
Performance: Because isolating hot services and scaling them independently of the rest of the app is possible, microservices architecture can give you better performance, under the right circumstances.
Cross-Cutting Concerns: Whereas there are fewer cross-cutting concerns with monoliths (see above), they are a disadvantage when it comes to microservices. You’ll need to worry about issues such as logging or caching for every service.
Higher Operational Overhead: Microservices frequently are deployed on their own virtual machines or containers, causing a proliferation of VM wrangling work. These tasks are automated frequently with container fleet management tools.