Serverless computing is a new paradigm, and it is becoming rapidly popular in Cloud computing. Serverless computing has interesting, unique properties that the unit of deployment and execution is a serverless function. Moreover, it introduces the new economic model pay-as-you-go billing model. It provides a high economic benefit from highly elastic resource provisioning to the application. However, it also accompanies the new challenges for serverless computing: (1) start-up time latency problem from relatively short function execution time, (2) high-security risk from highly consolidated environment, and (3) memory efficiency problem from unpredictable function invocations. These problems not only degrade performance but also lowers the economic benefits of Cloud providers. In this work, we propose VM-level pre-JIT snapshot and develop Fireworks to solve the three main challenges without any compromises. The key idea behind the VM-level preJIT snapshot is to leverage pre-JITted serverless function codes to reduce both start-up time and execution time of the function and improve memory efficiency by sharing the pre-JITted codes. Also, Fireworks can provide high-level isolation by storing the pre-JITted codes to the snapshot of microVM's snapshot. Our evaluation shows that Fireworks outperforms the state-of-art serverless platforms by 20.6× and memory efficiency up to 7.3×. / Master of Science / Serverless computing is the most popular in cloud computing. Contrary to its name, developers write and run their code on servers managed by cloud providers. The number of servers, required CPU, memory are automatically adjusted in proportion to the incoming traffic. Also, the users only pay for what they use and the pay-as-you-go attracts attention as new infrastructure. Serverless computing continues to evolve and it is being done as research from business to academic. There are many efforts to reduce cold start, which is the delay in creating the necessary resources when a serverless program runs first. The serverless platforms prepare resources in advance or provide lighter cloud resources. However, this can waste resources or increase a security threat. In this work, we propose a fast, efficient, and safe serverless framework. We use Just-In-Time (JIT) compilation, which can improve the performance of the interpreter languages which are widely used in the serverless. We keep the JIT-generated machine code in the snapshot for reuse. Besides, the security is guaranteed by the VM-level snapshot. In addition, the snapshot can be shared, increasing memory efficiency. Through our implementation and evaluation, we have shown that Fireworks improve up to 20 times in terms of cold start performance and more than 7 times in memory efficiency than state-of-the-art serverless platforms. We believe our research has made a new way to use the JIT and the snapshot in the serverless computing.

Digitaliseringen går allt snabbare för att fylla det behov som det moderna samhälletkräver så behövs inte bara en digital arbetskraft, det behövs även en infrastruktur sommöjliggör en snabbare digital utveckling. Samtidigt har cloud computing och molnleverantörer blivit en alltmer integrerad del av mjukvaruutvecklingen. Ett ytterligare abstraktionslager som fått mer popularitet och uppmärksamhet de senaste åren är serverless computing. Serverless computing innebär ett abstraktionslager som moln-leverantörer tillhandahåller för att ta bort ansvaret för drift och skalbarhet av servrar. Denna studie konstruerar ett ramverk för en benchmark av prestanda för serverless infrastruktur på tre av de största moln-leverantörerna. Ramverket bygger på en grey box implementering av en rekursiv algoritm för att beräkna det 45:e numret i en Fibonacci-serie i Python, Java och NodeJS. Detta görs på moln-plattformarna Google Cloud Platform, Amazon Web Services och Microsoft Azure. Syftet är att se huruvida det finns skillnader i exekveringstid och minnesåtgång för den givna algoritmen på de tre plattformarna i respektive programmeringsspråk. Studien visar att det finns statistiskt signifikanta skillnader mellan både exekveringstid och minnesåtgång, för alla kodspråken på de tre plattformarna. Störst skillnad är det på NodeJS, följt av Java och sist Python. På aggregerad nivå är det större skillnad för minnesåtgång gentemot exekveringstid. / The pace of digitalization is ever-increasing. To fill societies need for digitalization adigital workforce is needed, as well as the infrastructure to support said workforce.In the wake of digitalization, cloud computing and cloud providers have become anintegrated part of software production. An abstraction layer that builds on top ofcloud computing has gained traction over the last couple of years, serverless computing.This is an abstraction layer that cloud providers provide, which takes away theresponsibility of scaling and maintaining servers. This study constructs a framework to benchmark performance for serverless infrastructurefor three large cloud providers. The framework is a grey-box implementationof a recursive algorithm to calculate the 45th number in a Fibonacci series. Saidalgorithm will be tested in Python, Java and NodeJS. The tests will be conducted onthe cloud providers Google Cloud Platform, Amazon Web Service and Microsoft Azure.The purpose of the study is to show any differences in execution time andmemory consumption, for the given algorithm, on all three platforms and betweeneach programming language. The study shows that there are statistically significant differences for execution timeas well as memory consumption, for all coding languages, between all three platforms.The biggest difference is observed for NodeJS, followed by Java and lastly Python.On an aggregated level there are greater differences in memory consumptionrather than execution time.

