Screaming in the Cloud - Overcoming Cloud Development Obstacles with Elad Ben-Israel

Episode Date: February 20, 2024

Corey Quinn talks with Elad Ben-Israel, CEO and Co-founder of Wing Cloud, about the creation of Wing, a revolutionary programming language designed to simplify cloud application development. Elad shares his experiences at AWS and the journey to developing Wing Cloud, highlighting the challenges developers face with existing cloud paradigms and how Wing aims to seamlessly integrate infrastructure and application code. The conversation goes further into Wing's open-source nature, its design philosophy focused on making cloud development more accessible, and the delicate balance between commercial interests and open-source contributions.Show highlights: (00:17) - Corey Quinn introduces Elad Ben-Israel(02:27) - Elad Ben-Israel discusses the motivation behind creating Wing,(06:28) - Elad presents Wing as a programming language designed to add an architectural dimension to cloud programming(09:45) - The demarcation between application and platform is explored(13:27) - Introduction of the "platform provider" within Wing(22:18) - The Importance of Choice in Cloud Development(31:22) - Getting started on Wing (33:14) - Closing remarks About Elad Ben-Israel: Elad has been coding since he remembers himself, which is quite a long time ago, and always had an unexplained attraction to developer tools. He created the AWS CDK when working at AWS and is now the co-founder and CEO of Wing Cloud, which is building Winglang, a programming language for the cloud.Links Referenced:Winglang.ioWinglang on GitHub - https://github.com/winglang/wingWinglang Slack Community - https://winglang.slack.com/join/shared_invite/zt-23emj8uue-ZF4ijRNtdDOLO5F7iIz~NA#/shared-invite/emailElad Ben-Israel on LinkedIn: https://www.linkedin.com/in/hackingonstuff/

And Wing has this concept called platform provider. And a platform provider is kind of like this adapter that takes a Wing application and compiles it to a specific cloud implementation. Welcome to Screaming in the Cloud. I'm Corey Quinn. Today I'm talking with Elad Ben-Israel, the CEO and co-founder of Wing Cloud. But before that happened, he was at AWS and started building something called the CDK. Thank you so much for joining me today. What's it like to have inadvertently become a cult leader? You mean the CDK, huh? Exactly. I gave a talk at this last year.

It was a video of a pre-recorded talk, and I showed up dressed in a cultist's robe with burning candles in the background and talked about how I thought the CDK was a cult. And now I'm driving membership in the cult. If I get four more people to sign up, I get a free toaster. It seemed like this weird esoteric thing that once I started using it,

I suddenly understood why people liked it so much. And I still use it today fairly consistently, which I have to ask, did you expect that to be the reaction? That it would be a cult? No, I mean, I built it because I needed something like this personally. So I always knew it gives a lot of value to developers that try to build stuff on the cloud. And that's always been the driving force around everything that I've done, including what we're doing today. So I'm glad you're enjoying it and I'm glad you're using it. And it's really cool to hear that you think it's addictive in a sense.

And now you've decided, you looked around at the entire ecosystem and saw, at least in the CDK side, something at least I figured out pretty early on, was that TypeScript is sort of the first-class citizen, so to speak, of the language. And yeah, you can use it in Python and a bunch of other things,

but it's not as well-documented. It doesn't do things quite as you might expect them to. So that's what I learned TypeScript to do. Now it seems like you looked at this and decided, ah, the real problem with all of this is that it didn't have its own language. So you went off and started up Wing, Wing Lang, I think is what we're calling it, or Wing, depending on the level of familiarity. Why did you decide, let's build a new programming language for funsies?

Yeah, it wasn't a small decision as you can imagine. And I think that one of the things that bothered me with the CDK, and I feel like we kind of didn't manage to do with the CDK, is encapsulate both the application and the infrastructure of the application together in a single model. And the more I've been building applications in the cloud, the more I've been talking to customers that build applications in the cloud with it. They're building applications

in serverless or Kubernetes. I'm realizing that developers really are not empowered to use the cloud. And one of the reasons is that they don't have the right tools. And I think programming languages are the primary tools, a tool that developers use to express their systems. And so if you think about the CDK, the CDK has been really great at describing the infrastructure of the application, but then that's not the whole story, right? Like when you're building something on the cloud, you have both infrastructure and application code

or the runtime code that's actually running inside your compute services, whether they're containers or Lambda functions. And they're interacting a lot with these resources, these cloud resources. And so every time you cross the boundary between the runtime code and the infrastructure, you basically escape the abstraction. You end up with like IAM policies

