Okay, Hey, what's going on? Everybody got another episode of Adventures in DevOps. I'm back this week. Hey, Warren, how's it going. It's great. You know, I didn't know if you were going to show up, so I was thinking about we'd be having to do a second episode just by myself. I mean, I think last week went right. You know, I was on an island in the South Pacific, so it went
great for me as well. I have zero complaints. I'm jealous. I'm gonna have to head over there myself, so I've got my Factor of the week. I was over in Warsaw doing a cybersecurity short conference meetup, and I got questions whether or not using SaaS is secure. And I feel like it's an interesting proposition people bring up as a challenge whether or not what you're
building internally versus externally is more or less secure than that. And I find it really interesting that still lots of companies believe that somehow the engineers that you've hired are better than the ones that another company is hired. Now, for sure, it can be true sometimes, but I still feel like there's an overwhelming majority that keeps questioning this, which is really a surprise for me. Yeah, So what you're saying there is that people are reinventing the wheel still
because they don't trust sas. Is that the Yeah, for sure. I mean it's a whole nother level on top of not invented here, right, it's a oh yeah, that's not secure. And I feel like it's just this abyss that you can fall into of believing that because we're doing it ourselves, we're going to somehow do it better, it's going to be more secure
than another solution. I'm just like, you know, show me where your interview process is that proves that the engineering team is definitely better, because there's lots of good companies out there that are have great interviewing processes, have great cultures that are for sure building secure solutions. Yeah for sure. Yeah, I'm leveraging that right. Well, may I may I interrupt? May I absolutely an opinion? Yeah, bring it on, go for it. I
think I understand where people might be coming from it. I don't think it's
because they think that they're better engineers. I'm sure some of them do, but I think that there's some legitimate engineering consideration around isolation, right, Like I think like as an engineer, you would say, Okay, well, if it's like inside my ABS account and I control the boundaries of this account, the VPC, the im rolls as account as an example, is like an isolation boundary, and I think like there is something to say about going
outside of that boundary into another you know, and then into another system. And so I think that maybe some of that sentiment comes from from that isolation boundary, not necessarily from like I didn't build it, so I don't trust it. I don't know. Yeah, I feel like we should introduce our guest for today, right. That new voice that you just heard is our guest, Eli Ben Israel, former ABS, former Microsoft, the CEO and co founder of Wing. And this is a cool fact you created the AWS
CDK, Is that right? Yeah? Yeah, you just hold that. Yeah, Yeah, of course I did. Mean and an amazing team that Amazon and WUS and but yeah, it's it's really really really proud of this
project. That definitely been really sure the journey. Yeah, just looking at your background here, it seems like it's been a fun journey, which I've always you know, I feel the same about my career, and I just think how amazing that is that I could spend three decades doing something and go that was pretty cool, man, and continuing to be passionate about it and
like excited about it. I feel like, actually, I think Microsoft was the first time in my career where I stumbled into old geezers who are still doing software for a living and still writing code and still have this like childish enthusiasm after you know, forty years of programming and got really inspired by that. I feel like that was like, as a young engineer, it was like, yeah, I can I can see myself doing this for a few
more decades. Oh for sure, I agree, And I think that's super cool because a lot of people can't say that, And I know for sure if I were in a different career, I may not be as excited about it. So I think it's really really cool that we can do that.
Well, now, I'm worried that the first job you get out of university or you know, get into the professional environment, whoever is around you is going to dictate how were you inspiration and how you think about work goes on for the rest of your professional life, and that that scares me a bit because I feel like there were way too many jaded engineers at the early on places where I worked. I don't think it would it would dictate it.
I think, like like anything in life, you you find your role models during your journey, and you identify them when they they're the right road models, right like, not necessarily with the first one, the first ones that you encounter. Yeah. I can say from my perspective that a lot of the the mentors in role models that I had over my career, it wasn't until years and sometime decades later that I realized that they were mentors and role
models. Yeah. I mean, I don't think it's well defined, and I also think that there the corollary problem here is you're not really talked to or taught about how to find a role model or why you might want to find one, or what that even looks like and how it can help you. I feel like at one point in your career people start popping on and be like, oh, I it would probably be good if I had one of these. Maybe how do I get one? Where's the app? Where's
the app? Right? You joke? But I'm sure there was one out there now, like find your tech mentor, right and go on there? Actually both I think both Microsoft and Amazon has like had like internal systems for matching you with the mentor. So it's not so makes sense right, the AI has automatically selected your mentor. Please click continue Why it has Scarlette Johansson's It has Scarlett Johanson's voice. Cool. So aside from mentoring and sas and
careers, what is wing? I'm curious about that because I kind of have a little bit of an idea, but I want to hear it straight out
of your mouth. Tell us what wing is. Yeah, we're also like learning how to talk about it, like as the project evolved, so it's probably you probably have a different It would be interesting to hear what you you know, I think that the way the way I'm thinking about it is so Yeah, spend some time at AWS, built the CDK, built some internal distributed systems at Amazon, and been constantly obsessed about developer experience and developer productivity
and iteration speed because to me as a developer, that's like the most most important piece of like my my experience is my ability to iterate. And after leaving Amazon, I was like, okay, so it still feels crappy to build stuff on the cloud. For some reason, I mean, I love the CDK and I think like it's it took us many steps forward, but something didn't feel like we've really solved the problem. It's kind of I was thinking, well, the cloud is going to be here for fore you know,
for the foreseeable future. We're going to continue to build stuff on this new kind of platform. But something is still a bit broken, and it took me some time to untangle, like what are the what are the big pains or where the kind of the root causes of the of those of those of this friction that we feel. I think like everybody I talked to kind
of resonates with that friction. But no, I think like people perceive that it's coming from different uh, you know, from different reasons and and the way I am thinking about it, my perception of this is that there are two main problems. One is the fact that the developers, you know, when you're when you're looking at a system like the cloud, there are two
engineering disciplines that are required in order to deliver something to the cloud. One is the infrastructure discipline or the DevOps discipline or the it ops or the system administration, and the other is the application developers. And as much as we would love a world where all applications developers would also be passionate about I P routing tables. And I think some of us are. I think some of us are, which is tantalizing somethings, because you know, I'm I'm one
of those. And so for me, like having like a full understand of the stack is it's fun and I enjoy it. And I learned enjoyed learning how to configure vpcs and how to set up EC two instances. And but most application developers are focused and passionate about the problem domain that they're you know, solving for, which is usually the business problem domain or the customers of their business. And these are two different engineering domains in terms of like the
problem space. And I think what I've seen with the CDK, and I think a little bit of the blind spot we had with the CDK, especially given Amazon's and Aws's engineering culture, which is very much on the kind of like full stack devop see you know, everybody, the side of the spectrum is that developers don't really want and are really struggling to understand all the mechanics of the of the cloud and and in reality, when you look at organizations
they don't really want their developers to fully understand all the mechanics and the cloud. And so one of the problems that I've seen is that developers are not they don't have access to this new type of computer they they access in terms of like cognitive you know, cognitive barrier, learning barrier, and in some cases also like they're not allowed to touch the cloud, right, Like it's like, this is the develop scene, this is the platform stuff. You
just do your container you know. I kind of I kind of sometimes think about it, like we've containerized the developers just put them in side, and this is the cloud. You don't worry about it. Just just write your code and the cloud is you don't have to care about it. And I think it's a shame because you know, the beauty of the cloud is infrastructure
is the ability to leverage managed services to achieve your goals. And the more but the more you're leaning on that, on that, on that system, the more you're leaning on these services, uh, the less you give developers independence, and the less you give developers the ability to actually like iterate quickly and choose the right tools and understand how they're you know, leveraging this new
type of technology. And so to me that was like the fundamental realization is that the gout that the cloud is not is not ready for developers in a sense. And and I think what we've seen is that, or what we're seeing is that organizations are trying to kind of again they containerize the developers.
They create these like big platforms and complex workflows. And you know this HELM chart, So go and change this one line if you want to add an API endpoint, but you can't really test it because we need to deploy it on the cluster in order for you to actually see that it's working. But don't worry, it's going to be fine. And it's not fine sometimes And I think you guys know what I'm about, right, And so basically trying to solve this problem, right, Like it's like, how do we give
developers access to this new type of computer? And it's a huge challenge, I feel, because I think what happened is that the cloud is you know, we've we've raced to the cloud in a sense and as an industry, and we've basically carried with us a lot of the tools and approaches that worked for us in the data center and in traditional computing that like the programming languages and the abstractions and the deployment systems, and and we ended up with like
something that's not optimized for this type of platform, and so what have you know. What we've been doing with WING in the past few years is trying to distill how to how to address this pain uh. And I think like one of the kind of like maybe a bit of a recent coin drops I had or the recent kind of uh observations I had, was that the thing
that we're missing is is an abstraction layer. Is this decoupling between application and platform that we have in traditional software and we've developed in traditional software, Like I used to write code in the nineties, and we didn't have that decoupling. I had to you know, I know which file system I'm using in order to write files, and I had to know how to you know, store create like TSR programs in order to do some memory you know background uh,
you know stuff that truns in the background and like do sometime. And
so again this is I loved I love this. I've always been a acted to this, but now today when you want to do these things, you really don't have to understand how your your platform works, right Like, you really don't have to know which filesystem you're using in most cases, and which even which operating system you're using, right Like, we have established a bunch of layers that allow developers to be effective on this platform called a computer,
right computer that runs inside a machine. And and and my realization was that we need this layering for the cloud because without this layering, we keep bumping into each other, right Like, these disciplines keep keep the friction keeps happening. And what we've been doing with WING is basically we've established this abstract cloud API as a foundation for solving this problem. And I think there's a timing aspect to this, because the cloud as a as a you know, as
a as a platform is is maturing over time. And we've and I believe we're at the state where we can identify the primitives and and even identifying them from the bottom. In a sense, it's not necessarily saying, you know, I'm going to be able to like give you all the primitives you ever need. It's basically saying, let's give you more primitives. I'll give you. I'll give you an example, what I mean about this, you know what let me So the basically what I'm trying to say is that it's it's
pretty safe. There are some primitives that we know that are very valuable. But for example, a container, right, being able to execute a container, run a container, you know, in a scalable way. And I think Kubernetes said basically said, yeah, here's here's your primitive. And it's been very very successful in exactly that, right, Like it's basically saying, if you need to run containers, Kubernetes gives you exactly this abstraction that you
need. And it's because super successful because it was able to identify this one primitive, uh that that can hold an application on the cloud. But in my mind, it's it's very low level, and it's it still means that you're not leverage you're not really able to leverage the cloud, right, Like you're leveraging VMS maybe, right, which is super powerful, super valuable.
But again, if you need if you need storage, for example, then okay, go manage hard drives and memory manage and and you know, scale your volumes and back up and replication and like, but hey, guys, there's like a thousand people team at Amazon that's managing object storage and S three, maybe we can use this service and then instead of doing this ourselves, right, And so even just saying let's take object storage as another primitive,
it's pretty ubiquitous. It exists in every cloud, every cloud provider. It even as a self hosted Kubernetes you know, solution if you need it. And let's define the abstraction layer of this, of this idea called a bucket
or object store. And I think we know how to do this. I think, like you know, anybody can pretty much define, Okay, we need to be able to put files and get files and download and download multi part downloads and uploads and mind types and this there's a surface area that's pretty easy to identify and say, even just adding this one primitive to your toolbox
of abstract cloud primitives can really help. Right. I've talked to many people and because that especially people who use Kubernetes that are kind of like, we're worried about taking too much dependency on their cloud provider, but they still have a bucket, right, Like they still need a bucket, which is anecdotally it's actually as is first service, right like atabus is first service. That's
three. So taking step by step basically saying, okay, let's let's talk about object store and define this abstract API and start building our applications on top of this abstract API, which is decoupled from the you know, concrete implementation.
Again, super simple exercise, not super hard to do. And the other thing that we're doing with Wing is we're actually doing we're actually audi also providing a simulator implementation for those for those resources, because again, if I define the contract for a bucket, pull, get lists, whatever, it's pretty easy to implement it locally. It's obviously not highly available and replicate it and all that stuff, but like from a functional perspective, I can actually
test my application now and I can iterate. And so this is basically the exercise that we've started doing. It's like, okay, let's take buckets and queues and topics and static websites and and secrets and basically slowly kind of like adding more tools to the arsenal of tools that you that are the foundation. They are the standard library in a sense of the cloud. And let me
let me pause you right there. So so if I'm following you correctly, you're thinking about application development in terms of just the primitives as far as like Okay, I need compute, I need file storage, I need database, and so instead of forcing the application developers to think about the individual characteristics of those because of the chosen provider, just abstracting that away to say, look, you need file storage, Okay, here's here's the interface for putting files.
Here's the interface for getting files. How that happens because you're using ABS or g CP or NetApp or whatever doesn't matter, right, am I following? You're right? Yeah, yeah, exactly right. And I think like the heavy lifting that we're doing on our side is testing, right. It's basically saying, oh, here's an implantation for a WS, here's an inflation
implantation, or azure, here's an implementation for the simulator. It's heavy lifting because I can't expect every platform team across the industry to actually do all this heavy lifting across you know, multiple resources, across all the different types of cloud providers. And obviously we're doing this with the community. It's like an open source project, and so we start to see people fill up, you know, fill up little little boxes in this matrix of compatibility and the thing
that this does in terms of solving the original problem. There are two things. Basically, one is a higher level API which is in it, which is based on the mental model of the application and not on the mental model of the infrastructure. And because when the developer uses a bucket, they they understand the the semantics of this the function, the functional semantics of this of this resource even today right like when they're using S three, they understand,
okay, so I'm putting objects on this service. And there's some constraints related to the fact that it's a distributed system. Like all those things are easy for developers to understand, they're not that that's not the hard part. The
non functional aspects of the of the of the of the bucket. Uh wing actually has this like pluggable customizable back end model, and so we provide some default implementation, but then platform teams can actually like customize that default implementation and provide their own implementation or you know, a customized implementation of our of our
bucket. And so for example, we have this customer who it's actually a really cool example, like we have this uh resource called API, which is sorry, which is basically so we have this resource called API which is basically an API gateway, so you can specify routes and then you can specify the handlers, you know, how how how the each route, how you respond
to each route. And our default implementation at the time for the time being is using infre w S, is using API gateway and lambda functions because it's
the it's the simplest implementation to get started with. And we have a customer who basically said, well, we were not allowed to use API gateway because you know, some compliance security, you know, some financial institute, and and they created an implementation of this API resource that uses load balancer and a monolithic container right behind the scenes, and you didn't have to change to anything
about the programming model. Like from the developers perspective, they just specify the bunch of routes and a bunch of handlers, and and the way that these guys are going to be deployed in that with this particular cloud environment is using
you know, a load balancer and a long runnings container. Great, and so I think this de coupling offers both the application the developers the ability to actually understand what they're doing, right, Like it's not just like change this one line here this terre form and yeah, it's it's HCl, it's this
thing. Don't worry about it, it's it's now. Like talking in their language also gives the platform teams and develops teams the ability to focus on their responsibility, because it's not like we're saying there's no need for develops or there's no need for you know, people who are experts in on the on the problem domain of the infrastructure and the problem domain of the the of the system. It's always been needed, right for software. So that's why sure.
And then the second side is like the simulation, which I think is really shifting the developer experience to to the left in the sense it's like the cloud is not that you don't need the cloud in the loop when you're iterating, which is and probably don't want it there even if it is in the loop. Yeah, I mean, I think developers are really spoiled and legitimately so right, Like they want to work on their ID, they want their debugger.
This is their you know, this is their craft, right Like their craft is like to change some code and check that it's working, and change it again, and check again and change again, and then then write a little unit test, and like you want to be able to do these iterations really really quickly, and even if it takes like thirty seconds or a minute,
it's too long, at least in my my standards. You said, you said a bunch of really interesting things there, and I feel like there's a there's three that really come to mind, and the first one is there's an aspect of the container world, which I think you know started with Docker than Kubernetes, that has really failed us. It just the interface that you have to understand in order to deploy your technology in one of these environments requires
I mean, it's better than it was. It took the interface that we had, which was the operating system, and sort of adjusted it by like say, ninety degree angle. It's still the same, it's still the same thing in a lot of ways, but maybe there is more consistency in what we're getting. And I feel like that's that's in a way something that we lost. We had the DevOps movement. Everything's supposed to be under one roof, everything's supposed to be understood together, and if anything, we didn't achieve
that. We didn't get in that direction with the tools. We just you know said, oh yeah, you know, we have the mindset, and I feel like this is an opportunity. You start talking about primitives here that we actually need, and I feel like that's where AWS was really successful compared to the other cloud providers. You start out with S three. A huge
release was Lambda successfully in an API gateway. I mean, these to me are the primitives that you're even talking about, and they that's where the success came from. Everything else is like, you know, what is that even? And if we take it another step further, we can see companies like render or Netlify versl that are trying to create an abstraction layer on top of the cloud to make it simpler. But I feel like it's you know,
almost what we're saying is it's two opinion based, right. You're losing the aspect of how to deliver value from the underlying resources that are there, blockstore, et cetera. By offering a two opinion needed answer, like if you need to dive down, you can't get that. So both early on we didn't succeed because we didn't figure out what the primitives were, and we also
have two over opinionated platforms. It'd be great if we could redefine what that real interfaces at the platform level, at the cloud provider level, so that what you need at the application makes sense. I mean, even Lambda, you have to know that you're using Lambda in aws in order to deploy your software. Right, you can't just be like I don't want to think about this in go to town. Early alternative as containers today. Yeah, absolutely
agree. I think I think the vertical the vertical platforms like Heroku, you know, ver Cell render uh, you know, they're able to create a really great developer experience by completely narrowing down the surface area and saying, Okay, we're just going to give you the ability to you know, deploy websites or to deploy containerized the applications. And in that sense, it's it's great, it's solving it's solving the problem right in that sense because for those use
case you really get an amazing experience. Well, what we're trying to do with Wing is we're trying to actually create like a general purpose solution, not necessarily a vertically integrated solution, but more of like like any any you know, programming environment where you're able to actually pick and choose which tools you want to use for your solution, and we are actually working on a delivery experience there will be very similar to what Render offers and verseell offers, but works
on top of this foundation, so it's not limited to you know, just
delivering websites or containers. It almost makes me think of like an infrastructure approach implemented with Go interfaces, you know, because if you have a Go interface, you can swap out anything that matches those same interface, the same interface specification, so underneath, you know, if you're if you're logging provider matches the interface and you want to swap that out, you can just swap it and there's no there's no impact that no one knows the difference except for the
people who are required to maintain that, and you're it sounds like you're taking that to an infrastructure approach. You know, if you need a storage bucket, here's the interface for it, and who the actual provider that is doesn't matter. You can swap it out daily if that's what makes you happy. As long as it matches the interface, you're good to get the buckets. You have to also move all the across Oh you're not, You're not going
to handle that part automatic, and that's that's the support teams problem. That line, I think that's a very apt uh, you know, very aware of the problem. I mean, just for those that haven't used GO versus other compiled languages, you normally you have to define the inner the interface. Is that a class implements you know, not just here are the methods,
but explicitly that it implements an interface, and then go. You actually don't have to define the interface in order to pass an object around and injecting as long as all the properties of that class actually match. So, I mean,
I think that's that's spot on realistically here. Yeah, there are many versions of this, I think in software design and dependency injection is like something that exists in almost every programming environment and and and it's at the heart of what we're doing, right, Like you're able to basically inject the dependency and say, okay, in the case I want to use, uh, my bucket instead of of the standard bucket. Yeah, I agree. I think I think we know how to do this as a as a you know,
you know, as an industry. It's not we're not inventing the wheel in the sense of like new, completely new uh design paradigms. But but I think like there's a I think like I think you know there is you know there is a there's there. They're going and doing it right, like going and going and saying this is the API that we think is the right a
PI. That's a really big challenge because designing good a PI is is is an art and science problem of thing right, like and and and this is one of the reasons we're doing this as an open source project because we believe that this is something that needs to be baked with the community, baked with
use cases, baked with the real world. We don't have the oracle and knowledge of like exactly how to do this, and so I think like doing this in the open and collaboratively is the right way to do something like that for sure. And you've been working on us for a couple of years now, is that right? Yeah? Cool? How has how's the community support been from that? Because like with with open source projects, you know, that's I think that's the challenge is like getting people to make it a two
way conversation. How has that experience been for you? It's been amazing, to be honest, I feel like I feel I learned a lot from my experience, you know, building the CDK and kind of like being not in a way a bit not very intentional about the community that's built around the CDK, but observing the organic kind of evolution of it, and then coming into Wing was like, Okay, I kind of know what are the important things about creating a community like that, And we've really made a lot of effort
to kind of put that in place very early in the project, and it really pays off, right like the fact that I feel like I feel Wing is a really really great project to contribute to, and I'm not saying that, I really do think it's just a good experience as a contributor, right, Like, you have a really good, really reasonable documentation, definitely always have, always can improve the documentation with reasonable documentation, the build environment and
the development environment is is is pretty easy to use, and it's a pretty complex project. So you know, being able to actually like get that right as took us quite a lot of iterations. We're trying to be very responsive. The community is very welcoming and very helpful, and we public goods first issues and there's a bunch of things that you can do that even things like
I'll just give you an acdotal example. Uh, there's this to two really simple things that that you can do to really improve the experience of contributors. One is, whenever someone submits a pull request, send them a note, you know, send them a comment, acknowledge that there's someone on the other side. That's like it's a it's a dopamine rush, right, Like it's like, oh, sure, someone that saw me right, saw that I'm
that I'm here. And then the other one is that once the feature that they or the fix that they contributed was released, add a comment to the pool request that says this was released in the version of V and and just getting that like closing the cycle and giving people the acknowledgment that what they've contributed is now a public release and everybody can use it is really gratifying for contributors. I can say that as you know, from from firsthand experience, right
like for me when I'm contributing. And so these two things can be pretty much automated, right Like you really don't have to be super It doesn't require a lot of efforts, but it does require intention to to put them in place. And once you put them in place like even for me when I'm I'm submitting pr to our repo and I get this little note that says it was released and version of x y Z, it just feels good for sure.
That's that's something that I think is worth acknowledging and mentioning, you know, because that's the people side of writing goods software and it's something that we we can easily get defocused from. You know that there are people at the other end of this, and so I think that's super cool to just acknowledge them. And you're right, it's a it's a dopamine hit. Yeah,
I mean you you can look at it. Actually two from it just a statistical value driven standpoint, Your software isn't delivering value or the changes that you make until someone's using it. And if they don't know that the changes that you're deployed you've worked so hard to get out, you know, aren't there or you know what they've done. There are so many open source projects that you don't know when it's going to be released after you put in a polear
quest. I mean my strategy now is first I start with the issue. I'd be like, this is a problem. Is someone like if I submit a pole request, will it get merged? Yeah? And ninety nine percent of the time I never hear back. There is like sometimes I hear back within six months, which is just so ridiculous to me. Frequently I hear back with that baby agile. Agile is thirty days. I hear back from their box saying, no one's meant put a comment on this for thirty days.
We're going to close it automatically. I'm like, thank you, yeah and again. And I think, like we can. I think we can. Definitely there's things we can improve, but at least we were trying to be intentional about those things. I mean, I remember uh from the CDK at some point. It is really hard to maintain a big open source project.
And once one of the problems with this is is that there's an asymmetry between the capacity you have with the team, with the core team, which is usually a fixed size or you know, maybe growing a little bit every year, and and and the user base, which is sometimes exponentially growing or sometimes growing like crazy, and the contribute and the contributor base as well. And if you don't have automation, if you don't have like really great workflows
for like accepting contributions and dealing with them. It's just immediately, very quickly gets you overwhelming for the for the core team, and the CDK had like still I think really struggling with this because you know, anyways just keeps growing. There's like more and more services, more and more capabilities. The CDK definitely is perfect for contribution in that sense. It's like, oh, yeah, just they eded this new feature in Lambdough, let's just expose it in
the CDK. So it's like these are really simple contributions and so people can can really participate, but you need someone to review this, you need someone to accept it, you need someone to and so it's it's a challenge. It's a big challenge with big projects. So definitely I can also you know, I can also be empathetic to the other side in that sense. That's
what I'm trying to say. Yeah, for sure, so and now and so with weing, you've got that problem, but also with the other cloud providers as well, because you are supporting all the different cloud providers, right right, I guess we can't say all because I don't even know what all really. Someone someone who said the cloud flare back, right, which is oh, yeah, right, Uh, they seem to have all the primitives we need now to build the standard library. Yeah, and we don't.
We don't. We also don't have full support for all all the kind of traditional providers. As I said, it's kind of like a matrix that we're filling up. We have the foundation for testing everything, which is really important. So like if you fill up something, it goes into the goes into the factory and starts, you know, and we start testing it every time
you every time there's a change. And it's interesting to think about the cloud agnostic problem, which is I haven't mentioned it actually but in a way not in a way, but we also solve that problem, right like because once you work against the substraction, then suddenly you're not you're portable. Your application can be ported across different implementation. Like you said, I can change the
bucket, I can change the cloud provider. And and I've been talking to like tons of you know, people from the industry in the past two years, and this is a growing pain. It feels like I've seen more and
more people concerned about portability, both from a cost perspective. Just talk to someone yesterday and they mentioned you know, they've been an AA base shop for many years and at some point just became really expensive and Atabase was wouldn't you know, wouldn't give them any discounts, And so they said, Okay,
we're gonna move some of our workloads to GCP or to AZURE. I think I don't remember what it was, but just just just pointing out that I think, like, as the cloud is evolving and people have bigger workloads and more stakes than the fact that the power is in the hands of the vendor as opposed as opposed to being in the hands of the of the user is
I feel like it's not it's not the good. It's not good for the industry eventually, right, Like it's not good for anyone, and Wing is solving that problem again still early, still have a lot of work to do, but like at least from at least uh, you know, architecturally, this is a solution to this problem. And I'm seeing more and more people talk about this. I think the other the other anecdotally like weren't like kind
of related to what you asked earlier. I'm seeing a lot more vendors wanting to support self hosted solutions because of those concerns about you know, data where the data is stored and going out of your account, and and so in those examples are like they're not they're not SaaS providers. They are vendors that create services, but they want to be able to deploy them in customer accounts
across different cloud providers. And right now, the only reasonable solution, which is which you know, I don't actually think it's like a fully it's not real in a sense, it's to use pure Kubernetes, right And the reality of that is actually pretty harsh because first of all, you're really limited in terms of like the resources that you can use outside of your Kubernetes cluster. So once you start you need a bucket. Then okay, we need this
abstraction again. And two is Kubernetes, as much as we wanted to think about it as like cloud agnostic and portable, and the reality is that the
distributions are very different. The versioning are very are different, vms are different, the VM types are different, the volumes are different, the managed you know, Kubernetes solutions are different, and so you end up having to like actually test yes this works with the GCP Kubernetes, and with the abase Kubernetes, and and so even this is not truly so the only portable thing in this world is the container in a way, or you know, your application
that's running inside Kubernetes, which is a bit unfortunate, I feel, because I know that a lot of people are using Kubernetes with the sense of cloud portability, and then when when they actually need it, it's, uh, it's much harder than than they expect. For sure, because you dhorn I would say, you heard it here first, are using Kubernetes for cloud portability.
Stop it. You're you're not getting the value out for sure. It's been a it's been a slow transition like that, you know, because as Kubernetes has matured, you see like little things that steer you towards a cloud
agnostic or a cloud specific solution. Like whenever you set up your ingress for for your service, if you're in GCEP, you know, you use one type of ingress, or if you're using uh, you know, the the Amazon managed kuberne As, you'll use a different ingress and then you try to move it to a different Kubernetes cluster and you're like, oh damn it,
I've screwed. Yeah, and then you end up with like overlays and tim plates and patching and taint different taints, and I don't I don't even know all the but I just wanted to make sure that I think Kubernetes is a really great and powerful tool I have. I think that oftentimes people use it without really needing all this power and these capabilities. And oftentimes people use it because they think that they're not going to be locked to a cloud provider.
But that's not really. But but there are I've seen amazing use cases of Kubernetes, and I think, like, you know, definitely, by the way, people who need like on prem container orchestration right amazing, right, Like I don't, I don't know that there's a better solution for them. No, I'm totally with you on that. I mean, I'll say the controversial thing, which is, I believe there's probably one percent of the use cases are Kubernetes, and the ninety nine percent you probably don't need that,
you know. I feel like from experience it's something related to GPUs or on prem you have if you have need to deploy like a very high cardinality number of containers with minor tweaks to the variables or parameters for each of those containers, then for sure, one hundred percent Kubernetes, nothing else is going to
give you that level of control with the repeatability. I just find that, as you said, there is hypothetical value associated with portability or cross platform same way like, oh, if we use terraform, we'll just be able to immediately change clouds, just like that with the infrastructure. I think it's it's for sure the same mistake. But at the application level. That's my highly controversial opinion. I'm not going to get my mind changed anytime soon, but
you know, feel free to write me some letters to my email. Yeah I would. I would also add that the ecosystem that's evolved around Kubernetes is amazing, and I think a lot of people use Kubernetes because of that ecosystem, because they have, you know, great tools in Kubernetes that enable them to do observability and c ICD and the or and I see or you also have another Yeah, I know, right, this is hot take episode.
I think that there's uh. There was a controversial AI developer Devin who I'm sure everyone is aware of at this point, and I feel like there's a it's very difficult to separate out core problem solving from solving problems that were created by the infrastructure or architecture that you've picked. So ideally, if using a cloud provider, you don't need to monitor and observe what's going on there.
If using Kubernetes, you for sure do. So. Yes, all the great tools for observability only work with Kubernetes because you need them to work. Otherwise you're like, what is going on and by infrastructure staff? Yeah, what's wrong with me? Why don't I Why don't I need to use all these observability cool observability tools be with the cool kids. No, No, it's interesting. I mean you definitely get you definitely get left out right because
you're not using that thing. I hear very frequently using Oh, we can't use Lambda or cloud functions or even cloud run because they don't offer the same
sort of integration. I mean, I think the truth is almost everything offers hotel integration at this point, So you know, forget that, you know that's no longer the truth, But for sure, you just don't need to integrate with things because the hope is that you don't need to and I imagine, you know, with wing Lang you're writing stuff in a way that is agnostic, and you also hopefully don't need to know the observer. I don't know, maybe I'm saying too much. I assume you know, some sort
of observability back end configuration or integration exists in some way. It exists in a roadmap. It doesn't exist yet, but it definitely exists in a roadmap. We want to We do want hotel to be built in to Wing, which is actually really exciting. I can wait to get there. I know a lot of people are jumping for joy over the fact that, oh I get that for free now, and I don't have to write a whole bunch
of things to run a sidecar. Actually it's really timely because there was just a huge vulnerability discovered in a fluent bit I think like literally today, where there's a huge problem there and anyone running it there's a promote code execution vulnerability that you need to go and patch. Oh okay, well I guess I know what I'm doing this second. I don't over I mean so literally asked a question, is it worse than mug for Jay, so still being determined.
Oh wow, the fact that you have to pause to answer that question is not a great indicator. This is concerning Yeah, so you mentioned that hotels on your roadmap. What else is on your roadmap? For Wing? One of the one of the pieces of of the solution is what we call the WING Console, which is this graphical user interface that allows you to interact
with your cloud application. And again it starts from the developer, from the inner loop, right like you're because we're running inside a simulator, and so now you want to be able to see that when you put something in the bucket, it's actually there, and you know, send a request through the API or put some message in the queue and see that it's behaving the way you want it and run your tests. And so it's kind of like this.
Currently it's kinrent of like a development tool, but one of the things that we're working on is getting the same view to connect to your production system. And and I think that I'm really excited about this because one of the cool things about this view is that it has a logical model of your application. So if you design your application, and every developer designs your application through
composition. Right, they say, okay, this, I'm taking my problem, I'm breaking it down to smaller pieces, and each piece solves a certain part of the problem, and there's like interfaces, and you know, I can test each piece in isolation blah blah blah. But then you compose things together and it becomes this like tree. Right, so you have like your application and then your inger system and your storage system and your outbound connector and
whatever. Right, So it basically create some kind of a hierarchical logical structure. And one of the things that I've seen with the CDK, and the CDK also allows you to do that, Like CDK has this concept called constructs that basically allow you to compose a smaller you know, composed truck together into
higher level, higher level abstractions. And one of the things that I've seen with the CDK is that people are a bit reluctant to use these constructs to create logical abstractions because they they're lost when the abstractions are when the system is
deployed. So you have this beautiful view right of your system and all these logical units, but then you end up deploying them and they break down to their atoms in a sense, right, like they break down become queues and buckets and containers and you know, topics, and like you're just you're unable to have like this logical you don't have this logical view of your system anymore.
And so this console being able to actually see the same logical view in production, and being able to reason about your application in production the same way you reason about it and during development the same way you wrote your code, and having this trace stability between something that happens and in production on the cloud and the logical unit in the code that actually you know, like you know, I have this queue filled up. Okay, so this is a low
level error. But then if I understand that this que belongs to some certain piece of the system, I can react much more much quickly. I can understand exactly who's responsible for this. I can diagnose problems much better. And
and so that's another thing that we're working on. The I think it's I feel like that's something that's not work like definitely not to skip over, like when you're using stuff like the CDK, it's a bunch of transformation steps, and so one of the transformations you lose sort of all of the metadata that happens in the step before its CDK turns into CloudFormation templates, which ends up in AWS, and it's like one direction. All that basically means you have
a bi directional view. You're able to look at what's actually deployed in production, combine it with the metadata that's in your in the written for wing, and see that picture from the outside without needing a WS to make fundamental changes to their tagging system or I mean, I'm sure there's some clever ways of getting that metadata am so you can pull it back out later, but they don't have to make changes to the cloud in order to directly be able to
support this view, which is what we need to happen with stuff like the CDK or even terrorform, which doesn't command or really look into your production cloud environment to understand what's going on. It's just one direction, you know,
transform, have to transform until you're there. Yeah, it's kind of leaky in that sense, right because basically the abstraction is leaking out and that and and also in many cases you have different people involved in the operations of the system and so not having like a shared mental model of the system is sometimes a huge problem, and I think you know people what people do is that
they they use tagging, they they create dashboards. Dashboards sometimes is basically just a way to restore some logical view, right they Oh, all of these resources belong to this part of the system, and so now when I'm walking looking at the dashboard, I understand that something happened in this part of the system. But with WING, you really don't have to do this manual because
we know all this information from your code, which is exciting. I mean I feel like as actually trying to go in this direction a little bit, but then clearly didn't get it turned into a product or a service in the aws's view, which is like I don't want to see the underlying primitives as you put it here, Like I want to see the service components and the
architecture that I've deployed, as I understand it. When I go to the homepage of AWS console, I want to see my individual services laid out there that I can click on directly and not be like, oh wait, this service is made up of a container, plus it's running Kubernetes, and then there's these other things like I just want to see one blog and I can click on it and it will tell me. Data is fine, Logs are great, monitoring, observabili everything's great. There, connections in and out a
shop good, right, flows fantastic. I don't want to have to jump into those underlying primitives to understand them. Yeah, I agree. I think a lot of them went too far with that, Like they tried to show that, but then in doing so, they ended up showing you know, like, oh, here's the four hundred security groups that were created. Was as a result of this template, and like, ah, okay, thanks,
but really really not helpful, man. Yeah, I mean I can also be empathetic to a w S society of the world in that sense, because one of the beautiful things about Amazon, and really for me it was it was it was just empower incredibly empowering. Is this two pizza team model, you know? And I'm assuming like it's basically like this operational model of the company that says, you know, there's a there's a small team that's
responsible for a certain type of product delivered to customers. They just obsess about making these customers happy and and it's it's and it's real, like and the empowerment is real, Like the ability of that team to actually make decisions and deliver without interruption is I haven't seen that anywhere. And I think one of the results of this is that it's really hard to create like a holistic view,
right, Like I think like as customers both aws. You actually also see this in the Amazon website, right, Like you go to an Amazon product page and there's like a eleven thousand services involved in like rendering this page, and it's horrible, right Like, it's like it's clear that nobody has like this holistic you know, intention about how this needs to look. But it's good enough, and it's like, you know, very valuable to customers.
And I think like this is saying kind of like DNA Amazon DNA, that's like leaking out to the experience because Amazon is really intentional about this trade office like saying, we prefer that teams would have independence because otherwise it's just, you know, with such a big organization, so many services and so many teams just becomes like a you know, a standstill at some point if you have to, Like so, I can't even imagine what that would look
like if you had every developer at Amazon had to go through like a single infrastructure team to build something we would it takes like six months to get a PR through. There's a there's a couple of other cloud providers out there who may be following that model, and you know, maybe that's what it looks
like. I mean, I see I see WING as this like you know, imagine AWS worked exactly as it did, but there are a couple of things that are cross cutting that just salt Like everyone's like, how can tags not be ubiquitous? Right? There are a couple of things like that which are which would really make the developer experience so much better. And I feel
like maybe it's WING that's giving you that. I think. I think the way we kind of circumvent the challenge is by reducing the surface area, right, because trying to do this across one hundred and eighty services of ABS is no reasonable, right, especially not for a small startup. It's not also
reasonable for like a team of databas. I think one of the challenges we've had with the CDK and constantly having with the CDK, and I think CloudFormation is also having this challenge is basically racing AWS and making sure there's coverage for all the research for the capabilities and feed new features and new services that spin
up every year. And so what we've done with WINGS is said, Okay, hold on for a second, Let's see what's the foundation that is, you know, good enough to build a majority of the applications or a good you know, a good chunk of the applications and create a really great developer experience for that. And it is a very extensible kind of ecosystem play that
we're doing. And so you can actually create libraries and we have like people starting to like publish libraries for Wing and so like it is designed to offer you a general purpose solution. But what we're trying to do is we're trying to focus on the foundation. I think like it's a it's a it's a reverse pyramid, uh. And I think one of the problems with AWS is kind of architectural philosophy is that there's no pyramid in in internally a a WS,
all services are created equal. So s Ree and Robomaker are basically the same, has the same kind of you know, place in the in the architecture. Right, Like it's kind of like a it's a it's a mesh of services as opposed to being like a stack. And I think like not having a stack makes it really hard for a ws's teams to prioritize and say, okay, this is this, these are part of the foundational stack.
Let's make sure that you know, we get it in practice, this is what right like in practice, when we started a CDK, we've you know, we've created as three abstraction API would create it like we've actually done practically, we've done that. But but I think it's if when you don't have that architecturally, then you can't really build holistic experiences based on that stock. And then that's what we're trying to do with me. I don't know if
that made sense philosophical Sometimes it just goes that way. Yeah, So from a practical perspective, what does it look like to get started with Wing? Like if I have my application and of like it's it's already built and running, but I'm signing off on this new approach. How do I what's the transition project or transition process look like for saying I'm going to use Wing to
do that? And how do I get started? So first of all, it's you know, open source and go to Wing lang dot io and you can download it and install it and run it on your machine and it's free, and uh, you get the simulator and the console and everything. And what what we've that's actually an interesting you know, it's an interest. It's a it's a more interesting question. I think that you that maybe we want it to be at this point. But what we've started to do with Wing
is we basically said we want to start from the ideal experience. We want to put it to put that in place. And and so what we've done is we actually created a programming language. We haven't talked about this, but we've actually created a programming language that's that has that has these ideas baked into
the language, and it's built on top of this standard library. It's built on top of this you know, set of abstractions, but it also has this really cool thing called in flight functions, and the idea of inflight functions in the way it's kind of like ACYNC functions in traditional languages, only that inflant functions not only run later in time, they also run in a different place, so you can actually package them and ship them to the cloud.
And what you could do with inflight functions is basically represent the application logic, the run time behavior of your system within the same programming model that you're describing the cloud resources that you're using. So you can basically say new bucket, new queue, new container, and then you can basically specify the code that's running inside the container in the same programming space or new function, new Lembda
function. And the cool thing about this is that when you write this code, this inflight code, you can interact between your inflight and your pre flight resources. So you can basically say bucket, dot put and when this, when this is basically compiled, it compiles to terra form or to any other uh you know target platform. As I said, right like, it's a customizable thing. So we actually have an a b c DK platform, the
compilsitor that can be deployed through cloud formation. And we have someone asking about cross plane platform, which is interesting, right like, basically compiled to Kubernetes siamos and deployed through through Kubernetes. And but when you compile to the Staria platform, the compiler is able to basically bind your runt time code with your infrastructure. And so it basically says, okay, so you need to be
able to put file in the bucket. Great, I need to know the name of the let's say I'm on S three, I need to know the bucket name, and I need the im permissions, these im permissions in order to actually deliver this this application code and and so you get this really really
really nice end to end holistic experience. But what we're realizing, and I guess it's pretty obvious, but what we're doing right now is we're basically offer it starting to offer the ability to use WING just for the infrastructure piece. So basically use all these APIs, but then just bring in your own LAMB the function or your own container. And we already have support for containers, which is pretty cool. We're working on some support for LAMBDAM And in this
case you're binding between your infrastructure and your application. Is obviously requires a bit more a bit more work because those things are now decoupled and not coupled together into the same language. And so to your question, if you have existing code, you can take your application code and use it and then replace your
infrastructure code with WING. So would it be maybe it's like terraform or CloudFormation, So you can basically use way to define your infrastructure and basically point to your application code and bind it together, and then it starts running in a
simulator and you can start compiling different cloud platforms. So yeah, it's it's, it's it's definitely a theme that we've we're working on now, and we kind of have some more work to do in order to streamline this experience because obviously we understand that most people already have some work clouds, and we really do want to be able to bring the value immediately, right Like it doesn't mean it, yeah for sure, And I think it's that's kind of kind
of the reason I phrased the question the way I did, because I think as a community or as an industry, maybe we're all sort of looking for that solution that says, Okay, I'm I'm down with cloud infrastructure, but that's not the solution every time. And you know, we talked we've talked about this already in the episode, that there's a desire to have cloud agnostic solutions and so there's all this legacy stuff and it's problems that we haven't really
face before or saw before. So I think you're very early in this, and there's there's no path right now where you're you're kind of cutting your own path, as are some other people in the industry to figure out what this looks like. And I think it's like the future of what the whole infrastructure world is going to look like a few years from now. They're very optimistic. I like the fact that you both laughed at me, like I've done. No, I was, I was. I was happy to hear that.
No. Obviously obviously optimistic. I was. I was, I obviously you know, I always, I really do believe that. You know, as an engineers, we we want to solve problems. Eventually we solve them. It takes time. We need to crack the crack, the solutions, crack. The The business around solving those problems is you know, one of the things that I'm you know, challenged by right now is like, Okay, I'm an engineer, but you need to build a business act and create
like a commercial story around this. But it's all problem solving eventually, so we'll figure things out. No, I mean, I think it's right on point, because actually last week on the episode, we were talking about the
fact that there needs to be probably a compaction in the space. We need to do some sort of depth first evaluation on a bunch of different things until we find one that actually solves a majority of our stack, majority of the problems that we're having, and then sort of eliminate all of the previous examples. And so right now we're not really sure, especially in the infrastructure deployment
area. I feel like, as Will you pointed out, we don't really know what the best answer is at this moment, and for sure what we've got is not appropriate. Like we can see that there's lots of churn, lots of struggle in the different areas, So I think realistically you may actually
want to start fresh with something new to examine it. There's not really another way, But you know, Flo, as you said, it's a business, right, I think trying to capture those existing everyone has something today, likely if they're making money in some way, So trying to do that migration is going to be a critical path forward totally and possibly, like you were
just alluding to Warren, maybe a bit premature. Like the first thing is to just do a new project and see what the see what it looks like, and kind of iron out that flow and then figure out, Okay, now, how do we use this to onboard all of the legacy stuff that we're that kind of forced us to look at this problem. Oh yeah, every company should be doing pocs with experiments like I don't know, each team
should be doing at least once maybe once a month. And if they're not, you know, then you have this extra capacity where you're not actually figuring out how can we push our business forward with a huge step change? Right? You know, how what can we do with innovative in our space? So it doesn't really matter where it's at, the idea is, of course, experiment with something new and figure out how you can maybe use that effective in a future real business case. Yeah. So yeah, if people are
experimenting with wing, we'd love feedback. We'd love to learn about people's use cases and what they're trying to achieve and what they like, what they don't like. More than happy to talk to anyone. What's the time commitment look like for checking out like the Hello World version of using wing? How long does it take to get up and run? In? Fifteen minutes? Ten
minutes? Nice, super quick, super quick? Right on? I think you've got a I don't think you saw this a whole Discord community dedicated to the project to Yeah, it was a Slack community until last week. So yeah, come join our new Discord. It's it's uh, we're ramping it up and it's been just a coincidence. Has nothing to do with their policy change, Actually not, it's it has to do with you know, the community just grew to a point where it was like didn't make sense financially to
support the slack Slack stuff. Yeah, for sure that that gets out of control really really quick. Yeah. Yeah, but yeah, as you mentioned, Warren, the policy change has been has been the best thing to happen to Discord in years. I mean it's right online because uh, you know, Discord wants to IPO at some point, so uh you know, I feel like having those wins in there in their bag is important. Just need Microsoft teams to uh continue on. It's pretty as bad. Yeah. Every
product has their like product name and tagline. For Discord, it's going to be Discord. We're not Slack. Yeah, it's it's I like, I really like the playfulness and the like. There's some weirdness, like it takes use to definitely if you're coming from Slack, But I like the pay playfulness. I like all the community features, the events, the uh. It definitely feels like we've debated it when we started the when we started the community, and it was a mistake. I feel like we should have started with
Discord. I feel like Discord has come a long way, and probably in the last two years, I'm going to say as far as like the number of features and options, but the biggest one for me has been the improvements they've made. And like the onboarding experience and getting started because it was early on it was a hassle to get connected and God forbid you. You get a second device and have to sign in again. It's like, ah,
it's great, I'm just starting a new account. Yeah, totally. Or you make it through the onboarding experience and realized you did create a second account without meaning to cool. So anything that we should have covered that we haven't talked about yet. For Wing, No, I think you let me talk a lot. That's that's my job. Give an introvert to mic and everything else works itself out. Awesome, man, Well let's do some pics, Warren. Did you bring a pick this week? Yeah, of course,
right, that's a sort of requirement for sure. My pick is going to be Building micro Services by Sam Newman, So I'm going to stay on my book trend. Really, I feel like this is what converted me to personally the micro services in my career, where the advantages are really hot, to think about them, how to interface between them, how to build them effectively. Uh, it's a really great book. Honestly, I think it's still in the community. It's probably considered the I don't say holy Grail, but
for sure relic that represents how to how to push the industry forward? Ran excellent. What about you? I'll pick The Three Body Problem. Have you had a chance to watch it? Both both actually like the the I read the books a while ago, and probably one of the best science fiction serious I've ever read. I really love science fiction, and this one's like the first book is a bit it. I actually read the first one and only read the second one kind of got came back to the serious few years later.
It didn't, it didn't make it didn't. It didn't for some reason then when it didn't want to continue. But then as you continue to read the series, it's just amazing. It's just an amazing story and beautifully written and creative and it goes really really really far, and so I think like Netflix has just released the first season and it was so much fun to watch, especially knowing where this is going, and so highly recommend this the book
series and the and the show. And it's like it's it's there's something I think I can tell, like the kind of like the theme basically is aliens are coming in three hundred years. We know that they're coming. What happens with humanity? Right? Like what what does this knowledge due to humanity? Right? Like that's just crazy? So right you mentioned you you also read a little bit some of it. I read the first two books and seen the show. Honestly, they're sort of like the same concept but different,
completely different content as far as watching or reading. Obviously the same challenge, but they go in different directions, so you can get the same enjoyment twice by by going about them. It's not really like book is better than the movie. Yeah, yeah, which is very rare. It's very differ.
Both of them are very very well done, for sure. I mean I feel like you said something controversial when you said it's the best science fiction I have, you know, but I don't want to get this into an argument said, it's almost the best, because to me, the best always foundation. It's always like, oh man, see, you know, just agree to disagree there, Okay, no, no gloves come off, let's go. Oh for sure, for sure it's Frank Herbert's Dune, hands down,
no question. I admit I didn't. I didn't read the book, so maybe I should. I know that I should know that I should. It's like the idea of world building is so far, even beyond the three body problem. How to think about it and the things that are generated in order to further the universe. Also the length of time, you know, much more further out than even three body problem. It's nuts, it's not you
haven't read the last book. Yeah, so all right, So what I'm hearing here is Warren is going to go read the third book and then you're going to come back on the show and we're gonna Yeah, he's just trying to read The Expense now, which is also pretty good for sure, also great science fiction book. Will just trying to get out of sharing his pick though. Oh no, I'm ready with a pick. Mine is is it's
about knife sharpening because I did not know this was a rabbit hole. I was gonna go down, right, So I ended up watching Alex over on the Outdoors fifty five YouTube channel on how to sharpen your knife. And he's got to have a complete list of his videos here. It doesn't say him two hundred and sixty three videos on how to sharpen your knives. I didn't know you could talk about it that many times, but they're all like super
interesting. And as a result, I bought a diamond grit sharpening stone and have been going through and sharpening all my eyes And I thought I could do a pretty decent job of sharpening and eyes before, but this takes it to a whole new level, like surgical grade sharpening. And so go check out, go check out his channel. Outdoors fifty five is the YouTube channel for two reasons. One, so you can learn everything you didn't know that you
needed to know about sharpening your knife. But also just like the content creation, yeah right, And but also just like for content creation, like how do you create two hundred and sixty three entertaining videos about the same topic, Because he's done that, so it's actually pretty cool to share off for two reasons, and that's my pick for the week. Cool, all right,
well, thanks for joining us, Eeled. This is being cool and I'm yeah, I'm excited about this because I you know, I I really think that this is the direction our industry is going is until it's an interesting space. There's quite a few people working on this, and and so yeah, I think it's super cool. Really appreciate you taking the time to come and
sit with us on a show. Thanks for having me guys, yeah, Lawren, thank you, appreciate having you here and for yeah, I guess most importantly to everyone listening, thanks for listening, because that's not really a whole lot of reason for us to do this if you're not listening. Oh does it for himself? Right? Awesome? All right, Well it's getting awkward at this point, so I'm gonna kill the stream and thanks again, and we'll see you all next week.