Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Event Driven Architecture
38 Plays1 year ago
In this episode of the Basement Programmer Podcast I speak with James Eastham from AWS Professional Services. James and I talk about event driven architecture and .NET. Learn what event driven architecture is and how it changes the way we think about state. Special bonus for those who listen to the end you can lean the secret behind the name “Plant Power James.”
Twitter: @plantpowerjames
YouTube: https://www.youtube.com/@serverlessjames
Recommended
Transcript
Introduction and Podcast Overview
00:00:11
Speaker
Hello basement programmers and welcome. This is the basement programmer podcast. I'm your host, Tom Moore. The opinions expressed in the basement programmer podcast are those of myself and any guests that I may have and are not necessarily those of our employers or organizations we may be associated with.
Call for Participation and Suggestions
00:00:28
Speaker
Feedback in the Basement Programmer Podcast, including suggestions on things you'd like to hear about, can be emailed to me at tomatbasementprogrammer.com. And I'm always on the lookout for people who would like to come on the podcast and talk about anything technology related. So drop me a line. And now for this episode.
Guest Introduction: James Easton
00:00:47
Speaker
Hi, everybody, and welcome to the April episode of the Basement Programmer Podcast. This is Tom, your host, and this month I'm joined by my colleague and fellow serverless .NET enthusiast, James Easton.
00:00:58
Speaker
James, welcome Tom. Thank you for having me on. I'm excited for this conversation. Looking forward to it. Me too. So James, tell us a little bit about yourself and what you do.
Journey to AWS Cloud Architect
00:01:10
Speaker
So I'm James Easton. I'm a senior cloud architect here at AWS based in the UK, and so I actually work in the professional services part of AWS, so I get really hands on actually helping customers build things with AWS. So that's kind of
00:01:27
Speaker
My day job, I always like to say by night, the K power is the whole.net serverless. That's kind of my real area of interest. You know, building things with.net on serverless technologies and helping people upscale. Cause there's kind of some shifts that you need to have in your thinking when you start building really serverless native applications. Cool. So how long have you been using.net? Oh gosh. I think framework.
00:01:58
Speaker
maybe 35 possibly. So I wasn't quite a framework one developer, but I've been around for a little while, so I started off. Started off in front line support. I think this is maybe a typical route into tech and then quickly realized supporting the system in a GUI that teaching myself SQL would be an interesting way to help debug things easier. Then I learned SQL and thought actually this.net thing seems kind of interesting. This was Microsoft SQL Server.
00:02:26
Speaker
then thought this whole.net thing seems interesting. Imagine how much more useful I could be if I knew.net and then talk myself.net and then the kind of snowball effect from there. A lot of the work I've done with.net is kind of building integrations around systems, so I did a lot of work with OCR technologies, technologies installed on Windows servers that need to integrate with manner of different things. Windows services, console apps, task schedules, you name it, it's been there, done it.
00:02:56
Speaker
So I too actually got my start doing frontline support, but in my case it was for an antivirus company. OK, yeah, I think you learn an awful lot in frontline support about both dealing with customers, interacting with customers, handling problems. I think it's a real I recommend it to anyone looking to get into tech is have a go at frontline support because it teaches you a lot. Absolutely. So what is
Benefits of Serverless Technologies
00:03:19
Speaker
it about? What is it about serverless that you really like?
00:03:24
Speaker
There's a few things I think. So, you know, there's the kind of cost benefits you pay for what you use, lack of operational overhead, patching, you know, I don't imagine you liked it as much as I did, but installing patches on servers, like, nobody wants to do that. So there are some of the high level things, but I think actually my favorite thing about serverless is developer velocity, like just how quickly you can get
00:03:51
Speaker
things out into the world for people to use. So I've been doing some work with with Kubernetes recently, you know, the naughty word. And there's just like so much I had to do before you could even run a line of code. Like there's the networking, there's the clusters, there's all this stuff you've got to think about. And then doing that after having worked with serverless.
00:04:13
Speaker
at the speed you can just get things out and get things in front of customers and delivering value is just incredible with serverless. You focus on your business value, deploy that and let companies like AWS worry about the rest. So that's by far my favorite thing. Just get things out quickly, get them in front of people, get them using them, as well as all the other benefits, cost benefits, et cetera.
00:04:33
Speaker
So you don't like the idea of patching a server and immediately having it fall over because of some incompatibility? That's fun. I don't. I think my least favorite memory of working with servers is I once logged into a server, did some stuff Thursday evening, hit shut down, thinking I was shutting down my laptop. Lo and behold, I was shutting down a production server. So yeah, I don't have good memories of doing things on servers.
00:04:59
Speaker
Oh, dear. Yes. Indeed. Oh, dear, indeed. So we're here today really to talk about event driven architecture.
Understanding Event-Driven Architecture
00:05:08
Speaker
So what does that really mean when we talk about event driven? I think an interesting place to start with event driven architecture is actually just to define what an event is, what is an event.
00:05:24
Speaker
And an event is simply a signal that there's been a state, a change of state in a system. Events are typically immutable and they're always in the past tense. Like they have happened. They can't be changed. So there's a nice analogy I've got from one of my colleagues about a light switch. You know, something we all do every day. You turn on a light. That's a light switched on event. You can't un-switch on a light, right?
00:05:53
Speaker
The way you turn off a light is the light switched off, event light goes off. So they're completely immutable. And I think one thing I'll always add when I talk about event-driven architecture is that this isn't using events in systems isn't a new thing. Events have been in systems in programming, in systems designed for an awful long time. So it's not a new thing, but I think that definition of what an event is is a really important understanding to have when you first get into event-driven architecture.
00:06:22
Speaker
Now I got to say my kids probably wouldn't understand the concept of the event of the lights turn off. Only when dad goes in church. So it's kind of like in Windows programming back when you click a button and something happens. Is that where we're kind of going with this? Yes and no. So I think.
00:06:49
Speaker
This might be a little bit of semantics, but I'd actually consider that an event based system. So you're using events to trigger functionality in your system and it helps you build loosely couple things in Windows programming like you've got your UI layer, you've got your business logic layer, and you've got these events that are kind of gluing things together. But I think there's a couple of key differences when we think about event driven architectures as we're talking about in this conversation. And the first is, I think the most important is that
00:07:20
Speaker
Events are the first class citizens of your application. Events drive everything, and these events are business events. I think that's one of the most important things with event different architectures. These events are relevant to your business. So with your Windows programming example, your events are going to be things like, you know, submit button clicked, for example. Whereas event different architecture, your events are things like order created, order confirmed,
00:07:48
Speaker
order deleted, delivered, et cetera. These are the kinds of events we're talking about in event of an architecture, which is maybe slightly different to how events were maybe viewed in more traditional programming. So it's really tied down to business value. Yeah, exactly.
Asynchronous Systems and Communication
00:08:06
Speaker
Everything is about the business context. And I think
00:08:09
Speaker
The second thing, I suppose, which may be slightly different to more traditional event windows programming type is the asynchronous nature of event architecture. So again, if we stick with this Windows GUI example, when I hit a button in a UI, that raises the button clicked event, but I'm expecting some kind of synchronous response, right? It might not be synchronous like under the hood, but I'm expecting a response that's kind of synchronous.
00:08:36
Speaker
Whereas event-driven systems are fundamentally asynchronous. Something happens in my system that causes a change of state, and I publish a business event or the created. And I'm not expecting anything to happen off the back of that. I'm just notifying the world that this thing has happened. And other components of my system, other pieces of the architecture might choose to react to that. They might choose to completely ignore it.
00:09:00
Speaker
Some systems might even be interested in like a subset of the events. So maybe your loyalty service is interested in order confirmed events, but only if the value is over $100, for example. So I think there are two big differences, I see, with more how events have been used in systems in the past, as opposed to event-driven architecture in the way we talk about it today. And that fits really nicely with things like Lambda and serverless.
00:09:25
Speaker
We've got these events, the systems that are only reacting to events when they're interested in them. And then we've got Lambda, which is completely event driven compute events are what source Lambda is reactive. So these different concepts kind of play really nicely together as we start to build out systems. So why would a customer want to do any of this? It sounds like it's an earth shattering change.
00:09:51
Speaker
Yeah, there's a few reasons, actually. I put quite a bit of thought into this. Why? When I give conference talks and things like that. I always like to start at the why. So I'm really glad you've asked this question up front. And I think my favorite reason about the why is one that I don't often hear talked about all that much. And that's about the language of the application. So with systems design, we've had domain-driven design, I think, since 2003. I think the book was published, the big blue book.
00:10:21
Speaker
And part of domain-driven design is this idea of ubiquitous language, which is using the same language in the business as you would using your application code. And then it makes that conversation really easy between the business experts, the domain experts, and the developers, because you're all speaking the same language. And I think when you start building out event-driven architectures and make events the core of your system,
00:10:45
Speaker
it brings that ubiquitous language to the integrations, the interactions between parts of your system. These integrations are now expressed in plain English that everyone can understand. Maybe unless it's my English, then maybe not quite as easy to understand with my accent, but most people would understand. It no longer becomes a conversation then about Service A talking to Service B over HTTP. It's
00:11:11
Speaker
conversation phrased around, you know, what would happen, Mr. Business Expert, when an order is confirmed, for example. So we're talking about things, you know, the integrations are in a language that everybody understands them. And I think the other really interesting reason to start looking at event of an architecture is around coupling. You know, coupling is one of the biggest challenges in system design. And I think there's a spectrum of coupling
00:11:41
Speaker
from tight coupling and tight coupling would be something like a HTTP API call, for example. And if we consider the fallacies of distributed computing, which makes me sound very intelligent when I say that, but actually it's somebody else thought of. But this was an idea back from a group of folks at some microsystems in the mid to late 90s. And the fallacies of some false assumptions programmers knew to distributed computing make. So things like,
00:12:11
Speaker
the network is reliable, latency is zero, bandwidth is infinite, the network is secure. People always laugh when I read some of them out. But if you've got a really tightly coupled system over HTTP, and I think you can fairly say that anything you're building in the cloud is technically a distributed system, that becomes really tricky because then you're over a network that brings in all sorts of potential issues with HTTP.
00:12:41
Speaker
I, sorry, I laugh because as you know, when I was full-time as a developer, you know, something will go wrong in your app and you'd say, Oh, it's the network's problem. Yep. Well, it's first place to check. Is it the network? Is it DNS? Oh, that could be a problem. What? And I mean, the other thing with tight coupling that every time you want to add a new integration or a new piece of functionality to your system, it means a code change everywhere. Like.
00:13:08
Speaker
We'll stick with this e-commerce example because it's just an easy one to think about. But let's say you want to add a membership service to your e-commerce system. OK, now your membership system needs to communicate with my order system and maybe my delivery system, which means them systems all need to know where each other are and that the network's there and that the DNS names are right and they resolve to the right location.
00:13:31
Speaker
This then leads to that massive, and we've all seen the big webs of, I'm guessing with my hands that people can see me, leads to these big webs of service integrations that people seem to be really proud of that look really, really complicated if you ask me, but that time coupling leads to that, doing things over here, it's DTP. The other end of the spectrum, you've got no coupling, which a component exists without communicating with anything else in the world, which
00:14:00
Speaker
I imagine there's an awful lot of systems doing that Tom, but maybe you know some, but I'd love to know what value they add if they're integrating with nothing at all. I was going to say, it doesn't sound like a particularly useful system. No, no. So, I mean, a level up from no coupling is what we call loose coupling, like a loosely coupled system. And there's a quote I really like when I'm coupling it from Gregor Hoppe,
00:14:27
Speaker
who wrote the enterprise integration patterns book, if you aren't familiar, but it's an awesome book. And the core is the amount of coupling required depends on the level of control you have over the endpoints. So if you're me and you were working on the same team, Tom, and we own four different microservices, coupling them together more tightly isn't potentially that big of a deal because we own the release cycles, we own the DNS, we own the SLAs, we own all this stuff.
00:14:58
Speaker
But once you start integrating with other things, whether that be third parties, whether that be other other components within your company, you want to try and reduce that coupling as much as possible. How does that relate to event driven architecture, you might ask? Because if you're designing your system in an event driven way, that forces you to think about your system in these immutable business events, which therefore then naturally force you to think more asynchronously.
00:15:26
Speaker
event first, which then naturally leads you to be more loosely coupled in your system because you're thinking about things asynchronously. Cool. Well, I will say this, if anybody's listened to the podcast and they have a use for a zero coupled system, please get in touch with me. James and I would love to talk to you. We really, really would. We really, really would. And I mean, even with like a loosely coupled event driven system, you still do have some
00:15:52
Speaker
elements of coupling in places so things like your schemas of your events right like that's one of the potential challenges that people run into when they start doing event driven systems because your schema is almost your point of coupling like someone consumes your event they expect it to be in a specific format if you massively change your scheme and all of a sudden
00:16:12
Speaker
Although you don't care about people who are consuming your events, you kind of need to a little bit because people need to work with these events and do things with these events. So just changing them every other day is difficult. So there's a lot of really good content that David Bein, one of the serverless developer advocates here at AWS has got around schema management and things like that. I'm sure we can grab some links to put in the show notes, Tom. And David's got some really good talks about that.
00:16:39
Speaker
So yeah, I'm listening to you talk about this and I'm thinking back to when I started and obviously people can't see that I've got a lot more gray hair than James does. I started off as a systems programmer. We do things like Windows services, so you'd have an app that just sits there and then it waits and it checks the directory to see if a bunch of files have come along and it doesn't work and then it goes to sleep for awhile. And how does that model change when we start talking about adventure of an architecture?
00:17:11
Speaker
So one of the most important things in that Windows service example you're talking about there, you know, everything that needs to happen to that file is likely happening in a single process. You know, that's one process that they're going to sleep waking up. And that makes. Any integrations or any any patterns or anything like that quite easy because it's all in a single process. But once you start. Thinking about event driven architectures and serverless.
00:17:37
Speaker
What you end up with is actually all these little discrete pieces of functionality, guest room with my hands again, of course. Sorry, everybody. All these little discrete pieces of functionality that are all integrated with each other. So I think the biggest difference I see with the move from what you described to more serverless applications is the integrations between things. So one of my mentors, he's once said to me, when you do an architecture diagram, it's not the boxes you need to worry about, it's the lines.
00:18:06
Speaker
And that becomes even more important in event of an architecture, because everything's asynchronous, because everything is happening, you know, things could be hooked into things and people could start listening to events. It can become quite hard to rationalise about the individual components themselves. And I think that's where patterns and talking about different patterns becomes really, really important when you're thinking about event of an architecture.
00:18:32
Speaker
So again, going back to your Windows service example, everything is written in .NET and we have a language around programming in .NET. You've got the gang of four. You've got builders patterns, mediator patterns, factory patterns.
Transitioning to Event-Driven Systems
00:18:44
Speaker
But then if I was to say to you, Tom, you know I want to integrate this system and this system in an asynchronous way. Would you jump straight into services? I think that would jump straight into SQS, SMS, EventBridge, for example.
00:19:01
Speaker
Yeah, it's interesting. The other thing that jumps out on me at this conversation is we used to love our sleep statements and you haven't mentioned sleep once. Yeah, absolutely. These things go to sleep by themselves. Yeah, that's one of the beauties. If we go back to the opening question around what I like about servers, that's one of the absolute beauties using something like Lambda processing a file.
00:19:28
Speaker
your lambda function contains only your business logic, gets the file event, reads the file from say S3, finishes its work and then just automatically goes to sleep and while it's sleeping you're not paying for anything. With your Windows service example when your service isn't doing anything you're still paying for the server that it's running on just in case something might happen. You're still paying for the people time of maintaining that server and managing that server like these kind of
00:19:52
Speaker
costs that I think people don't think about sometimes. So yeah, this reactive programming example really helps with situations like that where you've got these kind of sleep and wait type situations. And again, this is where I think that patterns are really important when we talk about this. So that example I've just posed, I want to communicate between two systems in an asynchronous way.
00:20:18
Speaker
OK, so we think about AWS services. You might go SQS, SNS, event bridge, etc. And then maybe get really confused about which one to pick. Whereas. When I said think about the integrations between your components, I think we should start asking the questions of what type of communication do we want between our components? So do we want like a message channel where you have a separate channel for each type of message? Do we want publish subscribe where you just publish your event and
00:20:48
Speaker
infinite number of people can listen to it. I do want like a point to point channel where every message is consumed by only one receiver. Like I think because these integrations become so important when you're building event-driven systems, exploring them integrations a bit more deeply becomes really important because otherwise you'll just default to HTTP and then everything's that big web of mess over a network again. So I think they're the kind of things you need to be thinking about when you're
00:21:17
Speaker
moving from maybe non event driven non serverless to serverless. And then the services naturally start to fall out at that point. You know you want a message channel where you've got a separate channel for each type of message. SNS topics. Publish, subscribe, lots of receivers, event bridge potentially. Potentially SNS, but I'm not getting to that. And you know you want point to point and point to point one receiver, maybe SQS and something a bit more point to point.
00:21:46
Speaker
coming from that non event driven non serverless background into a event serverless background. Not that people didn't used to think about integrations and how things talk to each other, but it becomes really important because you've got these really small pieces of functionality that are all working together to create a whole or a bigger thing.
00:22:09
Speaker
Well, you actually already answered kind of answered my next question, which is going to be, you know, if we if we have taken this effort to move our applications to event driven architecture, how do we figure out just how to do all these connections? Because as you mentioned, there's like a whole bunch of different options here and how you can get the multiple different event handlers or event processors to do stuff.
00:22:38
Speaker
Yeah, this is a challenge I speak to customers about a lot, especially in the .NET world, maybe the Java world as well, these long-lived languages that have been around for 20, 30 years. You're going to have some older legacy stuff, but then you also might want to start using some of these newer serverless paradigms.
00:22:58
Speaker
probably still communicate between the two systems and Lambda will scale up to a thousand concurrent executions by default. Can your old Windows 2012 server handle that kind of load? Maybe not. So yeah, it is a real challenge when you have legacy stuff around, but there are different patterns you can use to start to work with this.
00:23:20
Speaker
You know, you probably want to start with something Q based if you've got something legacy integrating with something more scalable and more modern because a queue gives you that ability to control the load that's hitting your old system. You can have that buffer if you will between your old system and your new system. And then alongside that queue, you might use something like an adapter pattern or a channel adapter pattern and a channel adapter again is another pattern described in the enterprise integration patterns book.
00:23:50
Speaker
But the channel adapter is useful when you're connecting a system that isn't built with messaging in mind to a system that is. Which is kind of what we're talking about. Some legacy old thing talking to a new serverless system. And let's you know, let's think about this with you know of.net and an AWS frame around this. Let's say we've got an old.net framework API running on a Windows Server and we've got a lot of modern.net 6 stuff running in the cloud. So what we might do is put
00:24:20
Speaker
may be an SQS queue in the middle, and then maybe a Lambda function next to that SQS queue. And the SQS queue and the Lambda function will be owned by the legacy system, if you will. And then what that enables you to do is define the types of messages that you want to land in the queue. So let's say you're interested in order confirmed events.
00:24:42
Speaker
they're landing your queue, and then you can use that Lambda function connected to the queue to both control the load on your system because there's various little knobs you can tweak in the Lambda and SQS integration to kind of control how fast messages are pulled off the queue. And then you can use that Lambda function to access the translation layer or the proxy layer to take that event, translate that into maybe a HTTP request to then fire off to your .NET Framework web API within a Windows server.
00:25:13
Speaker
You can attach your Lambda functions to a VPC, so then that gives you that ability to route into the network. And then you can even do the same on the way back out. That HTTP server might return a response. And then you can use that same Lambda function to handle the response and maybe even publish an event. Who knows? So there's patterns you can put in place to kind of work with these legacy systems alongside your more modern, more cloud native systems. And I think there's actually a really
00:25:43
Speaker
interesting pattern. If you've got some legacy CRM system that doesn't actually differentiate your business from any of your competitors, do you want to invest however many man hours into upgrading that or modernizing that? Or actually, could you just leave it where it is and then put some time into building a nice integration that works with it? Everything doesn't
00:26:09
Speaker
necessarily need to be modernized if it's not adding value to your customers potentially. Right so you've talked quite a bit about you know different ways and architecture and things like that which for somebody who isn't familiar with it might be a little bit difficult
00:26:31
Speaker
Do you have any tips on ways that you can make life easier for the .NET developer who wants to move into event-driven architecture and serverless, all this cool stuff, but maybe isn't quite there yet?
Enhancing Observability with Lambda Power Tools
00:26:45
Speaker
Yeah, absolutely. There's a bunch of different best practices and some tooling that AWS has built to really help .NET developers get started.
00:26:55
Speaker
So the first is probably Lambda Power Tools for .NET, and this went GA I think three weeks ago. I think four weeks ago, so it's quite new. But the Power Tools suite is a set of libraries across all the different runtimes that. Make things easier to develop in Lambda, so the initial release of the .NET Power Tools supports logging metrics and traces. And it abstracts away
00:27:26
Speaker
a lot of the complexities that might come with that. So the logging utility, for example, supports structured logging out of the box. So you're just doing a logger.log information, your log message. And when that actually gets written out to CloudWatch, to the logs, it'll be structured. It'll have a structure. It'll have the service name. It'll have the environment name. You can automatically log the incoming event. The metrics utility,
00:27:53
Speaker
uses what's called the embedded metric format, which is a way to write a log message to cloudwatch and then cloudwatch will read that log message in a specific format and actually create metrics off the back of that, which saves you a whole bunch of cost in making calls to the metrics API endpoint. So power tools is really cool for a. From like a observability perspective and then with some of the other runtimes that are a bit further ahead than.net, they support things like.
00:28:22
Speaker
So managing idempotency for you and they support things like parameters so you can configure it and just know parameter dot get parameter and it will set up that connection to systems manager or secrets manager or whatever. So that's going to grow and if people are really interested in. What they'd like to see in power tools, what would be useful then? You know this is all open source. It's all on GitHub, you know, raise issues and the team will be happy to get back and contribute on that.
00:28:52
Speaker
Another really useful tool is the Lambda annotations framework. And what the Lambda annotations framework does is makes it really simple to build Lambda functions. It abstracts away some of the boilerplate code that you might get when you're building Lambda functions. So we think about APIs as a place to start. When you're building an API in .NET in ASP.NET,
00:29:20
Speaker
a lot of it is like attribute base. You know, you add an attribute to your method that says this is going to be a HTTP get and this is the root and then your actual method priorities or your actual objects. Let's say it's a post request, not a get request. And ASP.NET handles all that JSON C realization and DC realization and all of that stuff for you. Whereas when you first start building
00:29:43
Speaker
Lambda functions in.net, you'll find if you're building APIs that you've got to do a lot of that boilerplate yourself. There's a really great example on the launch blog of a API endpoint that adds two numbers together, X and Y. And there's like, I think 30 lines of code and like one line is X plus Y. That's it. That's all it will be boilerplate going on around it. So what annotations framework does is it
00:30:09
Speaker
moves towards this more attribute based model so you can add an attribute to your method in net and the attribute is Lambda function is the name of the attribute. And what will happen at compile time is that the compiler will use source generators to generate all of that boilerplate code. So you have an attribute to your method of Lambda function. You had a second attribute of HTTP post. In your method you have a from body attribute and you have
00:30:38
Speaker
you know your object and the name of your variable and annotations framework will compile time generate all of that boilerplate to do the JS on serialization and DC realization to check that the path parameters exist. You know all the things that ASP Net does for us that we're really used to and really love as.net developers and brings that to Lambda as well. So they're just two really really useful tools you can use to get started if you're working with.net and Lambda.
00:31:08
Speaker
really interesting when you're talking about, especially the power tools, because, again, stepping back into the idea of a Windows, like a Windows systems programming, you didn't have to worry about things like metrics, or as much, because everything was right there, you got one process. Yeah, I mean, I think the other thing that's really interesting with power tools as well, prior to power tools, if you wanted to do structured login, for example,
00:31:35
Speaker
You'd need to be using something like seri-log or some third party library to do that structured logging. One of the ways to use Lambda in its optimal way is to minimize your dependencies as much as possible. You want as few, keep your bundle size small and that'll start to help with cold start. What PowerTools does is it builds that structured logging on the fly, if you will. PowerTools doesn't use seri-log, so you're therefore introducing two dependencies.
00:32:04
Speaker
It's all done kind of in line, so it. It helps you minimize the total number of dependencies that you're going to have because you've got this one set of libraries that can do both logging metrics and traces and do it all for you. Now you just mentioned something called cold starts. Can you talk a little bit about what that is? We can't or anybody who isn't familiar with it. Yes, so the way that.
Explaining Lambda Cold Starts
00:32:30
Speaker
So we've already said that you know Lambda is reactive. You only pay for what you use and you know that that's to the to the milliseconds. So a cold start is what happens is when a new request comes into your system for a function that might not be ready to receive it just yet. So what actually happens under the hood is every request that comes into Lambda comes into a worker service or a front end service and that service is going to look to see.
00:32:58
Speaker
if there is an existing execution environment available for that specific version of your Lambda function. So we'll have a look around across the fleet of all these of all these bare metal machines and it'll say is there any execution environments? No, there isn't. So at that point Lambda then needs to create an execution environment for to handle that request.
00:33:19
Speaker
So that includes starting up a macro VM, downloading your function code from S3, or if you're using containers, pulling that from a container repo, setting up the runtime. And then at that point, that execution environment is now ready to receive a request. So that's what's known as a cold start. It's that time taken for this execution environment to become available. Now, once that execution environment's available,
00:33:46
Speaker
It can then be used again, so the the hang around foreign non SLA'd amount of time that makes any sense. So you know the hang around for a little bit. If you don't have any usage on your function for a little while, that execution environment will get will get torn down. Now an important thing to remember with execution environments is that each environment will only ever process one request at any one time.
00:34:11
Speaker
So if you've got two requests into your Lambda function at exactly the same time, you're pretty likely to get two separate cold starts. But then remember, then you've got two warm execution environments both sat there available ready to process things. So yeah, it's really interesting with cold starts because as a developer building against Lambda when you're in your development lifecycle, you know you make a change, you publish it, you're going to see a cold start every single time you publish a new version of your function.
00:34:40
Speaker
And I know when I first started Lambda, using Lambda, I was like, ah, damn it. These code starts are killing me, man. Every single time I'm getting a code start. But actually, once you put your function under any kind of steady load, let's say you've got 10 requests a second and it's an API, you're going to have a consistent set of execution environments available pretty much all the time. So the amount of code starts you actually see is potentially relatively low.
00:35:08
Speaker
So I actually got some if I can remember the numbers right, but. There's a repository on GitHub where we do all our benchmarking for the different.net run times and the different ways of running.net. And for a conference talk I gave a few weeks ago actually we ran. And the benchmarks to kind of look at the percentage of warm starts versus cold starts. So the the load that the benchmarking is done. We run 100 requests a second for 10 minutes and the numbers we ended up with where there was
00:35:36
Speaker
These might be slightly wrong, so don't quote me on these, but there was roughly a hundred and fifty six thousand. Warm invokes. Okay. Okay. There's about 500 cold starts. Additionally, on top of that, sorry. So that's a total of 100. Let's say 150,500 invokes in total 500 of them were cold starts. So, you know, you put Lander under load.
00:35:59
Speaker
you're going to get less cold starts. It's kind of a really paradoxical way of thinking about. I think that when I was building APIs on service, it's like, no, don't put it under load, it'll break. Whereas Lambda's kind of a little bit of the opposite in some respects. So yeah, the thing the cold starts is that always, I always say to people and your customers, run some
00:36:22
Speaker
If you know the Lord, if you can like predict what you think the Lord might be like, run the function under load before you jump to the conclusion that cold starts are going to be a problem and cold starts might be a problem in some cases. So I've worked on a system in the past where. We needed double digit millisecond latency with incredibly spiky workloads like some weeks that be 10 requests. Some weeks there might be one request, some weeks to be 100 requests. Unless you're getting into some of the things like provision concurrency and we can talk about provision concurrency as well if you want to.
00:36:53
Speaker
unless you're getting into things like that, that's really difficult to do with Lambda. Because across any runtime, even the fastest runtimes, like Go and Rust, maybe not Rust, but Go, you're still talking of hundreds of milliseconds cold start. So there are scenarios where Lambda might not fit, and then you can start to look at other programming models.
00:37:16
Speaker
Well, maybe we can come back into another episode just on managing cold stars and things like that. Yeah, I think that could probably go for quite a while in and of itself. Yeah, I mean, if we relate this back to event of an architecture.
Alternatives to Lambda in Event-Driven Architectures
00:37:31
Speaker
That although Lambda is fundamentally event based compute, like Lambda's functions are triggered by an event of some kind. That doesn't necessarily mean you have to be using
00:37:43
Speaker
Lambda functions to be doing event driven architectures. So there's a really awesome. Blog I think on the compute blog that Emily share one of our colleagues were all about event driven architectures with. I think it was ECS. It might be Kubernetes, but one of the container orchestrators and how you can still use event bridge and SNS and all these really cool native integration native services on AWS, but actually using container based compute so.
00:38:10
Speaker
the two kind of get conflated sometimes that you have to be doing lambda to do event of an architecture when you're done. You can use a mix of both. It's just a tool in the toolkit like everything else. Okay, so you've got me convinced everything should be event driven architecture. Is that the case?
Limitations of Event-Driven Architecture
00:38:29
Speaker
Maybe it is an interesting question, you know, and I think what I've just said, then kind of, you know, event of an architecture, you know, it's a tool in the toolbox, right? Like everything doesn't have to be event driven or everything doesn't have to be service oriented and microservices. Like it's probably a mishmash of things that you end up with.
00:38:48
Speaker
I think some of the scenarios I can think of where you might not want to do event of an architecture. I guess that's kind of what you're trying to leave me to talk is something incredibly simple, like a stupidly simple feature for your new service for your business. Like adding all of this. Additional overhead, you know everything's asynchronous. You've got integrations to worry about. You might actually be better just building more modular monolith. For example, running in a container like if it's just stupidly simple, that might be a reason not to.
00:39:19
Speaker
Um, and then the latency and ordering sometimes can cause a problem. So when everything's asynchronous, you've got cues, you've got event buses, you've got message channels. Typically that's maybe going to add a more, more latency to your application as opposed to like the best case scenario with HTTP. Obviously HTTP has got all them fallacies of distributed computing to worry about. But if we think about best case scenario,
00:39:49
Speaker
You may well get slightly worse latency, but because you've got everything's asynchronous and you've got all these moving parts. And then ordering as well, because if you're using, you know, let's say publish, subscribe, and you're using EventBridge, so you're just publishing events into EventBridge. Well, EventBridge do can't guarantee ordering, so then. If you really have strict ordering guarantees in your system, that might potentially move your way for event of architectures,
00:40:20
Speaker
services like SQS and SNS have first in, first out ordering. So you might just have to, again, think about the integrations, think about the communication, think about the patterns that you want in your system. And then the final reason is around consistency. So we've got eventual consistency, we've got strong consistency.
00:40:42
Speaker
And I think I've got quite a good analogy for the two. So let's see how this goes. So if you're not familiar with strong consistency and eventual consistency, strong consistency would be like going into a shop or a supermarket, getting your shopping together, taking some money out your wallet or your purse, and paying for that shopping with cash, with actual cold hard cash. I know it's rare nowadays, but cold hard cash. And at the point you hand over that money,
00:41:10
Speaker
you can absolutely guarantee that you no longer have that money at that point in time. That transaction is strongly consistent because the money's gone. I look back in my wallet, it's gone, it's not coming back. Whereas if I was to pay for that shopping with my credit card and my debit card, at the point I make the transaction and the terminal says approved transaction complete, I could go and check my bank statement straight away that it wouldn't be there yet.
00:41:38
Speaker
So a payment of credit card is a theoretical guarantee that at some point in the future, that money is going to lead my account, right? And that is eventual consistency. At some point in the future, this thing's going to happen. So when you make things asynchronous, you start to move towards eventual consistency. Because if I publish an event, I'm hoping that some point in the future, like let's say it's an e-commerce system, I publish in order to confirm the event.
00:42:07
Speaker
At some point in the future, I'm kind of hoping that the delivery service is going to deliver that already, right? So that's something that you might need to think about. And you know, I've seen, I've spoke to customers in like financial services, for example, where you need to absolutely guarantee that this thing has happened at the point in which you need it to, you know, because they were talking money, we're talking finances. I once got myself in a really real pickle with a bit of an architecture actually.
00:42:32
Speaker
There was a service have system I worked on and a piece of functionality needed to send an email sounds simple and I was trying to do it in an asynchronous way. So this one service. Publishing event and then the email service was listening to that event and sending email. What I didn't consider is that the email service didn't communicate back to the original service that it had sent the emails fast enough, which meant that the original service sent another event.
00:43:00
Speaker
And another event and another event. And before you know it, I've got 100 emails set in my inbox. They're all the same. I'm like what is going on here? So I actually then refactored that to be HTTP to be synchronous request response. And you know this is coming back to the start of this question. You know this is where event given architecture is like a tool in the toolkit. It's not that everything must be event driven. Everything must be asynchronous or everything must be synchronous and request response. It's. Understand the.
00:43:29
Speaker
requirements of what you need and based on that pick the right tool for the right job. You might have an e-commerce system where everything's event driven apart from the payment processing because you want that to be synchronous, you want to know when someone makes a payment that it completes successfully at that moment in time. So it's just a tool. I don't know, I'd love the situation where somebody made multiple payments to me. That would be nice wouldn't it?
00:43:58
Speaker
So where can people meet up with you if they want to talk about serverless? So I've got a couple of speaker engagements coming up, very much UK based unfortunately, but I'm going to be speaking at the serverless, the inaugural serverless meetup in Manchester in the north of England, some time in April towards the end of April.
00:44:24
Speaker
And I'm also speaking at DevOps Days Europe on May 23rd, which is about serverless integration patterns, actually. So if any of this has piqued your interest, then go and check out that. Talk to the expert. Cool. And so my final question, where can people get in touch with you? I know you do a lot of different things.
00:44:53
Speaker
Yeah, so if anybody's interested in any of this stuff, then please feel free to reach out anytime. I'd love to talk about it. I'm mostly active on Twitter. So on Twitter, my handle is at plantpoweredjames.
00:45:06
Speaker
That is because I'm vegan and I run ultra marathons, so hence the plant power. I'm pretty active on LinkedIn as well. That's another good segue and YouTube. So I do quite a lot of things on YouTube. Shameless plug shoved in right at the end here. Hopefully people have listened this far. You should really do this at the start of podcast episodes, shouldn't you? Get everyone to put all their handles at the start. So yeah, I'm at Serverless James on YouTube. I'm sure we can put some of them links in the show notes, Tom.
00:45:33
Speaker
But yeah, we can go anytime, whether it's .NET, whether it's serverless, whether it's a vendor of an architecture, always up for the chat. Great. Well, James, it's been an absolute pleasure. Likewise. If anybody can tell by the amount of laughs we've had during this conversation. Hopefully, you'll come back and be on the podcast again and find another topic of interest. Yeah, definitely. I'd love to. Thanks for having me, Tom. Thank you very much.
00:46:03
Speaker
Thanks for listening to this episode of the Basement Programmer Podcast. I really appreciate you tuning in, and if you have any feedback or comments, of course, send me an email. Also, please consider subscribing. It lets me know that you're enjoying this production. I'm looking forward to you joining me for the next episode of the Basement Programmer Podcast. In the meantime, take care, stay safe, and keep learning.