In this episode from the Serverless series, Guillermo and Sadek discuss the Serverless developer experience. Guillermo explains how using Severless can improve the developer experience in a number of ways - including through instant deployments, reduced cost, easy rollbacks, and better collaboration.

This is a transcript of their discussion, but you can watch the full video below and subscribe to our channel to see the full series and more of our interviews and tutorials.

Highlights:

Guillermo and Sadek discussed how Serverless improves the Developer Experience, including:

• Instant deployments, in one command, to get up and running quickly
• Reduces the cost of running many versions of your project so that every change can be deployed.
• You can access the live version of any state of your application, at any time, at almost no additional cost.
• Rollback to a previous version if something goes wrong without having to deploy again
• Collaborate and share previews of new versions throughout the project

Sadek: We talked about different things regarding Serverless in these videos. We talked about scalability, about deploying globally. And, there's one that is very important, the Developer Experience, and, you know, whenever you're working, the thing that I like about Serverless is that it doesn't integrate into the project by the end. It's since the beginning, since the start, it's there, and it's there for several things. So, can you tell me some of the advantages that you see about Serverless for the developer experience?

Deployment is hard

Guillermo: Yeah, in terms of Developer Experience initially, when Serverless was kind of getting started, and even until today, the primitives are quite hard to deploy. So, in essence, the technology is very simple, as a serverless function. But everything around deployment is very hard, and that's where we try to simplify it and make it one command.

Sadek: So number one is simplifying deployment.

Simplifying deployment

Guillermo: Yes, and you write your functions, you say what technology these functions are using, like, are they Next.js? Are they Node, are they Go? And then, you run Now, or you Git push, and your deployment comes alive. A deployment, in itself, is made up of one or many serverless functions, or static files as well, like CSS and JS assets, or SVG assets. So, from a developer experience standpoint, a few things happen with this model. So, one of them is, deployments are instant. So, what we usually see is that it takes just a few seconds to deploy hundreds of these functions. So, you know, you get up and running very quickly. The second thing that happens is, Serverless makes it possible to afford to run, or "run", because they're not really constantly running, many, many versions of your deployment. So, it takes away the burden in the developer's mind that they cannot deploy infinitely. Every little change they make, they can deploy. Every push gets tested, built and deployed. So, you can access the live version of any state of your application throughout time by just, for example, going to Github, with which we intergrate.

Sadek: So basically, if I understand, this means, if I have a Pull request, I can associate a function to that, like a deployment, a URL to that.

Guillermo: Yeah.

Sadek: And even if I'm not using it, I'm not paying for that.

Guillermo: Right.

Sadek: And the moment someone clicks on it, it boots up, and even if it was done one year ago, they still see that version running.

Version control

Guillermo: We kind of take the same approach as Gmail. When Gmail came out, they were like, "You know, we don't need the Delete button." Because, when you delete email, it's forever, and you lose it out of search, so that was their argument for doing that. And for us, it's not about search, although that's helpful as well, but it enables very important features. Like, you can review old versions of your projects. You can analyze the evolution. If you work on marketing, you can compare your changes over time, like, "Oh, this is what our marketing campaign looked like. This is what it looks like today." For people that are more on the application side of thing, not just the front-end or marketing side of thing, they can think about rollbacks. Like, what happens if something went wrong? I can quickly go back to another version, and it doesn't even require real deployment.

Sadek: It's there,

Guillermo: It's there, it's instant.

Sadek: And, also, what I like about it, if I'm working on something, and then I want to give a preview to someone, it's there, right? You just send them the link for collaboration.

A personal staging environment in production

Guillermo: Yeah, the link is always there. It's like everyone gets their own personal staging environment, with the advantage that it's not even staging per se, because it's running with the same exact features and qualifications as a production environment. So, a meme that has come up recently is test in production, and what it means is not, "Test with your paying customers "and break everything," but it's, try to test with the exact same environment, and that's what Serverless is essentially giving you. The way that I also like to explain it is, there's no such thing as staging. There is development, when you're playing with things, and then there is production, and you can use as much or as little as production as you want.

Sadek: Yeah, great. So, next one, next video, let's try to talk about a concrete example, and how would that work with Serverless.