Microservices architecture is made up of a collection of tiny, self-contained services. Each service is self-contained and should only execute a particular business feature inside a limited environment.
A bounded context is a natural split within a business that gives an explicit boundary for a domain model to reside within.
What Exactly Are Microservices?
Microservices are tiny, self-contained, and loosely connected applications. A service can be written and maintained by a small team of developers.
Each service has its codebase, which is manageable by a small development team.
Services can be launched on their own. An existing service can be updated without rebuilding and redeploying the complete application.
Services are in charge of preserving their data or external state. This varies from the conventional architecture, in which a distinct data layer handles data persistence.
Services connect using well-defined APIs. Each service's internal implementation details are concealed from other services.
Polyglot programming is supported. Services, for example, do not have to use the same technology stack, libraries, or frameworks.
Aside from the services themselves, the following components may be found in a typical microservices architecture:
- Management/ Orchestration: This component is in charge of deploying services to nodes, detecting errors, rebalancing services across nodes, etc. Rather than being specially designed, this component is often an off-the-shelf solution like Kubernetes.
- Gateway for APIs: Clients enter through the API gateway. Clients call the API gateway rather than the services directly, and it redirects the call to the necessary assistance on the back end. The following are some of the benefits of using an API gateway:
- It untethers clients from services. Services can be versioned or refactored without requiring all clients to be updated.
- Services may employ non-web-friendly message protocols such as AMQP.
- Other cross-cutting services that the API gateway may perform include authentication, logging, SSL termination, and load balancing.
- Benefits/ Agility: Because microservices are delivered autonomously, bug fixes and feature releases are easier to handle. You can update a service without reinstalling the entire program, and you can undo an update if something goes wrong. When a flaw is discovered in one section of a conventional program, it might halt the entire release process.
- Small, concentrated groups: A microservice should be small enough to be built, tested, and deployed by a single feature team. Smaller squad sizes allow for better maneuverability. Large groups are less productive because communication takes longer, management overhead increases, and agility decreases.
- The codebase is small: Code dependencies in a monolithic program tend to grow entangled over time. Adding a new feature necessitates touching code in several places. A microservices design reduces dependencies by not sharing code or data storage, making it easier to add new features.
- Combination of technology: Teams can select the technology that best matches their service, employing a variety of technology stacks.
- Isolation of faults: If a single microservice fails, the entire application will not be disrupted as long as any upstream microservices are built to handle failures effectively (for example, by implementing circuit breaking).
Scalability: Services may be scaled individually, allowing you to scale out resource-intensive subsystems without scaling out the entire application. Using an orchestrator like Kubernetes or Service Fabric, you may pack a larger density of services onto a single host, allowing for more effective resource use.
