[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, Part 2: Get Out Your CB, Part 3: “Do you want fries with that?”, Part 4: Check Those Vitals, Part 5: Auto Install, and Part 6: Re-imagine Your Data. This is an addendum.]
When I wrote my 6-part series about how to cloudify your software, I mentioned a bunch of changes to a programmer’s mental model, best practices, and expectations that will yield big benefits in the brave new world of cloud computing. All of that advice continues to feel relevant and valuable to me, but I’ve realized that I glossed over another important truth that ambitious developers need to grok. You ready?
Cloud is complex.
Depending on your mindset, this observation might either seem glaringly obvious, or totally irrelevant, or both. But I think it implies some important insight, not to be taken lightly.
On most modern software development teams, complexity is a major impediment to velocity. Encapsulation and dependency management and better installs and auto-configuring, auto-healing software have all been necessary because complexity can snarl the most straightforward intentions. Continuous integration and delivery, agile methodologies, static code analyzers, clean-room, and software six sigma are all reactions to its pernicious consequences.
And cloud makes it worse.
Those who love cloud might say the opposite—after all, you don’t have to think about the physical hardware that provides your platform; you just have to use it. I agree that this is a profound advance, but I’d point out that along with that simplification, we get a new kind of dynamism that can give software fits. If you scan through my previous “cloudify” posts, you’ll see the theme cropping up again and again. Old assumptions about data locality and I/O performance go out the window. New servers can be online and ready to participate in your system in seconds, not days. And they can disappear just as fast. Communication needs to be more adaptive and resilient. And on and on.
Faced with this dynamism, the “easy” answer is to push the task of handling flux and onto the user of the software. Expose a bunch of knobs and switches, and make them learn to use each one. When things go wrong, blame it on them.
This is not wise. As I’ve written elsewhere, flexibility that just makes users work harder to derive value is hardly a virtue.
Instead, we need to see the complexity of cloud as a challenge to raise the bar.
Photo credit: Philipp Pohle (Flickr)>
Raising the bar is not easy. It means demanding more of yourself, your teams, and your entire software delivery value chain. It means focusing relentlessly on keeping complexity carefully encapsulated, so the user experience can be simple and robust. But it is possible, as cloud thought leaders like Netflix and Twitter demonstrate. Although they don’t give medals for cloud high-jumping, the personal satisfaction of pushing for ever greater heights is real.
Are you up for it? If you put into practice all the advice that I bundled into my earlier “cloudify” posts, new personal bests will follow…
This is part 7 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
The post How to Cloudify Your Software, Part 7: Raise the Bar appeared first on Adaptive Computing.
