Towards sustainable ecosystems for cloud functions

Yessica Bogado-Sarubbi, Walter Benitez-Davalos, and Fabio Lopez-Pires

Information and Communication Technology CenterItaipu Technological ParkHernandarias, Paraguay

Email: {yessica.bogado,walter.benitez,fabio.lopez}@pti.org.py

Josef Spillner

Service Prototyping LabZurich University of Applied Sciences

Winterthur, SwitzerlandEmail: josef.spillner@zhaw.ch

Abstract

The main technologies around modern clouddevelopment and deployment paradigms such asFunction-as-a-Service (FaaS) environments follow atypical technology life-cycle. Starting with basic codeinstallation and execution environments, they unfoldinto a complete ecosystem with rich collaborativedevelopment and market enablement tools. In thispaper, we analyse the growth of such ecosystems,reveal causes of hindrances in previous service-orientedapproaches, and present a vision of how an ecosystemwith sustainable operation could look like both in gen-eral and specifically for cloud functions. We presentFunction Hub, a partial prototypical implementationto gain first knowledge about the potential operationalecosystem behaviour.

Keywords: Cloud Applications, Serverless Com-puting, Service Ecosystems, Tangible Microservices,Marketplaces.

1 Problem statement

In the late 1990s and early 2000s, the idea ofmarketplaces to exchange software development arte-facts arose in the research communities for Component-Based Software Engineering (CBSE) and later Service-Oriented Software Engineering (SOSE).

According to the early visions, rich ecosystemswould emerge based on centralised exchanges such asregistries implementing the Universal Description, Dis-covery and Integration (UDDI) specification includingthe Universal Business Registry (UBR) (Saini 2016).Yet, on a large scale, the ideas mostly failed. In-stead, several technology-specific exchanges, often de-centralised, have emerged in recent years. After severaliterations across web technologies, heavy-weight andlight-weight cloud technologies and more recently fogcomputing approaches, a few of them have manifestedas useful practical tooling. A brief overview on rele-vant technology-specific exchanges is presented next inTable 1.

Technology Exchange

Source code GitHubJava libraries MavenContainers Docker Hub

Web services Programmable WebCloud services Open Service Broker API

Table 1: Overview on technology-specific exchanges.

Hence, the initial ideas increasingly become viablealbeit often in limited form, focusing on pragmatic pro-ductivity gains especially for rapid prototyping of com-posite applications and services.In the context of previously described ecosystems,emerging computing paradigms such as Function as

18

a Service (FaaS) (Baldini et al. 2017) taking into ac-count serverless computing architectures and imple-mentations with cloud functions, relevant challengesstill remain open as the ones presented as follows.

• Who operates such exchanges (e.g. brokers ormarketplaces) in a sustainable way?

• If the operation of these exchanges is not cen-tralised and not linked to concrete business mod-els, how can it be sustained?

• Which future exchanges will emerge for new tech-nologies such as cloud functions in seeminglyserverless computing environments?

• How these future exchanges may look like?

Starting by answering the last question, this paperpresents our position by outlining an ecosystem vi-sion for exchanging and collaboratively developing soft-ware with cloud functions. Additionally, a comparisonof the conceptual ecosystem against existing ones ispresented, and main reasons about the sustainabilityaspects are included to give answers to the remainingthree questions.

2 Ecosystem analysis

For conceptualisation and contextualisation, ananalysis of the actual software ecosystem environmentis needed. In this section a definition is presented aswell as an analysis of ecosystems current growth andobstacles.

2.1 Ecosystem Definition

In this paper an ecosystem is defined to be an opensystem consisting of a set of technical elements whichenable growth by attracting contributions from par-ticipants. Among the elements are service-orientedelements (marketplaces, hubs, brokers), as well asplatforms and further provider and consumer tools.

2.2 Growth of ecosystems

Ecosystems can be measured primarily by lookingat provider and consumer metrics which cover boththe absolute volume and the growth factors. Yuobserves the co-evolution of ecosystems on a wider scalefrom a provider perspective involving hardware, sys-tem software and software-implemented applications

(Yu 2011). Among his key observations is the slow-down effect which occurs when moving up the stack.The dependent products grow slower with logarithmicrelation compared to the independent product. Froma consumer perspective, Petsas et al. reveal in thecontext of mobile application ecosystems that down-load statistics do not follow a Zipf distribution (Petsaset al. 2013). In these systems, there are moreover fewalternative system software choices, leading to a com-parably huge offering of applications.

