Screaming in the Cloud - Championing CDK While Accepting the Limits of AWS with Matthew Bonig

Episode Date: January 11, 2024

Matthew Bonig, Chief Cloud Architect at Defiance Digital, joins Corey on Screaming in the Cloud to discuss his experiences in CDK, why developers can’t be solely reliant on AI or coding tools to fill in the blanks, and his biggest grievances with AWS. Matthew gives an in-depth look at how and why CDK has been so influential for him, as well as the positive work that Defiance Digital is doing as a managed service provider. Corey and Matthew debate the need for AWS to focus on innovating instead of simply surviving off its existing customer base.About MatthewChief Cloud Architect at Defiance Digital. AWS DevTools Hero, co-author of The CDK Book, author of the Advanced CDK Course. All things CDK and Star Trek.Links Referenced:CDK Book: https://www.thecdkbook.com/cdk.dev: https://cdk.devTwitter: https://twitter.com/mattbonigLinkedIn: https://www.linkedin.com/in/matthewbonig/Personal website: https://matthewbonig.comduckbillgroup.com: https://duckbillgroup.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn.

And I'm back with my first recording that was conducted post-reinvent and all of its attendant glory and nonsense. We might talk a little bit about what happened at the show, but my guest today is the chief cloud architect at Defiance Digital, Matthew Bonnig. Matthew, thank you for joining me. Thank you, Corey. Thanks for having me today. So you are deep into the CDK. You're one of the AWS DevTools heroes, and you're the co-author of the CDK book. You've done a lot, really. You have a course now for advanced CDK work. Honestly, at this point, it starts to feel like when I say the CDK is a cult,

you're one of the cult leaders, or at least very high up in the cult. Yes, it was something that I discovered. Your robe has a fringe on it. Yeah, yeah. I discovered this at reInvent and it kind of hit me a little surprised that I got

called out by a couple people by being the CDK guy, and I didn't realize I'd hit that status yet, so I got to get myself a hat and a cloak and maybe some fun stuff to wear. For me, what I saw, and it was in the run-up to reInvent, but the big CDK-sized announcement was the fact that the new version of Amplify now is much closer tied to the CDK than it was in previous incarnations, which is great. It sort of solves the problem. How do I build a thing through a variety of different tools? Great. And how do I manage that thing programmatically? It seems, according to what it says on the tin, that it narrows that gap. Of course, here in reality, I haven't had time to

pick anything like that up, and I won't for months just because so much comes out all at the same time. What happened to the CDK world? What did I miss? What's exciting? Well, you know, the CDK world has been, I said, fairly mature for a while now. You know, fundamentally, the way the CDK works and the functionality within it hasn't changed drastically. Even when 2.0 came out a couple of years ago, there wasn't a drastic fundamental change in the way that the API worked. Really, the efforts that we've been seeing for the last year or so, and especially the last few months, is trying to button up some functionality, hit some of those edge cases that have been rough for some users, and ultimately just continue to fill out things like L2 constructs

and maybe try to build out some L3s. I think what they're doing with Amplify is a good sign that they are trying to sort of reach across the aisle and work with other frameworks and work with other systems within AWS to make the experience better. Shows their commitment to the CDK of making it really the first class citizen for doing IAC work in AWS. I think that that is a, that's a long road. And it's also a lot of work that's under the hood. That's not easily appreciated. You've

remarked at one point that my talk at the CDK community day was illuminating if nothing else, if for no other reason than I dressed up as a legitimate actual cultist in a robe to give the talk because I have deep-seated emotional problems. But it was fun. It talked a bit about my journey with it, where originally I viewed it as more or less this thing that was not for me. And a large part of that is because I come from a world of sysadmin ops types where I don't really know how to code was sort of my approach to this.

Because I had that reaffirmed every time I talked to a developer. Like, you call this a bash script? It's terrible. And sure, but it worked. And it tied into a different knowledge set. Then when I encountered the CDK for the first time, I tried to use it in Python, which at the time was not really well supported and led to unfortunate outcomes. I do not know if that's still the case. What got me into it in seriousness was when I tried it a few months later with TypeScript, and that started to work a little bit more clearly with the caveat that I did not know JavaScript. I did not know TypeScript.

