Micro-Services and Monolith
There are two popular architectures to build a web applications:
- Monolithic architecture
- Micro-services architecture
The question is, which one should you adopt? What are the advantages and disadvantages of each?
Microservices
What is a micro-services architecture?
A micro-services architecture is a collection of independent services, each encapsulates a business domain. Each micro-service provides a set of APIs as interface. These APIs are consumed by either other services or the front-end layer.
Each service ideally has its own data layer. Note that the data layer is a separate layer from the services layer, but in a truly decoupled micro-service app, the data layer shouldn't be centralized, but you should split it up to match your services layer.
The advantage of having micro-services architecture is that it allows for independent lifecycle. Programmers can develop each service independently.
By the way, the term "micro-services" can be misleading. It doesn't necessarily mean "small services". Some service may be large (depending on its business scope). I personally think it should be coined as "independent-services" instead.
Monolith
What is a monolithic architecture?
A monolithic architecture is a self-contained application where the front-end, business logic, and data store are contained in one application.
Because everything is contained in an application, it is simpler to develop, deploy, and understand. This won't be true once your application has grown larger.
As your app grows, more components will become tightly coupled. If you modify a component, there is now a good chance that other components will break. A large monolithic app is harder to develop, takes longer to deploy, and difficult to understand.
Micro-Services vs Monolith
A monolithic app is faster to build at first but harder to scale later. A micro-services app is easier to scale later but slower to build at first. It's all about having trade-offs.
It comes down to your situation. Are you running a startup with a tight budget and have to move fast? In that case, use the monolithic architecture. Is money and time not a problem? In that case, use the micro-services architecture.
Most people don't have the luxury of being able to move slowly, so they need to move fast in the beginning. Later when their startup thrive and they're sitting in bags of money, then they can slow down and prioritize scalability. So why not build a monolithic app at first until your startup find a solid position in the market, then transition it to a micro-services? It's a win-win.
(I'm not advocating to toss scalability away. However, about 90% of startups fail. Moving with scalability-first approach will inevitably slow you down. Why spend the extra time to build an over-optimized app to handle 1,000,000 simultaneous sessions if your app never even reach 1,000 customers? How fast you can go when you're starting can be the key factor that decides your survival).
Top comments (2)
This is concise. I enjoyed reading.
I also want to point out that without proper skills and knowledge, building a microservice application is extremely risky.
Just having the architecture knowledge is not enough. One would need to have DevOps and Containers experts on board since the concepts are tightly coupled with microservices. Domain modelling expertise must not be left out as well.
With that being said, the long-term benefits of having a microservices architecture to solve a complex business problem for much larger applications is well worth the investment.
Thanks! I agree. At work we used both a monolith and multiple micro-services (started out with a single Rails app, now we have multiple NodeJS app microservices). To be honest, when I started I didn't really appreciate the micro-services but now that I've been here for a while, I'm much more appreciative to what the architects had done.
And yes, there is a much larger picture that is not mentioned here (pipelines, containers, testing, etc etc).
Very good points, I'm glad you brought them up!