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