Cloud Disruption Continues with Continuous Deployment

Back when cloud first became a thing there were many who predicted its tumultuous impact on organizations. Many viewed the forthcoming disruption in terms of its impact on the traditional infrastructure market, as it’s very hard to move from a tangible product to one that’s nearly ephemeral in nature. And while that was true, it has been a bumpy ride as the infrastructure market returns (note that it’s a return, not a transformation) to a software-based perspective with an eye toward the cloud.

There were fewer experts who noted that the disruption wasn’t just of the physical world, but the business world, as well. Cloud and a more software-oriented approach to building the networks and infrastructure necessary to succeed in an application (and API) economy also required a shift in business models. Specifically, how the myriad network and infrastructure components were managed- including licensing.

You see, licensing a single box is easy (comparatively). A license is purchased, applied, and voila! It’s yours. But software has never (and I mean never) been that simple. Some of you may recall the firestorm igniting by certain software giants in the early aughts who somewhat frantically tried to adjust from the single-CPU licensing model they’d been using for years to a multi-CPU, multi-core mathematical nightmare not even “new math” could solve easily.

The same thing happened with cloud; where its utility billing model made the move back to software a lot more difficult than just tweaking some code to fit into a virtual or cloud-based hypervisor.

Now comes DevOps with its notion of “continuous” everything and suddenly licensing is a significant hurdle over which the network and infrastructure market is going to have to jump. It’s not only the speed with which network and infrastructure services must suddenly be provisioned and configured, it’s the rate of change that’s problematic. In the old days you deployed an infrastructure component and it stayed where it was. But now, you deploy many infrastructure components, sometimes many times a day/week/month. The frequency of change is increasing and the demand for that change is creeping (necessarily) into the network. Continuous Integration (CI) and Continuous Delivery (CD) are the purview of app dev and ops. But continuous deployment requires collaboration across the entire software deployment spectrum – which means production, too.

Testing earlier in that pipeline (like in test or QA, not production) is critical to achieving not just fast deployments, but reliable deployments. Deployments that aren’t eating up developers time because they run into problems in production due to differences in the network and infrastructure architectures.

A flexible, software-driven approach to licensing can mitigate that challenge as well as the need for more agility in the production network. By providing the means by which licenses can be pooled, managed centrally, and handed out with the ease of an API call, organizations can equalize dev and production (important for reliability and consistency), as well as supporting the need to scale out in production when using software versions of network and infrastructure platforms.

That’s why both BIG-IQ 5.0 and iWorkflow 2.0 support agile licensing for thousands of BIG-IP instances. The need to manage licenses – but not necessarily the instances licensed – is paramount for enabling dev and ops to integrate and test earlier in pre-production deployment phases. BIG-IQ 5.0 focuses on managing BIG-IP, true, but it’s also able to manage the licenses for up to 5000 BIG-IP instances in a flexible model that is supportive of a the more fast-paced, agile dev environments being forged by DevOps today. That’s especially critical as architectures are evolving and app services like load balancing become more tightly coupled with apps (and microservices) as part of the architecture rather than external “bolt on” entities. 

The disruption inherent in cloud, both operational and business model, is still being felt today. But it has to be more than just a “put your code in a VM/container” approach. It also has to adapt to the changing business models that cloud has introduced and perhaps unintentionally driven to be “the way” it will be for the foreseeable future. F5 BIG-IP 5.0 and iWorkflow 2.0 are designed to fit into “the way” and ensure that as organizations adopt that foundation in their own data centers – whether those are physical or ephemeral – the app services they need will be delivered with alacrity.