Skip to main content

Microservice Architecture

What are Microservices?​

  • Small Services
  • Running in its own process
  • Communicating with APIs
  • Independently deployable
  • Different programming languages
  • Own Technology Stack
  • Decouple microservices with bounded context (DDD)

Microservices Characteristics​

  • Small, independent, and loosely coupled
  • Separate codebase
  • Deployed independently
  • Persisting their own data
  • Well-defined APIs
  • Technology agnostic

By Martin fowler

  • Componentization via Services
  • Organized by Business Capabilities
  • Product not Projects
  • Smart endpoints and dumb pipes
  • Decentralized Governance
  • Decentralized Data Management
  • Infrastructure Automation
  • Design for Failure

Benefits of Microservices​

  • Agility
  • Small, focused teams
  • Small and separated code bases
  • Right tool for the Job
  • Adapting Technology changes
  • Scalability
  • Data Isolation

Challenges of Microservices Architecture​

  • Complexity
  • Network problems and Latency
  • Development and testing
  • Data integrity

Microservices Design Pattern​

The Database-per-Service Pattern​

  • Loose coupling of services
  • Own database
  • Polyglot persistence
  • Can't be accessed directly
  • Scale independently
  • Data encapsulated within the service
  • Do not affect to other services

Decomposition Microservice Architecture​

Domain Analysis --> Bounded Context -->  Decompose Strategies --> Identify Microservice Boundaries

Microservices Decomposition Pattern - Decompose by Business Capability​

Some prerequisite are;

  • Services must be Cohesive
  • Services must be Loosely Coupled
  • Corresponding to Business Capabilities
  • Business Capability

Microservices Decomposition Pattern - Decompose by Subdomain​

  • Services must be Cohesive
  • Services must be Loosely Coupled
  • Domain-Driven Design(DDD) Subdomains
  • The business- as the domain

Bounded Context Pattern (Domain Driven Design - DDD)​

DDD deals with larger models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

  • DDD - Bounded Context
  • Domains are required high cooperation
  • Strategic and Tactical DDD
  • Grouping of closely related scopes
  • Logical boundaries have common business rules

Identify Bounded Context Boundaries for each Microservices

  • DDD-Bounded Context
  • Context Mapping Pattern
  • Context Mapping
  • Define logical boundaries between domains
  • Talking to the domain experts
  • Change to the boundaries
  • Reshape your Bounded Contexts
  • Consider Refactorings

Using Domain Analysis to Model Microservices

  • Domain Analysis
  • Designed by business Capabilities
  • Loose coupling and autonomous services
  • DDD-Bounded Context following Context Mapping Pattern and decompose by sub domain model patterns

Understanding Domain & Identifying Microservices​

  • Use Cases
  • Functional Requirements
  • Follow Steps:
    • Requirements and Modelling
    • Identify User Stories
    • Identify the Nouns in the User stories
    • Identify the verbs in the User stories
    • For example
      • As a user I want to list products
      • As a user I want to be able to filter products as per brand and categories
  • Create object interaction diagram connecting nouns with verbs
  • Identify all the microservices by interaction diagram
  • Next, try to identify the Sync case and Async Case microservices

Microservices Communications​

  • Monolithic = inter-process
  • Microservices = inter-service communication
  • Distributed network calls
  • HTTP, gRPC or message brokers AMQP protocol
  • Synchronous or Asynchronous

Synchronous or Asynchronous communication​

Synchronous Communication

  • Inter-Service communication
  • Distributed Network calls
  • HTTP, gRPC protocols
  • Synchronous Request/Response
  • REST APIs

Asynchronous Communication

  • Not wait response and not have blocked a thread
  • AMQP (Advanced Messaging Queuing Protocol)
  • One-to-one (Queue)
  • one-to-many (Topic)
  • publish/subscribe
  • Event-driven microservices architecture

Microservices Communication Type​

  1. Request/Response type (HTTP/gRPC)
  2. Evented (pub/sub)
  3. Hybrid (both)

Designing HTTP based RESTful APIs for Microservices​

  • REST APIs for HTTP verbs like, GET, POST, PUT, FETCH
  • Creating APIs for our microservices
  • Design Microservice APIs
    • User REST APIs for HTTP
    • Avoid chatty calls
    • Two type of APIs, Public APIs and Backend APIs
    • REST vs gRPC protocols
    • Features of REST (Representational State Transfer)
      • Stateless
      • Uniform Interface
      • Cacheable
      • Client-Server
      • Layered System
      • Code on Demand
    • Richardson Maturity Model for REST APIs
      • Level 0: Define one URI
      • Level 1: Create separate URIs
      • Level 2: Use HTTP methods
      • Level 3: Use Hypermedia
    • API Versioning

What is gRPC?​

