Feasibility of a Function as a Service system as a frontend server for a websit

(1)

NIKO NUMMI

FEASIBILITY OF A FUNCTION AS A SERVICE SYSTEM AS A FRONTEND SERVER FOR A WEBSITE

Master’s thesis

Examiner: Prof. Outi Sievi-Korte Examiner and topic approved by the Faculty Council of the Faculty of Computing and Electrical Engineering on 31st January 2018

(2)

i

ABSTRACT

NIKO NUMMI: Feasibility of a Function as a Service system as a frontend server for a website

Tampere University of Technology Master’s thesis, 42 pages

May 2018

Master’s Degree Programme in Information Technology Major: Pervasive Systems

Examiner: Prof. Outi Sievi-Korte

Keywords: function as a service, platform as a service, cloud computing, AWS Lambda, AWS Elastic Beanstalk

Alma Talent Oy was renewing one of it’s media sites. In this site renewal project whole new tech stack was chosen for the frontend code. Running the site serverlessly in FaaS platform was an attractive possibility.

Function as a service platforms such as Amazon’s AWS Lambda are enabling new ways of thinking and executing code. These services promise to run code in response to events specified by the user. User is billed only when computation in response to an event happens. These services also promise to scale nearly limitlessly in response to amount of requests service is encountering.

These services are also called serverless systems because users do not need to worry about servers. Users have little to no control over servers running users’ code. This is also one of the selling points of FaaS. Only few attributes such as runtime and amount of memory are under users’ control.

New setup with various services from Amazon’s cloud were used to create setup capable of running frontend server in AWS Lambda. This setup was then tested with load tests. Charges relating to the use of this systems were also estimated and then measured when the site went live.

Setup proved successful but more expensive than expected. Main problem cost vice is that the outgoing data is payed twice. From a developers point of view the system is also easy to use and operate.

(3)

ii

TIIVISTELMÄ

NIKO NUMMI: FaaS-palveluiden soveltuvuus verkkosivuston frontend-koodia suorit- tavaksi palvelimeksi

Tampereen teknillinen yliopisto Diplomityö, 42 sivua

Toukokuu 2018

Tietotekniikan koulutusohjelma Pääaine: Pervasive Systems

Tarkastajat: Prof. Outi Sievi-Korte

Avainsanat: Funktio palveluna, alusta palveluna, pilvipalvelut, AWS Lambda, AWS Elas- tic Beanstalk

Alma Talent Oy oli uusimassa yhtä mediasivustoansa. Sivustouudistuksen yhtey- dessä sivuston koko esityspään tekniikka luotiin uudestaan. Yhtenä houkuttava mahdollisuutena esityspään palvelimeksi oli funktio palveluna -alusta.

Funktio palveluna -alustat, kuten Amazonin AWS Lambda mahdollistavat uusia tapoja ajatella ja suorittaa ohjelmakoodia. Nämä palvelut lupaavat suorittaa ohjelmakoodia vastauksina käyttäjän määrittämiin tapahtumiin. Käyttäjää laskutetaan ainoastaan koodin suoritukseen kuluneesta ajasta. Nämä palvelut lupaavat myös skaalata lähes loputtomasti palvelun kohdatessa kuormaa.

Näitä palveluita kutsutaan myös palvelittomiksi järjestelmiksi, sillä käyttäjän ei tarvitse niitä käyttäessään varsinaisesti välittää palvelimista. Käyttäjät eivät pysty vaikuttamaan alla oleviin palvelimiin, sillä palvelun tarjoaja huolehtii niistä. Käyt- täjän saa päättää vain muutamasta asiasta kuten käytössä olevasta ohjelmointikielestä ja muistin määrästä. Huolettomuus palvelimien hoidosta on myös yksi palvelun myyntilupaus.

Esityspään koodin ajamiseksi luotiin uusi järjestelmä, joka käytti monia eri Ama- zonin palveluita, jotta esityspään koodi saatin suoritettua AWS Lambdalla. Tämän jälkeen järjestelmää testattiin kuormakokeilla. Järjestelmän käyttökustannukset arvioitiin etukäteen.

Järjestelmä on toimiva, mutta sen käyttö on odotettua kalliimpaa. Suurin kulujen kanssa on se, että ulos menevä data laskutetaan kahdesti. Kehittäjäkokemuksen näkökulmasta järjestelmä on hyvinkin toimiva.

(4)

iii

PREFACE

I would like to thank professor Outi Sievi-Korte who guided me in writing of this thesis. I would also like to thank Alma Talent Oy who provided the case and the materials used in this thesis.

Helsinki, 20.05.2018 Niko Nummi

(5)

iv

LIST OF FIGURES

2.1 Different layers of a server. Servers consists of hardware, operating system, runtime and applications . . . 6

4.1 First request is handled by the Lambda function. First response contains application code, server side rendered HTML and preloaded data from APIs. Subsequent requests are handled by application code which in run in users web browser. Note that APIs and static assets are behind Amazon CloudFront but that is not depicted in the figure. 26 4.2 Second request and all subsequent requests are handled by the browser.js

in users web browser. Users are not making any requests to AWS Lambda at this point as are interacting with the application running in their own web browser. Application requests assets it does not currently have stored. Note that APIs and static assets are behind Amazon CloudFront but that is not depicted in the figure. . . 26

5.1 Expenses of running frontend server of www.talouselama.fi from 08.2017 to 03.2018 . . . 30 5.2 Availability before the launch of the renewed www.talouselama.fi web-

site. Total of 2 outages that in total resulted in outage of about 2 minutes. Data was gathered using pingdom service and data points are from 18.7.201 6 to 2.10.2017. . . 32 5.3 Availability after the launch of the renewed www.talouselama.fi web-

site. Total of 42 outages that in total resulted in outage of about an hour. Data was gathered using pingdom service and data points are from 3.10.2017 to 21.1.2018. . . 32 5.4 Chart showing latency of medium load test on AWS Lambda with 3

GB of memory. . . 34 5.5 Chart showing heavy load test results on AWS Lambda with 3 GB of

memory. . . 35

(8)

vii 5.6 Plateau in the graph clearly shows when application was returning

404. As application was not able to get data it requires from the API it returned 404 and thus replying to the request quickly lowering the latency. . . 37

(9)

viii

LIST OF TABLES

5.1 Results of medium and heavy load tests. Rusults are medians of latency in milliseconds . . . 35

(10)

ix

LIST OF ABBREVIATIONS AND SYMBOLS

FaaS Function as a Service

CMS Content Management System PaaS Platform as a Service

AWS Amazon Web Services

HTTP Hyper Text Transfer Protocol

HTTPS Hyper Text Transfer Protocol Secure SSR Server Side Rendering

