Customers looking to move to the cloud still voice concerns around ‘vendor lock-in’. These range from generalised ‘eggs in one basket’ worries to specific concerns about service resilience and corporate DR assurance. Companies express worries that once they are ‘in’, it will be difficult and expensive to get ‘out’. Is this valid for cloud specifically?
Reliance on a single service provider is not new. Companies looking to migrate to the cloud are (in general) moving from a managed datacenter. Usually the hardware (and much of the software) is leased from the datacenter provider. Resilience is implemented by additional data center presence from the same service provider. Contracts are usually fixed terms of 3, 5 or 10 years. Capacity right-sizing is possible, but there is often over-capacity in the platform. Usually, it is considered more operationally straightforward and cost-effective to use one data center provider for everything. Migrating from one data center provider to another would be a major project, carrying all the risks and costs of large-scale infrastructure changes. Vendor lock-in has been a long-running issue, and not confined to cloud deployments. And for companies, the issue remains, regardless of the service provider – where to put a large-scale infrastructure platform?
Cloud platforms offer more flexibility than traditional data center services. The ability to provision additional capacity on-demand.
- No long-term contract requirements (Reserved capacity is good cost management practice, not a contractual requirement).
- There is no contractual lock-in.
There is no contractual lock-in.
However, technical lock-in is a more valid concern. Platforms mostly built on IaaS resources can be seen as more ‘portable’. Provisioning and configuration management tools such as Terraform and Ansible provide a layer of abstraction between the underlying infrastructure and applications. However, the more extensive benefits of cloud services – reduced operational overhead, ability to develop new services and to match usage to capacity most effectively – are realised when moving away from ‘traditional’ server-based architectures and utilising PaaS, SaaS and FaaS services. However, the more cloud native the services that are used in a platform (ie, moving away from IaaS to more managed services), the more technically embedded it can be seen to be with a particular provider.
Lock-in mitigations
(eg, config management tooling, containerization, loose-coupling between services)
What approaches can be used to mitigate against perceived lock-in?
Multi-cloud strategies offer the ability to locate services according to best fit, and/or to implement resilience across CSPs. However, this brings its own admin overhead, including an additional layer of third-party multi-cloud management tools to provide a unified view of services. A multi-cloud implementation requires multi-cloud skills and multi-cloud tooling configurations, and this may not be practical for smaller companies. The reduction in operational overhead offered by managed resources may be negated by the additional overhead of managing configurations across multiple providers. Implementing service resilience across multiple CSPs is also likely to incur additional costs in terms of duplicated resources.
For organizations to whom a multi-cloud presence is not practical, what approaches can provide some assurance over vendor lock-in?
Abstracting the layers of a platform using tools such as Terraform and Ansible enable easier modelling between CSPs. Although the details of a specific Terraform configuration would be different between, say, AWS and Azure, the layer of abstraction remains the same. Having an architectural view of application services and interactions, abstracted from a specific CSP implementation, mitigates against seeing a platform only in terms of CSP technologies. Implementing components that interact over standard APIs enable a platform to be modelled on a different CSP. Containerization offers an amount of portability, as docker images themselves are independent of specific CSP services. However, containerized applications require an orchestration layer; this can be provider specific (ECS), or provider agnostic (Kubernetes). Both approaches add a layer of design and operational complexity, and a decomposed, containerized architecture is not suitable for all applications.
A strategic analysis of current and medium term technical requirements can clarify alignment with a particular CSP prior to migration.
Company A may prioritise PaaS offerings for their corporate applications; Company B may decide based on managed container platforms for building multi-tenant services. Providers are constantly adding new service features, in response to both competition and customer feedback. Real-term prices have fallen as a result of innovation and economies of scale. It is very unlikely that a company will hit a ‘technical dead-end’ with a particular cloud provider. For many companies, there is more value in selecting a provider and focusing the time and effort in maximising the use of services, than in expending resources on developing and operating continuous lock-in mitigation processes.
