The serverless computing concept is an up-and-coming execution model that tries to address the needs of modern, cloud-based software.
In this video from my course, Introduction to Serverless, I'll introduce you to the serverless architecture. We'll talk about its key points and compare it to other models for abstracting server functionality to the cloud.
What Is Serverless?
The Serverless Architecture
First of all, in a serverless system, there are servers. Hopefully, that isn't a big surprise to you. It's all about who manages them.
Let's have a look at a very common diagram that shows different kinds of services.
On the left, you have your traditional on-premises system. Everything is managed by you, right down to the physical machine and the network. Then you have various levels of abstraction.
Infrastructure as a Service
The first level of abstraction is infrastructure as a service. Here you are responsible for everything from the operating system up. Examples would be DigitalOcean or Amazon's EC2. The provider provisions an instance for you, and from that point on, you are on your own.
Container as a Service
The next layer of abstraction is container as a service. It is also a rather new player that has got a lot of traction due to the popularity of Docker. In an AWS world, this would be EC2 Container Services.
Platform as a Service
Then we have platform as a service, in which you aren't responsible for managing any operating system or containers. You are solely responsible for your application. Prominent examples from this category are Heroku, AWS Elastic Beanstalk, and Google Compute Engine.
Functions as a Service (aka Serverless)
A few years back, the graphic would have ended here. But nowadays we have a new terminology, that is, functions as a service. Instead of running an application that has state, which is true for all traditional web frameworks, even though you're using REST and other things, you have a system that uses stateless containers that are event triggered, ephemeral, and completely managed by the service provider.
This is what is called serverless. There is another concept called back end as a service that's sometimes also considered part of the server's architecture. But in my opinion, it belongs more to software as a service, which is essentially what you are trying to build.
Key Areas of Functions as a Service
So let's talk more about functions as a service.
As the name suggests, you as the developer are responsible for writing executable functions that are triggered and executed by events. This may be a completed file upload to S3 or a request through an API endpoint. So far, so simple. To completely understand the concept, though, I'm going to talk about a few key areas that define functions as a service.
State
The first one is state. Functions are very limited when it comes to preserving state. Generally, you should assume that you can't do it at all. Functions follow more of a fire and forget principle. If you want to store anything, do it with an external service, like file storage or a database or cache server.
Execution Duration
The second is execution duration. You might have a server application that is running for hours or days without restarting, depending on your deployment process. The same goes for background processing. With functions, the execution time is limited. It's not expected that the function executes for more than a few seconds, and AWS Lambda, for instance, terminates every function that hasn't finished running after five minutes. If you have a very long-running task, then functions as a service might not be the best fit.
Startup Latency
Then we have startup latency. This can be everything between a few milliseconds and minutes. Of course, this depends on the language and system you are using. Typically, a Python or JavaScript function on AWS starts within milliseconds, but if you are using the Java Virtual Machine, it might take a while until the machine is spun up—especially if your function hasn't been executed in the last ten minutes, or you experience a sudden surge in execution.
Scalability and Cost
This leads to questions about scalability and execution cost, and the answer you're looking for is: don't worry about it. Scaling is managed by the service provider, and cost is simple.
If you're executing a function ten times, you pay for exactly these ten invocations. If you're running 1,000 times, you pay for 1,000. It's a bit more complicated than that, of course, but that's the gist of it.
Conclusion
Having a serverless system can be very advantageous. It is great if you have inconsistent traffic—for instance, a spike at the top of the hour, or very few occasional requests, as you don't have to allocate resources which are idle most of the time.
To recap, serverless systems have servers, but they are completely managed by cloud providers. Functions are the core of a serverless architecture and they're executed by using triggers. Scaling and high availability are already taken care of by the cloud providers. If you have very occasional demand, or a big but short search, serverless helps you keep your cost down.
Watch the Full Course
In the full course, Introduction to Serverless, I'll show you how to use Amazon Web Services to create a "serverless" web app, complete with a REST API back-end. You'll also see how to deal with some advanced scenarios like integrating other AWS services and orchestrating state-aware functions. Along the way, you'll build a cool web service to convert text to speech.
You can take this course straight away with a subscription to Envato Elements. For a single low monthly fee, you get access not only to this course, but also to our growing library of over 1,000 video courses and industry-leading eBooks on Envato Tuts+.
Plus you now get unlimited downloads from the huge Envato Elements library of 400,000+ creative assets. Create with unique fonts, photos, graphics and templates, and deliver better projects faster.