QoS Quality of Service

API Application Programming Interface URL Uniform Resource Locator

IaaS Infrastructure as a Service SaaS Software as a Service

IAM Identity and Access Management

RAM Random Access Memory

CPU Central Processing Unit

vCPU virtual Central Processing Unit GUI Graphical User Interface

CDN Content Delivery Network SSR Server Side Rendering

HTML Hypertext Markup Language SEO Search Engine Optimization SPA Single Page Application SQL Structured Query Language CORS Cross-Origin Resource Sharing VPN Virtual Private Network DevOps Development Operation

(11)

1

1. INTRODUCTION

There are many choices that need to be made when deciding infrastructure for a commercial scale web site. For example, what programming language and frameworks are used, what databases to use, on what infrastructure should the systems run in and so forth.

When considering hosting a website the minimal setup would be serving HTML (Hypertext Markup Language) document from a storage system provided by a service provider. HTML served directly from a source without Javascript that would alter its contents would be optimal for search engine optimization as search engines would not need to execute Javascript.

However, sites that are only HTML can be lacking in functionality. Javascript frontend frameworks execute Javascript code to generate HTML. They also allow for richer user experience. However, if this kind of document served directly from a source would not be optimal for search engines and for some slow devices because Javascript would have to be executed in order to generate the HTML document.

This problem can be solved by pre-rendering the content into HTML document and that content could be stored in a storage system and served from there. This is problematic however because in some cases different content needs to be served to different customers. One pre-rendered HTML document would not thus satisfy the requirements.

Server side rendering remedies the problem as the code is run individually for all requests and after that pre-rendered and sent to the user. There are multiple ways of hosting this kind of a setup and this thesis focuses on one of them.

(12)

1.1. Background 2

1.1 Background

This master’s thesis focuses on suitability of FaaS (Function as a Service) systems as frontend servers. This master’s thesis was written while working for Alma Talent Oy company in one of their media site renewing projects. The renewed site in question was www.talouselama.fi.

In talouselama.fi’s renewal project the whole technology stack was reconsidered.

This reconsideration process offered nice opportunities to look for new and interest- ing technologies that could prove useful in the project. Main aim of the site renewal was to get rid off sluggish development cycle enabled by the old technology stack, mainly caused by the old CMS (Content Management System) system. Other goals were to get rid off vendor locking and to build the site by using widely used modern web technologies.

In addition to choosing programming languages and database engines there was a need to make choices regarding server environments and products to be used from a cloud computing provider. The infrastructure choices were important as the site in question attracts relatively heavy traffic.

1.2 Motivation

Resources in software projects are often limited. Because resources are limited it is crucial that limited resources are spent as efficiently as possible. For example software developers time should mainly be used writing software and not for example by managing servers.

Difficulties of managing server infrastructure were also noticed and largely mitigated in Alma Talent Oy. The mitigation was achieved by using PaaS (Platform as a Ser- vice) cloud services. PaaS services offer many benefits that make server management easier.

After PaaS entry to the market there has been some developments in the cloud computing field. One of the most significant new developments came in the form of FaaS that offer many same benefits as PaaS. FaaS also has its own advantages and disadvantages compared to PaaS.

Function as a service paradigm has great promises. Cloud services offering FaaS

(13)

1.3. Research questions and goals 3 typically make a promise that developers using their product are mainly able to focus on writing code, not on managing servers. This is a bold promise and this master’s thesis explores how accurate this promise is in practice. FaaS platforms also promise responsive and fast scaling in response to a load and their pricing models are attractive.

1.3 Research questions and goals

Research questions:

1. Is it possible to use FaaS as a frontend server?

2. Is FaaS feasable option as a frontend server cost and performance vice?

The goal of this thesis besides answering the research questions is to find out advantages and disadvantages of using FaaS, and to document problems unique aspects relating to this computing paradigm.

Talouselama.fi is a media and news website that covers mainly business related topic.

The website is usually under relatively heavy traffic and it is updated frequently by developers. These premises set some limits to underlying technologies. The underlying server technology must allow for quick development cycles and the site has to serve all readers even under heavy traffic.

The website in question being a commercial product sets some limitations as well.

Because it is a commercial product availability has to be high and this availability should be achieved with reasonable costs.

1.4 Research methods

Thesis uses both qualitative and quantitative research methods and focuses on few selected QoS (Quality of Service) measurements. Measurements where possible ware made from two different frontend server solutions focusing on selected QoS attributes. This part of the thesis forms the quantitative part of the thesis.

QoS attributes were measured from the new implementation running on FaaS platform. Some attributes were also measured on PaaS platform, although program

(14)

1.5. Scope of the thesis 4 running in PaaS was not the same as the one running in FaaS. This was done in order to have some baseline to compare FaaS platform’s performance. Data was also gathered from old www.talouselama.fi where possible.

Main source of data for QoS calculations came from self diagnostics and analytic tools provided by the service provider. In cases where QoS attribute data was not available by the service provider, measurements were made with different tools such as Apache Jmeter. Quality of service measurements and their results are shown and analyzed in chapter 5.

Another method used in this thesis is qualitative research method. Qualitative research part of this thesis focuses mainly on developer experience. Developer experience in FaaS context aims to find out how easy it is to maintain and develop a website program that is to be hosted in FaaS.

Developer experience part of the thesis relies on experiences gathered by me and the team working on www.talouselama.fi project. There were no formal interviews, developer experience was communicated via informal chatter among the team and written down on this thesis.

1.5 Scope of the thesis

The FaaS platform this thesis focuses on is AWS Lambda. AWS Lambda was selected because Amazon’s cloud computing service AWS (Amazon Web Service) is heavily used in Alma Talent Oy. The scope of this work is limited to AWS Lambda and Amazon’s cloud because it is not practical to use many cloud computing providers at the same time. Using many providers is not practical because every service has their own limitations and they each have a learning curve. Also some backend services were already built using AWS so changing to another service was not a practical choice.

An alternative choice for running frontend code in www.talouselama.fi project was Amazon’s PaaS service AWS Elastic Beanstalk. AWS Elastic Beanstalk is widely used within the Alma Talent Oy. Alma Talent Oy uses AWS Elastic Beanstalk service to host other media sites. As a proven solution it was known to be working for this particular use case. It has many advantageous features that allow services to scale and to run various types of software code written in any programming language available.

(15)

1.6. Structure of the thesis 5 Because it was unclear whether or not AWS Lambda was a suitable option to host a web application of this scale it was required that the www.talouselama.fi web application was designed in a way that it could be run in both AWS Elastic Beanstalk and AWS Lambda. Because of this interoperability, AWS Elastic Beanstalk was used as a comparison tool to compare against AWS Lambda’s features.

