Serverless computing... is a lie! Seriously though, it isn't a real thing. It's just the name that's a bit misleading. In this article I'm going to explain what serverless architecture is, and how it can save you time and money.
So how can you run applications without any servers? You can't. Prepare yourself for this. Serverless infrastructure runs on... servers. It's not magic. It's not powered by fairy dust. It runs on servers, just like everything else. It's called "serverless", not because there aren't any servers involved; but because you don't need to know anything about them.
Serverless is a way of building applications from cloud-native components. I'm going to give you an example of how that can be done later in this article, and then we can look at the pros and cons, but first let's try and position serverless computing amongst the rest of our cloud services.
When it comes to cloud, there are a bazillion "as a service" acronyms floating around; but in general, cloud services can be broken down into these three.
- Infrastructure as a Service (IaaS)
- Platform as a Service (PaaS)
- Software as a Service (SaaS)
As you move from top to bottom, you increase the degree of abstraction - meaning you've outsourced more responsibility for the underlying infrastructure components. That means there's less for you to worry about, but the flip-side is you lose some control. The degree of control you get moves in the opposite direction - increasing from bottom to top. With Infrastructure as a Service you're responsible for pretty much everything, bar the hardware. You manage the operating system, the full server and software stack, and the application itself; and you can tweak each of them as required. On the other end of the scale, with Software as a Service you pay your money and you get the service. You don't need to worry about how it works, but it does what it does, and there's not a lot of opportunity to change how it behaves.
So where does serverless fit on this scale? Serverless lands somewhere between PaaS and SaaS. I consider it a type of Platform as a Service, but towards a higher abstraction end of Platform as a Service.
Serverless sometimes gets designated the name "Function as a Service", but there are enough "as a service" acronyms already, and some of the products currently marketed as serverless were already being marketed as Platform as a Service before that became a trendy name.
The line between serverless architecture and traditional Platform as a Service lies in how your application is composed. Applications composed using traditional Platform as a Service are constructed in much the same way as with full servers. You just mask off a chunk of the underlying infrastructure complexity, and make it someone else's problem.
Applications composed using a serverless approach need to be designed a little differently. Essentially, they are broken down into single-purpose autonomous functions. You have no control over where these functions get executed, so they have to be self-contained and assume no persistent application state. This is different from traditional Platform as a Service, where although you might not have visibility of the underlying server you at least know of its existence; and you know your code is running on a server that is going to persist between executions.
The best way to explain this is with an example. Let's imagine a simple web app where we've got a text field, and as we type into it the page content dynamically updates. Think of something like the search bar on YouTube that presents you with updated suggestions as you type. Here's a representation of the different layers that might be involved in a traditional server infrastructure.
Now let's convert this to a cloud-hosted equivalent, using Infrastructure as a Service. All of the physical nuts and bolts become someone else's problem, and we just have to deal with the operating system and everything else above it inside managed virtual machines. Taking this a step further, let's move to Platform as a Service. AWS and Azure are the two biggest players here, and both have the ability to host managed database instances where the underlying server is abstracted away. So that's our data component taken care of. Both of these platforms also allow for the web server to be hosted as a managed entity, where you get a bit of control, but a lot is hidden from you. You primarily manage the code and the data, and the vendor manages most of everything else. In Azure this would be done using an App Service, and in AWS you'd use an Elastic Beanstalk; because whoever names Amazon's AWS products is clearly on some pretty exotic drugs!
While this abstracts away a lot the underlying complexity, it doesn't remove all of it. You still need to choose an underlying web server. You still need to design for scalability and resilience. AWS and Azure can automate scaling up and scaling down, but you need to define how and when to do this, and design your application to support it. Even though you can't get access to it, there is still a web server hosting your app, and you need to pay for its resources that it's consuming over time... whether or not it's actually doing anything useful with them.
To provide the rest of our app's functionality we need somewhere to run our code. We can do this using a Function in azure or Lambda Function in AWS. Same thing, different vendor. These functions aren't connected to a website - they're just somewhere to execute code when triggered. Where this code gets executed is the vendor's problem to solve.
With Infrastructure as a Service or Platform as a Service you're paying to keep the server running all the while you want your app to be available. With serverless you're only paying when it's actually in use. It's always available, but it's only when someone starts interacting with it that you incur costs. This can be advantageous, by correlating running costs directly to the benefits you derive from it; although the flip side is it can make your costs more unpredictable as a result.
Another benefit of serverless is that it allows developers to deploy their apps directly to the cloud, without having to rely too much on infrastructure people; who tend to ask annoying questions like "How many people will be using this app", "Where are they based?", and "What resilience do you need?". You know... the kind of boring questions that developers don't always want to concern themselves with. Those questions are still important, by the way. Just because you can deploy it without giving thought to it, doesn't mean you should. Certainly, once it's been deployed *properly*, there's a lot less maintenance for your infrastructure team to worry about with serverless architecture. Especially as serverless architecture is very easy to scale. Because you have to break your apps down into decoupled components in order to use serverless architecture, most of them will simply scale automatically. More users requesting content? Amazon's global S3 service takes care of that. More calls to code in functions? Azure spins up more resources to process them. Their problem. Not yours.
Read also: Is the Cloud Secure Enough?
There are some disadvantages though. While serverless architecture can be a major cost-saving for low-usage apps, because you're not being charged when they're idle; the other side of that coin is that a very heavily utilized app can rack up costs pretty quickly. Debugging can also be an issue. A lot of these components are being handled by a proprietary third party service. If you're trying to get the bottom of an issue, it's not like you can just spin up a replica environment on your laptop.
Finally, and perhaps most significantly: there is a high degree of vendor lock-in. If you build an application using Amazon's serverless cloud components, your application is completely reliant on Amazon's cloud. You can't easily pick it up and run it somewhere else as you could with a more traditionally deployed app. This introduces some risks for you to consider. What does it mean if Microsoft decides to double the price of Function execution time? Your costs go up. Significantly. What if Amazon decides they no longer want to support Java in their Lambda Functions, and that's what you were using? Well, now you need to rewrite your code or your app will stop working. This sort of thing does happen: PowerApps anyone?
I suggest that it would be prudent to make an exit plan when you make a significant investment in serverless. In other words, have a plan for how you'll transition your apps away should it at some point in the future cease to be viable. By doing this you will have quantified and managed the risk; so if your chosen vendor does suddenly drop you in it, you've got a Plan B ready to go. This can avoid a whole lot of panicked re-engineering and spiraling costs. The best way to learn more about serverless computing is to have a play with it.