MicroServices
Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs.
Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.
Characteristics
- Autonomous: Each component service in a microservices architecture can be developed, deployed, operated, and scaled without affecting the functioning of other services. Services do not need to share their code or implementation with other services. Any communication between individual components happens via well-defined APIs.
- Specialized: Each service is designed for a set of capabilities and focuses on solving a specific problem. If developers contribute more code to a service over time and the service becomes complex, it can be broken into smaller services.
Benefits
- Agility
- Flexible Scaling
- Easy Deployment
- Technological freedom
- Reusable Code
- Resilience: Service independence increases an application’s resistance to failure. In a monolithic architecture, if a single component fails, it can cause the entire application to fail. With microservices, applications handle total service failure by degrading functionality and not crashing the entire application.
Challenges and Disadvantages
- Complexity: Services are simpler in microservices, but the whole system is more complicated. You need to take care of all the services and the database, and you need to deploy each of the services independently.
- Testing: You need a different approach to write small services that rely on other dependent services. This is different from traditional monolithic or layered applications. Writing tests will be more complex if services are dependent on each other. To unit test, a dependent service mock must be used.
- Data Integrity: Microservice supports distributed database architecture. Each service in the microservice is responsible for its own data persistence. Data integrity or data consistency can be a challenge in these situations. You may have to update multiple business functions of the application for some business transitions. For different services, you may have to update multiple databases. You will have to set up eventual consistency of data with more complexity.
- Network Latency: Many small services in Microservice require more interservice communication. If services in microservice will have a long chain of dependencies then additional latency can become a problem for you. You will have to design the APIs carefully.
- Versioning: If a service needs to get updated, it shouldn’t break the service that depends on it. If multiple services need to be updated at the same time then without careful design you may face some problems with backward or forward compatibility.
- Debugging: Remote debugging through your local integrated development environment (IDE) isn’t an option and it won’t work across dozens or hundreds of services. Unfortunately, there’s no single answer to how to debug at this time.
- Logging: With distributed systems, you need centralized logs to bring everything together. Otherwise, the scale is impossible to manage.
Implement Microservice
Containers and Kubernetes:
- A container is a unit of software in which application code is packaged alongside all of the files necessary to make it run. This organization makes it easy to move the contained application between environments while retaining full functionality.
- Kubernetes is a container orchestration platform that allows for single components within an application to be updated without affecting the rest of the technology stack, which makes it perfect for automating the management, scaling, and deployment of microservices applications.
APIs:
- An application programming interface, or API, is the part of an application that is responsible for communicating with other applications. Within the infrastructure of microservices architecture, APIs play the critical role of allowing the different services within a microservice to share information and function as one.
Event streaming:
- An event can be defined as anything that happens within a microservice service. For example, when someone adds something to their online shopping cart or removes it.
Best Practices
- You can model the services around the business domain
- We have discussed that individual teams are assigned to specific services, so there is no need to share the code or data schemas.
- For each service, data storage should be private. You need to use the best storage for each service and data type.
- Each service in microservice should communicate through well-designed APIs. Implementation details shouldn’t be leaked.
- Coupling should be avoided between the services. The coupling has various causes including shared database schemas and rigid communication protocols.
- You should keep domain knowledge out of the gateway. Routing of client requests should be handled without the knowledge of business rules or domain logic. This should be taken care of very carefully, or you will be facing a coupling problem between the services.
- There should be loose coupling and high functional cohesion between the services. Functions that change together should be packaged and deployed together. If the functions reside in separate services then this should end up being tightly coupled. Updating one service requires updating the other service.
Why MicroServices?
With monolithic architectures, all processes are tightly coupled and run as a single service. This means that if one process of the application experiences a spike in demand, the entire architecture must be scaled. Adding or improving a monolithic application’s features becomes more complex as the code base grows. This complexity limits experimentation and makes it difficult to implement new ideas. Monolithic architectures add risk for application availability because many dependent and tightly coupled processes increase the impact of a single process failure.
With a microservices architecture, an application is built as independent components that run each application process as a service. These services communicate via a well-defined interface using lightweight APIs. Services are built for business capabilities and each service performs a single function. Because they are independently run, each service can be updated, deployed, and scaled to meet demand for specific functions of an application.
How does MicroService communicate?
- HTTP/HTTPS
- Message Queues
- gRPC
- Web Socket
- Service Mesh
- REST clients
- Database Communications
- Event Sourcing
- Direct Service-to-Service calls
- GraphQL
- Peer-to-Peer
How does the Monolith communicate?
- In-Memory Calls
- Shared Memory
- Database
- Inter-Process Communication
- Event or Message Driven
