Microservices Workshop - Craft Conference

transcript

Microservices Workshop: Why, what, and how to get there

Adrian Cockcroft @adriancoTechnology Fellow - Battery Ventures

April 2016

AgendaWorkshop vs. Presentation & Introductions

Faster Development Microservice Architectures

What’s Missing? Migration and Simulation

What’s Next? Hands-on

Workshop vs. Presentation

Questions at any time Interactive discussions Share your experiences

Everyone’s voice should be heard PDF of slides:

http://bit.ly/microservices-craft

What does @adrianco do?

@adrianco

Technology Due Diligence on Deals

Presentations at Conferences

Presentations at Companies

Technical Advice for Portfolio

Companies

Program Committee for Conferences

Networking with Interesting PeopleTinkering with

Technologies

Maintain Relationship with Cloud Vendors

Previously: Netflix, eBay, Sun Microsystems, CCL, TCU London BSc Applied Physics

Why am I here?

%*&!”

By Simon Wardley http://enterpriseitadoption.com/

Why am I here?

%*&!”

Why am I here?

%*&!”

Why am I here?

@adrianco’s job at the intersection of cloud and Enterprise IT, looking for disruption and opportunities.

%*&!”

20142009

Disruptions in 2016 coming from server-less computing and teraservices.

Typical reactions to my Netflix talks…

“You guys are crazy! Can’t believe it”

– 2009

“What Netflix is doing won’t work”

– 2010

– 2009

– 2010 It only works for ‘Unicorns’ like

Netflix”– 2011

– 2009

Netflix”– 2011

“We’d like to do that but can’t”

– 2012

– 2009

Netflix”– 2011

“We’d like to do that but can’t”

– 2012

“We’re on our way using Netflix OSS code”

– 2013

What I learned from my time at Netflix

•Speed wins in the marketplace

•Speed wins in the marketplace•Remove friction from product development

•Speed wins in the marketplace•Remove friction from product development•High trust, low process, no hand-offs between teams

•Speed wins in the marketplace•Remove friction from product development•High trust, low process, no hand-offs between teams•Freedom and responsibility culture

•Speed wins in the marketplace•Remove friction from product development•High trust, low process, no hand-offs between teams•Freedom and responsibility culture•Don’t do your own undifferentiated heavy lifting

•Speed wins in the marketplace•Remove friction from product development•High trust, low process, no hand-offs between teams•Freedom and responsibility culture•Don’t do your own undifferentiated heavy lifting•Use simple patterns automated by tooling

•Speed wins in the marketplace•Remove friction from product development•High trust, low process, no hand-offs between teams•Freedom and responsibility culture•Don’t do your own undifferentiated heavy lifting•Use simple patterns automated by tooling•Self service cloud makes impossible things instant

“You build it, you run it.” Werner Vogels 2006

In 2014 Enterprises finally embraced public cloud and in 2015 began replacing entire datacenters.

Oct 2014

Oct 2014 Oct 2015

Key Goals of the CIO? Align IT with the business Develop products faster Try not to get breached

Security Blanket Failure

Insecure applications hidden behind firewalls make you feel safe until the breach happens…

http://peanuts.wikia.com/wiki/Linus'_security_blanket

What needs to change?

Developer responsibilities: Faster, cheaper, safer

“It isn't what we don't know that gives us trouble, it's what we

know that ain't so.”

Will Rogers

Assumptions

Optimizations

Assumption: Process prevents

problems

Organizations build up slow complex “Scar

tissue” processes

"This is the IT swamp draining manual for anyone who is neck deep in alligators.”

1984 2014

Product Development

Processes

Waterfall Product Development

Business Need• Documents• Weeks

Approval Process• Meetings• Weeks

Hardware Purchase• Negotiations• Weeks

Software Development• Specifications• Weeks

Deployment and Testing• Reports• Weeks

Customer Feedback• It sucks!• Weeks

Hardware provisioning is undifferentiated heavy lifting – replace it with IaaS

IaaSCloud

Process Hand-Off Steps for Agile

Product Manager

Development Team

QA Integration Team

Operations Deploy Team

BI Analytics Team

IaaS Agile Product Development

Deployment and Testing• Reports• Days

Customer Feedback• It sucks!• Days

etc…

Software provisioning is undifferentiated heavy lifting – replace it with PaaS

etc…

PaaSCloud

etc…

Process for Continuous Delivery of Features on PaaS

Product Manager

Developer

BI Analytics Team

PaaS CD Feature Development

Business Need• Discussions• Days

Software Development• Code• Days

Customer Feedback• Fix this Bit!• Hours

etc…

Building your own business apps is undifferentiated heavy lifting – use SaaS

etc…

SaaS/BPaaSCloud

etc…

SaaS Based Business Application Development

Business Need•GUI Builder•Hours

Customer Feedback•Fix this bit!•Seconds

SaaS Based Business Application Development

Business Need•GUI Builder•Hours

Customer Feedback•Fix this bit!•Seconds

and thousands more…

Value Chain Mapping

Simon Wardley http://blog.gardeviance.org/2014/11/how-to-get-to-strategy-in-ten-steps.html Related tools and training http://www.wardleymaps.com/

Value Chain Mapping

Your unique product - Agile

Value Chain Mapping

Your unique product - Agile Best of breed as a Service - Lean

Value Chain Mapping

Your unique product - Agile

Undifferentiated utility suppliers - 6sigma

Best of breed as a Service - Lean

