Episode 1
· 40:42
Okay. So now we're oh, you'll be recording? Okay. So I guess I can start to pretend to be somebody else now. Okay.
Speaker 1:Pretend to be on private.
Speaker 2:I mean, we still have we could still make changes in post.
Speaker 1:Oh, okay. Alright. This is not livestream. You know, people do that. Okay.
Speaker 1:So what do you wanna talk about?
Speaker 2:Do you know what I tried to do? I tried to get chat gpt. Have you used chat gpt?
Speaker 1:No. Never. I didn't even know what that is. I'm liking a bunker, dude. I didn't talk to anybody.
Speaker 1:Just tell you have to tell me what the, like, the world is, like, is about now. Like, have you been invaded by aliens? Just tell me, dude. I have no idea.
Speaker 2:No. No. No. This is like, an AI chat, so you can ask something. So I don't know.
Speaker 2:Oh,
Speaker 1:okay. This is, like, correct my grammar with AI. Okay. I got it.
Speaker 2:Yeah. Exactly. So, like like, what's a good name for a podcast about This
Speaker 1:is such a nerdy thing to do, by the way. Can't think of a podcast name so you're going to AI engine just
Speaker 2:ask. Okay. So let's see what it says. This working or what? Come on.
Speaker 1:Come on, AI. You and they say you're you're gonna replace me. Cloudcast.
Speaker 2:That's already a podcast.
Speaker 1:Oh, really? Of course.
Speaker 2:The cool thing is you can also do stuff, you can, like, it it, like, remembers the context. So I can say, like, what about something, I don't know, with more personality?
Speaker 1:Oh my god. I started typing it and autocomplete like it read my mind.
Speaker 2:Yeah. It's pretty cool. You know? Oh, cloudy days and code nights. Clyde with a Chance of Code.
Speaker 2:I kinda like that one.
Speaker 1:Yeah. Claudia, I like it too. The Lost Seas, the CCC podcast.
Speaker 2:Oh, nice. Yeah. Okay. Okay.
Speaker 1:We're good on that? I
Speaker 2:yeah. If you're good.
Speaker 1:Go ahead.
Speaker 2:Okay. Let's do it. Alright. Welcome to the first episode of Clari with a Chance of Code. We're gonna start with some quick intros.
Speaker 2:My name is Larry Okranik. I've been a software developer for, gosh, over 20 years, I guess. Do a lot with AWS, in this fantastic AWS heroes program with my cohost. And what else? I don't know.
Speaker 2:You know? I'm just interested in, yeah, programming, development, doing a lot of stuff with more the serverless side, like Lambda, VetBridge, things like that. I don't know. Looking forward to spending some time conversing with, Tongue and keeping up on cloud and development stuff. And, I don't know, hopefully, building a nice community of fellow, developers and, AWS fans.
Speaker 1:Oh, that's cool. I thought that was a good intro, Larry. My name is Tom Wen. I'm also one of the AWS heroes. Met actually Larry through I think I met you through the AWS heroes program also, so that's pretty cool.
Speaker 1:We do a lot of stuff on AWS and stuff. Larry reached out to me. He was like, hey. You wanna do a podcast? I was like, there's a 1,000,000 of them, so why don't we do a 1,000,000 plus 1?
Speaker 1:Yeah. That sounds fun. So, I figured it's a good opportunity to actually catch up Larry since I only really see him before this kinda once a year during reevent, which is funny because, I think we both missed reevent this year. So we're like, oh, not going. So it's gonna be fun to recap something we kinda miss.
Speaker 1:I'm actually looking forward to what you have to say about re:Invent too. But, yeah. So let's see what else about me, though. I, build a lot of open source tools. Some in the service space, some in the Docker space, so all over the place, a lot of E plus tools and all that kind of stuff.
Speaker 1:And and I've been doing software engineering for, I guess, about 15 years, years or so. So that's the bit about me. What else you wanna talk about now, Larry?
Speaker 2:That's great, man. Yeah. That's good. Yeah. Do you wanna talk about yeah.
Speaker 2:You mentioned re:Invent. Yeah. We both missed it this year. Kind of a bummer. Yeah.
Speaker 2:I don't know. It's been I think I went to, like, every single one until COVID happened, and then haven't been back since. And, I don't know. I mean, this year was nice to go. They had that hero summit in Seattle that I went to, which was amazing.
Speaker 2:And I feel like especially, I don't know. Since I had already gone to that, it felt hard to do the extra travel, you know, with family and stuff like that. And, but there are some cool announcements. Yeah. I tried to keep up with what happened.
Speaker 2:Yeah. I guess I can talk about some of the things I'm excited about. I not sure how much I use, but I think it's just I'm excited about some of the direction, like the Lambda snap start thing, which is really cool. I don't know if you did you see that? It's, like, basically, the idea is to improve the quick start or the cold start time of Lambda function.
Speaker 2:So they added some stuff in Firecracker, like their VM technology, to be able to, like, snapshot the VM. So the idea is they will start up your Lambda functions, snapshot the VM, and then when the cold start happens later, they don't start from scratch. They just restore the VM from that snap started snapshotted state so that, you know, all the initialization is already done, and you you're starting, right away. The one interesting thing is right now, it's Java only, which I don't know. I did a lot of Java back in the day, but, I don't even know why it's language specific, to be honest, because it seems like it's at the VM layer, not at the language layer.
Speaker 2:But I'm excited for them to bring us other languages because, you know, I do a lot of Python stuff now, and the cold start time isn't bad. But one of the things that we're using, at work is, like, the SageMaker serverless endpoints, which is, like, not Lambda at all. I think it's probably closer to ECS, but, man, the cold start times on that is, like, terrible. Like, terrible. Terrible.
Speaker 2:Terrible.
Speaker 1:Yeah. ECS is it it's kinda slow to start up the task. Yeah. But I think it's also people, are maybe not used to the fact that not does ECS kinda start the task. Right?
Speaker 1:Kubernetes when it starts the task, because people always compare the the 2 ECS and Kubernetes, and I've I've gotten an opportunity to work on both. And, Kubernetes, it seems like it's fast too. Right? But because it's async, you don't get any feedback right away. With, ECS, it's async too, but I love the tooling.
Speaker 1:Basically, you start the task and you kinda, you you it just it feels a little different when you're kind of running the CLI command like of Kubernetes, but actually I've measured it where I kinda pull, basically, because what you could do is you kinda like start ECS task or start Kubernetes basically pod, and then you could actually pull for like a, like, you know, some type of log or something. Right? And then actually I measure it. It's about the same. So there there is overhead there.
Speaker 1:It's just whether or not from a human perspective you perceive it to be slow or not. So what I'm kinda saying is they're both actually kinda slow because it takes some time to orchestrate the whole process to spin up and all that. I did not know about, the Lambda, snapshot stuff. I've been kinda out of loop there. I've been kinda living under a hole in the last month because of just holiday traveling and everything.
Speaker 1:But that's kinda cool. But I thought they were actually doing some stuff to improve that. I'm actually surprised to hear that's that's a little bit newer, that they're basically it sounds like they're kinda imaging, basically, part of the, as much as possible, all, I guess, all whatever is loaded, the JVM essentially. And I guess they do with the JVM. Why?
Speaker 1:Because it's Java. Right? It's because the enterprise, big companies will pay for that, so they're gonna do that first. And then, all the uninterpreted languages, they basically kind of disregard until they go, okay. Enough people have to complain.
Speaker 1:Right? And then Ruby, they just like, oh, pretend it doesn't exist. You know? My one favorite language. It's like, ah, goodness.
Speaker 1:Right? Like Ruby, it's basically like the Wawa West language, like the cowboys, everybody loves it. Right? Or the people who are like, give it a chance. But then, like, the enterprises don't really do it.
Speaker 1:And I was actually wondering and talking to somebody else about this, and I was like, why? Why? And I think it's actually some of this is like legacy, like, historical reason that has nothing to do with programming or beautiful code or anything like that. It's kinda maybe like Google. The I think the founders when they kinda started the company, their engineers were Python.
Speaker 1:So just as a result of that, right, you're gonna have, like, more Python in in that world. Right? And, and so, and then I think Python is used a lot for machine learning too.
Speaker 2:That's yeah. That's right.
Speaker 1:And all that. Right. Yeah. Yeah. And, I didn't know you were also doing SageMaker.
Speaker 1:SageMaker is cool. I I messed around with it a long time ago in one of those. This is really cool. Those Abel's Lofts, I think they're open again. But, if you guys are, like, I don't know, talking to the people there who are, you know, the 2 people who are listening, if you get a chance to go check out the Abel's Locks, they're actually pretty cool.
Speaker 1:You get to go there, and then you just sit around working like I kinda I did that for like I think 2 years while I was doing the consultancy. Just like learning through osmosis. I figure if I put myself in the middle of like, you know, everybody else, and the funny thing is everybody at that loft, they're all learning too, so nobody basically has no clue what's going on. And the instructors, they're using it as like practice kind of material for the re invent for the big event. It's like the Super Bowl for 8 of us employees.
Speaker 1:So they're like, okay, we're just gonna like make up what we do along the present. Like, It's not that bad. They prepared. Okay? I'm kinda exaggerating here.
Speaker 1:But the good thing is basically it's like a really, a good place to go kinda learn. So I actually miss those lofts too. So that's good. And then sometimes they toss out credits and stuff like that, you know? Yeah.
Speaker 1:Anyway, I'm ranting again.
Speaker 2:No. That's cool. I'll have to check it out. Yeah. Yeah.
Speaker 2:I was thinking it's like it sucks to not have the good AWS support for, like, Ruby, but I wonder if you're it's maybe it's like a blessing and a curse because, like, like, for Python, they they obviously have support for Python Lambda stuff. But, like, I don't know why they're they've been ridiculously slow about updating it. So, like, the latest version of Python you can use was released, like, over a year ago. And then, like, you know, last year, they had a new release, and that's still not supported. Like, last year's release is still not supported.
Speaker 2:And then just had it they had a big release this year that's supposed to, like, really increase, the performance of Python. Like, the Python, runtime is is I had to figure out what they said, like, between 10 60% faster with some improvements they've done. But given that AWS doesn't support the version that was released last year, it's like, I'm gonna have to wait, like, 2 years to use, like, the fast Python. So I don't know. It's like
Speaker 1:maybe I was actually looking right now because I was, like, curious because I I got I didn't go to events, so I didn't keep up with any, like, maybe new runtime version releases. And I see Python 3.8, so I guess that's the latest version of Python, I'm guessing. But you were just saying that there's basically a faster, maybe the pre compiled, Python, you know. Some some of the I think some of the interpreted Python can be precompiled, and I think I forgot what they're called, but they're like not dotpy, maybe dotpyc files. Alright?
Speaker 1:Maybe that's where they're needing to optimize it. I don't know. But are are you basically saying you're waiting for, like, a faster version of Python, the 3.8 version, or or a
Speaker 2:a no version? Yeah. They're up like like, the last version that was released is 3.11. So
Speaker 1:Oh. Oh, I don't even know. You see? Oh, interesting.
Speaker 2:So that's what that's what I'm saying. It's like and I am not counting on it, I guess, to have it available for, like, probably 2 years based on how slow they've been to update. And I don't know why it's that slow. You know?
Speaker 1:Yeah. You know what? Maybe maybe I'm just saying from like announcement standpoint. Right? Where ReVent's all about announcements.
Speaker 1:It's not as sexy to announce like a brand new, like complete language versus, oh, here's a bumping version. Let's make a big deal about that. Right? So so maybe that has to do it or maybe, I'm just saying, like, Amazon is spread thin in resources because I don't know. They have 1,000,000,000 of dollars and 1,000 of engineers.
Speaker 1:It's like, dude, yeah, I don't know. I have no idea. Basically, I don't know. But, it's kinda interesting. So I see yeah.
Speaker 1:Node is right now, I see, wow, Node 18 dot, basically Node 18. Python's 3.9. So there's actually 3.9. I was looking at the bottom chart there. Java, the Coretto version, the Amazon basically, version is Java 11, and Java 8 is the older versions there.
Speaker 1:And then net dot net is 6. Go is 1. And Ruby, of course, is way behind 2 point 7. Ruby 3.1 is out already. Yeah.
Speaker 1:Yeah. But, yeah,
Speaker 2:that's interesting. I wonder how that maps. Yeah. Because I was just looking, like, the Oracle Java version is 17. So I don't have a
Speaker 1:whole I I remember I ran into this because I was doing some client work, and I was like, okay. What the heck is this? Right? It's like, I forget the mapping, but it's like they completely changed the versioning scheme. And like the node word did this at some point too, where it was like confusing during the transition.
Speaker 2:Yeah.
Speaker 1:But like it was like 0.12 or something. All of a sudden it's like, we're just gonna make the 12 like 12 or something or something weird like that.
Speaker 2:Yeah.
Speaker 1:Yeah. I don't remember how it maps anymore either. Yeah. I'm just kinda showing or saying kind of what I see in the council here.
Speaker 2:Yeah. Oh, jeez.
Speaker 1:Yeah. It's gonna be fun stuff. Do you do a lot of serverless? I didn't know you do a lot of serverless.
Speaker 2:I try to. I mean, the thing I'm working on now at work, it's all, you know, it's all serverless. It's basically, you know, just a I mean, it's using this AWS framework called Chalice, but it's all basically, like, a Python Lambda function. And then, yeah, we're using the the SageMaker serverless too to do some, like, machine learning prediction stuff. Yeah.
Speaker 2:We also have, like, you know, a a lot of the back end for a company is, like, a giant TypeScript monolith. But, I don't know. I prefer the serverless stuff. I think it's just I don't know. It's how my brain works.
Speaker 2:You know? To keep keep things small, like, do one thing. It's, like, super super easy to work with and deploy. And, like, I I don't know. Especially for for any, like, not insane workloads, it ends up being free.
Speaker 2:Like, you you get so much free Lambda compute hours that it's really hard to use them, like, for a normal business thing, you know, unless you're, like, processing huge amounts of whatever. Right? But, I don't know. Like yeah. I think, like, our Lambda bill bills for this app is, like, 3¢ per month or something.
Speaker 2:It's it's, like, nothing. You know? Like
Speaker 1:Yeah. I was thinking if your usage is moderate or low, it's basically free. Right? If your usage is, like, scaling, like, to crazy levels, like, you know, millions of requests and not even crazy levels of millions of requests Yeah.
Speaker 2:Then you
Speaker 1:have to start actually looking at the, economics of that because, as it scales, you're still paying a premium for, Lambda. Right? They manage basically the run time. They manage the maintain maintenance of that, they being AWS. So act actually, as the skills of 1,000,000 and 1,000,000 requesting, you're actually gonna pay more.
Speaker 1:Right? So so there's yeah. But then, yeah, the reason it goes yeah. Like that's, like, because you have to pay them in the DevOps team. Right?
Speaker 1:And, like, usually the Exactly. The bottom line is, like, engineers are way more expensive, right, than maintaining, basically, servers. So
Speaker 2:Yeah. That's the thing. I don't wanna maintain anything. Yeah. Even AWS like, I don't wanna worry about load balancers or scaling or anything or patching the OS for security updates.
Speaker 2:I just wanna, like, here's my Python function. Run this, and then I don't worry about anything else. And that's it's worth it, I think.
Speaker 1:Yeah. Yeah. Especially if you, well, I I I've actually messed around with Chalice before. When when I was, riding Jets, I looked into Chalice and I kinda looked evaluated, like how it works and all that. Chalice has some pretty cool things.
Speaker 1:I mean, it has it uses, Python decorators to essentially kinda do, like the scheduling right above the method definition, which is pretty cool, or the function definition, however you wanna call them Python. Yeah. But, yeah. Yeah. I like that framework.
Speaker 1:You know, Chalice was actually like it seemed like there was kind of like some, initial kind of debate around Chalice and Zappa. Because Zappa, it seems like Chalice is kind of like exactly what Zappa is, and Zappa is the open source version of it. And, you know, the guy who wrote that. And then eventually, you got kind of AWS moving there and kinda now there's official version essentially of Chalice. And I think there are some still features that Zappa supports that Chalice doesn't.
Speaker 1:But, again, you wanna kinda go with the the AWS kind of version right there and with support that you get from the vendor or you wanna go with open source. And again, there's some pros with open source too with Zappa. But I remember kinda seeing both of those. I'm like, oh, wow. These 2 look very, familiar or similar to each other.
Speaker 1:Yeah. Yeah. They're similar, and I
Speaker 2:think yeah. I think there's some differences. Yeah. Yeah. No.
Speaker 2:It's really cool. I think, actually, the the person who who, like, who wrote the AWS, like, CLI and maintains, like, you know, that and at AWS, are one of the people anyway. His name is, like, James, blankie on his last name, but, yeah, he's the guy who wrote Chiles. And it seems like it was probably, like, just a Hackday thing, like, something he probably started just on his own at AWS. You know?
Speaker 2:But, I mean, it's open source.
Speaker 1:It's a project.
Speaker 2:Yeah. It's it's open source, and it is an official AWS product. And I think, yeah, I mean Yeah. They're
Speaker 1:both open source. Yeah.
Speaker 2:Yeah. But for getting started with, like, AWS, Lambda API Gateway stuff, I think it's just, like, one of the easiest thing if you're using Python, one of the easiest things
Speaker 1:for sure. Before, I actually have, like, it's on one of my GitHubs. Basically, a chalice that's using, like, the schedule CloudWatch scheduler right above the method function to basically back up all your route 53 records and also back up your what else would it be? Back up your security groups. So, all your security group kinda like settings, you could just do, like, you know, loop through the API, describe all the security group settings.
Speaker 1:So you back up all the rules in case somebody makes changes manually. Right? Because I did this as product project. And then basically you just go, okay, re go back and re not revert, but at least or I guess revert because then you can look at the previous settings. You can do that with CloudWatch and stuff like that too, but I thought that would be kinda nice to have on backup.
Speaker 1:Yeah. Kinda Yeah. You know? Well, I did what I needed for that project. But so that was actually my first foray into Chalice, actually.
Speaker 1:And I eventually, of course, converted that to the the Jets application because obviously, I prefer the Jets stuff. But but Chalice was actually, cool to write stuff into. Yeah.
Speaker 2:Yeah. That's cool. Yeah. We should definitely talk about Jets sometime. Yeah.
Speaker 2:No. It's really, really, really cool.
Speaker 1:Yeah. Well, we could talk about it, and maybe, one of the other podcasts is something. It's probably slightly of something that we'll go on tangent with probably. Right? But, yeah.
Speaker 1:But I do stuff with containers and stuff too. I thought you were mainly working on Docker and stuff, man. Last time I talked to you, I thought we're talking about Docker and stuff. I don't remember. It's all blurry.
Speaker 2:Well, I like to do a little bit of everything. You know what I mean? But, I probably was doing a lot of Docker stuff. I think I probably was last time we talked, I was because I I spent a couple of years doing consulting, and I did a, like, a a big consulting thing at this place where, actually, we were doing a lot of stuff with Docker. And, like, pretty early on, they had started moving stuff to Docker.
Speaker 2:And so, yeah, that was interesting. So we did a lot of stuff with Docker there. And we do use Docker where I am now. And, actually, you know, I mean, it's, you know, we use it for unit tests and stuff like that too, even for our for our child space thing. All our unit tests, you know, use Docker containers just for, like, the spinning up the DB locally to do, like, integration tests and stuff like that.
Speaker 2:But, yeah. I mean, our main back in at my where I'm working now is, you know, using Docker for and ECS Fargate for, like, our, TypeScript GraphQL service.
Speaker 1:That's interesting. So you use Docker to test your Chalice application and unit test your Chalice application. So it's essentially just using, like, the MCI image to then kinda run, like, the the the the function through that?
Speaker 2:No. Not for that. I mean, Chalice has, like, some, like, kind of integration testing stuff that it ships with that, like, you you know, they have, like, a test they have, like, an HTTP client that'll, like, call the the Chalice method with, like and it because, like, when you're running in Chalice stuff, it's kinda like, yeah, you're writing I mean, it for, like, the web stuff, it kinda looks like you're writing more like you're writing a web application than you're writing a Lambda function because Charles handles, like, mapping the Yeah. Yeah. The CSO.
Speaker 2:They have, like, testing, and then, the Docker it's using this, like, Python testing plug in. I forget. There's, like, 2 of them that are very similar, but I think it's called, like, pytestdockercompose. And, basically, we just have, like, a, actually, a Postgres Docker container, that we use mostly for the database side because it's I don't know. Everything is, like, very integrated, most of the code with, like, the database.
Speaker 2:So, yeah, but it's really, really cool. I I oh, jeez. I gotta write a blog post about it sometime because it's, I don't know if enough people are doing shit.
Speaker 1:Write blog posts about, man. I'd be interested.
Speaker 2:Yeah. And that's one of the things I hear a lot from, like, other developers is that I think that with Lambda, like, serverless stuff, like, the tooling there is still not great. And I think a lot of people are just confused about it. Like, how do I test this? Or you know what I mean?
Speaker 2:Like, you know so I don't know. It would be good to have more info there and and more more tools, I think, too. You know?
Speaker 1:Yeah. Definitely. I mean, it's also, I think, a hard thing with the tooling is people have different opinions on what should be tested, how a tooling should work, and they come from different perspectives or worlds. Right?
Speaker 2:Yeah.
Speaker 1:Some of them come from the developer mindset and some of them come from the infrastructure mindset. You know? And there's nothing wrong with each of the perspectives. It's just you have to appreciate there's differences there. And there's so it's kind of I think a long time ago when I started my engineering career, I was actually originally an electrical engineer.
Speaker 1:And I talked to the senior electrical guy, and I think he was, like, 50 years old. He's, like, Tom, one thing I learned is if you try to please everyone, you're gonna please no one. And that's just kinda stuck with me. You know? So you're trying to please kinda both, you know, these demographics here.
Speaker 1:Like, 1 of the infrastructure side, 1 of the developer. Right? So it's it's kinda hard to please that way because you're kinda solved for different issues. So, yeah. I'm not saying it's impossible, but I'm saying there's gotta be compromises, I think.
Speaker 1:Think. Yeah.
Speaker 2:Yeah. That's interesting. Yeah. Yeah. I'd love to talk to you more about that sometime because I think that I feel like one of the things just when I look at, like, your you have a lot of open source projects for, like, doing a lot of, like, this kind of tooling and stuff like that with AWS.
Speaker 2:And I think that they all because I feel like you have a really great design sense for, like, making things, like, very developer, like, friendly. You know, just like, like, the stuff that you have for dealing with ECS or whatever, it's way nicer than, like, the Amazon version of it. You know what I mean? So I feel like you have a really good design sense there in making things, like, developer developer focused, I think.
Speaker 1:Well, thanks, man. I really appreciate that. I mean, I think one of the reasons is, I do try to please both the infrastructure side as the developer side. So one of the tools in the ECS space is Copilot. Right?
Speaker 1:Database Copilot? I mess around with that, and it's actually a good tool. I like it. But I have another tool that I actually still prefer to use called UFO. UFO ship is the command to deploy.
Speaker 1:I come up with QC names. It takes me forever. Okay? But UFO ship, basically, it will basically build the Docker image. Right?
Speaker 1:And then push up the registry, and then compile down a confirmation template, and then use that template to ship it off to the ECS service. Okay? So it does all in one step, which is what you wanna do. You wanna make a change to Dockerfile, meaning you wanna press a button, and then you wanna see the change, right, reflect eventually. Right?
Speaker 1:It does take some time. I know there's like some other kind of developer, more focused tools that are supposed to do this in kind of a more tight loop, like even in a second, but like I messed around with those 2 and like I don't know if it's just not quite there yet. But anyway, so that was the kind of flow I was kind of looking for. But here's the thing, that's the developer flow. Right?
Speaker 1:It's all one step. Sometimes infrastructure guys, what they wanna do is they wanna do this in piecemeal. So what you can actually do with the Uofold tool as well as some of the other tools, right, is you can actually run it it in discrete steps, like a step just to build Docker image, a step just to push the Docker image, and a step just to compile the template, right, a step to kind of register a task and all that kind of stuff. So that's where you have to kind of make the balance and trade offs. Right?
Speaker 1:The developer wants a one step where he doesn't he wants to see it as a black box or maybe a gray box. Right? Because they're curious. And then, infrastructure guys, they wanna see it kind of lower level because if they run to, like, infrastructure prompt, they don't wanna be able to debug diagnostically at that level. So, I don't know.
Speaker 1:Thanks, man. I don't know how much of the tools you've used and how much you haven't, but, of course, I use them all the time because what happens is I don't go out there and just, like, oh, let's go create a tool. I go, like, okay. Let's go use, like, Copilot or use another tool. And then when I grind some walls Yeah.
Speaker 1:I I either try to wrap around that, right, like most people do, or they eventually I I create a tool. Yeah. But anyway Yeah. Yeah.
Speaker 2:I don't know. We've been trying to use CDK a lot, you know, which, like, there's some good things there, but then also, like, I don't know. It's, like, a lot of things are way more complicated than they need to be. And, gosh. Yeah.
Speaker 2:Like, deploying a new container takes, like, forever. Right? I mean, doing anything takes forever. It's very slow because it's all through CloudFormation. You know?
Speaker 1:Yeah. Yeah. And you know what's interesting about CDK. Right? So CloudFormation itself is very decorative.
Speaker 1:If you just use the AWS CLI to run a create, or first, if you create a confirmation template and use the AWS CLI itself to, basically deploy the confirmation template, What you're doing is you're just usually just dealing with the YML. Right? And it's a very decorative kinda like way of thinking. And then CDK is like, I don't like the decorative way. I like the procedure way.
Speaker 1:I like I think I like a programmer. So then you, like, you you basically try to write a a program that does it, like a regular program language, you know, which is, like, what developers kinda used to in that sense. Right? But the end day, it still compiles it down with the, I think, CDK synced method. It still compiles it down to actually CloudFormation templates.
Speaker 1:So at the end day, you still have to bug debug CloudFormation. So I'm not, completely against CDK, but my mind actually works a little more decorative here. So this is where I will air more on the side and the infrastructure side. But like you're you're you're kinda saying you're like, oh, yeah. CDK.
Speaker 1:Oh, yeah. It's good. There were some things where it's just like, there's some wrinkles. Yeah. I can tell, like yeah.
Speaker 1:When you run to those wrinkles, it kind of sucks. Right? Especially, like, you have to figure out what CDK is doing. Is it like changing the physical ID or the logical ID, which is gonna in turn change the physical ID, which is gonna result in a replacement of the resource, which might not work depending on the resource. Like a s three bucket, if it's not empty, you can't just replace it.
Speaker 1:It's not gonna work. Yeah. Yeah.
Speaker 2:No. They've they've been they've been really it's like, I think one of the things they try to do is, like, make things easy. So they have, like, these constructs where it's, like, they pick the defaults for you, which is fine. But the problem is, like, every release, they, like, change the defaults. And so, like, you make, like, no changes, and, like, you upgrade the CDK version.
Speaker 2:It's just like, woah, what's it doing? It's trying to, like, change this and change that. And it's like it's just I don't know. I wish they were a little more conservative with those. I mean, there's some things I like about it is they have some higher level constructs for, like, doing stuff like, yeah, for, like, deploying Lambda functions.
Speaker 2:They have the Lambda function 1, which is, like, you know, just like the CloudFormation, but then they have a Node 1 or a Python 1 that actually, like, spins up a Docker container locally, installs all the dependencies in the container so that they will run, you know, the correct Lambda architecture, and then, uses that to deploy. So I think there's some cool opportunity for, like, high levels, or, like, the Chalice. Like, we're using the Chalice has CDK support too. So you just say, like, new Chalice app, and you pass in, like, the the stuff with your Chalice stuff, and it handles, like, doing everything for you. But I don't know.
Speaker 1:It's just been doing CDK for, Larry? How long?
Speaker 2:I think I guess it's been about 3 years now. It's been a while.
Speaker 1:Oh, wow. 3 years of CDK? Like, on a regular basis? Like, at least once a
Speaker 2:week? Yeah. Yeah. I guess so. Well, Yeah.
Speaker 2:I don't know. I just we don't have it depends. You know what I mean? Like, some weeks you're doing more infrastructure stuff than others, I
Speaker 1:guess. Right.
Speaker 2:But when we first started I've been at this company for over 3 years, and, we've been using CDK from the beginning. So,
Speaker 1:So you've been through the ins and outs of it at this point. Right? Because I would say, like, you have to use it probably regularly for, like, 2 or 3 months, and then you kinda start seeing the works. Right? Then you start feeling some of the pain
Speaker 2:and you start seeing the pain. Well, yeah. That's the thing. I think you you really see it when you're, like, trying to that's the thing is just, like, I think after a while, I kinda got used to it. But then, like Yeah.
Speaker 2:Someone asks someone asks you for help or, like, help you debug something or, like, what or they'll just ask you, why is this so hard? And you're like, I never really thought about it, but you're right. Like, it is kinda nuts that I have to, like, you know, do all this stuff to, like, configure this thing or whatever. I don't know. And it's not all the CDK's fault.
Speaker 2:I think a lot of it is, like, CloudFormation or even AWS. Like, I think it's still, like, too complicated for hooking, like, different services up to each other in terms of, like, the I'm permissions and things like that. Like, that's not really CDK's fault necessarily. But, I have to You know,
Speaker 1:I know we're talking about AWS and CloudFormation CDK, but you know what? Terraform has basically, equivalent to there's a term from CDK now. They released a couple months ago. So it's also like they're trying to fill out that market gap too, I guess. And remember Terraform is more like CloudFormation directly, and then Terraform CDK is like the AOS CDK.
Speaker 1:Right? Or you're using a programming language, but it still compiles it down, I believe, to JSON notation. I'm not exactly sure actually. I will have to play with it, but, yeah. I don't know.
Speaker 1:There's I guess there's always, like, this gap where people try to do every I didn't know you did it for 3 years. That's crazy. I mean, that's probably more than most people because CDK has only been around for 3 years. Right? And then like you've been deep in the weeds, so you kinda see the words.
Speaker 1:Like, you've done it more than me. I mean, I basically looked at it, and there's another guy. What's his name? He's a container hero. Container hero.
Speaker 1:What's his name? It's slipping my mind right now. But anyway, he's in Germany. Trying to look up his name right now. But anyway, he loves and he swears by CDK.
Speaker 1:So he loves it because, again, once you have like the, I guess a construct that's good enough and you're used to the words, you can you can basically do pretty powerful things with just a couple slight changes. And you could, you know, because you could create your own programming constructs unlike, you know, like, you know, it's much harder to do that with CloudFormation with Lightning Health. Right.
Speaker 2:Yeah. Yeah. Yeah. But,
Speaker 1:you could create your own program constructs, pass your own parameters in there. Macie, he uses to build containers and all that, and he swears by it. He just loves it. He's the one that first introduced me to CDK, like a 2 2 or 3 Philip Garb. That's his name.
Speaker 1:Yeah. So yeah. So he so he's he swears by CDK. So you and him will probably get along.
Speaker 2:Nice. Maybe we can have him on the have him on the podcast.
Speaker 1:Yeah. I'm sure. I mean, yeah. He I think he even wrote couple blogs about it. Some of them on the 8 o's official blog too about CDK.
Speaker 1:Because, like, yeah, Philip is really into, like, the CDK and stuff. See, like, I'll just be, like, honest. Like, I want I I like, they did CDK. I was like, oh my god. This is like abstraction, but then you it still leaks, and you still have to kind of see and understand the CloudFormation.
Speaker 1:So for me, it kinda drove me nuts a little bit. And I was like, oh, screw this, but I can see how it can be powerful. Right? And if I had to do it, I would do it. And it's it's not that big of a deal.
Speaker 1:I'll just do it. Now I do have a question about CDK. Does it give you a preview of what it's gonna change? Is there like a preview or a plan command or a dry run command for CDK? Is there one yet?
Speaker 2:Yeah. There is. Yeah. There's a there's a diff there's a diff command. So, yeah.
Speaker 2:It'll tell you what it's gonna change. But, you know, yeah.
Speaker 1:The diff, is that essentially the CloudFormation change set? Is that a change set, essentially? Or is that, like a code diff? Or what what does the diff kinda show you?
Speaker 2:I guess it is like the change set. I mean, it shows you, like, yeah. You know? It you know, it'll be like we're change you know, we're we're changing, I don't know, like, adding these things to this policy or we're, you know, changing this value to this value or adding this DNS record. So, I guess it is like a So
Speaker 1:So Yeah. So that change set, does it show you attribute level changes or just a high level like this, resource, like clock or like essentially confirmation resource is gonna be modified, deleted, or added? Is that high level, or is it, like, attribute level?
Speaker 2:No. Yeah. They they show you, like, the attributes, for, you know, for some things. I don't know. I guess it probably depends on it probably depends on, like, the the resource, because it's definitely not it's definitely not consistent, you know?
Speaker 2:I think some things are better than others.
Speaker 1:Oh, interesting.
Speaker 2:Yeah. But that part is cool. Yeah. We actually even have, like, a neat, like, a GitHub, kinda, like, hook that, like, whenever we have a PR open against something with, CDK, it'll automatically do CDK diffs, and then it'll post those to the the pull request. So
Speaker 1:that Is that custom to your company?
Speaker 2:Yeah. Or is that Yeah. We should we should yeah. It's custom. We should open source it.
Speaker 2:I mean, it's like yeah. Yeah. We should we should open source it. It's like it's just running CDK diff and then posting back to the to the poor request. You know,
Speaker 1:it's just nothing easy to think. Something. Yeah.
Speaker 2:Yeah. Yeah.
Speaker 1:That's pretty cool. Yeah. Because the disk command would be very, very useful. You know? The plan command is actually useful for dry run or whatever you wanna call it.
Speaker 1:Yeah. Like, so there's another tool I've I've been working on and off called Lono. It does actually diff, but it uses essentially CloudFormation chain sets sets as one of the diffs. And why I say one diffs is because I actually do 3 different diffs. I found 3 different diffs to actually be helpful.
Speaker 1:Because CDK, you don't really cast parameters. I think that's frowned upon in the CDK world. With CloudFormation, you basically build a CloudFormation template and you're supposed to, be able to deploy different variations of it via parameters. Right? Like run time parameters.
Speaker 2:Yeah.
Speaker 1:But in the CDK world, it's like more encouraged to like know write it into your code. That's my understanding of that at least, but it might be outdated. That was like 3 years ago when I was talking to Philip about it.
Speaker 2:Yeah.
Speaker 1:But anyway, so because of that, the only diff is gonna be a code level diff. And I thought it was gonna be like a change set, but it sounds like it does some changes and depending on the resource type, it's gonna also provide you attribute level differences or property level differences. So which is pretty sweet because that's what a Terraform plan will kinda do. And there are some benefits with that. There's you know, there's some things that are annoying about that too because the output becomes a little verbose.
Speaker 1:Anyway, eventually what I kinda end up doing was I had 3 different types of diffs. I changed that diff, which is a high level diff. Then I had a basically a parameter diff. Because remember, I'm I'm basically manipulating top CloudFormation templates directly. So I actually wanna see what the parameters are too.
Speaker 1:And then 3rd diff, it's actually a high level, basically looks like git diff. It's up. You know how when you do like a git diff dash dash stats or I think dash yeah, stat. It gives you a like high level summary of number of lines added and number of lines removed. And then it spits out like a diff command so that you could diff basically the, existing template that has already been previously to deploy versus the, newly generated template.
Speaker 1:Then you can actually see the line by line diff and all that. But I found actually all of those 3 diffs, diffs help a lot in kind of understanding what the heck is happening. It's I mean, it's still, you know, it's still not perfect. Nothing is perfect. That's a problem.
Speaker 1:People think, oh, I know I knew CDK. Now my life's perfect. No. Or like confirmation. Now no.
Speaker 1:I think it's perfect. You know, it's it's not like there's like you know, and and maybe later on down the road too, like, you know, a year down the road, you know, these courts are the I mean, these warts around CDK, a lot of them have been resolved. Maybe the abstraction level is, like, you know, done more close to reality. And then at that point, all of a sudden CDK wins, right, versus, CloudFormation raw. Until that abstraction gets to the point where it helps you more than it gets in your way, I don't know.
Speaker 1:I I'm finding it difficult still. Right? And maybe it's also because there's some custom distractions that maybe Phil was written or you have written. Right? That just makes it a little easier.
Speaker 1:I don't know. There's a lot of maybes in there because that's how it is. Right? It's just kinda like the the the it's it's a little bit hard to have a, a definite answer when the world software is moving underneath your feet, like, sometimes like quick sand, dude. You know?
Speaker 1:Yeah. You're like, oh, dude. Yeah.
Speaker 2:Yeah. No. I think they'll always
Speaker 1:be different than renting. Different things. Yeah. I'm learning something about CDK in this already, so that's pretty cool. Yeah.
Speaker 1:Yeah. I I don't mess around with CDK. Basically, I messed around with it a couple years ago when Phil introduced me. I threw up a lid in my mouth, and I kinda moved on. And then No.
Speaker 1:No. CDK is cool. Okay. Goodness, guys. Yeah.
Speaker 1:All of a sudden people are gonna be like, oh, you hate CDK. I don't hate CDK. I think, again, I think it'd be good to abstract it at the right level. Actually, I would like to have a project working on it and, like, get my hands really dirty. Like, do what you're doing.
Speaker 1:Like, 2 or 3 months to it? And then I
Speaker 2:mean yeah.
Speaker 1:You know? Unless you build off those battle scars, you don't really know. Right?
Speaker 2:Yeah. That's true. Yeah. Yeah. No.
Speaker 2:And I think I think a lot of my complaints with CDK aren't really CDK. It's more it's more CloudFormation. So maybe I'm I'm gonna be
Speaker 1:Oh, yeah. Plunking finger. No. I'm just kidding. But yeah.
Speaker 1:Yeah. I mean, yeah. Because that's what CDK does. It compiles down a confirmation template, and then it's gonna be limited to confirmation. The funny thing is, let's see.
Speaker 1:I ran into, like, a Jets bug. Not really a bug, but this so Jets basically is a serverless framework, right, but deploys Lambda functions. But at the end day, it deploys Lambda function API gateway routes, but at the end day, it's just compiling CloudFormation templates. So guess what? At the end day, I can do the same thing you're doing with CDK.
Speaker 1:Oh, it's not really CDK thing. It's not really Jet's thing. It's a CloudFormation thing. Right? So, you're gonna be limited by whatever the bottom, you know, the thing underneath it is kind of doing.
Speaker 1:But the reason why CDK is used in CloudFormation is the same reason why the serverless JS framework eventually, used CloudFormation. Because remember, the serverlessjs framework, which I think is still the most popular framework in the serverless space, it's just basically compiling down CloudFormation and then deploying Lambda and API gateway via CloudFormation. But at the very beginning when Austin was working on it, right, it was making raw API calls, dude. It wasn't using CloudFormation as an additional layer. Yeah.
Speaker 1:But then if you're making a raw API call, it's it turns out orchestration is the pain in the butt. Right? Basically, let's say you delete a Lambda function, you need to maintain state somewhere. You need to remember that you deployed a previous function, and then later on down the road when you're doing deployment again, like, you know, like, think about it this way. When you write a method, right, programmatically, right, with, let's say, CDK, and you basically write methods say, hey.
Speaker 1:Create me a Lambda function or create me a s three bucket. Right? Then you deploy, it creates a Lambda function or an s three bucket. And then you delete those lines of code. Right?
Speaker 1:In a regular API call, you actually have to write methods to say delete the bucket, delete the lambda function. Right? You can't just delete the bucket. The lines of code is like, oh, magically, it just knows. Right?
Speaker 1:Exactly. Like, people don't, like, realize this. Right? Like or maybe most people do. Right?
Speaker 1:Maybe it's just me. But then you have to kinda realize that's why the CDK is using CloudFormation underneath the hood because CloudFormation keeps track of state for you. Keeping track of state and deleting that Lambda function or the s three bucket later yourself, you're gonna need a database, man. Right? You're gonna need something to keep that state.
Speaker 1:Right? But CloudFormation is handling that crap for you. Right? I mean, if you're in the Terraform world, right, there's like this whole debate about like the first thing you do with Terraform is like, oh, no. I got managed state.
Speaker 1:Well, this is the beautiful thing about CloudFormation. It handles state for you. Right? But then Right. People who are used to Terraform is really fun.
Speaker 1:And they go, man, I miss the state. I miss I basically miss being able to inspect the state directly and and manipulate in that state directly when I have to, when somebody makes a manual change outside the purview or the vision of CloudFormation or Terraform in that case. Kinda interesting, actually.
Speaker 2:Yeah. Yeah. Yeah. Yeah. I think they yeah.
Speaker 2:I think they CloudFormation has been working on some stuff for, like, for remediating those those changes into your CloudFormation stuff. But I don't know, man. Yeah. They need to dump more resources on cloud formation. It needs a lot more love.
Speaker 1:Yeah. They always need a lot more love. I remember 2 or 3 years ago, talking to the guy who runs the AWS Heroes program. Right? He was like, yeah, they're kind of reorganizing, reshifting the organization so that instead of like a separate, CloudFormation team, they're gonna basically have people on the dedicated teams like ECS or serverless.
Speaker 1:And then they're gonna basically kinda be the CloudFormation person within that team. So then they can kinda get things integrated quicker. Right? I don't know if they ever kinda reorganized the organization to do that. But you know, it sounds like a good idea.
Speaker 1:I don't know. You know, it's because CloudFormation support's always kinda lagging. Sometimes behind open source communities. Sometimes behind Terraform. But, like, it just depends.
Speaker 1:Sometimes Terraform's actually lagging too. There's been some open pull requests for 5 years. 5 years, dude. I mean, I think Terraform is like a $1,000,000,000 company. You know?
Speaker 1:Like, where does that $1,000,000,000 go? Not to that pull request. You know? So it's just it it's kinda crazy. It's just that's just nature of the beast.
Listen to Cloudy with a Chance of Code using one of many popular podcasting apps or directories.