This is a transcript of a conversation between Guillermo Raugh, CEO of ZEIT, and Sadek, CEO of Prismic, about Serverless: what does it mean from a developer's point of view, how Serverless functions work, and how to manage the questions of state and startup time.

Watch the video, or scan through the highlights below, or read the entire thing – or do something else. I can't tell you what to do. But seriously, if you're interested in Serverless it is worth watching.

Description

Sadek and Guillermo talk about Serverless. What it is and:

00:34 Definition of Serverless from the developer's point of view.

01:28 How Serverless functions work.

02:23 The question of state and start-up time (cold boot).

Sadek: So I'm here again at Prismic and today I'm with Guillermo from Zeit, I like particularly Zeit for the strategical decisions that you're taking, especially with Serverless, and Next and what you're doing there. Not obvious choices but they're very interesting. Particularly I would like to talk about the Serverless topic and introduce people to what it is. So can you give us your definition, your introduction of what Serverless is?

Serverless is a way of deploying websites and application, where the developer doesn't worry about infrastructure. The infrastructure is outside of the code

Guillermo: Yes, Serverless is a way of deploying websites and application, where the developer doesn't worry about infrastructure. The infrastructure is outside of the code. You don't write severs in your code, and you don't provision servers. Which means there is no monitoring, no overhead. The servers are not running all the time. Which means your code gets invoked completely on demand. Which means you only pay for what you use. If you have one million hits of traffic to your website, you pay exactly for that. And then your code stops running.

Sadek: Does it mean it's only about cost? It's only about cutting costs?

Guillermo: It's not only about cutting costs, it's about making development a lot easier, it's about making development a lot more error free. So an example of Serverless is: your code is a structure that's what we call Serverless functions. When a request comes in, a function is invoked, and the result of that function is returned to the user. And this is how web applications were created, and structured for a very long time.

Sadek: But you're talking about PHP here?

When you're iterating on your application, you're not worried about servers. The server is literally not there, which allows you to focus a hundred percent, literally, on what your users are requesting.

Guillermo: For example. With PHP you'd write a bunch of files in the file system, you would FTP them, nowadays you push them into Git. And when your request comes in, that's when your code executes. So you do some logic, or you talk to a database, or you talk to a cache, you do some processing, and you return some HTML. But when you're iterating on your application, you're not worried about servers. The server is literally not there, which allows you to focus a hundred percent, literally, on what your users are requesting.

Sadek: Right, so basically that means that you should not consider that you're running on the server. So you can't store files, or things in memory, and expect them to be back the next request?

You kind of have to always assume that you're starting from scratch. But that's also a very healthy thing, because you write very robust code.

Guillermo: Yeah, so the question of state is very nuanced. The idea of Serverless functions is that they're not always running. So as a developer you can't make an assumption of what's in memory, you can't think "am I connected to a database?" You kind of have to always assume that you're starting from scratch. But that's also a very healthy thing, because you write very robust code. You don't make assumptions that "Oh, my database is connected, therefore everything is okay" and then you get paged, or you wake up at 3:00 a.m. to find out that your website is down, you're getting pinged, you're getting tweets, and what do you do in those cases? You go, and you reboot the server. That would never happen with Serverless because the pattern doesn't allow you to assume there is all this stuff already running, or like a database already connected.

Sadek: So meaning also you should be careful about startup time?

Your Serverless code, or Serverless functions do have a lifecycle. When a request comes in, if your code has not run in a long time, a cold boot happens.

Guillermo: Yeah, so that's what we call the 'cold boot' problem. Your Serverless code, or Serverless functions do have a lifecycle. When a request comes in, if your code has not run in a long time, a cold boot happens. You can think of it as starting an engine from cold. So when the cold boot happens you connect to your database, you do everything the normal way. And then when you respond, the function, the instance of that code that you run, gets frozen. And then when the next request comes in, the function comes back alive, but because it was frozen, it comes back alive very, very quickly. So that's where you do have an opportunity to save some state, but you should not rely on it.

Sadek: Okay, cool! Well on other videos we'll dig more deeper into some other aspects about Serverless, like deploying in global, scalability, on all of the other things.