My Master’s Thesis in computer science, written at Technical University of Munich .
Abstract
Cloud computing enables companies to quickly build scalable distributed systems without large initial capital expenses. Cloud service providers offer computing resources on-demand with a pay-as-you-go pricing strategy. Those resources can be used in a broad range of different fields, from factory automation and monitoring to complex shopping websites.
Some of the cloud services are considered “serverless”, meaning the underlying infrastructure is hidden from the user and managed by the cloud platform. Those services are typically unique to their cloud platform and require platform-specific knowledge and configuration. However, limiting an application deployment to only one cloud platform has various disadvantages, such as vendor lock-in.
There is no well-established universal standard for describing a cloud architecture that uses serverless services and can be deployed to multiple cloud platforms. The offerings of different cloud platforms often contain services that are similar in function but vastly different in usage and configuration, which is especially true with serverless products. This abstraction barrier is the reason why developing the same application for different platforms is expensive and time-consuming.
We propose a solution to this problem by providing a way to describe high-level cloud architectures in a generic, platform-independent way. Furthermore, a software tool that translates this generic architecture into platform-specific architectures is presented. These contributions enable developers to build applications that target multiple cloud platforms more efficiently.
Conclusion
Serverless computing is popular because it simplifies complex cloud deployments and reduces the management overhead. However, challenges such as cloud interoperability and the missing high-level abstractions that arise in multi-cloud environments are yet to be solved.
In Chapter 3, we presented several solutions that suggest abstraction layers to provide an environment for platform-independent applications. OCCI is a standardized interface for cloud management tasks. OASIS TOSCA introduces its own platform-independent application format that can be deployed on compliant platforms. Another approach uses the Kubernetes orchestration software tool running on different cloud platforms to provide a homogeneous cloud environment. The VSP schedules FaaS functions on different CSPs depending on their workload. Apache Libcloud provides a high-level Python interface to provision cloud resources. mOSAIC implements a broker-based approach to provide access to multiple CSPs through one interface. Similarly, Cloud4SOA uses a multi-layered architecture to offer a unified API across different PaaS platforms.
However, those solutions either do not provide an abstraction for serverless services or still require some platform-specific knowledge. Our approach to implementing proper architectures for cloud-agnostic applications is based on Terraform. While Terraform itself does not solve the abstraction challenges, it provides a homogenized API across different CSPs. We present a layer on top of Terraform, implemented as a software tool that uses templates to translate our custom generic architecture format, GAML, into Terraform HCL configurations.
First, Terraform configurations for a simple web application running on three cloud platforms are developed as presented in Section 4.2. This is used as a basis to find the lowest common denominator amongst the architectures. With the similarities derived, a language to model generic architectures is defined as shown in Section 5.1. The transpiler, as presented in Chapter 5, takes the generic architecture specified in GAML, as well as a collection of component templates as input, and transpiles them to one Terraform deployment per platform.
The evaluation in Chapter 7 showed that the transpiling process does work with our exemplary web application. We further showed that it significantly decreases the development time when a template library is already available.
There is a lot of potential for improving the transpiler and architecture language as presented in Chapter 8. We suggested working on the architecture language to implement inputs, modules, and labels. The transpiler could be further improved by implementing an automatic validation of the architecture file and the resulting Terraform configurations. Furthermore, the Terraform CLI could be leveraged to turn the transpiler into a tool that manages the whole multi-cloud deployment lifecycle. A user interface could further improve the developer experience by enabling easy management of the deployed resources.
The Multy project uses a similar approach as the one presented in this thesis to build cloud-agnostic applications. The Terraform-based language model, together with the Multy transpiler allows using a well-known language model and toolset to specify generic architectures. However, it requires a good understanding of the project as well as programming skills to modify the transpiling behavior and add new components. While a certain level of abstraction is given, it is not possible to use high-level or custom abstractions. In conclusion, Multy shows to be a very promising approach because they simplify the deployment process by leveraging Terraform functionality directly, as explained in Chapter 6.
The core contribution of our work is the transpiler that can be used to translate high-level architecture definitions written in a human-readable text format into platform-specific Terraform configurations. The evaluation showed a real use case by leveraging the transpiler to deploy a multi-cloud web application. While there is a lot of room for expanding and improving our solution, it is ready to be used to deploy cloud-agnostic applications in multi-cloud scenarios.
Download Paper Download Slides Online University Library GitHub: Multiform GitHub: Serverless Web App