Construct your constructs: Use AWS CDK to create architecture at scale

all right, welcome everyone to buy with prime 302. if you're in the wrong session, don't worry. it's happened to me before there are doors that work. uh we are excited to share with you how buy with prime has leveraged aws cd k to deploy our architecture at scale.

my name is steven. this is jd and mud of and you all are here to really understand how your organization can leverage aws cd k to save time, reduce repetitive architecture decisions and three increase developer confidence as you're deploying new systems, we're really excited to share with you today. we're honored that you spend time with us. uh let's get into it.

so first, just giving us a road map of where we're gonna journey with today.

first, i'll give an intro into what buy with prime is how the landscape of buy with prime necessitated that we use aws cd k. so we can understand from a business perspective how cd k would then impact us, then jd will come on stage and he'll be able to tell us a little bit more about, hey, here's how cd k actually was working inside of buy with prime including examples of pipelines, how we deployed services with it. and we'll look at some architecture diagrams and finally mud will come on stage and we'll dive a bit deeper another layer deeper into some code snippets and some construct examples. and hopefully give you the tools that you need to be able to do the same in your organization.

and at that theme, we also have prepared a github repository that will be widely available browseable at the end of the session. so be on the lookout for a qr code there. and we're really excited also, finally, the conclusion, hopefully, we're hoping that there will be some q and a time. uh and if there isn't, if we run out of time, we'll meet you at the outside and be able to talk and we'll, we'll get to know you all.

so without further ado, let's introduce by with prime.

so buy with prime allows millions of prime members to shop at merchant stores with the same trusted experience that shoppers have come to expect from amazon. and merchants can add, buy with prime to their store directly to the product detail page by adding a javascript code snippet. and that allows for this button and the delivery estimate to be displayed directly on the page or for shopify merchants. they can also install the shopify app on the marketplace for more advanced integrations.

we're offering a no, a growing number of api s and events to really help merchants understand or be able to be flexible with the architecture decisions we know in the ecommerce landscape, many different merchants have different use cases, different architecture decisions, legacy decisions, tech debt, all these things and buy with prime. really wants to meet our customers merchants where they are to that note, we are really excited to share how a composable architecture has allowed for these really interesting integrations.

so only do we show the page or show the button and the delivery promise? it's not simply a checkout uh like a a fast checkout button. but we also have that post order experience that prime members know and love with the fast free delivery and easy returns. that's a game changer for merchants business where they can now offer the same prime benefits that prime members get on amazon. and at this note, buy with prime has been shown to increase shopper conversion by an average of 25% 25% for those of you in the ecommerce world. you know that conversion is a huge driver. and the merchants that have experienced that lift have been really happy. and we are really excited and encouraged by that number

in order to make all of this possible though, right, we have to have the delivery estimate, right? we have to create orders, we have to show and integrate with all these different systems. so that that creates a really interesting architecture landscape that we need to dive a bit deeper into.

so let's look into what might go behind this order screen.

so the first obvious service if we're thinking about services and at amazon, we are very cognizant of our service mesh frameworks. a first obvious one is order service, right? so an order service is very concerned with who bought what, when and what quantity and all of that it needs to be a state machine for that.

so for example, i met mike and he mentioned that they recently bought energy drinks, right? so if i'm mike, i buy an energy drink, an order gets created that says mike bought an energy drink at 134 on november 29th, right? so the order service needs to be really accurate with that type of information and store that shopper information in a really secure way.

but what good is an order if we don't actually ship the thing, right? so buy with prime leverages, amazon's multichannel fulfillment service to ship orders and what that means is it's using the same amazon fulfillment network that you get when you, when you purchase something on amazon.com. and in order to show that little delivery date, right? it says get it by this time, there's a lot of complex calculations as you can imagine that would go into inventory where that item lives in the fulfillment center, right? all the core logic that goes behind showing that same thing on amazon.com by with prime had to build a custom integration on top of amazon services to be able to empower merchants to have that same delivery estimate on their site.

