A question that pops up very often lately from enterprises considering cloud deployment models is: Will moving to one public cloud platform constitute a vendor lock-in risk? Also, would a hybrid deployment model between public clouds and on premises, or with another public cloud, reduce or mitigate this risk?
To answer these questions, this article weighs the risk of vendor lock-in vs. the value added to businesses from adopting a vendor’s multiple cloud-based services. We will take a look at these issues from different perspectives, including technology, human resources and organizational level concerns. These, in turn, will take into account: new emerging application architectures, database solutions, managed services, financial factors, security, compliance, employee skills, productivity, overall organizational performance, time-to-market and cloud exit strategy, among other factors.
The goal is to help assess the value added from adopting vendor cloud services compared to only thinking of cloud adoption the old way, from a vendor lock-in perspective. The services evaluated here represent a sample, not an exhaustive list, to illustrate the issues to consider.
Let us start by looking at compliance as added value to a business, versus the cloud service provider (CSP) lock-in risk.
Compliance
Compliance could be one of the most influential factors for regulated industries moving workloads to public clouds to meet business requirements. As a matter of fact, compliance itself might motivate an enterprise to move to the cloud as it expands its operations and markets.
In reality, it can take a massive effort to get private data centers, or a private cloud, to work with multiple compliance frameworks and regulatory requirements, and then to stay in compliance. Examples of compliance standards include the PCI DSS, SOC 1, SOC 2 and SOC 3 reports and laws such as HIPAA. This effort to meet these standards involves time and expertise, along with both an up-front investment and ongoing operational costs, plus bringing onboard some sophisticated skills, which are neither always available nor cheap.
In many cases, businesses simply might not have the capacity to achieve the required compliance in their own operations. Plus, moving to the cloud might enable a business to strategically expand and extend its processes, since it does not need to worry about the compliance of its platform and underlying infrastructure.
CSP leaders, such as Amazon AWS, Microsoft Azure and Google Cloud, provide clients with great compliance services. These CSPs take on all the burdens and struggles of making sure their services comply, and stay in compliance with international, national and industry specific frameworks, such as FIPS 140-2, ISO 27001, ISO 27017, ISO 27018, ISO 9001, etc. These CSP leaders also periodically provide attestation of their compliance.
In most cases, compliance requires not only the platforms but also the underlying infrastructure to be compliant. All services running on top of that infrastructure directly depend on it, and therefore cannot be moved easily, if at all, out of that CSP. This risks a complete CSP vendor lock-in. It cannot be avoided by running workloads in a hybrid or multicloud deployment model, unless you establish a well architected cloud exit strategy, as described in the post Hybrid and Multicloud Deployment Models to Support a Cloud Exit Strategy.
For an enterprise with compliance requirements, using attestation that is acceptable to their auditors and creditors, moving to a compliant cloud provider (with their requirements) may outweigh the vendor lock-in risk, strategically, tactically and operationally. Most large CSPs are keen to stay compliant and have the dedicated resources to achieve this goal. CSPs, especially the leaders, simply have more compliance capacity and continuity than individual private data centers and private clouds.
Emerging Application Architectures
Lately, we have seen a strong trend from many enterprises, to adopt microservice application architectures. Some have a microservice first strategy. They mandate that all newly developed applications should adopt serverless architecture; or if that is not possible, then containers; or if neither of those are possible, then the old way of classic application architectures. Let us take a closer look at serverless and container architectures from the vendor lock-in and added business value perspectives.
Serverless
Serverless does not give clients any control over the platform and the underlying infrastructure, nor any understanding of how it has been set up, or of how to move serverless applications from one platform to another.
For example, AWS Lambda, Azure Functions and Google Functions only show users how to build and deploy an application. The application itself is solely dependent on the underlying infrastructure that only the CSP can access and control. Although most serverless applications are written in open source or non-proprietary programming languages, they might not, or most likely will not, work on another CSP platform, because of the complexity of the infrastructure dependencies.
It might not be worth the effort of analyzing the code using the “6 Rs” application migration effort. You most likely will need to rearchitect and redevelop the application, given all the dependencies and services it interacts with, which are specific to the cloud provider.
We can state with great confidence that serverless applications strategically have high, if not complete, risk of CSP vendor lock-in.
On the other hand, the added value gained from adopting serverless applications is very high at the operational and tactical levels. The benefits in these areas include, for example: reduced operational costs and time-to-market, ease of deployment, more time to design the UX, better scalability, more efficiency and improved latency and flexibility.
Containers
Container architecture gives clients more control over the technology and the platform. It also provides more flexibility in using supporting services, such as orchestrators and service meshes.
Both AWS and Azure container services give clients the freedom to either manage their own container deployments, or use cloud provided services. For example, both CSPs allow the deployment of Docker containers in either an IaaS model or their managed services. They each also offer a managed service for Kubernetes container orchestration.
The dilemma, though, is choosing between the ease of use and integration of cloud-provided managed containers and their supported services, and the operational overhead needed to deploy and manage your own containers. You must also consider the initial cost to build and establish the required platform and infrastructure, and the sophisticated skill sets required.
Overall — strategically, tactically and operationally — it is clear that the container model can offer less vendor lock-in risk than serverless, if clients manage their own infrastructures and platforms. However, strategically, there is a high risk of vendor lock-in when using CSP container managed services.
Container technology has great added business value, including: high ROI, standardized environments, CI/CD efficiency and consistency, immutable infrastructure support, simplicity, faster configuration, rapid deployment, compatibility, maintainability, and, more importantly, it supports a multicloud platform.
For that, containers have less CSP vendor lock-in risk than serverless application architectures, as long as you do not use specific CSP container managed services.
Automation
Not just applications development automation, but also infrastructure and security configuration and remediation automation, are becoming go-to strategies.
Automation and self-healing are at the top of the cloud maturity pyramid. This maturity framework covers: infrastructure as code (IaC), automated provisioning of IT frameworks, security automation, automated secured DevOps and auto recovery and remediation, among other principles and features.
Most leading CSPs provide different capabilities for automation, such as runbooks, CI/CD pipelines, serverless capabilities, managed services, etc. Unfortunately, most of these capabilities are specific to the CSP’s platform — e.g., Azure Automation and AWS Automation.
The added value from automation includes: cost reduction, enhanced productivity, greater availability, more reliability, optimized performance, improved tracking and monitoring, reduced human errors and increased business growth.
Utilizing CSP-specific automation may constitute a very high vendor lock-in risk, although this might be reduced by utilizing platform agnostic tools where possible.
Emerging Database Solutions
A great deal of momentum is building for a managed database services first strategy. This is being driven by the need for reliable, scalable, highly available and continually compliant database solutions, as enterprises have more and more data to maintain.
AWS, Azure and Google offer a very long list of managed databases, including both general and purpose-oriented solutions. These suit many different business use cases, including shopping carts, customer behavior analysis and tracking user posts — the list goes on.
Meeting business needs by using highly available, scalable and well-maintained databases with reduced operational overhead, might come with a high risk of vendor lock-in. But it may not be feasible to try and reinvent a database to perform a task, when there is already a battle-tested database provided by the CSP.
Managed database services have simplified the operating model. They eliminate most of the administrative tasks, including the tedious patching and compliance jobs. They offer highly available and scalable architecture provided by the CSP. They have advanced and well-integrated data archiving and long-term storage capabilities. Clients do not need to maintain another entity and infrastructure to ensure their data format will be up to date for retrieval. Other considerations include the need for decision support systems, as managed database services are easily integrated with CSP analytics and BI tools.
Important factors that reduce the lock-in risk, include being able to get the data back from the CSP, as well as being able to exit gracefully from one CSP platform to another public CSP, or private implementation. However, there are other issues that need to be looked at, such as how the applications using that database were architected and deployed.
But we must point out that if instead of using an open source database, such as PostgreSQL, the enterprise is using some proprietary database, it is already in the midst of a swarm of vendor lock-in issues.
Security
Massive security capabilities are natively available in public cloud offerings. Some of these are mandatory with the CSP’s architecture and deployment models. Examples are the security groups and access controls, which are required to architect AWS VPCs and Azure VNets. Some security features are offered at no cost, others have to be used as part of the architecture.
Also, CSPs natively provide lots of logging and monitoring capabilities at no cost, such as operating system and infrastructure logs. These need to be ingested into some central event logging tools. Recently, even CSPs started offering security tooling, such as SIEM and Security Advisor, which are natively and easily integrated with the CSP’s platform.
Infrastructure security implementation is very clearly a vendor lock-in issue, especially with regard to native capabilities. Also, some security tools might work for one platform but not for another. However, the latter is not a direct lock-in risk, as different tools would be required for each CSP platform. This has financial, skill set and operational difficulties, which can be explored further in another setting.
Some of the added business value provided by CSP security capabilities: regulatory compliance, security automation, flexibility, high availability and disaster recovery, massive DDoS protection and mature physical security. Most important is the integration that has already been done in both compliance and security.
It is worth mentioning that third-party security tools are more mature, having been well tested through the years. Many providers have an established research capability and long experience in the field. They partner with CSPs to ease the integration of their tools into the CSP platforms.
Managed Services
Throughout this article, multiple CSP managed service offerings were discussed. These range from microservice applications and databases to automation and security capabilities. Most of these are specific to the CSP’s platform and infrastructure.
We also outlined the added business value of each specific service. In general, managed services add value to the business through controlling IT costs, reducing operational costs (including labor), increasing efficiency and performance, staying up to date with technology and reducing risk, to mention just a few of the benefits. Obviously, all these also result in enabling the client to focus on core business functions.
One important part of this article is the CSP’s added value with regard to compliance. CSPs offer managed services along with the compliance requirements as one package. Security, a focus following all the data breaches, is integrated with managed services. However, there may be some exceptions, such as managing your own employee access, which are possible in almost all managed services!
Conclusion
Maybe it is time to rethink vendor lock-in with regard to public cloud adoption. There is great added business value to be gained from adopting public cloud offerings. In most cases, the added value at the tactical and operational levels outweigh the possible vendor lock-in risks.
Even so, it might not be wise to build core business revenue generation that is contingent on the continuity of one vendor. This is not necessarily because a major CSP will go out of business, although this highly unlikely possibility cannot be completely ignored from a risk management perspective. However, a CSP may discontinue a service your core business uses. Or, another provider may offer a better or a more advanced service than the one that you are currently using.
Strategically, you need a well-architected backup plan that embraces a hybrid cloud deployment model (see the ‘Cloud Exit strategy’ referenced earlier), in order to mitigate CSP vendor lock-in risk. Even if this risk is residual, a backup plan is necessary to ensure business continuity and competency.