and environment variables and bundling and packaging and a lot of hairy problems that are not really important, right? Like they're just mechanical boilerplate that you need to like understand and constantly do again and again so you're reading the code it's oh here's a here doc and it winds up just dropping a whole bunch of oh suddenly you're looking at raw cloud formation or iam policies or god forbid aws's management policy language yeah you constantly like have to like shift your gaze between the infrastructure and the application. And so that was one of the motivations for wing laying as a language, because if you think about one of the way I like to think about it is traditional programming languages are a way

for a developer to describe what a machine is doing over time, right? It's basically you write some code, you compile it, you get an executable, and then it's a bunch of instructions that the CPU executes. So that's basically kind of like the time dimension. But when you're building applications on the cloud, you also have a space dimension, right? Like you have like the architecture of your system.

In fact, that's actually the entry point is the architecture. When you build stuff on the cloud, you first draw a rectangle and rectangle and say okay this is my system and here's the api and here is you know the api invokes this container this container talks to this queue and this queue talks to this and so you have this architectural structure that represents the spatial dimension of your system in a way and you can kind of like connect it to infrastructure and application code. Infrastructure is the spatial dimension. The application code is the code that runs inside each one of those compute elements.

And traditional languages are designed to basically tell a sequential story. They tell a story over time. And what we're trying to do with Bing is basically adding another dimension to your program in a way. Like it's basically the architecture. And so Wing, when you start writing a Wing program, the first thing you define is the cloud resources. When you create a Wing program, you can write new cloud bucket, and that's it. Now you have a bucket. And that's not something that's running anywhere, right?

Like it's just a definition of a resource. And then you can say new cloud function. And then you say, okay, this is a serverless function. And then you can put the closure that represents the code that runs inside this function. And that's your in-flight, what we call the in-flight code, the runtime code. And so you get this two-dimensional programming model, in a sense. It's very philosophical, maybe, a little too annoying. Maybe, maybe not. One of the challenges I always found in traditional configuration

management land was, in the early days, you had CF Engine, and then that gave way to a new generation of things, Puppet and Chef primarily. And it was always, oh, great, now you get to go into its own specific DSL and learn this entire new syntax and structure for something that really only applies within this one dimension. One of the things I enjoyed about the CDK was, oh, if I understand JavaScript, which, spoiler, I absolutely do not, but hypothetically, someone who's good at things understands JavaScript or Python or whatever, or Go or whatever language binding they're using for this, then it's just an easy one-stop shop where suddenly everything winds up speaking them in a language with which they're already conversant.

What is Wing based on, syntactically? Is it close to JavaScript? Is it close to Python? Is it close to Python? Is it close to Perl because you hate people? I mean, how did you wind up going down whatever path you went down? It's close to JavaScript and TypeScript and C Sharp and Java and Swift.

So it's kind of borrowing a lot of the kind of modern object-oriented application programming languages. It would be very familiar to you. Like if you just read green code, you'll understand it. You wouldn't need to read like the manual to understand it because it's going to be very straightforward and familiar. Like we're intentionally trying to create it, to design it as a familiar language

because one of the goals of this is to make the cloud more accessible to people right so more developers can use it without having to have like deep understanding of all the layers of the infrastructure and and so the language is designed to be an accessible and familiar language and and so yeah i think javascript and types, you know, they play a big role in the design. You can also interoperate with JavaScript and TypeScript naturally from wing. And so you can write your wing code and basically extern to JavaScript and then use everything in the JavaScript ecosystem. So we're not necessarily like bootstrapping an entire ecosystem.

And it's very common for new programming languages or for any programming language to have interoperability with an existing ecosystem so that people can actually start building real things with it. Heavy lift otherwise. Yeah, a bit of an impossible heavy lift. I think it's already a heavy lift. Back in the olden days, you would have,

well, not that old, but still, you'd have something like Terraform setting up the EC2 instances. And then you'd have something like Ansible doing the configuration and logging into the thing and actually installing packages and the rest. And as a result, you had different repositories. You had different teams, in many cases, that were responsible for different parts of that operation. We've seen a thinning of that abstraction layer. The CDK is one example of this. But with Wing, are you envisioning the Wing code living in the code repository next to