2.3 Obstacles and hindrances

A key concern is the stakeholder structure behind theoperating entities of ecosystem elements. Multiplepopular exchanges are operated by a single commercialplayer. In case of bankruptcy or change of businessmodel, the exchange may vanish or fade into obscu-rity quickly. The ownership structure also distorts theanalysis of the economic viability. Docker Hub, for in-stance, is operated by Docker, Inc. but does not itselfgenerate direct revenue. Instead, it is cross-financed byother company operations whose growth is in turn sup-ported by the dominance of the exchange on the mar-ket. Another issue is the concentration of providers inecosystems. For example, images on Docker Hub areprone to several security issues. This situation also af-fects the officially maintained images from which theissues propagate into derivatives. Any security vul-nerability that could be exploited has the potentialto affect vast shares of development and deploymentworkflows in critical applications as a consequence (Shuet al. 2017).In summary, main identified obstacles and hindrancescould be single commercial owners and concentrationof providers in ecosystems.

3 Value proposition and position

This paper propose to strive towards sustainableecosystems for heterogeneous application developmentartefacts which can be customised for arbitrary do-mains including cloud and mobile applications andso forth. The sustainability will be achieved by de-centralisation and abstraction. Arguing that bya suitable combination of decentralised ecosystem el-ements with built-in abstraction capabilities, a long-term growth and sustainable operation can be achievedeven in volatile environments with changing technolo-gies and market forces.

19

DecentralizationDecentralized repositories

Users

Functions Hub Interface

AbstractionAbstraction tools

Figure 1: General view of the proposed ecosystem.

The considered arguments are as follows.

• Decentralisation: In recent years, several appli-cations on the Internet have become centralisedconglomerate services. Yet over longer periods oftime, they may not prevail (DeLegge & Wangler2017). A decentralised ecosystem guarantees thatin a worst case even when individual market par-ticipants vanish, the system will continue to func-tion in reduced form.

• Abstraction: The right level of abstraction isimportant. While existing ecosystems have onlybecome successful for technologically specialisedartefacts, there is a large spectrum between theseand fully generic approaches which can be ex-ploited. This exploitation can be partially auto-mated by converting formats and protocols.

To include these characteristics in a serverlessecosystem, the following approach has been establishas shown in Figure 1. For decentralisation, a set of de-centralised repositories that allows users to download,test and use cloud functions directly. These reposito-ries will be connected through a marketplace, wheredevelopers will be able to share, deploy and even com-mercialise cloud functions. For abstraction, tools toconvert and deploy functions will be used, allowing de-ployment on a diverse set of cloud providers.

4 Conceptual elements perspective

This section covers detailed design and architecture ofthe core elements within the proposed ecosystem.

4.1 Marketplaces

The idea of a marketplace is to create an environ-ment where developers could interact with the plat-form ecosystem in a way that allows them to create,share and trade tools, enabling users to deploy, scaleand create functions more easily and efficiently.In that sense, industry already has some marketplacesfrom other software ecosystems. For example, GitHubhas the GitHub Marketplace, a marketplace wherethird-party companies create and commercialise in-tegration tools that allow users to work more effi-ciently with their source code. Additionally, Dockerhas DockerStore, a place where third-party companiesoffer plugins and certified containers to docker users.This allows them to access enterprise solutions andcreate industry-ready applications using the Dockerecosystem. Amazon Web Services (AWS) Marketplacefrom Amazon, allows both users and third-party com-panies to trade tools that uses the AWS ecosystem. Atthe time of this writing, only Amazon has a first pro-totype of a serverless ecosystem with some still basicfeatures1.From the above mentioned example marketplaces,some relevant characteristic that the marketplaceshould have can be specified:

• Enable third-party companies and/or users to cre-ate tools that interact with the ecosystem.

• Enable third-party companies and/or users tocommercialise their add-on tools.

• A framework that allows users to collaborate witheach other within the ecosystem.

• Integration with other software platforms (Docker,GitHub, AWS, among others).

One characteristic that stands out of these softwareplatforms is marketplace centralisation. This couldlead to potential software disruptions in case of changeof policies or departure of mayor stakeholders.

