I’ve been on a bit of a mission lately to simplify operations and demystify “orchestration.”
Some people make orchestration sound like magic, but when I press them on it they describe the operational activities that need to be done over the lifecycle of their applications. This includes examples like registering containers with the load balancer as they scale things up and de-registering them as they scale down, but it expands from there.
Almost everybody seems to have different workflows, processes, and touch points, and many of those are constrained or shaped by policies, legacy, and priorities. The Autopilot Pattern seeks to simplify that magic by putting it in context to the lifecycle of application components.
That was a key point of my recent blog post on app-centric micro-orchestration. Yeah, I chocked on that title too, but it’s the shortest and most descriptive name I could think of.
And once we do automate those things, we find ourselves here:
By making our applications effectively stateless to the scheduler, we can make even the most complex applications simple enough to manage just by setting the scale of their components.
But how do you make stateful apps stateless? That’s where my post on persistent storage patterns for cloud applications comes in:
The conventional wisdom is that containers are great for stateless applications, but inappropriate for stateful apps with persistent data. If this is true, it’s not because the technology isn’t up to it, it’s because the patterns for managing persistent data and stateful applications are not commonly understood. The challenge isn’t so much about how to persist state, but how to do so without compromising the agility and automation that we love about containerization in the first place.
Tim Gross ran with that theme in his recent talk at O’Reilly Velocity: Stateful Applications on Autopilot.
Much earlier, I dug into the issues of discovery in distributed applications, making the case that discovery and connection management is a core concern:
Passive discovery patterns are those that separate the application from the decisions, leaving the application passive in both the choice of what back ends to connect to, and passive in resolving failures that may result. Active discovery patterns move those decisions into the application so it can have an active role in choosing the backend and working around failures it may encounter.