What is a Serverless Architecture?

Serverless architecture is one of the most cutting edge and advanced approaches to cloud computing today. With a serverless architecture, you can serve your application or workload literally without servers. Learn how a serverless architecture works and when you might use a serverless architecture.

• How can you have no servers?
  • Serverless application design
  • Development tools
  • Function-as-a-Service (FaaS)
• When do you use a serverless architecture?

How can you have no servers?

Serverless architecture uses advancements in application design, development tools, and function-as-a-service to build a complete application experience on an entirely on-demand basis.

Of course, there are servers behind the systems, typically part of a cloud based infrastructure like our IaaS. The concept of “serverless” comes from the user’s standpoint and not having to worry about those details.

Serverless application design

Your application must be designed from the beginning for a serverless architecture for the best results. Serverless applications are the most commonly dynamic mobile or web applications that are served from Content Delivery Networks or Static Web Hosting on a cloud storage platform like Ceph.

Serverless web applications are commonly JavaScript applications that are designed to operate entirely with the end user’s browser and load any required data asynchronously using additional background HTTP requests.

The JavaScript applications themselves can be served as-is from Content Delivery Networks or cloud storage platforms because they are simple HTML, CSS, JavaScript, and other static files that do not require dynamic evaluation when loading. This means you do not have to configure your own server to serve these files.

Development tools

Serverless applications are possible because of the tools developed over the last couple of years for new approaches to application development. One of the newest trends in JavaScript and other web application development languages is compiling all of the application’s HTML, CSS, and client-side code ahead of time to a static format that can be served directly to users.

This is in contrast to more traditional styles of application development where the application’s HTML, CSS, and client-side code is dynamically generated for every single visitor. Dynamically generating the page when a visitor requests the page requires a server to process the request and run the code to generate the page. This is commonly how PHP and Python web applications function.

Several development tools exist now for packaging web applications written in various languages as static HTML, CSS, JavaScript, and client-side code, such as Web Assembly, that can be served directly to browsers from Content Delivery Networks or Static Web Hosting as discussed previously. The visitor’s browser executes the code and runs the application, instead of relying on a server to handle all the work.

Function-as-a-Service (FaaS)

Function-as-a-Service is one of the most significant innovations in cloud computing. You can use FaaS to service requests for data or processing that would normally be handled by a persistent server application without the server and in an entirely on-demand fashion. To use function-as-a-service, you define cloud functions that each execute a single bit of code for a specific task, and your application sends HTTP requests to the service provider to trigger specific cloud functions instead of sending requests to a persistent HTTP API server.

With function-as-a-service you can literally only use the resources your application uses. There are no idle resources or wasted utilization with function-as-a-service because each cloud function only lasts for as long as it takes to process the request. The CPU and memory (RAM) resources are released as soon as the function completes its job.

With a serverless architecture, cloud functions replace the HTTP API server. Your server-side code has to be engineered to support an extremely strict microservices architecture where every task normally handled by a persistent server is broken down into blocks of code that can be executed as a cloud function.

Other features like authentication, firewalls, and caching are handled by the function-as-a-service platform and are defined and managed separately from your cloud functions.

When do you use a serverless architecture?

IT Departments are often called on to provide all kinds of resources and serverless architectures will fit in this as well. As those services can be tricky to keep track of, you will want a solid governance model. Additionally, you will have a centralized infrastructure, ideally IaaS or object storage on demand, for data storage of your application that is stateful. This is typically very different usage patterns so be ready to do both.

Serverless architecture is a great fit for applications that can run entirely within users’ browsers or on mobile devices. Much of the processing and work for the application can be pushed onto the users’ own devices instead of application servers or databases. Distributing your application’s workload to your users’ devices instead of application servers you run helps make your application or platform much more scalable while still giving your users a responsive, high-performance experience.

Serverless architecture is also excellent for applications that need to be quickly accessible for users in different parts of the world. Serving your application’s code from a Content Delivery Network should mean that users anywhere on the planet can quickly load your application, and many function-as-a-service providers have localized services around the world for providing cloud functions closer to users in different parts of the world.

A serverless architecture can also be significantly cheaper than other architectures that are dependent on persistent servers for serving application code or processing application requests. Content Delivery Networks and Static Web Hosting are usually significantly cheaper for serving your application than running your own servers because serving static files is extremely easy and efficient to do, especially at large scales.

Using function-as-a-service instead of a persistent also ensures that you only pay for the resources that you use to service your users’ requests and nothing else. If you were to use a persistent server instead of function-as-a-service, you would still have to pay for the server during all the times your users are not making requests or using the server’s resources. As products and applications grow, these resource costs can quickly become very expensive.