Cloud AWS re:Invent Coverage | Nick Coult, AWS

Clips
More from Cloud AWS re:Invent Coverage

Nick Coult

Director of Product, Serverless Compute

AWS

play_circle_outline Overview of serverless compute product portfolio at AWS

play_circle_outline Four principles of serverless computing: abstracting complexity, composing primitives, integrating other services, well-architected fundamentals

play_circle_outline Comparison of Lambda and ECS with other serverless offerings in the market

play_circle_outline Maximizing Efficiency: Cost and Operational Considerations in Widening Serverless Adoption for Faster Market Entry

play_circle_outline Event-driven architectures in serverless applications drive positive results for performance, scalability, and cost.

play_circle_outline Simplifying developer experience, owning less infrastructure, and moving faster are core principles.

Info
Transcript

Nick Coult, AWS

Nick Coult

Director of Product, Serverless Compute AWS

Nick Coult, the director of Product for Serverless Compute at AWS, discusses serverless compute as a model that abstracts complexity, reduces code writing, and integrates additional services with well-architected fundamentals. He highlights the popularity of event-driven architectures, especially with Lambda and step functions. Recent developments such as SnapStart and enhancements with VS Code for lambda function editing are mentioned. Coult suggests focusing on software architecture and event-driven architectures to embrace serverless. Fargate is explained ... Read more

explore Keep Exploring

What portfolio of products do you lead product management for at AWS, focused on compute? add

What are the key principles of serverless architecture that help developers move faster? add

What factors validate AWS's pioneering of serverless technology 10 years ago? add

What should be considered when evaluating serverless technology as a potential option for a business? add

What are some potential benefits of spending more time thinking about application architecture in the world of serverless? add

What is not going to change in the next 10 years, and how does that relate to serverless? add

bolt Powered by CUBE AI

Nick Coult, AWS

search

>> Hello, and welcome to re:Invent 2024. We're here live from Las Vegas with AWS on theCUBE. Today, we're really going to start to unpack what's been going on in serverless. We're celebrating its 10-year anniversary here at re:Invent this year, which is great because also, there was a 10-year anniversary of Kubernetes this year. A Lot of 10 years going on. So it's been a busy 10 years. So thank you, and welcome here. Today, I'm joined by Nick Coult, who's the director of Product for Serverless Compute. Welcome, Nick.

>> Thank you. Yeah, really excited to be here. Always love talking to customers and other folks at re:Invent. Super exciting times.

>> Yeah, it's real busy. I think, again, it's just been a fascinating week so far. The energy has been insane. The traffic's been insane, which is great. I was talking to some of the other partners that are on the floor. They said that it's been busy all week, lots of conversations. Tell us a little bit about yourself and what you're up to here, and let's go from there.

>> Sure. Yeah. So I lead product management for serverless compute at AWS. And so that's a portfolio of products focused on compute, so that includes Lambda, the serverless function service, Amazon Elastic Container Service, and Fargate, as well as what we call application integration. And so I love this portfolio because of the things that it can do for developers and for customers who want to move fast. I came to this myself as a customer, actually. I was a container customer. And so to be able to go from being a customer to being behind the scenes, helping to make things happen, these things happen is really, really exciting. And we do have some things that I want to talk about that we launched here in the last couple of weeks that are really helping customers move faster too.

>> And we'll get to that. I think, again, it's really interesting because people say serverless. And then actually, it runs on a server, but help people unpack what you mean by serverless compute.

