Birthday Sale! Up to 40% off unlimited courses & creative assets Birthday Sale! Save up to 40%!

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

1.2 What Is Serverless?

In this lesson, 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.

1.2 What Is Serverless?

Hi, and welcome back to Introduction to Serverless. In this lesson I'm going to talk about the serverless concept and why you might want to use it. 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. 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. The next layer of abstraction is containers as a service. It is also rather new player that has got a lot of traction due to the popularity of Tucker. In an AWS world, this would be EC2 Container Services. Then we have platform as a service, you aren't responsible for managing any operating system or containers. You are solely responsible for your application. Permanent examples from this category are a Heroku, AWS Elastic Bean Stalk, or Google Compute Engine. A few years back the graphic would have ended here, 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. 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. May just 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. 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. 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. 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. 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 1000 times, you pay for 1000. It's a bit more complicated than that of course, but that's the gist of it. 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 is 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. In the next lesson we are going to tackle functions, the main concept of serverless. See you there.

Back to the top