Building for the future with AWS serverless services

Hi, everybody and welcome to building for the future with AWS server services. Before we start the main presentation, I'm really excited to share with you some of the expiring and incredible work that's being done by Nationwide Children's Hospital in the fight against children's cancer.

Genomic medicine is really applying genomic technology to the study of diseased genomes. To learn more about the genetic underpinnings of disease and to help diagnose and treat disease. We think about cancer in terms of changes to DNA and how that can take a normal cell to a cancerous cell and using the technologies that we have now in the analytics, we can answer that question in a myriad of ways and really understand the genomic underpinning of cancer. Once we understand that we can understand better ways to treat the disease.

So we have two different data requirements for this project. The first is to deliver results quickly to the physicians. The other one is being able to share that data with the greater scientific community. The second that one of our scientists signs out or our clinical directors sign out the report, an event goes from there to our system and we have a set of step functions that work through and de identify every single piece of data that we're doing. We then use another set of step functions to transfer that data over to our friends at CCDI part of the NIH. We're also doing this immediately. So this is very unusual. Usually you have data deliver every six months, you deliver that kind of thing. We deliver nearly the moment the data is signed out from the clinical director.

So my priority is to get the patient a diagnose as quickly as possible, so that more decisions can be made by the treating physician. So really, you know, we we put together a pathology report in the first few days after a patient has surgery, we as physicians understand that there's a certain amount of time that things have to take. But when it's your family and it's your child going through, it speed is incredibly, incredibly important, the ability for us to take this tissue and be able to, to really give a comprehensive look at it through our analysis and then be able to turn it around so quickly and give it back. It helps these patients because we're able to give them an answer quickly and that really helps them not kind of stay in limbo for a long time of how do we treat this, the sooner, the faster we can get information back to them and to their physicians the better. And um our turnaround times are, are incredible here. So I'm really proud of, of all the work that we've done here for that because it's really making a difference in patient care.

So we have been serverless here for probably six or seven years. We were very early adopters of just the general mindset of not having servers running and we didn't need them for this project. We were leaning on step functions which is sort of the backbone of all of our pipelines. And from there, we integrate with a number of different things, lambda, batch ecs, different things for different algorithms that are required. The best part about everything is that we can also use a eventbridge. So we have an event driven architecture so we can add new tests as they come along or we can add new features without worrying about changing our clinical pipeline, which has already been validated.

I've been in technology for a long time. I've written a lot of software over many years and decades and this is by far the project that i'm most proud of because it makes a real difference. So every day I get to get up and I know that somewhere out there there's a kid that we're helping with this. And I've, I've never been a part of anything like it. And it's, it's amazing everyone.

Please give a warm welcome to the vice president of cus computes, Holly Mesrobian. It's the, it's very inspiring to hear about the story of Nationwide and how they're changing the lives of children and using serverless technologies in order to help do that. As a mother of four, I also really appreciate the work that Nationwide is doing on behalf of children. I'm excited to be back here at re invent. It is my sixth re invent. And every year I continue to be amazed by the innovation that I'm seeing by our customers such as Nationwide who is analyzing pediatric cancer samples 24 hours a day and getting that to the results to technicians even faster. So I want to hear a little bit more about the story. I'm sure you do too. And to help me do that, I would like to invite Grant Lamy, who's the development manager of cloud for data sciences at Nationwide grant. Come on up.

It's great to see you and have you here and to have a chance to talk to you. Thanks though. I, I really appreciate the chance to be here. We've, we've loved this project. Um it's been really important for all of us. Uh really important for the hospital. It's kind of we have this motto, it's best outcomes for kids everywhere. And uh and we really live by that. And so something like this, we have now had over 2000 kids that have gone through this process. And the idea is that we are finding the genetic cause of their cancer. So that they can have a targeted therapy. Right. When you're an adult chemotherapy radiation, that's really rough on the body. It's even worse if you're a little kid. Right. And so anything that we can do to make their, their process, their healing better, we're all for that. And it's through the use of this technology, we've really been able to, to change how that's done.

So I want to go into that a little bit more because I do hear from customers who ask questions about serverless and what that looks like and how do you do you adopt? And so can you start off and tell me a little bit like you say, said, you were doing this quite a while ago and I'm really interested in how you chose serverless. And what did you look at? What were the factors that you were considering with that selection?

