Microservices Architecture

Microservices is an architectural approach where apps are broken down into their smallest components, independent of each other. Each of this component or process is a microservice. And each microservice can be tested and deployed independently making it highly scalable. Each microservice can be written in different languages as they communicate with each other via APIs.
Unlike microservices, a typical monolithic approach involves the UI layer, business logic layer, and data access layer all bundled together in a container. Before microservices, in monolith any change or addition of a new feature was very tedious and time-consuming. Because of the poor agility, organizations have to wait for a longer period to release a new feature. Now with microservice, organizations can release a new feature as quickly as possible.

Microservices vs Monolithic Architecture

Now let's compare the microservice architecture with the traditional monolithic architecture.
If we break monolithic then we get Mono + Lithic which means single stone. In technical terms, Monolithic architecture is a software development pattern where an application created would have the user interface and data access code combined into a single program. This makes development and deployment easier as there is a single code base for every functionality.

‍Advantages of monolithic over microservice architecture

1. Single Codebase: Everything will be under the same code base, front-end or back-end code. 
2. Single Build System: As the entire codebase is single, the build system is also single.
3. Simple Deployment: Due to the single code base for the front end and backend, there are no multiple deployments and therefore there is a single and simple deployment in monolithic.
4. Simple Testing
5. Single Executable Binary: There will be a single JAR or WAR file instead of multiple files as in the case of microservice.

‍Disadvantages of monolithic

1. Tightly Coupled: The entire application is tightly coupled so any change in any feature will lead to testing and deployment of the entire application.
2. Poor Reliability: As it is tightly coupled, it is also poorly reliable.
3. Slowness
4. Lack of flexibility: Adding new features or changing the existing code can break the entire application. You also have to run the entire test cases to ensure that the application is running fine with all the existing features as well as new features. 
5. Difficult to understand: Monolithics grow over time and the entire code base becomes entangled so when a new engineer joins the team he has to understand the entire code base even though it is not necessary so that the feature or module he will be working on should not break the existing code.

Microservices beats monolithic in agility, flexibility, and scalability On the other hand, due to multiple teams working on different services the development cost can be much higher as compared to the monolithic approach.
Now this leaves an interesting debate as to whether to go for the microservices approach or the traditional monolithic approach for your next application. This depends on your business requirements. Every business starts with a monolithic architecture. Even if you take an example, of any of the tech giants like Amazon, Netflix, or even Indian startups like Razorpay they all have started with the monolithic approach as it will be easier to build a fully functional application using a monolithic architecture with fewer resources.

So, if you are just starting or are in the initial phase of your business then the traditional monolithic will be your go-to solution and if you are an already established business but started facing scalability issues recently then it's high time you should migrate towards microservice before your codebase becomes cluttered.

Why use Microservice Architecture?

There are many benefits of using a microservice architecture. Some major benefits have been explained below.

1. Distributed: It is possible to have components on different machines or servers and they can communicate with ease. A service deployed in one server can easily communicate with the service deployed on another server through well-defined APIs.
2. Loosely Coupled: As the entire application is broken down into small components, therefore, dependency of one component on another one is not high as compared to monoliths where there is a single codebase for everything.
3.  Resilient: It means how shockproof your application is. As the entire application is broken down into small microservice so the failure of any one component will not fail in the whole application and we can also find which service has malfunctioned and fix it quickly in microservice as compared to monoliths.
4. Highly Scalable: Suppose there is a component that is handling more load than other components and has a chance of failure then we can scale that specific component hence making it highly scalable.
5. Easy to deploy: Suppose there is a change in a specific component then you only need to deploy that microservice hence making the deployment process easy.
6. Ready for market faster: Suppose a new feature is being introduced then you can rapidly develop that component without worrying about the existing components just like plug and play.
7. Usage of multiple technologies: There is the flexibility of building a microservice using an entirely different language as compared to other microservice as microservices communicate with each other via APIs.
8. Easier for developers to understand: Microservice Architecture comprises smaller components that are easier to understand so if a new developer is assigned then he/she can easily understand the codebase for the specific service in a short period.