This thesis focuses on cloud computing services that execute frontend code which is then sent to the user. This thesis mainly ignores other servers needed for the media site. For example servers needed for running backend code are ruled out of this thesis’ scope.

1.6 Structure of the thesis

The Second chapter focuses on theory behind the thesis. It describes what servers are and how they are used in web environment. Second chapter also describes what QoS means and how those attributes are calculated. Also main concepts behinds FaaS and PaaS such as different kinds of virtualization are covered.

The Third chapter focuses on specific aspects of AWS Lambda FaaS platform. It describes properties of AWS Lambda and also advantages and disadvantages of using the system. Third chapter also lists and describes limits enforced on AWS Lambda by the service provider.

The Fourth chapter focuses on technical implementation of www.talouselama.fi website. Chapter covers also why certain technical choices were made and how they affected the whole project.

The Fifth chapter focuses on results of the projects and their analysis. Metrics from different implementations are compared to each other where possible.

The Sixth and final chapter of the thesis focuses on conclusions. Final chapter aims to answer research questions of the thesis and also to further contemplate if the FaaS implementations are something to pursue also in the future.

(16)

6

2. THEORY

Applications that are hosted in the internet are called web applications. Web applications depend on two way communication between the client and the server. Client can be anything from a mobile device to another server. In this thesis client refers to a web browser if not otherwise specified.

Servers respond to requests made by clients. Servers run purpose built software that enable them to respond to clients requests. Servers can in turn become clients if they have to request resources from other servers. Servers usually communicate with other resources such as databases or APIs (Application Program Interface) in order to serve clients request.

Traditionally all aspects of server were managed and maintained by by the user.

This can be very costly because of the different skill sets required to handle all aspects of server management and maintaining. Fortunately there has been many advancements such as various kinds of virtualization that have carried the field forward. Nowadays many if not all of aspects of running a server can be bought as a service from service providers [1].

Figure 2.1 Different layers of a server. Servers consists of hardware, operating system, runtime and applications

(17)

2.1. Server 7

2.1 Server

Servers consist of harware, an operating system, and the software. Sofware can be further divided into two parts: runtime and application. Diffferent runtimes are needed for running different software. For example, running a javascript application requires node.js runtime. Illustration of different server layers can be found in figure

2.1 [1].

Web servers are servers that process requests made to them via HTTP or HTTPS protocols. In traditional server environments there are no restrictions on the type of code that can be executed to produce a response.

A traditional web server listens to a port. Web servers start listening to a port after their start up and continue to do so until they are shut down [2]. Clients make HTTP requests to that port. Usually there is a dedicated web server software running in front of the actual application that produces the response. Using proxies in web servers allows for better handling of incoming traffic.

Routing also takes place in a web server. Users requests to different paths requires different parts of the program to be executed. Routing reads requests URL (Uniform Resource Locator) in order to determine correct part of the program to be run. After correct part of the code has been executed server responds to the client with correct response [3].

After the web server has received an HTTP request it executes code and responds to it via HTTP response. This response follows HTTP format and contains response headers and the response body. Response header includes information about the response such as status, content-type, size etc [4].

Web servers response body contains resources requested by the user if server was able to provide them. This response can contain other kinds of data. In example front end server of a website responds with HTML documents that can be parsed by clients browser. HTML documents can contain references to other resources as well which are in turn fetched by users browser in order to render the page as intended.

HTML pages can also contain executable Javascript code that is executed by the clients browser. [5]

(18)

2.2. Cloud computing 8

2.2 Cloud computing

Cloud computing is a paradigm in which server capacity and related software services are bought as a service from service provider [6]. Cloud computing has many benefits over traditional self hosting. These benefits include for example: scalability, availability, reliability and costs [1].

These benefits are achieved by having service providers that have a large user base and thus have bigger resources available to them to provide quality cloud computing services. SaaS (software as a service) and APIs are also a big part of modern cloud computing. Although some services that big cloud computing services provide have open source counterparts, it is still rather difficult for a small service provider to compete against larger providers. There are multiple large corporations such as Microsoft, Amazon and Google offering their own cloud services to customers [6].

Cloud computing service providers are not just offering infrastructure, they are in- creasingly offering more complicated services that abstract many layers of traditional server. In some services the server itself is abstracted and many services offer little to no control over server or its setup in general.

Software as a Service (SaaS) is a cloud computing paradigm in which software is served as a service. Typical SaaS applications are end-user programs commonly used via web client. SaaS applications are widely used in the field of productivity applications such as Microsofts Office 365 or Google’s suite of productivity tools.

Different cloud computing paradigms can be divided into different categories depending the level of abstraction: IaaS (Infrastructure as a Service), PaaS (Platform as a Service), FaaS (Functions as a Service) and SaaS. [2] [7].

Cloud computing is also creating a uniformed way of doing parts of the sofware infrastructure as different clients use same services provided by the cloud computing service providers. This creates big opportunities as smaller companies have access to same technologies and software that bigger companies also use. Cloud computing services have a relative low barrier of entry as many services are billed by usage and as cloud computing services gain popularity their community support gets better as well.

(19)

2.2. Cloud computing 9

2.2.1 Infrastructure as a service

Infrastructure as a service is a model in which clients buy virtual infrastructure from a service provider. This virtual infrastructure is then configured and set up by the client or by a third party in order to run software.

In IaaS, the client loses control over the hardware but is still in control of the overall software stack as that is not provided by the service provider by default. The client still has to have technical expertise to operate these kind of servers as only infrastructure and its baseline security is handled by the service provider. [8]

IaaS may be preferred by companies in comparison to own servers because of its payment model. There are no large upfront costs of buying required components and the staff to install them. It is also easier to scale up or down virtual servers as you can buy more or less of them depending on the situation. [8]

It can also be the first step company takes on a path to using more cloud computing services. Old legacy systems can be brought into IaaS and companies can shut down or reduce their own datacenter operations.

2.2.2 Platform as a Service

Platform as a Service is a cloud computing model in which infrastructure, operating system and runtimes are combined with load balancing and scaling into a platform which is provided as a service to users. In the PaaS model services provided by the platform reduce the amount of configuration needed to make software run properly if compared to IaaS model. All main cloud computing service providers have their own PaaS platforms [9][10][11]. There are also open source PaaS options such as OpenStack Horizon and Magnum [12]

Supported programming languages vary by different service providers. Although many different programming languages are supported all main platforms support use of containers as well [9][10][11]. Containers support all programming languages available as any runtime can be provided by the user.

PaaS services abstract many functions of server such as: networking, operating system management, security updates and deployments [12]. Although many aspects

(20)

2.2. Cloud computing 10 of the server are abstracted, PaaS services can still require complicated configuration scripts in order to configure them to suit the need of the running application.

