Micro services

MICROSERVICESMateusz Bukowicz

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 centralized management of these services, which may be written in different programming languages and use different data storage technologies.

-- James Lewis and Martin Fowler

…suite of small services…

The service can be rewritten and redeployed in 2 weeks

-- Jon Eaves, realestate.com.au

http://realestate.com


https://queue.acm.org/detail.cfm?id=1142065

If you hit the Amazon.com gateway page, the application calls more than 100 services to collect data and construct the page for you.

-- Werner Vogels, 2006, interview Web Services

https://queue.acm.org/detail.cfm?id=1142065

MICRO-SERVICES GROWTH IN TIME

RealEstate.com.au

No

of m

icro-

serv

ices

0

10

20

30

40

50

60

70

3 months 6 months 18 months

gilt.com

No

of m

icro-

serv

ices

0

50

100

150

200

250

300

2007RoR monolith

2009JVM

2011Scala

2014NodeJS

MICRO-SERVICES GROWTH IN TIME


“two pizza teams”

-- Jeff Bezos, Amazon

…running in its own process…

http://martinfowler.com/articles/microservices.html

http://martinfowler.com/articles/microservices.html

…built around business capabilities…

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

-- Melvyn Conway

=software structure reflects organisation structure

…built around business capabilities…

UI

Business Logic

Database

frontend devs

backend devs

DBAs

CROSS-FUNCTIONAL TEAMS

CROSS-FUNCTIONAL TEAMS

I am a designer

I am a programmer

I am a DBA

I develop product X

service ownership

Each service has a team associated with it, and that team is completely responsible for the service — from scoping out the functionality, to architecting it, to building it, and operating it. (…) Giving developers operational responsibilities has greatly enhanced the quality of the services.

-- Werner Vogels, Amazon

service ownership

Build DeployTest

…independently deployable…

You don’t go and have a deep discussion with the Google Maps team just to use their Maps API: it's a reasonably stable API, you are isolated, it's sort of versioned, occasionally it changes and you may want to do things.

-- Adrian Cockroft, (2010-2013 Netflix)

http://www.infoq.com/interviews/adrian-cockcroft-microservices-devops

http://www.infoq.com/interviews/adrian-cockcroft-microservices-devops

…independently deployable…

…bare minimum of centralised management…=

decentralise all things

MICRO SERVICES WITH SPRING BOOT

$ spring init --dependencies=web micro-service-1

$ spring init --list

$ spring init --build=gradle --java-version=1.8 \--dependencies=websocket --packaging=war \customized-project

$ spring run . -- --server.port=9000

$ spring test .

$ java -jar target/micro-service-1.jar

MICRO SERVICES WITH SPRING BOOT

@RestControllerpublic class MicroController2 {

@RequestMapping("/service2") public String service2() { return "Hello from service 2"; }}

@RestControllerpublic class MicroController1 {

@RequestMapping("/service1") public String service1() { RestTemplate rest = new RestTemplate(); String response = rest.getForObject( "http://localhost:9002/service2", String.class); return "Response from service2: " + response; }}

ADVANTAGES• cheap to scale

• fast to replace

• fault tolerant (resilient)

• promote modularity

• parallelize development

DISADVANTAGES• network is not deterministic

• lack of testing end-to-end

• complicated deploy and versioning

• a lot of new tools

• eventual consistency in favour of transactions

• more work and bigger dev costs

MICROSERVICES VS SOA

Microservices = pragmatic SOA

-- Adam Bien


Fine-grained SOA

-- Adrian Cockroft, Netflix


With SOA, the intent is a layered architecture of co-operating services where SOA focuses on describing the organisation and co-ordination of the services. With micro services, the intent is to describe the nature of the services themselves and not quite so much the organisation and co-ordination of them.

-- Jon Eaves, realestate.com.au

http://realestate.com

MICROSERVICES VS SOAWe have gone from building a single ball of mud to orchestrating a lot of shit

-- Hadi Hariri


SOA means too many different things

-- Martin Fowler

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

MICROSERVICES VS MONOLITH

http://martinfowler.com/bliki/MicroservicePremium.html

http://martinfowler.com/bliki/MicroservicePremium.html

MONOLITH FIRST

http://martinfowler.com/bliki/MonolithFirst.html

http://martinfowler.com/bliki/MonolithFirst.html

DON’T START WITH A MONOLITH

http://martinfowler.com/articles/dont-start-monolith.html

http://martinfowler.com/articles/dont-start-monolith.html


If you can't build a structured monolith, what makes you think micro-services is the answer?!

-- Simon Brown

YOU MUST BE THIS TALL TO USE MICRO SERVICES

http://martinfowler.com/bliki/MicroservicePrerequisites.html

http://martinfowler.com/bliki/MicroservicePrerequisites.html

YOU MUST BE THIS TALL TO USE MICRO SERVICES

• DevOps

• Continous Delivery

no SSH to server

realtime monitoring

build pipeline

click to deployculture of automation

IS IT WORTH DITCHING THE MONOLITH?

• 95% cases: totally not worth it

• dvd.netflix.com: monolith for 6 mln users (2015)


Monolithic deployment of multiple components within a single WAR still remains the simplest possible solution for a mainstream project without any additional requirements. Unfortunately, simplest possible solutions are usually not buzzword-compatible :-).

