Serverless Computing

Serverless computing is a form of cloud computing that allows users to run event-driven and granularly billed applications, without having to address the operational logic.

Function as a service (FaaS) is a form of serverless computing in which the cloud provider manages the resources, lifecycle, and event-driven execution of user-provided functions.

One of the latest developments in cloud computing is usually called “serverless” computing, even though, of course, servers are still where processing takes place.

For example, Amazon Web Services (AWS) offers “Lambda Functions,” Google has “Cloud Functions.” and Microsoft has “Azure Functions”

Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform.

By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component.

Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services.

Fundamentally, FaaS is about running backend code without managing your own server systems or your own long-lived server applications.

That second clause—long-lived server applications—is a key difference when comparing with other modern architectural trends like containers and PaaS (Platform as a Service).

If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless.

I wonder if serverless services will become a thing like stored procedures, a good idea that quickly turns into massive technical debt.

Serverless architectures are internet based systems where the application development does not use the usual server process.

Instead they rely solely on a combination of third-party services, client-side logic, and service hosted remote procedure calls (FaaS).

The headlines that we hear a lot about with serverless are that it’s so much cheaper to use. And I think there’s truth to that. Sometimes that drives businesses to look at serverless.

But what I’ve found is that most businesses embracing serverless are actually doing it because of the velocity that it adds to their team.

They find that they’re able to build and release products much more quickly using serverless infrastructure because they have to do less work in planning and managing for capacity, scaling the application.

One of the trends that I’ve heard discussed is this idea of no ops. That as a managed service there’s no operational responsible for an enterprise consuming serverless or function as a service offering. That is simply not true.

Now there are parts of operations that in fact do get outsourced to the cloud provider. Availability is clearly outsourced. Scaling is outsourced. Orchestration is outsourced in a serverless model.

But there’s huge parts of operations that are not being outsourced. So managing and maintaining the health of the application. That’s certainly not being outsourced. How you build and release an application with automation and reliability. That’s not being outsourced.

Serverless computing is meant to let businesses and application developers focus on the program they need to run and not worry at all about the machine it is on or the resources it requires.

Serverless computing is just the latest option in cloud computing's "as a service" model.

Different versions of the model—infrastructure as a service, software as a service, and platform as a service—have cloud providers offering customers different levels of resources, from software subscriptions to full computing systems. Serverless is a fourth category: functions as a service.

Functions as a service is even more magical. You don't even think about the runtime that you're using. You just write a blob of code and we will run it for you. You have to use our language, and you have to use it in a way that we are okay with; you have to use the libraries we offer. But if you use it in those bounds, man, your life is easy.

Serverless has the potential to be a great abstraction offering economic advantages for simple workflows, but beware of throwing everything into it too hastily.

If your functions/APIs will use a whole compute instance, it's probably cheaper to get the instance—but you need to bear in mind the operational overhead of that path as well. Again, consider what you will be paying for.

Even though serverless might be 3x the cost of on-demand compute, it might save DevOps cost in setting up autoscale, managing security patches and debugging issues with load balancers at scale.