The 12-Factor Principles

The 12-factor is a methodology or set of principles to build scalable, performant, independent, and resilient enterprise applications which are as follows:

• Codebase: There should be only one codebase for a deployed microservice, although multiple versions of application deployments are permissible. The build stage tags new releases and fixes bugs. Tools such as Maven are used to build JAR files. The release stage prepares the build stage for execution in the target environment. Tools such as Packer and Ansible are used in this stage. The run stage executes the application and does not need any intervention.
• Dependency: All the external libraries should be declared as dependencies and versioned explicitly. It is a good practice to declare dependencies, as it simplifies the setup for developers who are new to the application. Maven enables developers to bundle their applications and their dependencies into JAR files, hence isolating the dependencies.
• Configuration: Configuration options should never be hardcoded into the source code. It is a good practice to use environment variables for applications with configurations. 
• Backing Service: The services on which an application depends for different operations are called backing services. For example, message brokers like Kafka and RabbitMQ are database-backing services. The 12-factor principle states that all backing services should be treated as attached resources. The network connection/URLs of the communicating services must be configurable. There is no need to make any code changes, even if the location or connection details of a service change.
• Build, Release, Run: It is advisable to keep the build and run stages separate. The build stage tags new releases and fixes bugs. Tools such as Maven are used to build JAR files. The release stage prepares the build stage for execution in the target environment. Tools such as Packer and Ansible are used in this stage. The run stage executes the application and does not need any intervention.
• Processes: It is recommended to execute the application in the form of multiple processes. The applications should be stateless, such that even if a part of the application stack fails, the application in itself should not fail.
• Port Binding: The created microservices should be exported via a port binding, i.e., the application service should be accessible to other services via a URL.
• Concurrency: It is recommended to scale out via the process model. You can create multiple processes and then distribute the load of your application among those processes. Each process should be able to scale and restart itself independently when needed.
• Disposability: Application processes can be shut down on purpose or unexpectedly. The shutdowns must be graceful and the startup of the application processes must be quick.
• Dev/prod parity: The development and staging environment should resemble production to minimize any bugs or unforeseen issues. It is advisable to keep the development, staging, and production as similar as possible.
• Logs: Logs should be treated as event streams, and routed to a specific service for analysis. You can use SLF4J to handle logging abstractly within the application. 
• Admin Processes: Administration/management tasks should be run as a one-off process. One-off processes are processes that occur only once and are not repeated.

Challenges with Microservice Architecture

Microservice Architecture also comes with a few challenges.

Achieving data consistency

To achieve scalability, each microservice should have its database. In a large application, like Netflix where the number of microservices can go as high as 500, maintaining data consistency becomes a nightmare because

• Managing multiple SQL and NoSQL databases is difficult.
• Complexity in applying queries that span multiple databases
• Joining tables from different services also becomes a difficult task.

However, to achieve data consistency we follow a pattern known as the Saga Pattern. You can read about it here.

Complicated deployment process

Managing CI/CD pipelines was relatively easier in monolithic as compared to microservices. With the increased number of applications managing code repositories and CI/CD pipelines becomes much more complex.

Testing becomes challenging

The testing phase becomes complicated with the microservice approach as each service is a standalone application so you have to test them independently. Also, tests that involve multiple services can be complicated.

Communication

Each service is a standalone application developed using different tech stacks and they communicate with each other via APIs. For such communication, you need a proper infrastructure layer that would facilitate resource sharing across various services.
Managing such communications can be hard without using automation and advanced methodologies such as Agile. You would need DevOps tools such as CI/CD servers, configuration management platforms, and application performance management (APM) tools to manage the network.

Wrapping it up

Microservice Architecture is great when it comes to scalability and releasing new features rapidly however it is one side of the coin. The other side of the coin is to design an effective microservice architecture while keeping challenges in mind for your application so that it does not backfire and for that, you need an expert team that will help you in this process.

‍