Expert Talk: Cloud Native and Serverless

Should everyone move to the cloud? Are all event-driven architectures serverless or is it rather the other way around? Join the two experts, Matt Turner, software engineer at Tetrate, and Eric Johnson, principal developer advocate for serverless at AWS, to discover if you should take the journey to become cloud native. Understand the power of these technologies together with some useful tips & tricks about testing and the BEAM languages.

---

Intro

Eric Johnson: Welcome to another session of GOTO Unscripted. I am here with Matt Turner.

Matt Turner: Hey.

Eric Johnson: And I'm Eric Johnson. I'm a principal developer for Serverless at AWS. But, we might talk about some AWS today. I don't know, I think we can talk a little...

Matt Turner: We might, yes, a little Serverless maybe.

Eric Johnson: Yeah. Tell them who you are. What do you do?

Matt Turner: So, I'm Matt Turner. I'm a software engineer at Tetrate. We do service mesh, and Istio stuff.

Eric Johnson: Ok.

Matt Turner: We're a vendor in that space. I do some software engineering and some community, and dev relations. I take our stuff, I see what it can do. I try to explain that to people. I'm like, "Can we plug it into that system and that system?" And if I can make that work "Here's a GitHub repo full of that, here's a blog, here's a talk about it."

Eric Johnson: You do a lot of consulting then, right?

Matt Turner: Yes, I do. I have been an independent consultant, but yeah, I'm kind of out in the field now with Tetrate..

Eric Johnson: Nice. All right. Well, just before we get too much just so you know, we're coming live from GOTO Amsterdam here. And guess where we are?

Matt Turner: Amsterdam.

Eric Johnson: Amsterdam. Yes.

Matt Turner: You can tell from the...

Eric Johnson: Clever naming. Yes.

Matt Turner: ...the view. This is actually a beautiful room.

Eric Johnson: Yes. It's such a really cool... This is the first room I ever spoke in.

Matt Turner: Wow.

Eric Johnson: So yeah, years ago I did a talk called Attitude of Iteration.

Recommended talk: Attitude of Iteration • Eric Johnson • GOTO 2019

Matt Turner: Nice.

Eric Johnson: It was about overcoming challenges. I just did a bunch of one-finger jokes and we had a good time.

Matt Turner: Anyway...

Eric Johnson: It was more than that.

Matt Turner: Eric Johnson's talks are worth a watch. They are more than...there are one-finger jokes. They're great. But there's also great content.

Eric Johnson: Have you ever seen this one? Hang on, wait, let's see if I can do it. Okay, I want that on tape. That needs to be in the video.

Matt Turner: That's gonna be a GIF now. It'll be a meme.

Cloud native progressive delivery

Eric Johnson: So, let's jump in. So tell me, do you have a talk coming up?

Matt Turner: I do. I have a talk this afternoon.

Eric Johnson: Yes. What are you talking about?

Matt Turner: I'm talking about, I call it cloud native progressive delivery. So, I'm talking about, spoiler alert, I guess, for the talk because this will go out afterward.

Recommended talk: Cloud-Native Progressive Delivery • Matt Turner • GOTO 2022

Eric Johnson: Yeah, watch this after the talk, so, yeah.

Matt Turner: Yeah, right. I guess a lot of people talk about CI and CD, right? They talk about continuous integration, and continuous deployment. And those are sort of the two stages.

Eric Johnson: Or continuous...

Matt Turner: Or delivery.

Eric Johnson: ...delivery.

Matt Turner: And this is the thing. I mean, people have written books on this topic. I'm not hopefully going to do like a 101, like sucking eggs. I think the GOTO audience is a bit better than that. There's quite some quite good understanding. But it's basically saying yes if you separate build from deployment, which obviously you should, and then separate deployment from release. So deploying, like getting your software, getting your container image, say running in production, is deployment. And then it sat there, it can talk to production databases, it reads production configuration, it can talk to the other production services, but it's not released if it's not getting user queries.

So, if you've got something like an API gateway, or a service mesh that can do that more advanced traffic control, then you can have that thing running in production. You can test it, port forward to it, set some headers, or whatever. You can hit it with test traffic, you can get automated, you know, regression testing and load testing, you can start canarying traffic into it, or you can roll it back. So, you're getting the most representative test because it's in prod. I've had services, we had one, right, that just got deployed to staging, everything looked great, rolled it out into prod. CrashLoop just wouldn't start because somebody changed the config file format, right? It hadn't changed, and just silly things like that plus actually access to prod data and access to other prod services.

