Microservice

Table Of Content

• Monolithic vs Microservice
• Strangler Pattern
• Clean Architecture
• 12 Factor App

Intermezo

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin urna odio, aliquam vulputate faucibus id, elementum lobortis felis. Mauris urna dolor, placerat ac sagittis quis.

Monolitik

Monolitik adalah suatu arsitektur aplikasi berupa 1 codebase yang memiliki banyak modul dimana setiap modul memiliki fungsi yang berbeda beda.

Tantangan Monolitik

• Semakin besar codebase semakin kompleks dan susah untuk dipelajari, terutama untuk developer baru
• Semakin susah untuk melakukan scaling
• Susah untuk mengadaptasi tekonlogi baru karena jika ingin mengadaptasi harus mengubah keseluruhan kode.
• Git Conflict
• Database yang besar

Microservice

Microservice adalah suatu arsitektur aplikasi dimana setiap aplikasi memiliki codebase yang kecil dan hanyak memiliki 1 tujuan.

Ciri Khas Microservice

• Services are small, independent, and loosely coupled.
• Encapsulate a customer or business scenario.
• Each service is a separate codebase, which can be managed by a small development team.
• Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire system.
• Services are responsible for persisting their own data or external state.

This differs from the traditional model, where a separate data layer handles data persistence.

• Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.
• Services don’t need to share the same technology stack, libraries, or frameworks (hybrid technologies).

Keuntungan Microservice

• Independent deployments.

You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. Bug fixes and feature releases are more manageable and less risky.

• Independent development.
• Small, focused teams.
• Fault isolation.

If a service goes down, it won’t take out the entire application. However, that doesn’t mean you get resiliency for free. You still need to follow resiliency best practices and design patterns. See Designing resilient applications for Azure.

• When change is required in a certain part of the application, only the related service can be modified and redeployed — no need to modify and redeploy the entire application.
• The developers can make use of the latest technologies.
• Mixed technology stacks (hybrid technologies).

Teams can pick the technology that best fits their service.

• Granular scaling.

Services can be scaled independently. At the same time, the higher density of services per VM means that VM resources are fully utilized. Using placement constraints, a services can be matched to a VM profile (high CPU, high memory, and so on).

Tantangan mengadopsi microservice

• Model services around the business domain.
• Decentralize everything.

Individual teams are responsible for designing and building services. Avoid sharing code or data schemas.

• Data storage should be private to the service that owns the data.

Use the best storage for each service and data type.

• Services communicate through well-designed APIs.

Avoid leaking implementation details. APIs should model the domain, not the internal implementation of the service.

• Avoid coupling between services.

Causes of coupling include shared database schemas and rigid communication protocols.

• Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.
• Keep domain knowledge out of the gateway.

The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Otherwise, the gateway becomes a dependency and can cause coupling between services.

• Services should have loose coupling and high functional cohesion.

Functions that are likely to change together should be packaged and deployed together. If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

• Isolate failures.

Use resiliency strategies to prevent failures within a service from cascading. See Resiliency patterns and Designing resilient applications.

Komunikasi di Microservice

API Gateway

• Model services around the business domain.
• Decentralize everything.

Individual teams are responsible for designing and building services. Avoid sharing code or data schemas.

• Data storage should be private to the service that owns the data.

Use the best storage for each service and data type.

• Services communicate through well-designed APIs.

Avoid leaking implementation details. APIs should model the domain, not the internal implementation of the service.

• Avoid coupling between services.

Causes of coupling include shared database schemas and rigid communication protocols.

• Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.
• Keep domain knowledge out of the gateway.

The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Otherwise, the gateway becomes a dependency and can cause coupling between services.

• Services should have loose coupling and high functional cohesion.

Functions that are likely to change together should be packaged and deployed together. If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

• Isolate failures.

Use resiliency strategies to prevent failures within a service from cascading. See Resiliency patterns and Designing resilient applications.

Strangler Pattern

Strangler Pattern adalah suatu metode migrasi arsitektur monolitik ke microservice dengan cara mengganti suatu fungsi atau module tertentu dengan service baru yang berdisi sendiri diluar codebase induknya.

Clean Architecture

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin urna odio, aliquam vulputate faucibus id, elementum lobortis felis. Mauris urna dolor, placerat ac sagittis quis.

12 Factor App

• Bullet One
• Bullet Two
• Bullet Three