Operating Microservices

Michael Brunton-Spall
Technical Architect
Government Digital Service
@bruntonspall

InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/microservices-devops-patterns

Presented at QCon London
www.qconlondon.com
Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide

I'm a civil servant
GDSMichael Brunton-Spall

This isn’t the crown’s
opinion on micro-services

Because everyone has an
opinion

What am I not going to
cover?

What are micro-services

How to develop them

Micro-service patterns

So what are micro-services?

Vertically aligned stacks that
communicate via simple and
standard interfaces

Ownership of data

Team ownership of code

Team ownership of code
and runtime

Small is beautiful

Why are we all raving about
them?

Because small owned
systems can be updated
more easily and frequently

Because teams can move
fast and break stuff

Because teams can own the
whole stack

So why do infrastructure
teams hate them?

“Microservices represent a
new organisational model
as much as a new
architectural model”
@JeffSussna

You (Engineering and
Operations) exist purely for
the beneﬁt of the business

Micro-services can help you
have a radical focus on
delivering business value

The role of engineering and
operations is changing

Operations is the constraint

Operations is perceived as
the constraint

Micro-services in the small

How can we get started?

Start small

Automate infrastructure or
containers

Base Image

Base Image = Ubuntu LTS

Base Image + Cloud Init

Cloud Init = "apt-get update;
apt-get install xxx"

Base Image + Cloud Init +
Deployed Application

Deployed Application =
"wget URL_TO_JAR; java -
jar application.jar"

Time to new server = 1-2
minutes

Why is this useful?

Developer stupidity should
have a business impact

Monitoring tools that are
easy to hook into

Developers can create a
new metric and graph it

"If it moves, graph it. If it
doesn't move, graph it
anyway just in case it does”
@lozzd

Automate log aggregation

ElasticSearch, LogStash,
Kibana

Cloud-friendly databases

Automate deployments

Hand the keys for
deployment to developers

Keep logs of deploys

(Graph them even!)

Alerting

(Sensu Screenshot)

Give developers pagers too

Developers should be
exposed to the pain they
cause

Developers having root on
their service?

"You break it, you ﬁx it"

"You break it and cost £X
million, you take the blame"

Automate Infrastructure
Monitoring tools
Log aggregation
Databases
Automated deployments
Alerting

These are all solved
problems

You are not *that* special

Most of what you do is
wrapping libraries and other
peoples code

Pareto principle

You now have a single, well
supported micro service

Microservices in the large

Microservices are going to
fail in more spectacular
ways than equivalent
monoliths

Simple

Simple
Complicated

Simple
Complicated
Complex

Diagnosis tools

Someone will have to do
diagnosis across all the
services

How are services
monitored?

Shallow Check - Is my
service working

Deep check - Are my
dependencies working?

Average response time isn't
enough

90%, 95%, 99% as well

Distributed systems need to
embrace failure

Partitions are network
breaks and latency spikes

Timeouts are tricky, use with
care

Standardise admin
interfaces

Alerting tools

If citizens can’t submit a
claim at 1am because the
mainframe is down, who’s
problem is that?

You still need 1st line
support and triage

What about when the
developers get bored?
(They do that!)

Maturity model for support?

System must have < N
faults in M weeks and
complete run book to be
handed off

Systems that have more
than N faults in M weeks get
handed back

Who pays for this support?

Operations teams should
act like consultants

"You want an elastic search
cluster, sure we'll help you
…”

"... if we can document and
automate it (+20% effort)"

Pioneers pay the cost

Settlers pave the roads
behind

Everyone else follows

Don't forget to keep the
lights on at the monolith

Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations/
microservices-devops-patterns

Operating Microservices

Recommandé

Recommandé

Contenu connexe

Plus de C4Media

Plus de C4Media (20)

Dernier

Dernier (20)

Operating Microservices