the application code itself? Are you envisioning it being tightly coupled? What is the ideal archetype of how you envision that plan out? One of the things that we're doing with Wing, and I think another thing that I came out of Amazon with a bit of a blind spot, to be honest, is this demarcation between application and platform. Because when you're working at AWS, like everybody's a DevOps engineer, because obviously AWS is building infrastructure services. And so it makes sense that every SDE understands what a VPC is, right? and can configure a redis elastic cache cluster yeah at amazon and absolutely nowhere else yes exactly and it makes total sense when you're inside and i and when you're starting talking we start talking to companies outside of it

you're realizing more and more that that there there are two problem domains right like there's a problem domain of the developer who is responsible to solve problems for the business, for the users, for the customers of the business. And there's a problem domain of the technology, of the infrastructure, of the system, right? Like the thing that traditionally system administrators were responsible in DevOps and platform teams. And this demarcation line between the problem domains is really important because if it's a good one, it enables each one of those personas to be independent, right?

To deliver independently. Developers are able to actually deliver applications and system admins or platform teams are able to maintain the platforms and set policies and security and compliance and all those good things. And what happened with the cloud is we basically lost this demarcation line, right? Like we, in Kubernetes, this line is too high. Developers are, I call them containerized, right? Like they're just like shoved into the container. And their world is this one little container that's like spinning inside.

Build whatever you want. It doesn't exist inside of the container. It feels like it's the whole point of DevOps. Let's break down the wall between dev and ops and then containers are, yeah, and now let's put a giant wall between dev and ops. And it feels like it's a sine wave. It keeps vacillating between two extremes. Exactly.

And in serverless, it's almost the opposite. Serverless is more like Amazon, where developers own too much, right? Like they actually own both the application, the functional side, but also they find themselves configuring VPCs and VPC endpoints, right? Which is like completely lunatic. Like why would a developer at Airbnb need to understand how to configure a VPC endpoint? That's not valuable to anyone. Small, scrappy startups with people building

things in their spare time. Oh, I need to configure a VPC endpoint. They get surprised at the end of the month when it starts charging them a penny an hour, where it's, oh, that turned into money, and I configured six of them. Huh, there goes the Robin budget. So there's all these nuances, and people always

feel like they're getting surprised by some new aspect of the platform as it continually grows and evolves. Yeah, yeah. And so what we're trying to do with Wing is basically put the line in the right place. And that's not easy because the beauty of the cloud is that developers are now able to leverage capabilities from this new type of computer, right? Like if I'm a developer and I want an API gateway or I want a queue or I want a topic or I want a bucket, all of those things have like functional roles in my application.

And so for all intents and purposes, they're part of my application, but they're also part of the infrastructure of the system. And so being able to actually articulate the functional side of the system by saying, I want a bucket, I want a queue, I want an API, I want those to be connected together, I want the, you know, when an event happens here, I want to behave like this, all of that stuff, as far as I'm concerned, is part of the application. That's part of what the developer defines. And then the platform, Wing has this concept called platform provider.

And a platform provider is kind of like this adapter that takes a Wing application and compiles it to a specific cloud implementation. And that's a really important piece of the solution because it enables this decoupling between the thing that developers are responsible for and the thing that platform teams are responsible for.

And it also enables other really cool things like a simulation, for example. Like we actually were able to create a platform provider that takes your application and runs it locally on your machine. And it simulates the API gateway and simulates the buckets and simulates the queues and simulates,

because those from a functional perspective, they can behave exactly like the application expects them to behave. And so having this demarcation line at the right place is really an enabling aspect of the solution. And I'm really curious to see where this would go because I feel like that's really trying to solve a fundamental challenge with how people are building on the cloud today.

It's become a strange world where it used to be, well, you have servers sitting in a room somewhere and we're going to have code that runs on them. And there were inherent separations there. Then serverless kind of changed a whole bunch of things. Now, of course, it feels like AWS is trying to actively redefine what serverless even means. On their original website, when it launched, they said it scales to zero. Now they're slapping the word serverless onto a bunch of things where it doesn't scale to zero, and it starts to look a hell of a lot more like it's just a fancy word for managed service.

And it's starting to almost become a watered down distinction without meaning. What's your take on that? I think we kind of ruined this term. It's a really nice term that I think we kind of managed to destroy as an industry. And I don't know what happened really and what's the culprit. But I think the way I'm thinking about it more and more is the ability of an application to use resources as it needs them so definitely the flexibility the elasticity and the ability to scale either to zero or not to zero but i think being able to scale up and down based on your needs and not having to manage resources at the machine

