Industry adoption of microservices and Docker Microservice deployments vs monolithic deployments Container orchestration and scaling tools Optimizing microservices deployments Environment health

1. Managing and scaling microservices with Docker
in the wild
Alois Mayr
@mayralois
alois.mayr@ruxit.com
Oct 27th 2015

2. Industry adop>on of microservices
Microservices deployments vs monolithic deployments
Container orchestra>on and scaling
Op>mizing microservices deployments
Is my environment healthy?
Agenda

3. Who we are and what we do

5. When people talk about cloud-scale companies...

7. Industry adop-on of microservices
Microservices deployments vs monolithic deployments
Container orchestra>on and scaling
Op>mizing microservices deployments
Is my environment healthy?

11. h+ps://ruxit.com/docker

12. Industry adop>on of microservices
Microservices deployments vs monolithic deployments
Container orchestra>on and scaling
Op>mizing microservices deployments
Is my environment healthy?

13. Credit: Slavoljub Pantelic/Shu+erstock.com

14. Monolithic deployment: 10-20 services per process

15. Microservices applicaFon: 1 service per process
20 Fmes the number of JVMs!

16. Monolithic Deployment of Services
Full Micro Service Deployment using Containers
Service-oriented APM doesn’t expose JVM explosion within
microservices architectures

17. 7:00 a.m.
Low load, service running
with minimum redundancy
12:00 p.m.
Scaled up service during peak load
with failover of problemaFc node
7:00 p.m.
Scaled back down to lower load,
move to different geolocaFon
Deployments are no longer staHc

18. Microservices architectures can be complex

19. Industry adop>on of microservices
Microservices deployments vs monolithic deployments
Container orchestra-on and scaling
Op>mizing microservices deployments
Is my environment healthy?

20. h+p://radar.oreilly.com/2015/10/swarm-v-fleet-v-kubernetes-v-mesos.html
Marathon EC2 Container Service

21. Common features of orchestraHon tools
• DistribuFon of containers within a cluster
• Pre-configured by use of DSL
• Pooling and co-locaFng containers/services by various concepts
• Pods, labels, tags, task descripFons, etc.
• Resource scheduling within a cluster
• Scaling of resources/containers
• Service health checks
• Zero-downFme fail-over mechanisms
• Networking - SDNs

22. Fail-over containers across datacenters
1. Failed container
2. New container

23. Low-traffic service: 2 running containers
Running
containers
Failed container
Low traffic

24. Container view: traffic/load
Container is underuFlized
(Tomcat is idle)
Tomcat receives requests
for about 15 hrs
1 service per Tomcat

25. Killing containers when in failure mode
Failure rate for health check increased

26. Shortcomings of exisHng approaches
• StaFc pre-configured container orchestraFon
• Manually adjusted number of running containers
• Health checks may not reflect service funcFonality/availability
• Scheduling based on infrastructure metrics:
• Network traffic
• CPU uFlizaFon
• Absence of service-oriented scheduling

27. MisconfiguraFon can kill orchestraFon layer
Queue and deployment methods are slow

28. Industry adop>on of microservices
Microservices deployments vs monolithic deployments
Container orchestra>on and scaling
Op-mizing microservices deployments
Is my environment healthy?

29. What’s important
1. Which services are to be co-located?
• Relate services to infrastructure
• Cascading services impact scheduling (snowball effect)
2. Capacity planning
• How many resources are required?
• Infrastructure and container metrics
3. What’s the ideal number of containers per service?
4. Service deployment validaFon
• What are the effects of scaling services?

30. #1 – Who calls who?

31. #1 – Who calls who?

32. #1 – Who calls who?

33. #1 – Who calls who?
Most Fme spent in Credit Card VerificaFon service

34. #2 – Capacity planning
• OrchestraFon tools can use tags/labels
• Affinity and constraint rules
• Capacity planning based only on key metrics is insufficient
• CPU, Memory
• Network IO is important
in microservices architectures

35. #1 – Which services to be co-located? #2 – Capacity planning includes network IO

36. #3 – Ideal number of containers per service?
• Depends on workload and service dependencies
• Called and calling services
• # Requests/min and slowest 10% response-Fme
• Can be derived from monitoring data via API
• h+ps://blog.ruxit.com/ruxit-data-export-api/

37. #4 – Service deployment validaHon
APP1
APP2
APP1 depends on APP2
Where is this specified?
• Resource planning and scheduling is wasted if deployments deviate from plan

38. Industry adop>on of microservices
Microservices deployments vs monolithic deployments
Container orchestra>on and scaling
Op>mizing microservices deployments
Is my environment healthy?

39. Container metrics aren’t enough

40. Health depends on many components and variables!

41. Be+er to ask:
What broke?
What sFll works?

42. 820 BILLION dependencies!
Problem resoluFon is a scalability problem
Way too many components involved
The Mushroom cloud effect Network problem

43. 1. /logs ran out of space
2. /var/lib/docker ran out of space

44. Free trial - h+ps://ruxit.com/docker-monitoring/
Blog - h+ps://blog.ruxit.com/
@ruxit
Try Ruxit for free!
Work with us. Share your feedback
alois.mayr@ruxit.com