So, you can deploy like that, and that's risk-free, right? You can just do that and you really do it continuously. Because so many organizations, I think, have continuous deployment, they have the machinery for it, but somebody somewhere has to go press an approve button, or it has to happen on a Tuesday. So you can deploy, and you do that. You just move that prod, don't get me wrong, in some ways you are moving that product to release, but you get so much more value automatically by at least wrapping deployment up.

Eric Johnson: I do a lot of speaking, specifically for Serverless, but speaking on CI/CD pipelines. I mean, I always thought it should be CI/CD or D. You know what mean? Just like, is this deployment, or is this a deployment? But anyway, that's, you know. And one of the jokes I say, but truly honest is, if your deployment process includes somebody's name, it's not automated. Because I can't tell you how many companies I've worked as a solutions architect for a partner company, and how many times I would come in, like, "Okay, tell me about your CI/CD process. How do you deploy? How do you release?" "Oh, we're fully automated." "Awesome. Right, so tell me about it." "Well, Bob, does whatever, and then Jan does whatever." It's like, "Stop."

Matt Turner: "Jan's got delegation of authority. If Jan's off sick we know who to call. So we're automated. We're redundant, man."

Eric Johnson: Jan's husband will drive down and push the buttons.

Matt Turner: Yes, we're going to the mood, yes.

Eric Johnson: So yes, so it's like, that doesn't work. I think you're right because... I know for me and I don't want to steal your thunder. And I won't, you're much more eloquent than I am obviously. Well, you're British.

Matt Turner: It's the British accent, yes, absolutely.

Eric Johnson: Yes, exactly. I tried the British accent, my wife just says...

Matt Turner: Say banana?

Eric Johnson: Yeah. No, I'm not doing banana. No, I did it.

Matt Turner: You're not doing it?

Eric Johnson: Oh, no.

Matt Turner: Oh, you got it.

To test or not to test in production

Eric Johnson: It's an old movie stunt. Well, you know what? Never mind. Anyway, yeah, so that always interests me in how people approach that. One of the things that I really encourage folks with CI/CD is, we talked about why, well, why would we go through the process of automating? Because we do have Bob and Jan, right? But the reason is, is that repeatable? We know that every time it's going to go A, B, C, D. And it's not one time because Jan was sick and Jan's husband had to come. It's gonna go A, B, D, C, you know? And so that automation is so critical. But the interesting thing that you're talking about. And we've had these long debates about, whether should you test in production. Should you not? I do think you should test it in production.

Matt Turner: Yes, I cover testing in production.

Eric Johnson: I just don't think you should only test in production.

Matt Turner: No.

Eric Johnson: Yes. So, that's where we're at. But why do you think testing in production? I mean, you kind of alluded to that. Why do you think testing in production is so important?

Matt Turner: Because I think it's the only way you'll catch certain classes of bugs. I'm a Rust fan, right? You should do as much testing as possible before production. And testing, you go to an interview and people say, "Can you draw that agile testing pyramid, right?" And I'm like, "There's a layer on the bottom, you've got your unit tests on the bottom, I think." I literally had this in an interview once.

Eric Johnson: No way.

Matt Turner: Well, I won't throw any company under the bus. But there's this thing on the bottom, it's like unit testing. And I know below that we've got a compiler. If you've got a language with a strong type system, you catch a whole...and a borrow checker and a lifetime checker with a plug for Rust, you catch classes and classes of error down there, right? I know there's the formal methods people, and the, you know, the Haskell people, and whatever. So there's all of the...you should do as much as possible before production. But I think Charity Majors puts it well, you have to admit that you test in production, because everybody does.

Recommended talk: The Art of Unit Testing • Roy Osherove & Dave Farley • GOTO 2021

Eric Johnson: That's good.

Matt Turner: There is zero use. I mean, what's a regression test, right? It's a test case we didn't think of. It's a unit test we didn't have. The user sent us input that we never thought of. A user made that request. What, why did they do that? Okay, write that one down, and store it. We probably did every version of the software because that's so crazy. We need to see what happens. So it's like, testing in production is undiscovered regression tests, maybe is the way to put it.

Eric Johnson: I love that.

Matt Turner: I just came up with that.

Eric Johnson: No, it's good. I'm going to take credit for it though because I think I pulled it out of you. But, so that's the Johnson-Turner. Turner?

Matt Turner: Yes, Turner.

Eric Johnson: So I did remember the..

Matt Turner: The Johnson-Turner hypothesis.

Eric Johnson: Johnson-Turner, it's alphabetical. You get it.

Matt Turner: Turner et al. I see what you're doing. I know your game.

Eric Johnson: Oh, yes.

