At Joyent, we pride ourselves on making systems easier to operate, without ever compromising security or performance. That's at the foundation of our decade-long investment in container technology, and why private data center operators choose our data center orchestration software to securely and conveniently manage their infrastructure. That unrelenting drive to simplify solutions was behind our implementation of Docker services and reintroduction of our data center orchestration solution as Triton last year. It's also driving our efforts to automate application operations and orchestration to take advantage of containerized infrastructure.

One of the first Docker demos I prepared for Triton was a database; not a trivial, stateless app, but an app with real operational complexity. I took on that challenge to demonstrate how truly container-native infrastructure could make application operations easier. ...How we could automate complexity for greater reliability.

The implementation was unique to that app, but it highlighted operational needs of every application:

1. The application must register itself in a discovery catalog
2. The application must look to the discovery catalog to find the other apps it depends on
3. The application must configure itself when the container starts

We've done a number of implementations since then, and those three responsibilities of a modern app—an app that's part of other apps—have been repeated in every one of them. We've added more detail to those steps, and some apps require more work than others, but those details have service to strengthen our conviction that the best way to orchestrate an app is within the app.

To make it easier to make all the applications we implemented in containers meet those responsibilities, we created a small helper application that runs inside each container. We called that helper app Containerbuddy and released it to the world in Github in October 2015. That's allowed us the great pleasure of working with open source contributors and our own customers—people running on Triton and elsewhere—to develop this approach to self-operating apps.

As we worked with a growing community and took on ever more complicated applications, we realized that the pattern we were using needed a descriptive name to make it easier to discuss separately from any specific implementation. The most descriptive and technically accurate name we could find is "the autopilot pattern."

And now we're renaming renaming Containerbuddy to ContainerPilot to simplify and clarify the relationship between autopilot pattern—the approach to automating our applications—and ContainerPilot—the shared library that makes it easy to build autopilot pattern applications¹.

ContainerPilot is fully backwards compatible with Containerbuddy, but the name is part of the API, so this change triggers a semver major version increment, making it ContainerPilot 2.0.

Our roadmap includes some exciting new features and enhancements, but we're staying true to our original vision: a lightweight, app-centric orchestration solution. Watch the ContainerPilot issues in Github to follow the latest news on the following and more:

1. Telemetry to support application scaling decisions
   • Release: Monitoring and scaling applications with ContainerPilot telemetry
   • Discussion: #27
   • PR: #119
2. Break out functionality into reusable modules for inclusion in other Go apps
   • Discussion: #83
   • PR: #123
3. Recurring events (cron) inside the container
   • Discussion: #87

Learn how to use ContainerPilot with your apps, join the ContainerPilot community on Github, and build apps that are easy to run and ready to scale.