ANALISIS DE LA CATEGORIA DE LA EDUCACION IGNACIANA

Several arguments have been made to explain the causes of vendor lock-in in cloud computing. Some authors argue that the lack of standards is responsible for cloud vendor lock-in [61, 186, 192]. Others attribute vendor lock-in to the heterogeneity of the cloud regarding service models [191], functions [83, 101, 176], environments [13, 192], billing strategies [6, 207], and architecture [189, 208]. However, as we explain in the next paragraphs, the use of different APIs, semantics, and technologies by cloud platforms and providers has been widely accepted as the main cause of cloud vendor lock-in.

APIs play an important role for the programmatic management of cloud services [77]. Therefore, they have a strong influence on vendor lock-in [138, 197]. Even though some cloud platforms offer APIs based on open standards [197], such as WSDL, or REST, they lack a single interface [61, 229]. The lack of a single interface is further complicated by property rights of APIs that prevent cloud providers to adopt homogeneous call formats [4, 59]. The use of different APIs prevents a smooth application migration to

2.2 Vendor Lock-in

another platform [73, 199, 260]. API incompatibility arises even between supposedly compatible platforms. Flores, Srirama & Paniagua [85] report incompatibilities in their experience on creating a mobile application to access storage services on both Amazon S3 and Eucalyptus, although these platforms claim API compatibility. Similarly, Souza et al. [221] demonstrated incompatibilities between the Amazon Web Services (AWS) and the OpenStack, Eucalyptus and OpenNebula APIs for computing service. Hill & Humphrey [108] observe that these differences in APIs are not only the result of syntax and semantics differences, but also a result of the different service models and services provided [167].

Loutas, Kamateri & Tarabanis [149] conclude that API compatibility is not enough to enable data migration, which also requires semantic interoperability. Semantics refers to the way in which a cloud platform describes characteristics and components of its services [147, 164] (e.g., security mechanism, resources, geographical location), mainly including the entity model [149] and entity names [152]. Analysing semantic differences among storage platforms, Kotecha, Bhise & Chaudhary [135] conclude that “Migration of an application to another cloud requires an application to be re-written and database to be restructured according to the newly identified cloud service provider’s datastore.” Loutas et al. [147] explain that this problem is not limited to data stores, but it is present in IaaS, PaaS, and SaaS. Hill & Humphrey [108] note that semantic differences force the cloud user to choose one specific platform. The same position is advocated by Kotecha, Bhise & Chaudhary [135], Nelson & Uma [164], and Fortis, Munteanu & Negru [86].

Finally, cloud providers use different technologies to internally manage their re- sources and support their services, including hypervisors and VMs, web containers, and cloud platforms. These technologies also significantly contribute to vendor lock-in [157, 235, 260]. Rochwerger et al. [196] observe that cloud technologies were not de- veloped to be interoperable. Galán et al. [92] emphasise the same idea highlighting the differences between the Amazon EC2 and GoGrid VM image format. The use of platform-specific technology is a relevant aspect of vendor lock-in [18, 86] that is more evident in the packaging technology used by IaaS providers [73, 219]. Different technolo- gies were also a critical issue to enable interoperability in grid computing [119, 249, 259], an area related to cloud. The differences in technologies also hinder interaction between different paradigms, such as grid and cloud [157].

Additionally, current development practices and technologies used for application development may also contribute to the vendor lock-in. Common hindering features are an application design based on proprietary technologies [191], and a monolithic

application architecture [106]. Of course, it would be impossible to develop an appli- cation without any commitment to a particular technology, such as a programming language. However, the major issue is the development without paying attention to important concerns, such as portability. Migration cases reported in [23, 216, 230] re- veal the need for changes to adapt a legacy system to a new technology. In an extreme case, Lancia, Puccinelli & Lombardi [136] report the need for entirely re-developing a Cobol/mainframe-based system to take advantage of a new technology. Similar prob- lems occur in grid computing since applications are hard-coded to use a specific grid middleware [157, 237, 249].

To illustrate this problem in application development, take into consideration the case of the PetStore application1_{– a reference application developed to demonstrate the}

features of JEE technology. In this particular case, the application is entirely developed to use a specific technology, limiting its deployment on some cloud platforms. However, there is a more critical aspect: although the application uses the traditional three- layered application architecture, the hard-coding of mechanisms used to ensure data persistence and other common functionality makes difficult and expensive any attempt to migrate it to a PaaS provider, for instance. The problem affects not only legacy applications, but also applications specifically developed for the cloud (cloud-native) [191] and applications migrated to the cloud (cloud-enabled) [15]. In [263], Zhou reports the need for re-designing the application architecture to comply with a specific cloud platform. A similar experience was reported in [232] and [52]. These experiences are evidence that even applications recently migrated to the cloud do not consider flexibility, portability, and interoperability.

On the other hand, van der Linden [238] emphasises the ease of migrating an ap- plication designed to be highly portable. Based on their experience with migrating an application to a cloud platform, Chauhan & Babar [52] conclude that applications based on stateless RESTful components are easier to migrate than applications based on other technologies. The authors also highlight the simplicity of migrating persistence components when the database is used only to store data instead of both data and busi- ness logic. Finally, the authors advocate, “it is more convenient and cost effective to evolve an SOA based system to SaaS targeting IaaS clouds as compared to PaaS clouds for which components need to be re-factored according to the API provided by the PaaS provider.” In addition, Andrikopoulos et al. [15] observe that the migration cost is associated to the type of migrated components.

2.2 Vendor Lock-in