Unifying Cloud Development: The Evolution of Infrastructure from Code

Infrastructure as Code (IaC)

Eric Johnson: We're back for another "GOTO Unscripted." My name is Eric Johnson. I'm gonna allow the folks to introduce themselves. I'm gonna start over here with Adam Keller. Tell them who you are, what you do.

Adam Keller: Thank you, Eric.. Wonderful introduction. My name is Adam Keller. I'm a senior technologist at AWS. I've been with AWS for a little over five years. But previous to working in AWS, I led platform teams, DevOps teams. The topic of cloud infrastructure as code, automation DevOps, serverless containers, all these really great things. I just love to talk about them. So I'm really looking forward to having this chat today.

Eric Johnson: This should be a cool one. Elad Ben-Israel, I'm gonna turn it over to you. Tell us who you are, what you do. And yeah, there you go.

Elad Ben-Israel: Hey, I'm Elad Ben-Israel. Good to see you guys. It's been a while. I'm the founder of a company called Wing Coud. And previously spent some time at AWS, about seven years. Before that, at Microsoft. And basically been programming my whole life. And at AWS, my last job was to build the AWS CDK. So I had a lot of fun doing that. And excited to chat about infrastructure, infrastructure as code, infrastructure from code, and all the variations and the evolution. It's definitely something that I've been actually doing for probably 20 years already.

Eric Johnson: It's interesting, when I tell people... So Elad is pretty humble here. But the truth is, we talk about infrastructure... I love to say, "Hey, do y'all know who Elad Ben-Israel is?" And you've kind of kept your name secret, right? So I'm like, Elad Ben-Israel... "Well, yeah, I kind of know who... Yeah, yeah." "Have you ever heard of a little project called the CDK?" And, "Oh, yeah, yeah. We love it." Well, Elad Ben-Israel, actually, and I know you said you worked on it. But that's not true, you actually created it. It was your baby, right?

Elad Ben-Israel: One of my babies.

Eric Johnson: One of your babies. That's right. And so obviously, a lot of credibility in building infrastructure as code, right? So, I kind of want to jump into this. And Adam, I'm gonna go to you first. If you're just watching this, and you don't know what infrastructure as code is, Adam, can you kind of tell us what it is? In your world, what is infrastructure as code?

Adam Keller: So infrastructure as code, when we think about it, it's quite simple, actually. You know, we want to build resources. We want to build...whether we're building in the cloud, building in the data center, wherever you're building. Previous to infrastructure as code, how did we do it? Well, we provisioned things manually. We'd go to UIs. We'd write scripts. We'd write automation. When things changed. Right? We'd have to keep track of changes and try to figure out how to, you know, ensure that we're not messing things up when we make changes, and that we are able to do all this simultaneously. Infrastructure as code was born to help solve these problems, to give you a centralized way to define your desired state of how you want your infrastructure to run. And I'm going to be honest, we're at a point now where we're in the cloud... You know, we have services like Lambda. You know, there's serverless technology. We call it infrastructure. I kind of just like to call them cloud resources, or just resources.

Because really, we're not managing a whole lot... I'm not racking and stacking at this point. But I'll digress there. But the idea is, you're able to define your desired state, and then take that desired state configuration... And, you know, when it started, it was...you take CloudFormation, TerraForm. So I'm using, like, JSON or Yamo, some sort of, like, declarative language, or HashiCorp has HCl, which is their DSL, which is a really elegant way to define your infrastructure as code. And then you send it to the infrastructure code engine. And it's the job of that service or that tool to make sure that that desired state is deployed. And if there's any changes, it's going to make sure that it tracks those changes and applies those changes accordingly. So that's kind of high level how I like to talk about it.

Eric Johnson: No, it was good though. I think there's some... Because we're going to dilute this, or we're going to convolute, or kind of climb in and change this up here in a minute. Because we're gonna move from infrastructure as code to infrastructure from code. And Elad, now I'm gonna ask you. So, from infrastructure as code, talk about... And first let me ask this, do you call it infrastructure from code or what do you call Wing or these Wing type languages?

