The Changelog: Software Development, Open Source - The serverless revolution (Interview)

Episode Date: June 16, 2017

We talked with Pam Selle at OSCON about the serverless revolution happening for JavaScript developers. This episode kicks off our mini-series from the Expo Hall floor at OSCON 2017.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Linode, our cloud server of choice. Everything we do here at Changelog is hosted on Linode servers. Pick a plan, pick a distro, and pick a location, and in seconds, deploy your virtual server. Jewel-worthy hardware, SSD cloud storage, 40 gigabit network, Intel E5 processors, simple, easy control panel, nine data centers, three regions, anywhere in the world they've got you covered.

Head to leno.com slash changelog and get $20 in hosting credit. This episode is brought to you by TopTow. TopTow is the best way to hire freelance talent to scale your team, work with top freelance software developers, designers, and finance experts from all over the world. Or if you're a developer, designer, or finance expert looking to freelance with top companies like JPMorgan, Airbnb, or Pfizer, head to TopTow.com to learn more. That's T-O-P-T-A-L.com. Tell them we sent you. For a more personal introduction, email me, adam at changelog.com. From Changelog Media, you're listening to The Changelog,

a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of Changelog. This episode kicks off our mini-series from the busy expo hall floor of OzCon. Over the next several weeks, we'll be releasing new episodes featuring conversations with speakers from OzCon that you won't want to miss. On this episode, Jared and I talk with Pam Selle about serverless. Special thanks to our friends at O'Reilly for inviting us to OzCon. It was an honor being there.

So, Pam Selle, welcome back to the ChangeLog. Yeah. Good to have you. Nice to see you all here. I think you go to lots of conferences because we go to very few conferences, but every one we go to, I think you're there. You're there. Is that fair?

Do you go to a lot of conferences? You know, I've been taking a little bit of a break since... I've been focusing on... What I've been trying to do is to go to a couple big ones so i'm here this week at oscon and i'll be at google io and it might be at strange loop later this year okay i have the privilege of being i was reviewing i'm volunteered to review some proposals and i i can tell you you all you all should go it's gonna be a really good conference strange loop i've been telling this guy for years for you all have you been we have not been in strange loop oh my every year i say you we should go. It's going to be a really good conference. Strange Loop? I've been telling this guy for years. Have you been ever? We have not been to Strange Loop, but every year I say, we should go to

Strange Loop this year. I've been twice. I love it. It's an audio show, Adam. Adam's nodding his head in agreement. I'm nodding my head because at the same time I'm nodding, I'm trying to find out who runs Strange Loop because I forget the person's name. Oh, Alex?

Alex. Yeah, Alex is kind of, he's the public face. There's many people on the Strangeloop team, but yeah, he's the public face. So we try to go, because we try to run a sustainable business, we try to go in a way that helps us, I guess, gain some revenue to get there, so to speak. Right, okay. And so, like, with OSCON, that's how we're here. Yeah, which makes sense with a big sponsor, like with O'Reilly. We have family, we have

things, we have mortgages, so we gotta try to, like, go places, which kind of sucks in a way, because, like, I want to go to a lot more places than we wish we could, but we both have, you know, like, lives, I guess, schedules, so to speak. Unlike you, Pam, who has no life. It just goes to conferences, whatever you want.

I mean, we just can't go to a win. But yes, Strangeloop, we would love to be there. It's an awesome conference, and I wish we could go. Yeah. So Alex, if you're listening to this... Yeah, if Alex hears that or someone who... Email us again. Someone else from the team.

But yeah, I have... I mean, you might not be the first person that I've heard from that they can be hard to get a hold of. So they just have so much on their plate. And there's also that I believe the, they have a few other conferences that co-locate with them. So Racket, which is a Lisp, they co-locate, who? Isn't ElmConf like the day before? Yeah, ElmConf, ElmConf, you're right.

And Papers We Love, I think, co-located. Like, they really try to do a lot to, you know, since they go through all this work to have all this, you know, conference space, that these smaller communities that might not, especially like, you know, these edge functional conferences, you know, how RacketConf. I had a friend who went to RacketConf one year when I was there, and he said it was, he had so much fun because it was such a, you know, Racket in terms of a list community has a lot of academics, but it's also really small in terms of who comes to RacketConf, but very interesting. So you're here to talk about the serverless revolution. In fact, you have a t-shirt on that says join the serverless revolution. So what

is that and why should we sign up? Why should we join? Yeah, so the serverless revolution is, I feel like is the thing, if you already know about it, the people who know what it is say, well, yes, this is definitely going to be the next big thing.