Observe

Orient

Decide

Act Continuous Delivery

Observe

Orient

Decide

Land grab opportunity Competitive

Customer Pain Point

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

INNOVATION

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Model Hypotheses

INNOVATION

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Model Hypotheses

BIG DATA

INNOVATION

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Plan Response

Share Plans

Model Hypotheses

BIG DATA

INNOVATION

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Plan Response

Share Plans

Model Hypotheses

BIG DATA

INNOVATION

CULTURE

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Plan Response

Share Plans

Incremental Features

Automatic Deploy

Launch AB Test

Model Hypotheses

BIG DATA

INNOVATION

CULTURE

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Plan Response

Share Plans

Automatic Deploy

Launch AB Test

Model Hypotheses

BIG DATA

INNOVATION

CULTURE

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Plan Response

Share Plans

Automatic Deploy

Launch AB Test

Model Hypotheses

BIG DATA

INNOVATION

CULTURE

Measure Customers

Continuous Delivery

Observe

Orient

Decide

Customer Pain Point

Analysis

Plan Response

Share Plans

Automatic Deploy

Launch AB Test

Model Hypotheses

BIG DATA

INNOVATION

CULTURE

Measure Customers

Continuous Delivery

Breaking Down the SILOs

QA DBA Sys Adm

Net Adm

SAN AdmDevUXProd

QA DBA Sys Adm

Net Adm

SAN AdmDevUXProd

Product Team Using Monolithic DeliveryProduct Team Using Monolithic Delivery

QA DBA Sys Adm

Net Adm

SAN AdmDevUXProd

MgrProduct Team Using Microservices

Product Team Using Monolithic Delivery

Product Team Using MicroservicesProduct Team Using Microservices

QA DBA Sys Adm

Net Adm

SAN AdmDevUXProd

Platform TeamProduct Team Using MicroservicesProduct Team Using Microservices

QA DBA Sys Adm

Net Adm

SAN AdmDevUXProd

Platform TeamAPI

QA DBA Sys Adm

Net Adm

SAN AdmDevUXProd

Platform Team

Re-Org from project teams to product teams

Release Plan

Developer

QA Release Integration

Ops Replace Old With New

Release

Monolithic service updates

Works well with a small number of developers and a single language like php, java or ruby

Release Plan

Developer

Release

Release Plan

Developer

Release

Use monolithic apps for small teams, simple systems and when you must, to optimize for efficiency and latency

Developer

Old Release Still Running

Release Plan

Immutable microservice deployment scales, is faster with large teams and diverse platform components

Developer

Release Plan

Deploy Feature to Production

Developer

Release Plan

Developer

Release Plan

Configure

Developer

Release Plan

Deploy Standardized

Services

Standardized container deployment saves time and effort

https://hub.docker.com

Configure

Developer

Release Plan

Deploy Standardized

Services

Standardized container deployment saves time and effort

https://hub.docker.com

Developer Developer

Run What You Wrote

Developer Developer

Run What You Wrote

Micro service

Developer Developer

DeveloperDeveloper Developer

Run What You Wrote

Micro service

Developer Developer

Monitoring Tools

Run What You Wrote

Micro service

Developer Developer

Site Reliability

Monitoring Tools

Availability Metrics

99.95% customersuccess rate

Run What You Wrote

Micro service

Developer Developer

Manager Manager

Site Reliability

Monitoring Tools

Run What You Wrote

Micro service

Developer Developer

Manager Manager

VP Engineering

Site Reliability

Monitoring Tools

Non-Destructive Production Updates

● “Immutable Code” Service Pattern

● Existing services are unchanged, old code remains in service

● New code deploys as a new service group

● No impact to production until traffic routing changes

● A|B Tests, Feature Flags and Version Routing control traffic

● First users in the test cell are the developer and test engineers

● A cohort of users is added looking for measurable improvement

Deliver four features every four weeks

Work In Progress = 4 Opportunity for bugs: 100% (baseline) Time to debug each: 100% (baseline)

Deliver four features every four weeksBugs! Which feature broke? Need more time to test! Extend release to six weeks?

But: risk of bugs in delivery increases with interactions!

Bugs! Which feature broke? Need more time to test! Extend release to six weeks?

16But: risk of bugs in delivery increases with interactions!

Bugs! Which feature broke? Need more time to test! Extend release to six weeks?

Deliver six features every six weeks

Work In Progress = 6 Individual bugs: 150% Interactions: 150%?

Deliver six features every six weeksMore features What broke? More interactions Even more bugs!!

Deliver six features every six weeks

Risk of bugs in delivery increased to 225% of original!

More features What broke? More interactions Even more bugs!!

Deliver two features every two weeks

Complexity of delivery decreased by 75% from original

Fewer interactions Fewer bugs Better flow Less Work In Progress

Work In Progress = 2 Opportunity for bugs: 50% Time to debug each: 50%

Change One Thing at a Time!

If it hurts, do it more often!

What Happened?Rate of change

increased

Cost and size and risk of change

reduced

Low Cost of Change Using Docker

Developers• Compile/Build• Seconds

Extend container• Package dependencies• Seconds

Deploy Container• Docker startup• Seconds

Low Cost of Change Using Docker

Fast tooling supports continuous delivery of many tiny changes

Developers• Compile/Build• Seconds

Extend container• Package dependencies• Seconds

Deploy Container• Docker startup• Seconds

Disruptor: Continuous Delivery with

Containerized Microservices