Elad Ben-Israel: So we actually call Wing, infrastructure plus code, and decode.

Eric Johnson: Times are flying here.

Elad Ben-Israel: Because I actually just, you know, thought about kind of, like, the evolution of this term. And I actually think that, you know, Adam Keller's digression is interesting. Because I feel like the cloud has evolved from the IT world in a sense, right? Like, it's kind of like the evolution of the data centers. And so, the system administrators, and the IT operators. And their world was about real infrastructure, right? Like, about data centers, and power, and network cables. And it made sense to call IT infrastructure. And we've completely diluted this term, as a cloud industry, right? Like, we kind of, like, oh, yeah, this is the same as a computer...or the power grid of the data center. But it's like, as far from infrastructure, as physical infrastructure that you can get. And I think the term as code is also kind of misappropriated in a way. And there was actually a really heated debate... Corey Quinn, I think, or not Corey Quinn. Anyway, there was some…

Recommended talk: Infrastructure as Actual Code • Gregor Hohpe • YOW! 2022

Eric Johnson: If there was a heated debate, Corey was in there somewhere, probably. Call out to Corey Quinn, there you go. Yeah.

Elad Ben-Israel: But when we released the CDK, we actually posted a job posting, and it was Jason Fulghum, if I remember him, who worked with me on that project. And so he posted a job posting, saying, "If you want to work on infrastructure as real code." And that stirred up a whole, like, Twitter...

Eric Johnson: Yamo as code, too.

Elad Ben-Israel: Yamo as also code. And JSON as also code.

Eric Johnson: Here we go. Here we go.

Elad Ben-Israel: You know, and I think, like, the word as code is also kind of, like, not really the right term in that sense. Because I think that it came from trying to basically use the same workflows that we use for code, use them for infrastructure. Which means, you know, you write some description of how you want your infrastructure to look like. You committed into a git repository, they're a CI, they're a CD. Like, all that stuff that we've been applying to software, we're now applying to infrastructure.

And I think, like, that's kind of like taking these two terms that basically are not the right terms, and combining them. And that became very popular... So, you know, I've been thinking a lot about these terms, as we've been building Wing. Because the way I see Wing is about unifying these two worlds together into a single model. And so it's not about thinking about infrastructure separately, or code separately, as first class citizens, but think about both of them as first class citizens. Because to me, when you're thinking about the cloud, this is the essence of the cloud, right? Like, it's basically this combination of infrastructure and application code, that form your application, that form your actual system, you know.

Bridging Infrastructure and Application Development

Eric Johnson: So I want to jump back for a second here. Because both of you, you've talked about this, and I want to dig into this a little bit. Especially for those who are... Look, I'm new to the cloud, which shockingly is still the case, a lot of times. We have a lot of new cloud. I know that...

Adam Keller: It's a big world out there, you know.

Eric Johnson: Exactly. We live, eat, and breathe this. But I'll digress for a second. I spent a lot of time last year and the year before going around to different universities. And it was shocking to me, I would ask students coming out with CIS degrees, "What kind of cloud work are you doing?" And literally, it's like, "What are you talking about?" "You know, have you heard of the cloud?" "iCloud?" Okay, that's a start, you know. So it's shocking how new the cloud is sometimes. And Adam Keller, you talked about this. And this is the world we live in also. But the separation of infrastructure and your code has gotten closer, and closer, and closer, the kind of merging and the resource. Expand on that a little bit. So how is that affecting kind of how this is driving how we're building?

Adam Keller: I love that. That segue was awesome.

Eric Johnson: Did you like that?

Adam Keller: First of all. That was really good, Eric.

Eric Johnson: If you didn't. But if we're good, we'll take that.

