Migrating monolithic applications to function as a service

Function as a service (FaaS) promises low operating costs, reduced complexity, and good application performance. However, it is still an open question how to migrate monolithic applications to FaaS. In this paper, we present a guideline for software designers to split monolithic applications into smaller functions that can be executed in a FaaS environment. This enables independent scaling of individual parts of the application. Our approach consists of three steps: We first identify the main tasks (and their subtasks) of the application to split. Then, we define the program flow to be able to tell which application tasks can be converted to functions and how they interact with each other. In the final step, we specify actual functions and possibly merge those that are too small and which would produce too much communication overhead or maintenance effort. Compared to existing work, our approach applies to applications of any size and results in functions that are small enough — but not too small — for efficient execution in a FaaS environment. We evaluate the usefulness of our approach by applying it to a real‐world application for the storage of geospatial data. We describe the experiences made and finish the paper with a discussion, conclusions, and ideas for future work

Practical aspects of FaaS applications' migration

With the huge variety of available FaaS platforms in cloud and self-hosted environments the idea of migrating function applications from one provider to another is becoming a important consideration. This work investigates the challenges developers encounter when manually migrating applications between Amazon Web Services, Microsoft Azure and IBM Cloud regarding the efforts needed to migrate the functions and the services. This work also proposes a simple approach to reduce the coupling between the function application and the cloud provider by externalizing the business logic into a serparate, completely vendor independant, package. We see that this approach reduces the efforts needed to migrate the source code to another provider but it does not reduce the effort of migrating the functions configuration and services. We see that the efforts for migration are not only affected by the migration of the source code but also by the migration of the services, especially in self-hosted environments. There developers also have to find a proper substitution of the service for their use-case.Bei der Vielzahl der verfügbaren FaaS-Plattformen in Cloud- und selbst gehosteten Umgebungen wird die Idee der Migration von Funktionsanwendungen von einem Anbieter zum anderen immer wichtiger. Diese Arbeit untersucht die Herausforderungen, denen Entwickler bei der manuellen Migration von Anwendungen zwischen Amazon Web Services, Microsoft Azure und IBM Cloud hinsichtlich des Aufwands für die Migration der Funktionen und Dienste begegnen. Diese Arbeit schlägt auch einen einfachen Ansatz vor, um die Kopplung zwischen der Funktionsanwendung und dem Cloud-Provider zu reduzieren, indem die Geschäftslogik in ein separates, völlig herstellerunabhängiges Paket ausgelagert wird. Wir sehen, dass dieser Ansatz den Aufwand für die Migration des Quellcodes zu einem anderen Anbieter reduziert, aber nicht den Aufwand für die Migration der Funktionskonfiguration und der Dienste. Wir sehen, dass die Bemühungen um die Migration nicht nur von der Quellcode-Migration, sondern auch von der Migration der Dienste, insbesondere in selbst gehosteten Umgebungen, beeinflusst werden. Dort müssen Entwickler auch einen geeigneten Ersatz für den Dienst in ihren Anwendungsfall finden