It’s what you know that isn’t so

It’s what you know that isn’t so● Make your assumptions explicit

● Extrapolate trends to the limit

● Listen to non-customers

● Follow developer adoption, not IT spend

● Map evolution of products to services to utilities

● Re-organize your teams for speed of execution

Microservices

A Microservice Definition

Loosely coupled service oriented architecture with bounded contexts

If every service has to be updated at the same time it’s not loosely coupled

If you have to know too much about surrounding services you don’t have a bounded context. See the Domain Driven Design book by Eric Evans.

Coupling Concerns

http://en.wikipedia.org/wiki/Conway's_law

●Conway’s Law - organizational coupling

●Centralized Database Schemas

●Enterprise Service Bus - centralized message queues

●Inflexible Protocol Versioning

Speeding Up The Platform

Datacenter Snowflakes• Deploy in months• Live for years

Virtualized and Cloud• Deploy in minutes• Live for weeks

Container Deployments• Deploy in seconds• Live for minutes/hours

Lambda Deployments• Deploy in milliseconds• Live for seconds

AWS Lambda is leading exploration of serverless architectures in 2016

Lambda Deployments• Deploy in milliseconds• Live for seconds

Separate Concerns with Microservices

http://en.wikipedia.org/wiki/Conway's_law

● Invert Conway’s Law – teams own service groups and backend stores

● One “verb” per single function micro-service, size doesn’t matter

● One developer independently produces a micro-service

● Each micro-service is it’s own build, avoids trunk conflicts

● Deploy in a container: Tomcat, AMI or Docker, whatever…

● Stateless business logic. Cattle, not pets.

● Stateful cached data access layer using replicated ephemeral instances

Inspiration

http://www.infoq.com/presentations/Twitter-Timeline-Scalabilityhttp://www.infoq.com/presentations/twitter-soa

http://www.infoq.com/presentations/Zipkinhttp://www.infoq.com/presentations/scale-gilt Go-Kit https://www.youtube.com/watch?v=aL6sd4d4hxk

http://www.infoq.com/presentations/circuit-breaking-distributed-systemshttps://speakerdeck.com/mattheath/scaling-micro-services-in-go-highload-plus-plus-2014

State of the Art in Web Scale Microservice Architectures

AWS Re:Invent : Asgard to Zuul https://www.youtube.com/watch?v=p7ysHhs5hl0Resiliency at Massive Scale https://www.youtube.com/watch?v=ZfYJHtVL1_w

Microservice Architecture https://www.youtube.com/watch?v=CriDUYtfrjsNew projects for 2015 and Docker Packaging https://www.youtube.com/watch?v=hi7BDAtjfKY

Spinnaker deployment pipeline https://www.youtube.com/watch?v=dwdVwE52KkUhttp://www.infoq.com/presentations/spring-cloud-2015

Microservice Architectures

ConfigurationTooling Discovery Routing Observability

Development: Languages and Container

Operational: Orchestration and Deployment Infrastructure

Datastores

Policy: Architectural and Security Compliance

Microservices

EddaArchaius

Configuration

SpinnakerSpringCloud

Tooling

EurekaPrana

Discovery

DenominatorZuul

Ribbon

Routing

HystrixPytheus

Observability

Development using Java, Groovy, Scala, Clojure, Python with AMI and Docker Containers

Orchestration with Autoscalers on AWS, Titus exploring Mesos & ECS for Docker

Ephemeral datastores using Dynomite, Memcached, Astyanax, Staash, Priam, Cassandra

Policy via the Simian Army - Chaos Monkey, Chaos Gorilla, Conformity Monkey, Security Monkey

Cloud Native Storage Business

DatabaseMaster

Fabric

Storage Arrays

DatabaseSlave

Fabric

Storage Arrays

DatabaseMaster

Fabric

Storage Arrays

DatabaseSlave

Fabric

Storage Arrays

Business Logic

Cassandra Zone A nodes

Cassandra Zone B nodes

Cassandra Zone C nodes

Cloud Object Store Backups

DatabaseMaster

Fabric

Storage Arrays

DatabaseSlave

Fabric

Storage Arrays

Business Logic

SSDs inside arrays disrupt incumbent suppliers

DatabaseMaster

Fabric

Storage Arrays

DatabaseSlave

Fabric

Storage Arrays

Business Logic

SSDs inside ephemeral instances disrupt an entire industry

DatabaseMaster

Fabric

Storage Arrays

DatabaseSlave

Fabric

Storage Arrays

Business Logic

SSDs inside ephemeral instances disrupt an entire industry

NetflixOSS Uses Priam to create Cassandra clusters in minutes

Twitter Microservices

Decider

ConfigurationTooling

FinagleZookeeper

Discovery

FinagleNetty

Routing

Zipkin

Observability

Scala with JVM Container

Orchestration using Aurora deployment in datacenters using Mesos

Custom Cassandra-like datastore: Manhattan

Twitter Microservices

Decider

ConfigurationTooling

FinagleZookeeper

Discovery

FinagleNetty

Routing

Zipkin

Observability

Scala with JVM Container

Orchestration using Aurora deployment in datacenters using Mesos

Custom Cassandra-like datastore: Manhattan

Focus on efficient datacenter deployment at scale

Gilt Microservices

Decider

Configuration

Ion CannonSBTRake

Tooling

FinagleZookeeper

Discovery

AkkaFinagleNetty

Routing

Zipkin

Observability

