Understanding Microservices
Fundamentals of System Design Chapter 13: Microservices
What are Microservices?
Have you ever wondered why companies like Amazon, Google and Netflix seem to roll out features at the speed of light? The secret might be hidden in their tech stack based on the Microservice architecture.
A microservice is a small, loosely coupled service that is designed to perform a specific business function and each service can be developed, deployed and scaled independently.
How Microservices work
Robert C. Martin, coined the term single responsibility principle which states that “gather together those things that change for the same reason, and separate those things that change for different reasons.”
Microservices architecture takes the same approach by breaking down software as a collection of small independent services that communicate with each other over a network. These services communicate via lightweight protocols such as REST APIs or messaging systems like RabbitMQ. Each service manage it’s own database. This approach enables different teams to develop the services concurrently, using different technologies for their needs.
What are the main components of a Microservice?
1. API Gateway - This is a single entry point for all client requests to interact with multiple services. API gateways simplifies interactions with a system and handles routing, load balancing, rate limiting, authentication etc.
2. Service Registry and Discovery - As the number of services in a microservices architecture grows, it can become challenging to manage and communicate between them. A service registry keeps track of all the addresses of all microservices. It enables them to locate and communicate with each other.
3. Load Balancer - A load balancer distributes incoming traffic across multiple service instances and prevents any of the microservices from being overwhelmed with requests.
4. Database - Each service has it’s own database. A decentralized data management ensures independent management and scaling.
5. Microservice - Small, loosely coupled services that handle specific business functions, each focusing on a distinct capability.
Difference between Monolith and Microservices architecture
A monolith application is the opposite of microservices as an application is tightly coupled into a single codebase that operates as a unified service. This design makes it challenging to implement changes without impacting the entire system, often resulting in a slower and less flexible development process. The table below compares Monoliths to Microservices.
| Aspect | Monolith | Microservices |
|---|---|---|
| Architecture | Single unit, tightly coupled components. | Modular, independent services. |
| Scalability | Scales as a whole application. | Independently scalable services. |
| Development Teams | Single team, often slower collaboration. | Multiple small teams working in parallel. |
| Technology Stack | Unified technology stack. | Flexible technology choices per service. |
| Deployment | Entire application deployed together. | Individual services deployed independently. |
| Resilience | Failure in one part can affect the whole system. | Failures are isolated to individual services. |
| Communication | Internal calls within the application. | API or messaging-based communication. |
| Data Management | Single shared database. | Each service has its own database. |
| Performance | Faster for simple applications. | More overhead due to inter-service communication. |
| Operational Complexity | Simpler to set up and manage. | Higher complexity in setup and management. |
Benefits of Microservices
1. Scalability - Microservices enables the scaling of specific parts of an application. Each service can be scaled independently based on it’s needs therefore optimizing resource usage.
2. Faster Development and deployment - Teams can develop, deploy and update services independently accelerating system delivery.
3. Flexibility in Technology - Teams can use different tools, languages, and frameworks for each service.
4. Ease of Maintenance - Small services that focuses to perform business functions are easier to understand, debug and maintain.
5. Resilience and Fault Tolerance - Any system failure can be isolated to individual services. If one microservice fails, the rest of the system can continue to function normally.
Challenges in Microservices
1. Complexity - The management of multiple independent services adds complexity in development, testing and deployment.
2. Inter-service Communication - Efficient inter-service communication is essential and can become a bottleneck without proper tools.
3. Compromised Security - Setting up access controls and implementing secure authentication for each service is not only challenging within a distributed framework but also increases the attack surface significantly.
4. Communication Challenges - Communication between teams becomes easy when using a monolithic app, but the scenario flips over completely in the case of microservices. he complexities in communication increase with the number of services in the microservices systems.
5. High Latency - Unlike monoliths, where communication happens within a single process, microservices rely on network calls (e.g., REST, gRPC). Each inter-service call introduces latency.
Conclusion
Microservices offer a robust approach to building scalable, flexible, and resilient systems, especially for large or rapidly evolving applications. Since Netflix announced they have 700 microservices running on their platform, more companies are eager to take advantage of them. However, many fail to notice that its not an appropriate solution for everyone. Below are scenarios on when to not use Microservices:
1. When you have a small team - It can be overwhelming for a small team to develop and maintain tens of microservices. This will cause a delay in the project as well as cost you efficiency.
2. When you have a small/simple app - We use microservices for large scale systems by breaking it down into multiple services. It doesn’t make sense to adopt the microservices architecture for small or simple applications.
3. When You Are Working On a Startup or a New Product - Building a new product requires constant changes through an iterative process. This happens since the imperfect idea needs to be polished and tested in the market for viability. It’s better to start with a modular monolithic approach.
Thank You!
I’d love to keep in touch! Feel free to follow me on Twitter at @codewithfed. If you enjoyed this article please consider sponsoring this blog for more. Your feedback is welcome anytime. Thanks again!