I had to learn it as I went in service to the CDK. And it works really well insofar as it scratched an itch that I had. There's a whole class of problem that I don't have to deal with, which include getting someone who isn't me involved in some of that code base or working in environments where you have either a mono repo or a crap ton of tiny repos scattered everywhere and collaborating with other people i cannot speak authoritatively to any of that i will say it's incredibly annoying when i'm trying to update something written in the cdk and then i haven't touched it in a year and a half and the first thing i have to do is upgrade a whole bunch of dependencies clear half a day just to get the warnings to clear before I can go ahead

and deploy the things, let alone implement the tiny change I'm logging into the thing to fix. Oh yeah, yes. Yeah, the dependency updates are probably one of the most infuriating things about any Node.js system. And I don't think that I've ever run across any application project framework, anything in which doing dependency upgrades wasn't a nightmare. And I think it's because the Node.js community, more so than I've seen any other, doesn't care about semantic versioning. And unfortunately, the CDK doesn't technically care about semantic versioning either, which makes it very tricky to do upgrades properly. There also seems to be the additional problem layered on top which is all of the various

documentation sources that i stumble upon the official documentation not terrific at giving real world use case it feels like it's trying to read the dictionary to learn how english works not really its purpose so i find a bunch of blog posts and all of them tend to approach this ecosystem slightly differently one talks about about using NPM, another talks about YARN. If you're doing anything that involves a web app, it seems to be increasingly common. Some will say, oh, use Webrick. Others will recommend using Vite. There's the whole JavaScript framework wars, and the only unifying best practice seems to be, oh, there's another way to do it that you should be using

instead of the way you currently are on. And if you listen to that, you wind up in hell. Oh, horribly so. Yeah. The split in the ecosystem between NPM and Yarn, I think, has been incredibly detrimental to the overall comfort level in Node.js development. I was an NPM guy for many, many years, and then actually the CDK got me more using Yarn simply because Yarn handles cross-library dependency resolution, a bit different from NPM, and I just ran into fewer errors and fewer problems if I use Yarn along the way. But NPM then came a long way since then. Now there's also PNPM, which is good if you're using monorepos. But then if you're going to be using monorepos,

there's another 15 tools out there that you can use for those sorts of things. And ultimately, I think it's going to be what is the thing that causes you the least amount of problems when dealing with them. And every single dependency issue that I've ever run into when upgrading any project, whether it be a web application, a backend API, or the CDK, it's always unique enough that there isn't a one-size-fits-all answer to solving those problems.

The most recent experience I had with the CDK, since you're basically Mr. CDK at this point, whether you want to be or not, and this is what I do instead of filing issues anywhere or asking for help. I drag people onto this show and then basically assault them with my weird use cases. I'm in the process of building something out in the service of shitposting, because that is my nature. And I decided, oh, there's a new thing called the Dynamo Table V2, which is great.

I looked into it. The big difference is that it addresses it from the beginning as a global table. There's a new thing called the Dynamo Table V2, which is great. I looked into it. The big difference is that it addresses it from the beginning as a global table, so you have optionality. Cool. Trying to migrate something that is existing from a Dynamo Table to a Dynamo V2 table started throwing CloudFormation issues, so my answer was, because this was pre-production, just tear down the stack and rebuild it. That feels like that would be a problem.

This had been something that was actually full of data at this point. There's a couple of ways that you could maybe go about it. Now, this is a very special case that you mentioned because you're talking about fundamentally changing the CloudFormation resource that you are creating. So of course, the CDK being an abstraction layer over top of CloudFormation and the Dynamo table V2 using the global table resource rather than just the table resource. If you had a case where you're having to do that migration, and I've actually got a client right now who's very much looking to do that, the process would probably be to orphan the existing table so that you can retain

