Monday, September 21, 2020

Orchestration and Chorography in Microservices

 Both Orchestration and Choreography are used for Inter Service Communication (ISC) in microservices.

 Example use case - When an order is completed, an invoice should be generated for the order items.

Orchestration:

  • One central service controls entire business transactions
  • Its ideal for synchronous Inter Service Communication
  • Tightly coupled - All the integration logic exists in a single Orchestration service (Often called as God object)
  • Easier to Rollback business transaction

 

Solution: OrderOrchestration service  to invoke OrderService.CompleteOrder() first, followed by Invoiceservice.GenerateInvoice(). Here entire integration logic present at the OrderOrchestrationService.

 

Choreography 

  • Suited for asynchronous Inter Service Communication
  • Loosely coupled
  • This is implemented using event based architecture (Example: Apache Kafka/Azure Event Hub). Microservices can be configured as both publisher and subscriber of events.
  • Harder to Rollback business transactions

 

Solution - Order Microservice can publish an OrderCompleted event to Event Hub. An Invoice Microservice can be subscribed to this event and can generate invoice based on the subscribed events.

Friday, September 4, 2020

Cross cutting concerns in Microservices Architecture

 Here's the list of cross cutting concerns/Common platform services:

  1. Logging & Tracing
  2. Exception Handling
  3. Caching
  4. Swagger documentation
  5. Health Check
  6. Dapper
  7. ISC (Inter service communication)
  8. Resilience
  9. Email
  10. KeyVault

 

Notes:

Logging & Tracing - Azure Application Insights

Caching - Azure cache for Redis

Swagger - Swashbuckle & ASP.NET Core

Health Check - in ASP.NET Core (HealthStatus.Healthy, Unhealthy, Degraded)

Dapper - Micro ORM for Azure SQL

ISC - Inter service communication  (HttpClient.GetAsync(url))

Resilience - Circuit breaker/polly framework

Email - SendGrind

KeyVault - Azure Key Vault


Sunday, June 14, 2020

When will you go for microservice & when will you go for monoliths?


If your company does not have appetite for below, then do NOT go for microservices

  • Rapid provisioning (Infrastructure)
  • Basic monitoring
  • Rapid application deployment (deployment as well as rollback)
  • DevOps culture

Another very important point is, if you cannot define the service boundary right at first place, then it will be very difficult to fix later in microservices.

Disadvantages of Microservice


Complexity – Microservices are distributed systems. Application needs to make remote calls. And remote calls tends to fail. This brings in complexity.

Consistency – Each microservices has its own data store. Hence only eventual consistency is possible.

Transactions – Managing transactions needs additional efforts.

Domain boundary – If you have defined the domain boundary (bounded context in DDD) wrong in first place, then it’s very difficult to fix in Microservice.

Advantages of Microservice


Scalability – It’s easy to scale in or scale out services depending on business need. Also doesn’t have to scale the entire application.

Availability – even if one service is down, application can be functional.

Partial deployment – it’s possible to deploy changes to specific to a microservices. This is faster compared to deploying the entire application.

Independently upgradable – each microservices are like components, it’s possible to independently upgrade or replace them.

Multiple platforms/technology - software development can be done using different technologies.