Impact of Vendor Lock-in for Cloud Users and Providers

Vendor lock-in affects both cloud user and cloud provider, although in different ways. For the cloud user, although cloud providers advertise service availabilities very close to 100% [83], they can suffer outages [202] – and the literature is full of cases1. The (temporary) unavailability of a cloud provider’s services gives rise to a cascading effect, affecting cloud users and their customers (application users), and potentially resulting in business losses for cloud users2,3,4.

Secondly, the cloud market is still maturing; in this process some cloud providers might go out of business [97]. Gonidis, Paraskakis & Kourtesis [97] note the case of Coghead, a company which offered cloud-based services between 2006 and 2009, and suddenly announced its closure in February 2009. In a similar case reported by Armbust et al. [22], the storage service The Linkup went out of business after losing 45% of their customer data, leaving its 20,000 users in a tricky situation. Finally, another risk to the cloud user is the violation of Service Level Agreements (SLA) [202], causing problems, such as data loss [22].

Another effect of vendor lock-in on the cloud user is the increase in the cost asso- ciated with resource migration [48]. Here, costs refer not only to money, but also to time and effort. From this perspective, migrating a resource between providers does not differ from resource migration in more established computing paradigms. Nfila, Dintwe & Rao [166] and Wilson [254] report two processes of migrating a library system to a new one (before the cloud era) that took one, and one and half years, respectively. These experiences can be compared with migrating between SaaS providers since the application is entirely replaced, and only the data is migrated [97]. Taking this long to complete a migration would be prohibitive in the case of a provider going out of business. Even when time is not a problem, the effort to migrate can exceed the expectations. Satzger et al. [202] analyse, “once an application has been developed based on one par- ticular provider’s cloud services and using its specific API, that application is bound to that provider; deploying it on another cloud would usually require completely redesign- ing and rewriting it.” In addition, migration processes are not free from unexpected problems. Even with a well-structured process and an experienced team, Teppe [230]

1 http://www.crn.com/slide-shows/cloud/240153188/6-devastating-cloud-outages-over-the-last-6- months.htm 2_{http://www.computerworld.com/article/2495766/social-business/} google-drive-hit-by-three-outages-this-week.html 3_{http://www.reuters.com/article/net-us-companies-netflix-idUSBRE8BO06H20121226} 4 http://www.bloomberg.com/news/articles/2012-12-31/amazon-apologizes-for-christmas-eve- disruption-affecting-netflix

reports problems during code migration. Both time and effort impact on the financial cost [6, 103].

Finally, although the cloud user is still responsible for their resources, the IT control is partially transferred to the cloud provider [109], which introduces challenges [105], such as integration and resource optimisation [66]. Without the flexibility to switch provider, the cloud user must agree with business, technological, and socio-technical decisions taken by a third-party. Another critical aspect of such shared control refers to the data security, privacy and trust [91]. Furthermore, as the control is partially transferred to the cloud provider, responsibilities for the service reliability are also shared. Armbrust et al. [22] cite the case of The Linkup (cloud user) and Nirvanix (cloud provider), in which a failure in the cloud user service led to a dispute between the cloud user and the provider to determine the responsibility for the problem. Since new cloud services have been built on the already complex infrastructure of cloud providers (e.g., Dropbox, Netflix, and Foursquare on Amazon Web Services), control and division of responsibility tend to become critical concerns for large companies.

From an economic perspective, vendor lock-in may bring benefits to the cloud provider [22]. Firstly, vendor lock-in retains users [184, 192], ensuring a permanent customer base and enabling the cloud provider to predict both the usage of resources and the revenue. Secondly, the cloud provider has some flexibility to take decisions, such as raising prices1_{. Even though the flexibility to change the price is somewhat}

limited (otherwise cloud users could abandon the provider despite the migration costs), the cloud market is different from public utilities, in which governments can control, pressure, or, at least, question companies about their price increases. In the cloud mar- ket, big customers can pressure cloud providers [184]; however, the flexibility to decide, and any concessions that may be available for some of them lies in the cloud provider’s hands.

Finally, exclusive services (i.e., heterogeneous and provider-specific) may be used to attract new customers [184]. For example, Amazon maintains a page dedicated to report success cases of customers that use their exclusive services2. Since the problems between user and provider are rarely disclosed, new customers might be attracted by the promised advantage of a service.

On the other hand, cloud providers can also suffer because of their heterogeneity – one of the causes of vendor lock-in. In [2], the authors highlight the case of hybrid clouds, in which heterogeneity is a problem. In a hybrid cloud, multiple clouds work together

1

http://bits.blogs.nytimes.com/2012/10/09/open-vs-closed-the-cloud-wars/?_r=0

2.2 Vendor Lock-in

coordinated by a broker. To realise such an integration, the authors identified several requirements, such as common formats for VMs and APIs. Additionally, in [3], the authors present several scenarios in which seamless integration among cloud providers could be beneficial, such as bursting, and availability in case of disaster recovery. In a bursting scenario, a cloud provider can temporarily transfer resources to a cloud partner in order to deal with an unexpected workload increase [155]. Extra requests for resources from cloud users are redirected to the partner, balancing the workload and ensuring SLAs.