the data and then using an import routine with CloudFormation to bring that in under the new resource. I haven't tried it yet. In this case, the table was empty, so it was easy enough to just destroy and then recreate. But it meant that also to tear down and recreate everything else in the stack as well, including CloudFront distributions, ACM certificates. So it took 20 minutes. Yes. And that is one of the reasons why I often will stick any sort of stateful resource into their own stack so that if I have to go through an operation like this, I know that I'm not going to be modifying things that are very painful to drop and recreate like cloud front distributions which can take a

half an hour or more to to re-initialize yeah so that was fun the problem got sorted out but it was still a bit challenging i feel like at some level the cdk is hobbled by the fact that under the hood it really just is just cloud formation once all is said and done and cloud formation has never been the speediest thing. I didn't understand that until I started playing with Terraform and I saw how much more quickly it could provision things just by calling the service APIs directly. It sort of raises the question of what the hell

the CloudFormation service is doing when it takes five times longer to do effectively the same thing. Yeah, and the big thing that I appreciate about Terraform versus CloudFormation, speed being the kind of the big win, is the fact that Terraform doesn't obfuscate or hide state from you. If you absolutely need to, you can go in and change that state that relates your Terraform definitions to the backend resources. You can't do that with

CloudFormation. So CloudFormation did release a few years ago that import routine, and that was pretty good. Not great, but pretty good. It's getting better all the time. Whereas this was a complete unneeded feature with Terraform, because if it came down to the point where you already had a resource and you just wanted to tie it to your IAC, you just edit a state file and they've got their import routines and tie-in routines as well. But having that underlying state exposed was a big advantage in my mind to Terraform that I missed going to CloudFormation and still to this day frustrates me that I can't do that underlying state change. It becomes painful and challenging, for better or worse.

Yep. But yeah, that was what I ran into. Things have improved, though. When I Google various topics, I find that the V2 documentation comes up instead of the V1. That was maddening for a little while. I find that there are still things that annoy me, but they become less all the time,

partially because I feel like I'm getting better at knowing how to search for them, and also because I think I'm becoming broken in the right ways that the CDK tends to expect. Oh, like how? Oh, easy example here. I was recently trying to get something set up and running, and I don't know why this is the case. I don't know if it holds true in other programming languages, but I'm getting more used to the fact that there are two files in TypeScript land that run a project. One is generally small in a side directory that no one cares about.

I think it's in the lib or the bin subdirectory. I don't remember which because I don't care. And then there are things you have to do within the other equivalent that basically reference each other. And I've gotten better at understanding that those aren't one file, for example. Though they seem to sure be a lot in all the demos,

but it's not how the init process when you're starting something new spins up. Yeah, this is the hell of TypeScript. The fact that Node.js as a runtime cannot process TypeScript files. So you always have to pass them through a compiler. This is actually one of the things that I like about using Progen for all of my projects instead of using CDK and NIT to start

them, is that those baseline configurations handle the TypeScript nature of the runtime, I should say the anti-TypeScript nature of the runtime a little bit better, and you run into fewer problems. You never have to worry about necessarily doing build routines or other things because they actually use the ts-node runtime to handle your CDK files instead of the node runtime. And I think that's a big benefit in terms of the developer experience. It just makes it so I generally never have to care about those JavaScript files that get compiled from TypeScript in the two years or so I've been using Progen. I never have to worry about a build routine to turn that into JavaScript. And that makes the developer experience significantly better.

Yeah, I still miss an awful lot of things that I feel like I should be understanding. I've never touched Progen, for example. It's on my backlog of things to look into. Highly recommend it yeah i also am still in that area of my word typescript knowledge has not yet gotten to a point where i see the value of it it feels like i've spent far more time fighting with the arbitrary restrictions that are typescript then it has saved me from typing errors in anything that I've built. I believe it has to come back around at some point of familiarity with the language, but I'm not there