Matt Turner: But  I think you're right. You've got to test. There are classes of things you're never going to get. The talk is talking about, you can have something deployed, right, standard production, so you hit it with explicit test traffic, you set a header or something. Explicit test traffic, so it's no users are affected. But it's testing in a representative environment. It just means that how many staging environments have you seen that are exactly like prod, right? So, it can't be by definition because they're not prod. Or you just put in huge amounts of time and money. I mean, you must have seen organizations with a huge AWS estate, and then like, "We do IAC, this is great. So, why can't we just make another copy of prod over here for, like, a staging test environment?" It's costing you $10,000 a month, like, or whatever.

Eric Johnson: But, in Serverless that changes some.

Matt Turner: It changes some.

Eric Johnson: It changes some. We had this conversation yesterday, but I don't think it changes enough where we go, "Don't do that. Don't test it in prod." I do think that tests in production and like, you're approaching it with, especially with the canaries, and saying, "Look, just the developers are seeing this," things like that. But with Serverless, if you're not, I mean, I know you are familiar with Serverless. So if you're watching this and not familiar with Serverless, Matt Turner's very familiar with Serverless.

Matt Turner: Say I don't.

Eric Johnson: When you're doing a release, your infrastructure as code because you are...that infrastructure, it's the same infrastructure regardless of which account, right? Because we at AWS are managing all that, right? So, it's the same infrastructure. Because that's what a lot of what you're testing is. I guess, let me say it this way, you're going to  come a lot closer to having an identical environment on Serverless. I won't commit to 100, although we probably are there. But, you know, I don't want somebody to come back, "You said it." So, you know, well, I'll say, "That was Turner."

Matt Turner: It's just the Johnson. That's just the Johnson hypothesis.

Eric Johnson: Well, there's the boss, right? Yeah, there we go. So, you do Serverless?

Matt Turner: But no, you're right.

Eric Johnson: Some?

Serverless vs cloud native

Matt Turner: I've done a little. I've not done that much. Well, okay, so what is Serverless?

Eric Johnson: Okay, I can see. You said you had some questions.

Matt Turner: Well, because I feel like you say Serverless, a lot of people think...

Eric Johnson: I'm glad you asked.

Matt Turner: ...Lambda.

Eric Johnson: So, you say cloud-native, and those aren't the same, although we fall into that cloud-native meaning. So, define cloud-native to me first?

Matt Turner: Well, yeah, that's difficult. There are people out there so much more qualified, I gonna get roasted for this. I mean, to me it's...

Eric Johnson: Do the 100 level.

Matt Turner: Ok. So to me, it is cloud. I mean, that sounds silly. But like we got no data centers, we got no lead time, we've cut... I mean, this is probably getting to what you're going to say about Serverless. We've cut several layers of infrastructure that we have to understand, an operational burden off the bottom of the stack, right, we don't have to do physical security for the data center, and we don't have to think about power redundancy, right, we've got rid of some lead times. So there are the advantages of the cloud, somebody else's computer. Then I think the native part says, we were born there. The system is designed to be there.

So, lifting and shifting into the cloud is absolutely a ground thing to do, right? You should get out of a data center, you should get off-prem, like out of the broom cupboard, lifting and shifting into an easy to and then going, for now, the first step on a journey absolutely valid. But to me, cloud-native is something that was either if you're lucky enough greenfields, born in the cloud, designed and only ever run in the cloud, or something that's where the engines have been changed in flight and you've re-architected something to work in a cloudy way, right? Such as it's stateless as far as possible so that you can get redundancy by horizontally scaling, and can get performance from horizontally scaling. You've got infrastructure as code so that your environments are reproducible around the world and reproducible for tests. So all of that kind of stuff.

Eric Johnson: Yes, and you're right. So, you take that and kind of go to the next level. Serverless is just probably more abstract. Although we say the cloud-native level of service as well. Just simply because we say it's a service in the cloud, rather than you spinning up a VM in the cloud and building your own service. So, the service is abstracting a lot of that work away from you. And with Serverless, at AWS, you can put 100 people in a room and get 100 different definitions of Serverless. Right? So at AWS, we have several tiers that we say there are several pillars. They're not the same as tiers. 

Matt Turner: No. They're like...

Eric Johnson: So the first is, you know, no management, there's no computer, no patching, you don't do any infrastructure management. The second thing is, you pay for only what you use. And that's where we get into some debate. There are people who go, "Oh, they scale to zero because Serverless, you know, at least, a Lambda function, a step function, things like that, they scale to zero." And lots of services can scale to infinity and beyond. That's a good reference right there.