Sure. We, like I said, in the video, we've been using it for for many years and what it was is so IGM the institute of genomic medicine is a cornerstone of the hospital. We decided around the same time that that was going to be a big pillar of what we did is genetic medicine, genomic medicine. And so that gave us a chance to sort of step back and look at everything we were doing. We knew we needed a way to scale up, we knew we wanted something that was robust and professional. A lot of times you get automation by graduate student or something like that, someone's running scripts doing that kind of thing. We wanted it to be streamlined and smooth. So we took a look at, at everything was out there and we could see a lot of mapping to serverless to what we're doing. So a lot of industries like say something, banking, you have a bunch of little transactions all the time. When you're sequencing a genome, it comes off as a giant pile of data. So we have these huge spikes that we have to deal with. And so not running servers all the time and just wasting them makes a lot of sense in that. So we can scale up real quick to handle these and then we can scale back down while our sequencers are still processing data so that it really kind of two things just fit really well together, I think.

Yeah. And um one of the things that um customers will ask a lot about is what kind of changes did you have to make in your organization or um you know, in your processes or how you do work um that made it successful for you in your adoption.

So what's really interesting there is from a technologist standpoint, I mean, I love learning about new things as much as everybody else that's here, right? We always want to try something new, do something new, so convincing our development teams, no problem. They were on, on to that. It's fairly easy to adopt the mindset. Once you get, it's a things as synchronous, all that kind of stuff. One of the real interesting benefits though is it gave us away a common language that we can use with doctors and scientists. So let's say I'm having a meeting and I've done this many, many times. What I'll do is I'll bring up the graph of a step function and I'll be like, ok, this is what we're thinking algorithmically for how we're gonna add this new test. It's like, ok, we'll do this, do this. That's super easy for them to grasp. They're super smart people, but they're also crazy busy. So it's a great way to have them see what we're thinking in a way that they can easily understand it's way better than a rima code on the screen. And so that's allowed us to turn around and make new tests even faster than i expected us to. So that it's one of those we never expected it. It's just one of those great happy surprises, making use of those visual.

Yes, that's a good 11 of the other really interesting areas is you're working in health care and health care for children. There is not a much more sensitive environment that you could possibly be working on. Meanwhile, you need to innovate really quickly. How are you able to pair up kind of the the requirements around handling, very sensitive data and then the speed that you need to be able to move at and how is that working for you with that?

Absolutely. And it's, it's very interesting too because the genomics area, it's pretty young. It's only been around for 20 some years. So there, we're always learning new things and we want to add new capabilities. So having an event driven architecture, i mentioned that a little bit in the video is absolutely critical for us because what it means is we could add new things without touching the bits that we have clinically validated. Now, I know i'm a parent, you're a parent. Lots of other folks out here are a parent. You do not want to just sort of mess around with this, the validated code that's already running, right? You want that and you want that validated for a reason we all that's, that's just a nonnegotiable but having these things we can add to that don't touch that original code is fantastic.

So a couple of examples of that um there was a request for a different kind of report to come out of it that we're gonna share with our friends at the NIH, we redact everything. They wanted an extra piece of data and that it's like, oh boy, in the olden days, if you had a big of a monolith, you'd have to dig around and change things and then you'd have to swear it's like i didn't break anything i, i didn't do it. Like, you know, we've all done that. I've done that and then you, of course, break something by accident and it's really bad. But in this way, you don't do that, it's totally separate and it's totally great. And then another thing, i had a doc come to me, he's like, hey, i'm on the floor, i'm going between things. I want some notification when my, my case is ready. But it's like i'm moving from room to room thing to thing. It's like, can you just get it to pop up on my watch? I'm like, ok, yeah, we'll just add an event we'll watch for a slack message and it just pops up. You can see it. He can go about his rounds and then he can go straight to look at the results. So really cool stuff like that we can do because we've separated it out.

And i absolutely love that story that the doctor going out into and working with the patients and then getting events and information where you can really move quickly, help the children.

So i think yes, in closing, i'd love to hear if there's any parting advice or words of wisdom from you about serverless and cerus adoption.

Yeah