It's serverless, like serverless right now is where I think is where you wish, you know, three years ago that you knew everything about containers. Serverless is that thing right now, in terms of the hotness. It's not the big thing. It's the next big thing. Yeah. Right. It's really, I think it might be, it might, because it's been, so serverless is kind of, and this is, I'll talk about this in my talk.

But, especially since this probably comes out after it, right? Yeah. been, so serverless is kind of, and I'll talk about this in my talk, but especially since this probably comes out after it, right? Yeah. But so you can watch the video on YouTube. There you go. Do you have the URL for us? No, I will. That would be cool. But, so

when you watch the talk, I cover that serverless really is this first of all, we'll get it out of the way. It's a terrible name. Yes. Everyone agrees. No one said it was a great name. A lot of people never even get past the name.

Obviously, there are servers just like the cloud is not made up of water vapor. Actual clouds. Yeah. So, like, we got over it for the cloud. We can get over it with serverless. It took us a while. It took us a while, but now people don't even, yeah. People don't even, like, you for the cloud. We can get over it with serverless. It took us a while. It took us a while, but now people don't even, yeah. People don't even, like you say, the cloud.

And you can talk to even people in the grocery store and they know what that means. So to be clear, this still involves servers. Yes. Okay. So you're saying there's servers. So serverless is the idea of the general category of doing software development so that you don't have to care about servers. And so there's two different sections of it.

There's serverless compute, there's serverless computing, which is functions as a service, and then there's backend as a service. So when you do things like use Firebase or using, let's say, PubNub, which is a real-time PubSub service, that's backend as a service. But functions as a service is what I focus on and what the serverless revolution is really centered around is this AWS Lambda and its friends. AWS Lambda and friends coming to Nickelodeon.

Yeah, it does sound like a cartoon. Not a great cartoon. So AWS Lambda is, and it's also, you know, I think this is another reason why people have such a hard time coming up, wrapping their head around it, is because it first starts as an AWS service. Right. And God knows if anyone knows what anything on AWS does until you use it. We were just talking with Justin at AWS.

Yeah. That they just have so many services. They have so many services. That it's hard to even know what they all do. I mean, I literally, I was watching, so they have a big conference every year, reInvent. And when I was watching the live stream in December, I had like a little cheat sheet of what the logos meant open in another tab because like, darn if I know what they are.

They all have the Amazon logo in there or something like it, right? It doesn't, well, they just don't mean anything. And like, they just throw them on slides and talk about. It's a shame too because they got so much good stuff. It's so confusing. Yeah, I think they're rallying around. It's getting better.

They're working on making their design better. But the thing is, I don't really care that they're not that good at design. They make great cloud infrastructure, and it's good stuff. So this started with AWS Lambda, which is like, write a function but run it on their... Right. Execute it there. Yeah.

So instead of running code on a physical server that you have under your desk, a virtual server on someone's public cloud, or a fake virtual server that is actually a container on someone's cloud, you upload your code literally as a zip file, or there's ways you can do that, to storage on one of these cloud providers. And then when an event that you've, kind of a trigger,

when you set up a trigger, when that comes into that cloud provider, it'll run your code. And behind the scenes, what happens is it gets spun up in a container, and then it runs that code in the container, and those containers get cycled. that you used to be doing yourself.

And all that stuff, yeah, all that stuff will happen without you doing anything. I mean, you should know how it works, because you should know what your infrastructure's doing. But ultimately, the whole point is that it's managing your infrastructure for you. And the end game of it, so it's revolutionary in a couple ways of just in terms of the technology that makes it possible is really interesting.

We wouldn't have functions of service without containers. That's what makes it possible. Sure. But the main things that make it really revolutionary in terms from a user perspective and from a cloud provider perspective are the way it's run. So it's not a persistent service. It is run in response to events. So that's the way it's run so it's not a persistent service it is run in response to events so that's the one big thing and the other big thing is that it's metered that's how you bill

it's metered in 100 milliseconds so think about just how different that is from a consistent server model i mean if you talk to early billing things like that you mean yeah that billing because i mean that's I mean, that's completely different than when, especially, you know, when your mom and pop cloud provider, which there are, there's plenty of, you know, not these you know, there's plenty of cloud providers that aren't this big

public cloud. The way they get into this business is they, you know, they just sell you the same server that you would have put in your own data center, but as you know, a virtual one in their data center. So it's really, there is revolutionary because there was technology that enabled it. But over time, it's kind of, when you look at the distance between those two points,

it's actually not that big a difference in terms of the distance between these two points and the distance between virtualization and containers and running code in response to events. Yeah. I think it's a much, it feels to me that it's a much bigger step. I would say it's definitely more of a departure. I would ask, so revolutionary in terms of different, I agree. In terms of like, what does that mean?