level. And I think like that, that would be the distinction that I, that I'm making. And so if I'm managing a Kubernetes cluster, then Kubernetes itself is not serverless, right? Like Kubernetes itself as a, as a, as a platform team that manages the cluster, I need to manage machines. I need to manage capacity. I need to manage CPU memory, right? Like there's like a bunch of resources that I have to manage. But if, if I'm a developer and I want to deploy a container on this Kubernetes cluster, then I get a serverless experience, right? I can basically say, give me five instances of this container,

or give me an auto-scaling set of instances on this Kubernetes cluster. And then from a developer's perspective, from the application's perspective, it's a serverless solution. So I wouldn't even say that I would define it on the line of what's managed and what's not managed. I think it's more around the relationship

between the application and the infrastructure. And I think that's, to me, but I don't know. What do you think? This is definitely a bit... I think it's... The problem is, I think when AWS talks about these things, it comes across as inherently self-serving. And I do not believe that that is their intention.

Truly, I don't. I think that's how it comes across. I think that once you cross a certain point of scale and success in the system we work in, that it is easy to lose sight of the fact that no one is going to take what you do in anything but the least charitable way. And that is a problem. I don't know how you fix it. It's also, frankly, not my problem how to fix it. I almost don't care why it is the way that it is. I care about the reality now, which is when they say we have a serverless offering here, you really have to start peeling back the layers and figure out what it means just because the word has become almost

meaningless. Cloud Native is very similar in a bunch of respects, where effectively Cloud Native industry-wide has turned into, it is something that I can sell you now. And I have a talk coming up at SREcon where among other things, I'll be pointing out that, well, maybe I'll say this one for scale, but regardless, there's a, my point is that Kubernetes itself

is inherently not cloud native and that's going to cause a kerfuffle. But what Kubernetes does fundamentally is that it provides a cloud around things that aren't cloudy. Great to run in a data center for that reason. But if you're already on top of a cloud provider, you're effectively duplicating a bunch of abstractions. You're hiding anything meaningful and useful from what the infrastructure provider sees, and it really does become turtles all the way down. It's an unfortunate troubleshooting experience.

It's very expensive. Telemetry becomes a living nightmare, et cetera, et cetera, et cetera. And it becomes a whole mystery puzzle box murder mystery. That's my take on it since you asked. This is why people generally don't ask me things, but there we have it. I generally agree.

My view is that there's a lot of forces in this industry. And I feel like Kubernetes has definitely been a great way for Google and other forces that stand behind it to basically hard to decouple the commercial forces and interests behind those technologies. And I think Google had done, and Kubernetes and CNCF had done an amazing job. And I think Kubernetes as a technology is an amazing technology for orchestrating containers. That's not what I would call cloud native, right? Like I think like to me, cloud native is almost the opposite of Kubernetes because the whole economy of scale of the cloud or the ability to lean on someone else to solve a problem

for you through a managed service is really hard to do in Kubernetes. Like Kubernetes doesn't encourage you to do that. It actually encourages you to deploy services inside your Kubernetes cluster and maintain them and operate them yourself. And so I agree. I think we kind of dug ourselves into holes. I think serverless has gone to this,

both sides, both paradigms have kind of managed to dilute the messaging in a sense. And to be honest, one of the things that we're trying to do with Wing is we're trying to say you don't have to be a serverless shop or a Kubernetes shop, right? Like that's not, that shouldn't be part of your identity as an engineering organization, as a developer team, right? Like you need to be able to use the right tools to solve the problems that you want. And if you need a long running service, then you can use a container.

And if you need something that reacts to an event, then you can use a function as a service compute platform. If you need a database and use a database, right? And the whole idea is to create this unified model that can hold all of this together and give you a way to use the same programming experience and the same programming workflow across those technologies and choose the right technology and also change them, right?

Also make a decision, oh, I'll start with serverless because it's like really quick and really easy to start. And then at some point, I'll bring in a DevOps team and I'll install a Kubernetes cluster and I'll move some of those services to Kubernetes. But from the application's perspective, there's no difference. It's the same application because

functionally, nothing had changed. Does that make sense? I don't know. No, it absolutely does. I've observed a number of times now that every AWS service is for someone, but very few services are for everyone. Because you, I don't know what the future holds for the DBA profession, but I don't want it to be, I don't think they want it to be, figuring out which of the 40 managed database services that AWS offers are fit for purpose for them. Without exaggerating and misusing things as databases,

