The 7 deadly sins of micro services

Microservices – The 7 Deadly Sins

Cork ALT.NET Feb 2016

Agenda• Overview• Benefits• The Seven Deadly Sins • Questions & Wrap Up

• Small autonomous services that work together• Focused on one business capability and doing it well• Deploy independently• Scale independently• No centralised, shared database

Benefits• Optimized for change• More resilience • Forces you to deal with eventual consistency• Increased productivity - smaller teams on smaller codebases work faster

• Freedom to pick the right technology for each service

Adopters• Netflix• eBay• Amazon• Gilt• REA• Twitter• PayPal• SoundCloud• Hailo• Uber• Google• Cloud Foundry and

many more…

Portal PracticeApp

Third PartyApp

API Gateway

STS (OAuth) Contact (CRM) Provisioning User Mgt FeaturesToggles

Doc Storage

WorkflowTax Prep Notification

Tax LodgementBusiness Event Digital Signing

ConversationLedger

Desktop client

SyncService

Client Portal

LedgerAggregator

Stat Reporting Log Aggregator

7 Deadly Sins..

Lust MmmmMmm shiney!

• Start small• You need a great DevOps culture to make Microservices work• Don't have too many variations between each tech stack• Get current stay current• Consider operations whenever you add new technology• Create a stencil project / service template – this should be

immediately deployable and kept up to date

Gluttony MmmmMmm … free resources

the circuit breaker…

https://github.com/App-vNext/Polly

// break the circuit after the specified number of exceptions// and keep circuit broken for the specified duration

var policy = Policy .Handle<ServiceUnavailableException>() .CircuitBreaker(2, TimeSpan.FromMinutes(1));Policy.Execute((=>YourAPICall))

Greed Need to make more..

• A microservices that do little more than expose a CRUD style interface result in an anemic data models that won’t be reused

• Start bigger, when you feel that a section of one a services needs to be scaled independently from the rest of the functionality, that's a good indicator of a need to create a separate microservice.

• Appoint service owners / custodians for each service.

Conway’s Law

“Organizations which design systems ... are constrained to

produce designs which are copies of the

communication structures of these organizations”

— M. Conway 1967

I can’t do anything by myselfSloth

• 1 service per repo • 1 pipeline per service• Build once, deploy many times• Version all API contracts• Service locator

Wrath

Beware distributed system !Wrath

• Know what “normal” looks like for each microservice and the overall system

• Information Radiators & Dashboards• Pass CorrelationIDs in all message headers• Use synthetic transactions in production• Realtime telemetry & dashboards• Alerts when auto scaling happens & synthetic transactions fail

EnvyI’ll be deploying to

production in 2 weeks time

• Embrace continuous delivery as an organisation• Doing something all the time takes the pain out of it & makes you

good at it• Feature Switch everything• Rethinking configuration – prefer convention over configuration• Immutable Infrastructure• Releasing a feature and turning it on are 2 separate things• Every code change is backward compatible• Blue Green Deployments

Blue-Green Deployment

PrideI don’t write buggy code, no need for automated tests !

Unit

Service

UI

Faster, more isolated

Increased scope and slower

Pact – Consumer Driven Contract Test

• It forces a conversation between the consumer and the provider • Pact tests are easy to run standalone as part of a CI build pipeline or

on anyone's dev machine• Best part is you end up with a standalone CI pipeline for each service

but within this pipeline we get to verify all expectations of the consumers of the service !

• Gives consumers a safety net - their tests are continually run as part of the API providers CI pipeline

• Pact broker - gives a picture of all the API consumers & the API call graphs

E2E User Journey Tests• pick a handful of key workflows across your application ( less than 10)• Brittle and expensive to maintain so choose wisely• Never let them break• Don’t be afraid to throw them away and create new ones over time

Summary

• Lust –chasing shiney new technology & tools• Gluttony - no circuit breakers to prevent cascading failures• Greed – creating too many services with the wrong bounded contexts• Sloth – creating a distributed monolith• Wrath – ignoring the wrath of distributed systems• Envy – your build and deploy process must be a joy to behold • Pride – fooled into thinking you don’t need proper tests

Recommended Reading