Inom IT-världen använder man väldigt ofta WebJobs för att utföra mindrearbeten på internet. WebJobs använder en server som är i gång i bakgrunden.2016 introducerade företag som Amazon, Microsoft och andra storaföretag/bolag “Serverless Computing” som ska kunna exekvera arbeten överinternet utan att utvecklaren behöver tänka på hur mycket resurser somanvänds, samt att den ligger aktiv i bakgrunden hela tiden. Med MicrosoftsAzure Function så exekveras ett jobb när en trigger har aktiverats, och närjobbet är klart så körs inget i bakgrunden för användaren. Detta leder till attresurser allokeras dynamiskt samt att man endast blir debiterad för deresurser funktionen använt. Vi ska tillsammans med Visma SPCS arbeta meden produkt som flyttar över information hos användare till en molnserver.Denna produkt ska vi sedan konvertera från ett Azure WebJob till AzureFunction och göra det till serverless computing. Med detta vill vi analyseraom exekveringen blir snabbare då användaren inte behöver allokera resurser,samt om företaget kan spara pengar genom att göra denna typ av migrering.Serverless computing är något som det talas om mycket just nu inomIT-världen och det finns många debatter och artiklar som förespråkar för omman ska göra denna flytt eller ej. Därför vill vi själva göra flytten ochanalysera om det är lönsamt för företag i längden att lägga ner den tid det tarpå att konvertera ett fungerande program till en ny modern arkitektur. För attta reda på detta har vi analyserat det nuvarande programmet hos Visma, settöver vilka algoritmer och funktioner vi behöver skriva om för att görakonverteringen, samt lagt in ett loggningssystem så att vi enkelt har kunnatanalysera tiden varje exekvering av arbetet tar. Med datan vi samlat in kan vidra slutsatsen att kostnaden gick från cirka 1200 kr/månad till 0 kr/månad.Detta för att det är ett så litet jobb som exekveras och på grund av att Vismasgamla jobb exekverades var femte minut och letade efter filer som skulleflyttas, medans vårt jobb endast startades om det fanns något nytt att förflytta.Microsoft har även en miljon gratis exekveringar per månad för användaremed licens och Visma kommer upp i cirka 8000 exekveringar per månad. Vifick också fram ett resultat att exekveringen blev 6 gånger snabbare än dengamla lösningen och detta är på grund av att Microsoft själv allokerar de mestoptimerade resurserna för just detta jobb.

Stemming from the growth and increased complexity of computer vision, natural language processing, and speech recognition algorithms; the need for scalability and fault tolerance of machine learning systems has risen. In order to comply with these demands many have turned their focus towards implementing machine learning on distributed systems. When running time demanding and resource intensive tasks like machine learning training on a cluster, resource efficiency is very important to keep training time low. To achieve efficient resource allocation a cluster scheduler is used. Standard scheduling frameworks are however not designed for deep learning, due to their static resource allocation. Most frameworks also do not make use of a serverless architecture, despite its ease of management and rapid scalability making it a fitting choice for deep learning tasks. Therefore we present Coach, a serverless job scheduler specialized for parameter server based deep learning models. Coach makes decisions to maximize resource efficiency and minimize training time through use of regression techniques to fit functions to data from previous training epochs. With Coach we attempt to answer three questions concerning the training speed (epochs/second) of deep learning models on a distributed system when using a serverless architecture. The three questions are as follows. One: does the addition of more workers and parameter servers have a positive impact on the training speed when running a varying number of concurrent training jobs? Two: can we see improved performance in regards to the training speed, when training is done in a distributed manner on a cluster with limited resources, compared to when it is done on a singular node? Three: how accurate are predictions made using fitted functions of previous training data at estimating the optimal number of workers and parameter servers to use during training, in order to maximize training speed? Due to limitations with the cluster used for testing we see that a minimal setup of a singular worker and server is almost always optimal. With results indicating that an additional server can have slight positive effects in some situations and an additional worker only appears positive in high variance situation where there are many jobs running at the same time. Which is theorized to be caused by choices made by the Kubernetes scheduler.