yet. Gotcha. So Python developer before this? Ish, mostly brute force and enthusiasm, but yeah, Python. Python, and I think you said Bash scripting and other things that have no inherent typing built into it. Right. Yeah, that is a problem I think that I thankfully avoided. I was an application developer for many years. My background and my experience has always been around strongly typed languages. So when it came to adopting the CDK, everything felt very natural to me. But as I've worked with people over the years, both internally at Defiance, as well as people in the community that don't have a background in that, I've been exposed to how problematic TypeScript as a language truly can be for someone who's never had this experience of,

I've got this thing and it has a well-defined shape to it. And if I don't respect that, then I'm going to bang my head against these weird errors that are hard to comprehend and hard to grok way more than it feels like I'm getting value from it. There's also a lack of understanding around how to structure projects, in my case, where, all right, I have a front end and I have a back end. Is this all within the context of the CDK project? And this, of course, also presupposes that everything I'm doing is effectively Greenfield, in which case, great, do I use the front end wizard,

a tutorial thing that I'm following? And how does that integrate when I'm using the CDK to deploy it somewhere? And so on and so forth. It's stuff that makes sense once you have angry and loud enough opinions, but I don't yet. Yeah, so the key thing that I tell people about project structure, because it does often come up a lot, is that ultimately the CDK itself doesn't really care how you structure things. So how you structure, where you put certain files, how you organize

them is your personal preference. Now, there are some exceptions to that when it comes to things like Lambda functions that you're building or Docker files, there are probably some better practices you can go through, but it's actually more dependent on those systems rather than the CDK directly itself. So I go through in the advanced CDK course, you know, my basic starting directory structure for everything, which is stacks, constructs, apps, and stages all go into their own specific directories. But then once those directories start growing, because I've added more stacks, more constructs and things, once I get to around five to maybe seven files in a directory, then I look at them and go, okay, how can I group these together?

I create subdirectories. I move those files around. My development tool of choice, which is WebStorm, JetBrains' long running tool, handles the moving of those files for me. So all of my imports, all my references automatically get updated accordingly, which is really nice. And I can refactor things as much as I want to without too much of a problem. So as a project grows over time, my directory structure can change to make sure that it's readable, well-organized and understandable.

And it's never been too much of a problem. Yeah, it's one of those things that does take some getting used to. It helps, I think, having a mentor of sorts to take you under their wing and explain these things to you. But that's a hard thing to scale as well. So in the absence of that, we wind up defaulting to, oh, whatever the most recent blog post we read is. Yeah, and I think one of the truest, I think, and truthful complaints I've heard about the CDK and why it can be fundamentally very difficult is that it has no guardrails. It is a general purpose language. And general purpose languages don't have guardrails. They don't want to be in the way of you building whatever you need to build. But when it comes to an infrastructure as code project, which is inherently very different from an API or a website or other sort of more typical programming projects, having guardrail or not having guardrails is a bad thing and it can really lead you down some bad paths. I remember working with a client this

last year who had leveraged context instead of properties on classes to hand configuration value down through code, down through stacks and constructs, things like that. And it worked. It functionally got them what they needed up until a point. And then all of a sudden they were like, well, now we want to do X with the CDK and we simply cannot because we've now painted ourselves into a corner. And that's the downside of not having these good guardrails. And I think that early, they needed to do this early on when the CDK was initially released and got popular back around the 0.4, 0.5 timeframe, I think I picked it up right around 0.42. When it officially hit a 1.0

release, there should have been a better set of guidelines and best practices published. You can go to the documents and see them and they have them published, but it really didn't go far enough to really explain how and why you had to take these steps to make sure you didn't screw yourself six months later. It's one of those one-way doors you don't realize you're passing through when you first start building something. And I find, especially when you follow my development approach of more or less used to be copying and pasting from various places, now it's copying and pasting from one place,

which is Jippity 4. Then, although I'm seeing increasingly GitHub's Copilot has been great at this, and CodeWhisperer, in my experience, has not yet been worth the energy it takes to really go diving into it. Your mileage may, of course, vary on that. But I found it was not making materially better suggestions