we're damn near 20 already. So by having a standardized, just abstracting away things like that, it feels like it smooths the path. And yeah, there are some things you need to branch out on down the road, but it solves the analysis paralysis problem super early on, which is why I guess I'm interested in your whole story around the monetization aspect of it. Writing a programming language to configure cloud resources doesn't sound like it's the most lucrative thing in the world because, oh, we're going to charge for the programming language. Sounds like a great way to never have anyone touch you ever. So Wing Cloud, being the company aspect of it, where you provide a bunch of hosted infrastructure services clear that, oh, there's a whole set of functionality that you'll be reminded on every step of the way that if you're using this thing, then

it behaves as it would be intended. Otherwise, you've got a bunch of work to do yourself, which I've never loved the model. Yeah, that's not the model. So you can rest assured. So first of all, we really suck at messaging and we need to improve and we need to like be more, I think like there's a lot of work well your xaws that sort of comes with the territory i would have to assume yeah maybe i didn't get the right education that's for sure um so yeah wing wing lang and the wing

framework the open the the sdk that that's kind of like the standard library of wing are both open source apache i believe that's the only way to do this of Wing are both open source, Apache. I believe that's the only way to do this, right? Like, I really don't think that there's another way to build something like a programming language and an SDK for the cloud without them being open source. And I would even say,

I really hope that at some point we'll be able to donate them to CNCF or to Linux Foundation. I really do believe that this should be a community driven project and we've we started from that like that's a very unique position to start as a startup company to like go and say we're going to spend a lot of time and a lot of energy to build something that's like completely donated to the the community and we're absolutely genuine about it right like there's nothing about what we're, and we're absolutely genuine about it.

There's nothing about what we're doing that we're trying to hide or change. But the way I see it is if you think about the software development lifecycle, there's development, and then there's basically build, test, deploy, preview, operate. And so the distinction that we have between Wing, the language and the commercial side of Wing is everything around development is going to always be open source. And Wing compiles to Terraform and JavaScript. And so you can write your code

or to CloudFormation and JavaScript, or you can actually choose which cloud provider you're using and which provisioning. And it's an open model. This platform provider can actually, you can implement a Pulumi provider for Wing and that should work out of the box. And so when you compile Wing, you get a deployable unit. You can get a deployable packet, and you can go and deploy it into your cloud provider, and that's it. And you don't have to buy anything from us.

But the way we think about it is that our mission, in a way, is to enable this idea of you build it and you own it for developers on the cloud. And my interpretation of this slogan is that developers want to own their applications across the lifecycle, so from development all the way to production, but not across the stack, not down the stack.

And so going back to what we talked about earlier, you have this platform and application boundary. And so going back to what we talked about earlier, you have this like platform and application boundary. And so Wing Cloud basically takes your application from development to production. And everything that's like on the right, build, deploy, preview, operate, all those things are part of the commercial offering. And even there, the approach is to connect to your existing cloud environment and not to reinvent the wheel or replace your cloud environment with a different cloud environment.

Because we know that the beauty of the cloud is choice, is the ability to actually choose the right tools for the job. And so if we say that we know exactly how to build everything, it'll work for every use case, that doesn't make sense. So we can build, you know, something like a platform as a service, and we're actually working on something like that to enable specific types of use cases. But our commercial offering is actually very, very modular. So you'd be able to actually install Wing Cloud in your cloud environment and connect it to your CICD systems and observability systems, but you will still get this

developer experience across the lifecycle of the application. Again, development should always be open source. I don't believe in charging developers for tools. I really, I don't know, my purity, I guess. I'm a little sensitive to it at the moment. Again, in my day job, we're a small

company, yes, but I have this ancient old-timey belief in if I'm using something to make money off of it, I should pay for the commercial version of that thing. But I'm also giving a couple of talks in March. And for one of them, I am finally building myself a Kubernetes because I need a test lab, just one. I pluralize weirdly, but it's sitting in the other room. So great, I'm building up a bunch of these things. And so much of what I see, I am besieged with upsells at every opportunity,

which that's great, but it's basically five Raspberry Pis and a rebadged Mac mini that are sitting there running together. I don't really have a $50,000 a year software budget for this thing in case the crappy low-end hardware didn't give it away. It's a, like, this is just a home lab style learning experience. So yeah, take the crappy path. And it seems like in some cases, they're almost intentional sharp edges put into place where, oh, now you get to go wrestle with a bunch of open source stuff rather