Matt Turner: I like it. Spicy.

Eric Johnson: But they... We might have to trademark that one. But not a lot of services can come back to zero. And I think that's a critical point. However we have some services like a Fargate or something like that, that may not come to zero, but they come pretty close. But they provide massive scalability.

Matt Turner: And they can be faster as well. mean, a lot of the cloud-native technology will get you a long way there. I can get a...I pay for what you use, I can get a Kubernetes cluster, and the cluster scales based on VMs. There are many vendors out there, it'll do cleverly.... When your cluster is going to scale it'll go to the spot market versus on-demand versus your reserved usage. It'll do clever optimizations. And then within the cluster, your workloads, your Kubernetes deployments can scale up and down as well. So you can be pretty elastic. You're always playing for that control plane. And you can…

Recommended talk: Kubernetes: Up & Running • Brendan Burns & Matt Turner • GOTO 2021

Eric Johnson: You always have a base.

Matt Turner: You get down to one of every service and you always pay for the control plane. Maybe that's good enough, right? If you're huge, and like maybe that's fine. And there are lots of advantages I think to living at that level of abstraction. Because you can extend the Kubernetes control plane, you can add a service mesh, you can add all the things. So there are a lot of reasons I think to live at that level of complexity. But if you don't have to...

Eric Johnson: You don't have to, but, of course, you'd want to.

Matt Turner: But so, as in if you don't have the requirements for it, I would say that you'd want to. If you don't have the requirements for it, then yeah, maybe you could use...you know.

Eric Johnson: One of the things we talked, I was playing with you honestly, but one of the things we talked about, and you make some good points is when we talk, because why Serverless, or when Serverless, when Kubernetes, things like that, or when ECS, when Fargate. At AWS, the way we kind of look at it is, first of all, right tool, right job, right? And I am a fan of this, we have a lot of companies that go, "We're Serverless first. But if it doesn't work in Serverless, then we roll."

Matt Turner: Serverless native.

Eric Johnson: Yes. Serverless companies, you know. I won't name a bunch of them because some of them are U.S., things like that. But we have companies that say, "We build everything Serverless first, but some workloads don't work. So we'll roll that off to containers. But the other option we have," this leans more to what you were saying, is, we have some folks that say, "Look, I want to be able to turn more knobs and levers than Serverless gets me." And so if you look at the spectrum of compute in AWS, you start with the EC2 instance, right? Where you manage all the knobs and levers, how long is it up, how powerful compute, all those kinds of things. But, you patch, you know, you do security, you're up in the middle of the night when it goes down, things like that. Then you kind of move up the stack, and you have the EKS and ECS, where you're managing clusters. And you still may, there's a lot of things, but you get some...

Matt Turner: You know, patching operating systems and stuff.

Eric Johnson: Yes, well, you might be depending on what you want. Exactly.

Matt Turner: Well, you can, but you don't have to.

Eric Johnson: But not the core, you know, right? Then you can kind of keep...you know, Fargate works a lot of the...a lot more is abstract down, then finally Serverless. What we talk about with folks is that some of it come down to preference. We know our app more than anybody else, even more than AWS, we being the company, right? We want to be able to modify and turn that, we have the skill set, and that's fine. That's when we say, "Okay, go to EC2, go to EKS, go to ECS," depending on where you are. We have a lot of companies, "Okay, look, we don't want to deal with all that. We just want to put our code in and we want to get moving really fast, proof of concept. We don't have the skill set to patch, manage, and turn all those knobs and levers." 

That's really when people say, "What should I use?" That's kind of one of the things I lean towards, is this is, you know, where you definitely say. And of course, you know, being a Serverless DA for Amazon, I'm gonna say Serverless, because I do believe in Serverless. I'm a huge fan of it. But the right tool, the right job.

Matt Turner: Exactly. I believe in Kubernetes and Istio and a whole bunch of problems that they can solve. I think that's what we look at Tetrate, is if you're a slightly larger organization, your software's been around for longer like you have, there's so much to know, and you've got the people that know all of it. Those levers you don't want to be patching Oses, you don't want to be doing data center physical security. But you maybe want to extend your Kubernetes, extend your network, so you can write some Rust or some JavaScript, you can compile it to WASM, you can inject it into so many places for your network proxies, you can use our Wazero product to embed that into any Golang program. So, you can get that kind of control.

