Microservice Systems

A Microservice architecture is a design pattern to handle complicated backend systems.

Principles of Microservices

• Microservices should not share code or data

• Avoid unnecessary coupling between service & software components

• Independence and autonomy are more impt than code reusability

• Should never have a single point of failure (Each microservice can fail independantly)

  • A,B,C,D → E ; when E fails, A,B,C,D loses E’s functions

• Each microservice can be responsible for a single system function only

• Microservices should not communicate directly with each other. Probably can use a even/message bus

Benefits of Microservices

Anti-patterns

Typical Microservices Architecture

Refresh: what is a RESTful API API Intro and Communication Protocols and APIs

API Gateway

API Gateway tells you where to go, and prevent direct client access. Do note Client and Service may mean the same thing in this course. This way, the API gateway can control authentication, versioning, deprecation, etc.

Why don’t skip API Gateway?

• Increases complexity of client integration if clients have to keep track of numerous microservice endpoints.

• Consider that microservices might be moved or a new version might replace the service that a client used to call.

• Clients have to implement their own load balancing and failure detection. If clients want to access multiple services publicly, then all these services have to handle their own security concerns, including SSL termination and authentication.

• Publicly exposed services face the risk of suffering attacks. You can implement restrictions in API gateways.

Event Bus

An event bus can be classified as the backbone of a decoupled microservices architecture. It allows microservices to communicate with each other without having to know about each other.

This type of communication is based on the Publish/Subscribe pattern, which is similar to the Observer Pattern. However, with the Observer Pattern the publisher or observable broadcasts changes directly to its subscribers or observers.

Whereas with the Publish/Subscribe pattern, the Event Bus takes up the role of the middleman and sits between the publisher and subscriber. In this way, microservices that publish events to the event bus, does not have to know what other microservices want to do with the published events, it only needs to make sure that it is available on the event bus for consumption.

Securing Microservices

Generally, good to have a standalone authentication microservice (one of the principles)

OAuth2.0, JWT, etc are commonly used for authentication

Data Management Patterns

CQRS & Event Sourcing

Command Query Responsibility Segregation (Command and Queries are split responsibilities)

• CRUD in traditional architecture

• CRUD via basic CQRS

Event Sourcing defines an approach where all the changes that are made to an object or entity, are stored as a sequence of immutable events to an event store, as opposed to storing just the current state.

• The event store provides a complete log of every state change, effectively creating an audit trail of the entire system.

• The state of any object can be recreated by replaying the event store. It removes the need to map relational tables to objects.

• An event store can feed data into multiple read databases.

SAGA Pattern

A distributed transaction can be defined as a database transaction that involves two or more network hosts (or microservices) as opposed to single system that executes a transaction directly to the database.

ACID is an acronym that refers to the set of 4 key properties that define a transaction: Atomicity, Consistency, Isolation, and Durability. If a database operation has these ACID properties, it can be called an ACID transaction, and data storage systems that apply these operations are called transactional systems.

2 types of SAGA, Choreography-based (Sequenced via events) and Orchestration Based (Controlled / conducted by one service)

Containerizing Microservics

This is one way to containerize, and deploy microservices (to mange). Certain other Orchestration Engine tools can be used to ochestrate a bunch of containers. There is most likely going to be a rhdevs module on containerization, but not yet.

A container image becomes a container at runtime. Containers isolates applications from each other and makes them platform-agnostic. Containers are lightweight, and unlike virtual machines, each container do not come with its own operating system. Instead, containers share the kernel of the host operating system between each other, and in this way, consume less resources and reduces infrastructure and licensing costs.

Container orchestration refers to the automation of tasks that relates to the scheduling and management of containers. More specifically, container orchestration is used to automate the following tasks:

• Container deployment and provisioning.

• Rescheduling of containers that have failed.

• Scaling and load balancing of container instances.

• Resource allocation between containers.

• Container redundancy and availability

• External exposure services.

• Health monitoring of containers and hosts.

Examples of Frameworks and Tools

Frameworks

• Golang

• SpringBoot

• Ruby, Scala, Kotlin etc (Eclipse Vert.x)

• Helidon

• Grails

• .NET Color

Containerisation Tools

• Docker (most popular)

• CoreOS rkt, LXC linux containers, openVZ, Containerd etc

Orchestration Engines

• Kubernetes (K8)

• Amazon ECS

• Azure Kubernetes Service (AKS)

• Docker Swarm, OpenShift, Cloud Foundry’s Diego, CoreOS Fleet, etc

Service Discovery

Assist Services to discover and communicate w each other

• Consul

• Apache Zookeeper

• Etcd (used by Grab)

• Eureka

• SmartStack

• SkyDNS (uses DNS queries)

• Vyne

API Gateways

• Kong

• Ambassador

• Ocelot (used by tencent)

• Amazon AWS API Gateway

• Azure Application Gateway

• Spring Cloud Gateway

Event Bus Tools & Technologies

• Apache Kafka

• RabbitMQ (publish subscribe patterns)

• Azure Service Bus

• Amazon Simple Queue Service (SQS)

• Google Cloud Pub/Sub

Logging Tools

• Fluentd

• Graylog

• Kibana

• Logstash

• Bunyan (for nodejs)

• Suro

Monitoring Tools

• Grafana

• Prometheus (Open Source)

• cAdvisor

• Riemann

• Spigo

• Sensu

Documentation Tools

• Swagger UI

• Apiary

• Readme.io

• Slate

• Gelato

• Aglio