According to the early visions, rich ecosystems would emerge based on centralised exchanges such as The main technologies around modern cloud registries implementing the Universal Description, Disdevelopment and deployment paradigms such as covery and Integration (UDDI) specification including Function-as-a-Service (FaaS) environments follow a the Universal Business Registry (UBR) (Saini 2016). typical technology life-cycle. Starting with basic code Yet, on a large scale, the ideas mostly failed. Ininstallation and execution environments, they unfold stead, several technology-specific exchanges, often deinto a complete ecosystem with rich collaborative centralised, have emerged in recent years. After several development and market enablement tools. In this iterations across web technologies, heavy-weight and paper, we analyse the growth of such ecosystems, light-weight cloud technologies and more recently fog reveal causes of hindrances in previous service-oriented computing approaches, a few of them have manifested approaches, and present a vision of how an ecosystem as useful practical tooling. A brief overview on relewith sustainable operation could look like both in gen- vant technology-specific exchanges is presented next in eral and specifically for cloud functions. We present Table 1. Function Hub, a partial prototypical implementation to gain first knowledge about the potential operational ecosystem behaviour.
a Service (FaaS) (Baldini et al. 2017) taking into ac- (Yu 2011). Among his key observations is the slowcount serverless computing architectures and imple- down effect which occurs when moving up the stack. mentations with cloud functions, relevant challenges The dependent products grow slower with logarithmic still remain open as the ones presented as follows. relation compared to the independent product. From a consumer perspective, Petsas et al. reveal in the • Who operates such exchanges (e.g. brokers or context of mobile application ecosystems that downmarketplaces) in a sustainable way? load statistics do not follow a Zipf distribution (Petsas • If the operation of these exchanges is not cen- et al. 2013). In these systems, there are moreover few tralised and not linked to concrete business mod- alternative system software choices, leading to a comels, how can it be sustained? parably huge offering of applications. 2.3
• Which future exchanges will emerge for new technologies such as cloud functions in seemingly serverless computing environments?
operating entities of ecosystem elements. Multiple • How these future exchanges may look like? popular exchanges are operated by a single commercial Starting by answering the last question, this paper player. In case of bankruptcy or change of business presents our position by outlining an ecosystem vi- model, the exchange may vanish or fade into obscusion for exchanging and collaboratively developing soft- rity quickly. The ownership structure also distorts the ware with cloud functions. Additionally, a comparison analysis of the economic viability. Docker Hub, for inof the conceptual ecosystem against existing ones is stance, is operated by Docker, Inc. but does not itself presented, and main reasons about the sustainability generate direct revenue. Instead, it is cross-financed by aspects are included to give answers to the remaining other company operations whose growth is in turn supthree questions. ported by the dominance of the exchange on the market. Another issue is the concentration of providers in ecosystems. For example, images on Docker Hub are 2 Ecosystem analysis prone to several security issues. This situation also affects the officially maintained images from which the For conceptualisation and contextualisation, an issues propagate into derivatives. Any security vulanalysis of the actual software ecosystem environment nerability that could be exploited has the potential is needed. In this section a definition is presented as to affect vast shares of development and deployment well as an analysis of ecosystems current growth and workflows in critical applications as a consequence (Shu obstacles. et al. 2017).
In summary, main identified obstacles and hindrances 2.1 Ecosystem Definition could be single commercial owners and concentration of providers in ecosystems.
In this paper an ecosystem is defined to be an open system consisting of a set of technical elements which enable growth by attracting contributions from par- 3 Value proposition and position ticipants. Among the elements are service-oriented elements (marketplaces, hubs, brokers), as well as This paper propose to strive towards sustainable platforms and further provider and consumer tools. ecosystems for heterogeneous application development artefacts which can be customised for arbitrary do2.2 Growth of ecosystems mains including cloud and mobile applications and so forth. The sustainability will be achieved by deEcosystems can be measured primarily by looking centralisation and abstraction. Arguing that by at provider and consumer metrics which cover both a suitable combination of decentralised ecosystem elthe absolute volume and the growth factors. Yu ements with built-in abstraction capabilities, a longobserves the co-evolution of ecosystems on a wider scale term growth and sustainable operation can be achieved from a provider perspective involving hardware, sys- even in volatile environments with changing technolotem software and software-implemented applications gies and market forces. Users
4.1
Decentralization
Decentralized repositories
Functions Hub Interface
ment where developers could interact with the platform ecosystem in a way that allows them to create, share and trade tools, enabling users to deploy, scale AbAstbrastcrtaiocntiotonols and create functions more easily and efficiently.
In that sense, industry already has some marketplaces from other software ecosystems. For example, GitHub has the GitHub Marketplace, a marketplace where third-party companies create and commercialise integration tools that allow users to work more efficiently with their source code. Additionally, Docker has DockerStore, a place where third-party companies offer plugins and certified containers to docker users.
This allows them to access enterprise solutions and • Decentralisation: In recent years, several appli- create industry-ready applications using the Docker cations on the Internet have become centralised ecosystem. Amazon Web Services (AWS) Marketplace conglomerate services. Yet over longer periods of from Amazon, allows both users and third-party comtime, they may not prevail (DeLegge & Wangler panies to trade tools that uses the AWS ecosystem. At 2017). A decentralised ecosystem guarantees that the time of this writing, only Amazon has a first proin a worst case even when individual market par- totype of a serverless ecosystem with some still basic ticipants vanish, the system will continue to func- features1. tion in reduced form. From the above mentioned example marketplaces, some relevant characteristic that the marketplace should have can be specified: • Abstraction: The right level of abstraction is important. While existing ecosystems have only become successful for technologically specialised artefacts, there is a large spectrum between these and fully generic approaches which can be exploited. This exploitation can be partially automated by converting formats and protocols.
• Enable third-party companies and/or users to cre
ate tools that interact with the ecosystem. • Enable third-party companies and/or users to
commercialise their add-on tools. • A framework that allows users to collaborate with each other within the ecosystem.
To include these characteristics in a serverless ecosystem, the following approach has been establish • Integration with other software platforms (Docker, as shown in Figure 1. For decentralisation, a set of de- GitHub, AWS, among others). centralised repositories that allows users to download, test and use cloud functions directly. These reposito- One characteristic that stands out of these software ries will be connected through a marketplace, where platforms is marketplace centralisation. This could developers will be able to share, deploy and even com- lead to potential software disruptions in case of change mercialise cloud functions. For abstraction, tools to of policies or departure of mayor stakeholders. convert and deploy functions will be used, allowing deployment on a diverse set of cloud providers. 1https://aws.amazon.com/serverless 4.2 Converters Microsoft like C#, F# , JavaScript or PHP. Nevertheless, the field of the deployment of functions does Even deployment-ready applications have to deal with not belong only to private platforms. In this context, syntax associated with each cloud platform. For in- one of the most popular open source cloud platform stance, every serverless cloud platform has its own Ap- is Apache OpenWhisk, that execute functions in replication Program Interface (API), methods and syn- sponse to events, supporting programming languages tax to deploy functions, generating a vendor lock-in like JavaScript/Node.js, Swift, Python, Java and even issue, where users have to create functions for specific implementing Docker logic. cloud providers instead of a general one.
A feasible solution is to automatically add wrappers through a converter, allowing this way developers to 4.5 Interaction and serverless ecosystem create code according to its real requirements, without In serverless architectures, cloud providers have comworrying with the code necessary to make it run on a plete management over the environment in which funcspecific cloud environment. With the advent of mo- tions run. These creates high-level abstract environbile edge computing, this could be a very interesting ments for the users, where they should not worry about approach to federate cloud providers. deployment or maintenance and expects it to be faulttolerant with auto-scaling features (Baldini et al. 2017). 4.3 Deployers This architecture is basically a event-driven computation pattern that promotes loosely couple services and To accomplish a total integration with the industrial ensures a trigger function execution (Stigler & Stigler cloud ecosystem, a flexible tool that allows users to de- 2018). ploy their functions on multiple cloud environments is The interaction between users, interfaces and reposineeded. Most of the tools used in industrial cloud en- tories is given in a way that presents a continuous exvironments are associated to its own platforms. Ama- changing of functions and allows the growth of a marzon Cloud Formation, Google Cloud Deployment Man- ketplace. The interface creates the link between all ager and Azure Resource Manager are examples of lo- repositories and users. Because each repository is percal frameworks that manage the set of resources for its sonal, every user could create a new repository and has own specific platform. the option to share theirs or store functions from other For cloud multi-tenancy, for example, allowing migra- users. As a way of allowing abstraction, every function tion from one cloud provider to another is a key fea- is created as simple as possible, to after that, establish ture. An example of a tool that currently applies this a conversion to match a cloud provider specific requireconcept is the serverless framework2, an open source ment.
Command Line Interface (CLI) for building serverless architectures and event-driven applications, using spe- 4.6 Related ecosystems cific software resources for deployment of functions in a wide set of cloud platforms.
for sharing functions in AWS Lambda is the AWS 4.4 Execution environments Serverless Application Repository. This repository allows users of AWS Lambda to create, share and use To easily create and deploy functions, an execution en- functions on that specific environment. The main vironment has to be set in place. Each cloud provider drawback of this new ecosystem is the vendor lock-in focuses its environment in accordance to an aimed de- issue, because all components are associated with this veloper group or their specific infrastructure. For ex- specific provider, resulting in a centralised non-abstract ample, AWS Lambda supports major programming ecosystem. Additionally, it only allows registration for languages such as Java, JavaScript, Python, C# and users with an associated bank account (credit or debit lately Go. Each of these languages with their most card), difficulting students to access this repository and popular runtimes like Node.js, Java 8, Python 2 and associated functions. 3, but they add extra features allowing users to inter- In contrast, the new approach considered for the proact with the infrastructure. On the other hand, Azure posed ecosystem, let users create their own repository Functions supports major development languages for to share, test and deploy functions. Remembering that 2https://github.com/serverless/serverless functions are created as simple as possible, they could be converted and deployed in different cloud environments, making it easy to create functions associated with a specific product without having any dependencies over a certain provider. 5
ments were implemented to gain insights and knowledge about their actual behaviour and effectiveness. For an implementation, it was focused on an eventdriven application as a subset of the entire cloud application space, due to their alignment with stateless cloud function processing. Furthermore, the use of decentralised open messaging infrastructure was explored. Figure 2 shows the proposed ecosystem to achieve a Function Hub that could help to create a decentralised environments for the serverless ecosystem. 5.1
defines what and how elements are trade within it. In this case, an ecosystem that allows free exchange of functions between users and generates the required environment for a serverless market to proliferate. For this purpose a Function Hub3 was designed considering the following characteristics: • Decentralisation, by using an Extensible Messaging and Presence Protocol (XMPP) for communications, without centralised storage. • Abstraction, by using Snafu4 which allows managing cloud functions across provider convention boundaries.
Additionally, the complete Function Hub ecosystem is composed by four main components: • Users: Users that access the Function Hub Interface5 to share and get functions according to its needs. • Function Hub Interface: It is a website based on AngularJS which runs on a NginX server. Users 3https://github.com/serviceprototypinglab/functionshub 4https://github.com/serviceprototypinglab/snafu 5https://github.com/YessicaBogado/FunHub can search a function by name or specifying other attributes, having the testing option on the same platform and then download functions according to its requirements. For the interconnection between HTTP and XMPP protocols, a message broker named MW 2 was developed. • Decentralisation: In this work, decentralisation is achieved through repositories to store functions and serving as an active server for users. A software named Snafu (Swiss Army Knife of Serveless Computing), a FaaS host process, was used for this task. Snafu was chosen because it fulfils two main characteristics, as an execution environment for functions (active mode) and as a function repository (passive mode). As Function Hub does not pretend to use an unique centralised storage, it communicate with other repositories through XMPP. For this reason, each provider has a XMPP Client account associated to its message broker MW 1 and to its associated XMPP Server for sending data required by users. The use of message brokers allows interconnection between HTTP and XMPP protocols, because both Function Hub and Snafu use HTTP as a main protocol connector. The implementation of the message brokers (MW 1 and MW 2 ) was made through flask and nbxmpp libraries in Python. • Abstraction: The abstraction sector is composed by a basic converter that add all the basic wrappers needed to deploy the function, according to most of the main cloud providers and uses the serverless framework (Collins 2015) as a deployment tool. 5.2
As an early prototype6, a converter of Python functions was developed to add wrappers for different modules that the file could have. It works according to these steps: • It consumes and checks if the function has some run-time code to avoid security issues when importing. • After checking, depending of the choice of the converter user, it dismantles different modules of the file and adds wrappers with the function for each 6https://github.com/walter-bd/faas-converter • It has option to add wrappers for providers like
AW S, OpenW hisk, F ission, OV H and Azure. one on different files or it add the wrapper of one facilitate the deployment on the most popular cloud of this module at the end of a copy of the file. providers. Furthermore, a composeless7 service is being developed to deploy functions on serverless ecosystems or in a container, according to particular needs. • The user can choose wherever to add the wrappers 5.4 on different files for each provider or to add it all together in one file but, it has to manually check for some collisions with other wrappers added.
5.3
vided by the FaaS host process Snaf u, and it’s support different programming languages like C, Java, JavaScript and Python. Snafu is deployed on an Alpine-based docker image, where it has the following run-time environments Python 3.5, Python 2.7, openjdk8, nodejs and for compiling purpose gcc and g + + for C programs.
For deploying functions into the ecosystem, a new func- 5.5 Type of users tionality was needed to be added. This will give users the option to upload their functions from their reposi- In the proposed ecosystem, the interaction is based in tories to the Function Hub ecosystem; hence, for this four kind of users: purpose a Snafu server is used. pTroivdateeplcolyoufdunpcrtoiovnidserfroisminttheendFeudntcotiuosne tHheubsertvoera- • dRoewgnulolaard,usteesrts: oTr hueypluoased thfuenecctoiosnysstetmo taollolowoekd, less framework, because this have already options to 7https://github.com/serviceprototypinglab/composeless repositories. To make this possible, a web interface is available, showing the user all the repositories and its respective functions. • Exclusive repository user: For companies that want to create exclusive functions to their products associated with their own infrastructure.
Function Hub would provide a place where they can share the use of this function, allowing them to decide what to share and what to sell.
need for an ecosystem in order to bring users necessary tools for a fast and cheap deployment of their software. Saini, A. (2016), An extension to UDDI for the disOn that point, Amazon took the first steps, providing covery of user driven web services, in ‘Distributed to their users a serverless repository with basic func- Computing and Internet Technology - 12th Intertionalities. Also, new open source serverless initiatives, national Conference, ICDCIT 2016, Bhubaneswar, like OpenWhisk and Fission, gives developers freedom India, January 15-18, 2016, Proceedings’, pp. 92–96. to create new tools. URL: https://doi.org/10.1007/978-3-319-28034However, and as it was showed in this paper, it is also 9 11 needed properties like decentralisation and abstraction that allows them to create applications that interact with a diverse cloud ecosystem and take advantage of this diversity according to their needs, without worrying when individual market participant vanish. Pointing on that direction, this paper presented a vision for how ecosystems with a decentralised Function Hub may give to developers a way to share their functions, thinking not only on a specific cloud provider but also Stigler, M. & Stigler, M. (2018), Beginning Serverless considering application itself instead. Further discus- Computing, Springer. sion, research and develop is required with the objec- URL: https://doi.org/10.1007/978-1-4842-3084tive of give such ecosystem essential properties like sus- 8 1 tainability, scalability and reliability associated with a wider adoption.
a study of the statistical relations among the growth rates of hardware, system software, and application software’, ACM SIGSOFT Software Engineering Notes 36(6), 1–5.
URL: http://doi.acm.org/10.1145/2047414.2047435