So what's interesting with me is I took biology in college in the nineties. That was the last I did anything medical. Um but my mom has AAA version of muscular dystrophy. So I've always wanted to do something that would help, would help people like my mom, help little kids in this space with genetics and genomics. And so when the opportunity came to be a technical person here and to bring things like the service architecture we're using it. It's really, it makes doing work really fulfilling for me and I think that others can, can find the same niche as well.

Well, it was a pleasure having you here and talking about serves. Thank you. Thank you so much. I appreciate it. It's great to see how grant is changing medicine at nationwide for children.

So we talked a little bit about this uh in terms of, you know, what is serverless and so let's start off there. Uh grant shared a bit of his story and I'd like to talk a little bit more how we look at it and what we're doing.

So we do believe it's an operational model and it's, it affects how you build your software. You shift the management and infrastructure and resources to AWS and we use our economies of scale and our expertise in e and efficiency in driving savings and reliability onto you. We work on these things all the time. I have teams of engineers who are absolutely obsessed with all of that and that's what they do. And then in turn, what this does for you, is it frees you up in your teams so that you're able to build and innovate in your business. And just like what Nationwide was able to do, we have a breadth of CUS products and we've been expanding that over many, many years. And really the reason we keep building more CUS products is to help bring all that value and remove the overhead for you. If you look across our products, you can see that we have compute with Lambda and Fargate and ECS. But we don't stop there. We also have storage solutions with S3 and EFS and we have workflow integrations, things like Step Functions and EventBridge like Grant was talking about and we have databases and analytics. We have things like Quicksight and Bedrock and Dynamo.

We pioneered serverless back in 2014 with the launch of AWS Lambda and we continue to innovate on, on that product. But we also continue to expand the application models for container and event driven workloads. What this means is that if you have a net new workload and you're ready to adopt an event driven architecture, you can choose Lambda and one of our event driven products, but you are not left out. If you have a product that maybe are a different existing application where you want to get some of those serverless benefits, you can go and use ECS Fargate and migrate your workload with very little change.

So why are customers adopting a survey model? I touched on a little bit of this agility performance security all while lowering total cost of ownership. Some companies do choose to uh manage servers and the infrastructure and do the patching. But that can, can be a lot of extra work on engineering teams for teams that want to do more and build more quickly, they're choosing the serverless operating model. And that in turn is delegating the responsibilities of all of that management to AWS. You use our expertise in performance, scale availability and security and then in turn, you're accelerating the innovation of your teams.

Let's see a little bit about how cerus drives agility in your business. Speed does matter in business innovation comes with speed and speed comes with doing less. Servius helps you write less code, do less maintenance and build quicker. You focus on your business logic, you're not scaling, doing security updates and other maintenance. Deloitte found in a recent study that this is reducing development time by 68%. One such capability that helps in that speed is Application Composer. It helps builders visually compose CUS services, you drag and drop the different CUS building blocks onto a canvas and you get a visual representation of the application Grant. talked a little bit about this.

I am happy to announce a new integration of Applicate App Composer with Step Functions. This brings another great building block into the App Composer interface to help you build even more. There's nothing like seeing something visually. So I'm going to welcome James back on stage. to show this to you.

Hi, everybody. My name is James Beswick and I lead the developer advocacy team for AWS Serverless. In this demo, I'm gonna show you how we've taken two existing services, Step Functions and Application Composer and brought them together to really help accelerate developer agility.

So the DA team has built an application called CUS Video that this week you'll see in the expo hall over in the Venetian. This is a streaming application that's built on serverless technology and generative AI. It's plug in based. So I'm gonna show you in this demo how we can modify a plug in using these new tools.

So in my existing plug in, I've got 2 S3 buckets, one EventBridge rule and a Step Functions workflow. Currently, all this does is it transcribes and translates the videos. What I'm gonna do is modify this so that it stores the data in a DynamoDB table and then we can access it using an API Gateway endpoint.

Now, previously, before these changes, if I wanted to do this, I'd have to go and make the changes in the workflow, then manually take the ASL make any changes to the to CH to put in definition substitutions, then move that into my ID all separately. But developers have told us they want a single pane of glass where they can do all of this in one place and that's precisely now what Application Composer delivers.