beyond that, we can't really do anything if we don't know what we're selling. so the product catalog needs to be flexible enough to be able to store energy drinks for mike, but also maybe shoes for me and they have very different size estimates or different product attributes. we need to be an incredibly flexible product catalog.

and finally, in the ecommerce space, you can't really get away from payments. so payments as some of you, i'm sure in the fintech world are aware is a very complex world where there's a lot of different players, payment processors, banks regulations, all of these fun things and buy with prime has to address that as well.

so these four areas, right? they're very different areas, order state machine, right? delivery date, we have to like calculate, find out where the thing is and how fast can we get that thing to the shopper and then not only that, but we have to do it quickly. so that on the product detail page, we are very confident in what we show, right? because we've like that's a critical part of the prime member experience is knowing when my stuff will get here.

and in order to do this, right, we as you may know, we follow the microservice idea that we create service boundaries around them so that the order service doesn't really have to care what kind of architecture the catalog has or what payment method, the shopper checked out with it, it its core model is the same regardless of other services. and we apply that to each one of these so that we can have a true separation of concerns.

and honestly, it's not just those for services, we have a lot more. uh here's just a sample size of other services that we have and we have even more on top of this uh powerpoints limitations dictate that i can't show you the full thing. uh but you know, you can imagine that it would get very complex, very quickly and again, not super technical, but there is a network between the services in order to empower an incredibly composable ecommerce architecture because again, we're going back to our merchants, our customers, we want to meet them where they are. and in order to do that, we have to be able to flex and change based on their requirements and say, oh, you know what this merchant really needs to be able to do why use case that we haven't thought about.

and i can imagine some of you in this audience also have that changing set of requirements to meet your customer's needs. and really aws cd k has empowered us to create the architecture that will be able to meet our customers where we are.

so now jd is going to come on stage and he'll walk us through an order example of an order service and how cd k was used to build, not only the service but the pipeline and the benefits that get that we get from going through all of those.

cool, thanks even.

all right. here we go. let's take a look at a sample order architecture and to be clear, this is just an example though, we do leverage many aws services shown here.

now, you've probably seen this architecture before, maybe when you're first starting out your career googling how to create a three tiered architecture or maybe even through a cloud guru. look, we've all been there before. i certainly have and to be honest, i'm still doing it.

so as steven mentioned, there are a lot of components and complexities when building a service like orders, each and every service, not just orders was designed thoughtfully by our engineering teams to ensure high availability, scalability, security and more. so that way your order does not come to my address as much as i wanted to.

now, that said, let's take a look into the to the our first uh layer of our architecture, our api layer a k a the front door in my lingo the entry to the club. in this entry, we got the best bouncers and security guards called waf and shield. we also got an amazing host named route 53. also in this layer we can set a vip list with access controls and protection for our api s.

now if your order request comes checks in and passes the vibe check unlike me here in vegas. well, welcome to the party, the compute layer like a club. this is your chance to meet and mingle with other people in our case services, talking to other services. you got catalog, talking to content, you got delivery, talking to fulfillment, you got payments over there on the dance floor, doing the cha ching.

now speaking of infrastructure, we use fargate simply because we can use containers, run containers without having to manage servers. see a wise manager named yuval once told me that friends do not let friends manage servers. ok?

so back to the club generally you have a certain task or job to do, right? and that's a fargate pun whether that's going to the dance floor to the bar or even talking to other people similar to our order request, that order request has a task due and whether that's to get a phone number, a delivery or an address from delivery service or credit card info from payments.

and now once we got that information, we have to store it which leaves our last layer. my favorite layer, the data layer where that information is stored and retrieved safely and securely. so we got dynamo r ds alas cash. and if you got a big buck aura, so nothing too fancy. here. i think we've all had our experiences with sql and no sequel queries. all right.

so back to the top, we need to ensure a well architected, yet decentralized order service. and again, it's not just for orders, all of our services will play by the same rules and will partake in fulfilling your order. however, engineering decisions and development does not stop there to ensure our service meets customer needs. we've built a robust pipeline for buy with prime.

