Looking at the marketing landscape for IT, you could be forgiven for thinking that the current strategy was to dynamite a word factory and use the resulting debris as marketing content. DevSecOps. NetDevOps. Ops, ops, spam, eggs, spam, and DevSpamOps.
The naming trend lends itself easily to parody, but it began as shorthand for an attempt to solve real IT problems. And its iterations have more in common than a resemblance to alphabet salad. What lies beneath the buzzwords? And do you need to care?
Countless companies have jumped on the NetDevOps bandwagon, all with their own way of doing things; and most are utterly incompatible with everyone else. Some may have already abandoned the NetDevOps craze, believing it to be nothing but marketing hype wrapped around a YAML parser and some scripts. Others might have found a system that works for them and swear by it, using nothing else for provisioning.
Regardless of views, a system that allows for rapid provisioning and re-provisioning of applications, containers, virtual machines, and network infrastructure is paramount.
Ministry of Silly Names: A History
The modern era of namesmashing started with DevOps. This made a sort of sense because, before this, IT had sharded into specialties. Developers didn’t really talk much to operations, and nobody talked to network admins. Over time, security became a fourth major branch, and Dev, Ops, Net, and Sec were all departments within the overarching heading of IT, each of which rarely talked to one another.
This became a serious problem for most organizations, because bad things happened when these departments didn’t talk to one another. Outages. Security breaches. Deploying Windows Vista.
Eventually, the first inroads were made into unifying IT with DevOps. This was supposedly the merging of Ops and Dev into coequal units with equal say in how things worked. In the real world, it became a code word for automating as much of the IT infrastructure as possible, and going with as lean an operations team as the organization could get away with.
Eventually, the world realized that developers were not very good at operations, and there was a reason that separate ops teams had existed in the first place. Operations types were sneaked back in to DevOps teams in other guises, often giving rise to DevSecOps, NetDevOps, or other horrible configurations of nomenclature.
The point of all of these exercises was twofold: force the nerds to play nice, and adopt as much automation as possible. Both goals were aimed at making IT more responsive, better integrated, and faster to scale. Success in every case has depended on corporate culture more than rigid adherence to any particular book or manifesto, and no technology or vendor has provided a magic bullet to solve what are, at the core, people problems.
For all the various iterations of nomenclature, the result is still just “IT,” and changing the buzzwords doesn’t change the underlying problems that caused a desire for a shakeup in the first place. Though, it should be noted, that after going through a DevNetSecOpsification, most organizations usually have far more automated IT, even if the people problems remain.
The Importance of Automation
With the unprecedented growth of containers, cloud deployments, and IoT devices, rapid provisioning and launch of infrastructure is vital. This requires some level of automation. You can call it composable infrastructure or infrastructure-as-code. You can yield to the inevitable and call it NetDevOps. But you probably can’t afford to ignore it.
The importance of composable infrastructure — to a small business, for example — isn’t always obvious. When a new server or VM is required, it’s usually created from scratch, or from a VM template that just needs to be customized for the specific deployment.
This works well… for a while. Twenty or 30 servers can be managed by a well-run NOC. But what happens when you start adding zeroes to that number, as in a cloud-hosted controller for a wi-fi solution?
Three hundred servers. Three thousand servers. Thirty thousand. Soon, managing all of these servers becomes simply impossible. This is where the automation technologies of NetDevOps become indispensable.
To continue the example of the wi-fi controller platform: a new customer signs up, and then the following occurs: A script is run on a server – whether physical or virtual – using a predefined YAML or other format configuration file, along with user-supplied values. This instantly spins up a container with the appropriate settings to be the wi-fi controller for that user or organization.
Now suppose a major vulnerability is found in the web servers hosting 3 million controllers. Updating that many containers individually would be impossible. However, with the separation of code and data, nothing special needs to occur. The containers simply need to either be torn down and re-provisioned with the new software or, if possible in the infrastructure, live-patched.
There is no downtime (or minimal downtime), and the systems are kept identically secure across any number of nodes.
Automation of infrastructure can have financial benefits: with one identical container * x number of nodes, maintenance becomes efficient, and therefore less expensive. All that needs to be done is to change one configuration file, and watch every container replicate the change. The savings are especially important when operating at scale.
Automation can also improve resilience. If a container goes down, pull the data from it, spin up an identical one, and you’re done. There’s little to no downtime, no divergence in security configurations, and guaranteed atomicity; either the container was created or it was not.
Automation By Any Other Name…
The NetDevOps world, or at least its marketing jargon, can be confusing. But the benefits it can bring your organization are substantial, both in time and security, and in ease of management. There are many open-source infrastructure-as-code environments available, and also many that provide commercial support and assistance, so there’s bound to be something for every business. Automation of infrastructure is worth serious consideration. Even if the buzzword bingo is getting abjectly ridiculous.