-- Adam Bien

5%• optimisation madness?

Micro-ServicesCertified

• micro-services envy?

MICRO-SERVICES BEST PRACTICES

NEVER ENDING CONCEPTS

Loose Coupling High Cohesion

POSTEL’S LAW

Be conservative in what you send, be liberal in what you accept

-- Jon Postel

Request

Response

STANDARDISATION

HTTP/REST SOAP

MySQL PostgreSQL

2xx error codes 4xx/5xx error codes

REST verbs REST nouns

push monitoring pull monitoring

Java/Scala/Groovy Ruby/Javascript/Python

Redhat CentOS

Dropwizard/Karyon Spring Boot

STANDARDISATION IMPLEMENTATION

• exemplary service

• service template

existing service serving as an

example

the basis for other services

STRANGLER PATTERN

STRANGLER PATTERN

Gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.

-- Martin Fowler

http://martinfowler.com/bliki/StranglerApplication.html

http://martinfowler.com/bliki/StranglerApplication.html

STRANGLER PATTERN

CMS/ERP/CRM

Recommendation(facade)

Service 1 Service 2 Service 3

HIDE IMPLEMENTATION DETAILS

API

Boundary

Sharing implementation details

BREAKING CHANGES

API

v1

v2

API

v1

v2

blue green

deploymentcanaryrelease

CONSUMER-DRIVEN CONTRACT WITH PACT

public class Service2PactTest extends ConsumerPactTest {

@Override protected PactFragment createFragment(ConsumerPactBuilder.PactDslWithProvider builder) { return builder .uponReceiving("Request for service 2") .path("/service2") .method("GET") .willRespondWith() .status(200) .body("Hello from service 2") .toFragment(); }

@Override protected String providerName() { return "Service 2"; }

@Override protected String consumerName() { return "Service 1"; }

@Override protected void runTest(String url) throws IOException { Service2Client client = new Service2Client(url); String response = client.callService2(); assertEquals("Hello from service 2", response); }}

<build> <plugins> <plugin> <groupId>au.com.dius</groupId> <artifactId>pact-jvm-provider-maven_2.11</artifactId> <version>2.2.10</version> <configuration> <serviceProviders> <serviceProvider> <name>Service 2</name> <protocol>http</protocol> <host>localhost</host> <port>9002</port> <path>/</path> <consumers> <consumer> <name>Service 1</name> <pactFile>../micro-service-1/target/pacts/Service 1-Service 2.json</pactFile> </consumer> </consumers> </serviceProvider> </serviceProviders> </configuration> </plugin> </plugins></build>

$ mvn au.com.dius:pact-jvm-provider-maven_2.11:verify

SINGLE CORRELATION ID

initial request request A:Correlation ID: 1005

request B:

Correlation ID: 1005

request C:Correlation ID: 1005

AVOID SHARED DEPENDENCY

API

Shared model

API

Boundary

AVOID SHARED DEPENDENCY

Don’t violate DRY within a micro service, but be relaxed about violating DRY across all services.

-- Sam Newman, “Building Microservices”

ACQUIRING CONSISTENCY

1) distributed transaction

INSERT retry2) retry

INSERT DELETErollback3) compensating transaction

Order ShippingplaceOrder shipOrder

ERROR!!!

PRODUCTION-LIKE ENVIRONMENTS

INFRASTRUCTURE AS CODE

ONE SERVICE PER CONTAINER

Our main focus is system containers. That is, containers which offer an environment as close to possible as the one you'd get from a VM but without the overhead that comes with running a separate kernel and simulating all the hardware.

-- linuxcontainers.org

http://linuxcontainers.org

Container in a Container in a Container in a…

CIRCUIT BREAKER

closed

openhalf-open

failure thresholdreached

timeout timer expired

operation failed

success count threshold reached

always return failure

increment failurecounter on failure

incrementsuccess

counter onsuccess

start

FAIL FAST & GRACEFUL DEGRADATION

UI Searchfind_movie(“Godzilla”)

error

find_movie(“Godzilla”)

return default movies

find_movie(“Godzilla”)

return default movies

circuit timeout

find_movie(“Godzilla”) find_movie(“Godzilla”)

successreturn search results

https://github.com/nurkiewicz/hystrix-demo

https://github.com/nurkiewicz/hystrix-demo

AGREGGATED MONITORING

DROPWIZARD METRICS

http://metrics.dropwizard.io/

STORING METRICSRetention policies

No

of sa

mpl

es p

er 1

hou

r

0

30

60

90

120

Within last 1h Older than 1h Older than 1 day Older than 1 week

CENTRAL SEARCHABLE LOGS

https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html

https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html

http://www.slideshare.net/renzotoma39/scaling-an-elk-stack-at-bolcom-39412550

http://www.slideshare.net/renzotoma39/scaling-an-elk-stack-at-bolcom-39412550

NETFLIX TOOLS

netflix.github.io

GOOGLE KUBERNETES

ATLAS (HASHICORP)

USE YOUR OWN STACK OF TOOLS

LEARN MORE11 September 2015

Sopot, Poland

incrediblebook

single sourceof truth

Micro services

Software

Transcript of Micro services