Migrating from Microservices to Serverless An IoT Platform Case Study

2025-05-02 0 0 676.59KB 7 页 10玖币

侵权投诉

Migrating from Microservices to Serverless: An IoT Platform

Case Study

Mohak Chadha, Victor Pacyna, Anshul Jindal, Jianfeng Gu, Michael Gerndt

mohak.chadha@tum.de,victor.pacyna@tum.de,anshul.jindal@tum.de,jianfeng.gu@tum.de,gerndt@in.tum.de

Chair of Computer Architecture and Parallel Systems

Technische Universität München

Garching (near Munich), Germany

ABSTRACT

Microservice architecture is the common choice for developing

cloud applications these days since each individual microservice

can be independently modiﬁed, replaced, and scaled. As a result,

application development and operating cloud infrastructure were

bundled together into what is now commonly called DevOps. How-

ever, with the increasing popularity of the serverless computing

paradigm and its several advantages such as no infrastructure man-

agement, a

pay-per-use

billing policy, and on-demand ﬁne-grained

autoscaling, there is a growing interest in utilizing FaaS and server-

less CaaS technologies for refactoring microservices-based applica-

tions. Towards this, we migrate a complex IoT platform application

onto OpenWhisk (OW) and Google Cloud Run (GCR). We com-

prehensively evaluate the performance of the different deployment

strategies, i.e., Google Kubernetes Engine (GKE)-Standard, OW,

and GCR for the IoT platform using different load testing scenar-

ios. Results from our experiments show that while GKE standard

performs best for most scenarios, GCR is always cheaper wrt costs.

CCS CONCEPTS

•Computer systems organization →Cloud computing.

KEYWORDS

Microservices, Serverless, Function-as-a-Service, FaaS, Container-

as-a-Service, CaaS, Performance Analysis

ACM Reference Format:

Mohak Chadha, Victor Pacyna, Anshul Jindal, Jianfeng Gu, Michael Gerndt.

2022. Migrating from Microservices to Serverless: An IoT Platform Case

Study. In Eighth International Workshop on Serverless Computing (WoSC

’22), November 7, 2022, Quebec, QC, Canada. ACM, New York, NY, USA,

7pages. https://doi.org/10.1145/3565382.3565881

1 INTRODUCTION

Cloud computing is the corner-stone of modern day corporate and

consumer IT. For companies it provides a multitude of advantages

such as outsourcing of costly infrastructure, scalability, elasticity,

and fault tolerance. To this end, the architectures of cloud native

Permission to make digital or hard copies of all or part of this work for personal or

classroom use is granted without fee provided that copies are not made or distributed

for proﬁt or commercial advantage and that copies bear this notice and the full citation

on the ﬁrst page. Copyrights for components of this work owned by others than ACM

must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,

to post on servers or to redistribute to lists, requires prior speciﬁc permission and/or a

fee. Request permissions from permissions@acm.org.

WoSC ’22, November 7, 2022, Quebec, QC, Canada

ACM ISBN 978-1-4503-9927-2/22/11. . . $15.00

https://doi.org/10.1145/3565382.3565881

applications have adjusted to the ever increasing demand of migra-

tion to the cloud. Most prominent among them is the microservices

