Microservices & Docker

Introducing

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage technologies."

Martin Fowler & James Lewis 

A new marketing name for SOA?

WAIT!!!

Microservices & SOA

In microservices, services can operate and be deployed independently of other services, unlike SOA.

In SOA, an ESB could become a single point of failure which impacts the entire application

In SOA, services share the data storage while each service can have an independent data storage in microservices

We could think of the Microservices Architectural Style as a specialisation of SOA

 A SOA can be either a monolith or it can be comprised of multiple microservices.

In Microservices the individually deployable services made it easier to apply Continuous Integration / Continuous Deployment

Service Oriented Architecture (SOA)

  • Requires a long-term commitment to a technology stack
  • Obstacle to scaling development
  • Overloaded IDE
  • Overloaded web container
  • Continuous deployment is difficult
  • Scaling the application can be difficult​

 

Monolith drawbacks

Structure the application as a set of loosely coupled, collaborating services

Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP

Services can be developed and deployed independently of one another

Each service has its own database in order to be decoupled from other services

Break the monolith

The Scale Cube

Decompose into services

Decompose by business capability and define services corresponding to business capabilities.


Decompose by domain-driven design subdomain.


Decompose by verb or use case and define services that are responsible for particular actions. e.g. a Shipping Service that’s responsible for shipping complete orders.


Decompose by nouns or resources by defining a service that is responsible for all operations on entities/resources of a given type. e.g. an Account Service that is responsible for managing user accounts.

let's do microservices!!!

let's do microservices!!!

Drawbacks

  • Additional complexity of creating a distributed system.
    • Developer tools/IDEs are not ready
    • Testing is more difficult
    • Must implement the inter-service communication mechanism.
    • Implementing use cases that span multiple services without using distributed transactions is difficult
    • Implementing use cases that span multiple services requires careful coordination between the teams
  • Deployment complexity.
  • Increased memory and resources consumption.

Challenges

  • Orchestration vs Choreography
  • Distributed transactions
  • Synchronous vs Asynchronous
  • REST vs RPC vs Messaging
  • Reusing code
  • Versioning
  • Shared database vs Database per service 
  • Security
  • Monitoring

Patterns

http://microservices.io

API Gateway

  • Granularity of APIs provided by microservices is often different than what a client needs
  • Single entry point for all clients

Service Dicovery

Server Side Discovery

  • The client does not need to know how to find a service
  • Simplifies the client code
  • More control over the traffic. A/B testing or Canary releases
  • Every request is suffering from an extra network hop and introduces more latency
  • The router must be configured to be highly available  

 

Service Dicovery

Client side discovery

  • Direct communication between Service A and B
  • The service is available as long as there is at least one entry in the registry
  • Higher coupling between the client and the registry
  • A library for every language you use with your microservices

 

Circuit Breaker

  • Used to wrap dangerous operations in a component
  • Tripping of a circuit happens automatically in case of failure
  • ​Facilitates self-healing applications, as in case of open circuit application decides
    • To use another similar service
    • To stop using the service till a timeout occurs

 

Observability

  • A centralized logging service that aggregates logs from each service instance   Kibana + Logstash + ELK
  • Assigns each external request a unique external request id and passes the external request id to all services that are involved in handling the request
  • Report all exceptions to a centralized exception tracking service that aggregates and tracks exceptions and notifies developers
  • A service has an health check API endpoint (e.g. HTTP /health)

Communication

Communication

  • REST (JSON) over HTTP
    • ​HTTP/1
    • HTTP/2
  • AMQP
    • RabbitMQ
    • ZeroMQ
    • ActiveMQ
  • RPC
    • gRPC by Google
    • Thrift
  • Reactive Streams
    • ​Flink
    • Kafka
    • Cassandra
    • Play
  • ReactiveSockets: Application protocol with Reactive Streams semantics (By Netflix)
    • TCP Sockets
    • WebSockets
    • Aeron - UDP

Success Stories

Deployment

Docker is excellent for microservices, as it isolates containers to one process or service.

  • Easily deploy new services
  • Scale each microservice independently
  • Make the failure of a single mircoservice instance transparent to clients that access it.  
  • Enable simple, ad-hoc name-based discovery of service endpoints.
  • Containers also help with the efficient utilization of resources on a host
  • Environment portability

DOCKER SWARM

Docker swarm is a container orchestration tool, meaning that it allows the user to manage multiple containers deployed across multiple host machines

  • Cluster management integrated with Docker Engine
  • Decentralized design
  • Declarative service model
  • Scaling
  • Desired state reconciliation
  • Multi-host networking
  • Service discovery
  • Load balancing
  • Secure by default
  • Rolling updates

DevOps

DevOps

 

DevOps is the evolution of collaboration where the operations, development, and quality assurance teams collaborate and communicate throughout the software development process

 

It’s not separate role held by a single person or group of individuals.

 

Microservices are changing how teams are structured, allowing organizations to create teams centered on specific services and giving them autonomy and responsibility in a constrained area

 

Developers are responsible for creating a system to deliver the final product successfully.

To the man who only has a hammer,

everything he encounters begins to look like a nail "

Abraham Maslow

Made with Slides.com