So to make these changes, I simply click on the Step Functions, workflow. And on the right hand side, I can edit directly in Workflow Studio. Now I'm going to search for a PutItem API call and then drag that to the bottom of my workflow. Everything on the right hand side, typically you would have done through code before, but now you can do it directly through the UI and I can make changes to my table name, replace that hard coded name with a definition substitution.

Now, once I've made all these changes, all I have to then do is click on save and exit this screen. And this will take me back to Application Composer. Now, if I click that state machine and edit the details you can see on the right hand side, there is an entry for a table, but currently it doesn't point to any resource. So I'm gonna drag that DynamoDB table onto the canvas. I'm gonna give it a name of TransitionTranslationTable and then I can use something called a connector where I can drag from the state transition directly to the table. And that has two effects. One is, it gives me access to the table first as I scroll down, you'll see the table is now the real resource is showing in the UI. And the second is it updates the permissions. So the workflow can access the DynamoDB table.

So the next task is to create an API Gateway end point so we can access this data. So in the same way, I'll drag this onto the canvas and I can configure all of those details about the API get it to use an OpenAPI spec and I'll pull a Lambda function onto the canvas. And here I can configure where the code can be found at the run time, the handler name and so on and so forth.

Now, next, I'll use a little bit of Python and all this is gonna do is query the DynamoDB table to pull a list of all of the, the items in that table and return it back to that API Gateway endpoint. So I'll save this code and then I'll use those connectors again to connect API Gateway to Lambda and the Lambda function back to DynamoDB. If I click on the range, that's now our microservice.

Now, Application Composer creates a SAM template once you've finished building. So I can then take that template and go to the SAM CLI. The first thing I can do is run SAM build. This creates a deployment artifact that builds everything needed for the Lambda function and everything else for the deployment. And then the next step is to run SAM deploy. SAM deploy will deploy that artifact into my AWS account.

Now, I'll upload an S3 AAA video file to S3 to simulate a video being uploaded in Serverless Video and that'll run through the workflow. Once that's then finished, I can then query that workflow using curl the API Gateway endpoint we created and you can see the translation in both English and Spanish.

So that shows you how these new features of using Application Composer make it just so much easier. You have this unified experience within one place that makes it easy to do things like definition substitutions. And at the end of it, you get a SAM template that then you can deploy directly from your IDE.

Thanks very much back to Holly.

There you go. Thanks James. That was a great visual demo. I hope you all enjoyed it. Another area of servius that helps drive agility is the ability to connect components together loosely with event driven architectures. You need to connect your application components to your own applications and to SaaS applications. In addition to the AWS services that we support, I'm excited to announce the ability to send and receive events with new SaaS partners, Amazon EventBridge has now integrations with Adobe and Stripe. This adds these event sources to our over 45 SaaS integration partners with a few clicks. You can publish Adobe and Stripe events into an Event Bus on AWS. These events can be routed to AWS targets including Step Functions and Step Functions can now send these events to virtually any API with its integration with HTTPS endpoints. We're continuing to invest heavily in additional integrations.

So I spoke about agility and how we enable you to turn your ideas into production applications faster. Along with agility, we are relentlessly focused on performance with serverless. We offload many performance responsibilities to AWS including scaling up of workloads and responding to unforeseen episodes. We drive well architected outcomes for operational excellence for your applications while you leverage our expertise in availability scale and security.

So what does high availability look like under the hood? We invest heavily in this area and we've done it for years with our engineering teams. We focus our efforts in several areas including resilience, health detection and automated remediation and workload isolation with cellular architectures.

In availability zone resilience, we run our services across multiple AZs for Lambda. We actually keep a full availability zone worth of capacity on hand and ready and we minimize interdependencies across our components between the availability zones.

In health detection and remediation, we also do a lot of work here. We have invested in health monitoring systems that detect gray failures of individual hosts but also more impactful broader availability zone events. And what's great about this is it also helps with triggering automated remediation, pulling the host out of service or moving workloads. We continually invest and improve our health monitoring systems for both speed and detection.

And we isolate and manage scale with cellular architectures. What this does for us is it helps to isolate workloads across multiple cells to limit their blast radius. And it also helps us with testing to a known scale.

Speaking of scale, customers love that Lambda automatically scales based on request volumes. This helps with performance critical workloads including web services and large scale data processing.