I think we're looking at people saying, cloud-native is great. Like, if you've been born in the cloud, you've only ever done greenfield on a cloud provider then that's awesome. But actually, if you're an enterprise with a bunch of site offices, and a bunch of some stuff is still on-prem, or there are regulatory requirements, or you're multi-cloud, or any of these reasons, and you want, you know, smart, observable, elastic compute, and smart, observable, secure networking. But you've got to plug those things together across continents and across cloud providers, then you need to have that understanding, you need to have that control. We try to take as much of that burden off you. We've got our management playing, we try to take as much of that burden off of you as possible and do what we're good at so that you can do what you're good at. But what you're good at has got to be running those bigger legacy systems.

Eric Johnson: Yes. And, again, as a DA at AWS that was a lot of the conversations we had, as well, as like... You said it earlier, get to the cloud as fast as you can. The folks that run their own data centers, I really, just probably turned into more of a relic.

Matt Turner: Probably.

Eric Johnson: Get to the cloud.

Matt Turner: Get to the cloud.

How to move to the cloud?

Eric Johnson: One of the things that need an answer is, how do we get to the cloud? A lot of times it's that lift and shift as you referred to earlier.

Matt Turner: Well, we found that we can help people with that, actually. So, if you get things into a service mesh, if you have, you can establish like a beachhead in the cloud. You can then get your layers, your smart layer server networking. You can actually apply it in the data center on VMs before you've gone to the cloud before you've gone to containers. We've got ways to get that stuff, right, really easily into the data center and into VMs and get that stuff observable and under control. Because then, you know, you try to move...

Eric Johnson: Then you start that process.

Matt Turner: Being in the cloud is great. Being in a data center is better than being split across two because then you've got a VPN link or like whatever. So, if we can help with that stage, then we actually help find that people find that lift and shift a lot easier. They think, "Oh, well, you know, my stages, I'm going to build up the tech stack," right? "So I'm going to dockerize everything, and then I'm going to put it in Kubernetes, and then I'm going to add a service mesh." And then I'm..." We're like, "No, actually, if you start by getting control of what really counts," which is the sort of resiliency and security of your requests.

Eric Johnson: It's the preparation for... And I think that's where a lot of companies fall, here we are. We don't know how it works, but just get us on the cloud. But if you can come in and go, "Okay, now, we've organized this, we know how it works." Much like what you're saying, "Well, let's add these layers, let's add this. We now have a good..." Because, how many companies have you talked to that would go, "It's kind of a black box to us?" You know, a lot of them. Okay, we know how it works. Now we can, you know. And we talk about strangler patterns, things like that, where we say, okay, let's start pulling some of those out. Excuse me, you have the ability to start plucking those much if you know your application. That's one of like long conversations that I'd have with customers is, "Tell me about your application." "Well..."

Matt Turner: That's the first... Because that's like, "Oh, Dave wrote it. And Dave left 20 years ago."

Eric Johnson: Yes, exactly.

Matt Turner: That's the first... That's how I describe Kubernetes to people, right? Because you can talk about, I mean, I've been on panels where you talk about Kubernetes as the new POSIX. 

It's this great, flexible, extensible API for accessing compute, and it doesn't actually have to be containers underneath, and it doesn't have to be real VMs, it can be some kind of Serverless compute. But, you know, that's the very abstract way to look at it. To a lot of people, it's like, I've got some containers, I've got lots of...and I can run on a container on one computer by typing docker run, right? I've now got 1000 computers. Kubernetes is the thing that, like, does that. So, what I say to people is, okay, all of these configurations, all of these different resources you can make, you're describing your application to Kubernetes. Just saying this is what it looks like when it's healthy and when it's unhealthy. This is how it scales. Oh, you need the minimum this thing forms a Paxos consensus, so I need a minimum of three. You have to tell Kubernetes that stuff. And the same with Istio or any other service mesh. You tell it, "Oh, this is an idempotent operation, this is not." So, you can retry this.

Eric Johnson: You have to know.

Matt Turner: So you have to know. It starts with what you have to know.

Eric Johnson: That's where I think a lot of our companies fail in preparing for that move. How many times? You go, "I don't know, we don't know." And I get that because of what you said, the person who built it is gone. We have to have it. You know, there's no end of life to this, it has to happen. And so, that's a painful point. Or it's, you know, it's on a mainframe. Oh, yeah, or something like, I would take...

Matt Turner: Or it's on a mainframe. I probably can't help you with a mainframe.

Eric Johnson: Ancient side note. We just had somebody in and I can't reference it right now, but I'll have to find, who is running as a custom runtime. They're running RGP. What's the IBM, RPG?

Matt Turner: I'm quite old, but I'm not that old, maybe...

Eric Johnson: What's that?

Matt Turner: I'm quite old, but I'm not that old.