on CDK stuff than Copilot was. Yeah, I haven't tried CodeWhawisper outside of the shell. I've been using Copilot for the last year and absolutely adore it. I think it has completely changed the way that I felt about coding. I saw writing code for the last couple of years being very tedious and very boring in terms of there weren't as interesting problems to solve and copilot as I've seen it is auto-complete on steroids. So it doesn't keep me from having to solve the interesting problems. It just keeps me from having to type out the boring solutions. And I, that's the thing that I love about it. Now, hopefully code whisperer continues

to get better over time. I'm hoping all of Amazon's Gen AI products continue to get better over time and I can maybe ditch a subscription to Copilot. But for now, Copilot is still my thing and it's producing good enough results for me. Thankfully, because I've been working with it for four years now, I don't rely on it to answer my questions about how to use constructs. I go back to the docs for those if I need to. It occurs to me that I can talk about this now because this episode will not air until after this has become generally available. But what's really spanked it from my perspective has been Google's duet. And the key defining difference is I'm in one of these files.

In many cases, I'm doing something with React these days due to an escalating series of weird choices. My apologies, by the way. My condolences, I should say. Well, yeah. Well, things like Copilot Chat are great when they say, oh yeah, assuming that you're handling the state this way in your component. Now, what I love about Duet is it goes and it actually checks, which is awesome. And it has contextual awareness of the entire project, not just the three lines that I'm talking about or the file that I'm looking at at this moment. It goes ahead and does the intelligent thing of looking at some of these things. It still has some problems where it's confidently wrong about things it really shouldn't

be, but okay, early days. Sure. Yeah, I'll need to check that out a little bit more because I still to this day despise working with React. It is still my framework of choice because the ecosystem is so good around it and so established that I know that whatever problem I have, I'll find 14 blogs and maybe one of them is the answer that I want versus any other framework where it still feels so very new and so very immature that I will probably beat my head more than I want to. Web development now is a hobby, not a job. So I don't want to bang my head against a hobby project. I tend to view on some level that these AI coding assistants are good enough to get me

almost anywhere I need to go at the point where a beginner or enthusiastic amateur would be able to get sorted out. And for a lot of what I'm building, that's all I really need. I don't need this to be something that will withstand the rigors of production at a bank, for example. One challenge I have seen with all of these things is there's a delay in something being released and their training data growing to understand those things very often it'll wind up giving me recommendations for i forget the name of it but there was a state manager in react that the first thing you saw when you installed it was

this has been deprecated this is the new replacement and if you explicitly ask about the replacement it does the right thing but it just cheerfully goes ahead and tells you to use ancient stuff or apply poor security practices or the rest. Yeah, that's very scary to me, to be honest, because I think these AI development tools, for me, it's revitalized my interest in doing development. But where I get really, really scared is where they become a dependency in writing the right code. And every time I ever use Copilot to fill out stuff, I'm always double checking it. I'm always making sure that this is right or that is right. And what I worry about is those developers who are maybe still learning some things or are having to write inline SQL into their backend and let Copilot or CodeWhisper or whatever tool they pick fill this stuff out. And that answer is based on a solution that works for a 10,000 record database,

but fails horribly on a hundred million record database. And now all of a sudden you've got this problem that is just festering in through a dev environment, if through a QA environment, and even maybe into a prod environment. And you don't find out that failure until six months later, when some database table runs past its magical limit. And now all of a sudden you've got these queries that are failing, they're crashing databases, they're running into problems. And this developer that didn't really know what they built in the first place is now being asked, why doesn't your code work?

And they just sort of have to go, maybe ChatGPT can tell me why my code doesn't work. And that's the scariest part of me to these things, is that they're a little bit too good at answering difficult questions with a simple answer. There's no it depends with these answers. And there needs to be for a lot of what we do in complex systems that, for example, in the AWS world, we're expected to build complex systems. And ChatGPT and these other tools are bad. We're required to build complex systems.