Adam Keller: Like, that was just, homerun. I love this question. Because, look, we have to look at how we've evolved. And Elad touched on it. We started with, you know, the two silos, the operation silo and the developer silo were two very distinct orgs, big walls in between. And, you know, one was just focused on one thing, one was focused on their own thing. But, you know, what we started to see is, as the cloud, as building resources in the cloud started to kind of change. And again, it wasn't just racking and stacking, it wasn't only provisioning servers for then someone else to go launch what they went on to that. But we're starting to see the application code and the infrastructure code move closer together. And I think it's because these worlds are the...what you're managing underneath is becoming more obfuscated from the user. And I think infrastructure as code, when it started, it was very much, I define my resources, and then someone rsync their payload in, or they kind of deploy their infrastructure that way.

Eric Johnson: Rsync. Nice, sounds nice.

Adam Keller: I used to use a Python tool...

Eric Johnson: You could have, yeah, yeah. But he went with rsync. That means he's a real developer, right? Or operations guy.

Adam Keller: No, no, no. SFTP or FTP, you know, if we want to just get rid of security there. But yeah, just go plain text. No encryption. But anyway. So what we've seen with infrastructure as code is traditionally, it was you define your infrastructure as code, and then you define your code pipelines. And you have to kind of figure out how to connect the two together. And this could be challenging, because you... If I'm deploying a... You know, let's use AWS, let's go with a simple example of, like, an ECS cluster, I'm deploying ECS, which is our container orchestration service, one of our container orchestration services. So I deploy my cluster, I deploy all these things, you know, kind of dependent resources. Now I have to think about that container image. And I have to build the image, push the image, gotta test it. I gotta do all these things. And then I got to figure out, how do I get that image to that cluster? So, typically, those were two separate things, two separate pipelines.

Eric Johnson: And two separate people too, right? It was generally two separate groups that did that.

Recommended talk: 10 Learnings From Running Production Infrastructure at Google • Christof Leng • GOTO 2023

Adam Keller: So what we've seen with tools like the CDK, you know. Like, the CDK is... The AWS cloud development kit is just...it's chef's kiss. It's an amazing tool. It was, you know, as someone who had been building in the cloud for years, and using infrastructure as code, it was like the thing I wanted, that just I could never fully articulate. And then when Elad and team came out and built it, it was like, this is it. This is what I want. I have been working with the CDK since the very early versions, and it's just, you know, only gotten better. But my point is, the CDK introduced these abstractions, these higher-level abstractions. And one of those is the assets module and the assets library. And what that allows users to do is, now I can define my infrastructure code using, you know, a programming language, leveraging all these cool abstractions. But also, I can bring my application artifacts and couple them with my infrastructure code.

Now, I don't have to worry about two separate locations of deploying...you know, two different people deploying these things. We can bring them into one place, and we can manage all of our changes in one location. So, I think this is, you know, very... I think we're still early days in infrastructure as code. I'm talking a lot, but, you know, Eric, you mentioned some folks don't even know about infrastructure as code. The reality is, there's still a lot of people out there that build in the console, that build using scripts. And there's nothing wrong with that. They're still just now coming into infrastructure as code.

Elad Ben-Israel: We're just a little bit judgmental.

Eric Johnson: Exactly.

Adam Keller: You know, but anyway.

Eric Johnson: I would add on to... Go ahead. Go ahead, Elad.

Merging Infrastructure and Application Concerns

Elad Ben-Israel: I just wanted to add one thing, Adam, to your point about the container example, or the Lamda example. It's not just about the deployment side of things, it's also about the surface area, right? My container usually doesn't run in isolation. It doesn't just do stuff in, like, a vacuum, right? It usually interacts with the rest of my system, either other services or other cloud resources. And that's why this decoupling really matters. Because if these were completely separate worlds, and my container could run without caring about this environment, then for all intents and purposes, the deployment story could have been decoupled, right? It might have even been a reasonable thing to do, because I don't want to wait for my infrastructure in order to deploy my container.