Eric Johnson: Oh, no. But, anyway, it's what you run on it is 400. It's a mainframe and they're running that code inside of a Lambda function.

Matt Turner: Wow, I think that Kubernetes was ported, I'm going to get this wrong. I think it was ported to the Z-Series architecture. And I think it was ported to z/OS. I think you can run it. I think you can run the Kube and all of the sort of, data plane components. I think you can run on z/OS, on a z390 processor. If those are even things that exist. I think they did do work.

Eric Johnson: You're, "What did we need that we had to do that?" You're like...

Matt Turner: It's like, "Who?"

Eric Johnson: "We don't need it. We just could do it."

Matt Turner: It's either that or it's somebody who will never agree to be named funded that development. Like, "I need this. I don't even want to talk about why we're here. Here is a million dollars. Can you all just go and like do these ports for me? And I'll take it away and I won't talk to you again."

Eric Johnson: It's a step backward... Well, I don't know, but yeah.

Matt Turner: It's a step sideways, whatever, I don't know.

Serverless and event-driven architectures

Eric Johnson: Yeah. So let's jump forward a little bit. So we talked about cloud-native, things like that. One of the things is Serverless, I'm gonna post-Serverless on this, yeah. Event-driven architecture, not all event-driven architecture is Serverless, but all Serverless is event-driven architecture. Does that make sense?

Matt Turner: Okay. So, define Serverless. Because I think a lot of people will say Serverless Lambda.

Eric Johnson: Now I'm moving to, you know, I'm talking step functions. I'm talking about Lambda functions. Chris Munns would have tackled me right there. You can't say lambdas. It has to be Lambda functions. So, yes, but...

Matt Turner: Like Aurora.

Eric Johnson: What's that?

Matt Turner: Aurora.

Eric Johnson: Aurora, there's an Aurora Serverless.

Matt Turner: Yes. It's that kind of stuff that I'm asked to read because obviously I'm deep in the Kubernetes world and whatever, like compute networking, I got it, I want to pull the levers, I understand it. I don't understand databases. I just want to call it a database. I just want there to be a network endpoint. I don't want to upgrade the database. I don't want to back up the database. I don't want to certainly patch its OS, because I do not understand that stuff.

Eric Johnson: You want DynamoDB.

Matt Turner: So, to me, yeah, like, I want something... So I can name other vendors. I want a Cockroach, right, or I want a Spanner, or something.

Recommended talk: CockroachDB: The Definitive Guide • Ben Darnell & Guy Harrison • GOTO 2022

Eric Johnson: Yes, Cockroach Mongo. Exactly. 

Matt Turner: So, it's just ambient. Like, I just hit the network endpoint and it just always works.

Eric Johnson: All right, so let me go back. So, Serverless, we talked about, you know, you don't patch, you don't manage, you know, it's a skill zero or it skills as you need it. We talked about paying for only what you use, and then all the security and stuff is built in, and we handled that. In this, well, I'm just going to manually box it to say that at this point I'm talking about, you know, get Lambda function, step functions, event bridge. I'm talking obviously AWS services. API gateway. Do you work with EDA at all, like event-driven architectures?

Matt Turner: I haven't done too much in the cloud. It's something I need to get to.

Eric Johnson: Okay. That's something that we're driving at as we're teaching folks. So, this again, kind of comes back to the knobs and levers, right? We have a lot of folks, it's like this mentality, who say, "We don't want to do all the knobs and levers, we just want to say, this happened, do something." And this is where Serverless really sells.

Matt Turner: And you think Serverless is the best way to do that?

Eric Johnson: I do. Yeah, I do in this respect because I'm not... One, I shouldn't have to have a server sitting out there, or a cluster, or anything saying, when did it happen? Listening on port 80 or port 443 and saying, when did it happen? When did it happen? Instead, I should just be able to say, "That happened, I'm gonna do something," right? And so, for instance, an IoT button, data saved to a database. You know, files dropped in a bucket, things like that. So it's a different way of thinking, of pooling, or always listening. And what we're seeing, it allows customers... And it's also kind of a shift more...maybe this is another question for you, it's a shift more to asynchronous processing versus synchronous processing.

Matt Turner: So, I'm a big fan. And actually, I'm quite an old guy. You see things come around in cycles, right? So, it's like, I'm thinking, I was always a massive fan of Rx, the Rx libraries, RxJS, RxGo, RxC#, that kind of observable base, you know, that's asynchronous, it's pool-based. And those things though, they kind of...you download that library into your program, and it just kind of works. But then sometimes you need to take more control of like, here's the compute pool, here's the thread pool for like this stage, because this is the bit that's the bottleneck or something. So we were doing that in process. And I've done a bunch of Elixir in my time, so sort of Erlang stuff. So the actor model is also a really nice kind of event-driven architecture. These tended to be on one, like in one process on one machine. These were like monoliths. And I talk about this when I talk about microservices. I'm like microservices are great. They've got a bunch of advantages. They were about decoupling deployment. They're about making architecture...