Systems for running distributed deep learning training on the cloud have recently been developed. An important component of a distributed deep learning job handler is its resource allocation scheduler. This scheduler allocates computing resources to parts of a distributed training architecture. In this thesis, a serverless distributed deep learning job handler using Kubernetes was built to compare the job completion time when two different Kubernetes schedulers are used. The default Kubernetes scheduler and a gang-like custom scheduler. These schedulers were compared by performing experiments with different configurations of deep learning models, resource count selection and number of concurrent jobs. No significant difference in job completion time between the schedulers could be found. However, two benefits were found in the gang scheduler compared to the default scheduler. First, prevention of resource deadlocks where one or multiple jobs are locking resources but are unable to start. Second, reduced risk of epoch straggling, where jobs are allocated too few workers to be able to complete epochs in a reasonable time. Thus preventing other jobs from using the resources locked by the straggler job.

Function as a service (FaaS) is a type of serverless cloud computing intended to facilitate development by abstracting away infrastructural management, and offer a more flexible, pay-as-you-go billing model based on execution time and memory allocation. FaaS functions are deployed to the cloud provider as either single units, or chained to form a pipeline of multiple functions that call each other. As each step in the pipeline might have different requirements, it could be beneficial to split larger functions into smaller parts. This would enable customized provisioning according to each function's needs, and potentially result in a lower rate. However, decreased memory entails a lower CPU performance, which directly correlates to computation time. A test application was created and executed on Google Cloud services to investigate what impact function segregation, and provisioning accommodated to each sub-function requirement, have on end-to-end latency and total cost. In conclusion, no trivial relation between cost and performance was found. Segregating and adjusting provisioning to required memory was in this experiment cheaper in some cases, but not all; however, always significantly slower. In addition to price and workload behavior being considered and balanced, it was found that aspects such as level of control over management and hardware configuration has to be weighed in when deciding if FaaS is a suitable alternative for a given situation.

Serverless is a fascinating trend in modern software development which consists of pay-as-you-go, autoscaling services. Promised reduction in operational and development costs attracts not only startups but also enterprise clients despite that serverless is a relatively fresh field where new patterns and services continue to emerge. Serverless started as independent services which solve specific problems (highly scalable storage and computing), and now it's become a paradigm shift how systems are built. This thesis addressed questions when and how to start with serverless by reviewing available literature, conducting interviews with IT professionals, analyzing available tools, identifying limitations of serverless architecture and providing checklist when serverless is applicable. The focus was on AWS serverless stack, but main findings are generic and hold for all serverless providers serverless delivers what it promises, however, the devil is in the detail. Providers are continuously working to resolve limitations or building new services as solutions in order to make serverless the next phase of cloud evolution. / Serverless är en fascinerande trend inom nutida mjukvaruutveckling som består av pay-as-you-go, autoscaling-tjänster. Löftet om reducerade kostnader för drift och utveckling attraherar såväl startupföretag som storföretag, trots att serverless är ett relativt nytt område där nya inriktningar och tjänster fortsätter att uppkomma. Serverless började som en oberoende tjänst som löste specifika problem (högt skalbar lagring och databehandling), och har nu blivit ett paradigmskifte för hur system byggs. Denna uppsats sökte svar på frågor om när och hur man ska börja med serverless genom att granska tillgängliga publikationer, genomföra intervjuer med IT-experter, analysera tillgängliga verktyg och identifiera begränsningarna i serverless-arkitekturen. Fokus ligger på AWS serverless stack, men de huvudsakliga slutsatserna är generiska och gäller för alla serverless-leverantörer – serverless håller vad den lovar, men djävulen bor i detaljerna. Tjänsteleverantörerna jobbar oavbrutet med att lösa begränsningarna eller skapa nya tjänster och lösningar som ska göra serverless till nästa fas i molnevolutionen.

