To summarize, the blog Use-Cases are:
- What is Serverless Architecture?
- Why Serverless Architecture?
- An Example of Website selling tickets: Front-end and Back-end collaborations
Two Strategic Questions on Front-End and Back-End collaborations
Question 1: What are backend services? What’s the difference between frontend and backend?
Question 02: What kind of backend services can serverless computing provide?How does Serverless or FaaS Differ from PaaS?
- What is next for serverless?- The Cold Starts
- 2x Notes for Reader
Note A: Degree of Automation in Diffferent Cloud Stack {IaaS, PaaS, SaaS, BaaS, FaaS}
Note B: Reliability, Scalability and Maintainability in Serverless architecture
Serverless architecture (also known as serverless computing or function as a service, FaaS) is a software design pattern where applications are hosted by a third-party service, eliminating the need for server software and hardware management by the developer. Applications are broken up into individual functions that can be invoked and scaled individually.
The term ‘serverless’ is somewhat misleading, as there are still servers providing these backend services, but all of the server space and infrastructure concerns are handled by the vendor. Serverless means that the developers can do their work without having to worry about servers at all.
Before I am going through details on what is serverles architecture, let’s imagine a website that sells concert tickets.
- When a user types a website address into the browser window, the browser sends a request to the backend server, which responds with the website data.
- The user will then see the frontend of the website, which can include content such as text, images, and form fields for the user to fill out.
- The user can then interact with one of the form fields on the frontend to search for their favorite musical act.
- When the user clicks on ‘submit’, this will trigger another request to the backend.
- The backend code checks its database to see if a performer with this name exists, and if so, when they will be playing next, and how many tickets are available.
- The backend will then pass that data back to the frontend, and the frontend will display the results in a way that makes sense to the user.
- Similarly, when the user creates an account and enters financial information to buy the tickets, another back-and-forth communication between the frontend and backend will occur.
Two Strategic Questions on Front-End and Back-End collaborations
- Qustion 1: What are backend services? What’s the difference between frontend and backend?
Application development is generally split into two realms: the frontend and the backend.
- The frontend is the part of the application that users see and interact with, such as the visual layout.
- The backend is the part that the user doesn’t see; this includes the server where the application's files live and the database where user data and business logic is persisted.
- Question 02: What kind of backend services can serverless computing provide?
Note: for now, this term and usage might be little unfamiliar to you. So escape it and jump to Section 1.1 and then return here and read to understand in-depth.
Most serverless providers offer database and storage services to their customers, and many also have Function-as-a-Service (FaaS) platforms like AWS Lambda.
- FaaS allows developers to execute small pieces of code on the network edge.
- With FaaS, developers can build a modular architecture, making a codebase that is more scalable without having to spend resources on maintaining the underlying backend.
1.1 Why Serverless Architecture?
Hosting a software application on the internet usually involves managing some kind of server infrastructure. Typically this means a virtual or physical server that needs to be managed, as well as the operating system and other web server hosting processes required for your application to run.
Using a virtual server from a cloud provider such as Amazon or Microsoft does mean the elimination of the physical hardware concerns, but still requires some level of management of the operating system and the web server software processes.
With a serverless architecture, you focus purely on the individual functions in your application code. Services such as AWS Lambda and Microsoft Azure Functions take care of all the physical hardware, virtual machine operating system, and web server software management. You only need to worry about your code.
1.2 How does Serverless or FaaS Differ from PaaS?
PaaS, or Platform as a Service, products such as Heroku, Azure Web Apps and AWS Elastic Beanstalk offer many of the same benefits as Serverless (sometimes called Function as a Service or FaaS). They do eliminate the need for management of server hardware and software. The primary difference is in the way you compose and deploy your application, and therefore the scalability of your application.
With PaaS, your application is deployed as a single unit and is developed in the traditional way using some kind of web framework like ASP.NET, Flask, Ruby on Rails, Java Servlets, etc.
Scaling is only done at the entire application level. You can decide to run multiple instances of your application to handle additional load.
With FaaS, you compose your application into individual, autonomous functions. Each function is hosted by the FaaS provider and can be scaled automatically as function call frequency increases or decreases. This turns out to be a very cost effective way of paying for compute resources.
You only pay for the times that your functions get called, rather than paying to have your application always on and waiting for requests on so many different instances.
NOTE A: Degree of Automation
Maybe you know the "Cloud Stack" and IaaS, PaaS, and SaaS, as the three layers of this stack. The picture below shows which responsibilities are automated by the vendors of IaaS, PaaS or SaaS solutions.
With serverless there is another concept which degree of automation is in between PaaS and SaaS. To understand serverless you have to separate the application into two different layers: (a) Client (b) Server (Backend)
Dividing the application layer into client and server and adding the serverless stack to the picture above the new picture looks like this:
Sharing resources and costs when using IaaS, PaaS, serverless, SaaS
1.3 Who Should Use Serverless?
You should especially consider using a serverless provider if you have a small number of functions that you need hosted. If your application is more complex, a serverless architecture can still be beneficial, but you will need to architect your application very differently. This may not be feasible if you have an existing application. It may make more sense to migrate small pieces of the application into serverless functions over time.
2. What is next for serverless?- The Cold Starts
Serverless computing continues to evolve as serverless providers come up with solutions to overcome some of its drawbacks. One of these drawbacks is cold starts.
Typically when a particular serverless function has not been called in a while, the provider shuts down the function to save energy and avoid over-provisioning. The next time a user runs an application that calls that function, the serverless provider will have to spin it up fresh and start hosting that function again. This startup time adds significant latency, which is known as a ‘cold start’.
Once the function is up and running it will be served much more rapidly on subsequent requests (warm starts), but if the function is not requested again for a while, the function will once again go dormant. This means the next user to request that function will experience a cold start. Up until fairly recently, cold starts were considered a necessary trade-off of using serverless functions.
NOTE B: Reliability, Scalability and Maintainability
A. Reliability (Failure vs. Fault)
A system is said to be reliable when it is:
- Capable of delivering what’s expected
- Tolerates mistakes from the user
- Operates within acceptable performance thresholds
- Continues to operate in the event of one or multiple faults
When one or a few components of a system start failing or deviating from what’s expected, we have a fault. When the entire system stops delivering, there is a failure.
B. Scalability
A scalable system is one that can continue to perform in a reliable manner under variable and often increasing levels of load.
A system’s scalability is rarely a single variable analysis. It usually involves at least a two-dimensional problem: a load metric and time.
For example:
- How does the database system scales when IOPS1 increases from 1,000 to 10,000 over a period of one second?
- How load time is affected when website pageview requests grow from 200 to 5,000 over one minute?
C. Maintainability
Systems maintenance and expansion cost much more than the initial development. As the project grows and technology evolves, complexity and the list of issues grow. Technical debt haunts developers and the longer it takes, the more ‘interest rates’ accrue over this debt.
This is why future maintainability should be at the top of developers minds when architecting and developing software applications.