The serverless revolution

Pam Selle, welcome back to The Changelog.

Yeah, it’s nice to see you all here.

Good to have you.

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. [laughter] Is that fair, do you go to a lot of conferences?

You know, I’ve been taking a little bit of a break. 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 I/O…

Nice.

…and I might be at Strange Loop later this year.

Okay.

I’ve volunteered to review some proposals, and I can tell you you all should go. It’s gonna be a really good conference.

Strange Loop?

Mm-hm.

I’ve been telling this guy for years…

Have you been ever?

We have not been at Strange Loop, but…

Oh, my goodness…

Every year I say “We should go to Strange Loop this year…”

You have to go. 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 the public face. There’s many people in the Strange Loop team, but yeah, he’s the public face.

Yeah. So 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.

With OSCON, that’s how we’re here.

Yeah, which makes sense with O’Reilly.

We have family, we have mortgages… We’ve gotta try to go places – which kind of sucks in a way, because I wanna go to a lot more places than we wish we could, but we both have lives, I guess, schedules, so to speak…

I’m like ‘You pay, you have no life.’ [laughter] He just goes to conferences, whatever you want.

I mean, I just, we just can’t go on a whim, but yes, Strange Loop - we’d love to be there. It’s an awesome conference, and I wish we could go. Alex, if you’re listening to this, email us.

[03:55] Yeah, if Alex hears about it, or someone else in the team… But yeah, I mean, you might not be the first person that I’ve heard from that can be hard to get a hold of. They just have so much on their plate, and there are also a few other conferences that collocate with them… Racket, which is a Lisp - they collocate.

Yeah. Elm-conf…

Who?

There’s an elm-conf, like the day before…

Yeah, elm-conf, you’re right, and papers-we-love I think collocated… They really try to do a lot - since they go through all this work - to have all this conference space, that these smaller communities might not…

That’s super cool.

…especially these edge functional conferences. I have a friend who went to Racket Conf when I was there, and he said he had so much fun. Racket, in terms of a Lisp community, has a lot of academics, but it’s also really small in terms of who comes to Racket Conf, 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 why is that and why should we join?

The serverless revolution 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.” Serverless right now I think is where you wish 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. Ground floor.

I’ll talk about this on my talk, but – especially since this probably comes out after it, right?

Yeah.

So you can watch the video on YouTube. [laughter]

There you go. Do you have the URL for us? Because that would be cool! [laughter]

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; everyone agrees.

yes.

No one said it was a great name.

A lot of people never even get past the name.

Obviously, they are servers, just like the cloud is not made up of water vapor…

Of actual clouds, yeah.

So we got over it for the cloud, we can get over it with serverless.

It took us a while… It will take us a little bit.

Like you say with the cloud - you can talk to even people in the grocery store and they know what that means.

So to be clear, they still involve servers.

Yes.

Okay.

So you’re saying they’re servers…

So serverless is the idea of the general category of doing software development so that you don’t have to care about servers. There’s two different sections of it - there’s serverless computing, which is functions of service, and then there’s back-end as a service. When you do things like use Firebase, or using let’s say PubNub, which is a real time Pub/Sub service… That’s back-end as a service, but function of service is what I focus on and what the serverless revolution is really centered around… It’s this AWS Lambda and its friends. AWS Lambda and friends, coming to the Nickelodeon. [laughter]

Yeah, those sound like a cartoon. Not a great cartoon…

I think this is another reason why people have such a hard time wrapping their head around it, because it first starts as an AWS service, 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 it just has so many services that it’s hard to even know what they all do.

They have a big conference every year, re:Invent, and when I was watching the live stream in December I had a little cheat sheet of what the logos meant opened in another tab, because darn if I know what they are…

They all have the Amazon logo in there, or something like it…

[07:57] Well, they just don’t mean anything, and they just throw them on slides and talk about –

It’s a shame too, because they’ve got so much good stuf…

It’s so confusing…!

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. It’s good stuff.

So they start with AWS Lambda, which is like “Write a function, 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 (there’s ways you can do that) to the storage on one of these cloud providers, and then you set up a trigger. When that comes into that cloud provider, it will run your code.

Behind the scenes, what happens is it gets spun up in a container, then it runs that code in the container…

They’re doing all that stuff for you that you used to be doing yourself.

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 is doing, but ultimately the whole point is that it’s managing your infrastructure for you.

It’s revolutionary in a couple ways… 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 revolutions from a user perspective and from a cloud provider perspective is the way it’s run… It’s not a persistent service; it’s run in response to events. That’s one big thing.

The other big thing is that it’s metered. That’s how you bill. It’s metered in 100 milliseconds. Think about just how different that is from a consistent server model.

