Blurring the line between software development and operations

A friend who got interested in concepts like DevOps and Infrastructure As Code after I introduce them to him, recently forwarded me an article in PC Magazine about something called Software Defined Networking (SDN). Being passionate about technologies that virtualize hardware infrastructure and allow you to programmatically manage your resources, I was immediately intrigued and decided to look up more information. After all, as the map on the right indicates, the IT landscape is very complex and if Dev & Ops can be put to work together by using a software driven approach to typical infrastructure needs everyone should be a winner.

Let me first say that I am a big fan of the “as a Service” business model and any technology that allows me to manage my resources and applications by using code is attractive to me. For example, I know a number of people who sniff at ideas like software firewalls, load balancers, proxies and swear that software can never outcompete hardware in terms of performance and stability. These same people readily allow production servers to run on VMs, they deploy application appliances (both software and hardware) or put “intelligent” storage in their data centers, without realizing that it is software that makes all of them work – or if they do they conveniently ignore that fact. I would argue that “as a Service” is possible because of the move from hardware to software, i.e. from infrastructure to code and is a trend I hope will continue.

Moving from hardware to software is democratizing. It frees you up from worrying about your resources and lets you focus on your applications. This is why cloud computing and the as a Service models are attractive to people. Virtualization of your own servers provides a similar benefit and coupled with infrastructure as code and software defined networking implementations it has the potential of democratization of your resources similar to the cloud too.

The real benefit of the cloud, though, is its elasticity and cost effectiveness. For a software defined solution to be truly democratizing over a traditional hardware approach I need not worry about the underlying infrastructure resources – do I have enough and how fast I can get them when in need, with the added value that I don’t have to pay for what I don’t use. The only solution that up until recently could live up to the promise and truly free you up from the underlying infrastructure was your typical SaaS: Gmail, Google Apps, Salesforce, Github, etc.

The problem with SaaS is that there are way too many needs out there that are not covered by the existing offering, so we still have to rely on the other two aaS models (Platform as a Service – PaaS, and Infrastructure as a Service – IaaS) to deploy our custom apps (which could be our own SaaS offerings) or run our own servers and data centers, potentially employing virtualization so we can abstract our servers from the underlying infrastructure.

Being able to define your networking through software too was one of the missing ingredients, since without that we were forced to put everything in the “public” cloud and concoct complex implementations to add security and networking services on top, or deal with the jumble of cables, network switches, routers, gateways, firewalls and other gear in our own data center (or server room for those who can’t afford to run their own data center or pay the rent for CoLo).

I probably lead you to believe so far that I think Software Defined Networking is a great idea but the title of the post suggests there is a but in the whole thing. I won’t deny that I can see the value – after all, everything software defined is worth my attention as it can be an enabler for more cloud and related technologies and free us all up from the infrastructure. However, I do have a gripe with it too.

First of all, there is an inherent problem with any Build Your Own solution that requires you to invest in your own infrastructure – whatever model you chose to use for it, whether it is simple virtualization, private or hybrid cloud, CoLo, etc. These solutions are not truly democratizing. You still need to provision and build the underlying hardware and network to be able to then deploy your favorite abstraction on top. You still pay for the entire infrastructure (plus licensing and service fees for the abstraction itself) even if you utilize only 30% of it. You will also hit problems with scaling fast enough and replacing failing hardware components due to slow provision cycles. And you’ll need skillset that will impact your bottom line through increased TCO but won’t add direct value to your business when measured through ROI and similar. (This is a topic for another post I realize!)

In my opinion, unless you are building a competitive cloud infrastructure or platform solution yourself, you don’t need to worry about implementing your own software defined infrastructure, network or data centre. The cloud providers like AWS, Joyent, Rackspace have been offering software defined infrastructures for years and some of them like AWS have added a software defined networking capability by implementing services like VPC. (People have been able to hack in networking capabilities on their own too using the public cloud and instances acting as routers, firewalls, etc. – all software driven.)

For an example of using a software defined networking on AWS, the following diagram provides a logical presentation of the network I designed using VPC for running this blog. You can click on the picture for additional information about the network.

Not to undermine the value of SDN too much, even if we, the regular mortals who prefer to free themselves up from servers and data centres, won’t directly take advantage of SDN and other Software Defined Infrastructure technologies, we will still likely benefit indirectly since the existing cloud providers can innovate more rapidly and new providers may be given a head start to catch up with the old ones, thus pushing the value for the customer to a new level.

I urge you to think twice before looking at these enabling technologies as an argument to avoid the cloud. The cloud may be offering natively the value those technologies are designed to provide. And if it doesn’t, those very technologies can be used to rapidly add the value to the existing cloud platforms, so your own effort to employ them “at home” in your own server room/data centre might be a waste. You have better things to do like creating business value, making your customers happy with that new feature they were dying to get for a year or make your employees ecstatic that now their database replication for development or testing can be done without asking IT to get a new VM installed for them. Unfortunately it seems, sometimes the hope and the hype get mixed in and the message gets clouded for all of us.