So, revolutionarily better or just different? Well, that depends. So, to me, I find that topic very exciting. And I'm okay with being in that space. I do think it's revolutionary because you also, in the same, I mean, a similar is happening right now. So, you know, so how containers are now in the orchestration stage of, okay, great, we have containers. Now what do we do with them? Now what do we do with them? Now what do we do with them?

And we have our buddy Kubernetes doing stuff and running at the ship's helm. Right. Because you know Kubernetes means ship's captain or whatever. And so I think that that's the thing that's going to end up being revolutionary in terms of how people architect. Because when you architect around that your code only runs in response to triggers and your infrastructure scales theoretically horizontally

just because of the kind of service you're running, that's going to have to reflect in your architecture somehow. I mean, for one very obvious thing of where do you put your state, it's got to go somewhere. Where does it go? Yeah, where does it go? That's a good question. It depends. We don't know.

You can put it in a, I mean, we use a database. Like, it's not, like, it's kind of where we always put, for us, in terms of some of the service architectures we run, at Iopipe, we use a database. We use Elasticsearch. We store data in the things that are meant to store data, and we run code on things that run code. So take me through the process here. So an event triggers your function,

your code executes on a AWS or other provider who provides functions as a service. Right. Infrastructure. That spins up a container. All the things that are necessary for that code to execute appropriately has to connect to a data store. Sorry.

And then do its thing and then maybe put stuff back. If you're going to persist it, maybe pull stuff out, put stuff in, and then spin down again. Think about that. It depends because the other thing is that and that's why I think the serverless is a terrible name. Functions is a service even though everything is a service.

That's actually not that bad of a name. It makes you think about it the right way. Your function is not going to do everything. It's going think about it the right way. Because, yeah, it makes you think about it the right way is that it's not, your function's not gonna do everything. It's gonna do this one granular thing. So for example, if it, you might have one function that gets something from the database and another function that modifies something from the database.

Those are very different things. Sure. And so you might have two separate jobs that do it. You might even, instead of writing directly to, if you have other things that have to happen, maybe you don't write directly to the database, maybe you write to a queue. And then that queue can be a trigger for,

or something like a Kinesis stream, that can be a trigger for another Lambda. But see, as I describe it, you can see, I think that's the thing of when you think about, so you asked what's revolutionary, is you end up with, it's very easy to end up with a Rube Goldberg machine made of functions as a service.

I think that's super interesting. I mean, there's a reason why I think Rube Goldberg machines are interesting. Right. They're intellectually stimulating, but there's a better way of doing it. There's more efficient or direct ways of getting this done in a Rube Goldberg machine. Sure, but at what cost as well? And so that's the other thing is that running and at what scale?

When we come back from the break, we talk about the environmental impact of functions as a service and how the serverless architecture removes the need for a traditional, always-on server system. We also talk about how serverless is being used in production today and where it's going in the future. Stick around. This episode of The Change Log is brought to you by our friends at Microsoft and Azure Open Dev Conference, their upcoming no-cost live virtual conference that's focused on showcasing open source technologies on Azure. Engineers are looking to bring more of the open source tools they know and love to the cloud,

but often need a grounding on what to look out for and what to expect. The fastest way to learn is to see live demonstrations and get time to Q&A with experts in the field. Microsoft is providing this at no cost. It's a virtual event, which means you don't have to travel anywhere. Reserve your spot today. Head to azure.com slash open dev. That's A-Z-U-R-E dot com slash open dev

to register for this free live event from Microsoft. It is on June 21st, 2017. And now back to the show. I also think about that functions of service are really cool from an environmental standpoint in terms of when we think about the usage of infrastructure, that if I'm building what I want to be a standard scalable infrastructure, I don't want my load to ever go over 50%, maybe, because I want to be able to handle a lot more traffic so that I don't fall over.

All that water and energy and all of it, you know, it's just getting wasted, and I'm paying for it. So it's bad for the environment, it's bad for my wallet. So if I use something where things are run in a scalable I want to use the word less waste. I want to use the word elastic but then that's also been stolen by

AWS too and for other projects. I mean elastic makes sense because it rubber bands. Yeah. That's why we use it. It condenses. Yeah. So why don't you go ahead. Stretchy services. Stretchy. Isn't there a superhero that's Stretch Armstrong. Yeah there you go ahead stretchy services stretchy isn't there a superhero that's

Stretch Armstrong yeah there you go now you have a mascot there you go the leader of the service revolution Stretch Armstrong what was the