Scala and Ruby with Docker Containers

Deployment on AWS

Datastores per Microservice using MongoDB, Postgres, Voldemort

Gilt Microservices

Decider

Configuration

Ion CannonSBTRake

Tooling

FinagleZookeeper

Discovery

AkkaFinagleNetty

Routing

Zipkin

Observability

Scala and Ruby with Docker Containers

Deployment on AWS

Datastores per Microservice using MongoDB, Postgres, Voldemort

Focus on fast development with Scala and Docker

Hailo Microservices

Configuration

HubotJanky

Jenkins

Tooling

go-platform

Discovery

go-platformRabbitMQ

Routing Observability

Go using AMI Container and Docker

Deployment on AWS

Hailo Microservices

Configuration

HubotJanky

Jenkins

Tooling

go-platform

Discovery

go-platformRabbitMQ

Routing Observability

Go using AMI Container and Docker

Deployment on AWS

See: go-micro and https://github.com/peterbourgon/gokit

Next Generation ApplicationsFill in the gaps, rapidly evolving ecosystem choices

ArchaiusLaunchDarkly

Configuration

Docker CaaSSpinnaker

Tooling

EtcdEurekaConsul

Discovery

ComposeCalicoWeave

Routing

ZipkinPrometheus

Hystrix

Observability

Development: Components assembled from Docker Hub as a composable “app store”

Operational: Mesos, Kubernetes, Swarm, ECS etc. across public and private clouds

Datastores: Distributed Ephemeral, Orchestrated or DBaaS

Policy: Architectural and security compliance, Cloud Foundry/Apcera for low trust teams

@adrianco

In Search of Segmentation

Datacenters/AWS Accounts IAM/AD/LDAP Roles VPC/VLAN Networks

Security Groups/Hypervisor IPtables/Calico Policy

Docker Links/Weave Overlay

@adrianco

Hierarchical Segmentation

B CA B C E FD E F

Security Group for team X Security Group for team YVPC Z - Manage a small number of large network spaces

An AWS oriented example…

AWS Account - Manage across multiple accounts

containers and links

@adrianco

What’s Often Missing?

Failure injection testing Versioning, routing

Binary protocols and interfaces Timeouts and retries

Denormalized data models Monitoring, tracing

Simplicity through symmetry

@adrianco

Failure Injection Testing Netflix Chaos Monkey. Simian Army, FIT and Gremlin

http://techblog.netflix.com/2011/07/netflix-simian-army.htmlhttp://techblog.netflix.com/2014/10/fit-failure-injection-testing.htmlhttp://techblog.netflix.com/2016/01/automated-failure-testing.html

● Chaos Monkey - enforcing stateless business logic

● Chaos Gorilla - enforcing zone isolation/replication

● Chaos Kong - enforcing region isolation/replication

● Security Monkey - watching for insecure configuration settings

● Latency Monkey & FIT - inject errors to enforce robust dependencies

● See over 100 NetflixOSS projects at netflix.github.com

● Get “Technical Indigestion” reading techblog.netflix.com

Trust with Verification

@adrianco

Benefits of version aware routing

Immediately and safely introduce a new version Canary test in production

Use feature flags n

Route clients to a version so they can’t get disrupted Change client or dependencies but not both at once

Eventually remove old versions Incremental or infrequent “break the build” garbage collection

@adrianco

Versioning, RoutingVersion numbering: Interface.Feature.Bugfix

V1.2.3 to V1.2.4 - Canary test then remove old version

V1.2.x to V1.3.x - Canary test then remove or keep both Route V1.3.x clients to new version to get new feature

Remove V1.2.x only after V1.3.x is found to work for V1.2.x clients

V1.x.x to V2.x.x - Route clients to specific versions Remove old server version when all old clients are gone

@adrianco

Protocols

Measure serialization, transmission, deserialization costs

“Sending a megabyte of XML between microservices will make you sad…”

Use Thrift, Protobuf/gRPC, Avro, SBE internally Use JSON for external/public interfaces https://github.com/real-logic/simple-binary-encoding

@adrianco

Interfaces

When you build a service, build a “driver” client for it Reference implementation error handling and serialization

Release automation stress test using client Validate that service interface is usable!

Minimize additional dependencies

Swagger - OpenAPI Specification Datawire Quark adds behaviors to API spec

@adrianco

Interfaces

@adrianco

Interfaces

Client Code

Object Model

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

CacheCode

Object Model

Decoupled object

models

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

ServiceDriver

ServiceHandler

Object Model

CacheCode

Object Model

Decoupled object

models

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

CacheDriver

ServiceDriver

ServiceHandler

Object Model

CacheCode

CacheHandler

Object Model

Decoupled object

models

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

CacheDriver

ServiceDriver

Platform Platform

ServiceHandler

Object Model

CacheCode

Platform

CacheHandler

Object Model

Decoupled object

models

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

CacheDriver

ServiceDriver

Platform Platform

ServiceHandler

Object Model

CacheCode

Platform

CacheHandler

Object Model

Versioned dependency interfacesDecoupled

object models

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

CacheDriver

ServiceDriver

Platform Platform

ServiceHandler

Object Model

CacheCode

Platform

CacheHandler

Object Model

Versioned dependency interfaces

Versioned platform interface

Decoupled object

models

@adrianco

Interfaces

ServiceCode

Client Code

Object Model

CacheDriver

ServiceDriver

Platform Platform

ServiceHandler

Object Model

CacheCode

