Download as PDF, PPTX
Uploaded byJohn D
Making Developers Happier with Mesos, Docker and Marathon
The document outlines the evolution of software architecture from monolithic to microservices over the past few years, highlighting the challenges faced with unhealthy services, resource consumption, and deployment issues. It introduces Platform as a Service (PaaS) as a solution that enables developers to focus on applications rather than infrastructure, while also promoting resilience and scalability. Additionally, it discusses improvements such as canary deployments and implicit service discovery to address the problems identified.
More Related Content
Similar to Making Developers Happier with Mesos, Docker and Marathon
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
Making Developers Happier with Mesos, Docker and Marathon
- 1. Making Developers Happier with Mesos,Docker and Marathon 1
- 2. 2015 Architecture Trajectory ● Ageof the Monolith (5 Years Ago) ○ Monolithic UI ○ Monolithic Backend ○ Unit and Manual Testing ○ Monthly Deployments ○ Infrastructure Monitoring
- 3. 2015 Architecture Trajectory ● Ageof the Service-Oriented Arch. (3 Years Ago) ○ Coarse Grained Services (Tomcat) ○ Unit and Service Level Testing ○ Hardware provisioned via Puppet ○ Weekly Deployments ○ Infrastructure Monitoring ○ Graphite Dashboards
- 4. 2015 Architecture Trajectory ● Ageof the Micro Architecture (1 Year Ago) ○ HTTP Microservices ○ Docker Managed ○ Unit, Functional Testing ○ On Demand Deployment ○ Infrastructure Monitoring ○ Application Monitoring
- 5.
- 6.
- 7. 2015 The Problem(s) • UnhealthyServices • Bad Actors • Static Deployment Topologies • Explicit Service Discovery • All Or Nothing Deployments 7
- 8. 2015 The Solution -PaaS • Platform as a Service • You can focus on your application, not the infrastructure • We can focus on making the platform resilient and self-healing 8
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. 2015 The Problem • UnhealthyServices • Extended service outages. • If your services crashes you have to restart it. • This leads to extended service outage windows as you investigate or roll back. 20
- 21.
- 22. 2015 The Problem • BadActors • There’s nothing to prevent a service from consuming all the resources on a box, starving it’s neighbors. 22
- 23.
- 24. 2015 The Problem • StaticDeployment Topologies • All your services have the same number of instances. • If you want to scale, you need to add more machines. 24
- 25.
- 26.
- 27.
- 28. 2015 The Problem • ExplicitService Discovery • Your application has to know where downstream services are. • It’s explicit in the app, but it should be implicit in the plumbing. • foo.services.prod.yodle.com, foo.services.qa.yodle.com 28
- 29.
- 30.
- 31. 2015 The Problem • Allor Nothing deployments • Your app is deployed or not. • If there are problems in production, you have to roll back. • Deployment problems keep you up too late. 31
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58. 2015 • Unhealthy Services HealthyServices • Bad Actors Customizable Resources • Static Deployment Topologies Easy Scaling • Explicit Service Discovery Implicit Service Discovery • All Or Nothing Deployments Canary Deployments The ProblemsSolutions
- 59.
- 60.
- 61. 2015 All images arecopyright of their respective owners.