now, for the nature of this presentation, we'll keep it simple and i'll guide you through the common stages in a pipeline. but if you're curious to know more about our pipelines for buy with prime, i recommend you check out our session that's happening later today at 4 p.m. 301. they got really cool stuff there and then you can share your learnings in happy hour. i think it's a win, win.

so back to it. let's dive into each stage starting with the source stage. our developer hub where developers live, breathe and be boop together to make magic happen where we merge, pull and push the key words that define our coding journey.

now, once our code gets finalized, we enter the build stage and no, we're not just adding muscles, but we're automating tests, downloading necessary tools, compiling and packaging. this is the powerhouse stage where we turn lines of code into a deployable service.

now, once our code clears the build stage, we enter the pre-production stage

This stage allows us to fine tune our application and ensure quality standards and really see how it performs. Really, it's a chance for us to make sure our service does not trip over its own code on opening night.

Finally, from concept to reality, the moment of truth, the production stage where all hard work innovation, dedication is presented countless of hours spent on system design infrastructure. The many slag pings at 12 a.m. denied code reviews and the many more merge requests. This is the moment where all hard work is paid off and our service goes live to users.

So that ends the pipeline section. Now let's hit the brakes and let's rewind. We start off by looking at a sample order architecture sharing the common core services and peeling back the layers. Then we zoomed into the beating heart of our operation, the pipeline sharing the common stages, stages as needed to deploy a service.

Now blending these two models, these well architected frameworks weave in essence, created a stellar service, no doubt about it. However, there is something missing here, something something very, very important and that's the actual doing and developing part of it.

See the magic happens when we roll up our sleeves and develop. Now cranking code for these two models is no walk in the park like i mentioned earlier, it takes time and commitment starting from opening up an id e writing code testing debugging countless of log info statements, maybe expensing some blue tint glasses, maybe having a midlife crisis or two or maybe having carpal tunnel fingers.

Guess what i'm trying to say is developing for these two models is no walk in the park. It takes time and it takes a whole village and it can get pretty complex. And typically our developers will use cd k to write infrastructure as code something we all know and love here as it offers ease of use with testing, pipeline integrations, flexibility and programming language. And if you like writing c# well, my hat's off to you and let's not talk about those cloud formation spacing, yaml errors. Nope, we're not gonna do that today in this lecture.

All right. So let me take a moment to pause and paint a picture. We have one dedicated service team in building the infrastructure and the pipeline for it. Now imagine having 100 or 1000 teams. This can get tricky, right? Imagine all that time that will be spent on building similar architecture. Imagine all that time that will be spent on onboarding, learning knowledge transfers.

See, as bible prime continued to grow, we needed a way to scale and rapidly deploy fast given we had so many existing services and are expanding new ones. We need to make sure that any infrastructure uh that we're that we're building could be reusable for other services and teams as well.

So check this, here's what we did given our developers knew their service best and rather pause teams from building services. Why don't we gather individuals from those service teams group them together to create a cross functional cd k team. This team of engineers, the dream team came from all different service backgrounds and they were responsible for collaborating and creating a repository filled with our cd k best practice constructs for buy with prime. And the impact has been huge, this repository, this maintained repository has been used across all different services and teams, it pretty much standardized the way we deploy any infrastructure, provisioning services and see the idea, the idea really allowed for our developers to focus on building great services and products without having to worry about building infrastructure.

So this strategy in fact, has saved us a total of 50 engineering years. Yeah, we said it. So keep that number and head and with that, i'll pass to our very own technical maestro, my technical brother madhav, who will take you through a gnarly deep dive regarding our cd k constructs. Take it away. mad, great, thanks jd.

So before we actually take a look at how this cross functional team created their strategy, let's actually dive deep into a few of the key cd k concepts that they used. Now, when we think of cd k, we automatically think of the aws construct library. Now, this library contains basic constructs that generally represent aws services and i'm sure as many of you all know, there are quite a few aws services, which i guess is why we have so many constructs here.