Platform

CacheHandler

Object Model

Versioned dependency interfaces

Versioned platform interface

Decoupled object

models

Versioned routing

@adrianco

Interface Version Pinning

Change one thing at a time! Pin the version of everything else

Incremental build/test/deploy pipeline

Deploy existing app code with new platform Deploy existing app code with new dependencies

Deploy new app code with pinned platform/dependencies

@adrianco

Timeouts and Retries

Connection timeout vs. request timeout confusion

Usually setup incorrectly, global defaults

Systems collapse with “retry storms”

Timeouts too long, too many retries

Services doing work that can never be used

@adrianco

Connections and RequestsTCP makes a connection, HTTP makes a request

HTTP hopefully reuses connections for several requests

Both have different timeout and retry needs!

TCP timeout is purely a property of one network latency hop HTTP timeout depends on the service and its dependencies

connection pathrequest path

@adrianco

Edge Service

Good Service

Bad config: Every service defaults to 2 second timeout, two retries

Edge Service not responding

Overloaded service not responding

Failed Service

If anything breaks, everything upstream stops responding

Retries add unproductive work

@adrianco

Edge Service

Good Service

Failed Service

@adrianco

Edge Service

Good Service

Failed Service

@adrianco

Timeouts and RetriesBad config: Every service defaults to 2 second timeout, two retries

Edge service

responds slowly

Overloaded service

Partiallyfailed

service

@adrianco

Edge service

responds slowly

Overloaded service

Partiallyfailed

service

First request from Edge timed out so it ignores the successful response and keeps retrying. Middle service load increases as

it’s doing work that isn’t being consumed

@adrianco

Edge service

responds slowly

Overloaded service

Partiallyfailed

service

First request from Edge timed out so it ignores the successful response and keeps retrying. Middle service load increases as

it’s doing work that isn’t being consumed

@adrianco

Timeout and Retry Fixes

Cascading timeout budget Static settings that decrease from the edge

or dynamic budget passed with request

How often do retries actually succeed? Don’t ask the same instance the same thing

Only retry on a different connection

@adrianco

Edge Service

Good Service

Budgeted timeout, one retry

Failed Service

@adrianco

Edge Service

Good Service

Budgeted timeout, one retry

Failed Service

3s1s1s

Fast failresponseafter 2s

Upstream timeout must always be longer than total downstream timeout * retries delay

No unproductive work while fast failing

@adrianco

Edge Service

Good Service

Budgeted timeout, failover retry

Failed Service

For replicated services with multiple instances never retry against a failed instance

No extra retries or unproductive work

Good Service

@adrianco

Edge Service

Good Service

Budgeted timeout, failover retry

Failed Service3s 1s

For replicated services with multiple instances never retry against a failed instance

No extra retries or unproductive work

Good Service

Successfulresponsedelayed 1s

@adrianco

Manage Inconsistency

ACM Paper: "The Network is Reliable" Distributed systems are inconsistent by nature

Clients are inconsistent with servers Most caches are inconsistent

Versions are inconsistent Get over it and

Deal with it

@adrianco

Denormalized Data Models

Any non-trivial organization has many databases Cross references exist, inconsistencies exist

Microservices work best with individual simple stores Scale, operate, mutate, fail them independently

NoSQL allows flexible schema/object versions

@adrianco

Denormalized Data Models

Build custom cross-datasource check/repair processes

Ensure all cross references are up to date

Immutability Changes Everything http://highscalability.com/blog/2015/1/26/paper-immutability-changes-everything-by-pat-helland.html

Memories, Guesses and Apologies https://blogs.msdn.microsoft.com/pathelland/2007/05/15/memories-guesses-and-apologies/

Cloud Native Monitoring and Microservices

Cloud Native Microservices● High rate of change

Code pushes can cause floods of new instances and metrics Short baseline for alert threshold analysis – everything looks unusual

● Ephemeral Configurations Short lifetimes make it hard to aggregate historical views Hand tweaked monitoring tools take too much work to keep running

● Microservices with complex calling patterns End-to-end request flow measurements are very important Request flow visualizations get overwhelmed

Microservice Based Architectures

See http://www.slideshare.net/LappleApple/gilt-from-monolith-ruby-app-to-micro-service-scala-service-architecture

Continuous Delivery and DevOps

●Changes are smaller but more frequent

● Individual changes are more likely to be broken

●Changes are normally deployed by developers

●Feature flags are used to enable new code

● Instant detection and rollback matters much more

Whoops! I didn’t mean that! Reverting…

Not cool if it takes 5 minutes to see it failed and 5 more to see a fix No-one notices if it only takes 5 seconds to detect and 5 to see a fix

NetflixOSS Hystrix/Turbine Circuit Breaker

http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.html

NetflixOSS Hystrix/Turbine Circuit Breaker

http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.html

Low Latency SaaS Based Monitors

https://www.datadoghq.com/ http://www.instana.com/ www.bigpanda.io www.vividcortex.com signalfx.com wavefront.com sysdig.com See www.battery.com for a list of portfolio investments

A Tragic Quadrant

Ability to scale

Ability to handle rapidly changing microservices

In-house tools at web scale companies

Most current monitoring & APM

Next generation APM

Next generation Monitoring

Datacenter

Containers

100s 1,000s 10,000s 100,000s

Lambda

A Tragic Quadrant

Ability to scale

Ability to handle rapidly changing microservices

In-house tools at web scale companies

Most current monitoring & APM