And on some level, I would put that onus on Amazon in many respects. I mean, the challenge I keep smacking into is that they're building, giving you a bunch of components and expecting you to assemble them all yourself to achieve even relatively simple things. It increasingly feels like this is the direction that they want customers to go in because they're bad at moving up the stack and delivering integrated solutions themselves. Well, so I would wonder, what do you consider a relatively simple system then? Okay. One of the things I like to do is go out in the evenings and sometimes with a friend, I'll have a few too many beers and then I'll come up with an idea for, I want to redirect this random domain that I want to buy to someone else's website. The end. Now, if you go with Namecheap or GoDaddy or one of these various things,

you can set that up in their mobile app with a couple of clicks and a payment, and you're done. With AWS, you have a minimum of six different services you need to work with, many of which do not support anything on a mobile basis and don't talk to one another relatively well. I built a state machine out of Step Functions that will do a lot of it for me, but it's an example of having to touch so many different things just for a relatively straightforward solution space

that is a common problem. And that's a small example, but you see it across the board. Yeah, yeah. I was expecting you to come up with a little bit of a different answer for what a simple system is. For example, a website. Everyone likes to say, oh, a static website with just a different answer for what a simple system is. For example, a website. Everyone likes to say, oh, a static website with just raw HTML. That's a simple...

No, that's the hardest house because the devil's in the details and it slices you to ribbons whenever you go down that path. No, I'm talking things that a human being would do without needing to be an expert in getting that many different AWS services to talk to one another. Yeah, and I agree that AWS traditionally is very bad at moving up that stack and getting those things to work. You had mentioned at the very top of this about Amplify. Amplify is a system that I have tried once or twice, and I generally think that for the right use case is an excellent system. And I really like a lot of what it does. It is. I agree. Having gone down that building up my scavenger hunt app that I'll be open sourcing

at some point next year. Yeah. And, and it's fantastic, but it has a very steep cliff where you hit that point where all of a sudden you go, okay, I added this and I added this and I added this and I added this. And now I want to add this one other thing, but to do it now, all of a sudden you go, okay, I added this and I added this and I added this and I added this, and now I want to add this one other thing. But to do it, now all of a sudden I have to go through a tremendous amount of work. It wasn't just the simple push button that the previous four steps were. Now I have this one other thing that I need to do, and now it's a very difficult thing to incorporate into my system. And I'm having to learn all new stuff that I never had to care about before because Amplify made it way too easy. And I don't think this is necessarily an AWS problem. I think this is just a fundamentally difficult software problem to solve.

Microsoft, I spent years and years in the Microsoft world, and this was my biggest complaint about Microsoft was that they made extremely difficult things far too simple to solve. And then once those systems became either buggy, problematic, misconfigured, whatever you want to call it, once they stopped working for some reason, the people who were responsible for figuring those answers out didn't have the preceding knowledge because they didn't need it. And then also they go, well, I don't know how to solve this problem because I was told it was just this push button thing. So Amplify is great. And I think it's fantastic, but it is a very, very difficult problem to solve. Amazon has proven to be very,

very good at building the fundamentals. And I think that they function very well as a platform service, as a building blocks. But they give you the Lego pieces and they expect you to build the very complex Batmobile. And they can maybe give you some custom pieces here and there, like the fenders and the tires and stuff like that. But that's not their bread and butter. Well, even starting with the CDK is a perfect example. You can use the CDK and NIT to create a new project from scratch, which is awesome. I love the fact that that exists, but it doesn't go far enough. It doesn't automatically create a repo you store the thing in that in turn hooks up to a CICD process that'll wind up doing the build and deploy. Instead, it expects you to do that all locally, which is a counter pattern.

That's an anti-pattern that'll lead you down the wrong path. And you always have to build these things from scratch yourself as you keep going, at least that's what it feels like. Yeah, it is. And I think that here at Defiance Digital, our job as an MSP is to talk to the customer and figure out, but what are those very specific things you need? So we do build new CDK repos all the time for our customers, but some of our customers want a trunk-based system. Some of them want a branching or a development branch-based system. Some of them have a very complex SDLC process within a PR stage of code changes versus a slightly less complex one after things have been merged into trunk. So if we fundamentally look at it like we're that bridge between the two, and in that case,