Hourly billing, things like that, you mean.

Yeah, that billing… Because it’s completely different than – especially your mom and pop cloud provider… There’s plenty of cloud providers that aren’t this big public cloud… The way they get into this business is they just sell you the same server that you would have put in your own data center, but as a virtual one, in their data center.

So it was revolutionary because there was technology that enabled it, but over time, 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. It feels to me that it’s a much bigger step.

I would say it’s definitely more of a departure… So revolutionary in terms of “different”, I agree. In terms of “What does that mean…?” So revolutionarily better, or just different?

Well, that depends. 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 – it’s similar to 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?” and we have our buddy Kubernetes doing stuff, running at the ship’s helm…

Right… [laughs]

Because you know Kubernetes means “Ship’s captain”, or whatever. So I think that that’s a thing that’s going to end up being revolutionary in terms of how people architect. 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.

One very obvious thing of “Where do you put your state?” It’s gotta go somewhere…

[12:09] Where does it go?

Yeah, where does it go? That’s a good question. It depends.

Oh, we don’t know…

I mean, we use a database. 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 will use Elasticsearch… We store data in the things that are meant to store data, and we run code on things that run code.

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 infrastructure; that spins up a container… All the things that are necessary for that code to execute properly have to connect to a data store, and then do its thing and maybe put stuff back in – if you’re gonna persist it, it’s gotta maybe pull stuff out, put stuff in, then spin down again…

Well, it depends, because the other thing is that – that’s why I think serverless is a terrible name; functions as a service… Even though it’s “everything as a service”, that’s actually not that bad of a name.

Sure. Well, it makes you think about it in the right way.

Yeah, it makes you think about it in the right way; your function is not gonna do everything. It’s gonna do this one granular thing. For example, 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, 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, or something like a Kinesis stream, that can be a trigger for another Lambda.

But see, as I describe it – you asked “What’s revolutionary?” It’s very easy to end up with a Rube Goldberg machine made of functions as a service…

Right.

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 is it a better way of doing it? There’s more efficient or direct ways of getting this done. Enter Rube Goldberg machine!

Sure, but at what cost, as well?

I don’t know…

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.

I also think that functions as a service are really cool from an environmental standpoint when we think about the usage of infrastructure… 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 wanna be able to handle a lot more traffic so that I don’t fall over. All that water and energy, all of it is 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 –

Less waste.

Yeah, less waste. I wanna use the word “elastic”, but that’s also been stolen by AWS, too.

They’ve got it all.

I like it – I mean, “elastic” makes sense, because it’s like a rubber band… It stretches and then it and then condenses.

It does make sense. Why don’t you call it “stretchy services”?

Stretchy… Isn’t there a superhero that’s–

Stretch Armstrong.

Yeah, there you go.

Now you have a mascot. He’s the leader of the serverless revolution - Stretch Armstrong. [laughter]

What was the – there was a… Wasn’t there a Fantastic Four?

Probably…

I can’t recall the name, but yes…

Yeah, I’m not that person, sorry…

I’m not either.

Neither am I, sorry. [laughter]

The Incredibles - the mom would stretch… I’m more of that person than the other one.

Yeah, me too. [unintelligible 00:17:26.09] [laughter]

Me neither. Mom? I don’t know…

Yeah, she was the mom…

The Incredibles Mom. Mrs. Incredibles.

That’s right.

There you go, Mrs. Incredibles. Take us through like 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. What are people using it for? Are there people taking this to production? Like you said, it’s ground floor, but…

No, 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 hill on the bell curve. AWS Lambda was released in late 2014 for re:Invent and we’re talking right now in 2017. In computer land…

It’s a long time.

…a lot of time has passed. Much time has passed, and there’s actually quite a few people running this in production…

In the olden days…

Yeah…

Three years ago… [laughter]

And I think this is one thing that makes serverless compute hard to understand - it’s a cloud offering, and there’s actually lots of ways to use it, especially when it’s something so general as “runs code in response to a trigger.”

Right. Executes your code.

There are actually lots of ways to do that. iRobot, of your friendly Roomba - they run on serverless. It’s popular in IoT because IoT is event-driven.

Yeah, it makes sense in that case, for sure.

You know, sensors send signals, and… Do something.

This happens, and then… Response.

Yeah. Then for more of a web development idea, you can run an API, because you can integrate with – in Google cloud you could use HTTP triggers, or in AWS Lambda there is API gateway… 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… 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.

Did you all hear about what – like, I read the report…

I did, but I’ve lost it now. Yeah, tell me.

Sure. So what happened was someone deleted something that they shouldn’t, and because of a command line argument…

