Join us at the hedge for a conversation
about engineering,
technology, and business. This week, Russ White, Tom
Ammon, and Derek Winkworth dig into automation.
So, Tom, how are you?
Doing good. Ready for the weekend. Ready for
the weekend. Derek, how are you?
I'm good. I'm I'm also ready for the
weekend. I, although I probably won't do a
lot outside because it's supposed to be crazy
hot tomorrow
Yeah, I know I know it is that
time of year and that heat wave has
been coming through and really it's kind of
crazy how hot it's been Yeah, I just
got off. I just did a three hour
webinar on data center design for Pearson So
I just got off that recording. So if
my voice sounds a little off, that's because
it's a little off.
You've been talking for three hours. I've been
talking for three.
It's a little bit crazy.
So, Derek, let's back up. You
you talk about your days as a network
engineer in the for in the far distant
past
before your current life
Yeah, you're one of the smart ones you
got out of network engineering before it drove
you crazy
What did I do to myself?
Oh, man. Yeah. It's true.
It it is a very stressful job, and
it's and it's insane. Like, the being
choosing to be a network engineer
is, it's it kind of is an insane
thing to choose to be,
for sure.
So talk to me about automation. You start
we started talking about automation a little bit
in the life of a network engineer, so
let's back up your your experience.
Because I know you mostly do automation today.
Right? That's mostly where you work is around
automation and cloud stuff.
Yep.
Yeah. Yeah. So I,
that that's what I do, I guess. I
I,
the reason why I sort of left the
customer side and went to the vendor side
was is in part was entirely because of
automation. That was right around the time that
SDN was in its, you know, at the
peak of its hype cycle that I decided
to,
decided to come to the vendor side, the
dark side.
And,
part of my motivation was whenever I talk
to people about network automation on the vendor
side or even on the customer side, then
one of the things that kinda blew my
mind
is they wanted to they wanted an automated
network.
And when you ask them what that meant,
you know, they I love that. An automated
network. Yeah. I just I want an automated
network. I don't know. Yeah. What does that
even mean? Right? So you would ask them,
and they would say, well, if this thing
happens in the network, then I want some
system that'll automatically go and and do some
kind of,
configuration change or some kind of action that'll
alter the behavior of the network.
And I thought that was insane, right? Because
you have this networks are already very complicated,
and they're built on fragile components.
And,
you know, they're they're already very dynamic by
their very nature, right? They I mean, we
have dynamic protocols and, you know, every everything
is dynamic. Right? The way every everything in
the network works. When you have bonded interfaces,
right, they they
go down and come back up and the
system automatically,
adjusts, you know, how it forwards according to
those the state of the interface.
Like, everything is is already automatic.
So when you wanna add more dynamic behavior
on top of a system that's already dynamic
and which already, if you if you stop
to think about it, is is already barely
functions.
There is no such thing as a network
that you can ignore because it it'll always
fail in some way.
And now you wanna add more dynamic behavior
on top of that. And to me,
that that sounds crazy. Right? And I
and I, and I, what we ought to
be automating in my mind is what I
always thought was we ought to be automating
what network engineers actually do.
And,
and therein
lies the gist, you know, if, or the
devil's in the details, as they say. If
you ask a network engineer what they do,
they'll say things like, well, I configure BGP,
and or, you know, I build
data center networks, or I configure VLANs, or
whatever they say. And if you ask, like
a typical product manager at a network vendor
what network engineers do,
they'll reiterate that. And there's so there's this,
you know,
unrealistic perception about what we ought to be
automating because people don't actually
they they actually have no clue what network
engineers actually do, including network engineers themselves.
I was gonna say, don't yeah. Yeah.
That's right. Because we don't know what we
do for a living.
Yeah. It it's true. And if you you
know what is crazy about that statement? I
mean, just to go a little bit outside
the automation realm is that I've never been
a network engineer anywhere where I only did
network engineering. Right? I I always had to
do
some other,
residual set
of things, whether that was actually troubleshooting applications,
you know, maintaining,
like, a server somewhere that no one else
wants to maintain. Right? The UNIX guys will
stand the server up, and and it has
some function like DNS or or, network a
network management system, and they're not gonna no
one wants to manage that. So,
you always end up you always have ancillary
duties as a as a network engineer. So
that that muddies the water even more.
Oh, definitely. Yeah. Definitely. Yeah. That that's that's
an interesting observation.
And I think a lot of people don't
think about that. Right? They think, well, you
just do network engineering. But in reality, you
are maintaining all these odd servers and all
this stuff that people have put out there,
and you're just like, I
I don't know. How did I end up
being a sysadmin? I don't know, but I
did.
You you know what I've always wondered? And
with your exposure to customers, Derek, maybe you
have some insights on this. What do you
think what percentage of an engineer network engineer's
workload do they actually really enjoy?
Would you say it's 50% for most engineers?
10? 20? Do they do they enjoy?
Wow. That's a well, I'm sure that's a
very subjective thing, but Yeah. Sure. I,
I would say it's very small. It's very
I'll give you an I'll so you know
what? I'll start off with an analogy, and
then I'll explain explain what I mean.
One of the one of the,
like, moments of joy that I, I was
just overcome with joy and like this immense
satisfaction
in the last few, probably last five years,
was when, I had to build a fence
in my yard because we wanted to install
a pool in our yard. And
the, the town said, well, you gotta have
a fence because it's an attractive nuisance.
And kids, you know, a kid might climb
in the ladder and go in the pool.
Mhmm. So,
we decided to build the the fence ourselves.
I I bought an earth logger. We bought
all the stuff. I had a friend who
had some experience building a fence. He helped
me. And at the end of it, like,
when we got done with that project, like,
there was the fence.
Right? It was like, oh my gosh, like
I had a project
that actually finished. And I can look at
it and say that thing is I made
that thing, right? And it has a purpose,
has a function. And it's still standing doing
the same thing it was meant to do
at the time I built it.
That is a very rare
occasion in the realm of network engineering, unless
maybe you're a contractor
and you can say, you know, my engagement
is done. But when you work for a
company,
it's it's a pretty rare thing
to to feel like
you
you built that or you, you know, you
did something, right?
Other than getting yelled at and and putting
out fires all the time.
And so I that was I like that
feeling of having having built something. And so,
it you know, if if that when you
get when you're when you go up the
chain as a network engineer and you get
into design and architecture,
those,
that experience becomes, you know, once every
few months, twice a year sometimes, depending on
your projects.
And that's and and even then it's like,
you don't get the same satisfaction because it's
pretty rare
that by the time the project is getting
to implementation that you're actually building the thing
you should have built. Because it's been, you
know, everyone's had an opinion that's been pared
down. You're not you're not actually building it
the right way because they wanted to cut
costs. Or there's other restrictions like, you know,
oh, we're gonna have two routers. Well, actually,
we can't get two routers into this building
because there's physically not enough space,
or not enough power. Right? There's always something
that get and then so you build it
and you're like, oh, you just look at
it and you know, this is going this
is I'm gonna have a relationship with this
installation now for the rest of my career
at this at this point. It's gonna fail
all the time. Right?
So it's it's pretty rare to get that
that a sense of accomplishment or enjoyment, I
think.
But I do enjoy I did enjoy troubleshooting,
quite a bit because I was I was
good at it. And,
I could troubleshoot all kinds of odd things
like voice systems and, you know, things that
I don't even necessarily have training in,
because I,
I don't it's just something I like doing.
Right? I like digging rabbit holes until I
figure out what's going on. Just and the
reason I guess the reason I asked that
is I was reading through some of your
blog posts and,
talking about how we do a lot of,
you know, mental modeling as network engineers. You
know, we build models to try and figure
out what happened or what's going to happen.
A lot of the network engineers that I
talked to, it seems like
they like automation because they get to build
something again. Instead of in my experience, it's
exactly what you're talking about. You don't actually
get a build very much when it comes
down to it, you know, especially the more
senior you get.
But it seems like automation gives us a
chance to to build something and complete something.
And in most companies, automation, at least my
experience, is never done. You're always going to
be building that thing and tweaking it and
all that kind of stuff. So,
do you does that resonate with other people?
I mean, is that why engineers like to
do automation, do you think? Or are there
other other things? Yeah. I think so. That's
true. You get to what I well, what
I like about the current sort of strain
of automation, when when SDN got huge, right,
it was all
like network engineers are the mainframe programmers of
the day. Right? And and if you remember,
hold on. I always forget the name of
the company. The the one that got bought
by VMware that became NSX. This was, Nicero.
Nicero. Yeah. Nicero.
They they actually would tell customers,
you know,
do not invite the network engineer to this
meeting. And they would talk to the server
guys.
And because they because they're they're irrelevant now,
or you don't need them. Right? That's that's
that was their message.
It was it was crazy, and it and
that's still a thing in Silicon Valley. There
are companies that really believe they're going to
obviate the need for network engineers. Oh, I
I know some I know some companies that
refuse to hire network engineers in the future.
You know, they're they're shape reshaping their teams
to be
coders. They only hire coders because they don't
really think they need network engineers any longer,
and they run networks, big ones. Mhmm. That's,
like, that's okay. Mhmm. And
big ones.
That's, like, that's okay.
K. That's a but you know what? GitHub
is one of the examples that people used
to love the town. Like, we don't have
any network engineers for our network, and now
they have them. Now they have several,
because it's
you need that expertise. And what I what
I like about the current crop of automation
is that you've gotten a little bit away
from the, you know, you're irrelevant to,
you know what, we need to start automating
what network engineers actually do. And,
and, of course, we're gonna need people who
understand
network engineering
to do it right.
So it's, I
I think there's I think there's enthusiasm around
that message for sure. So that's interesting. Let's
go back up because you said, you know,
what does a network engineer actually do? And
we don't actually know what we do. So
let's talk about that in automation a little
bit. I mean, how does that how does
that work out? I mean, what do we
what what is it we should be trying
to automate if it's not configuration?
Yeah. So,
that well, the modeling thing I was talking
about earlier. Right? I and one of one
of my I'm you know, we need to
republish these blog posts because everyone listening to
this,
if you're out there, none of there none
of them are on the Internet anymore because
it was I wrote these at a previous
company and that website's gone. But I
I'll republish these. Actually, I'll work on, I'll
rewrite these and republish them.
The, one of the blog posts I wrote
was what a network engineer actually does.
And
I was sort of inspired, I have this,
I have a bunch of books on, like
the psychology of
thinking, like how do and there's one of
those books is almost a whole book, every
chapter they talk about engineers in particular.
These, and these are psychologists, right? Like how
do they,
like conceptually model in their mind the things
that they work on, right?
And,
I, and
from that, I started really thinking about what,
what engineers what network engineers do. And we
have this sort of
graph model in our minds. Right? We have,
this big graph model in our mind of
of the elements in our network and and
the relationships between them. And so when we're
thinking about a problem, you know, we're we're
we're traversing
that graph in our mind. And when we're
typing command when we're gathering information about the
state of the network, it's, the most common
workflow
for this would be I'm gonna give an
example of, of how this
I'm I'm calling it referential traversal as you
go through this graph in your mind. When
you're trying to find an endpoint in the
network and you have an IP address, so
you start in the middle and you type
in show IP route and you get a
next stop. Right? You you you see the,
what the next stop is.
And then
you do a, you know, show LLDP and
see if you can see the a router
that's tied to that interface out that next
hop. And then you SSH over to that
router. And then you type in show IP
route. And that might be
a router where the IRB interface, the layer
three interfaces.
So, you do a show IP route, now
it's connected. Right? And it's an IRB interface.
So now you type in show ARP. Right?
And you do a show ARP for the
IP address of the thing you're looking for,
and now you get a MAC address.
And now you have the MAC address, and
so you're you type in show, you know,
you start looking for that MAC address in
tables, and then eventually,
you know, you might go another another hop
or in a switch now,
the next switch over. And then,
you you figure out
where that,
MAC address is is attached to the edge
of your network. And so now you found
where that thing is. Well, you've you started
off with, like, one piece of information that
got transformed into another piece of information,
which is the, you know, the MAC address
and then that MAC address translated into
an interface ID and a host name. So
you've
and and I call that referential traversal. You're
using the last piece piece of information to
look up the next piece of information to
look up the next piece of information.
And that's a pretty common that's
90% of what we do as engineers,
as network engineers.
You know, when we're troubleshooting a network or
we're thinking about
not not just troubleshooting, but when we're thinking
about a design change or something like that,
and we're trying to model
what we need to do, we're we're filling
that graph out in our mind, and we're
and the commands we type allow us to,
get an accurate
real time sort of view of of of
the state of the network relative to that
problem.
So that's to me, that's what we ought
to be focusing on for for automation. We
should maybe because that is
again,
your ability to model, whether you're troubleshooting or
doing something else, is a direct reflection of
your experience and expertise. And
it's the one thing, if you do very,
very well,
it makes it very easy to make the
right decisions,
design choices,
configuration changes, etcetera,
remedial remediation,
changes.
It it makes you it it gives you
the ability to make
the right choices. Right? In good, informed choices
and not, you know,
doing it terribly wrong and blowing things up,
I guess.
That's that's actually a really interesting way of
looking at it because I've always said I've
always believed that modeling is if I were
somebody coming into this field, when I tell
people, I tell them to read a lot,
and they're like, why should I read a
lot? Because you've gotta learn to model. I
mean, modeling is
the whole key
to being a good network engineer. It just
is. If you can't do it, then
you just might as well give up because
you're not gonna get anywhere.
So what's the so that that modeling exercise
where you show route and then you show
up and you traverse the layer three and
the layer two,
a human does it at a certain speed.
They're not that many humans, maybe none, that
can do that at the speed that a
computer can do it at. So what would
you say is the consequence of giving that
work over to a computer? What is it?
I mean, it's important. The network engineer needs
to do that, but if a network engineer
doesn't have to bash key, you know, keys
on the keyboard anymore, what what's the what
is where does that bring us to? What's
the consequence of that for network engineers?
Yeah. Well, I don't think,
I don't think automation is going to completely
eliminate the need for people to to be
at the keyboard, but what it can do
is, look, it takes time to do that.
Right? And all you need is the model.
Right? You just need to understand the state
of something.
Like, that that's all you need. If you
gotta log in to two or three or
four different devices
to figure out what's happening in a VERP
domain,
VRRP domain.
You know, and and you don't and you
don't do it right,
you know,
you're gonna you're gonna take time doing it,
you're gonna potentially make mistakes, or you could
have an automation
that collects all the information and presents it
to you in an easily consumable way. So
you understand immediately,
you know, you have a a good,
immediate working model of of what's happening in
that verb domain versus you trying to to
build that model yourself. And at the time
and the and you know what? Even if
you're a CCIE or a JNCIE or whatever,
I I know I I had two CCIEs,
I had a JNCIE.
I I all I still made mistakes all
the time. Like, I wasn't, you know, you
you forget or you don't or you overlook
something and then you're, you know, you could
waste two or three days worth of time
based on, some bad understanding because you did
something wrong, and now you got you you've
lost that time. So the consequence is actually
very positive for network engineers. It makes them
more effective.
And, and I think it it'll ultimately, it'll
help right? Network engineers are not very
well trusted by their organizations.
They may they they they might believe they
are, but if you I don't know. Any
place that would look at a network engineer
and say, you know what? I know it's
10:00 on Monday, but go ahead and make
those changes in the core of the network.
It's like that this isn't Yeah. Yeah. Not
gonna happen. So I think, you know,
it'll make them more effective, and, ultimately, it'll
it'll help build trust better. It'll it'll it'll
improve the relationship network engineers have with the
organization.
So, essentially, your argument is we need to
think how to automate
what network engineers actually do, which is day
to day
just this traversal process of understanding how the
network works,
finding things in the network, things like that.
Yeah. Yeah. And I'm not saying that configuration
is important or we or we can't automate
those things,
but we have lots of tools already for
doing
automating configuration changes. Right? We can feed Yeah.
There's now you can feed spreadsheets into Ansible
so we can configure VLANs all over your
network. I mean,
we have lots of tooling for that, but
we have almost no tooling for look, most
network engineers can only make those changes, during
a short window of time during the week.
Usually, at at the most inconvenient time, like,
Sunday at, like, two or 3AM,
they're making those changes.
And then the rest of the week, what
are they doing? You know, if I you
know, we ought to be
focusing on what they're doing in the rest
of the week,
I think.
Yeah. I like that, actually. Yeah. And, again,
I go back to this.
We don't really think a lot about what
it is,
like you said, what network engineers are actually
doing. And a lot of it is around
modeling. So tools that help you understand the
way the network actually works
and model the way things are. Now this
goes back as well to,
we have a serious problem in the networking
industry, and maybe this view of,
maybe this view of model driven
automation is a big deal here because
one of the big problems I think we
have in the networking industry is we've know
we have a lot of people who don't
know networking,
And they're network engineers. I mean, I'm I'm
not being, I'm not trying to be, you
know,
it's just the truth. We have a ton
of people
who understand how to configure things and understand
if I take this this product and I
put it with that product, I can make
this product do that. And they understand the
products really well. But they just don't understand
the network at all. They just totally they're
lost when it comes to the network itself.
So I think maybe thinking about this could
actually be a way, a wedge to say,
we need to actually think about how the
network works. We need to think about how
the network. We we need to talk about
traversing this and saying, oh, I'm gonna traverse
I'm gonna do a show IP route here
and do this and do that.
Alright. But what you've got to think about
is
when you look at that, what you're actually
doing is you're thinking about how does the
network converge?
How is how is that about advertised?
How am I getting this information? Where does
this come from?
This is not configuration level stuff. This is
how does it actually work? This is not
even packet level stuff. And by the way,
I know lots of people who know the
packet level details really, really well, and they
know how to configure it, and they still
can't tell me how BGP converges on a
Clove fabric. They still know. They're totally lost.
I don't know. If you asked me that
question right now, I probably fell at answering
it.
I, well, but this is a, this is
a really good point. I, and a lot
of people don't, you know,
they don't understand just how much they don't
know. I think one of the most humbling
experiences I've ever had was working for Dave
Meyer at Brocade,
and going to an IETF meeting
because I thought, Hey, you know, I'm, I'm,
I've had these certifications. I've read different, you
know, George,
Voorhees' book on
network algorithmics. You know, I've have, I have
some different books like that that are quasi
comp sci level,
stuff about
networking algorithms.
And,
and then I go to I start working
for Dave, and I go to an ITF
meeting, and I'm, like, my head is melting.
Like, oh my gosh. I had
maybe the dumbest person in Prague right now
when I was I was in Prague at
the ITF.
People gave them arguments about like K fan
out and stuff with multicast and like, you
know,
giving pulling out a sheet of paper and
writing down, you know, like math and, and
arguing
about multicast. And
I've never thought about it at that level,
because I don't, I don't design protocols. And
you know what, I think,
I do think if more people understood that
stuff,
our, we,
our field would be in much better shape
than it is now. We, we've, our knowledge
has been driven by certifications that have dollar
value tied to them. So where do we
put our brain cycles and what knowledge do
we ingest? We ingest the thing
that has the biggest payoff,
or a most immediate payoff. Right? Not the
thing that probably actually helps us serve the
business better. Yep. I think I think that's
absolutely true. Yeah. I think that's absolutely true.
And so, I mean, it's a good thing.
Certifications are a good thing, and they're a
bad thing. I mean, everything is trade offs.
And I always say this, if you can't
find the trade offs, then you haven't looked
hard enough. Because I think that's just the
way it is, and we often take things
as absolute in our field, and we don't
think about the trade offs and what they
actually mean and, how how you work around
that.
And and I think that also as well
that we we do like you said, we
ingest what we think will make us more
valuable tomorrow,
and the business
wants the network to run, so we think
what makes the network run is knowing how
to configure hardware
and software. That's that's what it comes down
to. And that's not really,
and that also leads us down the whole
complexity path. Right? Oh, if I could just
get this nerd knob,
then I could solve that problem and the
network would just work.
No. Yeah. No. No. No. No. It won't.
Trust me.
Trust me. I've coded a few of those
nerd knobs. You actually don't want them.
Yeah. That's true. I,
there's a there's a really great book called
MPLS enabled applications,
that that I think they published through. Oh,
yeah. Yeah. Yeah. Like, three editions of it.
Right?
What I really love about that book is
it was,
if if, if you haven't read it is
they they go into they explain in Junos
where where some of these nerd knobs came
from and the very
specific network designs and use cases they were
they were meant for. Right. And, and why
you wouldn't wanna use them if you don't
have that network design because it can, you
know, it's gonna cause convergence problems, it's gonna
cause,
whatever. You know, all memory, CPU problems, all
kinds of things.
And,
and and
yeah. The if only I could filter out,
you know, the, the BGP option that says
this route went through a route reflector, then
then I can make my network do anything,
including exploding.
It's like opening up,
for sure.
And then it explodes, and you're up at
02:00 in the morning trying to fix it
and complaining about how stressful your job is.
So
But the complexity thing is is interesting because,
people have no scale of reference for what
is complex and what is simple,
in in networking. That's another thing that I
I find people they throw those words around,
as as,
sort of to win arguments. Right? Mhmm. Well,
I don't use MPLS because I like to
keep it simple. So
what I do is, you know, and instead
of just using a VRF, what they do
is they build a network and put a
firewall on it that NATs, and they do
that. And everywhere
around their network, and then they have a
core, and they're like, see, super simple. And
then
in three years, no, okay, so you have
no dynamic routing beyond, you know, between
going into
throughout your network. And second, you know,
in two or three years, almost guaranteed every
time they have permit any any on all
those firewalls.
Yep. So basically, you have a statically routed
node
sitting in
all around your network because you wanted to
keep it simple. Right? And by the way,
all those firewalls are clustered and the clustering
fails all the time. Glad, super glad we
can. But but it's okay to make the
configuration of all those static routes.
Yeah.
I I think some people use complexity as
a kind of a pseudonym for I don't
understand or I don't I don't fully grasp
it. It's complex. I don't I don't wanna
go there. I don't know. Or I don't
know it. I don't know how to configure
that. So therefore, it's complex. Mhmm. Right. Yeah.
I think I think that's I think that's
a very common thing.
Yeah. So
alright. Cool. So
what else you got, Derek? Anything else you
wanna add to this before we close off
this recording and bring you back on in
the future? Because I know we're gonna have
to bring you back on now because this
has been a great show.
Yeah, thanks. Yeah, it was fun. No, just
thanks for having me. And,
you know, I'm gonna try to combine these,
these,
these blog posts into there's several of them,
and I think they can all be fit
together into one longer,
maybe, white papers thing or something like that.
And we'll publish them somewhere. Yeah. Yeah. Yeah.
Cool. And tell me, mate, and I'll put
them in the show notes when you do
so. So I just also wanna say,
for people who wanna understand how networks work,
I have,
I'm gonna I'm gonna do something that seems
cheesy, but I I gotta say,
your book that you wrote that, you you
told me to to look through was is
absolutely fantastic. That's
it's Oh, thanks. It's a permanent thing on
myself. The one you just wrote about, Problems
and Solutions in Computer Networking.
Yes. That's a fantastic book. I really think
it's more of a mindset than it is
what's in the book itself, honestly, in many
ways. It's just thinking through,
this is a problem. What am I what
are my possible solutions? Right? And that's really
I mean, I know it's a big book
for just trying to say that, but I
think
that's I think that's the bottom line. So
so, Tom, you're not blogging right now. Right?
No. No. Not at the
moment. Yeah. We're gonna fix that eventually, but
it's okay. And I know Derek doesn't blog
right now, but you're on LinkedIn. Right, Derek?
Twitter?
Twitter. On Twitter.
Yeah. I'm I'm on Twitter. I'm at CloudToad.
And, right now my, my big thing in
life is an open source project called NRE
Labs, that you can also follow on Twitter
at NRE Labs. It's about network automation,
and how we're trying to rebrand network automation
as actually reliability engineering.
So Which we should talk about that sometime,
actually, because that's a really cool concept. It's
just the concept of network reliability engineering
Yeah. Is a really good one. Yeah.
So good. Excellent. So in our labs, people
can find you there and they can actually
go to n r e labs
and try out some of the open source
stuff that you've been working on as far
as
like, just trying automation out, like it's out
there. You can go try it.
Yeah. Oh, yeah. It's really cool. You get
your own interactive sandbox environment with real networking
nodes.
It's and it's marketing wall free. You don't
have to give your email, your name, anything
like that. You can just click on a
lesson, and then in your browser, you get
this sandbox environment and some instructional
stuff for, you know, for a given automation
topic.
And the URL for that is labs.networkreliability.engineering.
Okay. Cool. I'll put I'll try to remember
to put it in the show notes too.
So back to you, Tom. You're on Twitter.
Right? Yeah. Twitter at Tom Ammon and then
also on LinkedIn. Okay. Cool. And I'm Russ.
You know, he's getting me at rule eleven
dot tech on Twitter, routing geek. Although, I
don't PM on Twitter for the most part.
I really don't log in very much
and,
I'm also on Linkedin. You can always find
me there. So that's cool And thanks for
joining us for this episode of the hedge
and we'll see you next time
Thank you for joining us. You can find
the hedge at rule11.tech.