microservice architecture is a new method of developing software as a suite of small modular and independently deployable applications.
While there is no standard and official definition of microservices,in my opinion the best way the best way to explain microservices architecture design is to compare it to the previous monolithic way of building applications.
Therefore, it helps to have have a quick recap on Monolithic Architecture.
In the traditional three-layer design, the server-side application plays the role of the middle layer, processing business logic and serving data from database tier to clients (web browers, mobile apps, internet of things, etc.).
The application is written as a SINGLE, unified code base and everything runs in the same process.
Despite having a logically modular architecture, the application is packaged and deployed as a monolith into a server.
The Benefits of this architecture style lie in its simplicity of development, testing and deployment.
In fact, we only need to copy the packaged application to a server and we are ready to run it.
Well known internet services such as Netflix, Amazon and eBay initially had a monolithic architecture
When it comes to scaling applications, we can only perform a horizontal scale by running multiple copies of the same application behind a load balancer.
As a result, the whole application scales and we cannot scale a single component differently from another one.
A monolithic architecture works well in the early stages of a project.
The downsides of the Monolithic architecture
Monolithic architecture style has a number of downside.
First of all, its simply approach has a limitation in size and complexity because as the application became larger, due to the fact that developers keep going on add new features, it becomes more complex and difficult to fully understand, to manage and test it.
Moreover, all new functionality must be coded using the same program language.
For example, we cannot have a component written in Java and another one written in Nodejs.
It goes without saying that after each update we must redeploy the entire application and recopy it to the server.
In addition, Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements. Furthermore, another problem with monolithic applications is reliability. A bug in any modules can potentially bring down the entire application. Since all the instance of the application are identical, that bug will impact the availability of the entire application.
In the 2008 a single missing “;” brought down the Netflix website for many hours.
Last but not least Monolithic applications requires long term commitments to technology stack upgrade, since changes in frameworks or programming languages will affect an entire application and it will be expensive in both time and cost.
Let’s talk about microservices architecture
One way to overcame the problems that monolithic architecture presents is to switch to a microservices architecture.
Microservices became the hot term in 2014, attracting lots of attention as a new way to think about structuring applications
The main idea is to split our application into a set of smaller, independent but interconnected services instead of building a single monolithic application.
Each microservice runs its own process and communicate to other services with a lightweight mechanism, often an HTTP APIs.
In a microservice architecture, services are modeled as isolated units that manage a reduced set of functionality
Microservices architecture is particularly well suited to cloud-based environments and to design complex, mostly web-based, applications.
Splitting a big application into a number of smaller and independent applications makes it more easy to develop a new feature, to test it and to add it to the entire project, without the need to stop and redeploy the whole application.
In a microservice architecture topology applications don’t, however, have direct access to the backend services. Instead, communication is mediated by an upper layer know as API Gateway.
The API Gateway hides the endpoints of the internal services and exposes different endpoints to the client application. In addition, it is responsible for tasks such as load balancing, caching, access control and monitoring.
Communication between these microservices can be done in two main ways: HTTP and message queue
Basically, HTTP is direct communication and should be used when you want an immediate response from the other service.
On the other hand, the publish/subscribe mechanism “send and forget” way.
The Microservices architecture pattern also impacts the relationship between the application and the database.
In fact, instead of sharing a single database with other services, each service has its own database.
We can choose different types of DB for different services because the databases are not shared with others services.
If a service needs some information, it will request that data using a REST API call to a specific service. The format of the data is usually JSON.
On the one hand, this approach could result in duplication of some data, on the other hand having a database schema per services ensure loose coupling.
Therefore, a service can use a type of database that is best suited to its needs.
In the Scale Cube plot (http://microservices.io/articles/scalecube.html), the Microservice architecture corresponds to the Y-axis scaling where scaling is done splitting the application into different services.
The benefits of Microservices
In terms of benefits a Microservice architecture solves the problem of application complexity by decomposing an application into a set of manageable services which are faster to develop and much easier to understand and maintain.
Splitting a big application in a set of smaller services also improve the fault isolation. In fact, it is more difficult for the whole system to down at the same time and a failure in processing one customer’s request is less likely to affect other customer’s requests.
In second place, developers are free to choose whatever technologies make sense for their service. We are not more bound to the technologies chosen at the start of the project.
If a team wants to test a new technology stack, it can do so without any problems.
In addition, it easier for a new developer to understand the reduced set of functionality of a microservice instead of understand a big application design.
Each microservice could be refactored piece by piece as new technology solutions become available.
The concept itself is largely language agnostic, so we can select the appropriate language or framework for each service.
Moreover, each service can be deployed independently by a team that is focused on that service, using different technology stacks that are best suited for their purposes. This is great for continuous delivery, allowing frequent releases while keeping the rest of the system stable.
Lastly it makes continuous deployment possible for complex applications and enables each service to be scaled independently.
Microservices architecture guarantees Loose coupling, which means microservices should be able to be modified without requiring changes in other microservices.
To list down some of the main advantages of microservices architecture,
- Improves fault isolation: larger applications can remain largely unaffected by the failure of a single module.
- Eliminates long-term commitment to a single technology stack: If you want to try out a new technology stack on an individual service, go right ahead.
- Makes it easier for a new developer to understand the functionality of a service.
- when individual parts of a system are separately deployed, they can also be separately scaled
- separately deployed services can be implemented using entirely different platforms or design models.
- It is more difficult for the whole system to go down at the same time
- Multiple developers and teams can deliver independently under this architecture.
- In case a service goes down, it will only affect the parts that directly depend on it (if there are such parts). The other parts will continue to function well.
The downsides of Microservices
Despite the fact that microservices patterns present a large set of benefits there are a number of drawbacks that we should take into consideration.
Microservices architecture is not a silver-bullet to every problem. While it solves a lot of problems of the old monolithic applications, it also introduces new problems that we need to consider.
Microservices architecture add a complexity to the project because a microservice application is a distributed system. For this reason, we need to choose and implement an inter-process communication mechanism base on API request, message queue. On top of that we need to address partial service failure and take into account other issues of distributed system.
Testing a microservices application is also much more complex than in case of monolithic web application. We need to launch the service we are going to test and any services that it depends on.
Deploying a microservices-based application is also more complex. A monolithic application is simply deployed on a set of identical servers behind a load balancer.
In contrast, a microservice application typically consists of a large number of services. Each service will have multiple runtime instances and each of them need to be configured, deployed, scaled and monitored.
Last but not least we need a service discovery mechanism in order to successful deploy a microservices application.
Conclusions:
To sum up a monolithic architecture better suits simple, lightweight applications. It is important to understand Monolithic architecture because it is the start point for the microservices architecture, where each service by itself is implemented according to monolithic architecture.
I'd rather say nowadays,the microservices architecture pattern is the better choice for complex, evolving applications.
References
- Building Microservices (Sam Newman)
- http://microservices.io/