Microservices are small, autonomous services that work together to form an application. The document discusses the benefits of microservices as well as the "Seven Deadly Sins" that can plague microservices architectures: lust, gluttony, greed, sloth, wrath, envy, and pride. It provides examples and recommendations to avoid these anti-patterns, such as implementing circuit breakers, proper service boundaries, independent deployments, versioned APIs, and thorough automated testing.

1. Microservices
– The 7 Deadly Sins
Cork ALT.NET Feb 2016

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

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

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

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

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

8. 7 Deadly Sins..

9. Lust MmmmMmm shiney!

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

11. Gluttony MmmmMmm … free resources

12. the circuit breaker…

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

14. Greed
Need to make more..

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

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

17. I can’t do anything by
myself
Sloth

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

19. Wrath
Beware distributed
system !
Wrath

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

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

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

24. Blue-Green Deployment

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

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

27. Pact – Consumer Driven Contract Test

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

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

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

31. Recommended Reading