Zero to Microservices in 5 minutes using Docker Containers Mathew Lodge (@mathewlodge) Weaveworks (@weaveworks) https://www.weave.works/
2
Going faster with software delivery is now a business issue Software is eating the world The old IT/software model is too slow Customers expect pace of innovation of Google, Facebook, Uber, Netflix, Amazon in all things Velocity comes from microservices approach & rest of market wants to do the same Microservices/DevOps to go faster Smaller teams combining dev & ops roles, working on smaller services vs. single large code base Each microservice team picks its own tech and self-services Table stakes: open source, cloud, s, continuous integration
Problem: Microservices also increase complexity Source: Adrian Colyer 4
New class of microservices infrastructure is emerging Scheduling / Orchestration Create Microservices, Manage and Control them Extreme simplicity and speed Add value alongside any platform choice, or standalone Packaged and priced for bottoms-up team adoption SDN Config Microservices infrastructure Visualization Provision API Routing Data persist Containers Programmable infra 5
A typical microservice scenario Client Client Client API proxy / load balancer Replica 1 Replica 2 Replica 3 6
How this used to work in Docker Docker host 1 Docker host 2 Client Worker 8080 80 8443 443 7
Docker Networking introduced in v1.9 Docker host 1 Docker host 2 Client Worker 80 443 Ethernet bridge on Docker host VXLAN tunnel between hosts Ethernet bridge on Docker host 8
Microservice on Docker 1.9 Client A Client B Docker Docker host host config config Client C Cluster Store Consul 1 VM HA Proxy / nginx Container SDN Consul 2 VM Worker X Worker Y Worker Z Consul 3 VM 9
Using Weave Net to make things simpler Cluster Store Client A Client B Client C Consul 1 VM Weave Net [ Micro DNS ] Container SDN Consul 2 VM Worker X Worker Y Worker Z Consul 3 VM 10
Demo Up and running in less than 5 minutes Built-in service discovery
How it works Weave router runs on each Docker host Allocates IP addresses to s Maintains IP address to DNS name mapping Responds to DNS lookups on names Gossips updates to other routers, builds eventually consistent cache Inter-host connectivity via VXLAN All s on local bridge Local bridges connected via VXLAN Linux Host Docker Client x Replica n Weave router/dns Weave Docker proxy Server/VM/AWS/Azure/GCP Other hosts 12
Plug-in architectures today Docker Kubernetes Docker Networking CNI API Libnetwork API 3 rd Party libnetwork Plugin 3 rd Party CNI Plugin Underlay Network Underlay Network 13
Simple deployment on AWS ECS AWS Autoscaling Group Weave ECS AMI Weave ECS AMI Weave ECS AMI Weave ECS AMI Zero configuration beyond starting instances in auto-scale group: Weave Net automatically finds other Weave routers via Autoscale Groups API 14
Traditional 3-tier architecture Incoming traffic Load balancers Application servers Database and replica
Microservice architecture Web UI Public API Services Message Broker Database NoSQL servers
Monitoring microservices is different Netflix USE*: Utilization Saturation Error rate Utilization metrics (Success) response times Queue depth Saturation metrics CPU Memory IO bandwidth Network bandwidth Error metrics Non 2xx HTTP response rate No response rate * http://www.brendangregg.com/usemethod.html
Traditional monitoring systems focus on saturation only
Need topology information to use USE
Weave Scope Microservice-centric monitoring Live topology No instrumentation, no configuration 100% interactive
But how do we get Utilization and Error rates?
Weave Flux demo 22
Thank you! http://www.weave.works/
Weave eventually consistent in-memory DB (AP from the CAP theorem) 24