Now, while the library is a starting 0.1 of the key benefits is that it provides you the ability to create a composition of these services to create complex architectures and solve your needs. So examples of this can include network setups, database clusters or even that three tier architecture from earlier.

Now, constructs are generally divided into three distinct layers. Right now, we're gonna go into each of these layers and uh give a brief overview of what these are layer one are the constructs that are automatically generated from the cloud formation resource specification. These resources are tied to aws service, aws services and provide a 1 to 1 mapping for them.

Now, an example of this would be if you take a, let's say a vanilla s3 bucket right now, let's take that one step further. A layer two resource is what we refer to as a higher level service construct. Now, these constructs represent multiple different aws resources but still tied to one distinct aws service.

Now, these constructs also have various opinion, a defaults built in to essentially help your use case. Now, from our previous example, we have that vanilla s3 bucket in order to make it into a layer two construct, uh we can do this by adding in some of our defaults, right. So let's say that we add in encryption and access logging.

Now layer three constructs. Now these are abstractions that are created by three distinct sources. They can be either the aws construct library yourself and your private library or third parties from the community. Now, this is the level where you have abstractions created to solve unique problems.

So taking our s3 bucket from earlier, we can make that into a layer three construct by essentially making it a source for, let's say a cloud front distribution. Now, an organizational strategy is comprised of a combination of different layers all to solve your unique needs.

Now, at by with prime, we said that well, since defaults can provide the best practices and they can help enforce that. Why don't we actually use that to create a common repository for all of the aws constructs that we use and then have our enforced best practices in there.

Now, before we actually dive deep into some of these principles that the cd k team used, uh there are a few points that we want to highlight. The first is we're gonna be using the term opinionated defaults a lot, right? And we don't want you to be confused. So all this really means is that these were best practices that we considered here at by with prime. This does not mean that it has to be your best practice. Our goal here today is to show you buy with prime story and help you use this as a starting point to identify what your unique use cases are and what your organizational needs are using this. We hope that you can extend on this and build your own organizational strategy.

Now, the second point is that there's gonna be a lot of code in this session. So I'm praying y'all don't start seeing ones and zeros, but as much as for y'all's sake as mine, I'm gonna keep the pace a bit slow here.

Now, let's take a look at that service architecture from earlier, as jd had mentioned, there's quite a few reusable components here, right? So all of our different architectures, be it orders or payments, they can use many of these services uh commonly. Now let's dive into one of these constructs to see what it takes to build a custom construct. And in particular, let's start with j ds favorite the database layer in this case, amazon dymo db.

Now, when it comes to databases, i think we can all agree that there are a lot of different concerns that we need to address. Right? Well, luckily cd k provides us the ability to set a wide variety of defaults to our databases. Now, the ones that we specifically want to hone in on today are related to security and operation, no operations. So primarily because of how important these are to any organization.

So let's actually hone in on building and encryption. Now, i'm gonna start with an example of how you create a custom construct class for dynamo db. Now, in this example, we're going to be using typescript cd k is available for most of the common programming languages today including java, javascript python and many more. And now i know that there's a lot of you out here who are probably typescript gurus. I personally am a huge java fan and yes, I'm also talking about the coffee.

So as much as for y'all sake is mine, I'm just gonna keep the pace a bit slow here. Now, let's go ahead and define our construct class, right? This construct class is going to help us provision a dymo db table and it's gonna be used by any of our service teams from any service, be it, order payments, billing, so on and so forth.

So let's go ahead and take a dive into what this code is doing. The first thing that we need to do is import the aws cd k dymo db table construct. This is going to be the base that we use to build all of our other constructs and our custom construct class.

Now, once we have that we can go ahead and define our construct class. Now this construct class is going to extend the cd k construct and thereby allow us to use all of the defaults that we get from a to cd k. Once we have that we can go ahead and override the constructor method that way any service team that's using, this will be passing in an extension of the default dymo db defaults, right? And those are these dymo db properties that you see here.

