← AWS Podcast
AWS Podcast
#692: A Discussion About Serverless and How to Make the Most of It
00:35:28
Simon is joined by Stephen Liedig to discuss the evolution of serverless technology and its impact o
Loading summary
Transcript88 lines
- [00:00]
Steve Ladig
This is episode 692 of the AWS podcast, released on October 28, 2024.
- [00:09]
Simon Lesher
Hello, everyone, and welcome back to the AWS Podcast. Simon Lesher here with you. Great to have you back. I'm joined by a special guest and an old colleague. Not old in himself, but like we've known each other for a while, Steve Ladig, who is a specialist solution architect in the serverless space. Welcome to the podcast, Steve. How you doing?
- [00:24]
Steve Ladig
I'm very well, Simon, thank you. And thank you for having me.
- [00:26]
Simon Lesher
Yeah, it's good to have you here. Now, Steve is located in the earth's most remote capital city in the earth's most remote country, that is Perth, Western Australia, which is a beautiful place, but far away from everything.
- [00:37]
Steve Ladig
It is, it is. And I quite like it like that.
- [00:41]
Simon Lesher
Let's keep it that way. Now, Steve, you've had a really interesting journey in terms of your overall career and also your expertise in the serverless space. And so before we get into sort of some of the nitty gritty of serverless and how to take advantage of it, help us understand where you came from in terms of your mental model and how it should shifted with this new technology.
- [01:01]
Steve Ladig
Yeah, good. It's a bit of a long story, but I think it probably started when I first started working with aws, even before I joined, some eight and a half years ago. And I really just fell in love with what the cloud could offer and what AWS could offer in terms of, you know, just being able to deliver software quicker and being able to automate a lot of the things. I remember way back then I was working for a consulting company and we. I was part of an innovation team that sort of like led the charge on some of the cloud computing initiatives for the organization. And it was amazing how much work we could actually, you know, get done. And I mean, it sounds simple, but like things like taking, you know, a piece of software, no matter how large, and something that ordinarily took two weeks to deploy, all of a sudden took 45 seconds. Yeah, and that was quite mind blowing. And I was really fascinated by how I could effectively architect everything through software. And then Lambda came along and that blew my mind.
- [02:00]
Simon Lesher
It blew your mind. And then the end. What you're talking about here is that fundamental thing of as a creative software developer, wanting to move quickly. Like you've got this idea, you've got this vision, you sort of know where you want to go and you want to get there quickly. And waiting three weeks for a firewall port to be Opened is not compatible with that mentality.
- [02:20]
Steve Ladig
Yeah, exactly. What I think it actually brought teams closer together because we were collaborating more closely with the infrastructure people to sort of get their feedback, get their input, and we were able to easily define all of their stuff through services like cloudformation and get some automation happening, which is a really key part of what cloud's all about, fundamentally. And when Lambda came on board, all of a sudden I didn't need to worry about managing my own servers and the runtimes that, you know, we had to make sure that we're configured on there and things sped up even more. And then I joined aws and it's like a kid in the candy store, really. And I really dived into the technology and I was very passionate about, you know, educating my coworkers, our customers, diving deep into the technology and it was just a really exciting space to be in.
- [03:13]
Simon Lesher
Well, I guess the nice thing too is you're at that amazing interface, if you like, between our customers, the developer experience and the service teams who build these services within aws. So you get to talk to the folks who make this stuff and you get to give them the feedback of, well, you know, there's an edge here or there's better ergonomics there or why can't this happen this way, et cetera. So I'm sure that's been kind of an interesting journey. If we think back to 2014, I mean, Lambda came out, it was like, oh wow, I can run some code. I think there's only two or three languages we supported at the time. And let's not underestimate the fact that I don't have to install an operating system, patch an operating system, do any o that stuff, and you can't hack my server because it doesn't exist unless the function is running. There was a lot of initial benefits, but we've come a long way. So maybe help us understand how that mentality of just sort of functioned as a service has really moved into more of a serverless mindset.
- [04:06]
Steve Ladig
Yeah, definitely. I think it's actually quite mind blowing how much innovation has happened over the last 10 years since Lambda was released. I mean, I think we launched with Typescript as a managed runtime, but then moved very quickly into supporting other runtimes like Python and C and Java. And then we just continue to iterate on what we were hearing from customers and providing more functionality around Dynamo and DynamoDB, streaming support and VPC integration, which was a big one because it really sort of opened up the doors for customers. To sort of run sort of internal private workloads. Along with that came frameworks, serverless frameworks like aws, Sam, shifting traffic with aliases, reserve concurrency layers. And along the way there were a few hiccups, particularly around some sort of the cold starts that we were seeing customers experience. And that even drove further innovation through, you know, the changes that we made to things like VPC integration through Hyperplane, enis and all of those things that effectively solved some of those challenging integration.
- [05:14]
Simon Lesher
Well, dramatically reduced. Yeah, yeah, exactly. Those startup times and cold starts and then things like Snapstart for Java help that stuff as well. This is this feedback loop. You know, we try and release things for customers that are really useful but then, you know, the ears are open saying, well, tell us what you need. So it's like, I think early on, like, was it three minutes was the maximum time a task could run and now it's 15 minutes or, you know, the amount of memory and you know, these things start to evolve and they open up new opportunities of what we can build.
- [05:41]
Steve Ladig
Absolutely. With the, with the introduction of services like API, Gateway and STEP functions, we really started to open up the experiences and all of the different types of workloads that could be built in a serverless way. And today there's a huge amount of application space that we're seeing customers adopt. Everything from, you know, web to mobile to IT automation, data processing.
- [06:05]
Simon Lesher
The Australian census, the last Australian census was completely serverless. I remain intensely proud of the ABS for that.
- [06:13]
Steve Ladig
You should be. I was actually involved in that project. That was a proud moment of mine as well. It was great to see public sector customers, you know, adopting serverless in such a way. And today, like, I mean, it was such a great application, it's such a great use case really for serverless. Listen, we saw a lot of those types of examples, you know, pop up in Covid as well. I remember, you know, during the, you know, the early phases of COVID you know, we had customers from all over, like public sector customers from India, from Malaysia.
- [06:42]
Simon Lesher
Yeah.
- [06:42]
Steve Ladig
Spinning up applications that, you know, dealt with COVID vaccination bookings and other services that require just a huge amount of scale, but didn't necessarily, it didn't necessitate a large amount of capital investment and they were able to, you know, build and provide services to their communities and then tear all that stuff down when they didn't need it anymore. So.
- [07:03]
Simon Lesher
Yeah, yeah. So let's help our listeners then kind of figure out the way that they should think about designing applications in this sort of new modality. Because if we get, if we throw it back and we'll do a bit of back and forward because I think this helps us to sort of figure out how we need to think about our changes. Like when I first started using serverless myself it was, you know, I get a lambda, then within the lambda I might call an SNS or an SQS endpoint that then triggers another lambda. And that was kind of how I would cobble things together, which was great when that was new. But that's not the way we do it anymore, is there? Tell us more about sort of, I guess, that concept of a state machine, the event driven architecture and just the mentality you use as a software designer in picturing in your head the boxes, if you know what I mean.
- [07:47]
Steve Ladig
Yeah, okay, well that's a pretty big question, so let's.
- [07:50]
Simon Lesher
Yeah, you know, just if you can answer that in five minutes, that'd be awesome.
- [07:53]
Steve Ladig
Yeah, fantastic elevator pitch for serverless application development. Look, I think one of the first things that there's a bit of a cognitive shift I think when we're, when you're starting to explore and adopt serverless architecture one good way. I heard someone explain it, you know, in a, in a very sort of interesting way the other day. So looking at, you know, what are the fundamental differences between serverless application development and traditional based servers? And fundamentally like, if you think about servers in the context of like they of an architecture, there's. There's a simple arrangement of complex services and a lot of the application functionalities typically deployed into an EC2 instance or a container and that's where a lot of the complexity lies. But the actual architecture itself is fairly sort of, you know, standard. We have load balances, we have application servers, hopefully they're highly available and auto.
- [08:47]
Simon Lesher
Scaling groups, RDs, all that good stuff.
- [08:49]
Steve Ladig
Yeah, yeah, exactly. And there's a lot of work that goes into that and you know, having to deal with managing, you know, the underlying infrastructure and all of the scaling capabilities that an application might have. And then you know, with serverless it's a bit of a different story. It's like you've basically got a lot of sort of simple services that do specific things, but they're more that the comp. The arrangement is a little bit more complex.
- [09:13]
Simon Lesher
Right, well, it's visible, isn't it? It's like you can see it, if I can put it that way, quote unquote, see it rather than it's a big box with EC2 written on it. It's a whole Bunch of boxes with little business functionalities written on them.
- [09:26]
Steve Ladig
One of the things early on that I really appreciated about services like Lambda was now we have per millisecond execution pricing. That in itself. Like as a developer you can actually see the effect that, you know, your code has on the total cost of ownership of an application.
- [09:45]
Simon Lesher
The optimization, yeah, it's totally true. It doesn't fall into the big bucket of, well, you've got a honking great server that's costing us a fortune. And yeah, you've used a new library, you've changed your compression and you've got me a 30% saving in CPU and it's still running on the same Hong Kong grade server that we were using before.
- [09:59]
Steve Ladig
Yeah, exactly. You know, we've gone from where we distributed some of the complexity to integration and how things are put together. And that's really a great story for services like Step Functions because they do help us orchestrate and match, manage the statefulness our applications require using services that are functional, that are, that are ultimately stateless. So, you know, they help us, you know, sort of break down and expose some of the orchestration needs that our applications have by providing us a visual means by building workflows and business processes and taking a lot of the sort of like responsibility around programming constructs that you might need in an application, such as being able to detect errors and having retry capabilities, abilities with exponential back off those kinds of things at letter.
- [10:53]
Simon Lesher
Cues, that sort of stuff.
- [10:54]
Steve Ladig
Exactly. Yeah, exactly. And so being able to model that visually is, you know, a great way for developers to be able to, you know, communicate with the business, sit down with even business owners who can participate in that process of how do I model a particular process?
- [11:09]
Simon Lesher
One of the fun things just on there about Step Functions I like is that it has a function type where it calls out to the world as in the physical world. And you can have, I think the timeout's like a year or something. Like it's a really long, like you can have it integrate into a physical process if you need to, which is kind of funky.
- [11:26]
Steve Ladig
Yeah, 100%. So with things like callback patterns that are supported with task tokens, you can literally run a process or a particular execution of a process for anywhere up to a year without necessarily having to worry about providing the persistence mechanisms that are required to support that kind of feature. So we've got quite a few customers that are actually running workloads or running stateful processes for many, many months. It's not just for that. I think I Look at Step Functions as a way of just dealing with any kind of statement. If you're looking at integrating with external services, it's a great way to deal with some of the unknowns that may affect those external systems as well.
- [12:11]
Simon Lesher
Is it there, is it not there? Did it behave the way I thought it would behave?
- [12:13]
Steve Ladig
Exactly. Is it up, is it down?
- [12:15]
Simon Lesher
All that good stuff.
- [12:16]
Steve Ladig
Exactly. And with that you can model failure modes and you know, what does what happens and be more explicit about what failure looks like and the path that you might want to take, which is not necessarily always a technical consideration. We need to look at, you know, what are the business needs when something fails. And this is, you know, a great opportunity for you to be able to model that through services like Step Functions.
- [12:39]
Simon Lesher
And do you recommend that developers go with a drag and drop type approach or to use more the DSL type approach like, because as with most tools, there's many ways you can do it. What do you find typically is the easier path for folks to use or is there even an easier path?
- [12:56]
Steve Ladig
Look, I really like the new features that step from Sport out a year or two ago. We have a workflow studio in the console and what I like about this new functionality that they've recently released that allows you to map the state machine definition so as you're to a file on your local hard drive. So as a developer, if you need to quickly spin up and potentially just build something really quickly, you can literally use the console as a means for the canvas in there to visually build and drag and drop dates for your application and then have that file be ready for deployment through some kind of automated process or framework.
- [13:35]
Simon Lesher
Cool. That's nice. That's handy.
- [13:36]
Steve Ladig
It is nice. It is nice. And like it's amazing really what Step Functions has done over the last couple of years in that you can now literally invoke up to 9,000 plus SDK calls. So we're not just dealing with specific resources, but you now have the ability to invoke literally every SDK. That's a really powerful mechanism and just takes away some of the heavy lifting that, you know, application developers would otherwise need to implement themselves through SDKs and writing code and you know, take a little bit more of a, you know, I guess a code less type of an approach to building.
- [14:12]
Simon Lesher
So if we think about that approach then if we've got sort of the state machine is our kind of architecture diagram slash skeleton of what we're building. We've got Lambda obviously for anything compute related. What am I doing from A storage perspective, what am I doing from a network perspective? What are the things I should be looking at there?
- [14:31]
Steve Ladig
So from a storage perspective, we have some of our oldest serverless services such as S3. Lots of people are using and integrating their applications using S3. DynamoDB is very big in building serverless solutions obviously and there's some key benefits to adopting DynamoDB. 1 obviously it's schemaless so you can quickly iterate on, you know, what your application needs are without necessarily worrying about, you know, relationships between tables and specifying a schema and bring that back to potentially some kind of ORM that you might be using. So there's some huge benefits around that other than, you know, that it's a really highly scalable services which we saw what we've seen in many cases and.
- [15:13]
Simon Lesher
You know, prime day, you know, goes, goes hard and goes. Exactly, exactly.
- [15:19]
Steve Ladig
So there's lots of different options. It really all depends on what the needs of your application are.
- [15:25]
Simon Lesher
Does relational have a place still? Like where does relational fit? Can you plug it into that ecosystem?
- [15:30]
Steve Ladig
Oh absolutely, 100%. So obviously having our relational database services typically are VPC dependent, right? They're network dependent obviously with integration, VPC integration and Lambda support, there's a great way to provide that support for those data sources. So we got lots of customers using relational databases early on. What a lot of people had challenges with is that lambda actually scaled much faster than the databases were able to keep up. And so that was another sort of like innovation that came out of that need is things like Aurora Serverless but There's a called RDS proxy1 RDS proxy, well done. Yes, thank you. So RDS proxy sort of came out of that and that's really helped us manage so the connection pools with databases at scale. So there's definitely a place for relational.
- [16:24]
Simon Lesher
Well and I guess it's also starting to sort of blend, isn't it? Because as I mentioned you've got Aurora classically built and then you got Aurora serverless, which is literally serverless. Like I don't have to size it or anything like that so it matches in with that scale of what I'm trying to do. Also super useful for dev test as well, I find like just 100% don't.
- [16:44]
Steve Ladig
To waste anything if you don't know ahead of time, you know, what your scale requirements are. These server solutions make perfect sense. So quite often as we're building and innovating on new products and features for customers, those things may not necessarily be known. There's trade offs obviously you need to make along the way. But they're a great service and great feature if you minimize the opportunity operational overhead of the services that you want to manage.
- [17:11]
Simon Lesher
I can store my data in object form, I can store it in relational form, I can store it in key value pair. I've got local storage on board the Lambda as well if I need to, so I can use temp if I want to. But what about from an accessibility perspective, a network perspective? Again, if we think about our older style three tier architecture, I've got my load balancer up the top. It's going to be ALB or NLB depending on what I'm doing. That's my entry point in the serverless world. Is it API Gateway? Is it something else? Is it? It depends. How do we think about that?
- [17:43]
Steve Ladig
Typically it'll be API Gateway, but we've got many customers using Application Load Balancer to route traffic to Lambda functions as well. Okay, obviously there's some trade offs in those capabilities, but typically we will see some kind of an API gateway in front of your lambda functions or other services for that matter as well. One of the great things that's probably little known is that API Gateway has service integration so you can provide an endpoint or resource that interfaces directly with other services and that actually opens you up to some really interesting design patterns and application of design patterns around asynchronous processing of requests, for example. So you could be exposing a resource that integrates directly with an SQS queue and that could be the starting point for that asynchronous process to execute. Similarly, we're seeing other applications through things like, like people managing or exposing webhooks and directly integrating that with EventBridge and other services. There's a fairly large application space that services like API Gateway supports. But also there's some benefit in using services like Application Load Balancer because they are technologies that people are familiar with and have access to and they may need to support multiple different types of workloads. So they may need to support, you know, workloads that potentially are being self managed in inside of vpc. But you know, they want to expose certain capability through services like AWS Lambda. The world's your oyster, so to speak. You can really pick and choose.
- [19:22]
Simon Lesher
You can pick and choose how you do it. Yeah.
- [19:24]
Steve Ladig
How you want to do it. Yeah.
- [19:26]
Simon Lesher
What about from an observability perspective? If you think about observability? You know, we talked about the fact that we're kind of deconstructing this EC2 block into multiple different things, and there's things moving through the state and different stages. And how do I keep track of everything? How do I know what's working, what's not, what's taking a long time, what's not, and how do I do it without a whole bunch of extra work?
- [19:49]
Steve Ladig
One of the cognitive shifts, I think that, you know, that I mentioned earlier, is that you're observing the movement of information across lots of integrated services. We've made a lot of inroads in terms of what we. The services that we provide customers to help manage that. I think X Ray was one of those services that came out early on to help us understand the flow of, of messages and events as they flow through our services and really help us understand the behavior and the performance of certain parts of our application. And today it's still very relevant service in terms of helping us troubleshoot maybe some of the more intricate parts of our application, whether that be integration with other services and helping us identify errors and bottlenecks. And it does so in a very visual manner. You can actually see where you may be having problems.
- [20:41]
Simon Lesher
Well, it gives you those little pie graphs, doesn't it, for each function where it's like, here's the green circle. If there's a bit of red on there, probably should take a look at that. There's something going on here.
- [20:50]
Steve Ladig
Exactly. And then you get performance metrics around average execution time for the sampling rates that have occurred across your application. The thing that I probably would step back and look at and point out that with serverless applications, because you're not worrying about the nuts and bolts of the infrastructure that's supporting your application, you've got an opportunity to focus, to really focus on things like the customer experience metrics. How are your customers engaging with your application and what are the sort of the business level metrics that you can start to surface. For example, you know, how many orders did I just sell in the last 24 hours? Those are really interesting parts of serverless observability. I think that has opened up the doors to exposing new visibility into what applications people are building and the benefits that those applications. Applications are bringing the businesses that are running them.
- [21:44]
Simon Lesher
Well, it's an interesting metric you share there too because often, particularly in retail, it's quite cyclical and people understand, relatively speaking, how many orders at which time of the day they get. Or it could be how many logins I get a particular time for my business, what have you. And so having a method where you're measuring not just what you're Having, but comparing that to what's normal and then alarming based on that is often the first time someone knows something's gone wrong. Oh, orders have dropped off. What's going on? Either. Either what we're selling sucks or something's gone wrong on the back end. Now, both of these could be true at the same time, but at least you know, you got to look at something.
- [22:20]
Steve Ladig
Yeah, exactly. And it's not just about tracing. I think, you know, logging plays still a very significant part in that observability story. And also having those business level metrics service up as custom metrics. So being able to model those important parts of your business as metrics is really, you know, kind of like another sort of like, I guess, things developers need to get their head around. Now, a few years ago we released what we call the serverless lens as part of the well architected framework.
- [22:48]
Simon Lesher
Yes.
- [22:49]
Steve Ladig
And remember back then, Simon, there was a lot of interest in well architected program and still today is a very useful tool to help people understand business process technology and understand how that manifests in their organizational processes and all the rest of that. And one of the challenges that we had with the well architected program, I guess, was that it wasn't really specifically focusing on a particular type of workload. And so we launched the serverless lens, which provided a lot of best practice guidance around the five pillars that the well architected framework defined. And we had a lot of good advice around to how to operationalize serverless applications and introducing things like structured logging and custom metrics and how to use tracing effectively and making sure that these are all elements of your application that you monitor. One of the things that we found with the lens was that many customers were actually trying to solve these problems on their own. And it's kind of seemed like a good opportunity to do something about that.
- [24:02]
Simon Lesher
Here's something I could fix.
- [24:05]
Steve Ladig
Exactly. HLSA and a few others who were involved in the development of the lens went, you know what, why don't we create a library that actually encapsulates all of these best practices and make that library available to customers so they don't have to reinvent the wheel. And as a result, we ended up with Power Tools for Lambda for aws. Lambda, wow. Which is now generally known as Power Tools for aws. And this is now a suite of utilities that is supported across Python, Java, TypeScript and. NET, and provides libraries that implement the best practice guidance for some of those core operational concerns that we defined in the serverless lens. And one of the Things that came out of that is that obviously there are other things that are really important parts of understanding or problems that we could have solved repeatedly for customers. So they didn't have to reinvent the wheel, such as of providing utilities for batching, for example. Right. So having a single library that would allow or poll messages from SQS or.
- [25:15]
Simon Lesher
Kinesis and do it really, really well.
- [25:18]
Steve Ladig
And doing it in a highly optimized way and providing additional features that just weren't part of the SDK and solving some of those technical challenges like idempotency and which is, you know, when you're building distributed applications are relevant parts of the things that you need to manage.
- [25:33]
Simon Lesher
Well, particularly in a stateless environment. You've got to think about these things that. Yeah, exactly. You shouldn't have to. Without that.
- [25:38]
Steve Ladig
Yeah, no, exactly. I mean, as Werner Vogels always says, you know, everything goes wrong all the time and we need to be prepared for that. Can't just plan for the golden path all the time. So that's almost like I would say it's a must have if you're developing serverless applications today because it just grab the power tools. Grab the power tools and it just saves you accelerates your development activities.
- [26:01]
Simon Lesher
We're talking about development activity and experience and the approach. As with most things in it, there are many ways you can do this. I mean I will admit this is a safe space. I'll admit that I have coded Lambda in the console directly, fiendishly only using libraries available in the native console so that I could get something done quickly. That's how lazy I can be. I have used Chalice, which is a really interesting library set for Python and serverless. And I use that in fact that if you're listening to this podcast, it has been processed through serverless technology deployed by Chalice. That's what I use to build this platform. And recently I've become a big fan of SAM because the serverless application model has made bundling of dependencies and stuff like so easy. Why would I do it any other way? But tell us what you as the doctor doctor Serverless recommends. How do you like, what do you like to reach for? Or maybe a couple of choices of what folks should look at. Obviously they're going to use power tools. If you're listening to this podcast now, you know you've got to use power tools. But from a developer ergonomics perspective, what frameworks approaches do you take to make that dev test run, iterate, deploy cycle easy and good in this environment?
- [27:12]
Steve Ladig
Yeah, that's A good question. I think a lot of the serverless application model has been around for a couple of years now and I think it's important to recognize what problems we were trying to solve with that. And one of the things that I really love about the serverless application model is the fact that it just simplifies a lot of those common integration patterns that you would typically apply to a serverless application. In recent times we've obviously launched other infrastructure as code tools such as cdk, which has grown immensely in popularity. And I think it's one of the things that I think we still. There's a little bit of confusion in the market in the sense like what are these things and how do they compare? Serverless application model is effectively an extension to cloudformation.
- [27:55]
Simon Lesher
Well, it generates cloudformation.
- [27:57]
Steve Ladig
It generates cloudformation. That's right. The main difference, I guess, is that you can't really consider SAM a general purpose infrastructure as code tool. Right. Framework. If you want to compare CDK with anything, you probably ought to be comparing it with cloudformation. Right. SAM is a very powerful framework to help you just apply and accelerate some of the serverless development activities that you would typically do and help support the integrations that you need, like, you know, integrating API gate with a lambda function or.
- [28:26]
Simon Lesher
Yeah, yeah. Or setting up all my IMs for me when you're creating those relationships or you know, writing code locally and deploying it in the cloud and then anytime I make a change in my local environment, hot fixes in the cloud type like. Absolutely. That sort of stuff. That's cycle time stuff.
- [28:42]
Steve Ladig
Yeah, absolutely. So there's lots of other options available in the market today. So you've got serverless framework pulumi. The name escapes me now, but there's a few, there's definitely a few others. There's plenty out there, there's plenty others. All taking very slightly different approaches to solving the problems of managing complex infrastructure. And I think that's probably, you know, one of the things that I guess we've done, what we've always done in software is, you know, whenever there's any kind of complexity, we'll add another layer of abstraction. And so what could go wrong? What could go wrong? Exactly. There are definitely some really powerful tools out there that I really like and that are helping customers adopt serverless and cloud computing in general. I think it's just important to realize also that, you know, with all of these things you have to. There's a trade off to make. Right, sure. I mean, sure. It all depends on how far away from the actual metal you get, so to speak, with adopting something that has, you know, a high degree of abstraction also comes with its own level of complexities and the dependencies that they have. So there's. There's also potentially, you know, different types of support models, some you have to pay for. Once you reach certain level of scale, then, you know, you end up, you know, having to pay for those frameworks too. So.
- [29:56]
Simon Lesher
So really you're looking for something that's kind of sympathetic to the task at hand and the strategy you have overall. So it's the thing that matches almost philosophically what you're trying to get done.
- [30:06]
Steve Ladig
Exactly, exactly. So, I mean, we have a lot of customers building a terraform and now open tofu. Exactly. So look, there's a lot of interesting stuff out there, and for me, it's not so much important about what you use, it's how you use it. So one of the things that I'm quite mindful of is when we're, you know, when I'm advising customers around how to build serverless architectures is really looking at, you know, where are the fund fundamental boundaries of your domain or your subdomain or the applications or the components that you're building and making sure that logical architecture is reflected in your physical representation of that. You know, after going through a lot of definitions of what serverless is. And to me, ultimately, it's fundamentally about understanding that serverless is about building solutions. Right. To address a specific problem. Most of the time, when I'm talking to customers about, you know, solving their business problems, I'm not talking to them about platform, I'm not talking to them about, you know, their, their infrastructure needs. I'm talking to them about, you know, building a solution that's largely based on serverless or cloud native services, and the representation that or the understanding that those services are really an extension of the application architecture and the architectural patterns that support that solution. So, you know, we have queues, we have event buses, you know, all of these things put together kind of manifest themselves in something that represents the behavior that drives a business outcome. And so when we're thinking about infrastructure in this context, I like to make sure that, you know, irrespective of whether using Terraform or CDK or whatever it is that you're using, is that you hold true to the idea of the service autonomy and that you've got your boundaries at an infrastructure aligned to the logical boundaries of your application.
- [32:05]
Simon Lesher
And it makes you understand the business workflow as well. Like if you're modeling that workflow effectively, then your architecture should pretty much match that. Which also means if people change that, you can change it easily rather than having to reimagine it.
- [32:20]
Steve Ladig
Exactly. There's obviously challenges with that because we like to reuse things a lot and we already have a lot to deal with in terms of managing application level dependencies. And so one of the things I'm quite conscious of is, you know, introducing too many infrastructure level dependencies as well, because they, they will have an impact and on your deployment models and potentially how you operationally, you know, maintain those applications. And so while I see a lot of benefit in reuse in certain parts, we need to make sure that the autonomy and we don't have too much cross functional dependencies at an infrastructure level not dissimilar to what we're trying to achieve with software.
- [33:01]
Simon Lesher
Right, exactly, exactly.
- [33:03]
Steve Ladig
We want our applications to be highly cohesive, you know, we want them to be loosely coupled.
- [33:08]
Simon Lesher
Yep. Resilient, able to scale independently. All those, all those good.
- [33:13]
Steve Ladig
All of those other things.
- [33:15]
Simon Lesher
This has been really interesting and I have to say in this day and age, I reach for serverless first as my first cut of a solution. I'll share with listeners why that is first, firstly, I think it gives you the best chance for time to value. So you know, the business wants to see something. Let me show you. And I can do it pretty quick. It makes it much more secure. Doesn't mean you don't think about security. You always think about security. But I'm yet to see someone who can hack a server that doesn't exist. That's always a great thing. It also means that I'm not managing that whole environment. That's a huge overhead. Like I've done that job. It's not a great job, it's a hard job. And you only ever get into trouble if you do it wrong. No one ever says, well done, you patched that server today, son. Good job. And I think then the other part is the, there is an immense opportunity to optimize the absolute bejesus out of everything in that flow. Because you can make decisions at the code level, you can make decisions at the interaction level, you can make decisions at the batching level, you can run analytics and as you said earlier, you can dial really, really finely. Now that doesn't mean you don't design things using the server style, the three tier. Like again, it's horses for courses, it's use what makes sense. But I just find that it's nice to at least as a mental model. Apply first cut of serverless and see does this make sense? And sometimes it does and sometimes it doesn't and that's okay.
- [34:29]
Steve Ladig
It is 100% okay. And I think one of the things that we felt like when we're talking about serverless first people need to understand we're not talking about serverless only. We've got many, many customers building different types of applications, merging serverless with non serverless applications.
- [34:46]
Simon Lesher
Be pragmatic.
- [34:48]
Steve Ladig
Exactly. Just be pragmatic and do what works and some of the trade offs that you're making in your architecture and hold true to the needs of the business and the, you know, the architectural, you know, principles and design patterns that you want us to be able to support.
- [35:03]
Simon Lesher
And if you're. And the final thing is of course Steve, if you're using serverless on AWS, use power tools for AWS. Correct.
- [35:09]
Steve Ladig
100%.
- [35:12]
Simon Lesher
Steve, thanks so much for coming on the show and telling us all about it.
- [35:15]
Steve Ladig
It's been my pleasure Simon, thank you very much.
- [35:17]
Simon Lesher
Simon much thank you and thanks everyone for listening. We do love to get your feedback. Adibuspodcast. Amazon.com is the place to do it and until next time, keep on building.