The 7 deadly sins of micro services

1. Microservices
– The 7 Deadly Sins
IT event @ Morgan McKinley August 2016

2. CTO Wavebreak Media
MVP Microsoft Azure
@AIDANJCASEY

3. Agenda
• What are Microservices
• Benefit of a Microservices architecture
• The Seven Deadly Sins
• Questions & Wrap Up

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

6. Benefits
• Optimized for change
• Optimized for experimentation
• Encourages ownership & accountability within development
teams
• 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
(multiple languages and frameworks)

7. Adopters
• Netflix
• eBay
• Amazon
• Gilt
• REA
• Twitter
• PayPal
• SoundCloud
• Hailo
• Uber
• Google
• Cloud Foundry and many many more…

8. Portal Practice
App
Third
Party
App
API Gateway
STS (OAuth) Contact (CRM) Provisioning User Mgt Features
Toggles
Doc Storage
Workflow
Tax Prep
Notification
Tax Lodgement
Business Event Digital Signing
ConversationLedger
Desktop
client
Sync
Service
Client
Portal
Ledger
Aggregator
Stat Reporting Log Aggregator

9. 7 Deadly Sins..

10. Lust MmmmMmm shiney!

11. • 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

12. Gluttony MmmmMmm … free resources

13. the circuit breaker…

14. 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))

15. Greed
Need to make more..

16. • 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.

17. 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

18. Two Pizza rule = better productivity

19. I can’t do anything by
myself
Sloth

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

21. Wrath
Beware distributed
system !
Wrath

22. • Know what “normal” looks like for each microservice and the overall system
• Information Radiators & Dashboards
• Pass CorrelationIDs in all message headers and log things consistently
• Use synthetic transactions in production
• Realtime telemetry & dashboards
• Alerts when auto scaling happens & synthetic transactions fail

24. Envy
I’ll be deploying to
production in 2 weeks
time

25. • 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

26. Blue-Green Deployment

27. Pride
I don’t write buggy code,
no need for automated
tests !

28. Unit
Service
UI
Faster, more isolated
Increased scope and slower

29. Pact – Consumer Driven Contract Test

30. • 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

31. 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

32. 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

33. Recommended Reading
https://microserviceweekly.com/