How Platforms Work: From Deployment to Recovery

In this 2016 talk, Casey West asks what it takes to run source code on a platform without making developers manage every infrastructure detail. He defines an operationally mature environment and demonstrates the ideas with Cloud Foundry.

His first capability is dynamic DNS, routing and load balancing. Deploying or scaling a service should not require a sequence of manual tickets for network and routing changes.

A service broker should provision backing services such as databases, caches and message queues, or supply access to existing ones. West wants authentication and connection details provided through the environment instead of manual copying.

Infrastructure orchestration must provision compute, storage and networking as needed. His distinction is between infrastructure that is merely programmable and automation already in place for the application team.

Health management should detect and recover from failed machines or application instances. Automated recovery reduces routine intervention, but it still requires sensible capacity planning and monitoring.

An immutable artifact repository separates building an application from deploying and running it. A known, inspectable artifact can be started repeatedly and quickly without rebuilding the application on every scale-out.

Centralized log aggregation lets operators investigate distributed applications without searching individually through production machines. West presents these six capabilities as his minimum viable platform; different organizations may need additional security and governance controls.

A car needs many integrated subsystems before someone can drive it. Likewise, West says containers alone are not a complete platform: infrastructure, operations and usable interfaces must work together.

The 2016 demonstration uses Cloud Foundry and BOSH. West describes BOSH as managing the lifecycle of distributed systems and Cloud Foundry as an application runtime with automated services. These are his descriptions of that stack at the time.

The sample Ruby service uses Sinatra and Puma, reads its port and instance information from the environment, and returns a small JSON response. Reading configuration from the environment supports deployment across different instances.

West uses the CF command-line tool to target an organization and space and deploy the application. The command-line client talks to an API, making the same operations available for automation.

He demonstrates routing and horizontal scaling: multiple instances run behind a route, and the platform directs requests among them. Logs are gathered so the operator can see application behavior without connecting to each machine.

A revised application adds a Redis-backed visit counter shared by the front-end instances. Initially it fails because the required Redis service is missing, so West rolls back while creating the dependency.

He lists available services, provisions a Redis instance and binds it to the application. The platform supplies host, port and credentials through the application environment; the small demonstration service is not itself a high-availability deployment.

Changing the service binding requires the running application to receive updated environment information. West explains that a restart or rolling deployment can apply new connection details.

He attempts a blue-green, zero-downtime deployment using a plugin: start a new immutable version, test it and move the route to it. During the live demo the new version cannot connect to Redis, so the intended smooth deployment does not work as planned.

Inspecting application configuration reveals the service binding problem. After rebinding, the environment contains the Redis connection details. West uses this to explain automated provisioning and credential rotation, subject to the platform’s actual security configuration.

To demonstrate recovery, he deploys an endpoint that crashes an application instance. The platform detects the failure, starts a replacement and adjusts routing; if too many instances fail at once, capacity can still be exhausted.

West defines cloud-native operability as maintaining applications over months and years, not merely deploying once. He favors microservices for independent scaling and iteration, while warning that multiplying services without automated delivery multiplies operational work.

He calls DevOps a culture of learning, measurement, automation and collaboration. In his view, microservices, continuous delivery and DevOps initiatives need an operationally mature environment to be effective.

In questions, he says the minimum capabilities may need to be supplemented with authorization, encryption and workload-placement requirements. He also discusses platform deployment choices and distinguishes applications from provisioned services.

West argues that robust distributed applications should expect failures and use techniques such as service discovery, load balancing, caching and circuit breakers as appropriate. The right architecture depends on context rather than a single product.