[20:05] Yeah, that’s right - it was a command line typo.

Yeah, it was a command line argument, so it was a human error… I hope that person is okay.

They had a very bad day.

They had a very bad day.

They deleted their Bash history. “I didn’t do that!”

Hug Ops, Hug Ops… It then caused this cascading failure. So one thing that you could do with AWS Lambda is, anything you can put in a playbook, you can probably run with functions of service, if I think about that. That’s why it actually is a good number, functions of service, because it’s a function. It’s a list of instructions. Do something.

I’ve heard people using it for operations task of “If I delete this route, then these other things should happen” and using functions as service to run that script for you in your [unintelligible 00:20:58.14]

It seems really like a good fit. I mean, IoT makes sense, but also bots, because they’re completely event-driven.

For box?

Bots.

Oh, bots… For sure. That’s actually one of the…

Bots.

That’s what I said.

Yeah, like robots. [laughter] The internet robots…

You accent may have thrown it off a little bit.

Accent?! I have no accent.

Anyways, sorry…

I thought I said it clearly…

No, because it’s event-driven…

It’s all good. Bots.

That’s what I said.

That’s really common if you look for a serverless tutorial, which we have one on GitHub at ioPipe/workshop, I believe…

These bots…

Yeah, you can make a Doge bot for Slack…

Nice.

You give it some words and it will make a Doge meme for you.

Nice.

It’s a little 40 minute “Do a tutorial to practice a thing” workshop.

I like it. “Do a tutorial to practice a thing”?

Well, I mean, that’s how you learn stuff, right?

Yeah.

We can talk about this as much as we want, but if you –

That’s what I’m saying. Getting practical, how do you actually get started?

You’ve gotta actually touch it, yeah… Especially because all the three big public clouds (AWS, Google Cloud, Azure) all have really generous free tiers. So the pricing for functions of service 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… It’s a very fancy way of saying “duration.”

How long it takes, given a memory constraint.

Yeah, and you get charged so much money per hundred milliseconds.

Can you run a Slack bot for free on all those?

Yeah, I would say…

Nice.

Unless it’s getting used constantly, or something.

Unless it’s absolutely constantly… I think it would be a challenge. Maybe your Giphy instance maybe could hit the limit, but you get a million invocations on AWS, two million free on Googe Cloud, and one million on Azure.

On a monthly basis?

It renews monthly [unintelligible 00:23:12.07]

It’d be a popular bot.

What was the entry point for you for this?

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.

Gotcha.

Before that, I was doing some consulting, and before consulting, I was working on a large scale API gateway for a major company.

That’s when we talked to you last.

Okay, yeah.

Things move fast in the software industry…

Yeah, I told you! We talked two years ago, and everything changes.

Do you have a good a-ha moment story for us? When you really got it, you were like “This is really awesome!”

[23:55] You know, I think I almost started having it before 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, it 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 something that you probably should sort out, and it will become part of what you generally know. I feel like that’s what ended up happening - I kind of had an inkling (even when I first heard it) that this was gonna be a big thing.

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, what they saw when they went from persistent infrastructure to – what is that? I heard someone say that running functions of service is not even immutable infrastructure, it’s untouchable infrastructure. Like, you use it and it’s gone… So it’s untouchable infrastructure.

But moving to that, the difference that they saw in their costs, to the time they spent on random operations task – it just was blown out of the water. It was just a huge change for them. 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 when people are super into something… But I would argue this is a big deal, and there’s a good reason why they’re excited, because they have that lived experience where they’ve seen that transition and seen what it looks like on the other side of it.

Yeah. Well, we’re where we’re at in tech because of a 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. And some of the operational challenges are really interesting, but for your average run-of-the-mill developer too, it’s really great… In terms of the barrier between having some code to run a back-end, and having it run and not paying very much money for it; it’s pretty great.

Yeah.

The bot you did for Memberful to Slack could have easily been this.

Oh, absolutely. And I actually think I probably will try to write a Slack bot for us, because I have like one or two ideas for our Slack, where I could write it as part of our main website and it just can 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 it’s a good case for trying it out and seeing if there’s a happy path there.

Yeah.

Cool. 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 11th September 2015 - that’s episode 173 of The Changelog; we had the entire Turing-Incomplete – I think it was the entire… There was three of you, but 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.

It was Len. 75% of the Turing-Incomplete cast on The Changelog… And that show has since retired, but…

It could come back… We’re thinking about it.

There are whisperings that Turing-Incomplete may return, so follow… Are you @pamasaur on Twitter?

Yeah, @pamasaur on Twitter.

Follow @pamasaur on Twitter, and thanks so much.

Yeah, thank you for having me.