In the world of cloud computing, “risk” is a big buzz word. Lots of analysts are debating how much risk is involved in using SaaS offerings like Salesforce, or hosting corporate applications with a public IaaS provider like Amazon’s EC2. They’re worried about outages (Amazon’s had several ugly ones, most recently for 49 minutes in January), about security, about regulatory compliance, and so forth.
Werner Vogels, Amazon CTO, NextWeb 2008: “Everything fails, all the time.”
These worries are well founded. However, I pointed out today on Adaptive Computing’s blog that the question “Can I take the risk to use the cloud?” is a bit naive. Sometimes you can just avoid risk altogether. In many cases, however, risk is endemic, and the smart course is to manage it.
How does risk figure in your architectural vision? You should think about it all the time. You should count it, weigh and balance alternative outcomes in ways that would impress even the gaming industry.
Here are 6 key questions to kick-start your pondering:
- Is my architecture properly accounting for risk of environmental problems such as DDOS, routing failures, brownouts, and temporary loss of an internal component? (See my article about circuit breakers.)
- When one of my components crashes, will its state be cleanly recoverable (e.g., on transaction boundaries) rather than corrupt? What data loss contract am I targeting?
- Will it be easy for users or admins to notice when theoretical risks I’ve planned for become true emergencies? How will they be notified?
- Is it possible to put the system in a “scabbed” state that’s degraded and safe, but functional, while more extensive repairs take place?
- Am I assuming success too often? (Werner Vogels, Amazon’s CTO, is fond of saying “everything fails, all the time.” That’s on my top 5 list of major insights to remember.)
- Am I diversifying intelligently, and enabling my customers to do so as well?
Make a list of a handful of important risks from your customer’s perspective. How many of them can you help with?
Most stories about zen masters, gurus, or other paragons of wisdom follow a similar pattern. The pupil discovers a problem. He or she struggles with it. The problem gets more and more overwhelming. Solutions are elusive. Finally the pupil goes to the master and pours out his heart, whereupon the master offers a pearl of insight that radically reinterprets the problem.
Seek the simple… Photo credit: departing(YYZ) (Flickr)
There’s a reason why this narrative exists in every culture: human beings need the insight that comes from synthesis, pared down to its essence. We crave the simple but profound:
- Less is more.
- Do unto others as you’d have others do unto you.
- A watched pot never boils.
- Freedom isn’t free.
The software industry desperately needs this sort of insight, but far too often I see us operate in the stage of the narrative where the pupil misunderstands the problem, struggles, and makes things worse. Continue reading
Just read an insightful post from Seth Godin. If you don’t already know who Seth is, and follow him, I suggest you get to know him a bit. He’s a thought leader in the field of permission marketing–the founder of the movement, perhaps. He’s spoken at TED conferences numerous times. Every one of his books that I’ve read is worthy of pondering.
Although Godin isn’t speaking specifically about software craftsmen, I see direct application of his thinking to our field. Since so much of what we do requires buy-in, coordination and shared mental models, we have to be savvy about how we communicate, advocate, and train. Assuming equal technical competence, the difference between effective and ineffective technical leaders largely depends on the mastery of this skill.
Have you considered how to grow your influence? Do you have a plan?
Influence doesn’t always work the way we expect. :-) Image credit: xkcd
Technorati code: FMUS579NQBM8
Saturday I went to a high school half an hour north of our home, to watch my 16-year-old daughter compete in a cheerleading competition. And I learned something about software.
Photo credit: neys (Flickr)
I’m not sure how many teams were there–maybe a hundred. The competition started at 9 am and was scheduled to run through 5. Every team consisted of dozens of girls, all dressed in spangles and glitter, with identical ribbons in their hair. They’d march out onto the floor, drop their heads and arms to their sides, and wait for the first blast of music to initiate the routine. Then they’d tumble and dance their hearts out, finishing out of breath with a flourish.
Every hour or so, the performances suspended so judges could announce winners in a particular division that had just fielded its last competitor.
I noticed a pattern. Even though I have no knowledge of competitive cheer scoring, I could tell who had won. Continue reading