DOCSLIB.ORG

Report Benchmarking the Performance of Recent Serverless Technologies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Report Benchmarking the Performance of Recent Serverless Technologies Followup Seminars - Report Benchmarking the performance of recent serverless technologies Jose´ Donato∗, Marco Vieiray Departamento de Engenharia Informatica´ Universidade de Coimbra ∗[email protected], [email protected] Abstract—Web technologies are constantly evolving. Serverless per unit time [2]. We are also interested in up-time, i.e., the Computing is an ambitious web technology that has emerged percentage of time the system is up [2]. in recent years and has been the focus of several studies. It There are several studies that compare different serverless is ambitions because Serverless aims to replace the traditional architecture where a server is always running waiting for re- technologies [3], [4], [5] or the same serverless technology quests. However, its stateless approach and design characteristics deployed on different serverless providers [6]. We focus on re- raise some concerns that need to be studied and the primary cent technologies that were not considered yet but are already one is performance. In this paper we study several technologies gaining popularity. This benchmark currently supports three (both serverless and traditional) normally used to support web different technologies but can be easily extended to support applications. We propose a preliminary performance benchmark that allows comparing recent serverless technologies (such as (as we will see in the SectionII). The currently supported Netlify functions, Next.js API routes and Cloudflare Workers) technologies are Next.js API Routes [7], Netlify Functions [8] and traditional technologies (such as Express.js). Results show and Express.js [9] (we dive deep into the technologies used in that all technologies tested provide high up-time and the server- SectionII). less technologies do not fall behind the technologies based on We developed the same application using these three dif- traditional server architectures. Index Terms—Serverless Computing,Performance Benchmark ferent technologies and several scripts to assess them (more detail in SectionII). All the source code is available on github[10] and the application with the results is live on I. INTRODUCTION benchmarking.vercel.app/sa[11]. As for the results, regarding the tests performed we observed Serverless computing (also called Functions as a Service that the serverless technologies behave similarly to applica- or FaaS) has been a hot topic for the past few years as it tions that follow the traditional architecture. All technologies aims to replace the traditional servers that are the standard tested (both serverless and non-serverless) should be viable so- and world-wide used. Serverless proposes an alternative ap- lutions when the goal is to implement simple web Application proach regarding how applications run in the cloud: instead of Programming Interfaces (or APIs) with high up-time and that constantly running as tradition servers, serverless consists of may involve expensive computations (e.g., image processing). stateless functions that run on containers in the cloud and only The remainder of this document is structured as follows. wake up on demand, i.e., these containers only turn on when SectionII describes the performance benchmark and explains they are called. Since the containers are by default sleeping all its necessary phases. Section III presents the experiences (i.e., not running), serverless functions can be an efficient made and their results. SectionIV we discuss the results and alternative in terms of energy consumption (and consequently, compare the different technologies under study. SectionV cost). However, if they are by default asleep, before the request enumerates the limitations of this work and why they exist. is processed we need to wait until the containers turn on. This Finally, SectionVI concludes the work. In this section we process is called cold boot and it is the primary reason of also consider what could be added to this study in the future. serverless performance limitations. This study focus on assessing the performance of server- II. BENCHMARK DESCRIPTION less and non-serverless technologies. Therefore, we propose a simple performance benchmark that allows comparing Our approach is described in Figure1. Our benchmark alternative technologies that can be used to develop either is divided into in three different processes. Therefore, the serverless or traditional applications. remainder of this section is divided into three subsections. In We can define benchmark as “standard tools that allow each subsection we through the processes and the necessary evaluating and comparing different systems or components tools to implement them are explained. according to specific characteristics (performance, depend- The following list itemizes a brief description about each ability, security, etc)” [1]. For our benchmark we focus on benchmark process: performance and up-time. Therefore, we choose to perform • Application Development (represented with yellow in several throughput tests, i.e., the number of items processed the diagram): The first process of the benchmark. This for(let x = 0; x < w; x++) { Receives Outputs Analysis Results in Configurations CLI Results in CSV idx = (w * y + x) << 2 Tool JSON rgb[0] += matrix[idx] rgb[1] += matrix[idx + 1] Tests several applications rgb[2] += matrix[idx + 2] Web App to } visualize results } Produces Application Application Application Application Application return [Math.floor(rgb[0] / size), Math.floor( Development 1 2 n-1 n rgb[1] / size), Math.floor(rgb[2] / size)] } Fig. 1: Benchmark Architecture As we will see in Benchmark Campaign II-B, for more expensive workloads we submit bigger images. For the opposite effect, we use smaller images. This endpoint phase consists of the development of the several applica- expects POST requests with the image in the body and is tions that will be tested in the benchmark execution phase. normally located at /dominantColor. Alongside the In its subsection we explained what are the application dominant pixel, this endpoint returns the duration it took features and why we choose those features. Also, we to compute the pixel (which will be useful in Subsections describe the technologies we choose. II-B and II-C for collecting the metrics). • Benchmark Campaign (represented with orange in the For our tests, we consider three different sizes for of the diagram): Receives the configurations and is responsible same JPEG image: for testing each application while collecting the metrics. – One small image: 640x959 pixels. In its subsection we enumerate the configurations, the – One medium image: 1920x2878 pixels. metrics we collect and how command-line interface (CLI) – One large image: 2400x3598 pixels. we developed works. The campaign outputs the results in • Echo Endpoint: Simple endpoint that does not receive comma-separated values (CSV). anything and just returns a “Hello World” string. This • Result Analysis and Presentation (represented with endpoint expects GET requests and is normally located green in the diagram): This is the final process of our at /echo and its purpose is to assess the throughtput of assessment. To sort the results from the Benchmark Cam- each application. paign we developed a simple analysis tool that receives the results in CSV format, performs some analysis and As said in the introduction, we developed several applica- converts them into JavaScript Object Notation (JSON). tions and they are all open sourced in the github[10]. Finally, we can provide the JSON files to the web Each application has its own folder and a Dockerfile as- application we also implemented in order to display the sociated (i.e., a file that contains the information needed to results. build a Docker image [12]) to ease the process of running each application. We considered the following technologies to A. Application Development develop the applications under test: The focus of our assessment is performance. Therefore, we • Serverless - recent technologies that are used to support tried to collect a set of features that despite being simple web applications such as: allowed to evaluate the performance (primarily the throughput) – Next.JS API routes: “API routes provide a straight- of serverless and non-serverless functions. This resulted in two forward solution to build your API with Next.js” [7]. features: – Netlify functions: “Serverless functions built into • Dominant Color Endpoint: An endpoint that receives every Netlify account. No setup, servers, or ops a JPEG or PNG image and retrieves its dominant color, required” [8]. i.e., the color that appears more times in the image. We – Cloudflare Workers: “Simple FaaS on the edge of think this use case is representative because it involves Cloudflare CDN” [13]. Cloudflare workers was not expensive computations. The bigger the image, the more included in tests because this technology is not computations are needed. In code snippet1 is presented compatible with docker and when running locally the code we used to calculate the dominant color. The it crashed as soon as the tests started. snippet navigates through all the images pixels (repre- • Traditional - also recent technologies to support web sented by matrix) and calculates the color that appears applications: more times. – Express.js: “Node.js web application Listing 1: Compute image dominant color. Adapted from this framework” [9]. source code. As we will talk in SectionV, the deployment of such function dominantColor(w, h, matrix) { technologies is hard without paying some money. Therefore,
Load more

Recommended publications
  • Towards a Security-Aware Benchmarking Framework for Function-As-A-Service
    Towards a Security-Aware Benchmarking Framework for Function-as-a-Service Roland Pellegrini1, Igor Ivkic1 and Markus Tauber1 1University of Applied Sciences Burgenland, Eisenstadt, Austria {1610781022, igor.ivkic, markus.tauber}@fh-burgenland.at Keywords: Cloud Computing, Benchmarking, Cloud Security, Framework, Function-as-a-Service Abstract: In a world, where complexity increases on a daily basis the Function-as-a-Service (FaaS) cloud model seams to take countermeasures. In comparison to other cloud models, the fast evolving FaaS increasingly abstracts the underlying infrastructure and refocuses on the application logic. This trend brings huge benefits in application and performance but comes with difficulties for benchmarking cloud applications. In this position paper, we present an initial investigation of benchmarking FaaS in close to reality production systems. Furthermore, we outline the architectural design including the necessary benchmarking metrics. We also discuss the possibility of using the proposed framework for identifying security vulnerabilities. 1 INTRODUCTION illustrates the technical workflow between the components: Cloud computing, as defined by Mell and Grance (2011), is a model for enabling on-demand network access to a shared pool of configurable resources. Cloud vendors provide these resources in the service models Infrastructure as a Service (IaaS), Platform- as-a-Service (PaaS) and Software-as-a-Service (SaaS). Through virtualization, the IaaS service model provides computing resources (e.g.: servers, storage, network) to consumers so they can deploy Figure 1: FaaS architecture, based on Pientka (2017) and run software. In other words, the consumers do not control the infrastructure, but are able to manage However, Cloud Service Providers (CSP) often the running operating systems and applications.
    [Show full text]
  • Nfaas: Named Function As a Service Michał Król Ioannis Psaras University College London University College London [email protected] [email protected]
    NFaaS: Named Function as a Service Michał Król Ioannis Psaras University College London University College London [email protected] [email protected] ABSTRACT functionality to be incorporated. Powerful end-user devices and In the past, the Information-centric networking (ICN) community new applications (e.g., augmented reality [1]) demand minimum has focused on issues mainly pertaining to traditional content de- service delay, while the Internet of Things (IoT) [2] generates huge livery (e.g., routing and forwarding scalability, congestion control amounts of data that flow in the reverse direction from traditional and in-network caching). However, to keep up with future Internet flows (that is, from the edge towards the core for processing). As architectural trends the wider area of future Internet paradigms, a result, computation needs to be brought closer to the edge to there is a pressing need to support edge/fog computing environ- support minimum service latencies and to process huge volumes ments, where cloud functionality is available more proximate to of IoT data. where the data is generated and needs processing. In contrast to cloud computing, edge and fog computing promote With this goal in mind, we propose Named Function as a Service the usage of resources located closer to the network edge to be (NFaaS), a framework that extends the Named Data Networking used by multiple different applications, effectively reducing the architecture to support in-network function execution. In contrast transmission delay and the amount of traffic flowing towards the to existing works, NFaaSbuilds on very lightweight VMs and allows network core.
    [Show full text]
  • 2.5 AWS Lambda
    Bachelorarbeit Jules Fehr Serverlose Architektur: Function as a Service mit AWS Lambda am Beispiel einer Web-Anwendung für Fotografen Fakultät Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science Jules Fehr Serverlose Architektur: Function as a Service mit AWS Lambda am Beispiel einer Web-Anwendung für Fotografen Abschlussarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Wirtschaftsinformatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr. Ulrike Steffens Zweitgutachter: Prof. Dr. Stefan Sarstedt Abgegeben am 19.07.2018 Jules Fehr Thema der Arbeit Serverlose Architektur: Function as a Service mit AWS Lambda Beispiel einer Web-Anwendung für Fotografen Stichworte FaaS, Serverless, AWS Lambda, Web-Anwendung Kurzzusammenfassung Das Ziel dieser Bachelorarbeit ist die Konzeption und Entwicklung einer Function as a Service Web-Anwendung für Fotografen. In dieser Arbeit werden die Prinzipien von serverloser Architektur behandelt. Es wird eine Referenzarchitektur vorgestellt und es wird eine Anforderungsanalyse für die Anwendung erstellt. Basierend auf der Analyse und den Prinzipien der serverlosen Architektur wird die Umsetzung wichtiger Komponenten erläutert. Jules Fehr Title of the paper Serverless Architecture: Function as a Service with AWS Lambda on the example of a web application for photographers Keywords FaaS, Serverless, AWS Lambda, Web-application Abstract The goal of this bachelor thesis is the conception and development of a Function as a Service web-application for photographers. The principles of serverless architecture will be discussed. A reference architecture will be presented and a requirement analysis will be made. The implementation of important components will be made based on the analysis and the principles of serverless architecture.
    [Show full text]
  • Nanolambda: Implementing Functions As a Service at All Resource Scales for the Internet of Things
    NanoLambda: Implementing Functions as a Service at All Resource Scales for the Internet of Things. Gareth George, Fatih Bakir, Rich Wolski, and Chandra Krintz Computer Science Department Univ. of California, Santa Barbara Abstract—Internet of Things (IoT) devices are becoming in- decompose their applications into multiple functions, each re- creasingly prevalent in our environment, yet the process of sponsible for some short-lived piece of processing. A function programming these devices and processing the data they produce is typically a small, single-entry code package (50 megabytes remains difficult. Typically, data is processed on device, involving arduous work in low level languages, or data is moved to the or less) written in a high level language (e.g. Python, node.js, cloud, where abundant resources are available for Functions or Java). Thanks to their small size and self-contained design, as a Service (FaaS) or other handlers. FaaS is an emerging these functions are easily invoked and scaled automatically category of flexible computing services, where developers deploy by the FaaS platform in response to incoming events (data self-contained functions to be run in portable and secure con- arrival, messages, web requests, storage updates, etc.). Many tainerized environments; however, at the moment, these functions are limited to running in the cloud or in some cases at the “edge” functions, potentially belonging to different tenants, execute on of the network using resource rich, Linux-based systems. a single server, using Linux containers to provide secure iso- In this paper, we present NanoLambda, a portable platform lation and a consistent execution environment.
    [Show full text]
  • Serverless Computing in Financial Services High Performance Computing—With More Speed, Accuracy and Flexibility Authors
    Serverless computing in financial services High performance computing—with more speed, accuracy and flexibility Authors Michael Behrendt is a Distinguished Engineer in Neil Cowit is the Worldwide Cloud Offering the IBM Cloud development organization. He is Manager for High Performance Computing at responsible for IBM’s technical strategy around IBM. HPC has been a significant part of Neil’s serverless & Function-as-a-Service. 20-plus-year career within the financial services technology sector. He has held leadership In that context, he’s also the chief architect for and individual contributor roles in Product the IBM serverless offering, IBM Cloud Functions. Management, Development, Sales and Marketing. Before that, he was the chief architect of the core platform of IBM Bluemix and was one of the initial founding members incubating it. Michael has been working on cloud computing for more than 13 years and has 35 patents. He is located in the IBM Research & Development Laboratory in Boeblingen, Germany. | 2 | Contents Authors 02 Introduction 04 What issues can serverless computing help address? 06 Technical perspective 07 IBM Cloud Functions: Implementing serverless computing 08 Benefits of IBM Cloud Functions 08 Conclusion 09 Glossary 10 | 3 | Introduction If Mrs. Wallis Simpson were alive today and Wouldn’t it be terrific if we only had to solve static involved in financial services, she may very well or deterministic models as opposed to stochastic have modified her famous quote from “You can or probabilistic financial models? Imagine being never be too rich or too thin.” to “You can never able to cover all the possible contingencies in have too much compute capacity.” proportion to their likelihood.
    [Show full text]
  • Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider
    Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider Mohammad Shahrad, Rodrigo Fonseca, Íñigo Goiri, Gohar Chaudhry, Paul Batum, Jason Cooke, Eduardo Laureano, Colby Tresness, Mark Russinovich, and Ricardo Bianchini July 15, 2020 What is Serverless? •Very attractive abstraction: • Pay for Use • Infinite elasticity from 0 (and back) • No worry about servers • Provisioning, Reserving, Configuring, patching, managing •Most popular offering: Function-as-a-Service (FaaS) • Bounded-time functions with no persistent state among invocations • Upload code, get an endpoint, and go For the rest of this talk, Serverless = Serverless FaaS What is Serverless? Bare Metal VMs (IaaS) Containers Functions (FaaS) Unit of Scale Server VM Application/Pod Function Provisioning Ops DevOps DevOps Cloud Provider Init Time Days ~1 min Few seconds Few seconds Scaling Buy new hardware Allocate new VMs 1 to many, auto 0 to many, auto Typical Lifetime Years Hours Minutes O(100ms) Payment Per allocation Per allocation Per allocation Per use State Anywhere Anywhere Anywhere Elsewhere Serverless “…more than 20 percent of global enterprises will have deployed serverless computing technologies by 2020.” Gartner, Dec 2018 Serverless Source: CNCF Cloud Native Interactive Landscape https://landscape.cncf.io/format=serverless Serverless December 2019 “… we predict that (…) serverless computing will grow to dominate the future of cloud computing.” So what are people doing with FaaS? • Interesting Explorations • MapReduce (pywren)
    [Show full text]
  • A Brief History of Cloud Application Architectures
    applied sciences Review A Brief History of Cloud Application Architectures Nane Kratzke ID Lübeck University of Applied Sciences, Department of Electrical Engineering and Computer Science, 23562 Lübeck, Germany; [email protected] Received: 14 July 2018; Accepted: 27 July 2018; Published: 14 August 2018 Featured Application: This paper features system and software engineering use cases for large-scale (business) Cloud-native applications (e.g., Netflix, Twitter, Uber, Google Search). Such Cloud-native applications (CNA) provide web-scalability and independent deployability of their components and enable exponential user growth. Furthermore, migration and architecture transformation use cases of existing tiered and on-premise (business) applications are additionally of interest. Thus, questions of how existing and not cloud-ready applications are migratable into cloud environments are covered as well. Abstract: This paper presents a review of cloud application architectures and its evolution. It reports observations being made during a research project that tackled the problem to transfer cloud applications between different cloud infrastructures. As a side effect, we learned a lot about commonalities and differences from plenty of different cloud applications which might be of value for cloud software engineers and architects. Throughout the research project, we analyzed industrial cloud standards, performed systematic mapping studies of cloud-native application-related research papers, did action research activities in cloud engineering projects, modeled a cloud application reference model, and performed software and domain-specific language engineering activities. Two primary (and sometimes overlooked) trends can be identified. First, cloud computing and its related application architecture evolution can be seen as a steady process to optimize resource utilization in cloud computing.
    [Show full text]
  • Architectural Implications of Function-As-A-Service Computing
    Architectural Implications of Function-as-a-Service Computing Mohammad Shahrad Jonathan Balkind David Wentzlaff Princeton University Princeton University Princeton University Princeton, USA Princeton, USA Princeton, USA [email protected] [email protected] [email protected] ABSTRACT Network Serverless computing is a rapidly growing cloud application model, popularized by Amazon’s Lambda platform. Serverless cloud ser- Scheduling vices provide fine-grained provisioning of resources, which scale Platform (priorwork) automatically with user demand. Function-as-a-Service (FaaS) appli- Queueing Management cations follow this serverless model, with the developer providing 35% decrease in IPC Interference their application as a set of functions which are executed in response due to interference 6x variation due to to a user- or system-generated event. Functions are designed to Memory BW invocation pattern 20x MPKI for be short-lived and execute inside containers or virtual machines, Branch MPKI >10x exec time short functions introducing a range of system-level overheads. This paper studies for short functions Cold Start Server the architectural implications of this emerging paradigm. Using (500ms cold start) Up to 20x (thispaper) Container the commercial-grade Apache OpenWhisk FaaS platform on real slowdown servers, this work investigates and identifies the architectural im- Native plications of FaaS serverless computing. The workloads, along with Execution Figure 1: We characterize the server-level overheads of the way that FaaS inherently interleaves short functions from many Function-as-a-Service applications, compared to native exe- tenants frustrates many of the locality-preserving architectural cution. This contrasts with prior work [2–5] which focused structures common in modern processors.
    [Show full text]
  • Persistent Helper Functions in a Serverless Offering
    Journal of Software Engineering and Applications, 2020, 13, 278-287 https://www.scirp.org/journal/jsea ISSN Online: 1945-3124 ISSN Print: 1945-3116 Result-as-a-Service (RaaS): Persistent Helper Functions in a Serverless Offering Arshdeep Bahga, Vijay K. Madisetti, Joel R. Corporan Georgia Institute of Technology, Atlanta, USA How to cite this paper: Bahga, A., Madi- Abstract setti, V.K. and Corporan, J.R. (2020) Re- sult-as-a-Service (RaaS): Persistent Helper Serverless Computing or Functions-as-a-Service (FaaS) is an execution model Functions in a Serverless Offering. Journal for cloud computing environments where the cloud provider executes a piece of Software Engineering and Applications, of code (a function) by dynamically allocating resources. When a function 13, 278-287. https://doi.org/10.4236/jsea.2020.1310018 has not been executed for a long time or is being executed for the first time, a new container has to be created, and the execution environment has to be in- Received: September 21, 2020 itialized resulting in a cold start. Cold start can result in a higher latency. We Accepted: October 24, 2020 propose a new computing and execution model for cloud environments Published: October 27, 2020 called Result-as-a-Service (RaaS), which aims to reduce the computational Copyright © 2020 by author(s) and cost and overhead while achieving high availability. In between successive Scientific Research Publishing Inc. calls to a function, a persistent function can help in successive calls by pre- This work is licensed under the Creative computing the functions for different possible arguments and then distribut- Commons Attribution International License (CC BY 4.0).
    [Show full text]
  • How Entle Core™ Reduces Risk with Proven Technologies
    How Entle Core™ reduces risk with proven technologies What is Entle Core™? cloud computing had become well-established, and serverless computing took that a step further to make On the basis of over a decade in the web elastic infrastructure even more accessible. development industry, Entle has developed a mature, In contrast to a constantly-running server or elastic risk-reducing, and highly performant website server group that responds to visitor requests (either architecture called Entle Core™. Websites built with using bare-metal physical machines, virtual machines, Entle Core™ are heavily optimised for performance, or containers), serverless functions use cloud native SEO, and ultimately, conversion. systems’ inherent elasticity to consume resources on To achieve this, Entle Core™ combines a serverless demand and in a fully abstracted manner. Server hosting architecture with the JAMstack (JavaScript, management is abstracted to the cloud provider’s APIs, and markup) pattern. expert team, in the same way that they are responsible for all their other cloud infrastructure (e.g. in AWS’ The key elements of Entle Core™ are: case, the underlying infrastructure for EC2, EKS, Aurora • Serverless hosting using AWS S3 storage and AWS or Redshift). This significantly reduces the DevOps Cloudfront CDN, and AWS Lamda to provide workload on the website developer and thereby dynamic functionality; reduces the risk associated with designing, testing, and maintaining one’s own server setup. Serverless is the next step in the evolution of A static site
    [Show full text]
  • A Systematic Mapping Study on Engineering Function-As-A-Service Platforms and Tools
    Institute of Architecture of Application Systems A Systematic Mapping Study on Engineering Function-as-a-Service Platforms and Tools Vladimir Yussupov, Uwe Breitenbücher, Frank Leymann, Michael Wurster Institute of Architecture of Application Systems, University of Stuttgart, Germany, {yussupov, breitenbuecher, leymann, wurster}@iaas.uni-stuttgart.de : @inproceedings{Yussupov2019_SystematicMappingStudyFaaS, author = {Vladimir Yussupov and Uwe Breitenb{\"u}cher and Frank Leymann and Michael Wurster}, title = {{A Systematic Mapping Study on Engineering Function-as-a-Service Platforms and Tools}}, booktitle = {Proceedings of the 12th IEEE/ACM International Conference on Utility and Cloud Computing (UCC 2019)}, publisher = {ACM}, year = 2019, month = dec, pages = {229--240}, doi = {10.1145/3344341.3368803} } © Yussupov et al. 2019. This is an Open Access publication licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. A Systematic Mapping Study on Engineering Function-as-a-Service Platforms and Tools Vladimir Yussupov Uwe Breitenbücher Institute of Architecture of Application Systems Institute of Architecture of Application Systems University of Stuttgart, Germany University of Stuttgart, Germany [email protected] [email protected] Frank Leymann Michael Wurster Institute of Architecture of Application Systems Institute of Architecture of Application Systems University of Stuttgart, Germany University of Stuttgart, Germany [email protected] [email protected] ABSTRACT which creates a wrong impression that servers are absent. A recent Function-as-a-Service (FaaS) is a novel cloud service model allowing newcomer in the line of as-a-service offerings called Function-as- to develop fine-grained, provider-managed cloud applications.
    [Show full text]
  • Rethinking Scalable Service Architectures for the Internet of Things
    Devices-as-Services: Rethinking Scalable Service Architectures for the Internet of Things Fatih Bakir, Rich Wolski, Chandra Krintz Gowri Sankar Ramachandran Univ. of California, Santa Barbara Univ. of Southern California Abstract vices at the edge that augment device capabilities and enable We investigate a new distributed services model and architec- scale. In this paper, we outline this approach to implementing ture for Internet of Things (IoT) applications. In particular, Devices-as-Services and describe some of the capabilities of we observe that devices at the edge of the network, although an early prototype. resource constrained, are increasingly capable – performing Our work is motivated by the following observations. • IoT applications can and will likely be structured as collec- actions (e.g. data analytics, decision support, actuation, con- tions of services that require functionality from a device trol, etc.) in addition to event telemetry. Thus, such devices tier, an edge tier, and a cloud tier are better modeled as servers, which applications in the cloud • in-network data processing can significantly reduce re- compose for their functionality. We investigate the implica- sponse time and energy consumption [31], tions of this “flipped” IoT client-server model, for server dis- • edge isolation precludes the need for dedicated commu- covery, authentication, and resource use. We find that by com- nication channels between application and devices, and bining capability-based security with an edge-aware registry, facilitates privacy protection for both data and devices, this model can achieve fast response and energy efficiency. • actuation in device tier will require some form of request- 1 Introduction response protocol where the device fields the request, • the heterogeneity of devices militates for a single program- As the Internet of Things (IoT) grows in size and ubiquity, it ming paradigm and distributed interaction model, and is becoming critical that we perform data-driven operations • multi-function devices can and will be able to perform their (i.e.
    [Show full text]