AWS Lambda & Containers: Choosing Compute for Your Application - AWS Online Tech Talks

Key Takeaways

i'm excited to be here with everyone um thank you for joining i'm emily freeman i think about all things devops at aws and i'm joined by benjot and hickey uh do you want to introduce yourselves sure i'm benjamin i lead the containers and serverless go to market team here at aws hi and i'm haydee park i'm a principal of solutions architect focusing on serverless fantastic so yeah we have uh containers representation serverless representation um so i'm really excited to have this this conversation and really just discuss the the pros and cons of both and how they kind of create a venn diagram i think sometimes people are really uh interested in kind of discussing well containers versus serverless and i've never seen it like that do you all agree or what what are your thoughts on that yeah for sure when i work with customers and i tend to work with some of the larger customers thinking about cloud native applications um and quite commonly you're going to see both of those it's not like you're saying it's not an either or it's really more of an and so for sure that's i see that a lot with our customers yeah likewise usually usually it's customers starting on the journey uh when they're first kind of modernizing that first app and they're trying to figure out should i go serverless should i go containers should i try lambda should i go to fargate should i try eks and that's when they that's when they first ask about the containers or serverless but i think quickly they get to the point of like you've got to use both there there's there's capabilities in both that are useful it depends on the workload it depends on you know who's running the project and where that workload is going to end up so talk to me about that like how how do you advise the customers you work with on what to choose and win you know what are the differences between the workloads and where you should be running them yeah i think there's there's some really good patterns we've seen for where serverless really really takes hold and can provide the better best total cost of ownership but i would actually start even further before the technical decision i think there's a bunch of conversations that you need to have about whether you're actually driving your modernization initiatives based on a desire to reduce your operational load or whether it's really about developer agility or whether it's driven by security or whether it's some combination of the three and usually it's it's some combination but then i think a key part of that question is who's gonna who's gonna actually staff the resources for this application or that application and where does that application end up in production are are is it gonna be run by a development team or is it gonna be run primarily by an operations team who's trying to just standardize as much as they can across the application portfolio okay that makes sense yeah i want to plus one the the people side of things you know oftentimes people come with lots of different backgrounds and experiences you know i'll have some customers who these are developers or architects that have been doing this for 20 years and they say i know how to do this and they have a very particular opinionated approach to building applications and so sometimes you may have to lean in one direction or the other whereas you may have others who are a little bit more maybe leaning forward and want to think about fresh and new ideas and so a lot of those tendencies and leadings will allow you to make choices between one or the other now certainly you can get really into the weeds and find technical nuances of why one will work versus one's work but we don't need to necessarily dive into those at this point yeah no i think that's such a good point because so much of any technical decision relies on the team that's available and the team that will be working on something um and the resources that a company can put into it you know even language choice is so much dependent on what languages the team already knows uh and i feel like this fits that as well it's a there's a comfort level aspect to these decisions that makes sense yeah it's an interesting point you bring up about language choice i mean containers and serverless are to some degree different kinds of languages you can speak right containers really speaks to i think operators who want to find ways to you know as quickly as they can re-platform an application and maybe the investment isn't necessary to go rewrite that application at you know any any near term well i think serverless really speaks to the developer side of the equation it's really about how fast can you go and how quickly can you prototype and get that app into production and scale up and scale scale down i mean those are such huge benefits for a both the development team and an operations team but i think the the technologies are almost like different languages depending on you know who's who's uh you know who's starting the conversation absolutely so i oh sorry did i interrupt no i i think a lot of times when we're talking about containers and serverless we we put it under the umbrella of a modern application or modern ops um what do you all define modern apps as you know this this modern application what does it mean yeah maybe i'll take a first ad and then i can let android add to that you know i think for me the idea is we're trying to use um kind of cloud-native tooling as much as possible so you know here at uws we often talk about reducing the amount of work we do on undifferentiated heavy lifting and so again for me i tend to work with a lot of application architects and developers and the idea being give me the business requirements what what is it that we as a business need to go and deliver and let's go build an application to do that and focus on building the application components writing the code that delivers as directly as possible that business value versus you know we're going to build a platform and certainly platforms are incredibly important for large enterprises but again as we think about modern applications we want to push more and more towards leveraging native services managed services so that we can focus our architect and developer time on building those customer delivery value yeah i would i love that description i i think the the more you can leverage the cloud native capabilities the less you're going to have to worry about and i think for your your modern app for you know whether whether that app is written in in java or whether it's python or whether it's you know you know the next latest language it's i think it's important to figure out how much of that operational burden can you outsource how much of it can you give away and and make sure you actually spend time on the on the things that matter yeah yeah i i think that's a an excellent point and it's something i think about a lot with devops and just operations in general and moving to the cloud you know operations has changed it's still um the the skills can transfer but but it's different and and learning to um operate at scale and in the cloud with these new cloud-native applications it's a different sort of approach to it um how do you all think that containers and servos fit in how do you abstract uh you know these operational concerns without without sort of obfuscating concerns or hiding alerts you know making sure that there's still visibility into the system yeah i think one of the things that we've seen customers do uh very quickly as they start to build out their next application is thinking about observability up front thinking about security up front building that in as as opposed to doing it as a side project or an after effect of deploying the application in production and realizing oh wait did we actually you know collect the logs out of this app or did we actually put traces in so we can actually figure out you know uh what function calls are running slow like those things you know typically happen after the fact one of the interesting things i've seen is customers as they start to go down the the journey of hey how how am i going to build my next application start thinking about all these things up front so the operational concerns actually become not after effects but really uh part of the application architecture and then you know the you know it takes a little bit more effort up front but uh the benefits pay off dividends huge in the end yeah it's part of the architecture decisions in the beginning absolutely i like that yeah and if i'll plus one that and if i could add anything to that it would be that it becomes as kind of this virtuous cycle right because the architects and the developers are building the security aspects the observability aspects into the application upfront it influences the direction of the application itself right because they're performance sensitive or they're cost sensitive or they're security sensitive they start to build um their applications in what we would call well-architected manners right so they use these well-architected concepts concepts ensure that they're building cloud-native applications in a way that really abides by best practices across the different pillars that we would want to kind of analyze and evaluate our applications i think that's such a brilliant point because so many companies really struggle i think on deciding what the priority is are we most concerned about performance are we most concerned about cost and really kind of stating that up front is very powerful but it's very difficult you know you have to choose yeah and i think emily like you focus a lot in devops and the great thing is that we can automate a lot of these considerations and capabilities like we're doing security scanning or even doing performance load testing all of these things we can kind of automate so that maybe up front there's a heavy lift to build some of the tool chains or maybe the enterprise is providing them or we're providing feedback into the enterprise tool chains but at a certain point you know maybe it's like one of those call walk run scenarios where initially there's a lot of upfront kind of human effort that we need to put into it but over time as the tools mature and as our application matures we spend a little bit less time on that because now we've got a well-oiled machine that's amazing and you mentioned the well architected framework uh this is something we talk about a lot at aws but do either of you want to discuss how that sort of fits in and and how customers might be able to access it or or use its information to make better decisions yeah i can touch on it so i do um so one of the nice things is you know i do focus on serverless so while architected reviews there's really two components the main core of the well architected review is to talk broadly about your aws adoption so it will talk about your how do you as an organization look at security so it'll talk about a lot of different it'll walk you through a number of questions and you can talk to different personas and senior leaders at organizations to ensure that they're thinking holistically about their adoption for me a little bit selfishly on the circle this side we have different lenses so for example there's a serverless lens that has a subset of questions that pertain specifically to serverless so we could think about now you're building serverless applications with this serverless lens here are some questions that we can kind of dig into what i've seen some customers do is they'll actually take the well architected review process and then include that as part of their own internal operational processes so as an example i had one customer they had a process that they called permit to operate and permit to build right these were two phases or checkpoints that they needed to go through in order to one be permitted to build an application and then later on once the development phases have completed they're now allowed to go into production in that permit to operate process they included the well architected review to ensure that all of these concerns are considered before they actually go into production that's kind of fascinating so probably things like security and testability and observability all the abilities fantastic when people hear serverless and containers and maybe they're working with legacy code and you know legacy systems is it too late to modernize i mean how is this something only for green field applications that are brand new or can everyone be a part of this it's definitely never too late to modernize uh we have customers who are modernizing applications that are easily 30 or 40 years old um stuff that's sitting on mainframes so yeah and and what's great about that i mean you know we think about it but i mean this is stuff that's running probably some of our most critical infrastructure whether it's financial transactions or you know whether it's the the backend customer database for most of our you know most of our customers that i mean this is this is where all the real information is is sitting in these legacy apps what's pretty amazing though is it it doesn't have to be a path that's you know prescribed through hey let's first uh figure out how to you know re-platform the app or put it on a new operating system and then somehow make it you know turn it into a container and then somehow get it to serverless let customers take the full leap and go from mainframe straight to serverless and the hardest part of that of that journey was not actually learning serverless it was actually making sure that they put a framework in place to make sure that they got the application right at the other on the other side right it's the typical like we have to re-architect our app well how do we make sure there's enough testability in there how do we make sure we've got the right capabilities and features how do we make sure the right interfaces are still available and how do we how do we find out all the other dependencies that matter it's like typical work that you do for any application re-architecture yes which is always stressful i mean i've been on those teams and it's hard so that's phenomenal i think i mean i did not realize that it would be that um i'm not saying it's seamless but a sort of one step where you you take this from mainframe to serverless on the cloud what i mean what kind of concerns come up with that and and talk to me also hey maybe for you how do how does serverless scale like how does it is there a point where serverless kind of hits a max or is it is it infinite yeah let me i hear two questions there let me first talk about like concerns right and so um you know banjo gave the uh example about you know taking a mainframe application and jumping direct into serverless you know i have a customer i can't really name them quite yet but i have a customer that we walk through that that journey and you know part of the there's there's kind of a broad range of concerns to think about one is you know before we talked about people right one is just enabling people to think serverless right if you're used to building a traditional three-tier application or maybe it's a just a two-tier application sitting on monolith so it's cobalt code with db2 database sitting on a mainframe and then they're traditionally now thinking about three-tier java applications using like oracle databases as an example you know first is just enabling the people to think okay what does an event-driven serverless architecture actually look like what does that mean right so it might sound like a lot of vernacular but that may not have a lot of applications so part of it is just doing enablement right let's do some training enablement help them kind of make the mental leap to think about how can we think about this business problem using a different paradigm of processes that's maybe one thing and then the other thing is getting so that's part of working with the technology oriented people the other is then working with senior leadership right so they're going to be thinking i have this mainframe application it's mission critical and it's core to my business you're going to go and do this thing called serverless which i've never heard of like to me that sounds like risk right so part of it is then building business case and convincing them that actually this new architecture is more agile will be able to meet your business demand and actually it's easier to troubleshoot the problems when they arise because we're going to like we just talked about build observability build that monitoring and logging and troubleshooting capability into the application so that we can kind of do this in more near real time maybe not to your second question around scale and performance so one of the nice things with when we think about serverless now serverless has a number of different compute offerings like one of those is perhaps a well-known one aws lambda and lambda will scale to meet your demand so we have the capability this idea of we're going to just run your function and we have what we call these execution contexts in the background and we can scale to thousands of concurrency per second so we can allow you to just burst up very quickly and likewise when those uh execution context or execution environments are completed they'll just go away scaled down you don't pay for any uh unused compute i mean let's just from a compute standpoint that is phenomenal i mean that is just unbelievable that not only do they not have to pay for whatever they don't use but the the effort required to build a system that can do that is is just i'm overwhelmed thinking about it to be honest if i could do one one more plus one to that um one of the really big values that we see with our customers when we think about modernizing applications you know applications don't exist within a vacuum right all these applications are integrating with other either upstream or downstream systems and really one of the powerful things about lambda is that we have over 200 event sources that can trigger a lambda function so just a concrete example is i upload a let's say a picture to s3 um that can automatically trigger a lambda function to be invoked and let's suppose i want to automatically generate a thumbnail as an example right traditionally you might have a system where people sfdp files in and then at night they're going to run a batch job that goes and processes all those images that came in during the day and maybe that batch runs for an hour now in this new kind of event driven model or event driven world we do these things in near real time when the image comes in we process it and we go kind of along our way you can now imagine there's many many many use cases where we try to process these things in near real time and that's where we have this kind of event-driven idea and it sounds like these events can happen concurrently right it's not like they get queued up it's happening as it comes in for everything yeah so there's many different models in there but yeah we just want to think about we're going to ingest a large bulk of messages or events and then we want to process those as quickly as possible in parallel yes okay and you mentioned something interesting which is you know say a developer or a team they're sort of pushing for this modern application either containers or serverless or both uh up to the leadership you know i think a lot of times we talk about the the business leaders or the cxos making these decisions but developers have a lot of power and a lot of influence how could they best sort of sell or persuade uh this new paradigm to their leadership i'll i'll throw in uh just a quick quick plug here i i think one of the best things you can do as a developer is to show the technology and show it off the the internal kind of viral adoption that happens is as powerful as you know a cxo or a business leader getting on you know getting in front of the team and saying hey we're going to standardize on this platform i think in the last 10 years or so we've seen developers just voting with their feet right they build on technologies that make sense to them they build on technologies that are efficient that take the operational burden away from them that you know don't require them to have to think about how they're going to scale up or scale down or deal with cost or deal with security as much of that as you know can be taken away but i think it does require both sides like you need you need the development teams to buy in and i think it's clear that once they've made a technical decision you need someone to be the executive sponsor to come in and say okay this we're going to make a bet and we're going to put budget behind this we're going to actually train folks and we're going to help develop the center of excellence around either serverless or containers or whatever it is and then we're going to we're going to help spread that out i think that's a that's a critical part of getting the internal adoption right you've got to do some internal marketing you've gotta you've gotta show off what you're doing otherwise no tree falls in the forest nobody hears it yeah and kind of to build on what banjo just said also you know one way you know sometimes it's hard for the so the developers could get excited about a technology but maybe the leadership isn't so much and you know i think what pancho is maybe getting at is like um sometimes like what he had mentioned is you just build it and you demo it but off like what i do with some customers also is it's not just about building the proof of concept but it's creating the story around it so you can you know here at amazon we're really big on data and metrics right so you can as a developer or an architect talk about you know before with our old process this would have taken us three months to build this capability hey using containers and servers we actually built this in two weeks right so you can kind of talk about the percentage reduction of people effort to be able to build the application and then another way could be we talked before about observability and maybe about troubleshooting problems that occur in the environment you could also talk about hey in the past these were some of our operational metrics around um you know mean time to recovery mean time to resolving those issues and then say hey actually with these new observability tools because we built in performance and security into the application from the beginning actually now we've reduced our mean time to recovery by you know 75 so usually business leaders want to talk in those type of metrics so you know we as technologists can actually help creating that story using those metrics i think that's one way to help get internal leadership really on board to why we want to push more and more with these modern apps absolutely and i talk a lot about that you don't have to boil the ocean right we're not we're not talking about making everything and shifting it over at one time you can take small little services or small little segments of your application and test it out uh and then as you say show this data off um i think also what's compelling for me perhaps with serverless more so than containers a bit is i think once you get past um the misnomer of the name uh you actually i think it's a little bit more easy for non-technical leadership to understand it's okay something happens and then something else happens this event driven um architecture and approach i think just makes sense intuitively to people which really really helps from a leadership perspective how what's the best way to recruit i mean if you're if we're moving toward this modernization and we need people who are more familiar with you know perhaps they're an aws shop and they they want things that are people who are familiar with aws lambda and fargate and these specific services what do you think the best way for them to approach recruitment and hiring us i actually think you know at this point it's super easy to train folks on this technology i actually think it's hard to get folks from the outside um and and just you know find find you know new folks who are gonna both learn your kind of culture of your organization as well as learn your your apps and you know your app frameworks that you use and then also somehow become experts on the technology you can always find those experts out there i think there there are tons of folks out there who are who are training up on serverless technologies but it's such an easy set of capabilities to learn i actually think that's that's way more beneficial to the organization because it promotes retention you get folks that are willing to stay on because they they're they're getting skilled up and they're getting skills that they wouldn't have gotten somewhere else um plus it you know it it it helps kind of bring that change into the organization without being kind of a foreign antibody like someone someone walking in saying hey i'm the expert on serverless let me teach you how everything works i think it's great to build that muscle internally and then you do you can bring folks from outside as well and i'm sure there are plenty of folks you know out in the you know out in the industry who can um who can jump in yeah i'll get kind of two ends of the of the spectrum in the story i have a colleague who was here at aws and recently went over to the customer side and he was sharing this exact challenge like you know i'm here at a let's just call it a pharmaceutical company and you know we're not known for being a technology company we're known for being a pharmaceutical company right but you want to hire strong technologists right and so he's you know it's currently faced with that challenge you know i think some of the steps that he's taken um is beginning to do uh public things that kind of show off their cases so you know one is creating public blog articles starting to create uh maybe open sourcing some of their software uh that demonstrates some of their capabilities and then you know maybe getting on webinars or you know perhaps participating in re invent as a speaker and kind of showing off some of the your technical capabilities to demonstrate that we as a company are now becoming more technology uh forward in thought and then the kind of the other end of the spectrum and i'll actually wearing their t-shirt from rehab four years ago is capital one right so capital one you know i remember i went to re invent five six years ago and in the expo hall that we invent is capital one and you're like that's interesting why is capital they're not they're not really a partner or vendor per se in the traditional sense but they were very you know forward thinking and saying we're not here necessarily to sell uh capital one goods and products but we're here to actually recruit and demonstrate that we're forward thinking so one example is you know capital one they open source uh their internal monitoring tool which many people probably know as cloud custodian right so it shows that as an organization they're really forward-thinking you know they've committed to being all in on aws and even recently they actually even talked about being servos first right so really pushing the envelope in terms of building uh cloud-native applications so again i think you kind of see that spectrum of like you know where do we begin and now you kind of become like capital one where they're really pushing the envelope and people know that they're you know really big on aws and really big on being starbucks i love that too because you know when you think of companies that would be slow to adopt banks would be pretty high on my list right so the fact that capital one is is really leading the way i think is phenomenal especially in these um newer technologies uh i want to focus on containers for just a minute containers kubernetes do they go hand in hand can they be separate talk to me how do customers use it yeah yeah i you know it's interesting i i i think um it used to be that you worried about first the container and then the orchestrator and then there was like a myriad of opportunities for you know choosing an orchestrator you could you could get mezzos there was swarm was kubernetes um there was console and nomad i mean it was just there's a fantastic like variety i think we've all settled on the fact that kubernetes is is now the standard in terms of orchestration and and the container technology just kind of comes with it but having said that you don't have to spend your time managing orchestrators either right um i think there are organizations that have said hey we're going to make a bet on kubernetes because it is the standard because we have a wide diversity of environments you know multiple cloud providers we run at the edge we run on iot devices and we've got to standardize on some platform and and that platform requires orchestration so and that makes total sense that means you have to go invest in the people the technology and the training and all the other pieces to make sure you can support that but i think for most organizations you shouldn't have to worry about that and so if you can take an approach where you don't have to think about the orchestrators so you know technology like like ecs our elastic container service you never have to worry about what the orchestrator is doing it's doing its job and and you never have to tune it or tweak it you just tell it hey run this task and give it the parameters for how you want to run the task and off it goes you know skills up as needed so and then you add fargate to that and then you never even have to worry about the the actual worker nodes that are running those those nodes just show up they get provisioned they've got isolation in between your your container tasks you're you know you're good to go so it doesn't have to be you know doesn't have to be that you have you have to manage for both they shouldn't have to be intertwined so i think for most organizations i would start with think about if you're going to run something in containers try to run it with the least amount of effort possible like start start in the simplest way and then you know if if you run a myriad of environments if you're running across a variety of cloud providers if you've got a standardized and you have the talent and the resources to fund a platform team that's going to be experts on kubernetes which you can absolutely do then you know then you go down that path but i would only do that if you absolutely have to and i'm trying to think of use cases but if someone wanted to start with ecs and and then eventually move to kubernetes and maybe use utilize eks is that what's the transfer between those services is it's pretty smooth or what are sort of gotchas yeah the big i mean the big gotchas is is learning how to manage kubernetes um right and and for most folks uh moving from ecs to egs you know your code is 100 portable right you bring your container images with you you you know uh you can you're gonna have to rewrite your your your yaml and you know find a new way to describe it and you know the format that is the kubernetes api uh and that's that's not impossible and it's not not super hard but it does take effort so i think for for organizations that are starting down the path i would i would make a very clear choice like is it worth your time and investment to invest in kubernetes and having to manage that control plane or do you you know can you get away from it i would tell you that actually most of our largest customers run both so for depending on the workload depending on the team that's managing that workflow depending on whether it's running in a production environment or whether it's more of an internal facing application you know internal facing non-production but also you know largely managed by a development team typically run on ecs and typically use fargate as a result those that you know maybe are running in production environments and have to run at scale and have to make sure that they can be 100 portable made a very clear choice on the type of workloads they have to run in a centralized platform typically go to kubernetes okay that's that's kind of amazing and i think it highlights another point we we talk often as if these companies universally utilize x y and z but it's really that this team specific service specific um even smaller applications within a broader context though the tools they use every day are going to be vastly different uh and so a company could utilize all of it but for very very different reasons yeah i mean back in the back in the stone age if we all recall like we used to manage application by application right it was like you deployed your j2e app on a specific you know os width specific middleware on a specific hardware platform and we had to manage that thing now at least we've got the benefits of okay we're all standardized on kind of virtual instances and you know virtual machines underneath and if we can standardize on a container format like we're way better than we were before hopefully um but yeah it does does definitely take still some effort it was just this is completely tangential but it was just a few months ago that someone pointed out software middleware hardware yeah so that was a moment for me [Laughter] talked about like thinking about the container as an artifact you know actually back at you know the last three events lambda also announced support for container images as a deployment artifact for your landed problems so if we want to lower the lines a little bit more um germany you can use your cicd pipeline so that your ci process is still building container images they just happen to now be lambda-based images and then now your cd process instead of targeting eks ecs or fargate you can now just target lambda at the deployment layer as well and that transition is probably easier than going from something to kubernetes so i would say like if you're going to move move up abstractions rather than down yes i like that be a salmon move up abstractions so can we we've talked about a few of these services but what is the difference between lambda and fargate um you know and i'm sure i know that there are many other serverless services so tell me about the high points please yeah i guess for me at least the big key thing to think about and this is this is more i'm putting on like the architect hat of like why would i want to choose one versus the other and oftentimes it's thinking about an event-driven paradigm versus like i need a server or i need a process to be running at all times so for example if i want to run an apache tomcat server and have you know host an api through there or i'm going to run a spring boot application to host express apis you know those type of application models or frameworks expect the process to stay online and act as the server alternatively if we want to say i want to move away from spring boot and i just want some managed nervous to be the api layer and then the api layer will then just make some functional calls and run whatever compute on the back end i think that's where we start to transition a little bit again this is pulling away some of those common uh infrastructure elements using a managed service and then focusing really on just building you know the the business logic associated with in this case like a rest api to me that would be like at least from an architecture standpoint like but i always try to distinguish it too they both work and they're both completely viable alternatives i think a lot of it depends on as an organization uh which paradigm do you want to choose you kind of want to maybe you're very used to spring boot and that's how you build your applications and i think you continue that way especially if you have a lot of operational maturity in that way but maybe you'll have some tiger teams in your organization that are saying it's fine we love it and the majority of our applications will be like that but let's just think about something new see if we can make it a little bit more efficient or maybe reduce some of the um work required to get this product launched that makes sense does cost factor in with this i mean how do when we're making decisions and i guess perhaps broader what are some of the anti-patterns you see as people kind of think about these things um but i would be curious like how what are the decisions they have to make and and how are they kind of approaching these i think for for cost structures look at at the end of the day i think lambda is the cheapest and easiest way to get started on any application right like anyone who's worked with lambda knows that you can get started really really quickly i i think if you're trying to manage your costs as you scale up i think that's something you have to do very consciously both in containers and serverless i don't i don't think there's a there's a huge difference there except that in containers you're you're bound a little bit more by the the resources depending on whether you know you're using fargate or whether you're managing instances in your worker groups or not but i think that's that's a place where as you as you move up that abstraction that's something that i think comes to the forefront for for anyone writing writing their application you have to think about um what that's going to look like as you scale up how uh you know how how important is it for you to be able to to you know service every request that comes in and how popular is this thing going to get so i think it's um it's an important thing to consider as you as you start developing your application architecture but to get started i think it's a no-brainer you always start with lambda okay yeah and because i guess i'm on the serverless lambda side and i kind of know some of the pitfalls i will i will say that when it comes to cost um especially with lambda you know abiding by architectural best practices is really a big deal when you want to optimize on consoles so there are certain anti-patterns with lambda or maybe there are certain developer practices that we would strongly recommend it again and you could you could almost boot yourself in the foot if you kind of kind of use lambda functions in a wrong way where you could actually incur significantly more cost uh than if you were to use maybe a container-based solution i'll just give one example of just ways to think about you know before we were talking even about observability and we could talk about how observability ties into costs you know i had one customer scenario where they had some downstream dependencies that were that broke within their infrastructure and you know instead of using observability metrics and trying to determine the root cause that way you know they kind of use the traditional model i'm just going to throw more hardware at it and with lambda the way you throw more hardware at it is you can either increase the memory associated with your function or you could just increase the concurrency associated to the function so in their case they said i'm just going to throw up both of those at the problem and see if we can resolve the problem unfortunately it didn't and it then caused costs to increase the results so again these are like anti-patterns so we want to make sure that you know all of those best practices are built in uh and therefore we can then realize kind of those constituents so while i would love to stand here and say serverless or lambda is always cheaper you know that's not always the case we want to ensure that we're applying those best practices yeah you bring up an interesting point in that you know i think as things get more and more abstracted we think that the i think there's a there's a chance that people assume that the skills of you know 30 20 10 years ago don't apply anymore but really these trade-offs are the same you're still thinking about you know do i want it faster i want it cost effective do i concurrency versus memory like how how do we think about these things um and i think the the fact that the principles and the the baseline knowledge carry through is really important sorry go ahead no i was just going to say before we talked about well architected and i think this is one of those scenarios where we just do a and we can well of talk through here's the architecture here are some of the things you've done very well here are some things that perhaps could use some improvement and help you operationally yeah i was going to just add i think it's um you know it's interesting as we see more and more customers scale up that cost allocation as much as cost management becomes part of how they deal with the kind of growth of their application portfolio how they deal with you know independent you know businesses independent teams you know using a shared platform we've seen we've seen for a lot of customers it's not it's not necessarily that they're trying to reduce their costs but they're trying to make sure those costs are used the resources are used efficiently and you know the the more you put on either a shared platform or into a cloud native service and someone else is getting the bill the less you have to worry about the cost and so you know we go back to maybe those days of of you know mainframe where you have to do cost allocation you have to show someone you know how much they've spent in order for them to understand whether they can do things more efficiently and drive the right behavior i think that becomes that becomes important in both leveraging kind of cloud native services but also if you start deploying on a on a common platform so if you end up you know you know putting out a single container platform for all of your teams to use you've got to build in not just cost management for your your platform team but also cost allocation so your your you know dependent teams know what they're doing on the platform as well i think that's that's such a good point i um i i make fun a lot of what i call the blank ops uh you know the the we had devops and then we got devstack ops and then we got we really went off the rails with ml ops and ai ops and all these ops but this is where finnops i think really comes in and then and that's sort of the focus of it is trying to just be aware and and conscious of your your spin and how it impacts things the let's see when people talk about serverless first and serverless first strategies what do they mean yeah i'll take that one first um so what let me start with what serverless first is not uh serverless first is not serverless only uh right and so i think before we talked about you know is lambda or container is it you know is it either or but again i think we i think we can start to realize it is an end idea so when we talk about serverless first it's thinking about a problem through the lens of serverless capabilities and again within the serverless portfolio we have a broad spectrum right within the compute layer there's aws lambda and then there's also fargate for containers we have different storage servers capabilities like s3 which is our object store dynamodb which is our nosql database and there's also aurora serverless which is our relational service capability and then there's another layer which is like our integration services so things like api gateway sms or simple notification service sqs or simple q service database that functions right so when we think about serverless it's kind of what we talked about before of when i have a business requirement i want to think about building it cloud native using native services building it kind of as a modern application again the the code is really focused on driving that business value so again if we can architecturally think of it that way and satisfy the requirements with those capabilities then by all means let's architect and build in that fashion now again we did talk about there are you know anti-patterns or maybe um practices that wouldn't necessarily merit for example using aws lambda as the compute platform um and then maybe we have a tiering of okay we're going to now use target we're going to determine if now we're going to build this application as a long-lived process but we still want to use a serverless capability it just happens to be deployed as a container and then of course maybe there's a scenario or a reason as an organization that that doesn't work and then maybe you'll use some other offerings so it's kind of having this tiered effect where we start with those capabilities and then based on requirements maybe we have to go down to a different offer i think that makes a lot of sense i saw the state of serverless report by datadock they found that 80 of containers customers are also using lambda so clearly that's it it's an amazing common paradigm now that um and you know i think i think people forget that like we you can't run everything in a container you can't run everything in lambda so you have to use what piercing how did that where how did that happen um and i will say that um you know i i like piggy's description of serverless because it includes such a wide variety of capabilities that can also be used alongside containers like surprisingly like you can use uh event bridge you can use api gateway you can you can use all these these integration points uh alongside your your container platform as well now it's interesting in in the operations world we also we also say hey fargate and you know technologies like that are also serverless technologies but i would put those in the category of serverless ops right if you're really trying to not manage infrastructure then fargate target is the model you want and and you know i don't know if it's a misnomer but you know as a part of the serverless offerings i think it's really more about serverless operations than it is about developing an event-driven architecture or developing an application stack that is built off of lambda you know we have a new offering actually that just came out this year called app runner which blurs the line completely between you know containers and lambda and serverless and you know provides just a really simple way to deploy uh you know front-end web app it's just you know super simple all of your you know load balancing and uh you know all the deployment is taken care of for you and so kind of sits you know sits right in the middle of that kind of serverless set of capabilities and i think we're going to see more of those i think where we can uh provide interfaces for customers to you know just just say hey i'm trying to deploy you know a batch application i'm trying to deploy you know web front end here's here's the interface for you right make it as simple as possible and then there'll be supporting technologies around that whether whether that you know is eventbridge or whether it's lambda or whether it's fargate or containers i i think we just had the invention of another blank ops serverlessops here today we have found that one more add it to the file at this point okay um no it's an interesting way of thinking about that i i like that sort of delineation the i think one of the interesting things about how tech is shifting is you know i've been talking about personas versus roles and my my whole thesis is that personas are immutable you know i was a developer i'm always going to identify as a developer even if i'm participating in uh activities that belong to other personas and so how how do these things kind of shift and and move in modern applications i feel like you know developers are doing more operations work than ever before um you know what have you seen in in customers that works really well as far as and then tangentially to that how do the titles um track you know i feel like titles right now are just all over the place yeah i i'll take a first step at that you know i do see there's a broad spectrum of you know this is um conway's law around organization defines uh architecture and so you do see some traditional organizations that have separate operations teams separate development teams and they're trying to be in a way bimodal where they have that but also they're trying to you know you know aws amazon we came up with this idea of two pizza teams some time ago but the basic idea is you have a small number of people that could be fed by two pizzas again there's a lot of memes out there about what that actually means i know i'm like new york pizza deep dish like how big is that pizza yeah the teams are cross-functional and emily i think that's what you're kind of getting at right is you have architects you have developers you have sres site reliability engineers you have security people you have product owners all operating within the same team and all of the concerns with that product that you're trying to deliver for your customers are all owned by that one team um whereas you know so you know there's kind of different spectrums you know i've also worked with large enterprise customers that don't want to move into that model because maybe they're not really comfortable with that and they're used to the traditional model of having a completely separate operations team the different product and development teams and then maybe they'll have things like a some type of cloud center of excellence or some type of central teams that are kind of oversight roles but not necessarily these different small two pizza teams so there is there is a spectrum of adoption i think a lot of this will depend on comfort of senior leadership for kind of really pushing the envelope organizationally versus we're goin