Microservices

Microservices

Subset of Service Oriented Architecture (SOA) where each service is deployed separately:

  • Microservices can be physically separated and independently deployed.
  • Each have its own data store.
  • Independent and self governing.
  • Communication is syncronous or asyncronous (e.g., through messaging systems).
  • Loose coupling between components (more or less by experience but that is design flaw likely :thinking:).
  • Shorter development and release cycles.
  • Each scale independently (either through physical or virtual machines).

Advantages #

  • Deployed/Scaled as needed.
  • Increase availability due to reduced single point of failures.
  • Better isolation leading to less couling giving flexibility.
  • Supports multiple platforms and languages.
  • More indepentent
  • Shorter cycles

Mention that cross team coordination become less necessary. That is true but often it still is and requires coordination.

Disavantages #

  • Require multiple complex deployment nad monitoring approaches.
  • Cross service refactors are more challenging.
  • Require supporting old versions.
  • Organization Change

Designing one #

Business domains are typically large and complicated. Several ideas, actions and rules interact with one another in complex ways. A good approach on understanding such complex systems and how to model them is through a process named Domain Driven Design .

A correct separation of concerns (i.e., clear and single responsibilities) leads to smoother workflows. Awkarwdness when modelling may indicate lack of understanding of the domain.

Principles of Isolation #

State #

All access must go thorugh the API and there is no backdoors. Allows internal changes without affecting others.

Space #

Should not care where the other services are deployed. Allows microservices to be scaled up or down to meet demands. However, if latency is an issue, they should be in the same region.

Time #

Should not wait for each other which allows more efficient use of resources. Resources can be freed immediatly, rather than waiting for a request to finish.

Between microservices we expect eventual consistency. It improves scalability as total consitency requires central coordination which hindes scalability.

NOTE: This is discussible. However it may be a implementation details.

Failure #

Isolate failures and should not cause failure on other systems. I.e., it still is responsive to attend other use-cases.

Isolation Techniques #

Bulkheading #

Failures are isolated to failure zones. Failures in one service will not propagate to other services. Overall the system remains operation but possibly in a degraded state.

In practice it means that that systems that depend on the service that is considered a failure zone, will mark that information or service as unavailable. IMO this is tolerable if the service is non-critical.

Circuit Breaker #

When a service is under stress we do not want to keep on retrying as it may make things worse.

Way to avoid overloading a service. They qaurantine a failing service so it can fail fast. Allows the failing service to recover in its time before they fail.

Types:

  • Closed - Normal Operation
  • Open - Fail fast
  • Half Open - Internally after a timeout will let one request to go through and if it fails, it goes back to Open.

Transitions:

  • Closed (normal) -> Trip: Open (Fail Fast)
  • Open (Fail fast) -> Attempt Reset: Half Open
  • Half Open -> Trip: Open (fail Fast)
  • Half Open -> Reset: Closed (Normal)

Message Driven Architecture #

  • Async and non blocking messages allows decoupling both time and failure.
  • System do not depend on the response from on another.
  • If a request to a service fails, the failure will not propagated.
  • The client service isn’t waiting for response. It can continue to operate normally.

Autonomy #

Services can operate independently from each other.

Autonomous services have enough information to resolve conflicts and repair failures. This means that they do not require other services to be operational all the time. Ideally all the time but in reality for a short time it guarantees some level of autonomy.

Benefits:

  • Stronger scalability and availability.
  • Can be scaled indefinetly.
  • Operate independently.

How:

  • Async messages.
  • Maintain enough internal state ofr the microservices to function in isolation.
  • Use eventual consistency.
  • Avoid direct, syncronous dependencies on external services.

API Gateway Services #

Microservices can lead to complexity in the API. How can we manage complex APIs that access many microservices?

A new microservice that is put between the client and the N-services that are required to fulfill that request. This new microservice is responsible for aggregating the responses moving the responsbility from the client itself. This way, the client only needs to manage failures from the gateway.

This effectively creates an additional layer of isolation.

!! This is specially useful for mobile applicatios where we cannot guarantee that the clients will update their app.