>> Yeah. So serverless, one way that we think about it is really as an operating model. And in that operating model, what we want to help customers do is move faster. And so the serverless operating model, the thinking behind it is focus on the things that matter that help you deliver value, and don't spend time on the things that don't matter. And one way that we break that down is into four principles. And so, one of those is this idea of abstracting a way, the complexity of infrastructure management. That sounds like a abstract term. But what that really means is you take something like a Lambda function. A Lambda function is a really simple construct that is wrapping up a whole bunch of things behind the scenes so that you as a developer don't have to think about those things. And so that's an example of abstracting away complexity through a higher level offering. And so that's one of the principles of serverless that we think is really important that helps people move faster. Another one is the idea that the second one is this idea that you build an application in serverless by composing these primitives together. And by composing those primitives together, you don't have to write as much code, things that in a monolithic world, you would've had as a developer to write code, to manage a queue and make sure the right code gets executed. When there's work to do on that queue, we take care of that for you. And so there's less code to write. And that's one of the key principles to helping developers move faster. Another one is around, there's a lot more to an application than just code. There's other things that you need. You need observability. You need storage. You need networking. You need databases. And so what we do in serverless and what we've done and what we're continuing to invest in is ensuring that we offer really the best of AWS through serverless, through the integrations that we offer, whether that's integrations with CloudWatch or integrations with our storage services so that when you as a developer, you're building your code, you're running it on serverless compute, you have access to those other services that you need through the integrations that we offer. And the last one is more subtle, but it's a really interesting one. And that's the idea of well-architected fundamentals. So when we talk to customers, and we've done this for a long time and we tell them how should you build a resilient application on AWS, we talk about things like your availability zone, how you should balance across availability zones and how you should manage capacity. Well, when you use a service like Lambda, all of that is taken care of for you. You don't actually have to think about those things because we are doing a well-architected fundamentals on your behalf. So those four principles really are the underlying concepts behind how serverless helps customers move faster.

>> I was going to say, and knowing that it's the 10-year anniversary for both Lambda and as well as ECS, some of the things that have been going on for each service have really exploded. A lot of the services that run on AWS now run as Lambdas, as serverless. There's a lot that goes into engineering that to be that resilient, to make sure that it's simple and things of that nature, because I think people, the end users sometimes get wrapped up in the whole, "I have to build a microservice. How do I do that? Is it in a container? Is it not in a container?" Help people understand what the targets you're building for today, and where you're going towards the future.

>> Yeah. So when you think about who is the target customer for serverless, in some sense, it's everyone, but we are always thinking of developers first. How can we make life easier for that developer? Because the developer is where the rubber hits the road. If you're trying to deliver business value, if you got an new application that you want to get in the hands of your customers, the developers are the ones that are actually off implementing that thing. And so the more that we can do to help developers move faster, the more we can help our customers move faster. Now, that doesn't mean that we don't care about a security feature that a developer isn't going to touch or that we don't care about operational concerns. We absolutely care about those things a great deal. But even there, the focus ultimately is actually on how do we help that developer move faster? So when you look at things like how we do runtime patching on Lambda, a developer mostly isn't going to care about that. But we're actually making the developer's life easier because the platform team and the security team doesn't have to spend time patching those run times, doesn't have to spend time talking to the developer saying, "Hey, we need you to upgrade," because it just happens for them.

>> Yeah. I think that to me is a lot of it, especially when you get into the lower end of enterprise and the mid-size companies where maybe they don't have the technical expertise to go and do that. I know for myself, I've worked. I was with a startup. They started out on ECS using Fargate and going in, and being able... Because it was easy to configure, quick to get up, quick time to value from that perspective. Same thing with Lambdas and building. They built some microservices that I know, again, you had some announcements in the past couple of weeks. There's so much that goes on here. And everybody can go and check out. There's a huge page of announcements that happened in the last week and a half. What have been some of the key announcements that you guys have been talking about?

>> There's a whole bunch. I want to start by talking about some of the developer-focused ones. So we have this really interesting technology called SnapStart. If you've used Lambda, you're probably familiar with the idea of cold starts. And cold starts is when you invoke a function and maybe you haven't invoked it in a while or you're scaling up. And so there's some initialization that has to happen that can briefly slow down the startup of that function. And so we launched SnapStart for Java a couple of years ago that takes that initialization period down from eight, nine seconds down to less than one second for Java functions where we launched SnapStart for Python and .NET now as well, especially Python. People are super interested because they're doing things like machine learning inference. And now, they can actually run those Python machine learning workloads on Lambda and have a much faster cold starts. Developers love that kind of thing because you think about as a developer, what do you have to do to adopt it? You click a button. You click a button and everything gets faster. That's just an amazing experience as a developer to be able to get that kind of thing.

