Cloud-Agnostic Platform-as-a-Service (PaaS) |
An approach to prevent vendor lock-in
| Journal | Industry 4.0 Science |
| Issue | Volume 41, 2025, Edition 1, Pages 68-73 |
| Bibliography | Share | Cite | Download |
Abstract
Keywords
Article
The increasing use of cloud computing resources is reflected in all service models (infrastructure (IaaS), platform (PaaS) and software (SaaS)) in recent years [1]. A closer examination of the various service models [2] allows for a more detailed discussion of the challenging issue of vendor lock-in.
The IaaS model offers a relatively good layer for provider abstraction or independence, as IaaS resources can be moved between different providers with little effort. With virtual machines, for instance, it does not matter which cloud provider they are hosted with as long as the underlying hypervisor is the same [3]. Of course, there may be other provider-dependent requirements such as costs or service level agreements, etc. However, this paper only focuses on the technical details, as other requirements are too specific for the respective use cases.
The PaaS level is similar to the IaaS level, as resources can also be operated here with relatively little effort from different providers. The focus of PaaS is on container technologies and their orchestration platforms. The most utilized platform for container orchestration and a quasi-standard for this is Kubernetes, which implements the Open Container Initiative (OCI) standard [4]. This standard guarantees that all containers adhering to it can be orchestrated in the same manner.
Like virtual machines at IaaS level, containers at PaaS level can be moved to different cloud providers as long as the underlying orchestration platform and the containers implement the respective OCI standards [4]. As almost all cloud providers offer a so-called managed Kubernetes platform, a change of cloud provider seems possible, at least from a technological perspective.
We do not consider the SaaS level at this point, as the services provided here appear to be too heterogeneous and corresponding cross-provider standards neither exist yet nor will they be developed in the foreseeable future. This is due to the aforementioned heterogeneity of the services and the opportunity for cloud providers to differentiate themselves on the market in the SaaS level.
The general question we are now addressing regarding a cloud-agnostic platform is:
Is it technically feasible to overcome the vendor lock-in with a cloud abstraction platform, and can this be automated?
Architecture design: Key considerations connected to the cloud
Before we look at technical architecture, i.e. the technical implementation of our platform, we present two possible business-driven architectures as examples for how services from different clouds can be used in a provider-independent manner. These are either the so-called redundant or the composite type of container usage [5].
In a redundant setup, the same services (for example containers) from different cloud providers are used to switch from one to another functioning service in the event of a failure. In a composite setup, on the other hand, various services from different cloud providers are combined to form a larger application.
In the context of cloud computing, such solutions are regarded as so-called “multicloud approaches”, in which more than one cloud provider is used either simultaneously (combined) or as a fallback or backup option (redundant).
Specific use cases for such architectures can be found as examples for a cloud-based (also at PaaS level), scalable smart city scenario with many networked road users, efficient traffic distribution and planning in an earlier publication by the author [6].
Regarding the topic of Industry 4.0, [7, 8, 9] and [10] provide a comprehensive overview of other possible use cases and implementations. In this publication, it is worth mentioning that PaaS does not refer to the service models according to NIST [2], but to the other, quite common abbreviation in the field of Industry 4.0: Product-as-a-Service.
On a more fundamental level, [11] offers an in-depth overview of the three-cloud service models and provides further information on what should generally be considered in cloud-based architectures.
Based on this general architecture and the other related work, we now take a more detailed look at the cloud-agnostic abstraction layer that we have developed with a focus on the PaaS level.
Cloud diagnostics: the technical implementation
The platform outlined here represents an abstraction layer based on various provider-specific Infrastructure-as-Code (IaC) implementations.
These provider-specific IaC implementations later instantiate the services provided by the respective cloud providers.
The required services (i.e. containers) can be specified and defined via a web application interface. The service definition determines the specific service instances, i.e. their number, how they are to be scaled, their degree of parallelization and other requirements. The service specification includes which services are to be operated by which cloud provider. The service definition and specification therefore include all the information required to be provisioned with the cloud provider.
As a preliminary outlook, it should be noted at this point that we deliberately use the term “service” here, as we are also looking at the SaaS level in further research work and aim to achieve a certain degree of provider independence here too.
However, it is not foreseeable at this stage whether and how this can be achieved at the SaaS level.
For this service creation and instantiation, we use OpenTofu [12] (an open-source fork of HashiCorp’s Terraform) as an IaC tool, as it supports an extensive set of services as well as all major cloud providers (Google, Amazon and Microsoft).
In summary, we model our application, which consists of several different services from different cloud providers, in a web application and automate the creation and instantiation of these services at the respective cloud provider.
Challenges and solutions
Service integration
The first challenge we are addressing here relates to the integration of various services. This concerns both architectures: the redundant and the composite. In the redundant form, an integration layer must be created that allows failing services to be detected and to switch to a replacement service (from another cloud provider) in the event of a failure. In the composite architecture, it is necessary for the various services to work together, i.e. to exchange data, which also requires integration between the services.
The challenge is to either control this via a central integration solution (known as orchestration) or to use the possibility that the respective services themselves are responsible for communicating with each other (known as choreography). This must be considered when implementing the logic for the services. An orchestration solution is offered, as this is exactly what is already being used with Kubernetes as an orchestration platform. However, what initially seems obvious can also be called into question due to the high complexity of this orchestrator.
Monitoring
Another challenge is the monitoring of services. In the context of this work, we subsume the topics of logging and monitoring under monitoring. Both topics are extremely complex, especially in distributed architectures. The integration of different cloud providers further increases this complexity. Standardized logging is required for monitoring the services with controllable effort. We are currently not aware of any option for such standardized logging approaches.
When implementing various services, we have noticed that all major cloud providers offer JSON as a logging format, but the internal structure of these JSON log files (attributes, metrics, etc.) differs from provider to provider. This means that even if existing technologies and tools (i.e. Prometheus, Grafana, Splunk, etc.) unify logging at a technical level (to create a single source of truth), the standardization of functional logging remains a challenge. We aim to tackle this challenge in the future.
Security
Closely related to uniform logging is the overarching question concerning the general security of such distributed architectures. Here, too, the complexity is higher than in non-distributed systems [13]. The real challenge behind this, however, is the evaluation between effort and benefit in the context of distributed or non-distributed architectures. In terms of effort, automation platforms such as the one outlined here initially represent a technical solution to reduce effort.
Ultimately, however, the organizational effort remains, and this must be weighed up against the potential benefits. As mentioned at the beginning, the benefits include higher availability (especially in redundant architectures), as this minimizes potential downtimes. Regarding composite architectures, they also offer the possibility of combining applications from different services that function optimally on their own into an ideal (so-called best-of-breed) overall application.
On the other hand, there are more complex systems, especially when using composite services, which must be evaluated accordingly, particularly regarding security. Possible attack vectors (i.e. denial of service attacks) affect all providers that are part of the overall system, see “multicloud” above. Furthermore, the integration of multiple cloud providers leads to greater organizational effort, which is reflected in the definition and monitoring of service level agreements (SLAs) for multiple providers.
Performance
The last point we address in this paper relates to the performance of the overall application. In general, the performance of a distributed system is potentially worse than in a monolithic architecture [13]. After all, the distributed services (components) must communicate with each other via networks. However, this must be considered on a case-by-case basis.
On the one hand, it is questionable whether there is so much communication that it has a (noticeably) negative impact on performance. On the other hand, the services are operated by different cloud providers, which technically represents server-to-server communication that should have sufficient bandwidth for many cases. However, as mentioned above, this must be checked and evaluated on a case-by-case basis.
Cloud abstraction platform can be implemented at the PaaS level
Circling back to the question posed at the beginning regarding the technical feasibility of a cloud abstraction platform at the PaaS level, it can be assessed as technologically feasible and automatable. However, “technically feasible” in this context must be understood as service creation, instantiation and decommissioning. The above-mentioned challenges regarding logging (both technical and functional), security and performance could not be examined in more detail in the context of this work.
However, the challenges relating to logging can be regarded as technically feasible—with the restriction that no automatic solution appears suitable for this purpose to date. This is due to the different metrics, attributes etc. for both technical and functional logging. A dedicated implementation of logging, which combines the different log files technically and professionally at a central location for efficient monitoring, is only hindered by the effort required.
We consider the second major challenge for a cloud abstraction platform to be the realization of such a platform at the SaaS level. As briefly outlined above, the heterogeneity of the services is even greater here than at PaaS and IaaS levels. This means that the selection of suitable services, the identification of alternative services across providers and their integration with each other involve an even higher level of complexity that needs to be overcome, if this is possible at all.
Bibliography
[1] Statista: Market Share. Public Cloud: Market Data & Analysis. URL: https://de.statista.com/statistik/studie/id/85672/dokument/public-cloud-report, accessed 17.11.2024.[2] Mell, P.; Grance, T.: The NIST Definition of Cloud Computing. URL: https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf, accessed 17.11.2024.
[3] Tanenbaum, A.; Maarten v. S.: Distributed Systems Principles and Paradigms, 4th edition. Twente, NL 2023.
[4] Kelsey, H.; Burns, B.: Kubernetes eine kompakte Einführung, 1st edition. Heidelberg 2018.
[5] Office of Information Integrity and Access: Multi-Cloud and Hybrid Cloud Guide. URL: https://www.cio.gov/assets/resources/Multi-Cloud%20and%20Hybrid%20Cloud%20Guide_v4_Final.pdf, accessed 17.11.2024
[6] Kohler J.; Specht T.: Towards a Secure, Distributed, and Reliable Cloud-Based Reference Architecture for Big Data in Smart Cities. In: Tamane S.; Dey N. (Ed.): Handbook of Research on Big Data Analytics for Smart and Connected Cities. Kolkata, IN 2018.
[7] Hidalgo-Crespo, J.; Riel, A. et al: An exploratory study for product-as-a-service (PaaS) offers development for electrical and electronic equipment. In: Procedia CIRP 122 (2024), pp. 521-526.
[8] Pivoto, D.; Almeida, L. et al: Cyber-physical systems architectures for industrial internet of things applications in Industry 4.0: A literature review. Journal of Manufacturing Systems 58 (2021), pp. 176-192.
[9] Bello, S.; Oyedele, L. et al: Cloud Computing in construction industry: Use cases, benefits and challenges. In: Automation in Construction 122 (2021), pp. 594-612.
[10] Baudouin, D.; Nejib, M. et al: The challenges, approaches, and used techniques of CPS for manufacturing in Industry 4.0: a literature review. In: The International Journal of Advanced Manufacturing Technology 1 (2024), pp. 2395-2412.
[11] Kavis, M.: Architecting the Cloud. 1st ed. New Jersey, NJ 2014.
[12] OpenTofu website: The Open Source Infrastructure as Code Tool. URL: https://opentofu.org, accessed 17.11.2024.
[13] Newman, S.: Monolith to Microservices: Evolutionary Patterns to Transform your Monolith, 1st edition. Boston, MA 2019.
Potentials: Services
You might also be interested in
