The Register guide to software-defined infrastructure

Our very own Trevor Pott does his best to cut through the marketing fluff

Developers are not engineers

Where it all goes wrong – and it has – is that while many engineers are developers, not all developers are engineers. In the "bad old days", we had a separation of powers. In a well-balanced IT department no one idiot could ruin everything for everyone one else.

A virtual admin with a burning idea would need to get the network, storage, OS, application and security guys to all sign off on it.

The new way is to dispense with all of that and let the devs run the asylum. Hell, most software teams have almost entirely done away with testing and quality assurance. It's common practice for even the mightiest software houses to throw beta software out as "release" and let the customers beat through the bugs in production.

It's a rare company that – like Netflix – invests in building a chaos monkey. Rarer still are those still building software using proper engineering principles.

Do you think the coders at your local software-defined startup are ready to code the next Mars rover? No? Then why in the name of Jibbers would you let them build the critical components of the IT infrastructure that runs your life-saving medical equipment, traffic lights, or air traffic control systems?

Also ... if everything can be controlled through an API on your infrastructure, then the first person to happen along who can pwn some app with administrative rights to your infrastructure can tear it all apart. And I mean all of it. A true SDI data centre will be one giant attack surface.

Software-defined change management

With the exception of a handful of Israeli startups run by terrifying ex-Mossad InfoSec types, these are the sorts of questions and discussions that make software-defined X startups very, very angry. They really don't want to talk about things like rate limiting change requests from a given authentication key, how one might implement mitigation via segmentation or automated incident response.

There's money to be made and any concerns about privacy, security or data sovereignty are to be viciously stamped out. The hell of it is ... they're not wrong.

Change management is seen as a problematic impediment by pretty much anyone who isn't a traditional infrastructure nerd or a security specialist. Developers, sales, marketing and most executives want what they want and they want it now. If IT can't deliver, they'll go do their thing in Amazon. Every time that happens that is money those startups – or even the staid old guard – aren't getting.

Eventually, the software-defined crew will realise that if they are going to be around for more than a single refresh cycle they need to put a truly unholy amount of time and effort into idiot-proofing their offerings. Those that don't won't be around long.

For all the derision of the old guard, Amazon has changed IT forever. The public cloud isn't just "someone else's computer". It's someone else's computer where every resource can be provisioned with an API by developers. It's the need for five sysadmins instead of 50. It's automation, orchestration, and self-service.

When someone talks about "software-defined", that's what they're trying to be. Or, at least, they're trying to be some small piece of that puzzle. If they do talk about "software-defined", however, take the time to ask them hard questions about security, privacy and data sovereignty. After all, in a "software-defined" world, those sorts of considerations are now automated. Welcome to the future. ®