Microservice Architecture
This is just a quick summary that covers what microservices are, potential use-cases, and the pros/cons of using this paradigm.
In a future post, I’ll go over packaging microservices in Docker containers, and then deploying the containers to the cloud.
What is a microservice?
You can think of a microservice as an individual module in a system that serves a specific business-goal. Each microservice is stand-alone and exposes its own unique interface that allow for other services to talk to it (Rest, SOAP, etc). Since each microservice acts as its own stand-alone service, there is flexibility when it comes to implementation, as each microservice can be built using custom tech-stacks that best suit the business goal.
When it comes to building distributed-systems using Microservice architecture, each microservice is often (not always, as a host can run multiple containers) deployed on a different host, whether it be through using EC2, DigitalOcean, Azure, VULTR, etc. Furthermore, each microservice can have several service-instances, which then aggregate to form a cluster. I will elaborate on these terms in the following sections.
The Pros and Cons of Microservices
Pros
Modularity: Each microservice has a specific business goal. This can be helpful for organizing workflow, especially for large teams, as assigning developers to an individual microservice sets modular boundaries for work items.
Deployments: Each microservice is as a stand-alone service, which means you can deploy your microservices more frequently. This means you don’t have to worry as much about each deployment bringing down the entire system!
Customizability: Analogous to woodworking, building something for a specific purpose requires the right set of tools. With microservice architecture, each service can have its own tech stack that best fits the business need. This means if your microservice is heavy in Machine-Learning and/or data-science, for example, you can use Python as your main driver, and whichever data-store provider that best fits the goal of the microservice.
Cons
Dev-Ops complexity: Managing several microservices and regular deployments can be a pain for a dev-ops team.
Performance: By having microservices, your system is now distributed, which means you have to call remote services, which can be slow.
If you want to see these trade-offs in more detail, visit here. Fowler does a great job of analyzing Microservices, diving deep into the specific use-cases and tradeoffs that come with choosing this architectural pattern.
Microservices in a Distributed System
Now that you know what a microservice is, let's zoom out and see where they play and how they are plugged into the rest of the system.
At the core of any microservice oriented system is the Api Gateway. The gateway is in charge of forwarding requests from various clients to the correct microservice cluster. Furthermore, the gateway is in charge of routing the request to an individual service-instance.
Based on the context of the request and the architecture of your system, one client request may involve several requests to different microservices in the background. In this situation, you will write another module that performs api composition, in which you call the desired microservice apis, then aggregate and formulate the data for the desired response to the client. This notion of microservice dependencies can add to the complexity of a project, which is a downfall of distributed systems.
Note: If you're interested, one way to communicate between microservices in the same private network is through using Message Brokers, such as RabbitMQ.
Isn’t Microservice-Architecture the same as Service-Oriented Architecture (SOA)?
Not exactly.
Although they share similar attributes, here are the main differences that separate SOA and Microservices.
1) Deployment
SOA systems have a concept of an Enterprise Service Bus (ESB), which acts as a platform for connecting consumers to services via point-to-point connections. The ESB, by nature, couples the various services that compose a system, and can sometimes become a single point-of-failure that can disrupt deployment for all services. Since all services communicate via the ESB, if the communication bus becomes clogged or overloaded, all services are affected.
Meanwhile, Microservice-Architecture allows for each individual microservice to be deployed, decoupling dependencies between other services like in SOA. This decoupling allows for more deployments and less bottlenecks & points-of-failures. This also allows microservices to have higher fault-tolerance, due to its decoupled nature. Furthermore, the Api-Gateway of microservice architecture also differs from the ESB, as the gateway acts more or less as a router with minimum logic attached, adding further to Separation of Concerns principal.
2) Data Storage
In SOA, all services share the same data-storage, whereas in Microservices, each microservice can contain its own data-store. We will not discuss the pros/cons of each approach, but just note this is a major difference between the two paradigms.
3) Size
This one is easy. Microservices are simply smaller in scope than services in SOA, as they are only a small module that makes up a service.
If you’re still not convinced, visit here for more information regarding Microservices vs SOA.
References
Check these out for more information regarding microservices!