But if they are coupled, and I think, like, there's a spectrum of applications where on one end of the spectrum, is this really isolated unit that just, you know, processes some data and doesn't do anything with the environment. And the other end of the spectrum is step functions, I guess, right? Like, it's basically something that has, like, a huge surface area with the cloud. Then the more you kind of lean on the cloud, the more your application code uses the cloud, the more this decoupling becomes inevitable. Because otherwise, you won't be able to actually, like, you know, orchestrate this deployment ever, right? Because you're... To me, this is actually one of the motivations for Wing, you know. Happy to...

Eric Johnson: Well, I feel like... And going back to what Adam was saying, and even earlier, talking about, you know, when we introduce services, right? So now we're not doing infrastructure. And so we need it. And I know you're saying coupling, but I say emerging. You know, when we're talking about the idea of, if I'm building, I'm going to quickly... Instead of me doing blocks of code in my code, I'm chaining together services, right? And so, it makes no sense to have operations say, hey, I need amperage, or hey, I need SQS, or, hey, I need SNS. As a developer, I should just be able to plug those in. And so, yeah, you're right, it's inevitable that we're coming closer and closer. So, with that, and Elad, this is coming to you. So you built... And I'll talk about my CDK story as well. I remember I worked at Rackspace. I was working there, and I was actually building something. And it was like, ooh, something new and shiny. I mean, if it's new, I'm gonna play with it. Right? And I'm gonna put it in production immediately. I'm that guy.

And if you've spent any time with me, go, yeah, you're that guy. But I remember playing with it, going, oh, my gosh. In fact, and he should not deny this because it's true, Matt Bonig, shout out to Matt Bonig, who's amazing. I introduced him to CDK. I said, "Matt, have you checked this out? This is the coolest thing ever." He became Mr. CDK. So that's my claim to fame. I didn't write no CDK book, but I introduced the guy who did to the CDK.There you go. It begs the question here, you built this. It's used globally, right? Everybody's used it. You heard Adam Keller say it's chef's kiss. It's the perfect thing. Why didn't you just stop there? I mean, you're an overachiever. We all know that, and stuff. And it's a little disgusting. But why didn't I just stop there? Tell me that.

Elad Ben-Israel: So first of all, it's really, really fun to see people use the CDK. Like, almost every customer we go talk to is using the CDK. And it's really amazing to see what people are building.

Eric Johnson: And SAM is pretty awesome too. Just throwing it out there. So, whatever, but go ahead.

Adam Keller: Yes, it is.

Elad Ben-Israel: I actually think SAM was... We borrowed a lot of ideas... Like, in a sense, if you think about SAM, these are the first constructs, right? Like, these pseudo resources that represent higher level abstractions. And I think a lot of the philosophy around the CDK was, like, let's just create an ecosystem of those things, right? Like, so it's not just like these three, four constructs. It's like a whole ecosystem, and it's open. And it's open source, and extensible, and blah, blah, blah. So I think, like, SAM definitely has a lot to do with the evolution of that thinking, because it did exist before the CDK. And, you know, I've been preaching to try and, like, merge these two technologies on top of each other. So yeah, it's really fun to see the usage of the CDK in the community. And in fact, what we're doing with Wing, it's built on top of the CDK. Like, it's built on top of CDK technologies, on constructs, on JSI, on AWS CDK, and CDK for TerraForm. In a way, it's kind of like a meta CDK.

You could compile Wing to AWS CDK, or to CDK for TerraForm, or to CDK for Kubernetes, and use all of the constructs in the CDK ecosystem. But one of the things that we've done with Wing that I think is very different from the approach that we took in the CDK, and one of the lessons that I took building the CDK, and related to what we've talked about just now, is that despite the fact that infrastructure and application code kind of got together, I think there's still a place for decoupling between the platform and the application. Because those are really different concerns, engineering concerns. And when you go to talk to companies that are not Amazon, then the world is actually, you know, in a very different mindset. You know, you have a company like Airbnb, or Fiverr, or any other company, their application developers, the engineers that are building the application, their problem domain is renting apartments. Their problem domain is not setting up VPCs, and subnet masks.