Stream processing systems have been widely adopted in applications such as recommendation systems, anomaly detection, and system monitoring due to their real-time capabilities. Improving observability in stream processing systems can further expand their application scenarios, including the implementation of stateful serverless applications. Stateful serverless applications are an emerging model in serverless computing that focuses on addressing the challenges of state management, enabling developers to build distributed applications in a simpler way. One possible implementation of stateful serverless applications is based on stream processing engines. However, the current approaches for observability in stream processing engines suffer from issues such as efficiency, consistency, and functionality, resulting in limited practical use cases. To address these challenges, we propose Queryable Workflow, an extension to stream processing engines. This extension allows users to access or modify the state within stream processing engines with transactional semantics using a SQL interface, enabling use cases such as ad-hoc querying, serializable updates, or even stateful serverless applications. We implemented our system on stream processing engines such as Portals and Apache Flink, and evaluated their performance. The result showed that our system has achieved 4.33x throughput improvement and 30% latency reduction compared to a baseline implemented with Apache Flink and Apache Kafka. With hand-crafted optimizations, our system achieved to process over 29,000 queries per second with a 99th percentile latency of 8.58 ms under a single-threaded runtime. Our proposed system provides a viable option for implementing stateful serverless applications that require transactional guarantees, while also expanding the potential application scenarios for stream processing engines. / Strömbehandlingssystem har på grund av sina realtidsegenskaper fått stor spridning i tillämpningar som rekommendationssystem, anomalidetektering och systemövervakning. Förbättrad observerbarhet i stream processing-system kan ytterligare utöka deras tillämpningsscenarier, inklusive implementeringen av stateful serverless-applikationer. Stateful serverless-applikationer är en framväxande modell inom serverless computing som fokuserar på att hantera utmaningarna med tillståndshantering, vilket gör det möjligt för utvecklare att bygga distribuerade applikationer på ett enklare sätt. En möjlig implementering av stateful serverless-applikationer är baserad på stream processing-motorer. De nuvarande metoderna för observerbarhet i strömbehandlingsmotorer lider dock av problem som effektivitet, konsistens och funktionalitet, vilket resulterar i begränsade praktiska användningsfall. För att ta itu med dessa utmaningar föreslog vi Queryable Workflow, ett tillägg till stream processing-motorer. Med detta tillägg kan användare komma åt eller ändra tillståndet i strömbehandlingsmotorer med transaktionssemantik med hjälp av ett SQL-gränssnitt, vilket möjliggör användningsfall som ad hoc-förfrågningar, serialiserbara uppdateringar eller till och med serverlösa applikationer med tillstånd. Vi implementerade vårt system på stream processing-motorer som Portals och Apache Flink, och utvärderade deras prestanda. Resultatet visade att vårt system har förbättrat genomströmningen 4,33 gånger och minskat latensen med 30% jämfört med en baslinje som implementerats med Apache Flink och Apache Kafka. Med handgjorda optimeringar lyckades vårt system bearbeta över 29 000 frågor per sekund med en 99:e percentil latens på 8,58 ms under en enkeltrådad körtid. Vårt föreslagna system har gett ett hållbart alternativ för att implementera stateful serverless-applikationer som kräver transaktionsgarantier, samtidigt som det också utökat de potentiella applikationsscenarierna för stream processing-motorer.