Configuration scripts can, for example configure how application auto scales [13].

Although PaaS allows users to have some access into underlying operating system and make changes there is a need to use special tools provided by the platform in order to accomplish this. Those special platform specific tools are required because when platform scales applications it creates new virtual machines. For example, Amazon Elastic Beanstalk uses .ebconfiguration files to configure environments before creating a new virtual server [14].

2.2.3 Function as a Service

Function as a Service or serverless computing is a cloud computing paradigm in which much of the underlying computer system has been abstracted [7]. As the underlying system has been abstracted user has little control over it. Lack of control has its advantages and disadvantages. Major difference between FaaS and PaaS is the ease of scaling as FaaS platforms scale without any configuration [15]. All major cloud computing provides have their own FaaS platforms [16][17][18][19], also open source implemantations exist such as OpenLambda [20].

Use of FaaS has created a new cloud computing model called serverless computing [7]. Serverless computing means that application code is split into functions and those functions are executed in response to events. Events are created and processed by other services in service providers cloud computing environment [21], thus further abstracting the actual logic that invokes serverless functions.

FaaS and PaaS have their differences which need to be accounted for in the programming code. In FaaS, code execution in response to cloud events requires new paradigms of software construction [2]. In addition to the code splitting between different serverless functions some additional changes to the codebase are required.

Platforms invoke serverless functions when needed and this differs from how traditional programs are run. Software originally coded to run on other cloud computing paradigms such as IaaS or Paas or in a physical hardware need changes in order to run in FaaS platforms [22].

In the most purest form serverless functions are small snippets of code that are meant to do one thing. This means that in order to complete a larger application

(21)

2.3. Virtualization 11 many smaller functions are used in tandem in a modular fashion. Each of these functions has a different role and together they form a larger application. Design and programming of an application has to be done with modularity in mind if the application in question wants to take full advantage of serverless computing.

Routing is handled by other services running in the service providers cloud. This means that the way programs are designed and programmed differs from how design and programming works in the IaaS/PaaS/physical hardware world. However, serverless programming offers many of the same benefits when used with traditional ways of design/programming as well.

FaaS platforms charge for the actual use [16][17][18][19], in contrast to resource allocation of IaaS and PaaS. Actual costs and how they are calculated differ slightly by the platform, but in general the number of invocations and the time it takes for a serverless function to complete determines how much the user is billed. Hardware running the serverless function also contributes to the costs.

There are other costs related to the use of FaaS platforms that come from the use of other services. Those other services are needed in order to create events that invoke functions running in FaaS platform. These indirect costs may even be higher than the cost of using FaaS platform itself. Because functions running in FaaS services need to be invoked in order to be used these costs have to be taken into account when calculating the total cost of using FaaS [22].

Software updates to underlying servers in FaaS services are handled by the service providers [23]. This is hugely beneficial feature in situations where major security risks and other faults in software or hardware are discovered. The end user does not need to worry about their software stack being up to date as the service handles it for the user. This has a benefit that all the updates are handled by service providers experts which eliminates problems and errors made by the user when deciding what to update and when. As there is no need to manually update servers DevOps (Development Operation) costs are also relatively low.

2.3 Virtualization

Virtualization is a broad group of methods that aim to mitigate problems related to physical machines and systems running computer software [24]. Virtualization is a base technology which enables cloud computing services as we know them.

(22)

2.3. Virtualization 12 Server virtualization is a group of different methods that aim to mitigate shortcom- ings of traditional servers. As the name suggests, virtualization virtualizes software and hardware in order to use computing resources more efficiently. Virtualization brings other benefits as well: it decouples certain links between different layers of a server. This brings out benefits such as faster deployment times, isolation, and added fault tolerance. These factors add to reduced costs and improved manageability [1].

There are multiple methods of virtualization, hardware-based, software-based and container-based [24]. Lambdas are a specific case of container based virtualization.

Different types of virtualization differ on how many layers of the underlying server have been shared between applications running on the server.

2.3.1 Hardware-based virtualization

In hardware-based virtualization emulating software creates its own virtual hardware that uses resources of the underlying machine but contain own operating systems, runtimes and applications. The actual hardware is shared between different virtual machines running on the same machine. [25]

Hardware-based virtualization enables more efficient use of the server hardware as many virtual servers can be run side by side on a real hardware. This also enables more increases in availability and security [26]. Virtual machines can be rebooted without affecting others virtual machines running on the same hardware.

Hardware-based virtualization has advantages but it has downsides as well. It is slow to scale because creating a new virtual machine with its own operating system takes a relatively long time. This is not a problem for applications that do not need to scale but for applications such as application backends that may suddenly receive large amounts of requests it is problematic.

The virtual machine is configured to use some amount of resources when it is created.

In order to change those limitations virtual machine needs to be reconfigured and rebooted.

(23)

2.4. Quality of Service 13

2.3.2 Software and container virtualization

In software-based virtualization, virtual machines are created on top of a host operating system. These virtual machines have their own operating systems and they are called guest operating systems. [24]

Container-based virtualization is a method in which applications run in isolated containers. These containers use different methods such as namespaces to isolate applications running in containers. This means that applications running in the same machine in their different containers can not interact with each other directly.

[27]

Container-based virtualization can be run on virtual machines. This means that all benefits of harware-based virtualization can also be applied to container-based virtualization. It has its own benefits as well. Because containers do not create a new operating system and provision resources like hardware-based virtualization when a new container is created, scaling becomes much more practical.

Typically containers are quick to setup, although their deployment time depends on the software run on the container. Containers may also install some extra software that is not provided by the machine running the container. [27]

2.4 Quality of Service

There are many quality aspects that need to be considered when making a web service. Quality of Service (QoS) is a term used to measure quality of a functionally similar services [28].

Services with good QoS are more likely to retain users. Bad QoS services have a hard time retaining users as there are others with better quality. In the case of www.talouselama.fi, QoS requirements were high because of the commercial nature of the site. In addition, the old website did not have any major QoS problems as main motivations for the site remake came from other aspects.

Different server platforms and services have differences on how well they are able to fulfill these requirements. Different platforms and services also have different costs related to them and that needs to be taken also into consideration. A platform with good overall QoS is thus preferred.

(24)

2.4. Quality of Service 14 There are many ways to measure quality of a web service [29]. Following quality requirements were considered when the www.talouselama.fi service was designed and developed: latency, availability, scalability, and execution price.

2.4.1 Response time

Response is the time the server takes to respond to a request. It takes into account things like network latency and execution time of the code. It can be calculated as a sum of latency and execution time [28].

It is possible to optimize response time by making the size of the response smaller and thus making the response time lower by having less data to deliver via interned.

