Building Backend with AWS Serverless - Lieu Vu - Theseus
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Lieu Vu Building Backend with AWS Serverless Metropolia University of Applied Sciences Bachelor of Engineering Information Technology Bachelor’s Thesis 30 October 2020
Abstract
Author Lieu Vu
Title Building Backend with AWS Serverless
Number of Pages 29 pages
Date 30 October 2010
Degree Bachelor of Engineering
Degree Programme Information Technology
Professional Major Software Engineering
Instructors Janne Salonen, Head of the School of ICT
Cloud technology has changed the game of how a software is deployed and delivered to a
customer in a faster, reliable and constant manners. Serverless technology ease further
the deployment effort and enable developers to concentrate on coding task.
Having intermediate experience with serverless technology, the author would like to take
the opportunity of this thesis to promote the serverless technology by discussing its
concepts, its strengths and its weaknesses. The real backend system namely booking-
system will accompany with the theory discussion to bolster understanding of how to utilize
the power of serverless technology.
The author hopes that the thesis may contribute to serverless technology research with a
concrete example and it perhaps inspire more developers to experiment and use
serverless technology contribute toward serverless technology.
Keywords Serverless, AWS Lambda, backend, database, Infrastructure
as Code, Docker, CI/CD, API, Terraform, NodeJS.
Contents
List of Abbreviations
1 Introduction 1
2 Theoretical Background 2
2.1 Serverless Computing 2
2.2 Serverless Benefits and Drawbacks 3
2.2.1 Benefits of serverless architecture 3
2.2.2 Drawbacks of serverless architecture 4
2.3 AWS Lambda 4
2.4 Database 5
2.4.1 Relational databases 6
2.4.2 Non-relational databases 6
2.5 Infrastructure as Code 7
2.6 Docker 8
2.7 Continuous Integration and Delivery 8
3 System Implementation 10
3.1 System Overview 10
3.2 Project Structure 10
3.3 Application Directory Structure 11
3.4 System Database 12
3.5 Docker Utilization 14
3.6 System APIs Main Flows 15
3.7 System Testing 18
3.8 System Documentation 20
3.9 System CI/CD 22
4 System Evaluation 25
4.1 System Strengths 25
4.2 System Limitations 25
4.3 Future Enhancement 26
5 Summary and Conclusion 27
5.1 Summary 27 5.2 Conclusion 27 References 28
List of Abbreviations AWS Amazon Web Services IaC Infrastructure as Code CI/CD Continuous Integration/Continuous Delivery API Application Programming Interface IaaS Infrastructure as a Service PaaS Platform as a Service SaaS Software as a Service FaaS Function as a Service SQL Structured Query Language VPC Virtual Private Cloud NLB Network Load Balancer ALB Application Load Balancer REST Representational State Transfer HTTP Hyper Text Transfer Protocol JSON JavaScript Object Notation DDOS Distributed Denial-of-Service
1 1 Introduction With the rise of cloud computing, there has been a significant number of companies ranging from small to big have been adopting the power of is Serverless computing. The development and deployment of software has been simpler with just several clicks and a decent server is created in just less than 10 minutes and ready to host any applications. Docker technology even push it further when a developer can develop an application in the language of his preferences and package all codes and all required libraries for the app to run in the docker image. The image can then be run in the cloud seamlessly. Serverless goes even beyond that when it enable a developer just to focus on what he or she is best at. That is coding. Indeed, the developer is free from the burden of maintaining and provisioning the server, which is somehow tedious task and time- consuming. As a developer who has been working with serverless technology for a period of time, the author has been inspired by the technology and all the power it can bring to a team of developers. Especially, the technology suits quite well for developing backend and APIs system, which used to take considerable amount of times in the past to implement. Thus, the thesis will serve as a reference guide to encourage more developers to try or adopt serverless technology via real example of creating a backend system empowered by serverless technology. Firstly, the thesis will discuss theoretical background with several main concepts such as serverless computing, its benefits and drawbacks, Amazon Web Services (AWS) Lambda, database, Infrastructure as Code (IaC), Docker and Continuous Integration and Delivery (CI/CD). Secondly, it will presents the system implementation in details by going through system overview, project structure, system database, system Application Programing Interfaces (APIs) main flows and System CI/CD. Thirdly, the study will evaluate the system in terms of its strengths, its limitations as well as its future enhancement. Finally, it finishes with summary and conclusion section.
2
2 Theoretical Background
This section presents some theoretical concepts that are used as grounds to develop
the application. It starts by introducing Serverless Computing concepts, following with
AWS Lambda and Database. It then continues with IaC, Docker and ends with CI/CD.
2.1 Serverless Computing
In order to understand the concept, another broader concept namely cloud computing
should be explained first. Cloud computing is the on-demand usage of compute power,
storage, applications, databases and any IT capabilities via the Internet based on the
pay-as-you-go pricing model (Sosinsky, 2011). The “Cloud” is the computer that is
located remotely and is accessed and utilized via the Internet. The cloud is consisted of
server computers placed in various locations around the world (Rajan, 2018). There are
four types of cloud computing such as Infrastructure as Service (IaaS), Platform as a
Service (PaaS), Software as a Service (SaaS) and Serverless (Gladu, 2018).
Three cloud types (Microsoft Azure, 2020)
The above figure tells the difference between three cloud types IaaS, PaaS and SaaS.
IaaS is an instant computing infrastructure, provisioned and managed over the Internet.
PaaS is a complete development and deployment environment in the cloud where the
user can develop and deliver simple to complex cloud-based applications. SaaS allows
users to connect and use cloud-based applications such as emails, calendar and tools.
(Microsoft Azure, 2020.)
Serverless computing or Function-as-a-service (FaaS) provides a software architecture
where an application is split into “triggers” (events) and “actions” (functions) running on
a seamless hosting and execution environment (Rajan, 2020). The application instances
3
are run inside the container which share same runtime, operating system and hardware
(figure 2). Each containers can handle the number of application instances. If more
applications are needed, another container will be created. This enable scalability of an
application.
Shared resources in serverless computing (Rajan, 2020)
The term “serverless” is often misleadingly understood that there is no server. Indeed,
there is still a server but a developer just ignore it and spend efforts only on developing
an application or coding.
2.2 Serverless Benefits and Drawbacks
As like many software architectures have advantages and disadvantages, serverless is
not an exception and has its own benefits and drawbacks.
2.2.1 Benefits of serverless architecture
Serverless offers several benefits as follows (Hopping, 2018):
• Saving resource planning: this is quite lengthy process for companies since they
need to plan resource capacity, predict which how much resource requirement in the
future and proceed to buy the appropriate resources.
• Saving server maintenance effort: the developer do not need to spend hours to
update, upgrade and maintain the system to improve security and performance.
These tedious tasks are handled by the serverless service providers.
• Better security: since the application is run on a random container which is black
box to developers, there is no way a hacker can access the running environment in
serverless architecture. Hence, the system is less likely to be hacked.
4
• Better scalability: developer needs not to worry if an application is overloaded with
requests or tasks because serverless architectures can run as many application
instances as needed. In other word, the application can scale up when there is more
demands from customers and scale down when there is less demands.
• Cost efficiency: companies only pay for the actual volume of consumed resources
meaning huge cost is saved especially when a company is a start-up and has less
customers.
Samarthyam, Ganapathi and Repakula (2017) suggest that serverless are good for uses
cases such as three-tier web applications, scalable batch jobs, stream processing and
automation/event-driven processing.
2.2.2 Drawbacks of serverless architecture
There are some challenges when implementing serverless applications (Rajan, 2020):
• Hardware-level challenges include distributed storage and their levels,
virtualization of servers, cold starts, optimization of resources and designing fault
tolerant system architecture.
• Developer-level challenges comprise lack of tracking and debugging tools,
designing stateful and stateless functions, transaction and concurrency
management, recovery system architecture, and applying DevOps principle.
• Management-level challenges relate to improving the resource limits, managing
resource provisioning and load balancing, launch overheads, dynamic scheduling, ,
legacy system migration, predictable salability and security mechanism.
• Business-level challenges refer to cost estimation, pricing model, managing hybrid
cloud and non-cloud systems employing the serverless architectures.
2.3 AWS Lambda
AWS Lambda is the earliest (in early 2015) and the most popular serverless technology
developed by Amazon. The competitor counterpart such as Azure functions was
launched in 2016 while Google Cloud Functions was just in 2018 (Rohit, 2020).
5 Table 1. Comparisons of serverless features (Rohit, 2020) According to the table, AWS Lamba support variety of languages such as Javascript, Python, Java, C# and Go with the maximum execution time up to 15 minutes and 1000 parallel execution. It also support automatic scaling and orchestration as well as logging and monitoring with AWS Cloudwatch. 2.4 Database Data plays an important role in every software system. There is hardly any system operating without data. The system manipulates data and create useful information or knowledge for users. Databases have been invented to store data effectively. Database is set of structured data or information stored in a computer system to facilitate a computer program or a person to retrieve this information via search language (Čerešňák, 2019). There are two main database systems are relation databases and non-relation databases.
6
2.4.1 Relational databases
Relational databases refer to databases using the concept of rows and columns in a set
of relational tables (Čerešňák, 2019). The great number of them also use Structured
Query Language (SQL) to write and query data and hence are often called SQL
databases. There are popular relational databases, for instance, PostgreSQL, MariaDB,
MySQL, Oracle DBMS; Microsoft SQL Server, It follows fundamental principles of
transactional database including Atomic, Consistent, Isolation and Durability (ACID).
These principles are explained as follows (essentialSQL, 2020):
• Atomic: transaction acting on several pieces of datais treated as single unit and
complete only if all pieces are saved successfully. Otherwise, it will fail.
• Consistent: the saved data must comply with the integrity of the database meaning
it satisfy all the constrains and conditions pre-defined in the database. All violated
modifications are rolled back to the state before the changes apply.
• Isolation: concurrent transactions have no effect on each other and executing them
leaves the database to the state as it is when they are executed sequentially.
• Durability: committed transactions are preserved regardless of the system failure or
restarts.
Holding those above mentioned properties, relational databases pose several
challenges for developers (Anderson and Nicholson, 2020):
• The relational databases require comprehensive up-front design of data models to
ensure decent performance and prevent evolution.
• Hosting data across multiple databases (horizontal scaling) in relational databases
is arduous.
• Non-distributed databases are commonly a “single point of failure” that must be
alleviated by replication and failover techniques.
2.4.2 Non-relational databases
Non-relational databases have become prevalent in the 2000s and is named NoSQL
because they use different query language (Čerešňák, 2019). The discrepancies of SQL
databases and NoSQL databases are portrayed in table 1.7 Table 2. Discrepancies between SQL and NoSQL Databases (Čerešňák, 2019) As can be seen in the table, some of the weak points of SQL databases such as horizontal scalability and pre-defined scheme requirements are solved in NoSQL databases. Nonetheless, NoSQL databases do not support several strong points of SQL databases for instance, transactions, consistency and isolation. Some of popular NoSQL databases are MongoDB, Couchbase, Redis, Cassandra and Neo4J (Čerešňák, 2019) 2.5 Infrastructure as Code Infrastructure as Code (IaC) is the practice to automatically configure system dependencies and to provision local and remote instances (Morris, 2016). With the rise of cloud computing technology, demands to employ IaC to build software infrastructure are becoming increasing. Just imagine a case that a team of developers need to set up an infrastructure to host an application in AWS without using IaC. Then, the team has to login to AWS Console and click numerous buttons as well as fill in many forms to create Virtual Private Cloud (VPC) in a specific regions, set up NLB (Network Load Ballancer) and ALB (Application Load Ballancer), provision Elastic Containers (EC2) and Databases. If the team needs to do that with another region, then another lengthy and error prone clicking process is repeated. The infrastructure setting task quickly becomes tedious and even a nightmare in case of destroying allocated resources. IaC comes to rescue by providing a versioned and consistent way to create infrastructure from code. A team of developers will have more details of the infrastructure such as computing capacity, restriction and the last one who modified the infrastructure. Furthermore the team will save time and work by not doing repetitive clicks as well as avoid errors. There are popular IaC tools in the market including Terraform, Chef, Puppet and Ansible (Hromádka, 2020).
8
2.6 Docker
In other to understand docker, it is necessary to fathom the concept of container. The
Docker container or just simply container is a standard unit of software that bundle codes
and all its dependencies so the application can run quickly and reliably in different
computing environments (Docker, 2020). Docker is software to create, deploy and run
applications by using docker containers (Opensource, 2020).
Comparison of Docker Container and Virtual Machine (Docker, 2020)
As can be seen from the figure, Docker container abstract the application layer which
contain only packaged code and dependencies. Multiple containers share the Operating
System (OS) kernel but yet run as isolated process in a user’s space. Because of not
creating the OS and contains only needed code and dependencies, Docker container
image has lighter size and run faster than the Virtual Machine image.
2.7 Continuous Integration and Delivery
According to Sacolick (2018), continuous integration (CI) and continuous delivery (CD)
represent a culture, a set of principles and collection of practices that allow software
development team to ship code changes more regularly and reliably.9
CI/CD Pipeline (Eneh, 2019)
The differences between CI and CD can be drawn from figure 5. The CI is the process
of constant code change, building and testing. In practice, it is the process of creating
branches from master, modify the code in those branches and merge them back to
master. The CI process emphasizes on building and testing application to ensure that
integration of new commits to the main branch do not break the application. The CD, on
the other hand, highlight the constant release and deploy phases. It makes sure that the
application can be automatically delivered to customer quickly in sustainable way at any
time.10
3 System Implementation
3.1 System Overview
The purpose of the author is to demonstrate the usage of AWS Lambda by building a
backend system and expose them via Representational State Transfer (REST) API for
client to consume. The backend system is named as booking-system. The system allows
to create and manipulate data entities such as user, user address, building address and
machine, booking and quota. Each user at a specific user address is given a certain
quota and can make a number of booking within the quota to use a certain machine of
that building. The backend system is a NodeJS application using ExpressJS to develop
API, Slonik library to communicate with Database, Jest as testing framework, Docker to
local development and deployment and Terraform to deploy application to AWS. The
code is publicly hosted in Github at the URL address https://github.com/lieuvu/booking-
system.git.
3.2 Project Structure
The project structure of the booking-system is shown in figure 5.
Project Structure of the Booking-System11
There are main directories of the project. The .github directory contains file for Github
CI/CD. The docs directory holds files for documentation purpose. The node_modules
directory has all library packages used during the project development. This directory is
not committed to Github. The scripts directory includes all scripting files of the project
such as bash scripts of python scripts. The src directory comprises all files of the main
system. The terraform directory has all terraform files which are used for deployment.
The test directory consists of testing files. There are also some other files in the project.
Files .eslintignore and .eslint.rc are files to server for linting library eslint. Files docker-
compose.dev.yml, docker-compose.test.yml and docker-compose.yml are used for
Docker compose for local development. File Dockerfile is used to build docker image.
File jest.config.js has configuration for Jest testing framework. Files package-lock.json
and package.json are used by npm package manger. File tsconfig.json is used by
typescript compiler tsc.
3.3 Application Directory Structure
The main code part of the application is under directory src and is organized as the
following in figure 6.
Application Directory Structure of the Booking-System
The purpose and functionalities of different directories and files are explained as follows:
• common: The directory holds common files such as classes of Error.12
• config: The directory includes one or more configuration files. These files
contains data to setup database, data for logging and environment
variables.
• controller: The directory contains all the main logic for different request
methods such as create, get, update and delete for different entities.
• db: The directory to comprise database related file such as migrations or
sql files.
• middleware: The directory holds middleware used in the application.
• models: The directory consists of model files for each entities in the
database and interfaces of the application.
• routes: The directory carries all files used for routing purpose.
• schemas: The directory contains JSON schema files for each entity. These
schema files are used to validate if the request send expected data.
• services: The directory provides services used in the application. These
services can be database service or third-party service such as Stripe,
Google or Facebook.
• utils: The directory includes utility that can be reused in any places within
the application. One example can be logging.
• app.ts: The main application file to set up the Express application,
middlewares and routing.
• server.ts: The file to set up a web server for instance, which protocol to use,
which port it listen to.
3.4 System Database
Since the system deals with pre-defined data structure and schema, the best database
should be used is SQL database and the author picked PostgresDB as a database to
use. The entity relation model of the booking-system can be seen in figure 7.13
Booking-System’s Entity Relation Model
According to the model, the system have 8 main tables such as user, user_address,
building_address, machine_location, machine, machine_type, booking and migration.
Table user holds user information including first name, last name, email. Table
user_address comprises of user address information namely building_id indicating the
building address, building block number and apartment number Table building_address
has all information of the building address such as street, street number, city, postal
code. Table machine_location tells where the machine is located by referring to
building_id field, what type of machine at the place via machine_id field as well as the
number and the status of the machine. Table machine contains the machine data, for
instance, the machine_type_id referring to the type of the machine, machine brand,
machine model, machine description, machine number and machine type. Table
machine_type holds data of the machine type. Table booking contains the information of
the booking record like user_id indicating who makes the booking, machine_id shows
which machine is booked, the starting time and the ending time of the booking. There is
an especial table namely migration which has no relations with any other table. This table
is used to store data relating to the database migration.14
3.5 Docker Utilization
The application needs to communicate with a database to manipulate data. In the past,
a developer needs to install the database to the computer and config it with port, name,
some provisioning for the memory, caching and pool sizes. It is a cumbersome process
since the setup procedure is not standards in different platforms such as Linux, Windows
and MacOS. Furthermore, if a developer may need to create at least two different
databases, one for developing purpose and one for testing purpose.
Docker comes to rescue by providing Docker containers which have preinstalled and
pre-setup environments to develop or run the application. The following figure describes
how the booking system employed Docker power.
Docker Compose Files For Development and Test Environments
The docker compose is another tool provided by Docker. In general, it is the tool to
manage multiple Docker containers. The application have two containers one is the
container to hold the backend application and the other holds the database application.
Docker compose tool need to read compose yaml file which contains all configuration for
different containers. As can be seen from the figure, the file docker-comopose.dev.yml
contains configuration for dev environment while the file docker-compose.test.yml file
holds configuration for test environment. The structure of two files are quite similar. There
are two services or two applications in each file one is booking-system, which is the
backend application and the other is the database application either booking-
system.db.dev or booking-system.db.test depending on the environment.15
Development Environment Setup Using Docker Compose (In Linux)
As can be observed from the above figure, the developer needs only to install docker
and docker compose tools and then execute simple command to setup development
environment and he is ready to go with coding tasks. Furthermore, the setup is consistent
and works seamlessly regardless platforms whether it is Linux, Windows or MacOS.
3.6 System APIs Main Flows
Figure 10 describes the main flow of the booking-system. The client sends Hyper Text
Transfer Protocol (HTTP) request to the server. The server receives the request and
authenticate the request if authentication requires. If authentication is not needed, the
server validates the request data if validation requires. If validation is not mandatory, the
server will route the request to a specific controller to process. The controller then
communicates with the database to retrieve necessary data. The database responses to
the server either with data or error message. The server responses to the client with the
data in case of no error or error message in case of error and appropriate HTTP
response code.16
Booking-System API Flows
The following figure shows part of the implementation of the body validator used as
middleware in requests that have body data mainly POST request. The application uses
library ajv to load JSON schemas in src/schemas directory. Then it will then to validate
the schema against the body of the request. If the request send the correct body data
shape, it will then forward to the controller to process the request further. Otherwise, it
will throw an errors either because of the validation failed or the schema files may be
uncompiled.17
Part of Body Validator Middleware
The controllers contain main logic to process the HTTP requests from the client. Each
controller will contains methods to handle different request methods such as GET,
POST, PUT and DELETE. Figure 12 shows part of the implementation of the user
controller. The code describes the getUser function which will get the user information
and corresponds to GET request. The user id is retrieved from the request, then the
connection pool in the database is created and the query is made to retrieve the user
having the user id. If a database contains the user, it will return the user object in
JavaScript Object Notation (JSON) format containing the user id, user’s first name, user’s
last name, user’s email and user’s role. Otherwise, the function will throw an error either
the user could not be found or there is an error when querying the database.18
Part of User Controller Implementation
3.7 System Testing
Testing plays an important roles in any application, especially backend application. The
booking system utilize Jest testing framework since it is one of the popular testing
framework for JavaScript project. All test files are placed in the test directory and are
grouped into sub directories such as api, global_test, stub and unit. The api directory
consist of files for api testing. The unit directory includes files for unit testing. The
global_test dir has files for testing setup and the stub directory has files containing dump
data used in testing.19
Part of Body Validator Middleware
The partial implementation for POST request of the user api can be found in figure 14.
The test will make a request with POST method to the server and check the responses
to match against the expectation.
Partial Implementation of User API20
The result when executing the Jest testing framework can be found in the figure 15.
Partial Testing Result Of The Booking System
3.8 System Documentation
The backend system should always expose the API via some sort of documentation.
There are many tools that help to document systematically the API and they vary in
different programming languages. Swagger seems to stand out in the community as a
standard way to design, build, plan and develop API.
The booking system uses Swagger and Swagger UI to visualize the booking API (figure
16). When looking at the booking API web interface, the Swagger tool did a great job
when grouping different requests under main headers in various colors representing
different purposes of the requests. For instance, the DELETE request is colored as red
since it is dangerous operation. Each request method comes with a path next to it telling
the construct of the resource path.21
Booking-System CI/CD
Another nice feature of the Swagger is that it enables developers and API consumers to
try out the API using the Swagger UI web interface. When clicking the GET method of
user resource, a expandable form will be shown and reveals the “Try it out” button and
the form to enter the user id. Nonetheless, the form is disabled (figure 17).
Swagger API Form
By clicking “Try it out” button, the form is enabled to input the user id with two “Execute”
and “Clear” buttons. If the user id is provided and button “Execute” is clicked, the
response from the server will be shown with response code and response body.22
Swagger API Form Response
As can be seen from the figure below, the user JSON object is returned with id,
first_name, last_name, email and role.
3.9 System CI/CD
The booking-system utilizes Github Workflows as CI/CD for the project. As described in
figure 9, if the local trigger the push commit to Github, it then run tests. When there is a
merge commit trigger in Github, it firstly run tests and then run terraform scripts to
provision or modify the infrastructure resources in AWS. If the provisioning is successful,
then it will run database migration. In case of any failed steps occurs, the whole flow
failed.23
Booking-System CI/CD
The example of how the CI/CD flows in Github is portrayed in figure 10. On the left, ther
is information about the workflow name and on the rights there is information about jobs
running in the workflow. The tick symbol before the jobs indicating that the job is executed
successfully.
Github Workflow CI/CD24
The lambda function in AWS looks like in figure 11. The lambda function is named
booking-system and uses runtime Node.js 12.x, which means the version of Node.js
must be equal or higher than version 12.
Booking-System AWS Lambda Function25 4 System Evaluation During the development of the booking-system, the study recognized some of the system strengths and weaknesses. This section will outline some of findings in term of system strengths, limitations and future enhancement. 4.1 System Strengths Since the system uses the power of AWS Lambda Function, it can scale easily and have no problem when handling numerous requests. Using Docker for local development relieve the need to install packages, databases and tools. All a developer need to do is to install Docker and run docker command to build the local development environment in any machine whether is Windows, Mac or Linux. The system also uses built-in CI/CD solution in Github, which is quite interesting and fast. 4.2 System Limitations As mentioned above in the drawback of serverless architecture, it is challenging to debug AWS Lambda Function since it is a black box toward a developer. It is not possible to put a breakpoint and use debugger to debug line by line as in local development. The only way to overcome this difficulty is to log as many useful information as possible in the application and employ AWS Cloudwatch to see what goes wrong when the function is executed. Although ability to scale is a system strong point, it also seems to be a drawback when the system is attacked by Distributed Denial-of-Service (DDoS) attack where the system is overwhelmed with countless of requests. The system is billed for the actual consumption of the AWS Lambda Function seconds and the number of requests. Imagine in DDoS attack, there may be hundred millions of requests coming to the system and each request takes considerable amount of time to handle. The money the company needs to pay must be a considerable amount.
26 4.3 Future Enhancement Improving the system to resist the DDoS attack seems crucial to prevent from incurring high cost. One possible solution is to apply rate-limit mechanism with caching database such as Redis can mitigate the problem. Currently, the system lacks of API documentation which may assist other developer in understanding the system. One of the popular API specification is to follow OpenAPI specification and Swagger tool to generate the interactive Swagger UI.
27 5 Summary and Conclusion Serverless is still a new and hot research topic. The thesis contributes to serverless understanding by providing a practical implementation of a system using AWS Lambda. 5.1 Summary The thesis commences by presenting the new trend of adopting cloud technology, especially serverless technology to develop the software in a faster, more interesting and painless manner. Hence, it is seen to have a need to propagate the benefit and power of serverless to urge developers to try to adopt the technology in their works and their hobby projects. Then, the theoretical background commences with the concepts of serverless computing and its benefits and drawbacks as well as introducing AWS Lambda. It then discuss some concept of database in terms of relational database and non-relational database. Afterwards, it presents Infrastructure as Code approach and Continues Integration and Delivery theory. In the practical implementation, the thesis provides the crucial information of the system and instructions for building the system with some code demonstrations and the portrayal of how the system should look like in Github or AWS. The system is finally evaluated with its strengths, limitation and future enhancement. 5.2 Conclusion The system works as intended by the specification and brings back quite much new knowledge and experience to the author during the development process. Indeed, serverless is a good solution to build robust and scalable backend or an API system. The author tries to employ all the good practices from his own working experience to organize and write the concise, clean and descriptive code. It also bolster the author’s knowledge of Serverless and CI/CD.
28 References Anderson, B. and Nicholson, B. 2020. SQL vs. NoSQL Databases: What's the Difference?. Available at: https://www.ibm.com/cloud/blog/sql-vs-nosql. Accessed: 1 October 2020. Čerešňák, R. and Kvet, M. 2019. Comparison of query performance in relatonal a non- relation databases. Transportation Research Procedia, vol. 40, pp. 170-177. Docker, 2020. What is a Container?. Available at: https://www.docker.com/resources/what-container. Accessed: 1 October 2020. Eneh, T. 2019. Most popular CI/CD pipelines and tools TEXu [online]. Available at: https://medium.com/faun/most-popular-ci-cd-pipelines-and-tools-ccfdce429867. Accessed: 1 October 2020. essentialSQL. 2020. SQL ACID Database Properties Explained. Available at: https://www.essentialsql.com/sql-acid-database-properties-explained. Accessed: 1 October 2020. Gladu, B. 2018. What’s the Difference Between Cloud Computing and Serverless?. Available at: https://northstack.com/cloud-computing-vs-serverless. Accessed: 1 October 2020. Hopping, C. 2018. What is serverless architecture?. IT Pro; London. 28 August, p. 2. Hromádka, V. 2020. Infrastructure as Code in Agile Software. Bachelor's Thesis. Brno University of Technology. Microsoft Azure. 2020. What is IaaS?. Available at: https://azure.microsoft.com/en- us/overview/what-is-iaas. Accessed: 1 October 2020. Moris, K. 2016. Infrastructure as code: managing sservers in the cloud. O'Reilly Media, Inc. Opensource, 2020. What is Docker?. Available at: https://opensource.com/resources/what-docker. Accessed: 1 October 2020. Rajan, R. A. P. Rajan. 2018. Service Request Scheduling based on Qunatification Principle using Conjoint Analysis and Z-score in Cloud. International Journal of Electrical and Computer Engineering, vol. 8, pp. 1238-1246. Rajan, R. A. P. Rajan. 2020. A review on serverless architecture - function as a service (Faas) in cloud computing. TELKOMNIKA Telecommunication, Computing, Electronics and Control, vol. 18, pp. 530-537. Rohit, A. 2020. AWS Lambda vs Azure Functions vs Google Cloud Functions: Comparing Serverless Providers. Available at: https://www.simform.com/aws-lambda- vs-azure-functions-vs-google-functions. Accessed: 1 October 2020. Sacolick, I. 2018 What is CI/CD? Continuous integration and continuous delivery explained. InfoWorld.com. San Mateo: Infoworld Media Group.
29 Samarthyam, G., Ganapathi, M. and Repakula S. 2017. Admin - Insight: Serverless Architectures: Demystifying Serverless Computing. Open Source for You; New Dehli. 1 September, p. 3. Sosinsky, B. 2011. Cloud Computing Bible. 1st ed. Wiley Publishing.
You can also read