A high performance, open-source universal RPC framework

  • gRPC (gRPC Remote Procedure Calls)
  • HTTP/2 protocol to transport binary messages
  • Protocol Buffers, also known as Protobuf files
  • Crose-platform client and server bindings

How gRPC works

  • gRPC directly calls a method on a server
  • Build distributed applications and services
  • Defining a service that specifies methods that can be called remotely
  • Can be written in any language that gRPC supports

Advantages of gRPC

  • Using HTTP/2
  • Binary serialization
  • Supporting a wide audience with multi-language/platform support
  • Open Source and powerful community behind it
  • Supports Bi-directional Streaming operations

gRPC vs REST​

gRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload. This is mainly due to the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC.

gRPC usage of Microservices Communication​

  • Synchronous backend microservice-to-microservice communication
  • polyglot environments
  • Low latency and high throughput communication
  • Point-to-point real-time communication
  • Network constraints environments
  • Example
    • API Gateway --> shopping aggregator MS with gRPC client 
                                      - --> ordering MS with gRPC server 
                                      - --> Basket MS with gRPC serve 
                                      - --> Catalogue MS with gRPC server

API Gateway Patterns​

  • Handles Cross-cutting concerns

  • Routing to internal microservices

  • Aggregates several Microservices 3 main pattern = API Gateway

  • Gateway Routing Pattern

    • Route requests to multiple microservices
    • Exposing a single endpoint
    • Layer 7 routing
    • Protocol Abstractions
    • Centralize Error management

  • Gateway Aggregation pattern

    • Aggregate multiple internal requests
    • Different backend microservices
    • Manage direct access services
    • Reduce chattiness communication
    • Dispatches requests

  • API Gateway Patterns

    • Complex large microservices based applications
    • Facade pattern
    • Reverse Proxy or gateway routing
    • Routing requests from client backend-services
    • Singel-point-of-failure risk

    Main features in API Gateway Pattern

    • Gateway Routing
    • Requesting Aggregation
    • Service Discovery with Consul & Eureka
    • Load Balancing
    • Correlation Pass-Through
    • Quality of Service
    • Authentication
    • Authorization
    • Throttling
    • Logging, Tracing
    • Headers/Query String Transformation
    • Custom Middleware

Backends for Frontends pattern​

  • Improvement on API Gateway Patters by removing Singla Point of Failure
  • It uses separate API gateways
  • API Gateway for handling to routing and aggregate operations
  • Grouping the client applications
  • Avoid Bottleneck of 1 API Gateway
  • Several API gateways as per user interfaces.

Service Aggregator Pattern​

  • Minimize service-to-service communications
  • Receives a request from API Gateway
  • Dispatches requests of multiple internal backend microservices
  • Combines the results
  • Used to reduce latency when service to service communication is required.

Service Registry Pattern​

  • Microservices Discovery Patterns
  • Register and discover microservices
  • Microservices should be register to service Registry
  • Finds the location of microservices

Asynchronous message-based communication​

  • Multiple microservices are required to interact each other
  • Without any dependency or make loosely coupled
  • one-to-one or one-to-many asynchronous based communication
  • Event Driven Architecture, CQRS pattern, Event Storing, event consistency principles

Dependency Inversion Principles (DIP)​

What is Apache Kafka​

  • Open-source event streaming platforms
  • Horizontally scalable, distributed, and fault-tolerant
  • Distributed publish-subscribe

Apache Kafka Benefits and use cases​

  • Reliability, Scalability, Durability, Performance

  • Built-in partitioning, replication and fault tolerance

    Use Cases

    • Messaging
    • Metrics
    • Log Aggregation
    • Stream processing
    • Activity Tracking
    • Event Sourcing

Kafka components - Topic, Partition, offset, Replication factor​

  • Topic : message an event are stored in topics, grouping the message,
  • Partition : topic is divide into partitions. Each partition is a log file, it is like a directory.
  • Offset : unique sequence Id of the message

Apache Kafka Cluster Architecture​

Kafka Brokers - Kafka Cluster

  • Multiple brokers exist in a single cluster
  • Data replication, fault tolerance, and high availability of you Kafka Cluster
  • Multiple brokers to maintain load balance

Zookeeper

  • Manager and maintenances for Kafka cluster
  • Coordinating Kafka brokers
  • Kafka Cluster master-less architecture
  • Follows the brokers in the cluster
  • Takes care about broker lifecycle

Apache Kafka core APIs - Producer, Consumer, Streams, and Connect API​

  • Producers API : Producers push data to brokers
  • Consumer API - Subscribe to topics and process the streams of data
  • Stream API - Transforming the input streams to output streams
  • Connect API - Configure connectors to move data into Kafka of from Kafka

What is RabbitMQ?​

  • Message Queue System
  • Used in EDA
  • Similar to Kafka, MSMQ, ActiveMQ etc.

