Business strategies for avoiding vendor lock-in
This section summarises both the desires and experiences of the participants who contributed to this study. Moreover, this section presents strategic approaches for mitigating the risks and challenges of lock-in in cloud migration.
Awareness of the commonalities among cloud providers
To refer back to the first research question of interest to business adopters stated in section 1.1. UK business decision makers are rightly concerned about the risks of being locked into a single cloud service provider and the implications of such a risk including not having a clear exit strategy. There is a need for these organisations to understand what the exit strategy looks like, even if it is unlikely that they will exit in the near future – besides, no company would want to buy into a service where they feel they had no alternative provider. In this connection, one possible strategy will require decision-makers to possess a comprehensive understanding of the heterogeneity that exist between cloud semantics and the cloud interfaces. This often requires an awareness of the commonalities (i.e. complexities and dependencies) among services offered by cloud providers and standards used. By clearly understanding this, organisations will realise how the cloud’s loose structure can affect data/application movability and security of data sent in it. This can be done by having an in-depth understanding of how data and application components are handled and transmitted in the cloud environment. When this is well understood and harnessed (at pre contractual phase), the benefits to the organisations become apparent (at post migration phase). Additionally, enterprises can be more interoperable and avoid vendor lock-in strategically by selecting vendors, platforms, or services that support more standards and protocols (as further discussed below in Section 4.1.3). This is essentially important in the vendor selection process as it enables organisations to maintain a favourable mix of cloud providers and internal support. These strategies can help organisations to form a plan for an efficient and effective migration and adoption process. Actually, having a clear understanding of the disparity between cloud semantics and service interfaces offered by different cloud vendors can help significantly to reduce the effects of vendor lock-in.
Substantial training and stakeholder engagement is necessary to develop an understanding and agree solutions on specific lock-in concerns [43–45]. Otherwise, cloud services offered to enterprises may not be properly assessed for potential lock-in risks before decisions are made to use the service [46]. Moreover, the results in Fig. 6 indicate a general lack of understanding and awareness of lock-in problem in the cloud. The low response gained from participants who identified over dependence on a single cloud provider (35.1 %) and difficulty to move data back in-house or across to a different cloud provider (28.8 %) platform illustrates the unawareness of practitioners on the potential effect of cloud lock-in problem. To infer from this result, it appears the risk of dependency is a more significant barrier than data lock-in. This seems counter intuitive considering the practical challenges associated with the data lock-in when extending the use of cloud in the enterprise. However, the probable explanation is that presently most organisations are too reliant on cloud providers for operational and technical support [47], thus they fail to fully prepare to deal with unexpected and undesirable data lock-in issues in the cloud (referring to Fig. 10). As pointed out by Bradshaw et al. [28], lock-in will become more of an issue as the cloud computing market matures. In agreement, Lipton in [48] admits that the complexity and cost of switching (or porting) a cloud service to a different provider is often under-appreciated until it is too late. Therefore it can be claimed that as long as corporate data is not locked-in moving to another cloud provider is just a matter of enduring a switching cost. Such cost can be reduced by employing best practices such as choosing cloud providers that support: (i) the use of standardised APIs wherever possible; (ii) wide range of programming languages, application runtimes and middleware; (iii) as well as ways to archive and deploy libraries of virtual machine images and preconfigured appliances. Overall, these findings suggest respondents do not currently have sufficient understanding on possible technical and non-technical issues of lock-in that can occur in the cloud environment. Thus, it is recommended that organisations remain meticulous when making decisions towards the selection of vendors, taking into consideration potential difficulties associated with switching vendors. However, it is probable for organisations to suffer financial loss if they did not make a strategically correct vendor selection decision from the very onset.
Well-informed decision making
The study has found that for UK organisations, when it comes to evaluating the business risks of vendor lock-in for or against cloud migration, surprisingly, a vast majority (66.4 %) of respondents said making well-informed decisions before selecting vendors and/or signing the cloud service contract is an extremely important part of the decision-making process (refer to Fig. 11). This signifies that as cloud computing becomes more widely used for various applications across different industry sector[s] and size[s], UK businesses are finding it extremely important to understand ways to maximize benefits and minimize the risks of lock-in. In essence, this is particularly important given the plethora of vendors in the market place today, with each offering businesses proprietary cloud-based services and contracts that have different specification (and legal agreements). In regard to the interpretation of this finding, our study suggests that the vetting process for selecting vendors is a critical aspect for effective cloud migration with minimized risk of lock-in. Moreover, such finding exemplify the need for organisations to look beyond the vendor selection phase, and focus on constantly monitoring any development or changes in the cloud that may impact data security or hinder interoperability and portability – thus facilitating a lock-in situation. However, the findings (in Fig. 11) also reveal a gap in understanding, regarding how organisations should manage the risks of vendor lock-in. A sign of lack of understanding is explained by a smaller percentage (8.4 %) of participants identifying the need to build perceived lock-in risks into initial risk assessment. This is quite enlightening, in spite of the relevance of this strategy in the vendor selection phase. Possible interpretation of these may be attributed to the general lack of understanding and experience (on the part of IT and business managers) in respect of technical aspects of complex distributed cloud-based solutions.
Standards and cloud-based solutions
The impact caused by vendor lock-in problem due to lack of standards is what enterprises should be wary about when considering migration to cloud computing [29]. Despite the number of studies in recent years underlining the high relevance of standards in cloud computing, unfortunately this study reveals that most UK organisations still lack a comprehensive understanding on the importance of standards in minimising lock-in risks. In fact, as pointed out by [49], there are two ways a business can achieve the full potential of cloud computing (i) either by changing providers according to their needs (ii) prioritising or simply combining different solutions to get the best of the breed services. However, this will require standards and interoperability to be supported by all providers, but it is often not the case. An informative example in this context is seen in research in [50], arguing that many cloud providers are concerned with the loss of customer that may come with standardisation initiatives which may flatten profits, and do not regard the solution favourable. Based on our research findings, from a business perspective, we suggest the following as key measures to improve customer retention and engender trust in enterprise cloud migration: 1) the quality of service (QoS) guarantee, 2) data protection and metadata ownership, 3) contract termination, as well as 4) data export functionality. Furthermore, as discussed in our previous study [4], in the absence of standardisation, UK businesses willing to outsource and combine a range of services from different cloud providers to achieve maximum efficiency, irrefutably, will experience difficulty when trying to get their in-house systems to interact with the cloud. Likewise, the lack of standardisation also brings disadvantages, when migration, integration or exchange of computer resources is required. This is consistent with the research findings presented in this paper (see Fig. 10). Unsurprisingly these issues were identified from a business perspective, considering the important role of standards in at least mitigating such concerns. Hence, business stakeholders’ should be aware that decisions to adopt or move resources to the cloud require adequate risk analysis for potential lock-in. Based on this analysis and the evidence in Fig. 10, we believe there are opportunities that exist for the regulatory and standard bodies to take the necessary action. One potential solution would be to standardise the APIs in such a way that businesses (or SaaS developers for example) could deploy services and data across multiple cloud providers. Thus, the failure of a single cloud provider/vendor would not take all copies of corporate data with it.
Standard initiatives
Cloud-specific standards are regularly proposed as a way to mitigate vendor lock-in and achieve portability and interoperability [50]. It is expressed in [51] that many providers are concerned with customer churn rate that may come with standardisation. But according to [52], unless there is a well-accepted and widely used standard, it remains a questionable solution. Therefore as a partially adopted standard would represent a poor solution [53], many cloud vendors now support the creation and adoption of new standards by proposing them to standardisation groups. Clear examples of such cloud-specific standards are OASIS CAMP [54] for PaaS and TOSCA [55] for IaaS. Both specifications aim at enhancing the portability and interoperability of applications across different clouds. We review the two OASIS cloud-specific standards (TOSCA and CAMP) and their potential for dealing with the lock-in problem.
TOSCA
The Topology and Orchestration Specification for Cloud Applications (TOSCA) [55], is an emerging standard that enhances service and application portability in a vendor-neutral ecosystem. TOSCA specification describes a meta-model for defining IT services. This metamodels defines both the structure of a service (topology model of a service) and its operational aspects (such as how to deploy, terminate, and manage this service). Service templates are interpreted by a TOSCA-compliant environment (e.g. OpenTOSCA [56]), which operates the cloud services and manages their instances [54].
Managing cloud services requires extensive, mostly manual effort by the customers. Further, important cloud properties (such as self-service and rapid elasticity) can only be realised if service management is automated. In this aspect, TOSCA allows application developers and operators (DevOps) to model management best practices and reoccurring tasks explicitly into so-called plans (i.e. Workflows). TOSCA plans use existing workflow languages such as Business Process Model and Notation (BPMN) [57, 58] or the Business Process Execution Language (BPEL) [59]. To increase portability, TOSCA allows service creators to gather into plans those activities necessary to deploy, manage, and terminate the described cloud service. TOSCA also enables a cloud service creator to provide the same plan or implementation artefact in different languages (e.g. a plan can include the same functionality twice – in BPEL and BPMN). An application ported to the cloud using TOSCA can be composed of services provided by different cloud providers and a user can decide to a specific service with a similar one from a different vendor.
CAMP
Cloud Application Management for Platforms (CAMP) is an Oasis cloud-specific standard designed to ease the management of applications across platforms offered as a service (PaaS) [54]. The CAMP standard defines a self-service management API that a PaaS offering presents to the consumer of the platform. The specified CAMP API provides a resource model to describe the main components of any platform offer. For instance, independent software vendors can exploit this interface to create tools and services that communicate with any CAMP-compliant cloud platform via the defined interfaces. Likewise, cloud vendors can also leverage these interfaces to develop new PaaS offerings, or adapt the existing ones, which would be compliant with independent tools. Thus, cloud users save time when deploying applications across multiple cloud platforms.
At present, the effort of deploying applications with vendor-specific tools across multiple PaaS cloud platforms is a non-trivial task. Developers and system operators often face the barrier of redeploying applications to other providers’ platform because tools are incompatible. However, this can be simplified using the CAMP interface common to both source and target platforms. To simplify the deployment efforts and support migration across multiple cloud platforms, CAMP defines the Platform Deployment Package (PDP). A PDP is an archive containing a plan file together with application content files such as web archives, database schemas, scripts, source code, localization bundles, icons etc. This archive can be used to move an application and its components from platform to platform, or between a development environment and an operative target platform.
Portable hybrid IT environment
To infer from discussion in the preceding section, the vendor lock-in risk is a valid concern for organisations migrating to the cloud. Considering that lock-in is undesirable, and cannot be eradicated, then how can businesses mitigate its associated risks when migrating to the cloud? From a portability perspective, it becomes critical that organisations’ data is sharable between providers, since without the ability to port data or application, it would become simply impossible to switch cloud service providers at all [60, 61]. Cloud portability is a salient consideration to enable organisations migrate a cloud-deployed asset to a different provider and it is a direct benefit of overcoming vendor lock-in [62]. Generally, reconfiguration of systems and applications to achieve interoperability is time/resource consuming and may require a considerable amount of expertise, which could be challenging for some organisations. Therefore, from a business perspective, portability should be seen as a key aspect to consider when selecting cloud providers as it can both help mitigate lock-in risks, and deliver business benefits. This means allowing applications, systems and data components to continue to work correctly when moved between cloud providers’ (hardware and/or software) environments [35]. Indeed, the need for organisations to easily switch cloud providers with their data alongside have been a consistent theme throughout the discussion presented hitherto.
To expatiate on the question stated above, it is helpful to view the situation from a business perspective after deploying a SaaS cloud service such as CRM (which according to Fig. 7, 52 % of organisations have already adopted the cloud model). Suppose these organisations use the SaaS CRM and over time, perhaps, the terms of use or the price of the cloud-based CRM service become less attractive, compared to other SaaS providers or with the use of an in-house CRM solution. If the organisation decides to change providers for whatever reason, data portability aspects must be considered. For SaaS cloud services, data formats and contents are handled by the service provider thereby making data portability a major consideration. The issue of importance in a SaaS-level migration is the compatibility of the functional interface presented to end-users and any API made available to other customer applications. In order to alleviate this problem, the APIs made available by the SaaS service should be interoperable with the interface provided by the on-premise application or data that is being replaced. On the other hand, the data handled by one vendor’s software should be importable by the second vendor’s software, which implies both applications have to support the common format. Standard APIs for various application types will also be required. If the APIs are not interoperable, any customer application or data using the APIs will need to be changed as part of the migration process.
Data portability is usually of most concern in a SaaS, since in these services, the content, data schemas and storage format are under the control of the cloud service provider. The customer will need to understand how the data can be imported into the service and exported from the service. Further, SaaS applications also present interoperability barriers. The lack of adoption of standard APIs for SaaS applications makes switching from one SaaS application to another difficult as it involves a change in the interface. This also applies to any application or system belonging to the cloud service customers that use APIs offered by the SaaS application. Data synchronization is another concern, encountered in cloud interoperability and not in data portability [63]. To further substantiate this argument, we elucidate on the need for a portable hybrid environment by highlighting two main categories of portability scenarios encountered in current cloud service market: 1) porting legacy applications or data; and 2) porting cloud native applications or data. In scenario 1, due to dependence on particular technologies and data organisation, the legacy software assets currently require a significant amount of effort to be invested in porting them into the cloud environment. Whereas in scenario 2, even when applications and data are written from scratch for a cloud environment, they are usually locked and targeted for a specific cloud [63]. Thus, the effort of porting in a different cloud is usually a onetime exercise [63]. However, in both scenarios, the main problem is that there must be a capability to retrieve customer data from the source cloud service and also a capability to import customer data into the target cloud service. Thus, data portability is based on import and export functionality from cloud data services for data structures. This is commonly done through the existence of some API (or web interface) associated with the cloud service – it may be a generic API or a specific API, unique to the cloud service.
In light of such challenges, [64] claims that ensuring data portability is a major challenge for enterprises due to the large number of competing vendors for data storage and retrieval. The ability to move data also emerges as a management issue for cloud computing. Therefore, in response to the question of data movability, it is important to note that the API used for the source service may not be the same as the API used for the target service and that different tooling may be required in each case. The main aspects of data portability are the syntax and semantics of the transferred data. The syntax of the data should ideally be the same for the source service and the target service. However, if the syntax does not match (i.e., the source may use JSON syntax, but the target may use XML), it may be possible to map the data using commonly available tools. If the semantics of the transferred data does not match between the source and target services, then data portability is likely to be more difficult or even impossible. However, this might be achieved by the source service supplying the data in exactly the format that is accepted by the target service. Therefore, on a long term, achieving data portability will depend on the standardization of import and export functionality of data and its adoption by the providers. The aim is to minimize the human efforts in re-design and re-deployment of application and data when moving from one cloud to another. To this end, it becomes vital that any enterprise cloud migration project can be carried out without any disruption to data availability since data is an organisation’s most critical, ubiquitous, and essential business asset [29].
Observations
This paper confirms that UK organisations are increasingly adopting cloud services, and it also reveals that they have been progressively migrating services perceived as non-mission critical (i.e. where lock-in and security risks seem lower) such as general purpose applications suites, email and massaging applications. This strategy used allows the organisations to get a feel for how the cloud environment works before fully committing themselves. However, this is generally not the case for organisations surveyed. A lesser minority (see Fig. 7) seem to have adopted core systems in the cloud (e.g. ERP and CRM), including accounting and finance applications. At present, as indicated by the Cloud Industry Forum [39], cloud providers or vendors are better placed, if they ensure such capabilities like the trial or “test and see” strategy (whether completely free or paid for time limited pilot) is made available within their go-to-market strategy. It is worth underlining that, free of charge or low cost does not necessary mean free of lock-in risks or low proprietary lock-in risk. Organisations must be cautious of potential areas of lock-in traps and take adequate measures to mitigate their exposure; e.g. choice of operating environment, programming models, API stack, data portability etc. Further, businesses should take heed of other legal, regulatory, or reputational risks that may exist. This is vitally important if the data involved is not just for testing, but constitutes real corporate data, perhaps even confidential or personal data. It is interesting to note that 28 % of organisations surveyed have already adopted the cloud model for hosting accounting and finance applications (refer to Fig. 7).
On a conclusive note, it is believed that the discussions presented herein, above all, indicate hypothetically that vendor lock-in risks will reduce cloud migration, which in turn affects the widespread adoption of cloud computing across organisations (small or large). Thus an emerging research agenda arises as to investigate: 1) ways to come up with multijurisdictional laws to support interoperability and portability of data across cloud providers platform, along with effective data privacy and security policies; and 2) novel ideas of avoiding vendor dependency on the infrastructure layer, platform, and through to the application layer as lock- cannot be completely eliminated, but can be mitigated. However, these require, not just tools and processes, but also strategic approaches – attitude, confidence, comfort, and enhanced knowledge of how complex distributed cloud-based services work. Sometimes the inhibitor to cloud adoption and migration in most organisations, in principle, are the attitude, knowledge, and confidence of the paramount decision makers. Thus, for most organisations today, the challenge is clear that they simply do not understand potential effect of lock-in to the business. While the business benefits of cloud computing are compelling, organisations must realise that achieving these benefits are consistent with ensuring the risks of vendor lock-in and security implication of such risk is clearly understood upfront. When identified, such risks should be mitigated with appropriate business continuity plans or vendor selection, prior to migration to the cloud.
Potential of DevOps tools for avoiding vendor lock-in
Issues with cloud lock-in surpass those of technical incompatibility and data integration. Mitigating cloud lock-in risks cannot be guaranteed with a selection of individual open (technology-centric) solutions or vendors. Instead, the management and operation of cloud services to avoid lock-in should be addressed at a standardised technology-independent manner. In this respect, we present a concise discussion on the potential of DevOps [65] and of tools (such as Chef, Juju and Puppet) that support interoperable management.
DevOps is an emerging paradigm [66] to eliminate the split and barrier between developers and operations personnel. Automation underlies all the practices that constitute DevOps. The philosophy behind DevOps is to bring agile methodologies into IT infrastructure and service management [65]. This is achieved by implementing the concept of “Infrastructure as Code” (IaC) using configuration management tooling. An automation platform is what provides the ability to describe an infrastructure as code. IaC automations are designed to be repeatable, making the system converge to a desired state starting from arbitrary states [67, 68]. In practice, this is often centred on the release management process (i.e., the managed delivery of code into production), as this can be a source of conflict between these two groups often due to different objectives [68]. DevOps approaches can be combined with cloud computing to enable on-demand provisioning of underlying resources (such as virtual servers, database, application middleware and storage) in a self-service manner. These resources can be configured and managed using DevOps tools and artifacts. As a result, end-to-end deployment automation is effectively enabled by using the DevOps approaches in cloud computing environments [69]. Tools are emerging that address building out a consistent application or service model to reduce the proprietary lock-in risks stemming from customized scripting while improving deployment success due to more-predictable configurations. Today, several applications provisioning solution exists that enable developers and administrators to declaratively specify deployment artefacts and dependencies to allow for repeatable and managed resource provisioning [56]. Below, we review some DevOps tools among the currently available ones that may help enterprises simplify their application release circle.
Chef
Chef is a configuration management framework written in Ruby [70]. Chef uses an internal Domain Specific Language or DSL to express configurations. Configuration definitions (i.e. ruby-scripts) and supporting resources (e.g. installation files) in Chef are called recipes. These recipes are basically scripts written in DSL to express the target state of a system [71]. Chef manages so called nodes. A node is an element of enterprise infrastructure, such as a server which can be physical, virtual, in the cloud, or even a container instance running a Chef client [72]. Chef provides APIs to manage resources on a machine in a declarative fashion. Chef recipes are typically declarative (resources which define a desired state) but can include imperative statements as well. Combining a Chef system together with cloud infrastructure automation framework makes it easy to deploy servers and applications to any physical, virtual, or cloud location. Using Chef, an organization can configure IT from the operating system up; applying system updates, modifying configuration files, restarting any necessary system services, applying and configuring middleware and applications.
Puppet
Puppet is an open source configuration and management tool implemented in Ruby [47] that allows expressing in a custom declarative language using a model-based approach [73]. Puppet enables deploying infrastructure changes to multiple nodes simultaneously. It functions the same way as a deployment manager, but instead of deploying applications, it deploys infrastructure changes. Puppet employs a declarative model with explicit dependency management. One of the key features of Puppet is reusability. Modules can then be reused on different machines with different operating systems. Moreover, modules can be combined into configuration stacks.
Juju
Juju is a cloud configuration, deployment and monitoring environment that deploy services across multiple cloud or physical servers and orchestrate those services [74]. Activities within a service deployed by Juju are orchestrated by a Juju charm, which is a deployable service or application component [75].
In summary, as applications evolve to function in the cloud, organizations must reconsider how they develop, deploy, and manage them. While cloud computing is heavily used to provide the underlying resource, our review shows that DevOps tools and artefacts can be used to configure and manage these resources. As a result, end-to-end deployment automation is efficiently enabled by employing DevOps approaches in cloud environments. But, cloud providers such as Amazon and cloud frameworks such as OpenStack provide cost-effective and fast ways to deploy and run applications. However, there is a large variety of deployment tools and techniques available [76]. They differ in various dimensions, most importantly in the metamodels behind the different approaches. Some use application stacks (e.g., AWS OpsWorks2 or Ubuntu Juju) or infrastructure, others use lists of scripts (e.g., Chef run) or even PaaS-centric application package descriptions such as Cloud Foundry manifests. This makes it challenging to combine different approaches and especially to orchestrate artefacts published by communities affiliated with the different tools, techniques, and providers. Nevertheless, these solutions are highly desirable because some communities share a lot of reusable artefacts such as portable scripts or container images as open-source software [77]. Prominent examples are Chef Cookbooks, Puppet modules, Juju charms, or Docker images. Adopting a configuration management tool implies a significant investment in time and/or money [78]. Nevertheless, before making such an investment, an informed choice based on objective criteria is the best insurance that an enterprise has picked the right tool for its environment, as the focus is on deploying predefined application stacks across several (virtual or physical) machines.