>> And also it's cost-effective because I think the best practice was, and we did this was with our Lambdas, is you would have one Lambda kind of sitting there running to a certain extent waiting for it. And then as it would scale out, it really quickly and things of that nature. So this helps that cost effectiveness as well.

>> Absolutely, yes. Helps on cost as well. We've also spent time on some of just the sort of core developer friction. So we've seen that VS Code is a super popular IDE. And we launched recently in the last couple of months some really nice enhancements with Lambda and how it works with VS Code. In the Lambda console, in the web console now, we have a VS Code based editor for Lambda functions. So you can go in and create a Lambda function, edit it directly in the console and use that familiar interface. Likewise, we have a really nice local IDE integration with VS Code that's got a bunch of getting started help, a really nice queue integration. We have a lot more plans there as well to just make life easier and easier for developers to get their code into Lambda. Same thing for ECS and Fargate. We're just continually investing in making that sort of inner loop of development faster and easier.

>> Yeah. I think that was what I was going to tie in, is the queue aspect of it because people are looking for that, especially where they're coming here because they don't necessarily have all of the techniques or they don't have the people, and they have a skills gap there. Are you seeing that when you talk to customers that a lot of them come to you and come to these services because they have skills gaps in their organization, and this lets them actually get to production or get to proof of concept and then production faster?

>> Yeah. That's actually a really important sort of way that people choose services that we don't often talk about. People will ask us, "Hey, should I use containers? Should I use Lambda?" And they think it's all about the workload. It's not all about the workload. It's also about the skills that you have. And what we're finding is that if you don't have an operations team, if you don't want to spend a bunch of time and you don't have the expertise to spend time operating clusters, run Lambda, run ECS Fargate,. There's no cluster to manage. There's no instances to manage. You just focus on the code. We do find things like queue to be immensely helpful as well because queue can help with code transformations. Take something that is written for a container environment that's not a Lambda function interface, and rewrite it for a Lambda function interface. Queue is immensely helpful with those kinds of tasks.

>> Yeah. And especially with the stuff they announced around going from things like .NET to Java, and things of that nature where you can actually optimize the code or even optimizing the .NET for that matter.

>> Yeah.

>> So I think there's a lot of, I would say, other competitive type of offerings out in the market. Help us understand again what your take is on these different offerings and where Lambda and ECS really sit.

>> Well, I would say when you look at the fact that AWS pioneered serverless 10 years ago and now you've got a lot of serverless or serverless-like offerings out there, it just validates our approach. This resonated with customers in all different industries across the world, and that's why you see that happening in the industry. And so we view that as a positive thing that we work backwards from customers, innovated, came up with this idea. And it looks like we got it right.

>> I would say so. I would say so. And also, I think some of the workloads that you're seeing, because I think a lot of people when... And I was just at KubeCon a couple of weeks ago, and again, AI is the big topic for containers and things of that nature with ECS, I think ECS started out, it was really aimed at being ephemeral workloads. And now, you're seeing that the workloads aren't necessarily ephemeral. Same thing for Lambda I would expect as well.

>> Yeah. We certainly see more if you have more stateful-like workloads, those are often a better fit on a container orchestrator because you can have things like a file system that persists and so forth. But we're seeing a lot of AI-based workloads running a Lambda too, especially when you combine it with things like step functions. We are seeing things like retrieval-augmented generation, like pipelines where you're going to generate the vector, put it in your vector database. Those kinds of things are actually really well-suited for serverless where your pipeline may need to process 10,000 documents right now, and then none the next hour scale up and down automatically. You don't have to worry about the infrastructure.

