What is serverless #1 | Introduction | Prismic

- So I'm here again at Prismic and today I'm with Guillermo from Zeit, and I like particularly that because of the strategical decisions that you're doing, especially with severless, and Next and what you're doing there, not obvious choices but I guess, you know, they're very interesting. The whole strategy is very interesting. And, furthermore, particularly I would like to kind of talk more about the severless topic.

And you know, introduce people to what is it. So can you give us your definition, your introduction of what severless is? - 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 servers 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. - Does it mean it's only about cost? It's only about cutting costs? - 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 severless is, your code is a structure

that's what we call severless 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. - You're talking about PHP here? - (laughs) For example. So PHP was, 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, you talk to a database, 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 100%, literally, on what your users are requesting. - 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? - Yeah, so the question of state is very nuanced. So 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, what resource-- 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 like you wake up at 3:00 a.m. 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 severless because the pattern doesn't allow you to assume there is all this stuff already running, or like a database already connected. - So meaning also you should be careful about startup time? - Yeah, so that's what we call the 'cold boot' problem. So your serverless code, or serverless functions

do have a lifecycle. So 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,