It is also possible to reduce execution time by using more computing power or by making optimizations to the application code. Only latency measurement was used for response time as opposed to calculating it as latency plus execution time.

2.4.2 Scalability

Scalability tells how fast the service can provision or delete instances to meet increased or decreased load to the server. The optimum would be a service that scales up and down instantly without any extra costs.

Services that are slow to provision new instances may actually be doing more harm than good to the system as a whole. This harm may be achieved in a situation in which service is slow to provision and the traffic increase is short lived. Thus the peak may already be over when the new server is up and running and thus accumulates costs for no reason.

2.4.3 Availability and accessibility

Availability and accessibility are closely related metrics. They measure if the users are able to access the service. Availability focuses on the time service has been available to the users. Accessibility on the other hand focuses on the number of successful requests.

(25)

2.4. Quality of Service 15 Availability can be calculated by dividing services uptime with total time the service has been live. Availability should be as close to 100% as possible. Accessibility can be calculated by dividing number of successful requests by total number of requests.

2.4.4 Execution price

Although price usually is not the main driving factor when considering QoS one has to take it into account. Good quality achieved with massive costs is not preferred.

Usually there needs to be some balance between the two. Execution price includes server costs and at least software licences. Operating and development costs can also be included.

Execution price also depends on usage of the service. Price per execution becomes lower if the same resources can be used more effectively. For example, if a server has enough capacity to handle more request, more request does not necessarily increase costs.

(26)

16

3. AWS LAMBDA

AWS Lambda is a FaaS service that only executes code in response to events in AWS.

Programs that are run on AWS Lambda are called Lambda functions. Lambda functions are run in their own isolated containers.

AWS Lambda differs from a traditional server in many ways. It can only run a limited set of runtimes and it has limited computing resources. Lambda functions offer many advantages, such as scaling and minimal operation and configuration needs compared to running own servers or even buying server platform as a service.

3.1 Programming model

Programming Lambda functions differs slightly from running your program in its native runtime environment. The system calls a predetermined handler function in users code to start Lambda functions execution [30]. Handler function is determined by the user in Lambda functions settings. Handler function accepts two mandatory parameters event and context, which carry information of about the incoming invocation. Handler function for Javascript Lambda function shown in listing 3.1

1 // AWS L a m b d a s e t u p 2

3 e x p o r t s . h a n d l e r = ( event , context , c a l l b a c k ) = > { 4 // Do s o m e t h i n g

5 }

Program 3.1 AWS Lambda calls users Lambda function via handler function that locates in users code. Users can rename their hander function.

The programming model sets some requirements to user’s code but all the features of selected programming language are available. Users can use external libraries but those libraries have to be uploaded by the user. Logging statements can be used but in order to see them another AWS service called CloudWatch has to be used.

(27)

3.2. Invoking Lambda functions 17 Programs running in AWS Lambda also have to be mainly stateless. This is because the platform does not guarantee that sequential requests end up in same individual Lambda function instance. Each instance has a temporary folder in which the programs can store information between invocations. Because requests can end up in other instances, user’s can’t build any significant program logic relying on this feature. Stateless nature of Lambda functions in part enable Lambda functions to scale. [30]

If function needs a state to persist across invocations other services provided by the platform are needed. AWS has many such services for example Amazon S3 storage or AWS Dynamodb database can be used. Lambda functions need to have correct access rights in order to access other resources within the AWS ecosystem. These credentials are called roles in AWS and can be modified and created via AWS IAM (Identity and Access Management).

3.2 Invoking Lambda functions

Running the code in a Lambda function in response to some event is called a function invocation. These invocations can be triggered by multiple AWS services such as S3 or Dynamodb [30]. Lambda function invocations only happen in response to some event. For example, saving a document to Amazon S3 storage service can be configured to trigger Lambda function invocation.

When running a Lambda function as a web application the only practical way to invoke Lambda functions is to use Amazon API Gateway service [22]. API Gateway acts as a bridge between users requests and the server application not unlike nginx works on a traditional HTTP server environment for example.

3.3 Supported programming languages

Currently AWS Lambda supports Javascript, Python, Java, Go and C# programming languages [31]. Fortunately these languages are well suited for web development.

Runtime versions are also a factor that needs to be considered. AWS Lambda does not currently support newest versions of its supported programming languages and

(28)

3.4. Resource limitations 18 it has been sluggish to update them in the past. This sets some limits to what programming language features can be used. At least in Javascript this problem can be somewhat mitigated by using compilers that transpile newer specification Javascript code to older specification code.

3.4 Resource limitations

AWS Lambda functions have limited computing resources. Only option to control computing resources on AWS Lambda is the amount of RAM (Random Access Memory) function can use. The amount of RAM however directly controls how fast the CPU running the code is. So by choosing bigger amount of RAM one also chooses a faster CPU. Maximum amount of RAM that can be chosen is 3 GB. [32]

Execution time is limited to a maximum of 300 seconds. This means that execution of a Lambda function has to complete within its given timeout time. If a function has not completed by its timeout time then it is terminated by the AWS Lambda service. [32]

Payload size of the incoming requests is also limited to either 6 MB or 128 KB depending on the type of a request. Also disc space in the /tmp folder is limited to 512 MB. [32]

There is also soft limit to how many concurrent Lambda functions can be executed at a given time. Currently this limit is set to 1000 concurrent executions shared across all Lambda functions under same AWS account. This limit can however be lifted via AWS’s customer service. [32]

There is also a restriction on how big the Lambda function code can be. Currently this is set to 50 MB. This size limit has to encompass the whole application that is to be run on the AWS Lambda service. Application code is however zipped which helps in keeping the deployment size under the limit.

3.5 Scaling

AWS Lambda scales to handle all incoming events. This means that AWS Lambda creates new instances of the Lambda function and runs them concurrently in order to handle all incoming events. In theory there are no limits to how many concurrent

(29)

3.5. Scaling 19 Lambda functions can be run at one time. However, there is a soft limit that can be increased via customer service.

Scaling of the Lambda function requires no configuration at all from the users per- spective. AWS Lambda service handles all the required infrastructure and software components and as such offers great benefits compared to, for example PaaS services.

New Lambda instances are also created quickly, and thus there is virtually no increase in latency when scaling up. Even under a constant increase in load users should not experience increase noticeable increase latency [33].

Even when the system has no instances running it takes a few seconds to complete the request [34]. Few seconds of request time is acceptable in web environment and this only happens if the request handled by a new instance that is just being created by AWS Lambda.

Even if there is no traffic the AWS Lambda keeps functions ready to accept events for some time before making them inactive. Chapter five contains detailed measurements of AWS Lambdas ability to scale.

