NetOps Needs to be Agile because the Cloud Can Change Overnight

NetOps needs to embrace DevOps methodologies and principles to restore the balance of stability and speed to support the growing number of applications deployed in the public cloud.

There is a belief on this side (the network side) of the fence that teams adopting DevOps anything have traded stability and security for speed.

In many instances this is absolutely true. Remember this gem from Arxan and IBM on the security of IoT and mobile applications? In it we learned a majority of respondents cited “rush to release” as the primary reason applications are released containing vulnerable code. Speed trumps security – and stability.

On the stability side, there’s less quantifiable data but heaping mounds of anecdotal evidence. Most notably is the frenetic response of cloud partners when “the cloud” changes overnight.

No one is told. Someone simply notices that something has broken. It is investigated, and invariably the cause is a change in the underlying infrastructure. A change that was no doubt was beneficial to the provider and perhaps even customers, but that resulted in breaking a whole lot of solutions that depend on that infrastructure.

YOU HAVE NO CONTROL OVER PUBLIC CLOUD.

Perhaps I need to start a ‘cloud rules’ with that one as Rule Zero, because it’s critical to your sanity and to the way in which you approach adopting cloud.

The cloud infrastructure is not yours. You don’t control it, you can’t change it, but the provider sure as heck can (and does). If you approach cloud with the same mindset as that of your corporate data center infrastructure, you are going to be miserable.

All you can do is react to those changes. And one of the DevOps methodologies that can help you react in a timely manner is infrastructure as code. Remember, infrastructure as code is a simile, it means treating the configurations, templates, and scripts that deploy, provision, and manage infrastructure like code.

Key to that is the adoption of a declarative model of deployment, meaning the use of templates where possible to describe what you want the infrastructure to do, not how it should do it.

Using a declarative model enables greater agility (reaction speed) in the face of unexpected (but unsurprising) changes in the cloud infrastructure. Yes, they will break. But you’ll be able to more quickly adapt because you need only address the changes in a central (shared) template to redress.

You won’t need to modify code, per se, nor sweep through and make changes to existing configurations (like patching, only scarier). You can modify, test, and redeploy a template much faster than modifying code or installers or the legacy ‘install guide’ in a PDF.

Cloud is going to change – and you’re going to have to react. You’re going to need to be agile – and follow its principles to quickly address the changes you can’t control.

An agile approach coupled with a declarative model for infrastructure in public cloud is the best way for you to restore stability for applications without sacrificing speed.