Next generation APM

Next generation Monitoring

Datacenter

Containers

100s 1,000s 10,000s 100,000s

Lambda

Metric to display latency needs to be less than human attention span (~10s)

Challenges for Microservice

Platforms

Managing Scale

A Possible Hierarchy Continents

Regions Zones

Services Versions

Containers Instances

How Many? 3 to 5

2-4 per Continent 1-5 per Region 100’s per Zone

Many per Service 1000’s per Version

10,000’s

It’s much more challenging than just a large number of

machines

Some tools can show the request flow

across a few services

Interesting architectures have a lot of microservices! Flow visualization is

a big challenge.

See http://www.slideshare.net/LappleApple/gilt-from-monolith-ruby-app-to-micro-service-scala-service-architecture

Simulated MicroservicesModel and visualize microservices Simulate interesting architectures Generate large scale configurations Eventually stress test real tools

Code: github.com/adrianco/spigo Simulate Protocol Interactions in Go Visualize with D3 See for yourself: http://simianviz.surge.sh Follow @simianviz for updates

ELB Load Balancer

ZuulAPI Proxy

KaryonBusiness Logic

StaashData Access Layer

PriamCassandra Datastore

ThreeAvailabilityZones

DenominatorDNS Endpoint

Spigo Nanoservice Structurefunc Start(listener chan gotocol.Message) { ... for { select { case msg := <-listener:

flow.Instrument(msg, name, hist) switch msg.Imposition { case gotocol.Hello: // get named by parent ... case gotocol.NameDrop: // someone new to talk to ... case gotocol.Put: // upstream request handler ... outmsg := gotocol.Message{gotocol.Replicate, listener, time.Now(), msg.Ctx.NewParent(), msg.Intention} flow.AnnotateSend(outmsg, name) outmsg.GoSend(replicas) } case <-eurekaTicker.C: // poll the service registry ... } } }

Skeleton code for replicating a Put message

Instrument incoming requests

Instrument outgoing requests

update trace context

Flow Trace Records

riak2us-east-1

riak9us-west-2

Put s896

Replicate

riak3us-east-1

riak8us-west-2

riak4us-east-1

riak10us-west-2

us-east-1.zoneC.riak2 t98p895s896 Put us-east-1.zoneA.riak3 t98p896s908 Replicate us-east-1.zoneB.riak4 t98p896s909 Replicate us-west-2.zoneA.riak9 t98p896s910 Replicate us-west-2.zoneB.riak10 t98p910s912 Replicate us-west-2.zoneC.riak8 t98p910s913 Replicate

staashus-east-1

s910 s908s913s909s912

Replicate Put

Open Zipkin

A common format for trace annotations A Java tool for visualizing traces Standardization effort to fold in other formats Driven by Adrian Cole (currently at Pivotal) Extended to load Spigo generated trace files

Zipkin Trace Dependencies

Trace for one Spigo Flow

Definition of an architecture

{ "arch": "lamp", "description":"Simple LAMP stack", "version": "arch-0.0", "victim": "webserver", "services": [ { "name": "rds-mysql", "package": "store", "count": 2, "regions": 1, "dependencies": [] }, { "name": "memcache", "package": "store", "count": 1, "regions": 1, "dependencies": [] }, { "name": "webserver", "package": "monolith", "count": 18, "regions": 1, "dependencies": ["memcache", "rds-mysql"] }, { "name": "webserver-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["webserver"] }, { "name": "www", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["webserver-elb"] } ] }

Header includeschaos monkey victim

New tier name

Tier package

0 = non Regional

Node count

List of tier dependencies

See for yourself: http://simianviz.surge.sh/lamp

Running Spigo$ ./spigo -a lamp -j -d 2 2016/01/26 23:04:05 Loading architecture from json_arch/lamp_arch.json 2016/01/26 23:04:05 lamp.edda: starting 2016/01/26 23:04:05 Architecture: lamp Simple LAMP stack 2016/01/26 23:04:05 architecture: scaling to 100% 2016/01/26 23:04:05 lamp.us-east-1.zoneB.eureka01....eureka.eureka: starting 2016/01/26 23:04:05 lamp.us-east-1.zoneA.eureka00....eureka.eureka: starting 2016/01/26 23:04:05 lamp.us-east-1.zoneC.eureka02....eureka.eureka: starting 2016/01/26 23:04:05 Starting: {rds-mysql store 1 2 []} 2016/01/26 23:04:05 Starting: {memcache store 1 1 []} 2016/01/26 23:04:05 Starting: {webserver monolith 1 18 [memcache rds-mysql]} 2016/01/26 23:04:05 Starting: {webserver-elb elb 1 0 [webserver]} 2016/01/26 23:04:05 Starting: {www denominator 0 0 [webserver-elb]} 2016/01/26 23:04:05 lamp.*.*.www00....www.denominator activity rate 10ms 2016/01/26 23:04:06 chaosmonkey delete: lamp.us-east-1.zoneC.webserver02....webserver.monolith 2016/01/26 23:04:07 asgard: Shutdown 2016/01/26 23:04:07 lamp.us-east-1.zoneB.eureka01....eureka.eureka: closing 2016/01/26 23:04:07 lamp.us-east-1.zoneA.eureka00....eureka.eureka: closing 2016/01/26 23:04:07 lamp.us-east-1.zoneC.eureka02....eureka.eureka: closing 2016/01/26 23:04:07 spigo: complete 2016/01/26 23:04:07 lamp.edda: closing

-a architecture lamp-j graph json/lamp.json-d run for 2 seconds

Riak IoT Architecture{ "arch": "riak", "description":"Riak IoT ingestion example for the RICON 2015 presentation", "version": "arch-0.0", "victim": "", "services": [ { "name": "riakTS", "package": "riak", "count": 6, "regions": 1, "dependencies": ["riakTS", "eureka"]}, { "name": "ingester", "package": "staash", "count": 6, "regions": 1, "dependencies": ["riakTS"]}, { "name": "ingestMQ", "package": "karyon", "count": 3, "regions": 1, "dependencies": ["ingester"]}, { "name": "riakKV", "package": "riak", "count": 3, "regions": 1, "dependencies": ["riakKV"]}, { "name": "enricher", "package": "staash", "count": 6, "regions": 1, "dependencies": ["riakKV", "ingestMQ"]}, { "name": "enrichMQ", "package": "karyon", "count": 3, "regions": 1, "dependencies": ["enricher"]}, { "name": "analytics", "package": "karyon", "count": 6, "regions": 1, "dependencies": ["ingester"]}, { "name": "analytics-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["analytics"]}, { "name": "analytics-api", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["analytics-elb"]}, { "name": "normalization", "package": "karyon", "count": 6, "regions": 1, "dependencies": ["enrichMQ"]}, { "name": "iot-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["normalization"]}, { "name": "iot-api", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["iot-elb"]}, { "name": "stream", "package": "karyon", "count": 6, "regions": 1, "dependencies": ["ingestMQ"]}, { "name": "stream-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["stream"]}, { "name": "stream-api", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["stream-elb"]} ] }

New tier name

Tier package

Node count

List of tier dependencies

0 = non Regional

Single Region Riak IoTSee for yourself: http://simianviz.surge.sh/riak

Single Region Riak IoT

IoT Ingestion Endpoint

Stream Endpoint

Analytics Endpoint

See for yourself: http://simianviz.surge.sh/riak

Stream Endpoint

Analytics Endpoint

Load Balancer

Stream Endpoint

Analytics Endpoint

Load Balancer

Normalization Services

Load Balancer

Stream Service

Analytics Service

Stream Endpoint

Analytics Endpoint

Load Balancer

Enrich Message Queue Riak KV

Enricher Services

Load Balancer

Stream Service

Analytics Service

Stream Endpoint

Analytics Endpoint

Load Balancer

Enricher Services

Ingest Message Queue

Load Balancer

Stream Service

Analytics Service

Stream Endpoint

Analytics Endpoint

Load Balancer

Enricher Services

Ingest Message Queue

Load Balancer

Stream Service Riak TS

Analytics Service

Ingester Service

Two Region Riak IoT

Stream Endpoint

Analytics Endpoint

East Region Ingestion

West Region Ingestion

Multi Region TS Analytics

Two Region Riak IoT

Stream Endpoint

Analytics Endpoint

East Region Ingestion

West Region Ingestion

Multi Region TS Analytics

What’s the response time of the stream

endpoint?

Response Times

What’s the response time distribution of a very simple storage backed web service?

memcached

disk volume

web service

load generator

memcached

See http://www.getguesstimate.com/models/1307

memcached hit %

memcached response mysql response

service cpu time

memcached hit mode

mysql cache hit mode

mysql disk access mode

Hit rates: memcached 40% mysql 70%

Measuring Response Time With

Histograms

Changes made to codahale/hdrhistogram

Changes made to go-kit/kit/metrics

Implementation in adrianco/spigo/collect

What to measure?

Client ServerGetRequest

GetResponse

Client Time

Client Send CS

Server Receive SR

Server Send SS

Client Receive CR

Server Time

What to measure?

Client ServerGetRequest

GetResponse

Client Time

Client Send CS

Server Receive SR

Server Send SS

Client Receive CR

Response CR-CS

Service SS-SR

Network SR-CS

Network CR-SS

Net Round Trip (SR-CS) + (CR-SS) (CR-CS) - (SS-SR)

Server Time

Spigo Histogram ResultsCollected with: % spigo -d 60 -j -a storage -c

name: storage.*.*..load00...load.denominator_serv quantiles: [{50 47103} {99 139263}] From To Count Prob Bar 20480 21503 2 0.0007 : 21504 22527 2 0.0007 | 23552 24575 1 0.0003 : 24576 25599 5 0.0017 | 25600 26623 5 0.0017 | 26624 27647 1 0.0003 | 27648 28671 3 0.0010 | 28672 29695 5 0.0017 | 29696 30719 127 0.0421 |#### 30720 31743 126 0.0418 |#### 31744 32767 74 0.0246 |## 32768 34815 281 0.0932 |######### 34816 36863 201 0.0667 |###### 36864 38911 156 0.0518 |##### 38912 40959 185 0.0614 |###### 40960 43007 147 0.0488 |#### 43008 45055 161 0.0534 |##### 45056 47103 125 0.0415 |#### 47104 49151 135 0.0448 |#### 49152 51199 99 0.0328 |### 51200 53247 82 0.0272 |## 53248 55295 77 0.0255 |## 55296 57343 66 0.0219 |## 57344 59391 54 0.0179 |# 59392 61439 37 0.0123 |# 61440 63487 45 0.0149 |# 63488 65535 33 0.0109 |# 65536 69631 63 0.0209 |## 69632 73727 98 0.0325 |### 73728 77823 92 0.0305 |### 77824 81919 112 0.0372 |### 81920 86015 88 0.0292 |## 86016 90111 55 0.0182 |# 90112 94207 38 0.0126 |# 94208 98303 51 0.0169 |# 98304 102399 32 0.0106 |# 102400 106495 35 0.0116 |# 106496 110591 17 0.0056 | 110592 114687 19 0.0063 | 114688 118783 18 0.0060 | 118784 122879 6 0.0020 | 122880 126975 8 0.0027 |

Normalized probability

Response time distribution measured in nanoseconds using High Dynamic Range Histogram

:# Zero counts skipped|# Contiguous buckets

Median and 99th percentile values

service time for load generator

Cache hit Cache miss

Go-Kit Histogram Exampleconst ( maxHistObservable = 1000000 // one millisecond sampleCount = 1000 // data points will be sampled 5000 times to build a distribution by guesstimate )

var sampleMap map[metrics.Histogram][]int64 var sampleLock sync.Mutex

func NewHist(name string) metrics.Histogram { var h metrics.Histogram if name != "" && archaius.Conf.Collect { h = expvar.NewHistogram(name, 1000, maxHistObservable, 1, []int{50, 99}...) sampleLock.Lock() if sampleMap == nil { sampleMap = make(map[metrics.Histogram][]int64) } sampleMap[h] = make([]int64, 0, sampleCount) sampleLock.Unlock() return h } return nil }

func Measure(h metrics.Histogram, d time.Duration) { if h != nil && archaius.Conf.Collect { if d > maxHistObservable { h.Observe(int64(maxHistObservable)) } else { h.Observe(int64(d)) } sampleLock.Lock() s := sampleMap[h] if s != nil && len(s) < sampleCount { sampleMap[h] = append(s, int64(d)) sampleLock.Unlock() } } }

Nanoseconds resolution!

Median and 99%ile

Slice for first 500 values as samples for export to Guesstimate

Golang Guesstimate Interfacehttps://github.com/adrianco/goguesstimate

{ "space": { "name": "gotest", "description": "Testing", "is_private": "true", "graph": { "metrics": [ {"id": "AB", "readableId": "AB", "name": "memcached", "location": {"row": 2, "column":4}}, {"id": "AC", "readableId": "AC", "name": "memcached percent", "location": {"row": 2, "column":3}}, {"id": "AD", "readableId": "AD", "name": "staash cpu", "location": {"row": 3, "column":3}}, {"id": "AE", "readableId": "AE", "name": "staash", "location": {"row": 3, "column":2}} ], "guesstimates": [ {"metric": "AB", "input": null, "guesstimateType": "DATA", "data": [119958,6066,13914,9595,6773,5867,2347,1333,9900,9404,13518,9021,7915,3733,10244,5461,12243,7931,9044,11706,5706,22861,9022,48661,15158,28995,16885,9564,17915,6610,7080,7065,12992,35431,11910,11465,14455,25790,8339,9991]}, {"metric": "AC", "input": "40", "guesstimateType": "POINT"}, {"metric": "AD", "input": "[1000,4000]", "guesstimateType": "LOGNORMAL"}, {"metric": "AE", "input": "=100+((randomInt(0,100)>AC)?AB:AD)", "guesstimateType": "FUNCTION"} ] } } }

See http://www.getguesstimate.com % cd json_metrics; sh guesstimate.sh storage

@adrianco

Simplicity through symmetry

SymmetryInvariants

Stable assertionsNo special cases

What’s Next?

Trends to watch for 2016:

Serverless Architectures - AWS Lambda

Teraservices - using terabytes of memory

Serverless Architectures

AWS Lambda getting some early wins

Google Cloud Functions, Azure Functions alpha launched

IBM OpenWhisk - open sourced

Startup activity: iron.io , serverless.com, apex.run toolkit

With AWS Lambda compute resources are charged

by the 100ms, not the hour

First 1M node.js executions/month are free

Teraservices

Terabyte Memory Directions

Engulf dataset in memory for analytics

Balanced config for memory intensive workloads

Replace high end systems at commodity cost point

Explore non-volatile memory implications

Terabyte Memory Options

Now: Diablo DDR4 DIMM containing flash 64/128/256GB Migrates pages to/from companion DRAM DIMM Shipping now as volatile memory, future non-volatile

Announced but not shipped for 2016 AWS X1 Instance Type - over 2TB RAM Easy availability should drive innovation

Diablo Memory1: Flash DIMM

NO CHANGES to CPU or Server

NO CHANGES to Operating System

NO CHANGES to Applications✓ UP TO 256GB DDR4 MEMORY PER MODULE

✓ UP TO 4TB MEMORY IN 2 SOCKET SYSTEM

Learn More…

@adrianco

“We see the world as increasingly more complex and chaotic because we use inadequate concepts to explain it. When we understand something, we no longer see it as chaotic or complex.”

Jamshid Gharajedaghi - 2011Systems Thinking: Managing Chaos and Complexity: A Platform for Designing Business Architecture

Q&AAdrian Cockcroft @adrianco

http://slideshare.com/adriancockcroftTechnology Fellow - Battery Ventures

See www.battery.com for a list of portfolio investments

Security

Visit http://www.battery.com/our-companies/ for a full list of all portfolio companies in which all Battery Funds have invested.

Palo Alto Networks

Enterprise IT

Operations & Management

Big DataCompute

Networking

Storage