AWS Elastic Beanstalk is also capable of scaling. However, the way AWS Elastic Beanstalk scales is different compared to AWS Lambda.

AWS Elastic Beanstalk has multiple generations of instances. Instance generations have different ways of scaling. This comparison is between T2 generation of AWS Elastic Beanstalk instances and AWS Lambda. T2 is chosen because it is latest instance generation and it is cheaper and better supported than legacy T1.

T2 instances have two methods of scaling compared to AWS Lambdas one. Each T2 instance has a guaranteed baselevel performance. However, when the load increases on these instances they are capable of bursting their performance above the baselevel.

Performance boost is limited by CPU (Central Processing Unit) Credits that are earned by having the systems load at the level where baselevel vCPU (virtual Cen- tral Processing Unit) performance is enough. Each CPU credit corresponds to one minute of 100% vCPU use. When instance runs out of CPU credits instances CPU performance is limited to baselevel.

Another way for AWS Elastic Beanstalk instances to scale is increasing the amount

(30)

3.6. Creating and updating AWS Lambda functions 20 of running instances. Increasing the amount of running instances can be cumber- some because it does not react quickly as boosting CPU performance. Furthermore AWS Elastic Beanstalk offers multiple options on which to trigger the increasing instances. This offers more flexibility but in turn can increase risk for misconfig- uration. Elastic Beanstalk also requires preset limits on maximum and minimum number of instances.

3.6 Creating and updating AWS Lambda functions

Lambda functions are simple to set up. Only few clicks are required to create a Lambda function with required runtime, memory and maximum execution time.

Once the Lambda function has once been created it does not need to be created again when the code running in the Lambda function changes.

AWS Lambda functions store the code to be run in Amazon S3 buckets. Updating can be done either manually via AWS management console GUI (Graphical User Interface) or via command line tools. The simplest way to update code is to manually zip the application code and upload it via management console. [35]

Updating a Lambda function can be automated. For example, it is possible to create a script that uploads Lambda functions code to Amazon S3 bucket and instructs Lambda function to update itself with a code from that bucket as shown in code listing 3.2.

1 # B u i l d for L a m b d a

2 npm run b u i l d _ l a m b d a _ $ { E N V I R O N M E N T } 3

4 # C r e a t e l a m b d a d e p l o y m e n t p a c k a g e ie . zip s e r v e r . js 5 cd d i s t _ l a m b d a /

6 rm - f $ { D E P L O Y M E N T _ P A C K A G E }

7 zip $ { D E P L O Y M E N T _ P A C K A G E } s e r v e r . js 8 cd ..

9

10 # C o p y z i p p e d s e r v e r . js to s3

11 aws s3 cp d i s t _ l a m b d a / $ { D E P L O Y M E N T _ P A C K A G E } s3 :// $ { S E R V E R _ S 3 _ B U C K E T }/ $ { D E P L O Y M E N T _ P A C K A G E } || e x it 4

12

13 # C o p y b r o w s e r . js to s3

14 aws s3 cp d i s t _ l a m b d a / b r o w s e r . js s3 :// $ { B R O W S E R _ S 3 _ B U C K E T }/ s t a t i c / b r o w s e r . js - - cache - c o n t r o l max - age =60 || e x i t 4

(31)

3.7. Pricing 21

15

16 # C o p y r o b o t s . txt to s3

17 aws s3 cp r o b o t s . $ { E N V I R O N M E N T }. txt s3 :// $ { B R O W S E R _ S 3 _ B U C K E T }/

r o b o t s . txt - - acl public -r e a d || e x i t 4 18

19 # U p d a t e new c od e to l a m b d a f u n c t i o n

20 aws l a m b d a update -f u n c t i o n- c o d e --f u n c t i o n- n a m e $ { L A M B D A _ F U N C T I O N } - - s3 - b u c k e t $ { S E R V E R _ S 3 _ B U C K E T } - - s3 - key $ { D E P L O Y M E N T _ P A C K A G E }

|| e x i t 4 21

22 # M e s s a g e to s l a c k

23 c u r l - X P O S T - H ’ Content -t y p e: a p p l i c a t i o n / json ’ \

24 - - d a t a " {\ "t e x t \" :\ "G o o s e p a i v i t t y y y m p a r i s t o s s a $ E N V I R O N M E N T .\ n \" ,

\ "u s e r n a m e \" : \ "G o o s e \" , \ "i c o n _ e m o j i \" : \ ": g o o s e :\" }} " \ 25 h t t p s :// h o o k s . s l a c k . com / s e r v i c e s / xxx

Program 3.2 Deploying Lambda function to AWS Lambda. Deploying to AWS can be automated with few command line commands.

3.7 Pricing

AWS Lambda’s pricing consists of two parts: number of executions and duration of the execution time . Duration is rounded to nearest 100ms. Amazon offers free usage of AWS Lambda: first one million requests are free and depending on memory usage some amount of computing time is also given for free. [36]

Lambda’s payment model is attractive in some use cases because the billing happens only when Lambda functions are being executed. The cost of using AWS Lambda differs by the amount of RAM chosen for a Lambda function and also on the amount of executions and their duration [31]. This means that AWS Lambda should be exceptionally well suited for applications where high availability is required but relatively low number of requests are actually executed.

Lambda is also well suited for applications which need to scale up and down often because by using AWS Lambda there is no need to have extra servers as a reserve to handle quickly rising amount of requests.

Lambdas payment model can be somewhat misleading because in order to use AWS Lambda some other AWS service is always required. These other services may have costs of their own that increase total amount of costs related to using AWS Lambda.

(32)

3.7. Pricing 22 In www.talouselama.fi AWS Api Gateway was used to pass users requests to Lambda function.

AWS API Gateway charges by two metrics: number of calls made to it and by outgoing data. Outgoing data is measured and depending on the usage prices differ on how much data has to be transferred. [37]

Cost per invocation can be calculated by adding all the charges relating to an invocation together. Cost per invocation can be a handy parameter in a commercial application where for example ad revenue per pageload can be estimated.

Amazon offers a cost calculator for users to estimate their cost of using AWS platform [38]. AWS’s calculator does not however include AWS Lambda nor AWS Api Gateway which are key contributors for costs in using AWS Lambda as a frontend server. Total cost related to frontend solution can be calculated with equation 3.1 where C_t is total cost, C_l is cost of AWS Lambda, and C_a is cost of AWS Api Gateway. Cost calculation do not take into account CDN costs as same data would be cached in CDN with other solutions as well.

C_t =C_l+C_a (3.1)

Total cost of AWS Lambda can be calculated with equation 3.2 where C_e is cost per execution, E_c is number of executions, C_t is price per 100ms, and t is time of executions in milliseconds.

