You can also watch the video version of this here: https://youtu.be/OtOqhjK_nd4
Serverless is a means to develop cloud-native applications that run on servers fully managed by the cloud provider instead of yourself.
The term ‘Serverless’ is a bit of a misnomer. There are definitely servers involved in this process, but it refers to the fact that your team isn't managing any servers. They don't even have access to the servers as they are managed entirely by the cloud provider, including the operating system, the software and many other supporting components. Scaling, redundancy, backups and, to some extent, security is also taken care of by the cloud provider.
More responsibility with the cloud provider means that the team can focus on those aspects that are going to give you your return on investment or ROI. Their focus will be on configuring the cloud services, which is not to be underestimated - a lot of recent hacks are due to misconfigurations in cloud services, and they will be focusing on the application code itself. The plumbing and other necessary components that don't directly contribute to the ROI will take up significantly less of their time.
Above, I mentioned the term ‘cloud-native’. This means that an application has been developed specifically for the cloud, as opposed to an application that was designed for an internal data centre - even if the application was moved to the cloud later. Cloud-native doesn't necessarily mean that it's Serverless; it could have been developed to run on servers in the cloud. I use the term ‘Serverless’ because of this ambiguity with ‘cloud-native’.
True Serverless, pure Serverless or fully Serverless are terms that refer to services that are both fully managed and billed only based on actual utilisation. Fully managed is a fundamental requirement for Serverless, and this should include management of the servers, operating system, the software and the platform by the cloud provider. Billing based on actual utilisation means that you should never be paying for idle time. That is the time that the service is running, but nobody's using it. Servers are a clear example of billing for idle time.
Let's give that some context to make it more clear. If you want to host a web application in the cloud, you have three options.
- You can put it on a server, which you would lease from the cloud provider and you pay a monthly amount for regardless of how much the server is being used. Whether you have one user on the server in a month or 1000, you will just be billed the monthly server fee. While the cloud provider is responsible for the network and the infrastructure for that server, you are responsible for picking the operating system. Making sure it's configured, hardened, maintained as well as the software and everything that runs on the server, and your application code. You are also responsible for backups and redundancy - what happens if the server crashes?
- You can use a fully managed hosting service provided by the cloud for hosting applications. Fully managed means you don’t need to manage the operating system or the software; you just configure the platform and deploy your application. Redundancy and scaling are also readily available as part of the service. This service still bills a fixed monthly amount regardless of utilisation, however.
- Serverless is the third option, and it is like fully managed, but this service can switch itself off when there are no requests. You are only billed for the number of requests and for the time that the service is running in response to a request.
To further underscore that point with a real example, let's take a registration form that needs to be made available through one of the three options. The form will have four users per day, and processing the form takes five seconds. That means the form will be utilised for 20 seconds each day.
If you put it on the server, you would need to set up the operating system, software, harden it, patch any security issues while it was running, set up a backup and have some solution in place to deal with the server crashing. All of this is probably not worth it for a registration form and as-such, you might not do it, which leaves the server vulnerable and a potential security risk.
Fully managed would take away all those overheads, you could get the form live the same day and not have to worry about operations so much. However, you will be billed for 24 hours of running the server when it's really only being used for 20 seconds.
With Serverless, you won't have the operational overheads, and you will only be paying for the 20 seconds that it is actually being utilised. That is the cost-effectiveness and premise of Serverless.
What Serverless is not
Besides explaining what Serverless is, I also like to talk about what it is not. It's not the end-all; Serverless is not going to replace every other way of building applications. It's a very powerful tool, but, as with any tool, you need to pick the right tool for the job. There are projects and entire organisations for which Serverless is not suitable for several reasons. We should always assess the project’s short and long term requirements and make technology decisions based on those and not because it's a buzzword.
To go deeper on this topic and to read many more related topics about Serverless Architecture please buy the book Serverless - Beyond the buzzword here: serverlessbook.co