With the development of cloud computing technologies, the concept of Function as a Service (FaaS) has become increasingly popular over the years. Developers can choose to create applications in the form of functions, and delegate the deployment and management of the infrastructure to the FaaS provider. Before a function can be executed at the infrastructure of the FaaS service provider, an environment to execute a function needs to be initiated; this environment initialization is known as cold start. Loading and maintaining a function is costly for FaaS providers, especially the cold start process which costs more system resources like Central Processing Unit (CPU) and memory than keeping functions alive. Therefore it is essential to prevent a cold start whenever possible because this would lead to an increase in both the response time and the cost. An instance management policy need to be implemented to reduce the probability of cold starts while minimizing costs. This project’s objective is to develop an instance management algorithm to minimize total costs while meeting response time requirements. By investigating three widely used instance management algorithms we found that none of them utilize the dependency existing between functions. We believe these dependencies can be useful to reduce response time and cold start probability by predicting next invocations. By leveraging this observation, we proposed a novel Dependency Based Algorithm (DBA). By using extensive simulations we showed that proposed algorithm can solve the problem and provide low response time with low costs compare to baselines. / I och med utvecklingen av molntjänster har konceptet FaaS (Function as a Service) blivit alltmer populärt under årens lopp. Utvecklare kan välja att skapa applikationer i form av funktioner och delegera utplaceringen och förvaltningen av infrastrukturen till FaaS-leverantören. Innan en funktion kan exekveras i FaaS-tjänsteleverantörens infrastruktur måste en miljö för att exekvera en funktion initieras; denna miljöinitialisering kallas kallstart. Att ladda och underhålla en funktion är kostsamt för FaaS-leverantörerna, särskilt kallstartsprocessen som kostar mer systemresurser som CPU och minne än att hålla funktionerna vid liv. Därför är det viktigt att förhindra en kallstart när det är möjligt eftersom detta skulle leda till en ökning av både svarstiden och kostnaden. En policy för hantering av instanser måste införas för att minska sannolikheten för kallstarter och samtidigt minimera kostnaderna. Projektets mål är att utveckla en algoritm för hantering av instanser för att minimera de totala kostnaderna samtidigt som kraven på svarstid uppfylls. Genom att undersöka tre allmänt använda algoritmer för hantering av instanser fann vi att ingen av dem utnyttjar det beroende som finns mellan funktioner. Vi tror att dessa beroenden kan vara användbara för att minska svarstiden och sannolikheten för kallstart genom att förutsäga nästa anrop. Genom att utnyttja denna observation föreslog vi en ny beroendebaserad algoritm. Med hjälp av omfattande simuleringar visade vi att den föreslagna algoritmen kan lösa problemet och ge en låg svarstid med låga kostnader jämfört med baslinjerna.

When developing mobile applications, the tradition has been to write code specific (native) for each platform they are running on. Usually it’s about writing two separate applications for the biggest platforms, Android and iOS. There exist alternatives to this approach that uses the same code for different platforms. React Native is a relatively new cross-platform development framework that makes it possible to use the same code for application to Android and iOS. It also uses native UI-elements as a possible solution for performance issues that is often associated with cross-plattform development. This thesis evaluates React Native and compares it against native Android. The implementation is done by replicating the main functionality from a social media application written as a native Android application. However, the application is not made as an exact replica since that could limit the solutions in React Native. The evaluation is done in a Startup company and therefore focuses on aspects important in a Startup. Another issue when developing a mobile application is what type of backend that shall be used. Performance, scalability and complexity are all important aspects when choosing a framework or language as a base for the backend architecture.There do exist theoretical frameworks that could be used when building the backend. However, these frameworks require resources that are often missing in a Startup. AWS Lambda is a platform that claims to be a cost-effective way of building a scalable application. In this thesis AWS Lambda is evaluated to see if it can be used to create an automatically scaled backend for this type of social media application. The conclusion of the React Native evaluation is that it can be a suitable alternative to native Android development. If the team has previous experience in web development but lack experience in mobile application development it can be a wise choice since it removes the need to learn two frameworks in native Android and native iOS development. React Native is also good to fast create functional prototypes which can be shown to potential investors. The biggest drawback is performance in animations. However, there are often ways to work around that. In our case this drawback did not affect the user experience of the end application. The evaluation of AWS Lambda concludes that it is not for every project. In this thesis, the application was a bit too database heavy and therefore the autoscaling ability did not work properly. However, for a service that needs a lot of computing power, AWS Lambda could be a good fit. It could also be a suitable alternative if someone in the team has previous experience in the AWS environment.