architecture that displaced the prevalent monolithic architecture [

This architecture enables the development of applications as a suite

of small independent services communicating with each other via

well-deﬁned interfaces. A microservices-based architecture provides

several advantages such as better modularization, enhanced isola-

tion, and easier maintainability [

]. Moreover, each service can

be scaled up or down on-demand, or be deployed in multiple avail-

ability zones to eliminate single point of failures. However, this has

led to an increase in complexity of deployment and provisioning of

services, resulting in developers having to develop their application

as well as take care of its operation, i.e., DevOps [

]. To this end,

an emerging computing paradigm called serveless computing that

abstracts infrastructure management away from the user has gained

popularity and widespread adoption in various application domains

such as edge computing [16,24,27] and machine learning [4,13].

Function-as-a-Service (FaaS) and serverless Container-as-a-Service

(CaaS) are key enablers of serverless computing that allow develop-

ers to focus on the application logic, while responsibilities such as

infrastructure management, resource provisioning, and scaling are

handled by the cloud service providers. In FaaS or serverless CaaS,

the developer implements ﬁne-grained functions that are executed

in response to external triggers such as HTTP requests and deploys

them into a FaaS platform such as Apache OpenWhisk (OW) [

] or

a serverless CaaS platform such as Google Cloud Run (GCR) [

On invocation, the platform creates an execution environment, i.e.,

function instance which provides a secure and isolated language-

speciﬁc runtime environment for the function. These functions are

generally launched on the platform’s traditional IaaS virtual machine

offerings [

]. Serverless computing offers several advantages

such as

scale-to-zero

for idle functions, a

pay-per-use

billing

policy, and rapid ﬁne-grained automatic scaling on a burst of func-

tion invocation requests. However, serverless functions are stateless

and any application state needs to be maintained through external

transactions with a database or a data store.

Both architectures, i.e., either microservices or serverless have

their advantages and disadvantages and the decision to adopt one

over the other depends on several factors. In this paper, we investigate

these two competing software architectures for an IoT platform

application. Towards this, our key contributions are:

•

We migrate a microservices-based IoT platform application

developed by us onto OW and GCR.

•

We comprehensively evaluate the performance of the IoT

platform across different deployment strategies, i.e, Google

arXiv:2210.04212v1 [cs.DC] 9 Oct 2022

WoSC ’22, November 7, 2022, ebec, QC, Canada Chadha et al.

Kubernetes Engine (GKE) standard, OW, and GCR with dif-

ferent load testing scenarios wrt performance and cost.

•

We highlight the important lessons learned from our migra-

tion. All code artifacts related to this work are available at1.

The rest of the paper is structured as follows. §2describes the IoT

platform application in detail. In §3, our migration methodology is

described. §4presents our experimental results. In §5, prior work on

migrating microservices onto FaaS platforms is described. Finally,

§6concludes the paper and presents an outlook.

2 IOT PLATFORM

We designed and developed the IoT platform to enable numerous

IoT applications such as room monitoring and occupancy estima-

tion. The platform provides a scalable infrastructure for managing

multiple users, devices, and sensors. Furthermore, it provides per-

sistent storage for sensor data that is received via

HTTP

WebSocket

MQTT

protocols and supports secure communication with end de-

vices through

JWT

tokens. Finally, it supports visualization of data in

various formats to enable smart data analytics.

2.1 Data Model

The IoT platform’s data model consists of four main entities, i.e.,

users,devices,sensors, and consumers. Users are the main com-

ponents responsible for interacting with the IoT platform. Their

attributes include

name

, credentials consisting of a

username

and a

password

, and a

role

, which is either admin or user. Users can have

multiple devices associated with their account and each device can

have multiple sensors associated with it. Consumers are responsible

for retrieving sensor data from the IoT platform. A user can have

multiple consumers, that each allow access to a self-administered set

of the user’s sensors. Prior to retrieving data, the user has to grant

a consumer access to one or multiple sensors (§2.2). The relation-

ship between the different entities and their attributes is shown in

Figure 1.

2.2 System Design

The IoT platform consists of several independent microservices

that interact with each other to provide the different functionalities

described in §2and §2.1. The different components of the platform

are shown in Figure 2.

At the center of the platform is the

IoTCore

which is implemented

as a web application with a

React

based front-end and a

Node.js

based backend. It enables users to manage devices, sensors, and

authentication/authorization tokens for secure communications with

the end devices. All data related to the users, devices, and sensors

is stored in the relational database management system

MariaDB

The end devices can send data to the platform using three differ-

ent gateways, i.e.,

HTTP

WebSocket

MQTT

. The main purpose of

the gateway is to check the sensor’s authentication token and ver-

ify its data schema. Currently our platform supports sending and

storing data in various formats such as string, integers, or as ﬂoat-

ing point values. Moreover, it supports complex data types such as

tuples and arrays. Following a successful veriﬁcation by the gate-

way, the received sensor data is forwarded to

Kafka

. Kafka is a

1https://github.com/CAPS-Cloud/IoT-Platform-Migration

Figure 1: Data Model of the IoT platform.

scalable streaming platform and incorporates a publish-subscribe

pattern. One or multiple producers publish data records to a topic,

the core abstraction of Kafka that is used to store and process data

record streams. A single topic can then be subscribed by zero, one

or multiple consumers (subscribers). Each sensor is matched to a

separate Kafka topic in our current implementation. As a result, the

received sensor data is logged under its own Kafka topic. Further-

more, for scalability purposes, each Kafka topic has a corresponding

consumer called

Kafka-connect

for consuming the data from the

Kafka topic assigned to it and saving it into

Elasticsearch

(ES).

Kafka-connect

enables the streaming of data between Kafka and

other systems such as databases and cloud services. In the IoT plat-

form it utilizes the ES service sink connector to write data from

a topic in Kafka to an index in ES. ES is an open-source scalable

search and analytics engine based on Apache Lucene. After receiv-

ing the sensor data in ES it is parsed, normalized and enriched before

being indexed. An ES index stores data in a data structure called

inverted index that allows near real-time searches. All sensor data

is persistently stored in ES. In our current implementation, one ES

index is created for each sensor. The stored sensor data can be vi-

sualized using Kibana or can be retrieved by creating consumers

(§2.1).

2.3 Interacting with the IoT Platform

The IoT platform provides several RESTful API endpoints that

enable users and consumers to interact with the platform and per-

form create, read, update, and delete (CRUD) operations on the

devices and the sensors. In a typical usecase, an admin user of the

IoT platform creates new users by sending a post request to the

Users-Add

endpoint along with their attributes (§2.1). On receiving

the request, new users are created with their attributes which are

stored in MariaDB. Following this, users with an account on the IoT

platform can login to the platform by sending a post request to the

Users-Signin

endpoint containing their username and password as

parameters. Internally these credentials are compared to the values

stored in MariaDB. After successful veriﬁcation, a

JWT

is returned

as the response which encodes the user’s id. Following this, users

can add their devices to the platform by sending a post request to

the

Devices-Add

endpoint along with its attributes (§2.1) and the

returned

JWT

in the authorization header. On successful addition to

the database the added device id is returned as a response to the user.

After this, users can create sensors for their devices by sending a

post request to the

Sensors-Add

endpoint along with its attributes,

the returned

JWT

, and the device id. On receiving the post request,

the platform creates a Kafka topic and an ES index for the sensor.

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

MigratingfromMicroservicestoServerless:AnIoTPlatformCaseStudyMohakChadha,VictorPacyna,AnshulJindal,JianfengGu,MichaelGerndtmohak.chadha@tum.de,victor.pacyna@tum.de,anshul.jindal@tum.de,jianfeng.gu@tum.de,gerndt@in.tum.deChairofComputerArchitectureandParallelSystemsTechnischeUniversitätMünchenGarchin...

展开>> 收起<<

Migrating from Microservices to Serverless An IoT Platform Case Study.pdf

共7页,预览2页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Migrating from Microservices to Serverless An IoT Platform Case Study

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: