How to Cloudify Your Software, Part 3: “Do you want fries with that?”

[Author’s note: This is one of a series of posts about how developers can design and code differently to take advantage of the cloud. Check out the rest of the series: Part 1: Ender’s Homework and Part 2: Get Out Your CB. Please subscribe, follow me on Twitter or Google+and check back weekly to explore the topic in full.]

What’s in a name?

Do you remember the name of the person who took your most recent order at a restaurant?

I didn’t think so.

Do you remember the name of the person who showed you to your desk when you clocked in on day one of your most recent job?

Me, too.

It’s ironic. Most of us have been to a restaurant many times since our last job change. We’ve tipped waiters who gave us their name (“Hello, my name is Ichabod. I’ll be your server tonight.”), or said “thank you” to a name tag behind the cash register at McDonald’s. And yet the names of these folks evaporate in a flash, whereas the name of the HR person (or the boss or coworker) who ushered us into the building stays with us.

The reason for the difference is an important lesson for anybody who wants to cloudify, and it’s summed up nicely by the tag line at the bottom of the golden arches:

What can McDonalds teach a developer of cloud-friendly software? photo credit: phogel (Flickr)

What’s in a billion names?

When you walk into McDonald’s, you don’t expect to interact with Sally or John, specifically. You expect to order from whichever employee happens to be behind the first empty cash register. This is not an indictment of you or of McDonald’s; it’s just a basic reality that at the scale where McDonald’s operates, roles—not individuals—govern the mental model. You see one another as “customer” and “employee,” and further detail is unnecessary.

Even when scale is not extreme, this phenomenon is observable, if repetition or fungibility are an important consideration. This is why the servers at smaller, more local restaurants don’t finish their introduction with their name. They always tack on, “I will be your server tonight,” because you’re having a role-based interaction. You are like other customers they’ve helped, and they are like other servers who’ve waited on you in the past.

In contrast, those who work with us on a day-to-day basis may play many different roles over the course of our association—supervisor, partner in the department foosball championship, fellow committee member, competitor for a promotion. We learn their names, and we tend to see each coworker as having unique traits that have a direct bearing on how we experience our jobs.

Lessons for software

Before the advent of cloud computing, the dominant paradigm in software construction was to compose complex systems out of named, hand-configured building blocks that were relatively permanent. Software components got to know one another like coworkers:

  • State-of-the-art software collaboration in the ’80s and ’90s had teams mapping named network shares to named mount points or drive letters on their local workstations. If the file server had trouble, the whole department heard about it.
  • Because servers were major capital expenses, they tended to be big and multi-purpose, often changing which services they hosted over the course of their lifetime. Remember that hunk of iron that the IT department lovingly dubbed “Sauron”…?
  • In the early days of the dotcom bubble, web sites were typically deployed on a single web server with a DNS entry that pointed directly at it. If the server went down, your web site went down, too.
  • How many man-hours have IT folks spent editing config files to point software one one machine at another specific machine with which it needed to interact?

Software that is friendly to cloud doesn’t work that way. It thinks about the rest of the ecosystem in terms of roles, behind which all uninteresting details are hidden. Instead of memorizing that Sauron is its DB server, Elrond is for LDAP, Frodo is the file server, and Gandalf is the machine that hosts middleware and UI, cloudified software asks a broker to give it a DB connection. Any DB provider will do; its name is unimportant and can vary freely. That way, when the DB scales out, it doesn’t care. When the traditional DBMS is replaced with Amazon RDS, it still doesn’t care. It might notice if its server asks, “Do you want fries with that?”—but it doesn’t read the name tag.

CDNs, load balancers, sharding, virtual compute farms, and throwaway instances are all evidence that this mindset is becoming more entrenched as cloud sinks in.


Between now and my next post, ponder how much your software is built on role-based interactions:

  • Does its configuration assume static relationships with named machines, or does it tolerate the dynamism of cloud?
  • What permanency does it assume in a deployed environment?
  • Does it have robust mechanisms for discovering changes, and does it react to those changes without missing a beat?
  • If you had to scale out or resurrect an actor in the system, what disruptions would ensue?

If you find areas where you’re not managing the production equation with the sophistication of a McDonald’s, consider emulating their strategy to cloudify more.

After all, what developer wouldn’t love to have “billions and billions served” in the about box of their creation?

This is part 3 of a 7 part series, click the links below to view the rest:
How to Cloudify Your Software, Part 1: Ender’s Homework
How to Cloudify Your Software, Part 2: Get Out Your CB Radio
How to Cloudify Your Software, Part 3: “Do you want fries with that?”
How to Cloudify Your Software, Part 4: Check Those Vitals
How to Cloudify Your Software, Part 5: Auto Install
How to Cloudify Your Software, Part 6: Re-imagine Your Data
How to Cloudify Your Software, Part 7: Raise the Bar

Facebook Twitter Email