We see a move of servers move from virtualization (cattle) to process separators (bacteria). What will the impact be to have servers that last only last as long a single process? At New Relic, we have customers monitoring Docker containers that last 5 minutes or less. How can organizations plan, develop and operate software in this environment? I’ll provide insights we gathered from our customers and from our own internal use of containers and short-lived servers.
Since they are cheap to startup and more efficient to run than bare metal or VMware VMs, you don't need to nor want to keep them around. The "shoot em" part is not only when they're done but if they're not behaving right it's easier just to start a new one and kill off the old.
Containers *can* be short lived to just accomplish a task, and that's a pattern you can't support with VMs. The lifecyle matches the usage and the usages are much broader than VMs.
As noted, this is still early days. Docker usage patterns are not standard across the industry. People use Docker in unique and unexpected ways—something we discovered with this data—and there is no one single solution that will cater to the entire Docker market. The products we develop have provided visibility into containerized applications.
New Relic has 35,000+ Customers
large volume of containers (generated by multiple customers) lasting less than 5 minutes indicates the potential for net new application architectures using containers for periods of time far less than the amount of time typically needed to activate a virtual machine. Our suspicion is that the long-running servers may be proof-of-concept lightweight VMs that have been left running.
1=100s 3=1000s 5=100,000s 6=1,000,000s
Here we see raw container volumes by minute for containers with lifespans of less than an hour.
How about the lifespan question? The chart below shows a log scale of container lifespans by hour. For the containers that last for days or a week, the use case is likely medium lifespan servers (cattle!). Our suspicion is that the long-running servers may be proof-of-concept lightweight VMs that have been left running.
Centurion is a tool to centrally manage configurations for fleets of Docker services and it has been instrumental in formalizing the handoff between developers and system administrators. Can support Amazon S3 via external tools.
From Pets to Cattle to Bacteria OSCON BOF
From Pets to Cattle to Bacteria
Pet Photo: Chicken, the best dog ever
Cattle Photo: John Comloquoy
Bacteria image: R. Muir, Bacteriological Atlas
Server attached to particular
Servers typically on site
Own and maintain
Name and become attached
Improved resource utilization
Typically off site
Problems? Just delete
VMs are “heavyweight”
Images are hard to upload
Typically “long lived”
A process isolator
Alive for minutes
• Docker Monitoring Beta since May
• 300 New Relic customers
• 40,000 to 60,000 containers daily
• > 2 million containers
• Disclaimer: it’s early!
New Relic CustomersUsing Docker
What To Monitor
• Monitoring servers
makes less sense
F O R D E V E L O P E R S
Iterate fast and often
Containers aren’t VM replacements
Single container for a single process
Processes working together to solve a problem
• New Relic 5th largest generator of data in the world
• Using Docker for 1.5 years
• Our Engineers have written the book!
• From zero to using it for deployment of a
huge release in 2 months
• Started with simplest web apps
• “We generate bacteria”
• One process to create info and another to clean it up
New Relic Use of Docker
• Docker Deployment Tool for repeatable deployments
1. Build ships container to Docker registry
2. Centurion sends container to Docker fleet
• Developers can deploy apps
• Open source tool
• GitHub: Newrelic/centurion
• Ruby Gem
• Implementing Docker in Production at Scale
This image is the work of Luc Viatour
F O R O P E R A T I O N S
Measure images, not servers
Containers can provide 4-6x more capacity than VMs
Update dependencies in sync w releases
Separate builds from deployment
Lower the bar for developer use of Docker
Start simple: high throughput apps should not be the first thing you Dockerize