You really don't want that to be their problem domain. You want them to focus on optimizing the algorithms for figuring out which apartments to rent. But there are platform teams whose problem domain is to figure out the compliance, and security, and networking, and all this stuff that's part of the platform side. And I think what we didn't do in the CDK, we haven't created this line. We haven't really said, okay, this is the line that separates the application and the platform. And so to that end, what I'm seeing is that CDK is mostly used either in the serverless world, where people basically have to own their entire stack. Like, they really don't have any choice. And in many cases, they're not happy with that, right? Like, they're not happy having to own the entire stack. Or you see CDK being used by DevOps engineers. And then application developers are still kind of, like, okay, I'm just building my container, I don't care about what's going on in the cloud.

And that's the problem we're trying to fix. Because to me, this means that, you know, in either mode, you're not really leveraging the cloud in the right way. Because of one mode, developers are not empowered at all, the container world. And on the other end, there is no clear separation between the platform concerns and the application concerns. And so, what we're trying to do with Wing is we're trying to basically put this line that says, this is the boundary between application and platform. It still uses CDK concepts. So you're still using constructs to define resources. But when you're defining those resources from the application perspective, you're interfacing with the resources functionality. You're not interfacing with the resources platform concerns.

And so the best example we have is, like, encryption, right? Encryption is not an application concern, in most cases. It's a platform concern. And so when you're defining a bucket or a queue in Wing, you just say, I want a bucket. I want a queue. It's a functional unit in my application. It serves a function. And so that's something that application developers care about. They understand because it's helping them solve a problem in their domain. But the concern to encrypt the buckets and the queues comes from the platform side. And Wing has this concept of platform providers, where you can inject those concerns below the abstraction, below this line. And so that's actually, you know, one of the main things, I feel, one of the main differences between the way CDK thinks about the world, and the way Wing thinks about the world. Technically, a different persona, even. Definitely a lot of challenge to get that through.

Balancing Opinion and Customization in Cloud Development

Eric Johnson: Well, I've heard you explain it before. And it does make sense to me. Would it be fair to say these are primitives you're building? Maybe that's not the right word, but that's how I've always kind of explained it. These are primitives, they just do what the developer needs. But we haven't forgotten the fact that we need governance, we need those kinds of things brought in through the other layers. So that's really interesting.

Adam Keller: If I can just add... So I do think it's a valid point. I think personas are really important to just talk through it. Because when you choose the tool, every organization is different. The persona, you know, whether it's... It really comes down to who's using the tool and what your organization structure looks like. You know, Conway's Law, ultimately, I can get the most advanced, cool tool in my company, and if we operate as if we're waterfall, and it's 1995, that tool is not going to serve us well. But I will say, the platform problem is real. And we see it. You know, the platform engineering has really grown, where we have now these bigger, larger central platform teams. I do think platform engineering is really big in the Kubernetes space, right? Because you're managing these large clusters, orchestrating them, and vending things to your end users, your developers, and so on.

I just wanted to say, I do think the CDK...I see it with larger enterprises, the larger customers, that the platform teams are building these, you know, constructs, they're extending the abstraction through aspects. Which obviously, Elad, you're very familiar with. But they're leveraging their own constructs and their own higher-level abstractions that they sell to developers, which developers use. And things like encryption, and the things that the developers really don't care about are abstracted. And you can set those as defaults to make sure that when the developers deploy, they're doing it in the way that we, as the organization have deemed safe and secure. But I do see a huge upswing and a huge uptick from just customers that I've been talking to, and users of the CDK, specifically in the platform space. So there's a huge boom there.

Elad Ben-Israel: And so, in a sense, what we're trying to do with Wing is generalize this problem, or kind of generalize this pattern, because it doesn't make total sense to me that every platform team in every organization will have to build this construct library for their users. And one of the things that we're doing with Wing, which I think is something that we see, actually, really a lot of traction with, is, because we've created this layer, we're able to create a simulation below. So you can actually plug in a different platform provider based on not just your organization, or your policies, or your cloud environment, you can also plug a different platform based on the stage of development. And so you can say, when I'm developing, I just want to use a simulator, a functional simulator of this platform. And when I put an object in my bucket, it just goes into my disk, because I don't need it to be replicated three times across two different regions when I'm debugging my code locally. Or when I'm running my test in my CI system.