"And we are continuing to improve on this capability. There is overall scale of the service. So tens of trillions of requests every month, that's what Lambda does processing these days. And there's also the what the customer sees. So concurrency, which is how much work you can drive in an accountant function level and also scale rate. That's how fast you scale into that concurrency.

What this looks like graphically the peak is the total concurrency that's available to you for your workload. And the slope of the curve is the rate that you are scaling up and into that total concurrency. If you have workloads that you know need a certain scale, you can use provision concurrency. And this can be really economical if you can predict your concurrency because you can also use auto scaling to fit your workload to that curve. We also support Lambda snaps start which has improved cold starts for Java based functions. It improves start up latency. So we continue to make product improvements to help you drive improve performance.

It's in that vein that I am happy to announce the launch of Lambda function scaling improvements. We automatically scale each Lambda function to respond to large increases in traffic even more efficiently. So I'm going to make this with an example, if you have 1000 concurrent executions every 10 seconds, that's what you are able to scale into. Now say for instance, you have 6000 concurrency on your function, you can scale from zero to that full 6000 concurrency in just one minute to make it even more real. If you have 100 millisecond function duration, that's 60,000 RPS, you can scale into in a minute. That is really a lot of scale without any pre provisioning of resources with these improvements, Lambda is only getting better.

So since this is such a great one to to look at, I'm gonna welcome James back up to show you what it looks like in practice. Ok? So Lambda can scale incredibly quickly and that enables you to do two things. One is when you have workloads from queues or streams, you can scale up Lambda to do that more f more quickly. But also if you have large computational tasks, you can break them down using parallelization. And that's what I'm gonna show you here.

So back to our serverless video example, in the UI, we have this feature that enables the customers to drag the slider backwards and forwards and see a preview of videos by looking at GIFs. This is fairly standard functionality that you would see in a streaming video application, but producing the GIFs themselves is not actually very easy because it's computationally challenging.

So if I take a long video, like last year's re:Invent video of Avernus presentation at the keynote, and I try to convert this into GIF files every 30 seconds. If I run this on an EC2 instance using FFMPG, this creates about 220 or so GIF files and it takes about five minutes to complete. But the question is, what can we do to bring this job down to just a few seconds? So it doesn't take several minutes.

So what I'm gonna do is I'm gonna use Application Composer that I showed in the previous demo to build a microservice that can tackle this problem with Lambda. So first of all, I'll bring a Lambda function onto the canvas. Now, this first function is gonna be invoked when the file is originally uploaded to S3. Its job is actually is not to create the GIF file. It's going to receive the file. It's gonna look at the length of the overall video and for every 30 seconds, it will create an event which then it puts back on an EventBridge event bus.

There will be then be a second Lambda function that is invoked by those events that actually does the processing of the GIF files. So I'll take the second Lambda function and then bring that onto the canvas. And this time the function is actually gonna download the file directly from S3. So each uh the entire file will be downloaded to each instance this Lambda function. I'll call the segment processor and it will also create GIF files.

So I'll bring on an S3 bucket onto the canvas and this will we'll call this the segments bucket and I can use those connectors again to connect the Lambda functions with S3 and the EventBridge rule with the first Lambda function to set up the IAM permissions automatically.

Now, we'll also need a second EventBridge rule here. So the second of brawl will route all those events from the first Lambda function to the second. And the reason for doing this is it gives us the ability to scale up very quickly when we have hundreds of events released by the first function.

So I'll just configure the last of the connectors to make sure the permissions are correct and then click on the range and that's our microservice. Now, if we upload that two hour video from the first time now to our microservice, what we see after a couple of minutes when it's processed in CloudWatch metrics is that the, we've got over 228 invocations of Lambda. On average, they took about eight seconds and they took about 10 seconds as a maximum.

So instead of taking over five minutes, this now was done in roughly about 10 seconds. Now, what can we do to scale this up to thousands of videos instead of just one video. Well, I've got the staging bucket in S3 where I've uploaded thousands of videos including that, that the re:Invent keynote from Verno. So I've put those all in this staging bucket to give you an idea of how many files there are. If I run this command, we've got 3489 videos, 716 gigabytes.

