Software Defined Software: The History of “Software Defined”

“Software defined” is the latest buzzword in IT and cloud. Some people hate it because marketers are jumping on ”software defined” almost as fast as they jumped on the word “cloud” years before they had real cloud products. Cloudwashing was a real phenomenon, and it was easy to say. “Software Defined Washing” just doesn’t roll off the tongue the same way, and it implies IP-enabled virtual laundry.

Here is an explanation of why you should embrace the term (I like it even more than cloud) and a view what we called it before “software defined” became in vogue.

The truth is that the idea is not new. Here’s what we used to call “software defined”.

Policy based whatever

In 1999, I co-wrote a 350 page book called “Business Class Internet” for Prentice-Hall that never got published thanks to the dotcom bust. In it, I wrote extensively about how policy-based and policy-driven architecture was required for the Internet to reach the levels of availability and security that enterprises expect. Network engineers have been talking about policy and policy-based architecture for more than a decade now. VLAN policies are even today a fundamental part of keeping cloud networks segmented.

The difference between software defined and policy-based is… marketing. Then again, marketing matters enormously. The proto-cloud service I created years ago at Speedera (now Akamai) was called “flex computing” because I didn’t have the marketing smarts to think of the word “cloud.” At the end of the day, it did exactly what infrastructure as a service clouds do: provision new instances based on rules or policies. But it had the wrong name!

In the current software defined world, no one has a nausea reaction when they hear software defined, but at some level the word “policy” is neurologically linked to unthinking, inflexible bureaucracies and slow-moving systems. The truth of the matter is that policies are amazing, as long as you are the one who gets to write them. But let’s wisely discard that term, as Arista has, because it doesn’t work. Software-defined it is.

Software Defined Software

Back in the day (i.e. 1994), CASE tools were all the rage (Computer Aided Software Engineering). If you ever had the displeasure of working with such tools, they allowed you to define very high level software policies, which the systems would then (hopefully, if you wrote very careful policies) compile into high-quality, defect-free, and maintainable software products.

Look at Opscode Chef, which AWS is uses for automation, and Facebook also uses. It reminds me of computer-aided software engineering. You simply define cloud deployment policies, and the systems get deployed as high quality, defect-free, maintainable cloud services. The difference between automatically deploying a complex system across tens of thousands of instances and automatically creating and then compiling code to work with millions of logic gates is not large. Orchestration offerings like VMware’s vCloud Director are another example – you can set policies to configure virtualized compute, networking, storage, and security automatically.

As Trend Micro’s cloud security guy, I feel obligated to point out that my company’s Deep Security ties in to vCloud and Chef so you can automatically build security into cloud environments as they are provisioned in a software defined world.

As long as it’s easy to create policies, manage policies, and enforce policies in the system, it doesn’t matter if you call it “software defined,” cloud, orchestrated, policy based, CASE, or something else. Just don’t create extra security and availability problems caused by human error or waste time doing things manually, and it will be a better IT system.

In all these cases, you need a system to manage the system. And that is the essence of “software defined.”