>> Yeah. I think I was seeing something around the elastic open search offering doing that with the vectorizing and using serverless under the hood for that as well, which again got me thinking about that because I think you see a lot of this being done in kind of almost batch mode or things of that nature. They have a certain amount come in and being able to go through, vectorize it, put it in there, or moving data, and things of that nature. With Kafka, and I know there's some integrations with Lambda and Kafka as well, as well as Kinesis and things of that nature that have been going on as well.

>> Yeah. Those data processing workloads are actually one of the best fit and most popular for event-driven architectures with Lambda. So it's really a growing area for us and one that we see a ton of customer interest in.

>> So what have been the biggest questions you've been getting this week? Again, you're 10 years in. You're talking. You're probably doing a lot of EBCs and things of that nature. But this week, but given 50,000 of or closest friends are here .

>> Yeah. We've had a ton of great customer conversations. EBCs, I also just went out into the floor and spent time with the serverless booth and just talked with customers there talking with people who might not otherwise get in on an EBC. And I would say one of the most common questions that I've been getting is how can we use more serverless, help us use more serverless. We love the operating model. We want to figure out how to get it into more workloads on more teams.

>> Yeah. And I think one of the things that's also out there, again, people look at serverless. And to my earlier thing about ephemeral versus stateful application, sometimes they do have that, "Hey, serverless costs more because I have something running there, and I have to keep it there to keep it warm and things of that nature." What do you say to a VP of software or a CTO or somebody in these organizations that may be looking at serverless and saying, "Hey, I'm going to be cautious with going down that path because I don't know what I don't know from a cost perspective and how I'm going to get into this"?

>> Yeah. First of all, I would say definitely go into any major technology decision eyes wide open. Evaluate the trade-off. See if it's the right fit for you. Like I said earlier, it's as much about the team and the expertise as it is about the workload. I think if you're interested in moving fast, and if time to market matters for you and it's hard to identify a business today where time to market isn't important, then serverless is going to be a really good choice. That doesn't mean that there aren't things you have to think about. It's not an automatic, just click the button, and now you're serverless. It is a different operating model. And in many ways, it's a superior operating model, but it is a different operating model. One thing that people find is that because you're taking away all the infrastructure and you're making the application really the center, if you write your application with Lambda, the functions are the thing. There's no clusters. There's no instances. And so that application team ends up owning more, in some ways, than they would if you were operating in a more VM-centric environment. And so they might have to take on some operational tasks that previously, they didn't. Now there's a lot of benefits to that because they're actually closer to that application when it's running. Who knows better to diagnose what's going on with the application than the person who wrote it, right? That's actually the Amazon model, by the way. You build it. You own it at Amazon.

>> I know. Having been here, I definitely know that getting sent too in the middle of the night is not fun. But again, it's part of the story.

>> But it does mean that there is a learning curve. It's not a huge learning curve, but there is sometimes a learning curve to say, "Okay, we have to think a little bit about who owns what and what the responsibilities are, and we have to make sure that our developers understand what they own and what they don't own because it's probably different than if they were running containers on VMs before." Who owns what is going to be a little different.

>> What would you say are some of the skill sets that those developers will really embrace and come up? Is it the shift left of the security aspect? Is it different code-based parameters and parameterization and variables that they need to understand? What are some of the things that people should consider about, "Hey, I'm going to up-skill my team because this is something we should be looking into," at least like you said, going into eyes wide open, starting to experiment and go down this path?

>> Some of it's around software architecture. We talk about this term event-driven architectures. And not everyone's familiar with that term. And if you're living in a more monolithic software world, you probably aren't thinking about event-driven architectures. Even though you may actually have events and event processing in your monolith, you're just not thinking about it in that way. But when you go to the world of serverless now, if you actually try to spend some time thinking about your application architecture, you may actually drive different development decisions that can lead to really positive results in terms of performance and scalability and cost and developer agility because you could decouple things in a way that you might not be able to otherwise. But you do want to spend a little bit more time maybe upfront thinking about that application architecture in a way that if you're writing monolithic code and cramming it into a container, you might not have to spend time thinking about those things.