Now, once we have that set of properties, we can then create another set of updated properties which will have all of our inbuilt best practices. Now, i wanna stop here and say that this is a layer one construct. What this means is that any service team that provisions an instance of this custom construct will create a dymo db table without any inbuilt defaults, right?

So some of you might be saying, well, what benefit does that actually provide me? You know, why don't i just use aws cd k for that? And you're right, in order to make this provide some form of a benefit, let's go ahead and convert this into a layer two construct. And in order to do that, we want to add in all of the custom logic in the constructor.

So as mentioned earlier, we're going to be focusing on billing mode and encryption. I know this looks like a lot of code, but don't worry all of this is available in the github repository. So we'll have the qr code at the end and we will be here for any questions.

So let's just start at the top and work our way down. Now, we allow service teams to pass in any of the defaults that uh cd k supports, right? And they should be able to choose what those default values should be

So in this case, we're taking the billing mode and encryption attributes and using those for a custom logic.

Let's start with billing right now. As By With Prime was uh building out our systems and testing, we wanted the ability to conserve and save money while also allowing us to scale out as needed as an organization. It just made a lot of sense to default the billing mode to pay per request or on demand mode.

That being said, we didn't want to block any of our service teams from using provision mode. Now, if their use case really required it, our perspective around provision mode was that we should set the min read and write capacity, but we should not take the max read and write capacity as we didn't want any of our customers to experience a service outage due to limited system resources.

Now, all that logic could be in line seven. But let's actually take a look at another example, right? Encryption.

Now for encryption, DymoDB uh uses AWS own keys which are owned by the DymoDB service. Now, while this provides encryption at rest, if a malicious actor actually gets access to the DynamoDB service, they do have access to the customer content, which for us was a big no.

Now, in order to deal with this, we actually prefer that we use the customer manage keys by default. All right. That said DymoDB also has this pretty nifty feature that if the encryption attribute is set to customer managed key, but none is provided, it'll automatically spin one up for you.

Now, KMS keys do result in additional costs as such. We again did not want to block our service teams from uh using another option instead, as Jay had mentioned earlier, we do have our pipeline set up and that allowed for us to flag any potentially unsafe configurations.

Now, using this, we then create our set of updated properties as mentioned earlier and use that to go ahead and create an instance of that DymoDB table. So this as it is is a layer to construct, right? Any service team that uses this will by default, have pay request or on demand mode, billing and customer manage keys.

So now, in addition, if we take a look at how uh they only have to provide the basic CDK defaults that they normally do for a regular uh CDK construct. So the other thing we want to hone in on is that all we need to do is create a custom instance of this. And by adding in the standardization, our security teams no longer have to worry about any of those default attributes that we've said. Instead, they only have to look at the attributes which have been updated by our service teams.

And now I want to pause there and take a second to reflect on that. How much time and cost savings would we have if this was applied to all of these constructs that you see here today? Right.

So let's actually go ahead and take a look at a layer three construct or in this case, AWS Fargate. Now Fargate is generally fronted by load balancers, be it an Application Load Balancer or Network Load Balancer? For our specific use case, we do use both. But today, we want to focus on Network Load Balancers and their integration with AWS Fargate. Specifically, we want to take a look at how um the Network Load Balancer integrates with Fargate. And we create a custom relay that ensures that any request that's passing through that Network Load Balancer is logged using Amazon CloudWatch.

Now creating a relay is a lot of code, right? And I mean as Steven's mentioned before, PowerPoint is probably not the greatest code visualization tool. So we're gonna go into a higher level pseudo code. And uh for the full example, we want you to go ahead and see the QR code at the end for a GitHub repository.

Now, in this example, uh we can see that a lot of what we do is similar to the DymoDB example or a layer two construct. We start by importing the basic ecs pattern from the AWS CDK. That's gonna be the base that we use to build all of our constructs and our defaults once we have that we go ahead and define our custom JLB relay. Now this is going to be a separate construct that we created specifically for integration with Fargate.