Eric Johnson: Distributed.

Matt Turner: ...understandable to teams. They're about distributing things. They're about getting those independent security contexts and sort of scaling boundaries and stuff. People just talk about all modularity, but like we will never be bad at... I mean, there was definitely some mess made, but like we knew how to make...the knowledge was out there of how to make a good monolith. You had interface-driven development, you had compartmentalization, you had DDD, right, we were pretty good at making a sort of nice, compartmentalized, dependency injection frameworks, all of that kind of stuff. We were quite good at doing that with monoliths. And yeah, all this event-driven asynchronous architecture. I've seen it inside a monolithic, inside one BEAM VM, right, one Erlang program, or inside one massive piece of Java, right? You can have a million lines of Java, that this utterly sprawling mess with your dependency inversion problems and all kinds of stuff. Or you can have something that's actually Akka Scala or it's actually RxJava, and it's really, really nice. So I've always been a fan of Akka and stuff.

!-- wp:spacer {"height":10} -->

Recommended talk: The Many Meanings of Event-Driven Architecture • Martin Fowler • GOTO 2017

Eric Johnson: And I didn't even know we're saying we invented event-driven. I know it's been reg-...

Matt Turner: So, I wasn't saying that.

Eric Johnson: You're welcome.

Matt Turner: That's the Johnson.

Eric Johnson: Yes. Just Johnson's event-driven model. So, no, event-driven has been around for quite a while. But I think there's a power, we struggle with folks who can't understand. Just like asynchronous versus synchronous. That's not always the case. You can have synchronous events being thrown in and responded to, but most of it does kind of move to an asynchronous move, but yeah, I know... So, kind of a side quest here. The last time I did one of these interviews several years ago, was actually with one of them, I don't think he was the founder but he one of the core users of Erlang. And I'll have to come up with the name, and I know that the folks probably hanging out probably know.

The BEAM languages and event-driven architecture

Matt Turner: Because it came out of Ericsson right in Sweden. It was the Ericsson language. Oh, wow.

Eric Johnson: He was there when all this was happening. Ulf Wiger. Do you know him?

Matt Turner: No, I've not heard of him.

Eric Johnson: They were... And then the other guy was like the genius of Elixir and how Elixir was based on... I mean, I can't spell. Either one of them, you know, so...

Matt Turner: Apologies to the Danish speakers. I couldn't do that.

Eric Johnson: Yes, Elixir is something you mix in a bottle, right? It was fascinating, and I've done a little Erlang. Erlang has a great framework for communication between devices. And we had to set up RabbitMQ. And you had to, I mean, literally, I'm just reading docs, and pushing buttons, and stuff, but I got it working. And it was this event-driven kind of queueing system.

Matt Turner: But within a process, everything is an actor. So, you sort of take the textbook definition of object-orientated programming, I guess, came from Smalltalk. So, they say that your passing message, think of it as passing messages between objects. But of course, you're like in Smalltalk, maybe you are in Objective-C, actually, you kind of are. But in C#, or Java, or C++, you're making a function call, right? You're pushing some arguments onto a stack, you're changing the program counter. Like it's very coupled. It's very synchronous. But Erlang actually says no, each instance of an object, of a class, if you want to look at it like that, each one of these actors genuinely does have like an inbox and it has messages. So, it has its own little thread. I mean, it's a lightweight thread, but it has its own little thread of execution that it'll sort of churn through the messages in its inbox.

Eric Johnson: And if it goes down...

Matt Turner: And if it goes down, then there's actually a service discovery. If it goes down it'll get restarted. Like, if it crashes, it's isolated. It doesn't take the rest of the monolithic process down.

Eric Johnson: And that's built into the framework.

Matt Turner: Yeah, so that's good. So, the BEAM, BEAM is the name of the VM. On the JVM you can compile Java, Kotlin, Scala for JVM. Erlang was the original language. So Elixir is like Ruby for the Erlang VM, is how I describe it. So it's a much nicer, more modern-friendly language, it just compiles to BEAM bytecode. So, you can look at one running like Linux process. That can even be a distributed system and have a bunch of actors inside it. Then as you say, you can take that, they had like a native mechanism to take that across machines, where you would run BEAM. Your actors, you would have like 10,000 on this machine or 10,000 on that machine. And you'd have to set up a message boss for them to communicate over.