>> Yeah. I think that makes a lot of sense because when you start to look at how people have traditionally built their applications, three-tier applications, a lot have been saying, "Hey, really. I'm starting to build new microservice-driven architectures at certain layers are going to be microservices." Then I may have some more monolithic code in the middle. And then I have my data layers. Do you see people who are looking at, they're embracing it, they're upskilling their people from an architecture and a software architecture perspective to look at it. Because I was talking to a major financial services company that happens to be roaming the halls here, and I just know them from a past life, and they're all the way to using Lambdas in front of containers in front of VMs that are actually calling back to databases on mainframes, on premise. Do you see a lot of these folks that are coming to you with these really, "Hey, we're modernizing this app, but we got to start from the front end back." And as we do, we're moving certain pieces more closer into the cloud and modernizing them into new ?

>> Absolutely. Actually, we have a customer who did exactly that. Their modernization journey started with almost nothing was running in the cloud. And they modernized as they moved into the cloud. So they didn't take their on-prem and just lift and shift. They wrote a new version, like a whole new version of their application. They started actually with their consumer-facing website and mobile app. And they got that running on Fargate first. They said, "Okay. Now, we know how to do it," and we've proven that we can move faster, because they were able to go from taking six months to ship a new feature in their app to two or three weeks to ship a new feature in their app, which drove a ton of value for them. And then they built the skills in that team and as they showed, "Hey, here's how to do it." And then they said, oh, hey, well, what about our backend application? We've got this core operational system that's not consumer-facing. Let's get that into the cloud. So they went and they containerized that, got it running on serverless containers with Fargate. And they're eventually just going to have their whole company running on serverless containers, and they're doing it, like you said, kind of front to back.

>> So we've both brought up Fargate. But we haven't really explained what it is. Why don't want to give people a kind of snapshot of that?

>> Fargate's a really interesting kind of in-between VM and a completely serverless function. There's no servers. So you don't have to pick a VM and manage an operating system.

>> You're Not going with the size of an EC2 instance.

>> No. You don't have to do those things, but it's a container. So you run a container in the form of what's called an ECS task, which is just a set of containers that run on the same host. That's all you run. You run your container, and then it runs.

>> Yeah.

>> And there's no infrastructure to manage. There is a host that appears that's behind the scenes that we own that we're managing for you. And each task gets its own dedicated host. So there's this really nice security benefit as well. What people really love about it is when you look at things like having to manage the scaling of the cluster and think about utilization, those questions go away. There's no such thing. You pay for the containers that are running, and you don't pay for containers if they're not running. And so the pricing model, people just love the pricing model. And they love the scalability and the fact that they can create a test cluster with a few tasks. A cluster in Fargate is just a name. We probably shouldn't even call it a cluster. It's really just a namespace. It's an entry and a database. It takes a half a second to create a Fargate cluster. People love that agility of saying, "We got an idea. Let's go create a cluster and run a service in it and then shut it down, and it doesn't cost us anything when we shut it down." So Fargate, the short answer to your question is it's serverless containers, and it's kind of combining that more traditional programming model where we don't have to make any assumptions about your code. But there's no server to manage.

>> Right. So let's take it up a level because say the CIO in regulated industry is looking at this, says, "Hey, we're modernizing an application. We want to go down this path." What would you say to them about, "Hey, we need some knobs because we're worried about the regulations"?

>> Well, actually, there was a really interesting transition that happened here because I've been on this team long enough to have seen this transition happen. So when I started in containers world in AWS six and a half years ago, there was some resistance from regulated industries because we're like, "We don't have access to the host." We got to have access to that to be able to audit it." Now, it's, "Oh, we don't have access to the host? Great."

>> That's your problem.

>> That is your problem. That's not our problem. It's a whole area that we don't have to have people looking at. We don't have to spend time on. So they love it actually. And actually, Fargate in highly regulated industries is super popular.