So I'm gonna copy all these files from that staging bucket into my application bucket. Now this is a massive amount of data. So it's gonna take a few minutes for the copy operation to complete. But what's happening already is as the files that are arriving, Lambda is already starting to process them and starting to scale up.

Now after a few minutes, if we go back to those CloudWatch metrics, this is what we see we can see on the top left, the invocations graph, we've got well over 85,000 invocations. And in fact, there are about 85,000 GIF files that are created in the process of this exercise.

Now that middle graph, the total concurrent executions that started at around 2500 invocations and is growing as more and more data arrives from S3 and it tops out at about 5300 or so or 5800 and so over about 10 minutes, the Lambda has scaled up to meet the challenge of this task and has done something that otherwise could take days possibly even weeks with the amount of data that otherwise i provided.

So with Lambda, you have some really amazing scaling options. You have this massive paralyzed. You can apply to certain workloads to reduce them for minutes. Down to mere seconds. There's no need for scaling of clusters or manual scaling. As you saw the Lambda service simply scales up as the amount of data in S3 grows. And perhaps best of all this is paper use computes. So now the job is finished. I'm not paying any compute cost whatsoever.

Thanks very much. Yep. Thanks James. Our focus on speed and scale is not just limited to Lambda. Usually to launch a container, you need to download the entire container image from a repository. This can be slow and you may only need a portion of that image in order to run your job. This is where a seeable open container initiative or SOCI comes in. This is a technology that was open sourced by AWS. It helps a applications deploy and scale out faster by enabling containers to start without waiting for the entire container image. It lazily loads the image in parallel to the application start up.

We recently launched this for ECS with Fargate and it's easy to use. You create a SOCI index for your container image. When starting an ECS task Fargate automatically detects the image and then starts without waiting for the entire image to download. It's also equally easy to roll back, you just delete the index and you're back to where you were. This is all available at no extra cost to help you achieve the highest levels of performance.

So so far, I've spoken of two pillars of performance, availability and scale, but they can be weak if your application security is threatened. Security is shared responsibility between AWS and you. But we use a number of techniques and technologies to ensure maximum security for your applications.

Starting with infrastructure, we use Nitro at the physical layer and we use Firecracker to isolate functions. When handling data, we follow strict data access policies including supporting KMS, custom managed keys so you can encrypt your data in transit. And at rest, we also support a number of access controls including GDPR compliance and human access prevention.

And at the application level, we even support other capabilities such as code signing, which is a feature of Lambda. You are also able to see through debug your applications with X-Ray. Look at your audit trails with CloudWatch just to name a few. We continue to innovate heavily in security and this helps heavily regulated industries such as Nationwide today.

I'm happy to announce that we are expanding on that further with GuardDuty Container Runtime monitoring. This is expansion of GuardDuty's existing support to runtime threat detection for ECS workloads. It also includes our service container workloads that are running on Fargate. It identifies malicious behavior using machine learning and anomaly detection.

If you're running ECS on EC2, you already have some protections with VPC Flow Logs, DNS query logs and CloudTrail events. This gives you an added benefit to view your runtime and metadata. Now, GuardDuty will identify these threats to the ECS environment included in Fargate.

The benefits of agility, performance and security that we spoke about. All help you drive down costs, you can accelerate your time to market without large start up costs. You can focus on your people which is your most valuable resource to have them add to high value work and you can save on security costs. Security breaches can be expensive.

Service services also have several cost levers to reduce spend. You only pay for what you use with features that deliver better visibility into usage and tools and services to optimize your costs along with purchase options such as Fargate Spot and Savings Plans with price performance of Graviton, which can save you up to 40% on your Lambda or Fargate workloads.

Let's turn back to that TCS study from Deloitte that I referenced earlier in September of this year, Deloitte conducted a study comparing services equivalents of self managed server technologies to determine their total cost of ownership. They looked at major cost components including infrastructure development and maintenance costs to look at the complete cost profile. They looked at different companies and different technologies as well including a transportation organization that was supporting Lambda, a health care organization and DynamoDB and a retirement wealth management organization with ECS Fargate.

