The Register guide to software-defined infrastructure

Software-Defined Infrastructure (SDI) has, in a very short time, become a completely overused term. Roughly a year ago I discussed what SDI is. As the individual components of SDI have started to become automated the marketing usage of the term has approached "cloud" or "X as a Service" levels of abstracted pointlessness. …

[Robert Helpmann??]

All your API belong to us!

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 it was at that point he realized that this must be stopped by any means possible. The rest, as they say, is history (but not the kind of history that small children should be allowed to read because they will have nightmares)." Sounds like the germ of a BOfH story...

[Anonymous Coward]

Nailed it

"Where it all goes wrong – and it has – is that while many engineers are developers, not all developers are engineers."

^this.

[Anonymous Coward]

So when I set up my NAS a few years back in a JBOD configuration, I was creating Software-Defined Infrastructure (SDI).

I feel so cutting edge.

[Anonymous Coward]

An earlier example

Was Dec Storageworks Controllers (circa 1994ish). Define the array of disk in various raid (or not) setups and drive presentations.

Then there were the VMS Cluster Disk controllers. At least one was configurable. VMS/VAX Clusters appeared in 1983.

I'm sure that there are many, many examples of earlier systems from the likes of IBM etc.

Nowt new young fella apart from marketing snake oil.

[Anonymous Coward]

Re: An earlier example

"Then there were the VMS Cluster Disk controllers. At least one was configurable. VMS/VAX Clusters appeared in 1983."

Indeedy. The DEC disk controllers I used from the mid-nineties on could be configured from the VMS command line. With a bit of effort that could be scripted too.

Adding Host Based Volume Shadowing (software mirroring built into the OS) gave more resilience and something you could program, for another level of error reporting and automation.

[Anonymous Coward]

I proffer my thanks

to Mr Pott for so succinctly explaining as much as I will ever need to know about SDI.

[allthecoolshortnamesweretaken]

Hmm. I remember when SDI was Reagan's Star Wars dream - you know, lasers that could vaporize incoming ICBMs and stuff... Are there any rules on re-using acronyms?

[Anonymous Coward]

" Are there any rules on re-using acronyms?"

Some - don't reuse SCO unless you just want abuse?

[Mark 110]

Change Management

Change Management doesn't go away just because you are doing SDI. It just needs to keep up. Its always been about assessing Risk and Impact and putting the appropriate governance in place to make sure the changes are assigned off at the correct level of expertise and accountability.

In order to 'keep up' you just need processes in place to make those 20 day approval lead times come down to two days. Not easy, but not impossible, and the DevOps crowd are looking hard at how they make their rapid implementation lifecycles work with a risk averse Service Management organisation. I could tell you more but I skipped the conference I was invited to on the subject last year.

The power for me in software defined is once you have defined you can implement your test environments in days instead of weeks, and given correct change control and configuration manageement, over the definition, when you come to implement on production you have a greater level of assurance that Production will be a 99.999% replica of the environment you tested on.

[Paul Crawford]

Re: Change Management

One of the guys in the networking department where I work explained it thus: Change management provides me with no immediate advantage in having to fill out the request forms, etc, but it provides me with plenty of benefits when others do it. And vice-versa.

Knowing what was changed and when, and having easy ways of rolling back (e.g. snapshots of file systems and configs, etc) is a huge advantage if what you do really matters.

[Cincinnataroo]

Strategic Defiance Initiative

[Big Ed]

Spot on with SDS

Trevor, love your SDS analysis; yes to a certain extent it's about locking you into someone's software.

Some key concepts though. In my mind Software Defined Storage is a common, independant abstraction of the physical hardware from the management platform. And a true SDS platform can manage any physical hardware; JBOD through commercial disk arrays. And the SDS platform needs to be open and interoperable with open standards and popular software defined automation tools. Think about a platform that can manage JBOD, ONTap and Unisphere, and present the Share, Mount, CUU or LUN to vSphere, vRealize, zOS, to S3 with the same clicks.

I would look forward to seeing a 'round-up" analysis of different approaches and a with a grading scale to see how far the various SW defined vendors go with interoperability and openess.

[Anonymous Coward]

handful?

"With the exception of a handful of Israeli startups run by terrifying ex-Mossad InfoSec types" .. such as ..?