C_l=E_c(C_e+ (C_t∗t)) (3.2)

Total cost of AWS Api Gateway can be calculated via equation 3.3. Where A is number of API calls, C_c is price per million API calls, D_o is outgoing data in gigabytes, and C_o is cost of outgoing data per gigabyte.

C_l = ( A

1000000 ∗C_c) + (P e∗T) (3.3) Calculations are performed with following assumptions: www.talouselama.fi will have approximately 2 million pageviews per month, each execution takes 500 mil-

(33)

3.7. Pricing 23 liseconds to complete, and outgoing transfer amount will be 700 KB per hard pageload.

Prices for AWS Lambda execution are at the time of writing 0.0000002$ per execution and price per 100ms of execution time is 0.000002501$. Cost per 100ms changes depending on the amount of memory chosen for the Lambda function. Prices were for Lambda functions with 1536 MB of memory.

Prices for AWS Api Gateway are at the time of writing 3.5 $ per million api requests.

Price for out transferred data is 0.09$ per GB. Rates for outgoing data depend on the amount as the rate lower the more data is transferred. However, in this application the first tier of 10 TB should be enought.

With these assumptions and prices the cost estimate for AWS Lambda is 25,01$.

Estimate for AWS Api Gateway is 133$. Total cost estimate for frontend solution is 158,01$. Cost of AWS Lambda would then be only about 16% of the total estimated cost and AWS Api Gateway around 84%.

(34)

24

4. TECHNICAL IMPLEMENTATION

AWS Lambda was chosen as the main option for running the www.talouselama.fi web site. Using Lambda brought its own challenges because Lambda itself is not suitable as a web server without using other AWS services to connect it to the internet [22]. AWS Lambda needs other services such as AWS Api Gateway and AWS CloudFront to function properly as a web server. These services are needed in order to route requests and cache responses from various sources. See figure 4.1 for more info.

Also there are some aspects of running a web server that are not practical to do with AWS Lambda. For example, serving static assets such as fonts and icons is not suitable for AWS Lambda. Static assets in www.talouselama.fi are stored in Amazon S3 bucket and routing to them is handled by Amazon CloudFront CDN (Content Delivery Network) service.

4.1 Applications infrastructure in general

All request to the www.talouselama.fi application are first processed by CDN (Ama- zon CloudFront) that handles the routing of main static assets. It directs the requests made by the application to the right endpoints. It also enables caching. Same content required by many users do not always require underlying APIs to execute code because similar content already exists on Cloudfronts cache, and can be thus served from there. Although many assets are cached, the www.talouselama.fi web applications responses are not cached because the site has login features. Cloudfront however directs all traffic with certain characteristics to AWS Api Gateway.

Requests that end up in AWS Api Gateway then invoke the www.talouselama.fi web application being run in AWS Lambda as a Lambda function. This invocation causes applications Lambda function to execute and results of that execution are sent back to the end user.

(35)

4.1. Applications infrastructure in general 25 When www.talouselama.fi is deployed the web application is divided into two slightly different bundles: server.js and browser.js. Different bundles are created with a javascript bundler called webpack [39]. Server.js is executed by the Lambda function and browser.js is executed in clients own web browser. Server.js and client.js differ only by one file that handles the entry point logic.

When a user makes a request, user is served with the results of server.js execution.

After the initial requests to Lambda function all users following actions are handled by the browser.js in clients web browser.

Server.js contains the same logic as browser.js because the project uses SSR (Server Side Rendering). SSR has many benefits because it pre-renders the site and thus user receives a nearly complete version of the requested site on the first page load.

As users receive pre-rendered HTML their device does not have to execute Javascript code in oder to see the site as intended. Because much of the computing is done by the server the user experience with lower compute power end user devices is better when compared to sites not using SSR [40].

Without SSR the server could have been just a dummy server serving static files.

SSR rendering also provides SEO (Search Engine Optimization) benefits because crawlers reading the web page receive fully processed HTML markup [41] [40].

Using SSR has also a nice side benefit: the site works even if the user has disabled execution of Javascript in the web browser. SSR in www.talouselama.fi project processes also styles so the site is almost fully functioning before the client side code in browser.js has been downloaded and executed.

Client side code in browser.js handles everything after the initial response from the server as depicted in figure 4.2. For example, if a user navigates to another article in the site browser.js fetches all the data required from APIs to show user right content. No requests to Lambda function are made after the initial first load.

This means that the page and code is actually loaded only once from the server.

Every action user takes after the initial load only changes the users view via code executed in clients browser. These kinds of applications are called SPA (Single Page Application) applications [42].

(36)

4.2. Development 26

Figure 4.1 First request is handled by the Lambda function. First response contains application code, server side rendered HTML and preloaded data from APIs. Subsequent requests are handled by application code which in run in users web browser. Note that APIs and static assets are behind Amazon CloudFront but that is not depicted in the figure.

Figure 4.2 Second request and all subsequent requests are handled by the browser.js in users web browser. Users are not making any requests to AWS Lambda at this point as are interacting with the application running in their own web browser. Application requests assets it does not currently have stored. Note that APIs and static assets are behind Amazon CloudFront but that is not depicted in the figure.

4.2 Development

Because of the closed nature of AWS Lambda and lack of official local development tools for the platform it was decided that local development environment would be express library for Node.js. Express is a web application framework [43] that acts

(37)

4.2. Development 27 as an interface between application code and requests from the internet. In this project Express was used as a simple web server library.

Using Express library meant that the code running in AWS Lambda would be different than the one running in the local development environment. The code difference of AWS Lambda and Express versions of the application are only few lines of code.

The code that was different between the versions focuses on getting the request’s path from Express libraries or AWS Lambdas API. Main differences can be seen in listing 4.1.

1 // AWS L a m b d a s e t u p 2

3 e x p o r t s . h a n d l e r = ( event , context , c a l l b a c k ) = > { 4 // Do s o m e t h i n g

5 } 6

7 // E x p r e s s s e t u p 8

9 i m p o r t * as e x p r e s s f r o m ’ e x p r e s s ’ 10

11 c o n s t s e r v e r = e x p r e s s () 12 c o n s t P O R T = 3 0 0 0

13

14 s e r v e r . use (’ / s t a t i c ’, e x p r e s s . s t a t i c (’ d i s t ’) ) 15 s e r v e r . use ( e x p r e s s . s t a t i c (’ p u b l i c ’) )

16

17 s e r v e r . use (( req : e x p r e s s . Request , res : e x p r e s s . R e s p o n s e ) = > { 18 // Do s o m e t h i n g

19 }) 20

21 s e r v e r . l i s t e n ( P O R T )

Program 4.1 Main differences between AWS Lambda and Express setups