than the seamless experience that we offer. And it leaves a bad taste in the mouth. That said, I think that part of the problem a lot of these things offer is they don't offer a reasonable free tier for the late night experimenter to get started with. Even people in production environments, you might work at an enormous company that's using this stuff at massive scale, but your signing authority craps out at something like 50 bucks. So you need to be able to kick the tires on something without sending something up a flagpole for approval. And that is something I think a lot of go-to-market motions tend to miss. Make the easiest, most straightforward path forward for experimentation and dev work to be using the best expression of what you have to offer.

If you intentionally make the experience crappy, people aren't going to say, oh, if I pay you money, maybe it'll get better. They'll say, maybe if I use some competing product, I'll have a better experience. Yeah. I think it's, you know, the relationship between open source and commercial has always been tumultuous. People want the upsides and then they don't like the downsides.

It's, no, I think like it's kind of like this dance. I think that's what I said when, you know, Hashi changed the license for Terraform. And it was fascinating fascinating to be honest to see to see what's happening and i'll admit i did i didn't immediately take the side of the open source you know community and the community and i i totally i'm absolutely empathetic to it and i i definitely think it's a again there again, it's a very, very complicated situation, you know, what Hashi got themselves into. But I'm also talking to a lot of other founders,

especially in the Kubernetes ecosystem, where open source is very prevalent. It's kind of like almost the table stakes. And I think the models are really complicated. It's really hard to kind of figure out the right relationship between commercial and open source. And it's also hard for us. I'll admit, I think the harder part for us is actually when we go to customers and we try to sell them, it's hard for us to actually put the boundary between the open source and the commercial because we try to sell them a solution,

right? Like we try to give them a solution to a problem, not to sell them an open source project or not to sell them a product. And the whole, the beauty of the solution that we're trying to sell them is that there's this continuous motion between the open source and the commercial side. But again, it doesn't mean that they can't use the open source if they want it. And it's not where we're trying to make it harder for them to do other things. It's just where we're saying part of this experience is something that we are charging for. And so I don't know if that's helpful or not, but it is a very complicated subject. And I think like every product has a different kind of recipe for how this thing can work. And we've also seen these things blow up,

you know, like with Elastic and Redis and Mongo. And like, I think like there's a lot of trauma in the industry around open source projects. I feel like there's kind of like this pendulum going back and forth. And as a contributor for a lot of these things over the years myself, it's like, oh, you're like not a massive one,

but still I did this as basically a volunteer effort for a lot of these things over the years myself, it's like, oh, you're like, not a massive one, but still, I did this as basically a volunteer effort for a community thing. And now you're turning around and selling it and saying some people aren't allowed to use it unless they pay you. And it's, hang on a second, it makes me a lot more cynical about open source contribution to be very direct. Now, given my level of coding ability, that's probably a good thing for the open source ecosystem. But for most people, it's not. Good thing for humanity, you mean. Exactly.

Yeah, it's like, honestly, I feel like I should be able to draw a salary from a foundation somewhere. And my sole job is not writing code. Like, great, write no code, use nothing as a database. You can do this job from home. It's fine. And it'll, yeah, it'll be like that

entire of it. But it feels almost like extorting humanity. That doesn't sound like a great plan. I really want to thank you for taking the chance to speak with me about this. When you look at an awful lot of services to get started with, quantum computing is on extreme end of the spectrum where the hello world tutorial is go get a PhD from Berkeley. Other stuff is very easy and straightforward to get started with. Where in that continuum does getting started with Wing fall and where should people go to do it? It's on the

basic 100 print Hello World. The Wingland GitHub repo, wingland.io, that's our homepage and there should be some getting started tutorials and Playground which you can play with. It's all, you know, it's still early. You know, we didn't even release 1.0 of the project.

So it's like early days. There's a really amazing Slack community that's forming around it. So like, it's a good place to hang out and share thoughts and give feedback and help shape where this is going. But it is just getting started. So expect rough edges.

And we'll, of course, put a link to that in the show notes. I really want to thank you for taking the time to speak with me today. I really appreciate it. Me too. It was always fun. I hope to meet up and reinvent soon. Oh, you say soon. Don't be ridiculous.

That's only 11 months. Oh, no, it's only 11 months away. Yeah, yeah. Yeah, I actually missed the last. I didn't go to the last one, and I kind of regret it because it's a fun, it's intense, but it's a fun event. Thank you so much for taking the time to speak with me. I really do appreciate it.

Laad Ben-Israel, CEO and co-founder of Wing Cloud. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment defending the good name of Pearl.