Microservices

Introducing

@mcolomer

marcelo.colomer@gft.com

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

Monolith

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

Break it all!!

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!!!

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

Patterns

API Gateway

Service Discovery

Client-side Discovery

Server-side Discovery

Database per Service

Messaging and Remote Procedure Invocation

Cross-cutting concerns

Microservice chassis pattern Externalized configuration

Circuit Breaker

Testing patterns

Service Component TestService Integration Contract Test

Domain-driven design

Decomposition

Decompose by business capability
Decompose by subdomain

Observability

Log aggregation
Application metrics
Audit logging
Distributed tracing
Exception tracking
Health check API

Deployment

Single Service per Host

Multiple Services per Host

Access Token

Transaction log tailing

Event-driven

Event sourcing

CQRS

Shared Database

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

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

Anti Patterns

Grains of Sand or Nano-services
Jump On The Bandwagon
Logging Can Wait
Using Too Much Acid
Static Contract
Service Orphan
Are We There Yet
Give It A REST
Distributed monolith

Success Stories

https://netflix.github.io/

Spring Boot

https://cloud.spring.io/spring-cloud-netflix

@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
public class Application {
...

@SpringBootApplication
@EnableEurekaServer
public class Application {

  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

@FeignClient("bookmark-service")
interface BookmarkClient {

    @RequestMapping(method = RequestMethod.GET, value = "/{userId}/bookmarks")
    List<Bookmark> getBookmarks(@PathVariable("userId") String userId);
}

Eureka service registry

Eureka client

Client-Side Load Balancing with Ribbon

Spring Cloud

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

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.