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