there was a wasn't there a Fantastic Four yeah probably I can't recall the name but yes yeah I'm not I'm not that person

I'm not either sorry sorry Incredible the mom she was I'm more that person than yeah'm not either. Sorry. Sorry. Incredibles, the mom would stretch. She was. I'm more that person.

Yeah, me too. But I'm Ernie neither, though. Me neither. Mom? Yeah, she was mom. Mom. The Incredibles mom. Mrs. Incredibles.

That's right. There you go. Mrs. Incredibles. Take us to a practical sense. Where does it stand today? We're talking, not really theoretically, but we're talking big picture about functions as a service. But, like, what are people using it for? Are there people taking this to production?

Is it still, like, like you said, it's ground floor. No, that's like, I really wouldn't put it at ground floor. It's almost like in the bell curve, we're still on the left side, and we haven't reached the top. But we're definitely not at the bottom of the hill. Okay. So we're making our way up the hill. We're going up the left side, and we haven't reached the top. But we're definitely not at the bottom of the hill. Okay. So we're making our way up the hill. We're going up the hill on the bell curve. So AWS was released in 2014, in late 2014, for re-event.

And we're talking right now in 2017. So in computer land, a lot of time has passed. Right. Much time has passed. And there's actually quite a few people running this production. In the olden days. Yeah, and the other thing that's kind of,

and I think this is one of the things that makes serverless compute hard to understand, is that it's a cloud offering, and there's actually lots of ways to use it. So, especially when it's something so general as runs code in response to a trigger, there's actually lots of ways to do that. So iRobot, of your friendly Roomba, they run on serverless. So that's one of the things.

It's pretty popular in the IoT because IoT is event-driven. Yeah, that makes sense. Sensors send signals and do something. This happens and then responds. And then for something for more of a web development idea, you can run an API because you can integrate with, like in Google Cloud, you can use HTTP triggers or in AWS Lambda, there's API Gateway.

And so you can run an API by saying when I get a request then run this function and send this response. There's so many. There's even I think one of my most favorite recent ones is in operations which this is interesting because this is, although, you know, when I think about this, this probably would have caused more problems, but when there was the great S3 outage earlier this year. Yeah. And did you all hear about what, like I read the report. I did, but I've lost it now.

I feel like there was, yeah, tell me. Sure. So what happened was someone deleted something that they shouldn't, and it caused a, because of a command line argument. Yeah, that's right. It was a command line type of thing. Yeah, it was a command line argument. So it was a human error. I hope that person's okay.

They had a very bad day. They had a very bad day. And deleted their bash history. I didn't do that. Hug ops. Hug ops. But they. Pep cack.

They, it then caused this cascading cascading failure but so one thing that you could do with ados land is anything that you put or something like it is anything you can put in a playbook you could probably run with uh functions of the service if i think about that because it's that's why it actually is a good name the functions of service because it's just it's a function it's a list of instructions. Do something. So I've heard of people using it for operations tasks of, if I delete this route, then these other things should happen.

And using functions of service to run that script for you and your infra. Seems really like a good fit. IoT makes sense, but also bots because they're completely event driven. For bots? Bots. Oh, bots. Yeah. Oh, no, for sure. That's actually one of the... Bots. Yeah, yeah. That's what I said. Like robots.

The internet robots. Let's make it clear. Your accent may have thrown it off a little bit. Accent? Bots. I have no accent. Because she was like, bots. It confused me. Anyways, sorry. I thought I said it.

I had to put that out there because I was thinking it. No, because it's a venture event. That's all good. Bots. And that's one that's really common if you look for a serverless tutorial, which we have wanted on GitHub at IOPipe slash workshop, I believe. And it... They use bots.

Yeah, you can make a doge bot for Slack. Nice. So you give it some words and they'll make a doge bot for slack nice so you give it some words and they'll make a doge meme for you nice it's a it's a little intro to it's a little 40 minute do a tutorial to practice a thing workshop i like it yeah tutorial to practice a thing well i mean that's how you learn stuff right i mean we can talk about this as much as we want but if you like that's why i say getting practical, how do you actually get started? You got to actually touch it. Yeah. And really, especially because on all the pretty much, well, all the major, the three big public clouds of being AWS, Google Cloud, Azure, they all have really generous free tiers. So the pricing for function of the service is in the number of invocations and in compute

time. Compute time being a calculation based on how much memory you said you want your function to use. So it's a very fancy way of saying duration. How long it takes given a memory constraint. Yeah. And so you get charged so much money per whatever, for 100 milliseconds. Can you run a slack buffer free on all those?

