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.