And so I think, like, this idea of not only generalizing this pattern of creating a standard set of resources, but also establishing the layer, basically saying, this is a good abstraction, I think, like, creating a good abstraction is really hard. And I don't think that's something that every platform team out there can do well, right? I also think that it's very hard for us to do well, but I think that's why it makes sense to say, okay, let's invest in this, right? Like, let's invest in figuring out kind of, like the POSIX of the cloud, right? Like, the layer that separates the application and the platform. It's a big challenge, you know. And so, Eric Johnson, you asked why I'm doing this, because it's challenging and a hard problem, I guess.

Recommended talk: Building Evolutionary Infrastructure • Kief Morris • GOTO 2019

Eric Johnson: I know you and I've had that conversation a lot. I've been a fan of Wing for a long time as well. I've been driving Elad nuts. How do you do this? How do you do that? But we've had a good time. Yes, I find bugs for Elad sometimes. But yeah, the idea of the... And I think you actually said this, and we can edit this out if you didn't. But we won't. But at one point you said, I mean, CDK is phenomenal... But it wasn't just CDK, you were talking about SAM as well. CDK and SAM are great, but they weren't quite enough. It wasn't meeting the needs of the developer. And we had talked about the developers looking for... And I actually believe. You know, I've kind of come full circle, for a long time, I would say, look, get to the cloud as fast as you can. You should test in the cloud, things like that. And that's a great kind of dream, but it's not a reality.

The reality is, developers want a single pane of glass. They want to build monolithic apps, same stream, but they want to run the microservices, right? They want the power of distributed apps, they want the power of, you know, decoupling, but they don't want to build that way. Because I gotta build a little bit over here, I gotta build a little bit over here, I gotta do some over here. And a lot of that's kind of a serverless, I wouldn't say, problem, but a challenge, because it is a different mindset. But you had said, and you can certainly tell me I'm wrong. But you had said, we didn't feel CDK, or SAM, or even TerraForm, or something like that, wasn't quite enough for what the developers wanted.

Elad Ben-Israel: I think it's basically, you know, what I talked about earlier, is this layer that allows developers to actually build their applications and focus on their functionality, and the function of their application, the business logic. But the business logic, not in terms of, like, the thing that runs inside the container. The business logic of the system. Right? And I think that's the point. Right? Like, the point is that in a way, Wing, I feel is more compatible with the roles and responsibilities we had before the cloud, where we had a centralized platform team, right? Like, we actually did have that model in the past. And their concern was to be responsible for the platform. And back in the days, the platform meant data centers, and servers, and power grids, right? And now it means a Kubernetes cluster, and IM policies, and the VPC, and a bunch of other things, right? But I think, like, that decoupling actually makes...to me, makes sense. I feel like it's a healthy decoupling. And I think one of the reasons it's hard for people to go to the cloud is because we don't have that decoupling today.

Adam Keller: There's another challenge here that, first of all, I will say, like, with Wing, that local testing experience is really nice, getting that visualization. And really, that decoupling there, you see it when you're testing locally. Like, the abstraction is good. But I do think there's something... And I think this is a longer term problem we're all trying to solve. Which is, abstractions are good. Abstracting is much away from the user that they want abstracted away is a good thing. But it becomes challenging for the day two stuff. And I think this is still a big problem in the infrastructure as code, infrastructure from code space, that we need to solve. You know, I've built this, everything works. But now it's day two, and I hit a concurrency limit with my Lambda function. But I don't even know what that is. I don't know how to even troubleshoot that.

So I think this is, like, kind of the next iteration of infrastructure as code, infrastructure from code, where we make it easier, you know, for developers to actually figure out what's wrong and get to answers quickly. And I think generative AI is going to be a big help there, to be honest. Go ahead, Eric , you were gonna chime in.

