Vendor-Locked DevOps Strategies

Developing specialized solutions that work specifically with one cloud provider can cause vendor lock-in, which is the inability to effortlessly move from one provider to the next due to proprietary constraints. In this column, vendor lock-in refers to an organization accepting the use of specific features from a specific cloud to facilitate its IT strategy with those tools. Given the goal of automating code building and deploying to a PaaS solution, if the organization uses CodePipeline from Amazon Web Services (AWS), the efforts could not be translated to Microsoft’s Azure DevOps solution. My goal in this column is not to dissuade organizations from creating cloud-agnostic strategies. This article discusses how the limitations and hindrances of cloud-agnostic and vendor-locked strategies are two sides of the same coin.

Perception of Vendor Lock-In

Organizations may avoid vendor lock-in, believing that being cloud agnostic will avoid having the constraints of proprietary limitations and hindrances on facilitating strategic IT goals. However, recent studies have shown a trend toward cloud-agnostic architectures restricting the facilitation of strategic IT goals as each cloud has limitations needing a workaround.¹ The strategic shift results from organization goals being more cloud-centric and cloud providers focusing on integrating within their own ecosystem instead of being multi-cloud or cloud-agnostic focused. To be truely cloud-agnostic, organizations go to great lengths to have automation that runs on the core infrastructure of a cloud’s IaaS solution. Using cloud-specific tools, especially those requiring custom APIs, begins the transition from a cloud-agnostic intent into a vendor-locked solution. Any challenge that hinders the facilitation of an IT goal in a cloud-agnostic architecture would need to be solved without using a specialized tool, such as Microsoft’s Azure DevOps or AWS CodePipeline. Vendor-locked architectures can more freely integrate within the cloud provider and use extensive tooling, most of which are designed to work with little configuration by the user.

A Cloud Migration Scenario

Consider the scenario of an IT organization with the strategic IT goal of moving its Python-based Web application with a database backend from a local deployment to a notable cloud provider. The application must run in at least two availability zones, static files must be served via a CDN, and the database must be highly available. The expected impact is reduced deployment time, improved cost-to-serve, and improved resiliency. To adhere to best practices of cloud design, cloud providers promote the idea of tenant isolation through custom virtual private clouds (VPCs) and having a Web frontend be public while the backend resources, such as a database, are put in a private subnet accessible only by the frontend service.² It should be noted that no architecture is complete without monitoring. In a DevOps solution, there are several metrics that could provide insight into critical performance measures;³ these metrics should also be centralized to help prevent sprawling.

Cloud-Agnostic Disadvantages

To devise a plan for a cloud-agnostic solution, an organization must already contend with how to architect the network structure to adhere to the aforementioned best practice. While many cloud providers share the term VPC and are structured similarly, how these resources are created varies by provider. An automated approach is preferred because the configurations should be version controlled. For a cloud-agnostic design, automation is limited as Terraform and cloud-specific CLIs would require refactoring when moving to another provider. Logging and metrics should be handled once the network has been established and the resources successfully created. In a cloud-agnostic schema, metrics and logging are more readily available from the logging service specific to that cloud. The organization must automate the export of those logs from the cloud provider and into a centralized aggregation point if they intend to keep them after migration to another provider. Certain architectures lend themselves to being more cloud agnostic than others. One example is using Kubernetes instead of a provider’s VM service. Though Kubernetes can be deployed through standard Kubernetes commands or Helm regardless of the cloud provider, this would not solve the creation of the virtual network. Lastly, cloud-agnostic solutions may require more specialized expertise, one of which would be an expert in multiple clouds. Hiring multiple engineers to account for the skills needed could be a disadvantage for an organization.

Cloud-Agnostic Advantages

Cloud-agnostic designs have many benefits, which is why they are still prevalent in IT. One major benefit is granular control over the cost. These solutions are often designed to be multi-cloud capable and cloud-agnostic; this allows organizations to pick the cheapest cloud services. Other benefits include greater portability and highly capable disaster recovery plans. Imagine a cloud provider that suffers a catastrophic event, cloud-agnostic disaster recovery could be enacted by deploying the solution to a different cloud provider in a short time. Additionally, if the strategic goal is universal, cloud-agnostic architectures allow the freedom to maximize how that goal is accomplished.

Vendor Lock-In Disadvantages

Vendor-locked designs limit the organization to the design capabilities of the chosen cloud. Depending on the specific desired functionality, an organization may need to create workarounds of varying complexity. These workarounds are not likely to be transferrable to other cloud providers, which may prompt the need to rework the solution to fit the capabilities of another provider during a transition. Vendor-lock becomes detrimental to the organization when a cloud is chosen, effort is put in, and the organizational goals are not aligned with the final product. The need to shift a solution to another provider can be costly and, in some cases, lowers morale.

Vendor Lock-In Advantages

In the context of cloud providers, vendor lock-in is not a hindrance. Rooting solutions within a reputable cloud allows organizations to develop highly integrated solutions into a tech ecosystem, allows for specialized talent throughout the development process, and centralizes infrastructure monitoring and tooling. A bonus of choosing a specific provider is that the tooling is often premade and extensive. Take Azure DevOps as an example. Those afraid to leap to vendor-lock and choose something like Jenkins, Koji, or another CI/CD tool will be happy to know that Azure DevOps is a capable build-and-deliver tool that can source files from GitHub or Azure Repos, uses build triggers for automated building on the chosen branch, and can deliver to many hosting services like Azure VM and Azure Web Apps with little setup; Azure DevOps has a drag and drop interface for building the required pipeline YAML file.

Lessons for Stakeholders

This article has covered what vendor lock-in is, the comparative advantages and disadvantages of vendor-locked solutions versus cloud-agnostic designs, and the shift of perception toward vendor lock-in, showing that proprietary constraints of cloud providers can hinder strategic IT goals regardless of vendor-lock status. The increasing number of tools and interoperability within top cloud providers should empower stakeholders and decision makers alike to explore vendor-locked DevOps solutions when they otherwise would not. Previously, stakeholders have been weary of getting trapped within a specific provider because of the amount of work needed to transfer to a different provider. Today, cloud providers have created solutions that have abstracted much of the work, such as deploying Web applications and setting up code-building pipelines. To avoid the vendor-locked transition, cloud-agnostic designs must tread lightly when adopting these tools. Vendor-locked solutions allow stakeholders to embrace the integrated functionality of a cloud-specific solution fully and allow a company to source talent specific to that provider. Regardless of the chosen solution, it is important that all stakeholders ensure their provider can facilitate accomplishing the organization’s strategic goals. Stakeholders must also understand the impact of provider limitations on goals and architecture design. Failure to do so could result in schedule setbacks, budget implications, or loss of trust within the organization.