Episode 12: CDK for Terraform and two pizza teams
Published: Tuesday, Dec 16, 2025 • Duration: 61 minutes • Season 1
Download MP3 | Watch on YouTube
https://github.com/hashicorp/terraform-cdk/commit/a0c56138e2b4c7b6c128bd7ba08a8e317df852af
Trying to plot the changing Infrastructure landscape.
summarize "https://youtu.be/rM2pj0JKc0g" --timestamps --slides
This discussion explores the volatile state of the Infrastructure as Code (IaC) ecosystem following IBM’s acquisition of HashiCorp and the subsequent sunsetting of the CDK for Terraform (CDKTF). The speakers analyze the technical and organizational shifts driving developers away from traditional configuration-based tools toward programmatic frameworks like Pulumi and AWS CDK. They examine the trade-offs between developer experience and operational control, the rise of platform engineering, and how modern “two-pizza teams” are redefining the boundary between application code and infrastructure.
The Fall of CDKTF and the Rise of Alternatives
The conversation begins with the news that IBM decided to sunset CDKTF, a project that was a collaboration between AWS and HashiCorp. The speakers note that the repository had been neglected for some time, remaining pinned to Terraform version 1.6 while the main project advanced to version 1.13. This lack of maintenance occurred despite the project being positioned as a way to bring the benefits of the AWS Cloud Development Kit (CDK) to the broader Terraform ecosystem. The sunsetting event triggered significant reactions on platforms like Reddit and Hacker News, where many users expressed that the tool was “half-baked” or simply not being used. Pulumi is identified as a primary beneficiary of this fallout, having launched years earlier with a more mature programmatic approach to infrastructure. The speakers suggest that for those still tied to the Terraform ecosystem, the move toward OpenTofu is becoming increasingly logical following HashiCorp’s shift to the Business Source License (BSL). Terraform Hashikorp language is a horrible way for developers to manage their infrastructure. This sentiment reflects a growing frustration with the limitations of HCL (HashiCorp Configuration Language) for product engineers who prefer familiar programming languages.
Pulumi and the Open Source IaC Landscape
Pulumi is highlighted as a strong alternative that supports a wide array of languages, including TypeScript, Python, Go, and even YAML. Unlike HashiCorp’s recent licensing changes, Pulumi’s source code remains Apache 2 licensed, allowing it to position itself as the “real” open-source option for infrastructure. A key advantage of Pulumi is its ability to interact directly with Terraform backends, allowing organizations to run both tools side-by-side during a migration rather than requiring a total rewrite. The speakers also discuss SST (Serverless Stack), which originally built abstractions on top of AWS CDK but has recently pivoted to use Pulumi as its engine. This shift is significant because it moves away from the “all or nothing” database-transaction style of CloudFormation, which can often get stuck during rollbacks. Pulumi and Terraform offer more granular control over state refactoring, which is essential for large-scale enterprise environments. While Pulumi offers a free open-source tier, its commercial model involves a managed cloud UI for state and orchestration, similar to Terraform Cloud.
Defining Developer Experience in Platform Engineering
The speakers attempt to map various tools on a scale of Developer Experience (DevX) versus operational features. They define the role of a platform engineer as providing tools that allow developers to take full ownership of their services in production. High-DevX tools like Vercel, Netlify, and Fly.io are praised for their simplicity, often requiring only a CLI and a basic configuration file. However, these tools often lack the “operational depth” required for complex infrastructure, such as fine-grained control over database bootstrapping or networking. AWS CDK is placed high on the DevX scale but lower on operational flexibility because it is backed by CloudFormation, which can lose track of resources if logical IDs change. The speakers argue that a good developer experience is not just about ease of use, but about the “agility” it provides to a team. They note that many organizations struggle with “click-ops,” where developers manually configure resources in the AWS console because the IaC tools are too convoluted to use effectively.
The Complexity of Low-Level Resource Management
A major criticism of Terraform is that it forces developers to manage every single low-level API resource, such as IAM roles, trust policies, and security group rules, just to connect a simple Lambda function to an API Gateway. This “low-level” perspective is a barrier for product engineers who want to focus on application logic rather than infrastructure plumbing. The speakers discuss the varying quality of Terraform providers, citing the Snowflake provider as an example of a tool that can be “experimental” and prone to recreating resources unexpectedly. They describe the “nightmare” of trying to manage everything through Terraform, such as running SQL queries to configure database extensions, which requires complex networking tunnels and security compliance measures. Some argue that IaC should be reserved for stable, long-lived resources like databases, while more dynamic application components should be handled by higher-level abstractions. The lack of automated testing in many Terraform setups further complicates long-term maintenance, leading to “complex interfaces” that are difficult to refactor after a year or two of development.
Strategic Infrastructure Mapping for the Enterprise
When considering how a CTO should manage hundreds of AWS accounts, the speakers weigh the benefits of Pulumi, SST, and AWS CDK. Pulumi is noted for its “on-event” hooks, which allow for dynamic logic during deployment—such as automatically adjusting configurations based on the number of availability zones in a specific region. This is contrasted with Terraform’s deterministic, static nature. AWS CDK uses “context providers” to achieve a similar effect, querying the environment during the synthesis phase and storing the results in a cdk.context.json file to ensure builds remain deterministic when checked into version control. The speakers discuss the “Two-Pizza Team” model used at AWS, where the team responsible for the product also handles observability, paging alerts, and reliability. In this model, the separation between “infrastructure” and “code” disappears. For organizations with strict silos—where security teams own IAM and networking teams own VPCs—adopting these integrated programmatic tools can be challenging, as they require a platform team that understands object-oriented programming and software testing rather than just system administration.
Integrated Deployments and the Construct Hub
The final segment focuses on the “Construct Hub,” a registry for AWS CDK, CDKTF, and Projen constructs that allows teams to share high-level integration patterns. Unlike the Terraform Module Registry, which is often limited to HCL, the Construct Hub supports multiple programming languages and leverages native package managers like NPM and PyPI. The speakers highlight the “Construct Hub” itself as a prime example of a mature serverless application built by a two-pizza team, featuring automated failovers and detailed runbooks. They argue that the traditional separation of infrastructure and application code is fundamentally “wrong” for modern DevOps. The whole deployment process belongs to the product team not to the infrastructure team. This integrated approach is facilitated by the AWS CDK asset pipeline, which bundles application code (like Docker images or Lambda zip files) directly with the infrastructure definition. While some criticize this for making deployments dependent on local build environments or rate limits, the speakers view it as a vital feature for developer autonomy. The discussion concludes with a look toward the future, where AI might assist in governing these complex environments by guiding LLMs with organizational rules and “sandboxes” to prevent rampant, unmanaged resource creation.
Model: google/gemini-3-flash-preview
Transcript (auto-generated from YouTube captions)
You see the little voodoo mask over there where I pray. I do my silent prayers and curse the forces of the day at Hashi Corp. >> Yeah. So that CDKF thing uh got you activated. So did you what did you do after hearing that news? Cuz I thought that project I I was I I think we discussed this project. No one was using it. I mean, or what was my impression? >> Triggered. Triggered. >> Triggered. >> He's pushing buttons, right? This guy woke up fresh. I don't know what I don't know what you want to, you know, get off before we start. >> Okay. So, anyone who's not aware, um, and this is my version of the story, right? My my my side of the story. Um when I woke up on Thursday last week um IBM has decided to sunset CDKTF even though that the week before that they were all there with and um with all the people from AWS and if you don't if you're not aware CDKTF kind of collaboration between AWS and Hashi Corp because CDK is is um is an AWS uh toolkit cloud development toolkit and only really successful for AWS cloud itself with AWS CDK there is some CDK TF for Azure but you know there's bicep and and Google I think they they try to use config um what's it config manager or config connect it's like crossplane or um based kubernetes based um so yeah it was sunset to be honest I have been trying to fork the repository and nobody did anything the repository had not received any love or any updates. It was still pinned to version 1.6 of Terraform and I think they released 1.13 lately. >> Uh most of the features that came to Terraform since 1.7 and I think 1.7 is when the whole BSL fork happened uh I think with 1.8. >> So ever since then >> you might as well go open tofu right at this point. >> Absolutely. So, so the the m so after the sunset event um which was posted on Reddit and hacker news and on LinkedIn uh most of the comments on on Reddit terraform obviously was nobody's using it right uh no let it die right hate those people why would people say that right and and then >> several of course Puli jumped on the opportunity it's like yeah CDKF is like two years younger than Pulumi so Pulumi came out first and it was kind of like a halfbaked effort from Hashi Corp to try and emulate what Palumi provides. I don't think that's really the case. I mean maybe it was >> actually I've not used Palumi in anger so I don't know what to say about it. >> Yeah. So I did a very fun talk at DevOps Day Singapore about how Terraform Hashikorp language is a horrible way for developers to manage their infrastructure and goodness that there's only few other options such as Pulumi but nobody used it and somebody in the audience obviously took offense to that and um told me to do a a co-presentation for the AWS uh community day in Singapore in June and um and I got schooled cuz um I was like um this is how I have to do it with CDKTF and he was like oh in Pulumi it's literally like one line. Oh okay. So he kind of showed me the way and I have to say Pulumi is impressive. Um the only problem is and kind of how I changed my presentation because my presentation was all about how so much easier it is to use CDKTF than Terraform modules. And the fact is that he was showing all of my examples with Pulumi and they looked even easier with Pulumi. No, they look the same. Let's be honest, they look the same. Um so then um I changed my pitch mid presentation to basically say so many organizations have like two to three years Terraform footprint with like you know known automation solutions such as Atlantis or GitHub workflows that are all built around Terraform you know security scanners all built around Terraform IC so it's very hard sell as a product engineer who wants to build a product and leverage you know, a queue and a lambda and the tool has to be connected and you don't care how, right? And you do do serverless. You're building this beautiful API gateway with all of its endpoints going through ECS Fargate containers for long running jobs or directly to lambdas for a quick response and you don't care to learn about five different Terraform modules with 40 different variable inputs and how do you configure an API gateway, right? So for serverless, you know, AWS CDK is amazing, but you know, try to come to your platform team and say, "Yes, I know you guys have this amazing Terraform uh pull request previews and and and scanning code and and and all this stuff, but I want to use AWS CDK. I want and then they have to start supporting cloud for uh or even you know more go towards them and say I want to adopt pulley and now they have to think about pulley um into this pipeline. Although that pulley's strong point is that they make um trans migration from Terraformed to their cloud very easy. Obviously they are backed by the original Terraform providers. So they have a lot of migration paths. >> Yeah. I'm just looking at Palumi now. They seem to support every language under the sun >> even YAML. Yeah, you can even put YAML as an input and you get uh you get infrastructure as code. >> So do they do they have tools to to convert the Terraform into into >> language? They have a very powerful I think they can even interact with the terraform back end directly right so you can have them side by side you don't need to migrate everything immediately the only problem is you have to now sign a contract with Palumi and then you have to you know >> so you're so the big problem with Palumi is that it's a commercial non-free thing right >> well when when the BSL announcement came basically when Hashi Corp announced that the source code was uh available but not allowed to be used in competing compar commercial platforms, >> the business license that they put on Terraform. Pulumi made a big announcement how they are the real free version, the real open-source infrastructure as code. So, I can't claim um >> Oh, so so they're open. Okay, hold on. I got to check out the GitHub now. They're open source. >> Yeah. And they um they also another famous pro for Palumi is that SST which is a I think originally SST they are the people that build serverless.tf TF uh serverless not serless.com. >> Yeah. SD, right? >> Yeah. Okay. So, so the source code is Apache 2 licensed. Okay. Okay. >> Yeah. So, >> but I'm guessing they have have a model because I see they see looks like they have like a a cloud UI, right? >> Yeah. So, they're they're like Terraform Cloud, right? They they give you the ability to very quickly get started. Just sign up to their cloud and get your Pulumi code ready. And the terraform cloud is is essentially non-free, right? >> Yeah. They both under management pricing models, right? I think we talked about that >> very first time back in September when there was this uh announcement of open. >> Okay. So, Palumi seems to be in a good position to deal with the CDKTF fallout then, right? >> Yeah. And they even have made their AWS CDK adapter generally available. So CDKTF had this in in um technical preview since its inception and for five years it was still in technical preview until it got uh you know shut down together with CDKTF. So the the adapter basically your team can write AWS CDK code and the adapter converts the the generating cloud formation into pulley equivalents allows your teams to quickly convert your AWS CDK to pulley as well. still that doesn't sound quite right to me because even if you convert your cloud information to Palumi, how the hell are you going to, you know? >> Yeah, it's I think this is just a um >> marketing >> just marketing and just to allow people to quickly do a PC on Palumi and then see the benefits of the cloud. I guess there is a benefit compared to cloud formation, right? It's very frustrating cloud formation sometimes when you kick off a roll out and then it gets stuck and it does a roll back and you have to wait an hour and and it's it's this cloud for all or nothing behavior that is sometimes very frustrating the ability for cloud form to you know lose track of resources if the logical ID changes. So that's where like terraform and puli are like advantage have advantages because of the the way they track state. They allow you to more carefully refactor your state, but they don't have this all or nothing guarantee like cloud form, right? Cloud formation is really like a database transaction. You kick off a roll out, it's going to go through. If it doesn't, it's going to try and roll back, which honestly also doesn't always work, right? Sometimes there will be something blocking it. Yeah. And then the roll back fails. So that's where people are like, oh, the AWS CDK is awesome. Cloud formation is horrible. um and then they maybe have a lot of issues with like managing the overall teams >> um interaction with cloud form stack. So pulley is in a really great position. They also have SSD. >> So SSD originally serless were built on cloud form and SAML um SAM sorry not SAML uh SAM the >> yeah I'm I'm an AWS SAM guy kind of guy to be honest. >> Yeah and SST was kind of like replicating SAM on top of AWS CDK. So you don't have to work with the AWS CDK abstractions but for example you can say I want open next deployed as serverless on top of lambdas. So SST gave you that um it take care of everything like I want an application right I don't care about lambdas >> I'm just clicking around Palumi I guess looks like it's done a quite a good job I'd say on the face of it >> it's just it's just the ball breaker is the fact that they will catch you in their in their web of the the >> cloud costs >> the cloud costs >> so there's there's no there's no open source >> there is cloud so There was one of the uh misconceptions I had as well about Pulumi was that I heard that it was expensive and you can't self-host but you can you can move your cloud hosted back end to an S3 bucket but the the the counter to that is then but now you have to manage all of this cross team uh rolebased access control you know all the enterprise features that come around >> oh yeah software >> orchestration and all that sort of stuff. >> So so then you need to take that on yourself. Yeah. And and in that aspect in in the Terraform ecosystem, you have a lot of open source projects, right? And you can choose between um Spacelift um you can choose between Terra Team or um you you can choose Terra Mate or Terra Grand or Terra Grand Scale. So there's so many options around Terraform and for Purimi we didn't have that many. However, Spacelift and others say yes, you can also manage pulley with us. We're also hosting an S3 bucket and we're coupling it together with your terraform. So, so yeah, that's that's why most of the reactions Yeah. >> So, the let me I'm I'm just let me just share my screen. I was I just I just want to map out where infrastructure is at then. Sorry. And then we haven't even talked about um system initiative and uh and >> I hope I hope to catch up with um with Adam at the config management camp in Gent. >> Yeah, you give you a beautiful demo. >> Let me just trying to think. I don't know how to do the scale here, but I was I was going to put like maybe this terraform here and then this Palumi here and Palumi has seems to be the last. >> I would put AWS CDK all the way on the right. That is like the benchmark for me >> because it came first. M no I don't think I think Palumi came be around the same time or at the same time or little bit earlier to AWS CDK maybe >> okay that okay so we have to pre prefix this with AWS infrastructure >> and then I mean I was going to put it here but like anyway so most >> yeah for me it goes more to the right to puli because because it it has this little additional library like next to AWS CDK Here you can put SST because that is on top of poly >> SST. >> Yeah. >> Okay. So I was going to maybe put use a scale of like I don't know features because you I mean let's be we've talked about this before but you can't do uh well lambda and serless very easily on the terraform level. So you need something like >> it depends what features you're talking about because features are related to developer experience or operational experience um and and how you like do >> um previews plan previews and things like that. >> Well and rolebased access control. >> Um I'm thinking developer experience. I mean what do you mean operational experience like how easy it is to to manage or >> to refactor? uh for example let's say as a company we start with a single offering and we build a VPC with like some lambdas and so on and then later on we spin off >> I would always feature agility operational then >> yeah agility >> yeah so so >> so you're you're only looking at one dimension operational features >> yeah well I I sent you the link but I mean be good to explore the dimensions. >> I uh yeah, let me try and add the developer experience dimension. >> So, um >> just bossing you around. >> I mean, cloud form is probably at the bloody bottom, isn't it? I mean, it's a nightmare to work with. >> No, >> cloudformation is at the same level as Terraform. Come on, be honest. >> Going to give you that. I've refacted Terraform plenty of time. >> Okay. >> The tooling is good. cloudformation like you it's you. >> So we I'm going to create a separate scale for developer experience. >> Yeah. >> Oh wow. Hyperland does not >> I'm going to I'm going to put AWS SAM in the middle just because >> I'm on Arch by the way. I'm going to say like six times during this call. Do you know I started I started my channel by making Archix installed videos for noobs like you. >> No, I didn't have to install it. >> Oh, yeah. You're using Omar. You're using uh what's it called? >> Omari. >> Yeah, that's that's how way he pronounce it, right? >> Yeah. But you were sending me screenshots of Hyperland crashing or something, right? >> Yeah. >> That's why I'm on Arch. for the uh crash experiences. I think Arch cannot run this website. Uh cannot run um Xcoly draw. >> What? >> Maybe developer experience goes the other way or I think the same direction. >> What's okay define developer experience. >> Yeah, as a DevOps engineer you should know this. >> Well, >> okay. Basically we are not devops engineer we are platform engineers and one of the things that we should focus on is to provide our developers the tools so that they can take ownership on the services that they built and run in production. >> Okay. Okay. >> And the developer experience comes with um you know the the easiness at which they can define their production workloads. >> Yeah. So my my points of what my point of mental reference is like you know net lefi and u up cell and things like that. >> So essentially what what they need to twiddle with is is a config yaml and uh a CLI tool or something like that and that that's it right that that's that's my point of reference. Of course, so many companies just do it so much more convolutely convolut in a awkward way. Fly.io. >> What did you say you you you called >> Netlfi? Netlfi. >> Yeah. So, they all work in a similar way. There's some CLI and there's some config YAML >> or toml. Maybe I should do a scale for cost like or enterprise adoption or something like that because some of these things like Palumi is going to get expensive. Enterprise I don't know. So, anything I select doesn't show up on my on my browser. I think there's a problem with Chromium to be honest. Um, I'm on a Chromium browser >> on a fork >> and uh and doesn't render properly sometimes. >> So, Palumi is going to be expensive. I think cloudformation terraform is a bit tricky cuz No, I mean Terraform is good because you don't need to pay for rum. No rum. I think you cannot put operational features AWS above terraform or maybe >> I I mean I love it. I love it >> because it's backed by CFN. So you must have the same problems like losing logical um logical ID for resources loses the actual resource ownership. Although they have added a lot of new features to cloud form to help you refactor your code. But yeah, the main reason there is that organizations constantly change the names. Oh, we did a we we had um an offsite of the with the sea level team and we decided to merge our AI team with our data team and then all of these resources that were AI team. >> I love what you I love what you said uh a few chats ago with changing of IDs. You were saying that like uh you should just use labels, right, to address resources >> and not and use opaque IDs. I mean I really that stuck with me. I need to do that more. >> Yeah, I think so. >> Oh, and convince people you don't have to name a bloody bucket this certain way. >> And that's something that cloud form kind of forces upon you or AWS CDK, right? By default, it doesn't even allow you to define the physical ID of resources. And it and then I had some some um colleagues and they were like, "No, no, this load balancer has to be named exactly like this because I need to be able to find it in the console." And I'm like, "No, >> no, >> no. then you have to deploy the same stack twice and you you get an error because the load balancer identity like physical ID does already exist like >> you know and then I got this whole discussion with the team manager after the guy that tried to do what I I wouldn't allow him to do raised it up to our our manager and then said yeah come on Vincent we we're not deploying the same application twice in the same AWS account and it's like Well, yes, we are. And we are consolidating more of our infrastructure. So, >> okay. I mean, I think you're being a little bit danty. I mean, to be honest, I make assumptions right now. The thing I'm working with and I need to make it uh talk to each other at some point soon. Okay. So, um yeah. Uh well, I thought I mean I like to fill this void. I do think AWS Okay. AWS is so specific to serless, it's probably not worth beating around about. Uh I'm probably going to copy. This is so difficult because the functionality is not comparable, is it? >> Copy it or just drag it. >> Oh, sorry. I meant to copy it. Hold on. Let me copy my Okay. I don't know. We've just been dragging things around. Maybe we should we got to start somewhere. Let's >> say what we what we mean by this. >> Okay. Your developer experience. Um I'm I'm really surprised you put Terraform right rock bottom. I mean Terraform has an incredible developer experience. >> No, >> it does. >> It's a horrible developer experience. >> It's the worst. >> Okay. So, okay. I I think Okay, you're coming from a developer point of view. Okay. You're like the guy says like I don't understand this. What is this TF file? >> Why do you s make a whiny voice when you're the emulator developer a product engineer? >> What I'm saying is Terraform um is exposing every single API resource of the cloud of the SAS that you're interacting with, right? Either the cloud provider or um you know whatever um is it or whatever you're you're you're talking to. Every single API endpoint must be configured and then must be linked together. So if you're setting up an API gateway and a lambda, you must set up the IM role and the IM policy to you know provide lambda permissions. Then you have to do you know the lambda trust policy. Then you have to set up lambda permissions to allow the gate API gateway service to invoke the lambda that you have to do with terapform. >> Yeah. And then you have to do it for every possible scenario that those things can be combined together, right? >> Yep. Yep. Yep. Yep. I I'm just trying I'm just trying to come up with the right word. You have to basically >> manage everything and it's >> Yeah. As a developer and many people always came to me when I was purely Terraform only guy um and said like look I'm not like you. I cannot read the API docs or the provider docs and figure out how I need to comm connect connect all of these resources. Let me click ops. Let me go into the AWS console, click on this, then click on that and then after that I will try to capture everything. >> On the subject of click ops, is there good support by any of these tools to basically capture the state from from a from AWS? I think I think you should ask uh system initiative to give you that de demo because that's one of the things that he's advertising right like look people have clicked and now you have to you know control it so here you go system initiative doing that for you is there anything that does that really nicely >> I don't think so I don't think any of these tools help you fix whatever somebody clicked in clicks up still in but >> some of these tools allow you to avoid clickups to basically start the correct way um by defining it with SSD because they give you that ability to say like I had a gateway. >> I mean I I got a soft spot for click ops in a way just because I was on a >> I was on a job and it took it took me literally like a week just just to toggle something. Wow. I'm I'm exaggerating, but it took a while. >> And I thought to myself, >> yeah, absolutely. So that's the problem with a lot of these infrastructure as code libraries is that they're built from um a very low-level perspective and you can either and a lot of the tools that are being built right now is to you know reflect the reality of this nature of the cloud changing things under the hood right if you create an RDS instance it's going to auto upgrade to the latest Postgress version and then your Terraform's going to go like nope this is supposed to be Postgress 15. What are you doing running Postgress 18 over there? You know, let's delete this database and recreate it. >> Yeah, actually >> dealing with dealing with data and any of these tools makes me a bit sweaty >> like uh what happened. >> That's interesting because that's exactly the argument that somebody made just now on a thread on Reddit because I'm I'm 24 hours on Reddit obviously. um that he just made the argument that the only place you would use something like Terraform is to manage databases. >> What? >> Yeah. Because he says like everything else is so dynamic and most of the stuff you shouldn't be doing with IC. IC should be done for these like um resources that take need additional like operational >> Okay, maybe he's got a point because it's got it's got more >> control >> stability aspects to it. Yeah. Yeah, because you're right. You do a because with IC it's often very close to GitHubs, right? You need to make a source code change, >> bring it to production. >> We're using Terraform to manage some data right now and and uh our basically one of our main guard rails is the plan, but no one reads the plan. No one reads the plan. Like we like we got like a nice GitHub summary to say like, oh, do you know you're recreating resources here? and they just go, "Yeah, whatever. Apply." >> That's weird because like first off, why is it recreating resources? That means that and that's the hard thing about Terraform. >> Well, I I didn't want to mention the I didn't want to mention the provider, but I'm I'm going to mention it. It's not going to incriminate anyone, but this the we've been working with the snow snowflake provider and it just wants to recreate things very easily, but it it's it's it's a complicated environment to be honest. >> Yeah. Some providers have really low quality. >> Yeah. And the snowflake one is in maybe someone has made a video about it, but it's it's it's came out of like I it came out of like the uh the Chan Zuckerberg Foundation or something like this. It's hasn't been maintained very well. Then Snowflake itself eventually adopted it. >> LOL. Oh, that's so funny. I I I used and there's so many experimental features in it, it makes you very nervous. I mean, and then Snowflake is only used by the like the biggest enterprises ever. >> Wow. >> We It's a very It's a very weird setup, but I guess it is it is better than managing it by by hand, I like to think. But still at the end of the day the the provider just seems to do SQL calls or or like it it it lacks so much functionality you're ending up having to write these like what do you call like SQL execute blocks here and there and everywhere which >> yeah so so this is kind of where I feel when I started on my Terraform journey I was like terraform everything right you create an RDS instance you need a database in it well we're going to define the terraform provider for Postgress and we're going to connect it to your RDS instance and we're going to create a database and we're going to create the plug the extensions that need to be active on that database and it's a nightmare because now when you ever you run Terraform you have to have a tunnel to connect to the Postgress instance and you know once you start doing compliance you need you need all types of security around that and and this is the type of stuff that it shouldn't be part of Terraform right like running SQL queries through a provider just to me already after using it for 10 years seems something like done that been there never again you know >> yeah okay I think we all agree I agreed I'm agreed with this whole developer experience at the bottom here um >> convinced you >> but but at the same time the things that we put at the very top don't really I mean that's for very narrow use cases I feel like we need to have maybe two axis at this point because we we need we We need like oh god one access to sort of we need we need the vertical access to talk about um what you can do like you know AWS feature >> but that's what the defex or what >> scope or something like well like the trouble is is that versal is good at setting up a website but you can't like run a database So I mean probably I mean maybe it does support database >> because is this as a higher level abstraction right? >> Yeah. So I understood. So so basically it needs to go down you know it needs to sink down here. Well well with with >> you just moved you just moved my devx uh scale to the right saying feature scope and and you just >> and then here I would say de dev experience because we need to basic okay we can discuss this later. I think your feature scope is the devx and your your x-axis should be the operational features that we we were just talking about >> because because the feature scope here like Versel has um great Devx so it needs to go up there but horrible operational experience such as like I need fine grain control to bootstrap a database I can't do that because first is very high level and under the hood it's going to create some type of data store and they take care of it which is like a trade-off right >> yeah they're going to you like three different types of data store and you don't care how they're >> Yeah, you're right. You're right. The operational stuff comes. Yeah. Yeah. You're right. You're right. You're right. I didn't know what SST v2 is. What the hell is that? That's just serverless, isn't it? >> So, basically the the way I understand it cuz I only came became familiar with SSD when my my friend introduced it to me. Um originally I think the server the people that built serverless.com they created um SSD on top of AWS CDK. I think serverless was using SAM and maybe cloud form directly and then they with some scripting around it and then they created um SST which is just instead of directly writing cloud form they would just leverage all of AWS CDK because AWS CDK is this amazing library that gives you these beautiful integration patterns. If you need to create a lambda and a gateway and you just connect it to it's going to take care of everything, right? So you don't have to generate every single cloud for resource, you just say here. >> So it's like a it's another sort of CDK/palumi type type offering, right? >> No, it's it's on top of so originally it was on top of cloud for then they rewrote it on top of um on on on AWS CDK and then they rewrote it on top of FUMI. So SSD is like the AWS CDKL2s. Um but they're trying to go like like Versel kind of in the middle. >> They are. >> Oh, we don't have Palumi on this top thing. I mean Palumi needs to be up here or something. I don't know. >> You're you're like yeah I was trying to duplicate it but it didn't manage to duplicate it. So yeah, Palumi and SST on operational I think there would be the same. Okay. >> Yeah, SSTV1 was on AWS CDK and SSTV2 is on top of Pulumi. Um, so >> how do you get exposure to all this stuff, man? I feel like I'm doing a lot and I don't get to touch some things. Okay. I guess you attend a lot of talks, don't you? It was my colleague uh sorry my ex- flatmate who um who who pivoted you know originally started with Amplify then with AWS CDK and then he says you know SSD is this amazing thing. >> Oh my god. Amplify. Oh my god. Sweet Jesus. >> Yeah. But Amplify also completely wrote itself on top of AWS CDK. Yeah. And then they just became like uh this portal that you it's kind of like I think AWS answer to Versel. This basically like allows you to create your front end to deploy it. >> Yeah. That's true. That's true. But I I never appreciated the stack. >> Okay. >> Yeah, they completely changed the stack because originally amplify was doing cloud formation and now it's just doing like CDK stacks and then it's just allowing you to manage your front-end deployments, you know, your S3 contents and your CDN configuration from an abstract level. A bit like Versel really like I think amplify is really like Versell. >> No, I think I think Vel is much better than amplify. >> When was the last time you looked at amplify? uh years ago and I I had I think I think I have a GitHub project about it and then it was impossible to like just maintain it. So basically, >> yes, I know that's what amplify used to be. But what I there was this uh lady who posted on LinkedIn access to a Udemi workshop that she had just published which was AWS AWS CDK and Amplify. And I and for free you got access for like two days or something like that. And so I I did a speedrun through it like literally in a day just crushed it. And um I went through the whole AWS CDK thing and the Amplify side of things. And this literally just like a month ago, not two months ago. >> Yeah. And and it's really like amplify when I looked at it and I haven't used forcell but um it really is like oh I want to do blue green experiment. Oh I want to do this. It just takes care of everything under the hood for you and you you just go here's my website source code and it just take care of the whole >> anyway. So we can put bloody amplify here. Gez. >> Yeah. Amplify V2 or whatever. Amplify current whatever new one. Okay. So, okay. So, now now if we and how do we account for the the cost of things? I guess let's let's just focus on operational features and and DevX. Can are you able to copy and paste into this one so that we have a a better graph here? or shall I just do it? >> Uh, yeah. No, my my my Chromium is un unresponsive. >> Okay, so if I maybe I put Terraform on the bottom here. Cloudformation too. God, it's got a terrible experience. Palumi looks like it can do a lot. Wait, it's going to look the same, isn't it? It's going to look the same. There's no there's no DevX and operational features seems to be the same thing, right? >> I mean, Palumi and Palumi cloud I guess and Terraform and Terraform cloud maybe. Uh so Palumi I would I would pose in terms of operational features a bit higher than Terraform and in terms of DevOps kind of in the middle. Um but but ultimately I can't help but think there's no the major differentiator short is going to be is just going to be it's just going to be price isn't it? We you you like if you were like a an enter like a Fortune 500 company, you're not going to use um well, you can't you can't use VEL and and things cuz that's not going to be enough and you're not going to use AW CDK and Terraform is as we know limited. But then you're gonna you're gonna basically pay for Palumi. Okay, this I'm not too sure where I'm going with this. >> Okay, I >> I also wanted to tie this into AI somehow, but it just it look it looks like Palumi is in a very good spot. And we haven't even talk about we haven't even talked about Kubernetes, but I don't want to talk about Kubernetes. Looks like Palumi is is on a I don't know if can can we invest in Palumi? Looks like it's in a really good spot. >> Are you building a tech radar? Maybe I should pull up the some famous tech radar. Um, hold on. Uh, what was I? Ah, AWS CDK. >> Not on the current edition. >> I would give AWS CDK highdevx but very low operational experience. And then SST given it's on on Palumi would be a little bit less on the DevX side because they don't they didn't build all the same like service levels but on the same level as Palumi in terms of operation because it lose uses Palumi under the hood. Yeah. What else is there? Does it make sense? Where are you? I don't see you anymore. >> I'm here. I'm here. I was just looking at um Oh. What the Why does it say data dog? >> What the I >> I was just I was just looking at the uh >> I think you're on this >> the tech radar. The thing the only thing it says on platform to adopt is uh ARM in the cloud. which sounds a bit weird sometimes. I wonder if these people that make those T radars really know what they're talking about. I don't know where which one you're looking at, but like I'm just guessing now. Uh, okay. Let's tie this back to AI. So we we just riffed about how Palumi ST is is in a good spot. We we Oh, we should we should put system initiative somewhere here, right? >> Maybe you can take this this slide back when you talk to Adam from system initiative where you put it. >> I'm not that I'm not that happy here, but like okay, what okay say you're the what do you call it? the chief technology officer of a of a big company that that had a whole bunch of AWS accounts >> only AWS. >> Let's say it's only AWS. Just just to keep the conversation sane. >> Yeah. >> How would you begin to manage it? Like let's even go even more bizarre. Let's say like, oh Vincent, we need to build up to 100 accounts and we need to do this in the space of six months. and or three months and you choose the technology to do it with can I assume that Vincent would choose Palumi and there's no budget I mean >> it would be between Palumi and or between SST and AWS CDK yes if there's no budget limitation maybe more towards SST then >> but SST doesn't have a a cloud and man and governance and or >> I think they may have runners but They they basically originally SSD they had their own like deployment pipelines but since they completely pinned themselves on pulley I would imagine that they are completely powered by Palumi deployments. >> Okay it sounds like Palumi. So okay so you would explain once once more why SST and and and Palumi and AWS CDK and cloud for what the relationship is right you understand AWS CDK. So AWS CDK is to cloud formation what SST is to pull. In other words, Pulumi gives you the low-level concept of an IM role, an IM policy and a bucket and an API gateway and a lambda. And then SST gives you the concept of I have an um an API gateway that's backed by a lambda and write >> higher level patterns, right? >> Yeah. SSD level two level threes and >> yeah and then and then Puni they have two different providers they have the pure terraform provider converted on top of their own engine so they they run the engine the configuration that you provide is in programming language or YAML or whatever they they run that inside a runtime they convert your program into configuration that then gets um executed right so if if you look at it like cdktf I to me pum and CDKTF is very similar um is that you write TypeScript code or Golang code or Python code and it generates configuration for the Terraform provider and PUMI their internal representation of whatever that cloud plug-in is right if they targeting AWS it's a plug-in for AWS this they originally just ported the provider AW for Terraform for AWS right PMI was just porting the Terraform provider and then building a programmatic interface on top of it I think they may like refactored the way that that works because now they have all kinds of hooks system. So while you are your program is executing some of your program execution is happening while it's deploying things inside the cloud. So if you look at Terraform, you you have a configuration and then the provider is executing the configuration and then the provider is you know config like sending the request to the API do this then send the request to the API do this right and Terraform does not really have a lot of features that allows you to mit deployment execute this function and then based on the output do something else right by design because originally Terraform was meant to be very deterministic very predict predictable so that you are able to to know this is the exact configuration what I want all of these resources to look right right but with pulley you have like this on on event type of things um you can you can hook into the process and if you're deploying to a region that only has two availability zones you automatically like um adjust the configuration towards it right so yeah so pulley has these like events um and I think AWS CDK has similar things because while you are you know as as a as a product engineer defining this is what I need to deploy. It will also hook into the target environment depending on how you are um calling the the constructs. They can basically decide that okay I I just I just downloaded the whole VPC setup. I know there's two subnetss and they are into the these these availability zones. I know all of this information which is called the context of the environment that you're deploying into and they can reconfigure or generate cloud form stacks accordingly. >> I didn't even I've never written a CDK like that. Um >> yeah that's that's what context providers do and and then to make sure that still deterministic that context that was used to basically determine how the uh cloudformation stack is generated is also stored on disk. So you can then put that into your GitHub um into your version control sorry git and then you can um you know rerun the context lookup to update your context. So then if you want to change things for example maybe maybe one day you are targeting Singapore region and it only has two availability zones uh but the next time Singapore introduced the third availability zone and you don't want all of your cloudformation >> you're blowing my mind here CDK you would check in something into your in >> the context yes so so >> I've never seen that done I mean the CDK is all managed in cloudformation is how I understood it >> CD no CDK generates cloudformation but in the process of generating cloud form. It can do some callouts to your environment to determine how to best generate the cloudformation. >> Do you have an example of a context checked into Git? I guess it's all going to be >> Yeah, the one that I I was just talking about and the example that they give why you should checking your context is exactly what I just said like let's say that the new availability zone is introduced and that kind of like deter subnetting logic that you have a whole like subnet for this particular tier of of of your >> blowing my mind. I didn't really know about this context. I have I have to look it up. And then and then and then when you do CDK bootstrap it it creates like three different bloody places for things or something if I remember correctly. >> Yes. because CDK is very enterprise focused allowing you to exactly control how to um you know how the the the bootstrap happens right like what are the basically CDK has this asset bundling pipeline and that's why it bootstraps so many things because if you do terraform you just need to find a way for example to put an object into a S3 bucket so that your lambda can point to it and then deploy the source code from the S3 object or maybe your lambda wants to be deployed from a docker image so you need to use ECR So these asset repositories uh the ECR and the S3 bucket are very important in the way that you deploy your code and this is more important if you do serverless because you know you have all of these snippets of of of code that that need to be coordinated together with your Lambda um configuration and the environment variables and everything right so AWS CDK has a built-in asset pipeline and and and part of the things that it bootstrap is all of the necessary supporting um architecture for that asset pipeline it will create an ECR repository so that it you know, so that they can build a Docker image part of the, you know, bundling aspect of your of your application and then deploy that that Docker image in or push that Docker image into the um into ECR the asset registry for Docker images or you know push the bucket maybe which is an ES ES build bundled NodeJS with all of its dependencies and whatever AWS SDK is external needs to be external because that's provided within the runtime. So all of that is taken care of by AWS CDK because it has this beautiful asset pipeline, right? >> Well, I noticed it in one in my workplace that when AWCDK deploys this Fargate pattern or whatever, it's building the Docker image in the same pipeline. And I thought to myself, >> yeah, >> that's not cool. >> It depends. So as soon as the Docker file build fails with some rate limit, then then the whole deployment fails. That's a joke in my opinion. >> Uh to be honest, if you are coming from a developer experience perspective, not being bothered by how exactly your code gets bundled up and and made available to be deployed is kind of a feature that you want and that's why they have it, right? This asset pipeline thing. From looking back when I started with AWS and Terraform, I very strictly said, okay, your code, for example, your website and your bundle, the way that like assets are getting deployed is very disconnected from your infrastructure, right? Classically, >> I'm not so sure I'm a big believer that because because these things, >> it's wrong. What I just said is wrong. When you start out, you think like I have a very very strict separation between infrastructure and the code because my infrastructure is, for example, my Kubernetes cluster. It's my S3 bucket and my cloud cloudfront uh CDN setup, but the actual website that's managed by the product team that need to be deployed and rebuilt is decoupled from it. Right. >> Exactly. Exactly. >> Exactly. And that's wrong. >> What? absolutely wrong because if you're doing um actual DevOps culture two pizza team where you have site reliability engineer as part of the product team the whole deployment process belongs to the product team not to the infrastructure team. >> Yeah. Okay. Okay. But there's more to it because you don't want a product team to manage Kubernetes. But okay. >> Why? I mean like sure you don't want them to damage to manage Kubernetes. That's where you as a platform team are provisioning the the the Kubernetes and the integration points like the Kubernetes endpoint where they need to target their deployments towards, right? >> But we're not talking about Kubernetes here, right? We were talking about an S3 bucket and the contents of that S3 bucket or a lambda and the contents of that lambda together with like let's imagine that you're you're deploying this API gateway like this magic. I feel like we need another scale about how the how the organ how the organization is done like if it's if it's like team team topology or whatever. >> Yes. Because that's what a lot Ben Israeli figured out after he left AWS and why AWS CDK works so well in in AWS but doesn't work in other organizations >> because >> because in AWS they have a two pizza team they have an S sur uh as part of the team. The team is responsible for all of the observability for every paging alert that happens. It goes to the product team. They are deploying 100 times a days. They get the alerts. They have their their product uh you know reliability and their runbooks. Everything is managed by the team. But in a lot of organizations there's still a very strict separation where you have a security team responsible for the IM roles and other team responsible for other things and that's where team topologies are are are then making it obvious. >> Yeah. I mean, to be honest, I'm I'm been working with strict separation, you know, separation of duty type outfits for like a decade now. So, I'm pretty I'm pretty like I don't know how to describe I I I don't even know what it's like to be in an autonomous team anymore. >> Yeah. So, so >> it's it's crazy that AWS can do that in a way considering you know >> you know where I like >> very nicely and a public artifact of this as an example as part of AWS CDK and the the whole CDK ecosystem they built this thing called the construct hub. So the construct helper if you go to constructs.dev I think it is is a place that you can find every single construct that was built and remember constructs are usually you know L2s or L3s built by the community. Yeah. Constructs.dev. So these are amazing. Um they are they're like the terapform module registry but instead they it doesn't cover a niche technology by one company IBM. um and then pedled by other companies like Spacelift. Instead, this is using registry of .NET, Golang, Java, Python, TypeScript and its best-in-class um you know artifacts or yeah artifactor um artifact registries. So across all of these so so this construct hub is a complete public GitHub repository and if you go to that public repository of the source code of the construct hub you see that it's a massive serverless application um basically there's um there's what is it it's it's a kinesis stream subscription or it's a stream subscription >> to npmgs uh publish published packages right so so if you go to the source um you can find and the reason this is public is because you can deploy this within your organization. So it tells you exactly how you can operate this within your organization. For example, you have your own private registry of npm your own net registry that you don't want to be public and you want to make it this construct hub available within your enterprise you can do that and and it has documentation with guide books exactly what is the alert that's set up like there's a backup bucket uh in in a separate region. So if a region is down, all of your registry downloads are still available in a separate region and this is how you do a failover and this is how you do that. These docs are amazing. So when I saw this, I was like now I understand how a product team can build something and has like very detailed runtime guidelines on on how to observe and react to alerts and why that alert exists because it creates all of the Cloudatch alerts. It tells you exactly why the alert is triggering and how to handle that that instance. So that's on one side like a two pizza team. You want to see a beautiful implementation or a product delivered by a two pizza team, you look at the construct hub. It's I looked at it, it was amazing. >> So I mean these the these people the two pizza team has to be like super mature to take take on all these this uh this responsibility I suppose. But mean but meanwhile most most companies are designed to to silo responsibility for for lots of good reason >> because once you start talking about compliance and and those initiatives then now you need to align and you need to like do across all of your your teams you need to make sure that the the technology they are using are are are similar so that you can push through huge initiatives. you know, you have have one team doing it like this and another team doing it all on on Google Cloud, you know, it's it's extremely difficult difficult to get like um compliant and I guess like AWS is really good at that as well. Um but most enterprise main main you know business is not about doing all of that, right? I mean AWS is a company providing cloud services and they they are building cloud services and they have a great team to build cloud services. So that makes sense. Most companies the DevOps um you know type of of of initiatives are part of an operational team that is short staffed and that needs uh alignment across the teams and centrally controlled and um and that's where team topologies come in right. So, so which so which tooling by that explanation would they gravitate to in your opinion? I believe with with things like AWS CDK and Construct Hub, you can have a platform team that builds really powerful constructs for the rest of the organization. constructs that make sure that the the patterns used by the product teams are supported and can be easily integrated within compliance initiatives and and zero trust and all those you know crossorganizational um effort that you don't want to go through every team and try to fix them up. You want to give them an approved and and rubber stamped. >> Yeah, that's exactly what happens in my current gig right now. We create constructs for for other teams to use. >> Yes. And and that requires your platform team not to come from pure operational background, right? requires your con your platform team to understand how to do object-oriented programming, how to define an interface, how to integrate that like iterate on that interface, how to do you know contracts across teams, how to test against those contract contracts and then you come to an organization that's using Terraform because the old system administrators that like config files never wrote uh actual object oriented interface or whatever and then they cannot deal with CDK. they cannot deal with like all of these like program. >> Yeah. Well, we we tr we uh >> I I sound because I'm I'm a bit frustrated because I was in a lot of those things where I try to to introduce this and and I always get like the feedback like you know Terraform is simple why do you make it so complicated but in reality Terraform is not simple and one year down the line two years down the line you have Terraform modules that have such a complex interface there's no testing because you have never thought about like actual software testing on your infrastructure as code Okay, cool. But you're actually doing infrastructure as >> comp. We need and we need to wrap up in five minutes. I need to run out and drop my kids off to school. But like >> but just on this point uh you you develop constructs for for for um for other people in your organization to use, right? But but the trouble is the trouble is is that um let me just get this clear. Do you expect people to use your constructs via a config.yaml or do you expect them to use like a a like a Python uh library or something? >> Yeah. So I think there's very different personas. Um, and I think as a platform team, what you should be building maybe exposes a flat interface like a YAML, but I don't like YAML. At least it should be JSON schema type YL so that they get an error if they use a field that is not there, right? You can do YAML uh >> with JSON schema or use most companies use pedantic. Pedantic >> pedantic on YAML. I never tried that. >> Yeah. Yeah. >> But how does pedantic work? It must must have some type of schema for the data structure behind it. >> Yeah. So so basically pedantic if I understand correctly it uh it has its own model. So so the the you the way they use pedantic is that you you read in that YAML and then you compare it against the model and the model is very powerful. You know you can you can express anything in that model. >> Okay. And then the model basically tells you if if it's um yeah how what what all the configs going to be and and if the config yl is valid and >> s so forth and it's used a lot. >> Yeah. So what the way I handled like the problem with YAML with it being so unstructured is that we use YAML often as an input for generating um well if you put it on top of Terraform you can do the Terraform plan preview to see how how messed up you did when you agreed to it. >> But it it sounds like such a this whole this whole area with the governor. Okay, I do want to bring this back to we I guess we can continue but like what what what of all these technologies that we sort of try to map out here badly what do you think AI is going to help any of these problems that we have at the moment like the teams the devx did >> so I did a podcast about a year ago about the AI and the infrastructure and They compared it as a new way of doing click ops. Basically, you just have these rampant LLMs just going around creating things across different areas where you have no idea. So the main point of bringing AI to an organization, I think we might have talked about this already was that we need to guide the AI with rules and sandboxes and there's several organization like several um tool tooling suppliers like stackpack that are focused on. >> So basically basically we're going to be in this area in AI We're we're we're headed to the governance side of things. >> Uh yeah, I mean in a way it's like you see what Cloud Skills is doing and and now Kira superpowers. It's all about giving the LLM directions, right? And and and right now they're generic, but I'm sure a lot of organizations adopting AI are are creating internal rules, right? They're saying okay uh if you're using cloud use our rules use our skills directory internally within our organization. What kind of rules would there be? Like use >> if you want to deploy the integration points for a VPC are in this repository. Don't create a VPC for scratch. There's an existing one and this is how you find the information about it. Right? Our ingress is handled through our CDN layer and uh we must follow these rules so on right like the platform team uh are here. This is the registry where you can find information about the different integration points. as a product team, you're going to have to integrate into the platform team or the cloud. >> Yeah. Yeah. I mean, that that makes sense, but I'm just thinking aloud that um how is this actually governed? So, so you have the rules and and you and like say say u a product team. Oh I need to go. But okay, we need to pick up here. We need to pick up here about how AI is going to work in a typical organization. Why did we end up talking about this? Because you asked me about CDKTF and I just went on my classic rant. >> Yeah, we can we can reflect. Okay, I I'll catch up with you in a bit. Uh probably tomorrow, right? >> Yeah, tomorrow because I in a bit I'll also be on the road. >> Okay. So, >> okay. Good one. Thanks, Vincent.