1https://aws.amazon.com/serverless

20

4.2 Converters

Even deployment-ready applications have to deal withsyntax associated with each cloud platform. For in-stance, every serverless cloud platform has its own Ap-plication Program Interface (API), methods and syn-tax to deploy functions, generating a vendor lock-inissue, where users have to create functions for specificcloud providers instead of a general one.A feasible solution is to automatically add wrappersthrough a converter, allowing this way developers tocreate code according to its real requirements, withoutworrying with the code necessary to make it run on aspecific cloud environment. With the advent of mo-bile edge computing, this could be a very interestingapproach to federate cloud providers.

4.3 Deployers

To accomplish a total integration with the industrialcloud ecosystem, a flexible tool that allows users to de-ploy their functions on multiple cloud environments isneeded. Most of the tools used in industrial cloud en-vironments are associated to its own platforms. Ama-zon Cloud Formation, Google Cloud Deployment Man-ager and Azure Resource Manager are examples of lo-cal frameworks that manage the set of resources for itsown specific platform.For cloud multi-tenancy, for example, allowing migra-tion from one cloud provider to another is a key fea-ture. An example of a tool that currently applies thisconcept is the serverless framework2, an open sourceCommand Line Interface (CLI) for building serverlessarchitectures and event-driven applications, using spe-cific software resources for deployment of functions ina wide set of cloud platforms.

4.4 Execution environments

To easily create and deploy functions, an execution en-vironment has to be set in place. Each cloud providerfocuses its environment in accordance to an aimed de-veloper group or their specific infrastructure. For ex-ample, AWS Lambda supports major programminglanguages such as Java, JavaScript, Python, C# andlately Go. Each of these languages with their mostpopular runtimes like Node.js, Java 8, Python 2 and3, but they add extra features allowing users to inter-act with the infrastructure. On the other hand, AzureFunctions supports major development languages for

2https://github.com/serverless/serverless

Microsoft like C#, F# , JavaScript or PHP. Never-theless, the field of the deployment of functions doesnot belong only to private platforms. In this context,one of the most popular open source cloud platformis Apache OpenWhisk, that execute functions in re-sponse to events, supporting programming languageslike JavaScript/Node.js, Swift, Python, Java and evenimplementing Docker logic.

4.5 Interaction and serverless ecosystem

In serverless architectures, cloud providers have com-plete management over the environment in which func-tions run. These creates high-level abstract environ-ments for the users, where they should not worry aboutdeployment or maintenance and expects it to be fault-tolerant with auto-scaling features (Baldini et al. 2017).This architecture is basically a event-driven computa-tion pattern that promotes loosely couple services andensures a trigger function execution (Stigler & Stigler2018).The interaction between users, interfaces and reposi-tories is given in a way that presents a continuous ex-changing of functions and allows the growth of a mar-ketplace. The interface creates the link between allrepositories and users. Because each repository is per-sonal, every user could create a new repository and hasthe option to share theirs or store functions from otherusers. As a way of allowing abstraction, every functionis created as simple as possible, to after that, establisha conversion to match a cloud provider specific require-ment.

4.6 Related ecosystems

At the time of this writing, a new serverless ecosystemfor sharing functions in AWS Lambda is the AWSServerless Application Repository. This repository al-lows users of AWS Lambda to create, share and usefunctions on that specific environment. The maindrawback of this new ecosystem is the vendor lock-inissue, because all components are associated with thisspecific provider, resulting in a centralised non-abstractecosystem. Additionally, it only allows registration forusers with an associated bank account (credit or debitcard), difficulting students to access this repository andassociated functions.In contrast, the new approach considered for the pro-posed ecosystem, let users create their own repositoryto share, test and deploy functions. Remembering thatfunctions are created as simple as possible, they could

21

be converted and deployed in different cloud environ-ments, making it easy to create functions associatedwith a specific product without having any dependen-cies over a certain provider.

5 Proof of concept and implemen-tation

For a Proof of Concept (PoC), several ecosystem ele-ments were implemented to gain insights and knowl-edge about their actual behaviour and effectiveness.For an implementation, it was focused on an event-driven application as a subset of the entire cloud ap-plication space, due to their alignment with statelesscloud function processing. Furthermore, the use ofdecentralised open messaging infrastructure was ex-plored. Figure 2 shows the proposed ecosystem toachieve a Function Hub that could help to cre-ate a decentralised environments for the serverlessecosystem.