AWS Lambda has unofficial emulators and even frameworks that try to imitate AWS Lambdas behaviour. Using one of the emulators or frameworks was deemed to be too complex for this project. Main reason for not opting to use emulators or frameworks was the fairly traditional internal working of the program. For example, internal routing was handled by the application itself not by AWS API Gateway.

Running the application in Express locally also provided an easy fallback to a more traditional way of hosting a web application. If problems that were not anticipated

(38)

4.3. Deployment 28 with AWS Lambda would have occurred, www.talouselama.fi web application with Express solution could have been run in AWS Elastic Beanstalk without modifica- tions.

4.3 Deployment

Because of the nature of AWS Lambda, deployments to various environments became really fast. Lambda functions can be updated by uploading compressed application code to Amazon S3 bucket. After the upload has been done Lambda is instructed to use uploaded code from that S3 bucket. This can be accomplished within seconds depending on the size of deployment package. The size of the deployment package was just 441 KB when zipped so the upload time is not a factor on modern internet connections.

4.4 Monolithic nature of the application

Talouselama application is run inside a single Lambda function. The application could have been built by using all the various tools AWS provides. For example, routing could have been done by creating multiple different routes with API Gateway and by splitting code needed to accomplish each task. However, this paradigm of programming would have required use of a framework such as Serverless Framework to keep the application organized.

A framework would have been needed because changes to application would have required changes to API Gateway and other AWS servicess as well. Those changes would have been difficult and slow to make and to maintain if they would have been made via graphical user interface of the AWS.

By using traditional programming methods and by running the whole code inside a Lambda function some shortcoming of the Lambda platform were avoided. Run- ning only as a one Lambda function allowed the project to have minimal cloud infrastructure setup.

This one function approach had other benefits as well. Team building the application did not have to spent a lot of time learning a new framework to work with, cloud setup was minimal, fallback to Elastic Beanstalk was a viable option and all of the major benefits of FaaS were still retained.

(39)

4.5. Logging 29 Application does not take any advantage of Lambdas temporary file capabilities ie. it does not save any data between executions to temporary files. This way the application built is truly stateless.

4.5 Logging

As AWS Lambda itself provides mainly info about invocations it does not satisfy logging requirements. For example, it does not show how many times some resource has been accessed if the resource is hosted somewhere else nor does it show who made the request and what was the given response. As the project uses AWS Cloudfront as its CDN it was decided that log data from Cloudfront would be saved to S3 bucket.

Logging data from S3 is automatically fed into Amazon Athena. Athena is a big data analyzing tool provided by Amazon. Athena was used to make queries directly into the log data saved by AWS Cloudfront. Querying Athena is done by using SQL (Structured Query Language). Athena uses Presto variant of SQL. Example of a query used to debug system is listed in code listing 4.2 [44]

1 s e l e c t *

2 f r o m c l o u d f r o n t _ l o g s _ 2 3 w h e r e uri = ’ / api / u s e r / ’ 4 o r d e r by d a t e desc, t i m e d e s c 5 l i m i t 100

Program 4.2Querying AWS Athena is done by using SQL. Query here retrieves 100 lines of data with all fields sorted by descending date and time

(40)

30

5. RESULTS AND ANALYSIS

5.1 Quality of service measurements

5.1.1 Costs

Costs for www.talouselama.fi service was estimated to be around 150$ per month.

After running the service in production for several months that estimate was proven incorrect. In reality the costs are more than double compared to the estimated amount and they vary slightly from month to month depending on the amount of days and visitor amounts. Expenses shown in figure 5.1 include development setups as well but it should be noted that those affect on numbers is minimal at best.

In chapter 3.7.1 it was estimated that AWS Lambda would account only for 16% of the costs and AWS Api Gateway for the rest. This estimate proved to be wrong.

Around one third of the costs are generated by AWS Lambda and around two thirds by AWS Api Gateway.

Figure 5.1 Expenses of running frontend server of www.talouselama.fi from 08.2017 to 03.2018

As estimates and actual expenses differed by a great margin it is safe to assume that some errors were made in calculating estimate. In addition to actual user made page

(41)

5.1. Quality of service measurements 31 loads system accumulates costs every time the site is queried by crawlers and other third party systems. Initial cost estimate did not take these third party crawlers into account. Further study on the subject is needed.

5.1.2 Problems in pricing model

Www.talouselama.fi application uses amazon’s Cloudfront CDN to cache different responses and also to make APIs seem to be hosted on the same domain to avoid CORS (Cross-Origin Resource Sharing) problems.

Cloudfront is very useful and performs its function but the pricing is problematic because data transfer from the application is paid twice. First application sends its response data through API Gateway and then that response is further piped through AWS Cloudfront. Each of these services charge based on the amount of data transferred out.

Use of API gateway is not required when the application is hosted for example on AWS Elastic Beanstalk PaaS platform. Paying for data transer twice further increases the costs of using AWS Lambda as a frontend server. Considering infrastructure costs AWS Lambda is not the best solution to run a web server setup required by the application.

5.1.3 Availability and accessibility

Old www.talouselama.fi website had an excellent uptime record of having only two minute long outages in about a year. This uptime was a result of heavy caching used by the old system. Old www.talouselama.fi was not in active development which also minimized risk for downtime. However, as the new website enables users to log in such a heavy caching was not used in the new implementation. Availability measurements with pingdom system were started on 18.7.2016.

New www.talouselama.fi website went live on 3.10.2017. After the the new service went live there has been only couple outages in the service of the system. At the time of writing www.talouselama.fi website had an uptime of 99.94 percent. Although the goal of 100 percent uptime was not reached, reason for outages is not outright clear. However, there were and still are some minor bugs in websites programming

(42)

5.2. Performance 32

Figure 5.2Availability before the launch of the renewed www.talouselama.fi website. Total of 2 outages that in total resulted in outage of about 2 minutes. Data was gathered using pingdom service and data points are from 18.7.201 6 to 2.10.2017.

code that might account for these outages. Mainly these are problems considering fetching data from different APIs.

Figure 5.3 Availability after the launch of the renewed www.talouselama.fi website. Total of 42 outages that in total resulted in outage of about an hour. Data was gathered using pingdom service and data points are from 3.10.2017 to 21.1.2018.

5.2 Performance

Performance measurements were done using Apache JMeter tool. Apache JMeter is a tool which can be used to measure performance of a webserver by sending multiple sequential and parallel requests to the server. After Apache Jmeter has sent the requests it measures the time it took for the server to respond to a particular request and draws a graph from the results. It has to be noted that Apache JMeter does not measure websites performance as a whole as it focues only on the time it took for the server to respond with a payload.

Feasibility of a Function as a Service system as a frontend server for a websit

NIKO NUMMI