>> Yeah. I can expect that. I think that to me would be a lot of taking that the care and feeding that goes on with that server and things of that nature. And I think one of the things, and I think you hit on this a little bit, is the time from provisioning to actually being able to deploy code is really quick.

>> Yes. Yes. And that's like that core inner loop is one of the most important things for efficiency for developers. And efficiency for developers then leads to efficiency for the whole end-to-end process. Right.

>> Yeah, I do. I think that to me has always been one of the keys for it and why, again, I was at a startup, we used it. And it was very successful. I think we got up and running, and we're able to build our SaaS product very quickly on that. And again, iterate through using ECS and Lambda and using a really serverless architecture. In fact, it saved us a significant amount of cash as well, which is even better.

>> Great.

>> I can agree with that. So it's been 10 years. Now, let's look out next 10 years. What do you expect? What are you seeing? There seems to be a lot of velocity which is great if the flywheel is going here at Amazon.

>> Yep. I think it's fair to say that a lot of things will change in the next 10 years. I don't want to claim to have a crystal ball to know what's going to change in the next 10 years. So what I like to do is spend time thinking about what's not going to change. What is not going to change in the next 10 years, and how does that relate to serverless? But people, they're not going to want a more complex developer experience over the next 10 years. They're going to continue to want a simpler and simpler developer experience. I think gen AI might change the nature of that developer experience. So the specific things that we do might change, but the philosophy of a simple developer experience that helps you move fast, that's not going to change. Owning less, the operating model of taking away the heavy lifting and having less things that you have to think about, that's not going to change. Nobody's going to want to own more infrastructure 10 years from now than they do today. They're going to want to own less. Now, again, the details of exactly what owning means and what the infrastructure is, there's probably going to be stuff that's invented in the next few years that nobody's thinking of today that's going to become a huge business 10 years from now. And so I don't want to claim I know the answers on the specific technologies, but I know these core principles aren't going to change. Are people going to want to move slower and get their products to market slower 10 years from now? No. They're going to want to move faster.

>> Yeah. No. I think that's very key. And I think what I've liked, and I think some of the stuff that we talked about is the queue integrations, being able to queue for developer. And I see those two as being peanut butter and jelly, just makes so much sense together. I see that there's a lot of people who are looking... There's been some pricing changes with some other people out in the market, and they're looking to modernize certain apps. Those apps, not all of them, are going to necessarily migrate to serverless, but I think people are revisiting serverless. Are you seeing that in a lot of conversations you're having? Is that, "Hey, we've gone and gotten support for the next year. We've licensed it, but we're going to spend that next year looking to modernize this front end or these pieces of it and move it up to the cloud"?

>> Yeah. That's happening more and more. And actually, one of the big drivers for that is around the agility piece because it might feel like, "Well, do I want to go down and have to spend the time modernizing when I could just take the thing I have and just keep it running?" And that might be the right answer in the short run. But at some point, you're going to be forced to adapt to a big change that you didn't expect, and you're going to have to move fast. And you want to be ready for that. And so if you modernize, you're going to be ready for it because now, you've got a software architecture, and you're using services that enable agility. And so we're seeing just more and more, "Hey, we're ready to modernize. We're ready to move on from this thing that we have."

>> So where is the best place people can go and find more resources about this? I know the Amazon site is big.

>> Yeah.

>> So where should they focus when they go in there?

>> We have a lot of great documentation on the main AWS site. We also have a really great kind of supplementary site called serverlessland.com that has a ton of reference material that you can go read and learn about all the different solutions that technologies that we offer, a bunch of code examples, and things as well, reference architecture. So that's another good place to go look.

>> Awesome. Well, thank you, Nick. This has been great. I really appreciate it. And this has been, I think, very enlightening. Again, I love celebrating 10-year anniversaries. It shows the success and the depth. So thank you for coming on.

>> Yeah. Thank you. Super fun.

>> And thank you for watching this special episode of theCUBE live from AWS re:Invent 2024, live in Las Vegas. We'll see you soon.