Eric Johnson: Well, I want to explore that for a minute, because it's a really interesting notion, because what we hear from customers, in my role, and Adam, you've done this role as well, is, we hear... You know, they'll ask, how do I do A, B, and C? And of course, the standard technical answer is, it depends. Or here's 17 different ways, you pick one. And you see the customer, and the customer is just going, "Just tell me how to do it, for the love of God and all that is holy, tell me how to do it." Right? And so it's this opinionated way of doing it. Rather than me giving you 17 ways, here's how I would do it. And I think that's what Wing, and Klotho, and Ampt, and a lot of these different ones that are coming out and saying, like, look, we're going to help you do this in the way we think is the best way to do it. Yes, there are 17 other different ways. But I think you hit a really good note there, in that, it's...what's the term? Paralysis of analysis, right? It's just too many options, tell me how to do it right. And help me avoid pitfalls like concurrency, you know, and stuff.

And this is the literal description of my job, trying to find the division between how much are we teaching, and how much are we saying, hey, you need to go learn this before you use the service. Right? But with the gen AI, and with, you know, these different tools that are available to us, we can start becoming very helpful in, hey, are you sure you want to do that? Here's why. And Elad Ben-Israel, you know, I don't know what you're doing tonight, but if you could build that in, that'd be great. Elad Ben-Israel is one of the fastest developers I've ever seen.

Elad Ben-Israel: I have a trick, my keyboard delay rate. Are you familiar with that trick?

Eric Johnson: No, I have two fingers, Elad. I've never needed that.

Elad Ben-Israel: A delay rate, the key delay rates. And so when you click a key for a long time, it will really quickly. And so I think, like, it really changes the...feels like it's faster, right? It's not really fast. Anyway...

Eric Johnson: I have never... Adam, have you heard of this? Elad, we don't face these kinds of problems. We're average men. I'm just throwing that out there.

Elad Ben-Israel: I agree. I really, really liked, you know, your point about opinions. Because I feel opinions are really valuable. I think, like, to be honest, you know, one of the things that I felt AWS hasn't been doing very well when I was there, and I feel still, is actually appreciating the opinion. Like, saying, this is the good way to do things. I think it's cultural. There's something cultural about this at Amazon, it's like, you know, it's a company of builders. It's just like, we'll just give you all these Lego blocks, and you will make your choices and your decisions. And I think to that end, like, that's one of the reasons AWS is very successful in the cloud industry, because there are so many needs and different needs. And so I think, like, AWS has managed to lead by just giving people a lot of choice. And I think the art and the big challenge, and I think this is exactly what we're trying to do with Wing, and I think a lot of the other approaches. You know, it is basically to give people both. You know, give people an opinion, but give them the ability to actually completely customize the behavior.

And that's really hard to do if you're creating a path, for example. Because if you're creating a path, then your ability to provide full customization and full control to an enterprise platform team that really does care about something, is very limited. And so, you keep chasing...you know, the surface area keeps constantly changing on you. And I think, like, the approach that we're taking with Wing, because it's a programming environment, it's a standard library, it's very similar to the CDK, in that sense. It's an ecosystem. And so you could plug in customizations at the platform level, that completely control everything about how you're deploying things. And I'll give you just one small anecdotal example: we had this team use our cloud API gateway resource. And the cloud API gateway resource, basically, is kind of, like, an express API. You know, it's API.get, API.post, API.delete, whatever, right? And you provide paths. And then you also provide the handler code. And that's something that Wing can do because, you know, it has this inflight and preflight idea. So you can combine the infrastructure in the runtime.

But the point is that the API is basically about the intent. And so the intent is, I get a request on that path. And this is the handler, you know, that handles the request. And the default implementation, when you're compiling to AWS, the default implementation is API, gateway, and Lambda. And we had a team that had a cold start problem. And so they've been, you know, looking at different approaches. And everything that they've done, they've done at the platform provider lift. And so the code of the application just didn't change. And they've explored different approaches. You know the common approaches. There's like the warm up job, and there's provisioned concurrency stuff. And all of that stuff, you can configure at the platform level. It's not part of the API here, but it's part of the API here. Because you know you're compiling to AWS, so you can use all the capabilities of AWS.

