Today we explore a topic that has been trending in the IT industry and it has been booming now, developers are using this method to scale up and build different Applications and Components.
Monolithic Architecture
Before microservices, the standard way of developing an Application was with Monolithic Architecture. All the parts of the Application/Code/Components were a part of one Single Unit.
Let's consider an example for a better understanding, say we have a website for shopping for different products, then every component of this site would be on a single codebase.
The User-Authentication, Product-Catalog, Shopping-Cart, and Payment-Page, these components would be put together in a single bucket or deployed as a single unit or will be a part of one monolithic app.
So this is the kind of scenario of a Monolithic Application.
Problem and Challenges of Monolithic Architecture
Obviously, the components and codes are in a single unit so this leads to many problems like -
The app must be written in One tech stack
Teams need to be very careful to not affect each other's work
There is one single artifact, so you must re-deploy the entire application on each update
As the app gets larger the coordination between the team became harder, also Scaling of the entire app is possible not of service.
These resulted in a longer release process and bugs in any module can potentially bring down the entire app.
So this is where Microservices came in Picture
Microservice Architecture
With microservices, we can break down the apps into essentially multiple smaller services which are more independent services. that make up one big application. But before that, there should be a consideration of how the breaking up of applications is gonna work. Where the code should go? How many services do we need to create and how big/small should they be??
Keep in Mind to split services based on "Business Functionalities" and not on Technical Functionalities.
In simple words there should be 1 service for 1 job, our shopping application example fits into this as in payment component should work differently from the shopping cart component.
Also, every service should be self-contained and independent from each other meaning each component should be developed, scaled, and deployed separately. This concept is also called "Loosely Coupled" which you may have heard. And each microservices can have its own version as long as they work perfectly in CI/CD pipeline.
How do services connect with each other?
These services are isolated and different from each other so, how do they communicate obviously in our shopping app payment service will need something from the user account.
A very common way is API Calls communication
Each service has its own API made and integrated by developers
They can talk to each other by sending requests to respective API endpoints and HTTP Requests.
This uses Synchronous Communication, which means one service has to wait for a response from other services.
- Communication via Message Broker
- This is the Asynchronous way of communication between services, as there is a common distribution pattern.
There are queries in Message Broker which is processed as per their need.
Advantages of Microservices
Each microservice team can choose its own dedicated tech stacks now
As a result, each team can develop the service independently without affecting others.
De-merits of Microservices
Now everything has its own disadvantages and microservices have theirs too -
Because of a distributed system, the complexity of application increases, and now management becomes tough.
If one service isn't working properly others can give unwanted error
It becomes more difficult to monitor with multiple instances running.
But there are many tools that are being built to omit the challenges popular one of which Is Kubernetes which is well-known for handling microservices.
Now we have known much about Microservices and their working but you may have a question how do we manage code for these, where do we keep the codes of different services, Well the answer is MonoRepo and PolyRepo.
Monorepo
Monorepo means using a single git repo that contains many projects. It contains 1 code with different folders and a directory for each project. Because of these, it makes code management and development easier.
Cloning and working can be done with one repo, changes can be tracked and released together, and also configurations are easily shareable.
some challenges here can be No tight coupling are allowed and big source code means git interaction becomes slow.
Polyrepo
Polyrepo simply putting it asOne repo is used for each service
Code is completely isolated from other services.
Cloning and working on these becomes easy as it's separate
Groups in git are used to configure connected projects
Helps developers to keep an overview of each component
And again challenges can arise here also like It becomes more difficult to work on projects as they are difficult and complex. Sharing resources also becomes difficult.
So these were the basic explanation of Microservice Architecture. If you find this article knowledgeable do share among your peers and if there is any suggestion or mistakes done by me, please comment I will improve it.