Microservices: Designing Highly Scalable Systems

 

Design patterns for data management:

·       CQRS (Command Query Responsibility Segregation) – i.e the command and query operations should be separated out (Updating and reading from DB segregated)

·       Event sourcing – defines an approach where all changes made to an object are stored as a sequence of immutable events to an event store. The event store provides a log of every state change, creating an audit trail of the entire system

·       Saga pattern – a distributed transaction is a DB transaction involving more than one network host. A DB transaction should either commit or rollback. Saga pattern provides solution for implementing transactions in the form of saga that spans across more than one microservice. A saga defines a sequence of local transactions. where each participating microservice executes one or more local transactions and then publish an event that is used to trigger the next transaction in a saga that resides in a different microservice. When one transaction in the sequence fails, the saga executes a series of compensating transactions to undo the changes that were made by the preceding transactions.

 

Success factors of Micro service architecture:

·       Logging (of exceptions, all requests and responses including HTTP code, response time, events, all login tokens and access tokens)

·       Monitoring and alerting (uptime and average response time of microservices, resource consumption and success/failure ratio of m.services, access frequency of client requests, infrastructure dependencies i.e. whether the infrastructure is capable of handling requests)

·       Documentation (API documentation, design documentation i.e. business logic design, documentation of dependencies, network and port allocations)

 

Deployment and infrastructure:

·       Containerization (create a container image, the image becomes a container at the runtime, container orchestration i.e. automation of tasks of deployment , rescheduling, scaling and loading, resource allocation etc.,

 

Tools to build microservices

·       Frameworks – Spring Boot, .NET Core framework, Grails framework, Eclipse , Helidon

·       Container technologies – Docker, CoreOS’ rkt, LXC, OpenVZ, containerd

·       Orchestration engines - Kubernetes, Docker Swarm, OpenShift, Cloud Foundry’s Dirego, CoreOS Fleet, Amazon ECS, Azure Kubernetes Service

·       Service Discovery (to locate and communicate services) – Consul, Apache Zookeeper, Eureka by Netflix, SmarStack, SkyDNS

·       API Gateways – Kong, Ambassador, Ocelot, Tyk, Amazon AWS API Gateway, Azure Application Gateway, Spring Cloud Gateway

·       Event Bus tools – Kafka, RabbitMQ, Azure Service Bus, Aamzon SQS, Google Cloud Pub Sub

·       Logging tools – Fluentd, Graylog, Kibana, Logstash, Bunyan, Suro

·       Monitoring tools – Grafana, Prometheus, cAdvisor, Riemann, Spigo, Sensu

·       Documentation – Swagger UI, Apiary, Readme.io, Slate, Gelato, Aglio

·       Testing – Postman, Hoverfly, Pact, Gattling, REST assured, Citrus framework

 

Converting a monolithic application to microservices:

·       Define the feature list of the monolithic application

·       List the microservices that facilitate the feature list

·       Select the critical microservices to implement

·       Focus on RESTful API side before implementing the event bus

·       Implement an API gateway

·       Identify processes which are handed through more than one APIs

·       Define events for each microservice that can be used as inputs that can trigger logic that reside in other microservices

·       Implement the event bus

·       Design patterns for distributed transaction

·       Decompose the single DB into a database per service

 

Microservices Architecture and Design Patterns

Characteristics –

·       Modifications are done efficiently

·       Organized around business domains

·       Microservices can have smart endpoints

·       Encourages collaboration

  

Microservices challenges

·       Monolithic architecture is difficult to be transitioned

·       Breaking apart the code may be more work, and may not be worth

·       Database deconstruction

·       Performance considerations

·       Monitoring and logging challenges (more components to monitor)

 

Alternatives to microservices

·       Service based architecture, instead of SOA

·       

 

Designing for microservices

·       Aggregator pattern – collects and collates all requests, and coordinates the responses of the services

·       Proxy pattern – does not do any processing.  A proxy is a class functioning as an interface to something else.

·       Branch pattern - Branch microservice design pattern extends Aggregator design pattern and allows simultaneous response processing from two, likely mutually exclusive, chains of microservices. This pattern can also be used to call different chains, or a single chain, based upon the business needs.

·       Shared data pattern - multiple components access data through a common data store. No single component is entirely responsible for the data or data store. This pattern is particularly useful when multiple components require a large amount of data.

·       Asynchronous pattern - the call site is not blocked while waiting for the called code to finish. Instead, the calling thread is notified when the reply arrives.

 

Potential risks of microservices:

·       Network calls and latency

·       Increased complexity

·       Must deal with external services

Dealing with failures of microservices:

·       Load balancing

·       Failover caching

·       Retry logic (when failed, attempt to retry)

Designing for successful microservices

·       Scoping functionality (prioritizing, logical functionality, organizational structure, set limits)

·       API presentation (exposed APIs)

·       Manage traffic (monitor, responsive APIs, graceful exit, volatility)

·       Offloading data (always on, shared redundancy, data caching)

·       Monitoring