RabbitMQ Exchange Types

  • PRODUCER publish message to --> EXCHANGE routes to --> QUEUE pushes message to --> CONSUMERS.
  • Ther are 4 exchanges type in RabbitMQ
    • Direct Exchanges
    • Topic Exchanges
    • Fanout Exchanges
    • Header Exchanges

RabbitMQ Architecture

  • Producer can only send message to an exchange
  • Exchange controls the routing of messages
  • RabbitMQ uses a push model
  • Distribute messages individually and quickly

Scale the Microservice Architecture Design​

The Scale Cube​

3 dimensions to scaling

  • X-Axis : Horizontal duplication and cloning of services and data
  • Y-Axis : Functional Decomposition and segmentation - microservices
  • Z-Axis : Service and Data Partitioning along customer Boundries - shards/pods

CQRS​

TODO

Event Sourcing pattern​

  • CQRS with event sourcing pattern
  • Source-of-truth events database
  • Materialized views of the data with denormalized tables
  • Publish an update event with using message broker systems
  • Consume by the read database and sync data Materialized view pattern
  • Read database eventually synchronizes with the write database
  • Changing to data save operations
  • Save all events into database with sequential ordered of data events
  • Append each change to a sequential list of events
  • Event Store becomes the source of truth for the data
  • Publish/subscribe pattern with publish event
  • Replay events to build latest status of data

Eventual Consistency Principle​

  • For systems that prefer high availability to instance consistency
  • Become consistent after a certain time
  • Does not guarantee instant consistency
  • Consider the "consistency level"
  • Strict consistency of Eventual consistency

Microservices Distributed Transactions​

Saga Pattern for Distributed Transactions​

  • Manage data consistency across microservices in distributed transaction cases
  • Create a set of transactions that update microservices sequentially
  • Publish events to trigger the next transactions
  • if failed, trigger to rollback transactions
  • Grouping these local transactions and sequentially invoking one by one
  • Saga patters are implemented using two ways
    • Choreography
    • Orchestration

Choreography

  • Coordinates sagas with applying publish and subscribe principles
  • Each microservices run its own local transaction
  • Publish events to trigger the next transaction
  • Workflow steps increase, then it can become confusing and hard to manage transaction
  • Decouple direct dependency

Orchestration

  • Coordinates sagas with a centralized controller microservice
  • Invoke to execute local microservices transactions in sequentially
  • Execute sage transaction and manage them in centralized way and if one of the step is failed, then executes rollback steps with compensating transactions.
  • Good for complex workflows which includes lots of steps.
  • Though it's single point of failure

The outbox pattern​

  • When your API publishes event messages, it doesn't directly send them
  • The message are persisted in a database table, a job publish events to message broker system
  • Provides to publish events reliably with written to a table in "outbox" role
  • The event and the event written to the outbox table are part of the same transaction

Why we use Outbox Pattern?

  • Working with critical data that need to be consistent
  • Ned to accurate to catch all requests
  • The database update and sending of the message should be automatic
  • Provide data consistency
  • Example - Financial business sale transactions.
  • increases the complexity

Event-Driven Microservices Architecture​

  • Communication with microservices happens via event messaging
  • Publish/subscriber pattern and Kafka message broker systems are used to implement it.
  • By nature it is a type of Asynchronous behaviour and loosely coupled
  • Real-time messaging platforms, stream-processing, event hubs, real-time processing, batch processing, data intelligence.

Microservices Distributed Caching​

  • Caching makes application faster
  • Increase performance, scalability, and availability
  • Reducing latency with cache when reading data
  • Avoid re-calculation processes
  • The distributed cache increases system responsiveness by returning cache data
  • Separating the cache server scale independently

Microservices Deployments with Containers and Orchestrators​

  • Monolithic deployment problems: single unit of deploy whole application
  • Container provide to decouple applications with all dependencies and isolate applications
  • With containers, microservices can be deployed separately in a container
  • New features can be applied and rollback very easy with container deployment
  • Docker is defacto standard for containerization of microservices
  • Containers need to orchestrate in order to manage lots of container in your application cluster
  • Orchestrators automates the deployment, scaling, and operational concerns of containerized workloads across clusters
  • Kubernetes is defacto standard for orchestration of microservices.

What is Docker and Containers?​

  • Developing, Shipping, and running applications
  • Reduce time to production
  • Run anywhere
  • Container packages code and dependencies Basic taxonomy in Docker
  • Registry - Stores many static images
  • Images - static, persisted container image
  • Container image-instance running an app process(service/web)
  • Docker Application Containerization
    • Dockerfile build --> Docker Image run --> Docker Container

What is Kubernetes?​

  • Kubernetes also known as k8s for kube
  • Open-source container orchestration platform
  • Automates many of the manual processes
  • Deploying, managing, and scaling containerized applications
  • K8s Components
    • Pods
    • ReplicaSet
    • Deployments
    • Deployments > ReplicaSet > Pod
    • Service
    • ConfigMap - secret