Microservices are small services with independent lifecycles that work together. There is an underlying tension in that definition – how independent can you be when you have to be part of a whole? I’ve spent much of the last couple of years trying to understand how to find the right balance, and in this talk/tutorial I’ll be presenting the core seven principles that I think represent what makes microservices tick.
After a brief introduction of what microservices are and why they are important, we’ll spend the bulk of the time looking at the principles themselves, wherever possible covering real-world examples and technology:
- Modelled around business domain – using techniques from domain-driven design to find service boundaries leads to better team alignment and more stable service boundaries, avoiding expensive cross-service changes.
- Culture of automation – all organisations that use microservices at scale have strong cultures of automation. We’ll look at some of their stories and think about which sort of automation is key.
- Hide implementation details – how do you hide the detail inside each service to avoid coupling, and ensure each service retains its autonomous nature?
- Decentralize all the things! – we have to push power down as far as we can, and this goes for both the system and organisational architecture. We’ll look at everything from autonomous self-contained teams and internal open source, to using choreographed systems to handle long-lived business transactions.
- Deploy independently – this is all about being able to deploy safely. So we’ll cover everything from deployment models to consumer-driven contracts and the importance of separating deployment from release.
- Isolate failure – just making a system distributed doesn’t make it more stable than a monolithic application. So what do you need to look for?
- Highly observable – we need to understand the health of a single service, but also the whole ecosystem. How?
In terms of learning outcomes, beginners will get a sense of what microservices are and what makes them different, whereas more experienced practitioners will get insight and practical advice into how to implement them.
11. @samnewman@velocityconf
Strategic Goals
Architectural
Principles
Design and Delivery
Practices
Enable scalable
business
More customers/transactions
Self-service for customers
Support entry into
new markets
Flexible operational processes
New products and operational
processes
Support innovation
in existing markets
Flexible operational processes
New products and operational
processes
Reduce inertia
Make choices that favour rapid
feedback and change, with reduced
dependencies across teams.
Eliminate accidental
complexity
Aggressively retire and replace
unnecessarily complex processes,
systems, and integrations so that we
can focus on the essential
complexity.
Consistent interfaces
and data flows
Eliminate duplication of data and
create clear systems of record, with
consistent integration interfaces.
No silver bullets
Off the shelf solutions deliver early
value but create inertia and
accidental complexity.
Standard REST/HTTP
Encapsulate legacy
Eliminate integration
databases
Consolidate and
cleanse data
Published integration
model
Small independent
Services
Continuous
deployment
Minimal customisation
of COTS/SAAS