What the finding of the studies was is that Fargate s monthly compute costs is 49% lower. Lambda's development costs are 68% cheaper, an ongoing service maintenance effort saved between 45% and 80%. The key takeaway from the study is that when accounting for development and maintenance costs, it is significantly cheaper to run applications through services such as Lambda, DynamoDB or ECS Fargate.

We continue to innovate to ensure that you have all the knobs to optimize costs. And earlier this week, we launched new features for AWS Cost Explorer."

this gives you even more visibility into your applications. it enables you to enhance your cost and usage analysis using multi year and data at the resource id level. and it also gives you a view of your lambda costs at the function level for up to 14 days.

it is providing both control and convenience in managing your costs and optimizing your spend. we believe that with the capabilities of serverless and its key pillars of agility, performance, security and reduced tco, you're empowered to build your applications for the future.

its applications range from legacy applications that you're modernizing by moving your on premise application to ecs fargate without much refactoring to quickly responding to event driven and web applications with lambda to large scale data processing, batch or real time with lambda or ecs fargate based on your programming model preference.

and speaking of possibilities, gen a i is what many of us are thinking about today. we see the possibilities of bringing the power of serverless and its agility performance and cost benefits to building with gen a models to supercharge your applications because service applications can handle at scale increases in traffic, adapt to rapidly evolving models and integrate easily with other services. we see foundational models becoming integral event sources and points to serverless workflows and vice versa. that is servius becoming the application choice for building gen a i.

so a couple of quick examples, let's just take inference enrichment. this is made easy if your source files are in different formats and you want to organize them and make them searchable. you can take the files and use lambda to determine the type of files and then use amazon ml services such as textract or transcribe to convert them. you can then invoke foundational models to summarize these records and feed them back into a database. and the entire orchestration can happen with step functions. and the best part is that it is executed on demand with pay for use.

similarly for model tuning and data prep, you can use foundational models which are agnostic, but they are better if you train them with data and do dataset enrichment. so to enhance the performance, you need to prepare a domain specific data set and you can do that again with step functions and using either lambda or s fargate. but we think we can make that even easier for you.

we are pleased to announce that step functions now integrates with bedrock, step functions is our visual workflow service. like we were talking about orchestrates, workloads. and amazon bedrock is our fully managed service that offers a choice of high performing foundational models from leading providers like anthropic stability a i and amazon along with other gen a i capabilities.

with the new step functions integration with bedrock, you can add gen a i capabilities to your applications and other aws sur solutions step functions can orchestrate user defined interactions with foundational models in over 220 aw s services. and you're able to leverage step function workflow studio to get that great visual presentation.

so with that, i'd like to welcome james thack. thanks. so building for the future means having access to the very best gen a i capabilities, but also the best sas applications and having the ability to build quickly and using minimal code. and so i'm really excited to show you some of these features and step functions and how they come together.

so again, what i'll do is i'll use the the cuss video example from earlier. so when a video is uploaded from cus video, it arrives in an ss three bucket that sends an event to eventbridge and an eventbridge then triggers this workflow. the first thing that happens in this workflow is we use amazon transcribe, transcribe, looks at the whole video, listens to any speech that's in the video and then converts that to text.

now, once you've got this text, this is then passed down the workflow through various steps to reach the bottom where it goes to translate where it's converted to another language. and then the results are put into a dynamo db table.

now set functions today integrates with over 220 aws services and you can use those api s directly from your state transitions without the need for compute. but we're really happy at this re invent to say that we've integrated now with bedrock. so you can call bedrock directly from state transitions.

so i'm gonna modify this workflow to use this. i'm gonna take those transcriptions from each video and use this feature to create a one sentence summary to create titles for my videos. so to do this, i simply drag this to the bottom of the workflow as we saw earlier. then from the ui i can then configure the things that typically i would do through code.

so i'll give this a title to summarize video. and the next step is to select one of the many, many models that are available in bedrock. next, i'll set a prompt and in the prompt, i'm gonna embed that transcription. so i'm gonna tell it to uh shorten the transcription down to a one sentence summary.

now imagine this was a service that i was charging customers for. i can now use that http s endpoint integration to call a web hook in a payment gateway service. and now stripe is a provider. so i'm gonna use the stripe gateway to process this payment. so the first step to this is to figure out how much money i want to charge. so we need a lambda function. i'll drag that into this workflow. i just put it at the bottom of uh the very last state transition. and the purpose of this, it will work out the price which will change per workflow. so we can charge the customer. and again, i can just configure this in the u i.

