The Importance of Licensing to Equalize Dev and Production

We’re all aware that dev/test != production environments. While the software stacks upon which applications are deployed may be (and hopefully are) the same, there still remains a whole lot of “infrastructure” (that’s everything else) that isn’t the same. Routers, switches, security devices, load balancers, caches, and other devices dedicated to ensuring the secure delivery of applications to hungry consumer and corporate users simply don’t exist in the dev/test environment. That’s particularly true as organizations continue to view “the cloud” as its ideal dev/test environment while continuing to insist that production remain firmly rooted on-premises.

The State of the Developer Nation Q3 2015 from VisionMobile noted this phenomenon: Almost half of developers are hosting their apps in private clouds, well away from the public infrastructure which grabs all the headlines. Even Amazon Web Services, the biggest cloud by far, can only boast of being the primary platform for 16% of software developers, while 44% of them are happier to keep their clouds safely at home.

This dichotomous environment is just as likely to result in deployment problems as that of the traditional “dev is not production” challenge faced by organizations since, well, since a very long time and happen more often than we’d like to admit. Preliminary results from an Electric Cloud sponsored survey noted this as reality: “When asked whether their organizations have software production release problems, a whopping 77 percent of the respondents said that they do, either occasionally (62 percent) or frequently (15 percent).”

Developers also recognize this as the cause of problems that crop up in production and ultimately delay deployment. 28% of developers responding to a survey in mid-2015 said “over 50% of production problems could have been found and fixed with the right test environment.” And more than half (52%) said “between 25% and 50% of production problems would have been fixed.”

One of the problems that contributes to the inability to equalize dev and production environments has long been that most of the infrastructure in a production network were hardware components. It was neither operationally or financially prudent to duplicate that infrastructure in both environments. But now we’re in the age of virtualization and software, where a great deal of infrastructure is available in virtual or pure software form factors. Most importantly is that the infrastructure most tightly coupled to the app themselves – the app services like load balancers, app firewalls, and optimization – and thus most in need of the testing and tweaking required during a deployment, are available in virtual, pure software, and cloud form factors.

So why haven’t organizations addressed the disparity between dev and production by ensuring that the platforms providing those services are available to developers and operators who would most benefit from the ability to test before releasing to production?

It’s in part due to licensing.

See, software has long had the notion of license pools from which licenses could be managed. When the software wasn’t running for me, you could use the license. And when you weren’t using it, Alice could use it, and so on. A single license could support fifteen people; one at a time. And the mechanisms for managing that were available; all the way back to Novell and its varied services. You could use, reuse, and share licenses across your environment.

Network-deployed infrastructure, however, has traditionally not had these options because most of the time it was just shared by everyone and you paid once and didn’t worry about it. Today, however, the impact of cloud and containers and highly volatile environments have brought to the fore the need for software-like licensing capabilities to ensure operators and developers can, in fact, at least nominally equalize dev and production.

Pooling licenses for app services is a critical component to ensuring DevOps can not only seamlessly transition architectures from dev to production but to enabling developers the ability to test apps within the context of the services that will most frequently interact with their applications. Being able to architect and develop an appropriate scalability pattern using a programmable proxy, for example, is not a task you want left until the app is already in the production environment. Dev and Ops needs the ability to design, develop, and test not only the pattern but its interaction with the app its scaling before it moves into the production pipeline. That means equalizing  dev and production, which means enabling provisioning and use of the same infrastructure as will exist in the production environment.

By coupling a robust licensing system with the means to treat that infrastructure as code (that’s templates and APIs) we can start to equalize dev and production in a way that addresses the issue of problems cropping up in production (and thus causing delays) while simultaneously reducing the amount of time spent testing the infrastructure service configurations in production.

It’s a win-win-win for dev, ops, and the business. And it’s made possible by a modern, flexible licensing model.

Licensing really is critical to equalizing dev and production.