If you are starting to build an application without any existing product reference or new products without an idea to start with, monolithic architecture may be a good fit. Be careful with microservices if you are not sure about your product’s size, how many users you have to serve or what specific services need to scale… because it can be complicated and unnecessary.
The most common problems when we deploy a monolithic application are:
And in large applications, development also matters. Many developers will work independently but consistently, so we must split a big project into many sub-projects for features then use it as reference packages in final project. A modular model can be a good choice; all developers will register their services and configuration at module startup.
Sometimes we need to rebuild all dependent projects to ensure that their references have the same version and the final application will work. Whenever we have a small change, no one can guarantee that the change will work for other features. We only know when it happens and not during build time. So a small change can lead to a large app that must be tested. It can affect multiple teams at once instead of a specific team.
Besides the problem of scaling the processing capacity of the monolithic application, we may need to scale up more human resources than necessary.
Microservices are needed when:
Unfortunatelly, this model has even more problems that need to be resolved besides the traditional problems of monolithic app:
Now a day, SaaS is growing up quickly to help ICT companies can provide their products and services to many customers rapidly and easily. We can provice multi-tenant services using infrastructure, in-app implementation, or mixed mode.
In most cases, we need separte tenant configuration, data, and resources. So we have common problems:
Choose the development model according to actual needs and conditions. We provide several application template: