With the rise of online application stores, it’s never been easier to acquire software but as DevOps processes continue to evolve there’s now a much larger effort under way to eliminate any friction in the purchasing and deployment process. Amazon Web Services (AWS), for example, has made available an extension of the Amazon Elastic Kubernetes Service (EKS) that makes it simpler to add software downloaded from the AWS Marketplace for Containers to a cluster. The extension makes it easier to install, configure and update complementary cloud-native tools using the same commands that IT teams already use, such as the EKS console, command-line interface (CLI) tools such as eksctl, AWS application programming interfaces (APIs) or infrastructure-as-code tools such as AWS CloudFormation and Terraform.
The odds are good most other providers of core platforms will similarly follow suit. The issue now will be determining to what degree the existing processes that organizations rely on to acquire software will be adjusted. Historically, IT organizations have always preferred to centrally manage purchasing processes as much as possible as part of an effort to control costs. IT leaders today are extending those efforts to encourage development teams to use tools that consume cloud infrastructure resources in a way that enables the organizations to meet the levels of consumption that allow them to take advantage of discounts that kick in when specific usage goals are met.
However, many DevOps teams have preferred acquire tools and platforms as they best see fit. Those teams are now being encouraged to consume software within the context of a larger enterprise licensing agreement but the ability of IT leaders to enforce conformity with that purchasing requirement often varies. Many DevOps teams in the name of agility rely on a corporate credit card to purchase whatever tool when required. If it’s an open source tool or platform they may not even ask for permission.
IT leaders, naturally, are trying to find a way to strike a balance between the desire for freedom of choice and innovation on the one hand and the need to put some guardrails in place to control costs. In fact, one of the primary drivers of the rise of platform engineering is that very issue. DevOps costs can easily spiral out of control if each DevOps team acquires and maintains their own tools and platforms.
The degree to which those efforts are going to be successful remains to be seen but they are often intertwined with enterprise licensing agreements that reward organizations for meeting specific cloud infrastructure consumption goals. A recent survey of 326 IT executives conducted by Canonical, however, found that only just over half (53%) qualify for discounts from cloud service providers so there is clearly room for improvement when it comes to optimizing cloud infrastructure costs.
The challenge, as always, is if IT leaders want DevOps teams to follow their lead, they need to make the process for deploying tools and platforms as frictionless as possible. Developers are not known for their willingness to fill out a purchasing request forms to gain access to a tool when there’s another tool they might like better that is readily available via any number of public repositories.
There are multiple IT services providers and consulting organizations that have the expertise required to navigate enterprise these licensing agreements. Most of these agreements should not be entered lightly because not every provider of a DevOps tool or platform is aligned with every cloud service provider to the same degree. Each provider of a DevOps tool or platform needs to have agreements in place that credit usage of the platform toward cloud infrastructure consumptions goals. New Relic, for example, just announced such an agreement with Microsoft.
Alas, licensing agreements don’t always get the level of scrutiny they deserve but as more organizations realize the extent to which they have become dependent on cloud infrastructure they are starting to have a greater appreciation for all the devil that currently exists in the details of those agreements.