[PJF]

Happy New Year

Mr. Pott

We haven't see you 'round in a dogs age..

That is all.

[RegGuy1]

SDS -- isn't this what IBM's SVC has been doing for years?

https://en.wikipedia.org/wiki/IBM_SAN_Volume_Controller

[Anonymous Coward]

Re: SDS -- isn't this what IBM's SVC has been doing for years?

Isn't SVC a virtualization platform running on IBM's Hardware?

Surely it's software abstraction of arrays, but don't think it qualifies as SDI because it lacks hardware independence. And the last time I looked, I didn't think it was capable of creating a RAID device over JBOD, or capable of file support. But maybe I'm wrong.

[KitD]

Amazon

There's this:

> 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.

Then there's this:

> For all the derision of the old guard, Amazon has changed IT forever.

I was under the impression that Amazon originally required all internal infrastructure to be managable via APIs, and then realised the commercial potential of those APIs, turning itself into a $bn business as a result.

Is the argument against APIs? Because having them (or at least properly managed ones) seems to me to be an absolute fundamental requirement for survival if you're going to take your infrastructure management seriously.

[Trevor_Pott]

Re: Amazon

No argument. Just facts. Judgment is in the hands of the reader; I'm staying neutral as there are both pros and cons to the approach. The implementation (both vendor side and client side) determine success.

[Hans Neeson-Bumpsadese]

A slight aside - processing power

"Hell, a simple hard drive or flash disk today contains more computing power – and more software – than we used to send people to the moon! Can you imagine what an early NASA could have done with just the flash controller in a modern SSD? Let alone the SSD itself!"

An excellent point...and the main reason why, as one of my company's resident old farts, the reason I get so vexed when a software developer grumbles about how something "might not be possible" on some mahoosive enterprise-level server

[thondwe]

It's all software?

It's always been software - even firmware is software, just difficult to replace with a 3rd party solution - can be done though - OpenWRT etc.

And almost everything has been "programmable" - most stuff is scriptable.

What's "new" is having a single button to create a piece of infrastructure - e.g. VM + Storage + ACLs + Firewall Config... "Software Defined Anything" is a lousy name - it needs something that actually reflects central control/management - HAL or Eddie or Skynet...

[Andymwood]

What does it matter that developers aren't engineers? That's not what they're there to do - they're there to write code. That code is the software in the SDx.

The "Organisation" has always wanted "stuff" now - because they are focused on getting their stuff done.

Change Management is introduced to ensure that the code that is written and deployed doesn't break something else and at the same time the new shiny thing to Make Things better isn't actually a Big Spanner to break something else.

SDx is, as thondwe states, a tool to introduce greater levels of automation and abstraction, but its not the messiah.

[Anonymous Coward]

"What does it matter that developers aren't engineers? That's not what they're there to do - they're there to write code."

I'm not going into the huge argument over whether software is engineering or not, except to say that software that duplicates the function of hardware needs to be engineered to the same standards of effectiveness and reliability. If software abstracts away hard drives so that they can, as it were, be connected to virtually, then that software needs to be engineered to the same standards as an IDE cable (remember them?).

Engineering is science applied with discipline to do with standards, consistent behaviour, documentation and planned upgrades. This has been known since the days of Whitworth, who wasa round at the same time as Babbage. You wouldn't let someone coding website markup anywhere near an engine management system, and storage is now as mission critical to businesses as ECUs and autopilots are to vehicles.

[Anonymous Coward]

Re; Andymwood - its not the messiah

...it's just a load of noughts and ones

[Boyan]

The SDS piece is rather one-sided.

While some vendors try to lock you in, in the end it is a standard storage interface exposed somewhere so you can use to migrate from one system to another. In minutes (or days depending on how much data you have :) And eliminating "vendor lock-in" is illusory - you still have to use a solution from a vendor. However being locked on the storage software is less of a lock in than being locked-in on software AND the hardware.

And if the proposition of the storage software vendor is to manage other companies' arrays - this is storage virtualization, not SDS.

[Naselus]

"To my knowledge there isn't a single functioning mercury delay line left on the planet"

Clearly, the author hasn't been keeping up with some of the bullshit being spouted in the 'longest uptime' comment threads.