5.1 Function marketplaces

The initial prototype its based on the core idea thatdefines what and how elements are trade within it. Inthis case, an ecosystem that allows free exchange offunctions between users and generates the required en-vironment for a serverless market to proliferate.For this purpose a Function Hub3 was designed con-sidering the following characteristics:

• Decentralisation, by using an Extensible Mes-saging and Presence Protocol (XMPP) for com-munications, without centralised storage.

• Abstraction, by using Snafu4 which allows man-aging cloud functions across provider conventionboundaries.

Additionally, the complete Function Hub ecosystemis composed by four main components:

• Users: Users that access the Function Hub In-terface5 to share and get functions according toits needs.

• Function Hub Interface: It is a website basedon AngularJS which runs on a NginX server. Users

3https://github.com/serviceprototypinglab/functionshub4https://github.com/serviceprototypinglab/snafu5https://github.com/YessicaBogado/FunHub

can search a function by name or specifying otherattributes, having the testing option on the sameplatform and then download functions accordingto its requirements. For the interconnection be-tween HTTP and XMPP protocols, a message bro-ker named MW 2 was developed.

• Decentralisation: In this work, decentralisationis achieved through repositories to store functionsand serving as an active server for users. A soft-ware named Snafu (Swiss Army Knife of Serve-less Computing), a FaaS host process, was usedfor this task. Snafu was chosen because it ful-fils two main characteristics, as an execution en-vironment for functions (active mode) and as afunction repository (passive mode). As FunctionHub does not pretend to use an unique centralisedstorage, it communicate with other repositoriesthrough XMPP. For this reason, each provider hasa XMPP Client account associated to its messagebroker MW 1 and to its associated XMPP Serverfor sending data required by users. The use ofmessage brokers allows interconnection betweenHTTP and XMPP protocols, because both Func-tion Hub and Snafu use HTTP as a main protocolconnector. The implementation of the messagebrokers (MW 1 and MW 2 ) was made throughflask and nbxmpp libraries in Python.

• Abstraction: The abstraction sector is composedby a basic converter that add all the basic wrap-pers needed to deploy the function, according tomost of the main cloud providers and uses theserverless framework (Collins 2015) as a deploy-ment tool.

5.2 Function converters

As an early prototype6, a converter of Python functionswas developed to add wrappers for different modulesthat the file could have. It works according to thesesteps:

• It consumes and checks if the function has somerun-time code to avoid security issues when im-porting.

• After checking, depending of the choice of the con-verter user, it dismantles different modules of thefile and adds wrappers with the function for each

6https://github.com/walter-bd/faas-converter

22

Encabezado

User

DecentralizationDecentralized repositories

Function Hub Interface

Repository 1

Fun_A

Fun_B

Web User Interface

Web Server

R XMPP Server 1

Repository 2

Fun_C

Fun_D

Repository M

Fun_E

Fun_F

User N

Web Browser

XMPP Server K

MW 1

MW 1

MW 1

MW 2

R R

HTTP

HTTP

HTTP

HTTP

HTTP HTTP

User 1

Web Browser

AbstractionAbstraction tools

Converter

Deploy

Cloud Provider

Figure 2: Proposed ecosystem implementation flowchart.

one on different files or it add the wrapper of oneof this module at the end of a copy of the file.

• It has option to add wrappers for providers likeAWS, OpenWhisk, Fission, OVH and Azure.

• The user can choose wherever to add the wrapperson different files for each provider or to add it alltogether in one file but, it has to manually checkfor some collisions with other wrappers added.

This tool will allow users of the environment to easilycreate standard function to deploy in different cloudproviders.

5.3 Function deployers

For deploying functions into the ecosystem, a new func-tionality was needed to be added. This will give usersthe option to upload their functions from their reposi-tories to the Function Hub ecosystem; hence, for thispurpose a Snafu server is used.To deploy functions from the Function Hub to aprivate cloud provider is intended to use the server-less framework, because this have already options to

facilitate the deployment on the most popular cloudproviders. Furthermore, a composeless7 service is beingdeveloped to deploy functions on serverless ecosystemsor in a container, according to particular needs.

5.4 Function execution environments