AWS works great. In fact, all SaaS solutions are really nice because they give us those building blocks. And then we provide value by figuring out which one of those we need to incorporate in for our clients. But every single one of our clients is very different. And we've only got less than a dozen right now. But I've got project managers and directors always coming back to me and saying, well, how do we cookie cutter this process? And you can't do it. It's just very, very difficult. Not in a small scale. Maybe when you're really big and you're a company like AWS who has thousands, if not potentially millions of customers, you can find those patterns. But it is a very fundamentally difficult problem to solve. And we've seen multiple companies over the last two decades try to do these things and ultimately fail. So I don't necessarily blame AWS for not having these things or not doing a well. excellent experience for the user start to finish. There's Versailles does something very similar

over in the front end universe too, where there's, it is clearly possible, but it seems that designing user interfaces and integrating disparate things together is not an Amazon's DNA, which makes sense when you view the two pizza teams assembling to build larger things. But man, is that a frustration? Yeah. I really wonder if this two pizza team mentality can ever work well for products that are bigger than just the fundamental concepts. I think Amplify is pretty good, but if you really want something that is this service that works for 80% of customers, you can't do it with five people. You can't do it with six. You need to have teams like what GitHub and what Vercel and other things where teams of potentially dozens of people that really coordinate things and have a good project manager and product owner and understand the problem very

well. And it's just very difficult with these very, very small teams to get that going. I don't know what the future of AWS looks like. It feels like a very Microsoft in the mid 2000s, which is they're running off of their existing customers, they don't really have a need to innovate significantly because they have a lot of people locked in. They would be just fine for years on years on end with the products they have. So there isn't a huge driver for doing it. Not like maybe GCP or Azure really need to start to continue to innovate stronger in this space to pick up more customers. AWS doesn't have a problem getting customers.

And if there isn't a significant change in the mentality like what Microsoft saw at the end of the 2000s with getting rid of Balmer, bringing in Satya, and really changing the mentality inside the company. I don't see AWS breaking out from this anytime soon, but I think that's actually a good thing. I think AWS should stick to just building the fundamentals. And I think that they should rely on their partners and their third parties to bridge that gap. I think Jeremy Daly and Ampt and what they're building over there is a fantastic product. Yeah. The problem is that Amazon seems to be in denial about a lot of this, at least with what they're saying publicly. Yeah, but what they say publicly and how they feel internally could be very, very different.

I would say that we don't know what they're thinking internally, and that's fine. I don't necessarily need to. I think more specifically, we need to understand what the roadmap looks like and we need to understand what are they going to change in the future to maybe fill in some of these gaps. I would say that the problem you said earlier about being able to do a simple website redirect, I don't think that's Amazon's desire to build those things. I think there should be a third party that's built on top of AWS and maybe even works directly within your AWS account as a marketplace product for doing that. But I don't think unfolds, because a lot of customers want answers that require things to be assembled for them. I mean, honestly, a lot of the Gen AI stuff is squarely in that category. App Composer or Copilot or things where they try, and then because they don't get enough traction, just feels like they stall out and get stagnant. I mean, App Composer was a keynote product announcement during last year's reInvent. And this year, we saw them introduce the ability to do step function editing within it and introduce the functionality into your IDE VS Code directly. Both good things,

but a year's worth of development effort to release those two features feels slow to me. The integration to VS Code should have been simple. Yeah, they are not the innovative company that would turn around and deliver something incredible three months after something had launched. And here's a great new series of features around it. It feels like the pace of innovation and pace of delivery has massively slowed. Yeah, and that's the scariest thing for me. And we saw this a little bit with a discussion recently in the cdk.dev server, because if you take a look at what's been happening with the CDK

application for the last six months and even almost a year now, it feels like the pace of changes within the code base has slowed. There have been multiple releases over the course of the last year where the release at the end of the week, and they hit a pretty regular cadence of a release every week, that release at the end of the week fixes one bug or adds one small feature change to one construct in some library that maybe 10% of users are going to use. And that's troublesome. One of the main reasons why I ditched the Terraform and went hard on the CDK was that I looked at how many issues were open on the Terraform AWS provider and how many missing features were and how slow they were to incorporate those in and said, I can't invest another two years into this product if there isn't going to be that innovation. And I wasn't in a place to do the development work myself, despite the fact that you can,

