Introduction to Microservices
In the past decade, software development has been rapidly evolving to keep up with technological advances and consumer needs. As a result, Microservices got its chance to show off what it is capable of. Now everybody is talking about microservices and it currently getting a lot of attention from IT industry. At the same time, some software developers and communities pointing that Microservices Architecture is not a completely new thing but a rebranding of SOA. However, Microservices Architecture offers significant benefits compared to Monolithic Architecture. So, before moving into the Microservices, you should have general idea about Monolithic Architecture.
Monolithic Architecture
The Monolithic Architecture is considered to be a traditional way of building applications. In this architecture, the whole application is developed as a single unit. Just assume you have developed an application based on Monolithic Architecture. The application has a client-side user interface, business layer that contains several processes, and a database. So, all those are put together as a single unit and it makes the application into one large code base. Therefore, if you want to update or change a simple thing, you must access that whole code base. Moreover, you have to update the whole code base, even for a simple change you do. As a result, you might be needed to put down your whole application for several hours.
If you think Monolithic Architecture is useless nowadays and it doesn’t have any advantages, you are wrong. Because it has several advantages, such as:
- Easier debugging and testing
- Easier deployment
- Easier performance monitoring
However, there are a few reasons why this Monolith architecture eventually becomes so difficult to manage, such as:
- The codebase is too big for any single developer to fully understand
- Monolithic applications cannot be develop using different technologies and languages
- If the codebase is difficult to understand, changes made will be harmful to the system
- Even if one feature of the system does not work, the entire application will be affected
- Applications cannot be scaled easily since each time the application needs to be updated, the complete system needs to be rebuilt
- Most of the time, Monolith applications have tightly coupled dependencies
- Development may take lot of time to be built since each and every feature has to be built one after the other
So, the above weaknesses of the Monolith architecture were the main reasons that led to the evolution of Microservices.
What are Microservices?
Microservices is an architectural style that structures an application as a collection of small independent services, while a monolithic application is a single unified unit. These small services carry out all the application processes as a separate service. As a result, each service has their own business logic and perform specific functions. Usually each service is packaged as an API so it can interact with the rest of the application components and most importantly, every service can be updated, deployed, and scaled individually.
In software industry there is no exact definition for microservices, but most of the time people refer Martin Fowler’s microservice explanation as a definition for it.
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
-Martin Fowler
Characteristic of the Microservice Architecture
Independent components
As you already know, in a microservice application all the services can be deployed, maintained, and updated individually, which gives more flexibility. To achieve that, these services do not share libraries and databases among them. Therefore, we can prevent coupling between these services. Assume there is a bug in one microservice, but it only affects for that particular service and does not influence the entire application. If it is monolithic application, it will impact the entire application. Same goes when adding new features to the application. Because it is much easier to add new features to a microservice application than a monolithic one.
Maintained by smaller teams
Since a microservice project comprises multiple teams responsible for multiple services, each team should be complete in every aspect. As an example, there must be a developer to handle each field, such as user interface, database, business logic, and even QA. Because each team need to understand everything from consumer to backend. However, teams can work independently of each other, since the services are independent.
Flexibility in choosing the technology
If you are developing a monolithic application, your entire team have to stick on to a single technology or a stack. However, in microservice architecture, teams are not limited by the technology chosen from the start. They are free to apply various technologies and frameworks for each microservice based on the scenario.
As I already mentioned, you can develop microservices using different languages. But Java is considered as one of the top choices for building applications with this architecture. Java provides several microservice frameworks, such as Spring Boot, Swagger, Jersey, and Dropwizard.
Fault tolerant
When developing microservice application, Fault Tolerant considered as a must have feature. Because any service call could fail due to unavailability of the supplier. Therefore, if there is a service failure, you need to maintain that situation. Technically this is a disadvantage compared to a monolithic architecture, as it introduces additional complexity to handle it.
Better scalability
A major advantage of the microservices architecture is that each element can be scaled independently. It ensures your application is up and running at all times, without wasting extra cost on unused modules. In case of monolithic architecture, the whole application has to be scaled even if there is no need in it. Additionally, every monolithic application has limits in terms of scalability. That means if your application got more users than expected, you might have to rebuild the monolithic application.
The Scale Cube
Scale cube is a 3D model of scalability, that defined by “The Art of Scalability” book. The scale cube elaborates the microservices scalability using 3-axis, named as X, Y, and Z. The Scale Cube can be represented by the following diagram:
X-Axis Scaling: This is the simplest form of scaling. In this scaling, multiple instances of the application are deployed and managed by a load balancer. That means if one instance is not enough, you should be able to spawn other instance while keep processing. This scaling model is usually applied where the architecture is monolithic and the application can’t be split into independent, deployable modules.
Y-Axis Scaling: In this scaling, Functional decomposition can be achieved by decoupling your architecture into functions. Basically, it splits the application into a number of separate services and each service only responsible for one function. Microservices is an example for functional decomposing as they are independent and smaller services with their own database.
Z-Axis Scaling: This scaling model is similar to X-Axis except, its individual instances process only a subset of data. Each of these instance keeps the same set of code, but at the database level, data is partitioned into different shards. Usually this is responsible for routing the request to appropriate application instances.
Advantages & Disadvantages of Microservices
Before finishing the article, I would like to highlight the major advantages & disadvantages of the Microservices architecture. These advantages are the reason for Netflix, Google, Amazon, and other tech leaders to adopt the Microservices architecture.
Advantages
- Smaller and faster deployments
- Improved fault isolation
- Ease of understanding
- Better scalability
- Mixed Technology Stack
- Granular Scaling
Disadvantages
- Communication between services is complex
- Developers may need to deal with network latency and load balancing
- Testing is difficult compared to monolithic
So, this is the end of my article and I hope you enjoyed it. Happy Coding👨💻.
