Breaking down your monolith into microservices — or starting fresh with a microservice architecture on a new project — is only half the battle. The next step is making your containerized microservice application fault tolerant and highly available, but how do you get there? How do you go from your local development machine to a production-grade cluster? See how container orchestration platforms like Kubernetes and Swarm can be essential assets for your production workloads, and learn how to replace bottlenecks and single points of failure with highly available, scalable microservice deployments.
35. Most modern orchestration systems use
an optimized scheduling algorithm for
dispatching services across a set of nodes.
G R E AT N E W S
36. It is not your tool’s responsibility to know about your
system and business constraints
• topology* (some schedulers are topology aware)
• specifics like OS, kernel, instance family
• PII and other compliance
YO U S T I L L H AV E TO D O W O R K
37. These tools work on the service
level, not the infrastructure level
R E M I N D E R
38. Scheduling Constraints
Restrict services to specific nodes, such as
specific architectures, security levels, or types,
first apply a label to the nodes
docker service create
--constraint 'node.labels.type==web' my-app
in Docker
39. nodeSelector has been around since 1.0, but there
are alternatives which are more expressive
nodeAffinity has been around since 1.2 (still in beta).
nodeAntiAffinity does the opposite — you can repel
things from one another.
in Kubernetes
Scheduling Constraints
42. Implements a spread strategy over nodes that belong to a
certain category.
This is a “soft” preference
--placement-pref ‘spread=node.labels.key’
in Docker
Placement Preferences
46. Topology-aware Scheduling
Kubernetes has a topology-aware scheduler! Read the docs.
In Docker, apply labels to your nodes, and use a placement
preference like:
--placement-pref ‘spread=node.labels.region’
47. An Imprecise Guideline
ignoring most constraints
redundancyrequired
(numberofreplicas)
time to recover from failure (hypothetical time units)
57. C O M M O D I T I Z AT I O N
If you have a hand-rolled solution for
running apps with containers, it’s safe
to migrate to an orchestration platform.
58. I N N OVAT I O N
Solutions to old problems get
commoditized, but it leaves room
for genesis elsewhere
59. Genesis Custom Built Product Commodity
Container
Orchestrator
Container Runtime
InvisibleVisible
?
?
?
Istio & service mesh tools
Whatever Heptio is building
Storage!
61. How can we guarantee
availability in an environment
that will definitely fail?
62. DISTRIBUTED APPLICATIONS ENGINEERING, 1998
“Redundancy and recovery are
the two main approaches to
solve this problem.”
Google became a company in 1998!