because it's open source and providers are forkable. And the CDK is getting real close to that same spot right now. So this weekend, and I know this is going to come out, you know, weeks later, but, you know, the weekend of December 10th, they announced a change the way that they were going to take contributions

from the CDK community. And the long and short of it right now, and there's still some debate over exactly what they said, is we're not going to accept brand new L2 constructs from the community. Those have to be built internally by AWS only. That's a step in the wrong direction. I understand why they're taking that approach. Contributions in the CDK have been very rough for the last four or five months because of the previous policies they put into place. But this is an open source product. It's supposed to be an open source product. It's also a very complex set of code because of all of the various AWS services that

are being hit by it. This isn't just Amplify, which is hitting a couple of things here and there. This is potentially... It touches everything. It touches everything. I can see their perspective, but they've got to get way better at supporting things rapidly if they want to play that game. And they can't do that internally with AWS, not with a two-pizza team. No.

And there's an increasing philosophy I'm hearing from teams. My service supports it. Other stuff, that's not my area of responsibility. The wisdom that I've seen that really encapsulates this is written on Colm McCarthy's old laptopFormation hits, then the product feels stalled. There isn't a good initiative for users to continue trying to adopt it because over time, users are just going to hit more and more services in AWS, not fewer as they use the products. That's what AWS wants. They want people to be using VPC lattice and all the Gen AI stuff and Glue and SageMaker and all these things. But if you don't have those L2 constructs, then there's no advantage of the CDK over top of just raw cloud formation. So the step in the right direction, in my opinion, would have been to make it easier and better for outside contributions to get into the CDK.

And they went the opposite way. And that's scary. Now, they basically said, go build your own, go publish them on the construct hub, and if they're good, we'll incorporate them in. But they also didn't define what good was and what makes a good API. API development's very difficult. How do you build a construct that's going to hit 80% of use cases

and still give you an out for those other 20 you missed? That's fundamentally hard. It is. And I don't know if there are good answers yet. Maybe they're going in the right direction. Maybe they're not. Time will tell. My hope is that I can try to do some videos here after the new year to try to maybe make

this a better experience for people. What does good API design look like? What is it like to implement these things well so they can be incorporated in? There has been a lot of pushback already just after the first couple of days from some very vocal users within the CDK community saying, this is bad. This is fundamentally a bad step. Even from big fan boys like myself who have supported the CDK, who co-authored the CDK book, and they said, this is not good. So we'll see what happens. Maybe they change direction after a couple of days. Maybe this is at times turns out to be a great way to do it. Only time will really tell at this point. Awesome. And where can people go to find out more as you continue

your exploration in this space and find out what you're up to in general? So I do have a Twitter account at Matt Bonnig on Twitter. However, I am probably going to be doing less and less over there. Engagement and the community as a whole over there has been problematic for a while. And I'll probably be doing more on LinkedIn. So you can find me there. Just search for Matthew Bonnig. It's a very unique name. I've also got a website, MatthewBonnig.com. And from there, you can see blog articles and a link to my advanced CDK course, which I'm going to continue adding sessions to over the course of the next few months. I've got one coming out shortly about the deadly embrace

and how you can work through that problem with the deadly embrace and hopefully not be so scared about multi-stack applications. I look forward to that because Lord knows I'm running into that one myself increasingly frequently. Well, good. I will hopefully be able to get this video out and solve all of your problems very easily. Awesome. Thank you so much for taking the time to speak with me. I appreciate it. Thank you for having me. I really appreciate it. Matthew Bonnig, Chief Cloud Architect at Defiance Digital, AWS DevTools Hero, and also much more. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud.

If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that you will then have to wind up building the implementation for that constructs that power that comment yourself, because apparently we're not allowed to build them globally anymore. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS.

We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.