Febin's Knowledge Garden

Appearance

Microservices Architecture ​

What is a Microservice?

Pasted image 20240825002823.png

  • The microservices architecture style is an ecosystem made up of single-purpose, separately deployed services that are accessed typically through an API gateway.
  • Client requests originating from either a user interface (usually a microfrontend) or an external request invoke well-defined endpoints in an API gateway, which then forwards the user request to separately deployed services.
  • Each service in turn accesses its OWN data (not to be confused with database), or makes requests to other services to access data the service doesn’t own.
  • Pasted image 20240824233045.png
  • Although each service is shown as having it's own database, this is not the case in most cases.
    • Services own it's own collection of tables, usually in the form of a schema, and is housed in a single highly-available database or a single database devoted to single domain.
    • Only the service can access it's own data. If another service requires access, it should call the respective service.
    • Bounded Context
  • The primary job of the API gateway in microservices is to hide the location and implementation of the corresponding services that correspond to the API gateway endpoints.
  • The API gateway can also perform cross-cutting infrastructure-related functions, such as security, metrics gathering, request-ID generation etc.
  • The API gateway does not contain any business logic nor does it perform any orchestration or mediation. This is critical to preserve Bounded Context.
  • Because microservices tend to be single-purpose functions, it’s not uncommon to have hundreds to even thousands of separately deployed microservices in any given ecosystem or application context.
  • The sheer number of separate services is what makes microservices so unique.
  • Microservices can be deployed as containerized services (such as Docker) or as serverless functions.
  • Applications that are well suited for the microservices architecture style include those that consist of separate and distinct functions within a business workflow.

Pros:

Cons:

  • If the data is highly coupled or if the services are very interdependent, this architecture might not suit the needs.
  • Complex: defining the single responsibility is subjective, as well as defining bounded context.
  • Expensive
  • Performance hits:
    • Since services require communication between each other, and since communication is remote, three types of latencies occur: network latency, security latency, and data latency.
    • Network latency is the amount of time it takes packets of informa tion to reach the target service over the network
    • Security latency is the amount of time it takes to authenticate or authorize the request to the remote endpoint.
    • Data latency impacts the performance aspects of microservices the most. Data latency is the amount of time it takes for other services to query data on your behalf that you don’t own.

Unique Features ​

The three things that make the microservices architecture style so unique are distributed data, operational automation, and organizational change.

Distributed Data ​

Only architecture that requires data to be broken up and distributed across separate services. This is because of the single-responsibility nature and the large number of services deployed.

Operational Automation ​

It is not humanly possible to manage the parallel testing, deployment, and monitoring of several hundred to several thousand separately deployed units of software. For this reason, containerization is usually required, along with service orchestration and management platforms such as Kubernetes. This also leads to the requirement of DevOps for microservices Teams own services and the corresponding testing and release of those services

Organizational Change ​

Microservices is the only architecture style that requires development teams to be organized into domain areas of cross-functional teams with specialization.

Bounded Context in Microservice Architecture ​

Microservices as an architecture style wouldn’t exist without the notion of a bounded context.

Imagine 250 microservices all accessing the same set of tables in a monolithic database. Suppose you make a structural change (such as dropping a column or table) that 120 of those services access. This change would require the coordination of modifying, testing, and deploying 120 separate services at the same time, along with the database change. This is a scenario that is simply not feasible..

Bounded context makes Microservice Architecture Agile. When a structural change happens, only the service owning the data needs to be changed.

Other services requiring access to data within another bounded context must ask for the data through a separate contract. This contract is usually a different representation than that of the physical database structure of the data, thereby usually not requiring a change to other services or the contracts.

Although bounded context is a main goal of this architecture, this rarely happens in real world applications. Sharing data is required for foreign key constraints, table coupling, triggers between tables, views as well as performance benefits while accessing data. When data is shared between services, the bounded context is extended to include all of the shared tables as well as all of the services that access that data.