Eric Johnson: I'd say this has been... I know it says in my title, developer advocate. And really, it's because they can't fit somewhat of a developer cum advocate. I'm an architect. That's what I do.I'm a Serverless architect working with Serverless. So, this has been a... I learned a lot from you, honestly. You obviously know deep knowledge, and I love it.

Matt Turner: But I've just been around it. But I've always liked that stuff.

Eric Johnson: Well, yeah. Well, you're a nerd.

Matt Turner: I've always liked those patterns.

Eric Johnson: Yes. big time. It's all right.

Matt Turner: I played with a lot of this stuff. And so, you can...

Eric Johnson: I'm not judging.

Matt Turner: But this guy's a nerd.

Eric Johnson: But I love how much information is in this. This is a session in itself on just understanding a lot of your thought processes in coding and development in language and things of that sort.

Matt Turner: Well, maybe. I'd have to really think about it. And this session would have to mean not like... What's the best way to put this? This session can't be like, oh, this is audio. What are you all talking about? Like, this has all been done before.

Eric Johnson: What does Turner know?

Matt Turner: Well, either that or like, "Oh, shut up about your Kubernetes. It's just Erlang. Shut up about your Erlang. It's just Smalltalk."

Eric Johnson: You obviously love it. 

Matt Turner: And I love this. I mean, I think I love that pattern when you talk about adventure in architecture. It's a pattern I've always loved.

Eric Johnson: And it works.

Matt Turner: So to say, and it works. We're kind of taking it to the next level, putting it, you know, in the cloud. As I say, you had all these actors in one Unix process, and you had them across machines. Now each one is a pod, or each one is a Lambda function or something. I really loved Elixir could do it. And Scala was very good at it. There was a DSL you could write. Because how many of those independent little communicating processes are just state machines?

Eric Johnson: Desired State Language, is that what DSL?

Matt Turner: Oh, Domain-Specific Language.

Eric Johnson: Okay. All right.I think the desired state was Microsoft.

Matt Turner: Oh, maybe.

Eric Johnson: There's maybe talking about your... Yes, there was the desired state process.

Matt Turner: There are these things, these TIs have been reused many times. I can't remember that one. A language that's got a syntax that's flexible enough that you can sort of extend it. So, you can make, like, a language within a language. So, in Scala or Erlang, you could write...you could just be very explicit about a state machine. Like, here's my state table what state am I in? What input did I get? Do this little thing. Because you find out that so many of your... Think about how many classes in Java, if you really squint at them, actually could be reduced to quite as simple as, I'm in this state, I've got this event, do this, go to that state. Like, just that tuple of...

Eric Johnson: Simple. One thing.

Matt Turner: Yes, that three tuples of, where am I? What came in? Like, what am I outputting? Where am I going? Okay, that's a four-tuple life and there's a fifth element actually, like a formal definition of a state machine. But in these systems, you could often just write. I think that's where something like Serverless, something where we don't care about the infrastructure underneath is really great. Because maybe something does need to be a complicated piece of compute, maybe I've lifted and shifted it, maybe I've bought it from a vendor, maybe it's whatever, something on an EC2 or in a pod. But then this part of the system, we can just model that as a state machine. So I'm just gonna write it in SAM or whatever, and we're just gonna let it hum. And I don't care about any levers on that. Like, you know?

Eric Johnson: There's a lot of power in that. I know we are out of time.

Matt Turner: We are. We need to wrap it up.

Eric Johnson: So, yeah, I'm gonna wrap this up.

Matt Turner: You might get one last pitch in first for...

Eric Johnson: Fantastic.

Matt Turner: Elixir and DSL.

Eric Johnson: We are live from Amsterdam, Matt Turner.

Matt Turner: Eric Johnson.

Eric Johnson: And Eric Johnson Johnson. The Johnson-Turner hour. And Turner after Johnson hour. And so, no, enjoy the time. I hope you enjoyed this. I hope you get some stuff out of this. And anything you want to say before we go?

Matt Turner: No, it's been fun. That's the great thing about being unscripted, isn't it? We just sit down, we see what we chat about. We've kept it pretty civil. We've agreed on most things.

Eric Johnson: No, I've fairly enjoyed the talk.

Matt Turner: No, it's been fun. It's been a lot of fun. Great pleasure to speak with you, Eric Johnson.

Eric Johnson: You bet. Enjoy the rest of the conference. And we'll see you later.

Matt Turner: See you around.