Microservice Architecture

Microservice Architecture

Engin Yöyen

November, 2014

What is a microservice?

… is a small, discrete, isolated, lightweight application that is stateless service and can be deployed separately.

What is a monolith?

… is a single unit of application, which all the business logic and data access code are combined into a single application.

Microservice vs Monolith?

Call Center• Agents : Current available agents

• Calls : Current calls with details such customer, length of call, agent

• Statistics : Current number of calls per day

• Monitoring : Failing calls, connections, etc.

This is how does it look like!

And this is how you scale!

…of course, more work involved!

ComparisonMonolith Microservice

Update and Feature Delivery

new features takes time to implement

easy to understand easy to implement

Deployment not frequent but easyfrequent but

orchestration can be challanging

Isolation errors can have effect on entire system

error has effect only on particular services

Response Time Process call (Faster) API Call (Slower)

Comparison (2)Monolith Microservice

New DevelopersLong learning curve

(understanding application)

Long learning curve (understanding

architecture)

Technology Standardization on single technology

Choice of technology based on problem

Testing Relatively Simple Complexity of distributed systems

Development Tools (IDE)

Larger the code base slower the IDE gets Not an issue

Characteristics of Microservice Architecture

Single Responsibility• Single Responsibility Principle : Do one thing, but

do it well

• a responsibility = a reason for change

• How small is small? Size does not matter!

• Line of code(LOC) is not a good measurement, depends on language, on developer.

Stateless

• Each request as an independent transaction

• Persist your data!

Data Management

Data ManagementEach service can have it’s own data store, and it can be different technology

Communication between services

• HTTP (Request, Response)

• Message Queue (e.g. RabbitMQ, zeroMQ )

• Don’t Reinvent The Wheel. Use

• HTTP Status Code

• HTTP Headers

• REST (Not just the url also the body)

Deployment• Each service has its own

• Repository

• Build Pipeline

• Host

• Build single artifact that represent release candidate. Do not build artifact for different environment

• Manage configuration separately

• Can we provision a server less than 1 minute?

Deployment

Source : http://www.slideshare.net/fasgoncalves/hypervisor-versus-linux-containers

Deployment : Image Management

Source : https://www.joyent.com/developers/image-management/

IT Configuration and Automation

• Don’t do anything manually on any of your servers

• Good understanding of IT Automation and tools (e.g. Ansible, Chef, Salt, Puppet)

• Flexibility to build and deploy new services

• You Build It, You Run It!

Testing

Source : http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/

• Test different scope, for different purposes

• Higher the pyramid, shorter the feedback cycle

• End-to-End tests are not easy for microservices • Team structure, who writes the test • Testing multiple microservices • Network issues, time-to-complete

Testing

Source : http://www.thoughtworks.com/insights/blog/introducing-software-testing-cupcake-anti-pattern

Monitoring• Monitor your host and individual services

• Check health of your system

• Keep track of your logs

• Build and use conventions (e.g. Standardise your logs)

• Use existing tools: ElasticSearch, Kibana, Graphite, Logstash,

Metrics

• Response time

• Error Rate

• Correlation ID

The Company Culture

• Decentralized Governance: Right tool for right job

• Open enough to change and adopt

• Cross functional teams (e.g. for testing, operations)

Questions