What is Serverless Architecture and Why Is Everyone Talking About It?

6 min readAug 13, 2018

When the average person thinks about web applications, they think of the interface and features. These make up the front end of an application, and that’s only half of the story. The other half is the connections, databases, bandwidth, and servers that make a web application run in the first place. The end user will never see the back end of a web application, but if the back end isn’t well optimized, load tested, or scaled, the end user will definitely notice in slow load times and broken features. The thing is, optimizing, load balancing, and autoscaling server capacity is a difficult and complex job. However, a new approach to the backend of web development promises to make that job easier.

Serverless architecture is rapidly gaining notoriety as a new way to design, manage, and scale a web application backend. In serverless, the server provider manages and automatically scales computing power for your app. The name can be confusing. Serverless is actually a misnomer. There are still servers, but the app developer no longer has to worry about those servers. Instead, the provider takes care of the work of tuning server use based on load.

All the major cloud providers — Amazon, Google, Microsoft, IBM — have begun building serverless offerings. Serverless is likely to be the future of web app infrastructure and backend development. This article explores the new trend and what makes it so exciting.

The New Paradigm

For backend developers, serverless is a huge relief. Traditionally, if you needed computing power and storage for your web app, you’d have to pay for the server capacity ahead of time. When your app needed to scale up or down, it’s up to you to set up systems for that scaling and pay for the new resources or free up unused resources and downgrade your server needs.

Serverless turns that model on its head. Now the server provider takes on the responsibility of scaling, and you only pay for the server capacity that you use. Serverless architecture implements systems for operating seamlessly whether your app has two users or two million. That’s a big promise, and it’ll be amazing for web development once serverless becomes standardized and commonplace.

However, there are still many hurdles in the way for developers adopting the new architecture. Implementing serverless also requires more time up front, and it comes with a heavy learning curve. However, as developers learn serverless and the tools become easier to use, its popularity is sure to increase since it makes backend management so much easier.

How Does It Work?

In traditional web development, a user’s browser connects directly to the web app’s server. From there, the app’s server makes requests of other functions, databases, and services that make up the web app. The server assembles those various parts and serves it to the end user’s browser.

Serverless changes things by breaking apart the various functions, databases, and services that go into the app. For example, in some cases the user’s browser might be able to connect directly to an authentication service, database, or API without needing to go through the app’s server. All the app’s various components come together through a serverless API. Each component runs separately on the server, and the server provider can spool up or down any service or component as needed.

Serverless Pros & Cons

One of serverless’s biggest advantages is its cost effectiveness. Pricing generally runs on a backend-as-a-service model where you only pay for the server capacity that you use. Compared to renting a fixed amount of server capacity or owning and operating your own servers, serverless promises big savings. This is especially true during idle or low utilization periods. Even if your app implements an autoscaling group on rented servers, serverless can be more efficient due to the server provider controlling and optimizing bin-packing.

Serverless architecture also has the potential to be more efficient with backend developers’ time. Setting up a serverless app takes more work up front, but that pays off later in time not spent on load balancing, creating and tuning autoscaling schemes, or otherwise maintaining servers. Additionally, since the serverless app uses a REST API to call its components, backend developers don’t need to worry about HTTP requests or multithreading.

The reason why serverless apps are more time consuming to create is because of granularity. It takes a lot of time to decide how many components go into a serverless app and how big each of those components will be. If you make them too small, it will be difficult to manage all the many moving parts as individual components spool up and down independently on the new architecture. If you make them too big, each component becomes its own inefficient monolith, undermining the advantages of serverless to begin with.

Despite its advantages, serverless does have shortcomings. Currently, the documentation, tools, and capabilities of serverless are limited, but the community of serverless devs is growing. Additionally, serverless can’t work for high-end, performance computing applications due to limits on resources. It’s also not well-suited to applications where runtimes take a while to start back up (e.g. Java), because the server provider will spin down the code completely when it’s not in use. This stop and start can lead to latency issues.

Conclusion

Serverless architecture takes a lot of work out of backend development by separating components and automating scaling of each component. While it takes longer to initially create a serverless app, the architecture pays benefits in maintenance over time. Reduced ongoing costs and less developer time spent on fine tuning make serverless a cost-effective solution for many companies. While most won’t develop serverless apps from scratch right away, expect serverless features to replace or extend existing features in otherwise traditional apps. Hybrid serverless-traditional projects will spell the beginning of the transition to serverless in the long run.