And then the last thing they tried, which was actually the coolest thing, is they just switched it from API gateway Lambda load balancer Fargate. And it's basically like 10 lines of code at the platform level, that changes the API from Lambda to Fargate. And, you know, it made sense because there was a lot of traffic. And so they paid for a bunch of instances, and all good. And completely eliminated a cold start problem in this case, without touching their application at all. And so that's an example of why this decoupling is very powerful. But why do you have to provide customization, right? Like, you can't just say this is my opinion. Because then it will only work for toys, right?

Eric Johnson: They need to be able to eject...

Adam Keller: It's a really good point. And I was gonna say it earlier, but I'm so glad you talked about it. The reality is, opinion is great. And we all need opinion, especially when you're starting like this, we need a path. But the reality is, you're going to go down this path. And at some point, you're going to break from the opinion. And we need to make it easy for users to break from that opinion in a way that's going to be clean and easy to digest for them. And then so they can build to their needs. Because the reality is, one enterprise, one startup... Two enterprises are completely different from one another. They could be in the same industry, it could be Pepsi and Coke, but they operate completely differently. By the way, I know nothing about them. I'm just using two examples. Is that coke that owns them, I think, Coca-Cola?

Eric Johnson: I don't know.

Adam Keller: But anyway... But my point is, I think this is important. And with other tools, this has been harder. I think, you know, the way you're talking about it with Wing, this is a really clean implementation. I think with the CDK, you see it as well. You can build beyond opinions, you can extend them as you grow. And I think this is where you're going to be successful in the infrastructure as code, infrastructure from the code industry, is when you can give both, which is challenging.

Elad Ben-Israel: There's an art to it.

Eric Johnson: All right, well, we are... I'm sorry, say that again, and then I'm going to wrap us up here.

Elad Ben-Israel: I said there's an art and a science to it. And I feel like we're really humbled about it. Right? Like, I feel like that's why we're doing it in open source because we feel like that's the only way to get that feedback and make sure that we're creating these abstractions in the way that holds water. Otherwise, it's just, you know, us guessing.

Conclusion

Eric Johnson: That's right. All right. So, fantastic conversation. I appreciate you both. And, you know, obviously, what y'all and a lot of the other companies are doing in this space is really cool. I'm excited to see it, is it infrastructure from code, is it infrastructure plus code. You know, obviously, we can debate that. But with that, I'm gonna...real quick, if you have any shameless plugs you want to throw out. Adam Keller, I'm sorry, we didn't get to talk about those shoes. I really wanted to get to those, and why there are 19 pairs back there. That's really cool. But any shameless plugs, Elad? Any coming up you want to throw out?

Elad Ben-Israel: No. I mean, happy to tell people to pick Wing up and play with it.

Eric Johnson: All right. Adam, you got anything you wanna throw out?

Adam Keller: I do. I do. So, first of all, the shoes, thank you. Yeah, this is a very unhealthy and expensive habit I've had to stop, because it's really unnecessary. So, for the CDK, one thing that I'm really passionate about is helping customers that are using the CDK, whether you're new or experienced, just helping to try to simplify some of the more complex topics. So, we have a YouTube channel, CDK-Live, it's just CDK.live. Go to your web browser and subscribe. Shameless plug, but...

Elad Ben-Israel: Check it out.

Eric Johnson: We'll throw that link in there.

Elad Ben-Israel: It's the...you know the first Twitch CDK?

Adam Keller: The construction zone.

Elad Ben-Israel: Construction zone. Yes.

Eric Johnson: Let's get back to CDK day, and who hosted that, the very first one. So, all right, with that, we're gonna wrap it up. Again, Elad, Adam, thanks for joining us. This has been another edition of "GOTO Unscripted." All right, keep building. See you later.Elad Ben-Israel: Bye.