Introduction
The website development community has experienced an explosion of new tools and technologies that help developers create websites. Popular websites today are built with complex user interface components and servers. New tools and architectures are being introduced everyday, to help with the complexity that developers face when designing a website. A new architecture pattern to develop websites has recently been taking the web development community by storm since Amazon Web Services introduced it in 2014. The Serverless Architecture has many names such as, but not limited to, serverless computing, serverless functions, or just serverless. However, Serverless does not mean not having a server. It means not worrying about a server. All websites need a server to function, so getting rid of the server simply could not work. Traditionally, web servers are made by development teams, also known as backend developers. A website's backend is the server that the website uses to allow users to interact with stored data displayed on the website. These backend developers need to create the logic of an application that lives in the cloud. This logic is coded to instruct a database to pass data to and from the user. A backend developer also creates an authentication layer that helps prevent the application from experiencing malicious attacks. Fortunately, the Serverless Architecture helps development teams. The Serverless Architecture is the better option for development teams to build web applications by allowing teams to not worry about building and maintaining servers, pay-per-use of the function, and to not worry about scaling their application.
Simple
The complexity that it takes to design a traditional web server is reduced when teams switch to a Serverless Architecture. When I would design an application, I would spend more time designing the backend than I would the user interface. For example, I needed to design a web application that allowed users to register for an account, sign in to that account, and sign up for a time to get maintenance done on their car. Using an older technology to build this web application took almost a week. Now that I develop with the Serverless Architecture, I can get a web application up and running in a few days. This has saved me a metaphorical cost of time. One of the most expensive elements of developing a website is developing and hosting the backend. Hosting is when the development team publishes their code to a server provider. The backend has many components that are challenging to build. A development team needs to program a way that users can sign up/sign in to a web application. This system needs a database, to hold user information. With that database, a development team needs to code a system to communicate with that database. This communication also needs to be secured to prevent attacks or data leaks. Depending on the needs of the application, the server also needs to perform calculations or data manipulation, to evaluate if an address that is entered is a valid address to ship too. With these components needed for a backend developer to design and code during the creation of the web application, there is a simple solution. Developing the same logic into a serverless function is faster to develop, files are manageable, and functions are deployed in an instant. Paul Castro and the authors of “The server is dead, long live the server: Rise of Serverless Computing, Overview of Current State and Future Trends in Research and Industry” describe what many development teams are turning to the Serverless Architecture as “it provides developers with a simplified programming model for creating cloud applications that abstracts away most, if not all, operational concerns.” (Castro, 44 - 46).
Cost Benefits
When developing for a traditional web server, the cost to deploy the application on a companies hosting platform is a flat, monthly rate. This will vary from company to company, as the starting cost for a small team could be between 25 dollars to a custom pricing model set up by the hosting company. Deploying a web server that is “always on” day and night is very costly, especially if the website or application is new and does not receive high traffic right away or if the application is only meant for a small user base. Having an always-on server when no one is using the server means the development team is paying to have the website or application ready to go day in and day out. Having the option to only pay when the server is being used can save the development team money on their website or application budget. The authors of the article “Formal Foundations of Serverless Computing” discuss their view on how the Serverless Architecture can save development teams money saying, “an economic advantage of serverless functions is that they only incur costs for the time spent processing events. Therefore, a function that is never invoked incurs no cost. By contrast, virtual machines incur costs when they are idle, and they need idle capacity to smoothly handle unexpected increases in demand.” (Jangda, 2) The money saved from using the Serverless Architecture can be used to fund further development of the website or application. Matt Crane and Jimmy Lin of “An Exploration of Serverless Architectures for Information Retrieval” conducted an experiment to calculate the cost of a web application running on the serverless architecture versus the standard server. They begin by talking about the cost of their standard server, then evaluate the cost of the Serverless Architecture. Here is what they found;
This instance costs USD$1.33 per hour regardless of load, which means that the cost is the same whether the server executes zero, one, or one million queries in any given hour. On the other hand, Lambda is charged on a per-request basis in increments of 100ms. The average billable time for our system was 1887ms per query, which translates to USD$0.000047951.
When Matt and Jimmy ran their experiment, they noticed that the standard server has a flat, hourly rate, even when the application was getting no use. When traffic increases on the website or application not using the Serverless Architecture, the development team has to worry about making sure that the current server can handle the new usage load. If the current server can not handle the new load, the development team needs to scramble to either make a load balancer to help manage the increase of traffic or scale the application across many physical servers, which increases cost. However, the Serverless Architecture’s pay-per-use cost model, is able to save development teams money in the long run.
Scalability
Being able to scale an application as the user base grows is an essential part of software development. Applications are developed to handle a growth in the user base, and having the right server is important for this process. In traditional web development, servers are connected to a load balancer that helps control traffic by direct client requests to different physical servers. For example, a development might deploy their application to five different physical servers that each handle about 100 users. The load balancer would then distribute users between the five servers to prevent “server one” from being overloaded with more than 100 users. When the development team sees that more users are accessing their application, they can then add another physical server to handle the new users. Brian Zambrano, the author of the book “Serverless Design Patterns and Best Practices” describes how autoscaling can benefit development teams, “before this, managing horizontal scalability was an exercise for the team designing the system. Never has horizontal scalability for computing resources been so easy.” (Zambrano, 10) With the Serverless Architecture, this scaling is handled automatically by the hosting provider, such as Amazon Web Services or Google Cloud. Since these serverless functions are brought to life when needed, there is no need to deploy the application to separate physical servers. The hosting company has already designed their physical servers to handle the Serverless Architecture. Then as a website or application sees increased users, the hosting companies' physical servers handle the scaling logic needed to create the space needed for that website or application. “By limiting time of execution and not allowing functions to keep persistent state FaaS platforms can be easily maintained and scaled by service providers.” (Castro, 47) Development teams only need to push the code for the website or application to the hosting company and the hosting company handles the rest, including maintenance of the servers.
Cold Start
The “Cold Start” is a common downfall of the Serverless Architecture. When a website or application does not see heavy traffic, the hosting company will turn off that function. This will cause a delay when the next user comes along to use that function. Abhinav Jangda, Donald Pickney, et al. who wrote “Patterns for Serverless Functions (Function-as-a-Service): A Multivocal Literature Review” explain how the cold start serverless functions are handled saying, “serverless functions are executed in containers that encapsulate and execute them. When they are invoked, the container keeps on running only for a certain time period after the execution of the function (warm) and if another request comes in before the shutdown, the request is served instantaneously.” (Taibi, 7) When the function gets invoked, the hosting company will need to create an instance of that function from scratch, as the company most likely did not cache, or temporarily save for future use, that function. As a result, the user who requested the function will need to wait as the function has a “cold start” while the hosting company's servers get the function ready to go. The authors from “The Server is Dead, Long Live the Server” raised a great solution for the “Cold Start”. They said “cold start problems can be mitigated by techniques such as maintaining a pool of uninstantiated stem cell containers, which are containers that have been previously instantiated but not assigned to a particular user, or reuse a warm container that have been previously invoked for the same user.” (Castro, 50) The authors mentioned containers and users. These containers hold the serverless function and the user is either the client making the request or the website, depending on the use case The solution presented allows for hosting companies to provide a sort of a bucket to keep old instantiations, or single instances, of a function warm for an application. This is similar to how a computer will cache web files from commonly visited websites, allowing for faster load times when a user revisits the same website.
Conclusion
The Serverless Architecture offers development teams many cost saving benefits. Development teams do not need to worry about spending money on maintaining physical hardware as the hosting company will take care of that for them. They do not need to scale the website or application as the user base grows since it is handled automatically. The cost of use for serverless functions are pay-per-use, which is far cheaper than paying a flat monthly fee. The Serverless Architecture is the better option for development teams to build web applications by allowing teams to not worry about building and maintaining servers, pay-per-use of the function, and to not worry about scaling their application.
Works Cited
Castro, Paul, et al. “The Server Is Dead, Long Live the Server: The Rise of Serverless Computing.” Communications of the ACM, vol. 62, no. 12, Dec. 2019, pp. 44–54. EBSCOhost, doi:10.1145/3368454. 15 Nov. 2020
Crane, Matt “An Exploration of Serverless Architectures for Information Retrieval.” Proceedings of the ACM SIGIR International Conference on Theory of Information Retrieval, 2017, pp. 241–44. Crossref, doi:10.1145/3121050.3121086. 17 Nov. 2020
Jangda, Abhinav, et al. “Formal Foundations of Serverless Computing.” Proceedings of the ACM on Programming Languages, vol. 3, no. OOPSLA, Oct. 2019, pp. 1–26., doi:10.1145/3360575. 17 Nov. 2020
Taibi, Davide, et al. “Patterns for Serverless Functions (Function-as-a-Service): A Multivocal Literature Review.” Proceedings of the 10th International Conference on Cloud Computing and Services Science, May 2020, doi:10.5220/0009578501810192. 16 Nov. 2020
Zambrano, Brian. Serverless Design Patterns and Best Practices : Build, Secure, and Deploy Enterprise Ready Serverless Applications with AWS to Improve Developer Productivity. Packt Publishing, 2018. EBSCOhost, search.ebscohost.com/login.aspx?direct=true&AuthType=ip&db=cat03146a&AN=BYUID.5100890&site=eds-live&scope=site. 17 Nov. 2020
Top comments (0)