→ The next thing asked is which architecture to follow. It is important to understand it and use it before the software/application development.
Let us walk through as a high-level overview:
→ If all the functionalities of a project exist in a single codebase, then the app is called monolithic
→ Inside one code-base, we have different layers like frontend, backend, deploying, etc. Mono means single
- Developing monolithic apps using legacy systems is a very simple and straightforward process: build → test → deploy → troubleshoot → scale
2. If the project is in the beginning stage, we can go for monolithic architecture for faster iteration.
3. Relatively easier and simple to develop in comparison to microservices architecture.
- It becomes too large in size with time and hence, difficult to manage.
2. We need to redeploy the whole application even for a small change.
3. As the size of the application increases, its start-up and deployment time also increases.
4. Even if a single part of the application is facing a large load/traffic, we need to deploy the instances of the whole application on multiple servers. It is very inefficient and takes up more resources unnecessarily. Hence, horizontal scaling is not feasible in monolithic applications.
5. It is not very reliable as a single bug in any module can bring down the whole monolithic application.
→ If the architecture development style is made up of smaller services communicating with each other directly using lightweight protocol i.e. HTTP.
→ The microservice architecture has a significant impact on apps and databases. Instead of sharing the database. Each microservice has its own database
Microservices are the small services that work together. — Sam Newman
Principle of Micro-service:
- Single Responsibility: Each microservice has one function and is designed as a part of the SOLID design pattern.
- Design for failure: Microserve must be designed with failure cases in mind. If one microservice is down, the whole application should not be down and must remain accessible to the user.
- It is easy to manage as it is relatively smaller in size.
- If there’s any update in one of the microservices, then we need to redeploy only that microservice.
- If a particular microservice is facing a large load because of the users using that functionality in excess then we need to scale out that microservice only. Hence, the microservices architecture supports horizontal scaling.
- Each microservice can use different technology based on the business requirements. We can choose the best-suited database for each microservice service
- Loose coupling — One database down does not make while application down.
- Being a distributed system, it is much more complex than monolithic applications. Its complexity increases with the increase in the number of microservices.
- Microservices are costly in terms of network usage as they need to interact with each other and all these remote calls result in network latency.
- Microservices are less secure relative to monolithic applications due to the inter-services communication over the network.
When to go With a Monolithic Architecture?
Monolithic architectures should be considered when you are building a small app that doesn’t require team growth. Microservices account for a system that can be too complex to design and manage by small teams, which is often not optimal for developing small-scale apps.
If your project is still at the early stages of your Software Development Life Cycle, at the ideation phase for example, and your app has the potential to grow in later stages, you may consider opting for the monolithic model as it supports fast iterating.
Teams that are building an MVP (minimum viable product), should consider going with monolith infrastructures as it enables you to get first-user feedback very quickly.
When to go With Microservices?
In the monolithic vs microservices battle, the microservice-based architecture comes out as the winner for a vast number of big companies that face a significant increase in customer demand. Most modern companies (including Amazon, PayPal, Spotify, etc) are switching to containers such as DevOps, Docker, Kubernetes, Lambda, etc. and microservices as it allows them to build a large-scale solution that is easily scalable and optimized in terms of resource usage and real-time demand.
Microservices are also extremely useful for the projects that require:
- multiple independent teams working on different app functions
- 24/7 reliability
- the ability to withstand big load peaks
- 10+ developers
- the ability to break down business domain into smaller ones
- operations that are short-lived or expressed as REST calls or queue events
- minimal or no specific or strict cross-service transactional requirements
Understanding both application architectures is important. Most bigger projects are switching to a microservice approach. In the end, it depends on the project’s goal, user traffic and project budget.
As software enthusiasts, we should be ready with both approaches.
Thank you for being till the end 🙌 . If you enjoyed this article or learned something new, support me by clicking the share button below to reach more people and/or give me a follow on Twitter to see some other tips, articles, and things I learn and share there.