Finally, we go ahead and create our class, the Fargate cluster. This is going to extend the construct class and be a composition of a bunch of these resources that we're using to meet our needs.

Now, there isn't much difference when it comes to the process of adding in defaults here, right? We're going to define our constructor and override that we're gonna take in our default Fargate properties. And then we're gonna go ahead and in the constructor define our custom relay.

Now, once we have that we go ahead and set that on our updated properties with all of the other properties that the service team has passed in. And with that, we go ahead and initialize our uh cluster.

So now that is the end of the code section here. So, you know, I take a sigh of relief and uh while I have you, I just want to tell you a quick story.

All right. Now, when Amazon CloudWatch came out, our service teams were very excited to use this. Our cross functional CDK team came together and in the span of one week, they identified all the various configurations that we would want. They created a custom construct for this and integrate it with many of our construct classes, including the one we saw earlier, Fargate.

Now, when any service team needs to go and provision, an instance of this construct that process takes less than one day. Right. That's a cost savings of approximately six days. Right. Now, imagine if you scale this out to 10 teams, your cost savings are approximately two months.

Now, given the scale at which we do things here at Amazon, we estimate that we've saved over 50 years worth of development time using this model. And I know it sounds like a lot, but just think of all the different services we've talked about and how many different teams that are needed for all of these, right?

So we hope that with this method, uh your organizations will also be able to take advantage of this and have a similar time savings.

Now, as promised here is the QR code for the GitHub repository. It has many examples for a lot of our AWS constructs that we use as well as documentation to highlight what that is. So we hope that's going to help you on your process to create an organizational strategy.

Thank you. Shit. Wow, that's amazing. Thank you for clapping for me. Coming on stage. I really appreciate it. This was all me. Just kidding.

I will plug that repo though. Uh Mudo has done some great work there. There's some very specific examples that are not bound to the limits of PowerPoint text editing. Uh so I will definitely plug that. So it'll still be available. Don't worry, it's still there just to recap what we've talked about, right?

We talked about the intro to Buy With Prime, understood the ecommerce landscape. Uh saw the impact for merchants really exciting. Uh and then we went into exactly how we use AWS CDK both to deploy our architectures, but also our pipelines and then Mud have finally brought us home here with how to actually build our layer one or sorry, our layer three constructs to really capture all those savings.

Now, depending on your company size, you know, you might not achieve the same 50 years of experience. But again, I promise if you use these construct principles, you'll be able to save time either for yourself or for others, right? Reduce those duplicative or repetitive architecture decisions, you make them once we want we like these defaults and then you move on and then finally you increase developer confidence, right?

You have pipelines that someone else has built, right? As a service developer, I'm worried on how fast can I make my service? I don't really care about like the nitty gritty DynamoDB things. I'm sorry if the DynamoDB team is here. I love DynamoDB. Definitely a big fan, but I don't want to have to think about it every time I'm building a service. And so that that's a huge thing.

So now we are here at this section. Uh we'll, I'll plug some other sessions and then we'll get into the, the Q&A and I'll bring these guys back on.

Uh like we mentioned, there are other Buy With Prime sessions if you're interested. Uh there's actually, I guess it's happening in like 20 minutes. We will not be offended if you stand up and go. Uh but there's a uh example of launching a generative AI uh or sorry with Amazon Bedrock with against our Buy With Prime APIs kind of that again. Meet our customers where they are aspect definitely would recommend that please check the room number because I think they might be different. They switched them on us.

Uh and then again at 4pm today here in the MGM Grand. Uh we are diving the other, some other great SAs that Buy With Prime are diving into more about the pipelines and the concepts that go into making sure that everything is running smoothly for us.

If you're interested in doing business with, Buy With Prime, either as a merchant or as a partner, please go ahead and check out uh our interest list. Uh and I'll don't worry, I'll, I'll put that QR code back on the stage.