On Feb 3, Lori guest blogged about “programmability is the future of NetOps”. Lori is a frequent guest blogger and you can check her other blogs here. Cisco Insieme Business Unit and F5 have been innovating on the DevOps front for several years now and Lori is taking us through recent automation and orchestration trends in this blog.
Containers. Even though the technology itself has existed for more years than many IT professionals have been out of college, you can hardly venture out onto the Internet today without seeing an ad, article, or tweet about the latest technology darling.
They are one answer to the increasingly frustrating challenge of portability faced by organizations adopting a multi-cloud strategy, which means most according to every survey in existence. Containers, too, provide an almost perfect complement to development organizations adoption of Agile and DevOps as well as their growing affinity for microservices-based architectures.
But containers alone are little more than a deployment packaging strategy. The secret sauce that makes containers so highly valued requires automation and orchestration of both the containers themselves as well as their supporting infrastructure. Load balancers, application routers, registries, and container orchestration are all requirements to achieving the simplicity of scale at the speeds required by today’s developers and business.
Growth is inevitable, and the speed at which container-based systems grow once they’ve become ensconced in production is astonishing. Per last year’s Datadog HQ survey on the technology, “Docker adopters approximately quintuple the average number of running containers they have in production between their first and tenth month of usage. This phenomenal internal-usage growth rate is quite linear, and shows no signs of tapering off after the tenth month.”
Imagine managing that kind of growth in production manually, without a matching increase in headcount. It boggles the mind.
Even if you can imagine it, consider that the same survey found that “at companies that adopt Docker, containers have an average lifespan of 2.5 days, while across all companies, traditional and cloud-based VMs have an average lifespan of almost 15 days.” So, managing “more” becomes not only more in number, but more frequently, as well. Such volatility is mind-boggling in a manual-world, where configurations and networks must be updated by people every time the application or its composition changes.
NetOps never envisioned such a dynamic environment in production, where the bulk of business “gets done” and reliability remains king. Balancing reliability with change has always been a difficult task, made exponentially more troublesome with the advent of micro-environments with micro-lifecycles.
Therefore, it’s imperative for NetOps to not just adopt but embrace with open arms not only the technical aspects of DevOps (automation and monitoring) but its cultural aspects, as well. Communication becomes critical across the traditional siloed domains of network and application operations to effectively manage the transition from manual to automated methods of adjusting to the higher frequency of change inherent in container-based applications. You can’t automate what isn’t known, and the only what to know the intimate details of the apps NetOps is tasked with delivering is to talk to the people who designed and developed them.
No matter how heavy the drum beats on those siloes, it’s unrealistic to expect those deeply entrenched walls to break down amid their digital transformation. Developers aren’t going to be programmatically manipulating production network devices, nor are network engineers going to be digging around in developers’ code. But communication must be open between them, as the rate of change increases and puts pressure on both groups to successfully deploy new technologies in support of the faster pace of business and the digital economy. The walls must become at least transparent, so the two groups can at least see the grimaces of pain when something breaks. Through that communication and shared experience comes empathy; empathy that’s necessary to bring both groups together in a meaningful way to design and architect full-stack solutions that incorporate both network and app services as well as the entire application architecture.
Scripts are easy. Shared responsibility and effort is not. But it is the latter that is becoming an imperative to designing networks that can support emerging architectures at the speed (of change) required. The technical side of DevOps is not unfamiliar territory for NetOps, though its skills will no doubt requiring sharpening in the coming sea storm of change. The cultural side of DevOps is less familiar (and more uncomfortable – trust me, I get that, really) for all involved. But only by collaborating and communicating will these highly automated, dynamic, and rapidly cycling technologies can succeed and allow businesses to reap the rewards of adoption.
“Developers aren’t going to be programmatically manipulating production network devices, nor are network engineers going to be digging around in developers’ code………The walls must become at least transparent”
I think you’re spot on here, Ravi. At dockercon this week it felt like it was about 2/3 developers, 1/3 ops attending the show. The toolchains are bringing everyone together whether they are prepared or not 🙂
Hi Todd
thanks for sharing dockercon experience. Good to see the blog’s thought alignment with major conference themese
will pass this on to my F5 counterparts
This is a very informative post, Ravi! Working at https://www.nclouds.com I know from first-hand experience how important it is for developers to communicate with ops. It can be the difference between implementing a successful DevOps culture or not.
Hi Frank – thanks for sharing your experiences. Yes, the DevOps initiatives ha spicked momentum and more and more companies are jumping into this bandwagon. We are creating lots of innovative content in near future on this topic, and please stay tuned.