Yeah, I would say. All right, that, because you get. Unless it's getting used constantly or something. Unless it's absolutely constantly, I think it would be a challenge. Like maybe your Giphy instance maybe could hit the limit. But you get a million invocations on AWS, two million free on Google Cloud, one million on Azure.

On a monthly basis. And it renews monthly your free grant. Maybe a popular bot. What was the entry point for you for this? For me, it was actually when I started working for the company I'm working for now. I work with Iopipe where we're building monitoring for serverless. So I came from, before that, I

was doing some consulting and I was working, actually, and then before the consulting, I was working on a large-scale API gateway for a major company. That's when we talked to you last. Things move fast in the software industry. Yeah, I told you.

Yeah, we talked two years ago, and yeah, everything changes. Do you have a good aha moment story for us? Like when I thought I got this, and I was like, oh. When you really got it, you were like, this is really awesome. You know, I think I almost started having it when, before I ended up working with IOPipe, when I first spoke with the founders, I I ended up working with Iopipe, when I first spoke with the founders, I was speaking to one of the founders and she was talking about

this thing that she was working on and was building and involved the cloud and this thing that I think I'd heard of but I hadn't done anything with and I barely understood it. And that's the kind of thing where you either don't understand it because it's pointless to understand it or it's because it's you know something they probably should like sort out and it will become part of what you generally know and I feel like that's what ended up happening was I kind of had an inkling even when I first heard it that this was going to be a big thing. And then when I started, and especially once we started, we spent a lot of time at the company talking to teams who are using serverless in production and the kind of problems that they're using it on, the kind of production challenges they run into.

But all of them ultimately had such amazing stories about the transition that what they saw when they went from persistent infrastructure to, what is that, I heard someone say that it's not even, that running functions of service is not even immutable infrastructure, it's untouchable infrastructure. That it runs, you use it and it's gone.

So it's untouchable infrastructure. But moving to that that the difference that they saw in their cost in their office for the time they spent on random operations tasks just it just was blown out of the water that it was just a huge change for them and that's I mean I think that's one of the reasons why people might hear this trend and they're like why does everyone care so much which is also a fair reaction to something when people are like super into something yeah um but i i would argue that this is a big deal and i mean there's a good reason why they're excited because this you know they

have that lived experience where they've seen that transition and seen what it looks like on the other side of it yeah we're where we're at in tech because they consistently lowered barrier to entry and that's what this does This is lowering it one more time. Yeah, one more time. I think so. I mean, because it really is. And I mean, and some of the operational challenges are really interesting. But for, you know, for your average run-of-the-mill developer too, it's really great.

I mean, in terms of the barrier between having some code to run a backend and having it run and not paying very much money for it. It's pretty great. The bot you did for Memberful to Slack could have easily been this. Absolutely. And I actually think I probably will try

it, write a Slack bot for us, because I have one or two ideas for our Slack. Nice. I could write it as part of our main website and just could always be there because the website's always there. Or I could try it as a serverless little thing and it's small enough that I could move it if I wanted to. But I think that's a good case for trying it out

and seeing if there's a happy path there. Yeah. Cool. Well, Pam, thanks so much for talking to us about the serverless revolution. By the way, long-time listeners of the show may remember, Pam, from a crossover episode we did back

in September 11, 2015. That's episode 173 of the Change Log. We had the entire Turing Incomplete. I think it was the entire. There was three of you. You guys had four, though, didn't you? We had four. I can't remember who didn't make it. It might have been Len. 75% it was the entire there was three of you you guys had four though didn't you? we had four I can't remember who didn't make it it might have been Len

75% it was Len 75% of the Turing Incomplete cast on the Change Log and that show has since retired but

it could come back I hear Inclean there are whisperings that Turing Incomplete may return so follow are you Pamasaur?

yeah Pamasaur on Twitter follow Pamasaur on Twitter. Follow Pamasaur on Twitter. And thanks so much. Yeah, thanks for having me. Good game. Nice. Good game.

All right, thanks for tuning in to The Change Log. We love talking with people like Pam who help make the open source community thrive. If you enjoyed this show, make sure you share it with a friend. Thanks to our sponsors, Linode, TopTow, and Microsoft with their Azure Open Dev Conference. Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. We host everything we do on Linode servers. Head to linode.com slash changelog. Check them out, support the show. The changelog is hosted by myself, Adam Stachowiak, and Jared Santo. It's edited by Jonathan Youngblood. And the awesome music you've been hearing is produced by the mysterious Breakmaster Cylinder.

You can find more episodes like this at changelog.com or by subscribing wherever you get your podcasts. Thanks for listening.