The execution environment of the ecosystem is pro-vided by the FaaS host process Snafu, and it’s sup-port different programming languages like C, Java,JavaScript and Python. Snafu is deployed on anAlpine-based docker image, where it has the followingrun-time environments Python 3.5, Python 2.7, open-jdk8, nodejs and for compiling purpose gcc and g + +for C programs.

5.5 Type of users

In the proposed ecosystem, the interaction is based infour kind of users:

• Regular users: They use the ecosystem to look,download, test or upload functions to allowed

7https://github.com/serviceprototypinglab/composeless

23

repositories. To make this possible, a web interfaceis available, showing the user all the repositoriesand its respective functions.

• Exclusive repository user: For companies thatwant to create exclusive functions to their prod-ucts associated with their own infrastructure.Function Hub would provide a place where theycan share the use of this function, allowing themto decide what to share and what to sell.

• Passive repository user: In this case, collabo-rative users or companies could create a repositoryso that other users could use it to store its func-tions.

• Active repository user: It would work as a Pas-sive Repository, but also will allow regular usersto test the functions or execute it there.

6 Conclusions and future directions

The rapid growth of serverless computing creates aneed for an ecosystem in order to bring users necessarytools for a fast and cheap deployment of their software.On that point, Amazon took the first steps, providingto their users a serverless repository with basic func-tionalities. Also, new open source serverless initiatives,like OpenWhisk and Fission, gives developers freedomto create new tools.However, and as it was showed in this paper, it is alsoneeded properties like decentralisation and abstractionthat allows them to create applications that interactwith a diverse cloud ecosystem and take advantage ofthis diversity according to their needs, without worry-ing when individual market participant vanish. Point-ing on that direction, this paper presented a visionfor how ecosystems with a decentralised Function Hubmay give to developers a way to share their functions,thinking not only on a specific cloud provider but alsoconsidering application itself instead. Further discus-sion, research and develop is required with the objec-tive of give such ecosystem essential properties like sus-tainability, scalability and reliability associated with awider adoption.

References

Baldini, I., Castro, P., Chang, K., Cheng, P., Fink,S., Ishakian, V., Mitchell, N., Muthusamy, V.,

Rabbah, R., Slominski, A. et al. (2017), Serverlesscomputing: Current trends and open problems, in‘Research Advances in Cloud Computing’, Springer,pp. 1–20.URL: https://doi.org/10.1007/978-981-10-5026-8 1

Collins, A. (2015), ‘Serverless framework’, GitHub.URL: https://github.com/serverless/serverless

DeLegge, A. & Wangler, H. (2017), ‘Is this the end forfacebook? A mathematical analysis’, Applied Math-ematics and Computation 305, 364–380.URL: https://doi.org/10.1016/j.amc.2017.02.014

Petsas, T., Papadogiannakis, A., Polychronakis, M.,Markatos, E. P. & Karagiannis, T. (2013), Riseof the planet of the apps: a systematic study ofthe mobile app ecosystem, in ‘Proceedings of the2013 Internet Measurement Conference, IMC 2013,Barcelona, Spain, October 23-25, 2013’, pp. 277–290.URL: http://doi.acm.org/10.1145/2504730.2504749

Saini, A. (2016), An extension to UDDI for the dis-covery of user driven web services, in ‘DistributedComputing and Internet Technology - 12th Inter-national Conference, ICDCIT 2016, Bhubaneswar,India, January 15-18, 2016, Proceedings’, pp. 92–96.URL: https://doi.org/10.1007/978-3-319-28034-9 11

Shu, R., Gu, X. & Enck, W. (2017), A study ofsecurity vulnerabilities on docker hub, in ‘Proceed-ings of the Seventh ACM on Conference on Dataand Application Security and Privacy, CODASPY2017, Scottsdale, AZ, USA, March 22-24, 2017’,pp. 269–280.URL: http://doi.acm.org/10.1145/3029806.3029832

Stigler, M. & Stigler, M. (2018), Beginning ServerlessComputing, Springer.URL: https://doi.org/10.1007/978-1-4842-3084-8 1

Yu, L. (2011), ‘Coevolution of information ecosystems:a study of the statistical relations among the growthrates of hardware, system software, and applicationsoftware’, ACM SIGSOFT Software EngineeringNotes 36(6), 1–5.URL: http://doi.acm.org/10.1145/2047414.2047435

24