How to Cloudify Your Software, Part 2: Get Out Your CB Radio

[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. View Part 1: Ender’s Homework. Please subscribe, follow me on Twitter or Google+and check back weekly to explore the topic in full.]

“That’s a big 10-4, good buddy”

The 1970s novelty hit single “Convoy” begins with some banter between truckers on CB radio:

Ah, breaker one-nine, this here’s the Rubber Duck. You gotta copy on me, Big Ben, c’mon?
Ah, yeah, 10-4, Big Ben, for sure, for sure. By golly, it’s clean clear to Flag Town, c’mon.
Yeah, that’s a big 10-4 there, Big Ben…

 If you’re old enough, this reference probably brings a smile to your lips; if you’re young, you may not have heard the song or seen the movie. But if you’re a computer programmer who wants to write for the cloud, I’ve just provided some meaty research material. We could learn a thing or two from these truckers.

Convoys require frequent, real-time, adaptive coordination by many independent actors.

Convoys require frequent, real-time, adaptive coordination by many independent actors. Photo credit: Sangudo (Flickr)

A convoy is a loosely coupled group of vehicles that travels together. They share a common destination. They continually coordinate their actions with one another, adjusting speed, and sharing information about hazards and obstacles. Each vehicle has an intelligent driver. Each has its own engine and fuel supply. A single roadblock rarely impedes a convoy—it simply re-routes. A single flat tire won’t slow it down—the troubled vehicle just exits without diminishing others’ momentum. The fictional convoy in the song swept across the entire United States, continually growing and shrinking, and ended on the East coast over 1,000 vehicles strong—despite organized and urgent efforts to kill it.

Contrast this with a train. Trains usually have a small crew and one or more engines at the front, with hundreds of driverless cars, coupled in such a way that they blindly follow where their dead weight is pulled. They can’t be reconfigured while they’re moving. Blockage on the tracks can be fatal. If a car in the middle of the train suddenly breaks an axle, the whole train grinds to a halt.

The First Rule of Cloudthink

Both convoys and trains haul freight or passengers, and both have legitimate uses. But which mechanism sounds better aligned with cloud’s value propositions of flexibility, easy scale, and goal-driven optimization chosen by the customer?

In Part One of this series, I said that cloud turns much traditional software design wisdom on its head. I claimed that if you want to engineer cloud-friendly software, you need to think differently. The convoy-train metaphor is a prime example: most traditional software engineering produces trains, but cloud loves convoys.

The Language of Cooperation and the Language of Command

If you think about what makes a convoy form and remain cohesive, you’ll quickly zero in on a phenomenon captured in the first three lines of the “Convoy” lyrics above. Convoys depend on a characteristic style of communication:

  • The truckers identify each other using unique, arbitrary handles that are location-independent.
  • They don’t assume that they’ve been heard. They request and provide confirmation. Liberally.
  • They rely on a gestalt perspective where many pieces of input are shared publicly to make the best decisions.
  • They are egalitarian and self-organizing.
  • They expect status to change regularly.

Traditional software doesn’t work this way. The contrast is easiest to see in client-server or n-tier architectures, where you have a centralized command and a fairly static hierarchy for flow of data, control, and status. But even in many distributed architectures, vestiges of a different intellectual genealogy can persist:

  • Are you building a software that has an install for components A-Z?
  • Do you assume that particular components will always be network-wise or physically “close”?
  • Do you tell admins to modify config files or databases to create the links that allow A and B to talk to one another?
  • Once two nodes have learned about one another, do they assume that they’ll continue to work together in perpetuity?
  • Do you upgrade the system as a whole?
  • How sophisticated is your error-handling strategy?
  • Do you require unrealistic guarantees instead of diversifying your risk?

If so, consider joining the convoy by studying and enhancing the way your software communicates. Question easy assumptions and convenient short cuts that make your structure rigid. Add a few more ACKs, and a lot more error checking and circuit breakers. Subtract a few config files and replace them with dynamically negotiated alliances.

Stay tuned for more ways to cloudify in subsequent posts.

“Yeah, that’s a big 10-4 there.”

This is part 2 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