The past few years have been a staple time in the transformation in the software development world. Most of today’s software products are based on a subscription or cloud model thanks to the SaaS revolution. The SaaS architecture concept has seen a massive surge because of the increasing uses and dependability of people on the cloud model.
Let’s have a look at the different ages the SaaS architecture has gone through.
The Monolithic Era
The first-ever approach that the SaaS architecture adopted was the Monolithic one. So far, it was the easiest and very straightforward structure to develop. All you had to do is to put collectively all of your source code, APIs, test code into one single app folder, and then create a single executable build.
Advantages
i) Easy Creation of New Projects
Monolithic Architecture provides a very stacked and mundane MVC architecture. And hence, kicking off a new project, making changes in it, and developing it along the way is very simple.
ii) Easy to Test
Since the structure of Monolithic Architecture is simple, the testing process becomes faster and easier as well. Finding out bugs and mistakes in the application becomes really easy to test.
iii) Easy Deployment
The codebase in the Monolithic Architecture follows a single way. And only one deployment pipeline is enough for the codebase which is easy to set up.
Disadvantages
i) Continuous Deployment (CD) Difficulties
- A minor change would require the whole application to be bundled and deployed again which is unnecessary re-work.
- There would be frequent changes in multiple parts of the big application, these would require the whole application to be bundled and deployed again very frequently.
ii) Continuous Integration (CI) Difficulties
Even minor changes will trigger full application tests to execute again. As code/test grows, it could take longs, sometimes hours to complete.
iii) Technological Commitment
When it comes to adding additional technologies to the backend and frontend, the monolithic applications don’t stand sharp as architecture and all the other elements (codes) are dependent on one another, so it is very difficult, even impossible sometimes to add new technology( framework or language) in the existing monolithic project.
iv) Scaling Difficulties
As the complete application code is written in a similar tightly coupled manner and bundled in a single executable process, scaling infrastructure only for certain required parts of an application becomes nearly impossible. Either we end scaling infrastructure for the whole application or nothing at all.
v) Difficult to Onboard New Developers
The size of the code in monolithic applications is generally very huge. Hence, it becomes very difficult for new developers to go through it, understand, and start changing existing code initially.
The Microservices Era
The Service-Oriented Architecture (SOA) gave birth to the Microservices Era. It is a modern architectural style that provides flexibility to structure an application into a form of well-designed modular components & services having immaculate operations. In order to develop a microservice, it is important to determine the technology stack (Framework, language) as well as the database technology for every microservice. One large backend service needs to be divided into multiple microservices and there are a total of three ways to do that:
i) By Domain
In this category, the business domains are analyzed and each microservice is created according to the nature of that certain domain and the problems associated with it.
ii) By Scale
Some applications have features that have a high use or become very popular that many people start to use them. In that case, separating them from core services and scaling them individually as per need becomes a better approach.
iii) By Use Case
Different use cases sometimes require particular technologies or solutions because they could perform faster and better for that particular use case. When you have such a special case, then it’s better to split it into different microservice.
Advantages
i) Faster CI/CD
The scale of the application determines how much time it would take to build, test, migrate, and deploy. With the microservice architecture, the code is divided into a number of microservices. Thereafter, each microservice can be deployed and tested much faster.
ii) Easy Maintenance
The codebase of Microservices is very small. They are developed to solve specific problems in the application. Hence, maintaining and extending these services is relatively easy for developers.
iii) Easy to Scale
The architecture approach of Microservices is very effortless which enables a developer or a DevOps team to scale it without much effort. Different microservices can be scaled differently as per need. Hence, there’s no requirement to scale the entire application.
iv) Faster Development:
Each microservice is usually owned and maintained by an independent specific team who can work in isolation and faster without being worried about behavior or impact on other parts of the app. Also, the developer’s doubts and queries get sorted very quickly within the team, which enables them to complete assigned tasks much faster by avoiding unnecessary delays.
v) More Reliable
Monolith applications are not very stable as they have a single code base. On the other hand, Microservices are more stable than that because of independent smaller services (codebase) to maintain. Means changes made to one service don’t affect others.
Disadvantages
i) Maintaining Different Tech Stack
The Tech Stack of different microservices can be different. And that’s why different teams with distinct specialties and capabilities are needed to develop and maintain the services.
ii) Complex Deployment
When you have multiple microservices to work with, you will need multiple CI/CD pipelines to set them up and deploy and they all should be able to interact with each other effectively. Hence, the initial deployment process becomes very complicated.
iii) Cost Factor
As we know that Microservices need multiple CI/CD pipelines to be set up for effective deployment, the cost of the entire application begins to rise. Another factor that adversely affects the cost is the need for a specialized team of developers to handle the various microservices of the app.
Micro Frontends Era
Micro frontends are more likely an extension to the Microservices pattern, where frontend functionality gets extended and split into multiple micro frontends or mini-apps and all of them are contained under one base app or shell. Owned by independent teams, these multiple micro frontend apps work in a way that they interact with one another and provide a unified app’s illusion.
Earlier it was difficult to manage and deploy a single large codebase, with the approach of Micro Frontend this problem seems to be resolved as it split it into smaller mini-apps that act independently. This is how Micro Frontend offers less bulkiness, great flexibility, and better testability. It has been a big help for businesses in providing an upgraded user experience to end customers. It’s generally a team of frontend and backend developers assigned to one or multiple mini-apps. Enabling teams working together on individual services, the micro frontend era quickly closes the loops and eliminates delays that occur due to the unwanted dependencies across teams.
Advantages
The advantages of the Micro Frontends structure are more or less similar to the microservices one, have a look:
- Scalability is better
- Development can be done faster
- Deployment independence is there
- Maintenance is easy
Disadvantages:
- Cost Factor
- Complex Deployment Setup Initially
Conclusion
The software development industry is evolving with emerging technologies and so is the software development architecture. The SaaS revolution has made a drastic impact in the software industry and has shown a huge rise in the new Software architecture concepts. New architectures provide a better way to structure and manage code effectively and easily.
Change is part of evolution here. From a single code base proposed in the Monolithic era has been shifted to a team of multiple developers with distinct specialization for different microservices in the Micro Service Era focused on backend development to today’s Micro Frontends focused on frontend development.
