The Happiest Platform on Earth: What the Cloud Can Learn from Disney World
Cloud platforms and theme parks are escapes from reality: one is a fantasy world and the other is someone else’s computer. Both are also collections of attractions (or features) that come together to create an experience that’s more than the sum of their parts. No theme park brings attractions together better than Disney World, and by learning from the techniques Disney’s Imagineers use we can add a little magic to our own platforms.
Go-Away-Green
When Disney needs to hide a building or obtrusive object, they paint it “go-away-green”. It’s a dull color that effectively makes the object disappear into the background. As a park guest, your eye is drawn to the more vibrant objects around it.
Cloud platforms should, first-and-foremost, provide valuable capabilities (attractions if you will). But making a good experience for those capabilities requires metaphorically painting parts of the platform stack in go-away-green. A platform is delightful to use when it is subtractive. Subtraction can mean hiding physical data centers behind virtual machines, hiding virtual machines behind containers, and hiding containers behind functions. These are the most common examples, but there are many other operational concerns that a platform can hide.
Making something simpler by taking things away is harder than it seems. Our inclination as engineers is to solve problems by adding, rather than subtracting. Too often, we introduce a new capability or technology when our customers may have wanted us to abstract it away.
AWS Lambda, FaaS, and other serverless platforms are good examples of subtraction. But my favorite example is Parse.com, the original Mobile-Backend-as-a-Service (MBaaS). It gave mobile developers a way to persist data in the cloud without really even knowing the fundamentals of the cloud. Facebook shutdown Parse.com, but the Parse platform is still kicking as an open source project.
Forced Perspective
Disney employs forced perspective to make objects appear larger or farther away than they actually are. If you look too closely or think too hard about these structures, the optical illusion breaks and they start to look weird. But if you accept them for what they’re meant to represent, they help create a magical experience.
A platform also needs to force its users to see things a certain way because it can’t be all things to all people. A good platform has opinions about how apps and services should be architected. When users resist these opinions, it creates friction and a bad experience. But when embraced, those opinions elevate the user.
A great example of a platform having opinions is the 12-factor app, which defines a set of architectural principles that encourage scalability, operability, and sustainability of services. When Heroku published the 12-factor app in 2012 it went against the grain. Developers were accustomed to long-lived processes and treating infrastructure as pets not cattle. Those who resisted the 12-factor principles found it difficult to use the Heroku platform. But adopting those principles became essential to getting the Heroku experience that’s so well known.
Tell a Story
Storytelling is an integral part of every Disney attraction. Each ride has its own arc with a beginning, middle, and end. When you enter the line for Space Mountain you’re boarding a flight. Your flight takes you through space, and you exit onto a new planet.
Too many platforms forget that an app has a story arc too. We can’t focus myopically on the “day-1” interactions (i.e. the early phases of creating a new service). Developers spend 90% of their life in “day-2” (i.e. running that app in production and applying security patches), which are messy, complex environments. A good platform strives to make day-2 operations an integral part of the experience, and enables complexity exploring tools like APMs and Observability tooling.
Buildpacks help the application story arc by separating developers from the software supply chain and even many security patches. This makes their apps more secure, but it also simplifies operations because they’re no longer responsible for updating their base image, or making sure they’re using the latest version of Java. The Buildpack infrastructure handles much of this for them on day-2.
Hospitality
Entire books have been written about Disney’s hospitality. But in short, Disney’s goal is not to simply satisfy customer expectations, but to exceed them.
Look at all the things I didn’t have to do when I visited Disney World. I didn’t have to figure out how to get to the Magic Kingdom because the Monorail came to my hotel and picked me up. I didn’t have to get my wallet out because my MagicBand linked my meal to a pre-paid dining plan.
When your platform is hospitable, your users will love you for the decisions they don’t have to make. This comes part-and-parcel with being opinionated because every opinion your platform has is a decision your users don’t have to make. An opinion can be the difference between two steps and one step needed to accomplish something, or even one step and zero steps.
Hospitality requires all hands on deck though; it’s a culture that only works when your entire organization is onboard. You and every other engineer need to feel personally responsible for the usability and experience of your platform.
It’s not a museum
Walt famously said “Disneyland will never be completed. It will continue to grow as long as there is imagination left in the world”. It’s a theme park, he said, not a museum; that’s why you can’t ride 20,000 Leagues Under the Sea anymore. Similarly, a platform needs to evolve and grow as the ecosystem matures and new innovations emerge.
RedHat’s big bet on Kubernetes for OpenShift is a great example. In 2014, RedHat announced that OpenShift V3 would be built atop Docker and Kubernetes. This investment helped transform the platform from a footnote into an industry leader. Kubernetes is the standard now, but in 2014 it was competing with a crowded field of container orchestration technologies. RedHat’s willingness to change and adopt very young open source technologies helped it rapidly gain market share, and ultimately played a big part in its acquisition by IBM.
Don’t be afraid to change your platforms. Everything in software is an experiment, and should always be subject to change or or even being shut down. Ending an experiment isn’t a failure, though. We often learn the most from experiments that don’t produce the results we wanted.