now, once that's done, i can pull the stripe api directly into the bottom of the workflow. and again, this is something you can configure completely from the u i here. so in this, there's two steps to a stripe call, one is to one is to decide what the product is and what the price is. and the next is to create a payment page. so all i have to do is specify my authentication type using a connection a rn i can then in the request body, use that bedrock output as my service name and then take the output from the lambda function as the amount of money that i want to charge the customer. and that's all just specified in json in the rest of the ui i can put any other chain, any other uh definitions that typically i would configure using code.

now, once this is set up, there's a two step process where the next i have to then duplicate this step to then create the payment page. so i can then just select this and then duplicate that. and i'll rename the state name to create the payment page. and once that payment page is ready, this will then generate a url that then we can charge customers.

so i'll run that workflow. it goes through the translation transcription, all those steps and the output is a url. so i'll copy that to a browser. when i go to this browser, we'll see that the bedrock output is the item that i'm charging for. and the lambda function amount is what we're asking the customer to pay.

now. it'd be great in this workflow. if we get it to wait at this point, in case the work the payment doesn't go through or we want to capture details of the payment and in step functions, that's very easy to do. all i can do. all i do is drag a wait state into the workflow using a eventbridge. and then afterwards, i'll drag a, a dynamo db in there so i can capture the details of the payment.

now, the stripe eventbridge integration that's new to set this up. what i have to do is go to my stripe configuration page. now from here, what i can do is basically select, select which events going through stripe i want to send back to aws. so here i'm gonna select for all payment events to be routed back to the partner event bus in my eventbridge bus.

now, once that set up in stripe back in the vent bridge, i just create a rule. creating the rule, lets me route certain events to restart my workflow. so i'm gonna create this rule and call it charge succeeded. and i'll specify what type of event i want to capture. and i can select a generic stripe event and you'll see it builds an event pattern on the right hand side which is just j sum.

now, once this is in place and my rule is created that will then cause this to all be connected up so i can restart the workflow. and that now goes through the steps of processing that video, doing the transcription and translation, calling bedrock. and then we get to that payment page that we created in the second step.

if i take the url created by this second step, i'm going to then paste that back in the browser where i can simulate a payment using test card data. now, once the stripe platform then processes this payment, it'll send an event back to my partner event buss and eventbridge. and when that, then it activates the rule that we created that will cause this workflow to continue and we then capture the details back in that very final step with the dynamo db integration.

and so we've done some really extraordinary things here. just by using step functions, it gives us really extraordinary power with writing very little code. you've seen this direct gen a i integration using bedrock. we can integrate with third party payment gateways or really any web hook over http s. but now stripe is partners that gives us a robust way to process payments. and it also enables us to build very highly scalable workflows with very minimal code.

if you're interested in learning more about the stripe integration, please take a look at the url which is eventbridge dot stripe dot dev. thank you very much.

thank you, james. i love seeing how that all was pulled together. so many things that we talked about today. i know we're only scratching the surface with that demo, but you can see the possibilities and it's not surprising that nearly 85% of enterprises are using or are planning to use servius within the next two years. according to the recent 2023 vanguard report, some of the largest companies in the world use aws services solutions including bosch, vanguard life, omic and pga tour.

we measure our success by the success of our customers and their use in innovating and transforming their business just like what grant and nationwide children's have been able to do and the momentum is strong just to show you the adoption lambda has over a million active customers driving over 10 trillion. that's what the t requests every month. and ecs is launching over 2.25 billion tasks every week.

and while these numbers are phenomenal, we are most excited about the things that are yet to come to help make customers you here able to innovate faster. i spoke about some of our most recent launches and the capabilities and we continue to invest across key areas, developer experience so that you're able to build faster and faster and do less controls over how the services run. like the scale up that you saw integration with aws capabilities where it makes sense more than 220 services and improving on the well architected fundamentals of performance, security resiliency and cost.

it's inspiring to see that you've prioritized your time and spent it with us today and i can't wait to see what you're going to continue to do. i hope this has been an educational session for you and i encourage you to keep learning. thank you and enjoy your re invent.