September 10, 2024 • 45 mins
In this enlightening episode, we dive deep into the world of application networking with Marino Wijay, Staff Solutions Architect at Kong. Marino shares his journey from traditional network engineering to the cloud-native space, offering valuable insights for professionals looking to make a similar transition. We explore the parallels between VPNs and service meshes, discuss the evolution of networking technologies, and unpack the complexities of modern application architectures. Marino also shares his experiences as a CNCF ambassador and provides guidance for those interested in getting involved with the cloud-native community.
Where to Find Marino Wijay
- Twitter: https://x.com/virtualized6ix
- LinkedIn: https://www.linkedin.com/in/mwijay/
- Blog: https://marinow.hashnode.dev/
- Sessionize: https://sessionize.com/marinow/
- YouTube: https://www.youtube.com/@marinowijay
Show Links
- Container Lab: https://containerlab.dev/
- Cilium CNI: https://cilium.io/
- CNCF: https://www.cncf.io/
- KubeCon: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
- Istio Service Mesh: https://istio.io/
- Ambient Mesh: https://istio.io/latest/docs/ops/ambient/
- Tailscale: https://tailscale.com/
Follow, Like, and Subscribe!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Marino (00:00):
Now these data planes are communicating with other
data planes using a protocolcalled MTLS, but that MTLS
protocol is simply a tunnelingmechanism.
William (00:09):
What is a VPN?
Marino (00:11):
A tunneling mechanism.
William (00:24):
Coming to you from the Cloud Gambit studio.
This is your host, William, andwith me, my co-host, the
world-famous, highlydistinguished cloud philosopher,
Yvonne Sharp.
How are you doing today?
Eyvonne (00:39):
Hello, I was trying to avoid the eye roll but I
couldn't quite manage it.
But thank you, William, forthat introduction.
William (00:48):
Awesome.
And also with us is Marino,with Jay.
How are you doing today, marino?
Marino (00:54):
I'm doing very well, it's Friday and that's the best
part.
It's like almost the weekendand, as I was talking about
earlier, friday is generally thebusiest day.
How are you both doing?
William (01:04):
All good here, busy with kids this morning, getting
them ready for school and allthat noise.
But other than that, yeah.
Eyvonne (01:11):
In theory I have a light meeting day.
I have high aspirations ofgetting some stuff done, so
we'll see how that goes.
William (01:18):
Good luck with that.
Marino (01:20):
Yeah.
William (01:21):
Yeah, so you come to us from the beautiful, usually
much colder than Kentucky,Ontario, Canada correct.
Marino (01:31):
That is correct.
I'm just outside of a verylittle city called Toronto.
I live in Whitby, but Torontois probably the most familiar
city I can use and people wouldimmediately recognize it.
And I've lived here all my life.
You know, I've kind of grown upin the area and seen how it's
transformed and morphed into.
(01:52):
You know what it is today.
It's a bit of a tech hub.
There's a lot of thrivingopportunity here and, just you
know, a very diverse culture outthis way.
So you know, I love being outhere, but I also love traveling
too.
It's fun to get around and seewhat other people are doing and
what other cities are up to.
William (02:11):
Awesome, yeah, and you're not a hockey fan, are you
?
Marino (02:16):
I'm actually not a huge sports fan.
You know what?
I will go watch basketballgames.
If my sister's like, hey, Isome tickets, let's go, let's go
hang out.
I'm like, yeah, sure, whateverthree hours, let's kill in the
stadium and hang out for a bit.
But I can't.
I don't have the patience orthe um, the focus level to pay
(02:36):
attention to like baseball orhockey or any other sport,
because it's just, I don't know,just me I hear you had to ask.
William (02:43):
I'm a hockey fan and every time I I'm a hockey fan
and every time I can findanother hockey fan is a special
moment.
There's not very many out therethat I talk to day in and day
out, so I'm always asking.
But yeah, so kind of back towhat I was saying.
Before we hit the record button, I had two separate individuals
reach out to me, like probablywithin a month of each other,
saying hey, you need to havemarino on the show.
(03:11):
You know you need to reach out.
So I I love suggestions forawesome guests you know to have
on in the future.
So if anyone in the audiencehas any ideas for future
episodes, avon and I are allears always.
Um, yeah, so do you want togive us a brief overview, just
kind of, of your background?
Marino (03:26):
Yeah, absolutely so.
Currently, as I reside inCanada, I work as a remote
solutions architect for an APIgateway company called Kong, and
a lot of my career whether inthe data center, in the cloud
space or Kubernetes a lot of ithad a lot to do with networking
and that kind of brought me tothis place, brought me to what
(03:49):
I'm doing today.
In a lot of ways, though,through my journey, I focused on
certifications, took a varietyof courses, changed job roles
quite a lot to try differentthings and see how different
roles function and how theyinteract with either the
community or within theorganization or across
(04:10):
organizations in across-functional manner.
So I've learned a lot.
But I've also sat there andrealized there's still so much
to learn, tech-wise,environment-wise, to understand
how organizations run.
And you know, I come down to therealization that a lot of the
decision-making that happens,especially in massive
(04:30):
organizations, tends to bepolitical decisions at times.
And I sat there kind of goingback and forth with this a few
days ago because I was askingone of my end users about some
decision that they made a whileback why did you decide that
you'd use this workloadenvironment along with this one,
when you could just accomplisheverything with one, and there
(04:55):
was a lot of dancing around theanswer and I came to the
conclusion that a lot of thiswasn't their own decision.
It was just coming from the top, from the top down, because of
some agreement that was made.
So to get to that point ofrealization, obviously I've had
to work through different partsof my career work in support,
work in pre-sales work, inarchitecture, work in
(05:16):
implementation and even thedeveloper relations side of
things and it just opens youreyes to what goes on in the
industry and how organizationsmake the decisions that they do.
Eyvonne (05:28):
I had a.
I had a.
I made a pivotal kind ofdiscovery at one point in my
career and I naively believedfor a long time that that the
right, the best technicalsolution wins.
And the goal was to be right,to find the right answer, to
find the best solution to meetall the requirements.
And that was what it was to besuccessful.
(05:53):
And I had this moment ofclarity where I'm like, wait a
minute, you can do all of thosethings and still not get
decision makers on board, andthat there's a human component
to our work.
And for me that's really when Istarted reading on
(06:13):
organizational psychology andKahneman and Tversky and trying
to understand more of the humanelement of decision making,
Because at the end of the day,people are implementing
technology and making technologydecisions and that really
shifted the trajectory of theday.
People are implementingtechnology and making technology
decisions and that reallyshifted the trajectory of my
career.
So it's interesting to hear youbring that up this early in the
(06:34):
conversation about yourtrajectory as well have.
William (06:37):
You've probably made a life living, you know, somewhere
in between the physical layer,like layer one of the osi model,
and like layer three.
You know the network layer ofthe osi model.
So you know basically from thatphysical connectivity of bits
up to the, the boxes that areswitching frames and on up to
(06:59):
the boxes that are routingpackets, and you know, I guess
you've established yourself askind of an expert in the area of
application networking.
So when you say that to someonethat's just been in the data
center and in the weeds withphysical network gear and BGP
connecting ISPs and stuff likethat, and you say application
(07:21):
networking, they're going to saywhat?
What do you mean?
Can you take your best shot atdefining to the audience?
Marino (07:31):
what application networking is?
Absolutely, I actually want togo back a little bit before I
even answer that one question,because a lot of what I do today
is heavily influenced by a lotof what I used to do, especially
in the layer one to three era.
Now, when I first startedgetting into physical networking
(07:52):
and messing around withswitches and routers, I was
we're going way back to like2007, ish, 2008, ish.
And that's when, you know, Ireally started to realize, look,
you know, when you plugsomething in, it's not just
lights up, there's actually somelogic going on behind the
scenes.
And oh, by the way, there'sactually a configuration that
(08:13):
needs to be loaded in to providesome additional logic.
Like we, we have to take thisswitch and compartmentalize it.
So it's doing different thingsand you provide some isolation,
boundaries there.
And when you think about that,you're doing that in service for
security, for an application,to provide some QoS, to provide
(08:39):
some boundaries, limit thecrosstalk, and a lot of those
patterns become very prevalent,especially when you work in the
data center, when you work invarious campus environments.
But they become very repeatable, right?
And you begin to realize thatyou're solving part of the
problem.
Part of the problem is buildingthe road.
The other part is knowing whatis on that road, and I began to
realize that a lot of what wenton my roads were virtual
machines and physical machines,a combination of both.
(09:02):
And it all came to a head when Iwas sitting in a hospital with
a tech team and they were tryingto design a data center, a
little mini data center, and itall came down to routing of
routing was working.
We're talking about a vSphereenvironment where we're talking
(09:26):
about vSwitches, standardvSwitches, nothing fancy.
There's no special routing here, and in order to route you have
to go to something top of rack,you have to leave the actual
host, especially if you have aworkload that might be adjacent
to you in the same node.
And I began to wonder why don'twe have anything software-based
that can handle this routinglike?
(09:46):
Why don't we have anythingsoftware-based that can handle
this routing?
Because we do run routing insoftware anyways.
It's not like this is foreignto us in any way.
And I started to dig a littlebit more and I stumbled upon
this notion of software-definednetworking.
Software-defined networking wasjust all this networking in
software.
We're creating these virtualnetworks as we need to, on
demand, for whateverapplications that we need,
(10:08):
keyword applications, and Ibegan to realize that the
application sets people who arebuilding the applications needed
to provide guidance on howthese networks should be built.
We can't just build networks forthe sake of building it.
We have to be very intentionaland purposeful about them.
If I want to build a very smallyou know slash 31 network,
(10:30):
there's a reason I'm probablydoing so.
Obviously, I only want to builda point-to-point network and I
only want two points to be ableto communicate with each other.
And this might be, you know, anoccurrence in a WAN environment
, whereas in a containerizedenvironment with thousands of
microservices, the networking isgoing to look differently.
And at the same time, you can'tsit there and go in and plug in
(10:53):
a wire every single time forevery one of those containers
that come online and then, oh,by the way, disappear like five
minutes later because of ashort-lived action or function.
So that's what I meant by.
Let's focus on applications fora second, because they are
dictating how networks should beformed and with
software-defined networking,you're basically codifying how
(11:14):
you build your network.
I'm going to build my network,but based off of this set of
criteria, of how thisapplication is defined.
But we're still talking aboutlayer three, four.
We're not talking aboutanything you know immense or up
at layer seven.
But where that layer sevencomes in is wait.
I need additional logic.
(11:35):
This layer four stuff isn'tgoing to give me what I need.
And that's where the applicationbit truly comes in, because we
write applications with themindset that they're going to
talk to other applications.
How they talk to thoseapplications is through either
HTTP or gRPC as protocols, butunderneath all of that it's DNS,
and then there's a TCP IP layerright below that.
(11:59):
And so when I go out and saythat I'm an application network
architect of some sorts, I'm notjust thinking about layer one
to three or layer one to four.
I'm also thinking about theseservices that are making HTTP
calls using a variety ofattributes to decide hey, I'm
(12:19):
going to communicate with thisresource or that, but I'm not
going to communicate with thisthird resource, because I don't
have the right authentication inthe header of that HTTP request
I'm about to make.
But that's applicationnetworking and it's so much more
advanced than that and I'msorry it was such a long way to
get there.
Eyvonne (12:35):
But as a network engineer, I feel like you need
to understand layer one to seven, all the way through, to
understand applicationnetworking need to understand
layer one to seven, all the waythrough, to understand
application networking, callingout the evolution and going back
to talking about moving thelogic behind the thinking,
(12:56):
behind moving networking tosoftware.
That's an evolution that's beenhappening for 15, 20 years at
this point, with differentiterations of SD-WAN or SDN, if
you go back to the Nicira daysor even before then, and then
(13:16):
there was an iteration of thatwhich was SD-WAN more software
defining than WAN, and I knowthat you did a lot of work in
that space as well.
And so this is just the nextiteration of how we need to
think about how our networksserve applications, because, at
the end of the day, the networkis there to deliver applications
(13:39):
and we've created artificialbarriers in our thinking that we
need to evolve, remove change.
Marino (13:49):
Yes, You're absolutely correct.
I mean, software provides asubstantially significant more
amount of flexibility in the waywe can construct our networks.
Hardware, on the other hand, iseffectively powering that, and
we're only able to get to thislevel because our CPUs got so
(14:12):
much faster.
We're able to fit moretransistors on that little chip
and we can process a variety ofdifferent kinds of things in a
matter of like sub seconds.
And that becomes so much moreimportant, especially when we're
trying to consolidate moreworkloads into less devices.
You know, conserve power, evenconserve like this, this notion
(14:34):
of having to consolidate thingsinto a few sets of cables, that
was a huge thing when I wasdoing the data center stuff.
And it still is like we don't.
We don't want to have like 10different cables leaving a
server, we want two, and forredundancy, for high
availability, for active-activesetups, and it's going to be
like 100 gig per server or 200gig, if you're thinking that way
(14:57):
.
Right, and it's because of thatcombination of fast CPUs and so
much available bandwidth thatwe can write software any way we
want to and develop thenetworks we want to, but we also
can destroy them very quickly.
Destroying is probably the keypart too, and that ties heavily
into the whole notion ofmicroservices and cloud native
(15:19):
and Kubernetes, becauseKubernetes likes to and even
other orchestration environmentslike to, treat objects as very
ephemeral.
Like I should be able to tossthis away if I don't need it
anymore, and it's only becausewe don't want resources to be
changing constantly.
If we need to change something,we change it elsewhere in our
(15:40):
source of truth, and then thatgets honored and recognized in
the environment that we run.
And that's how we have to adaptnetworks as well.
So a lot of the principles offoundational networking has made
its way into cloud native.
Right, we think about containernetworking for a second.
If we're building containernetworks, it's network
(16:01):
namespaces that we have toconstruct, which is straight up
Linux networking, which isstraight up Linux networking,
which is straight up things weused to do and we still do today
, like there's nothing differenthere.
It's just the level at whatwe're doing in this macro or
micro.
William (16:16):
That's a good point and that was a great sort of
foundation of the container youknow, just kind of working your
way from just what networkengineers see as network
engineering all the way up tothe application side and one
thing that's interesting justkind of to tack.
On another question, I feellike the tools and practices for
(16:38):
managing this application-basednetworking is really different
than what has been the statusquo for your network
professionals in the past.
And I think this is almostwhere a lot of the uncertainty
of wanting to take that nextstep is, because all the network
engineers I know, yeah, bgp,yeah, dns, yeah, namespaces,
(17:01):
yeah all those things, yes, yes,yes.
But when you talk about Gitlike oh hey, you got to do this,
or you have to create a pullrequest or you know some of
those, I feel like those arelike things you you pretty much
have to if you're going to getinto this space.
There's some fundamental toolsthat you kind of have to know a
little bit and they're not thathard.
(17:22):
That's the thing.
I think there's some fear anduncertainty there, but they're
not.
It's very you know, if you'vegone in the CLI and you've been
doing Cisco and Arista andworking with all these
complicated platforms using Gitis like low-hanging fruit.
At that point it is not thathard.
Do you see that as well?
(17:42):
Or do you have any advice toprofessionals that are kind of
wanting to take that next stepto get into the cloud-native
space?
Absolutely.
Marino (17:49):
I don't think you have to jump right away into
Kubernetes or containers, butthere are entry points to
leverage cloud-native styleoperations with a lot of the
networking stuff that you dotoday.
So about a year ago I stumbledupon something called Container
Lab, which I think the both ofyou are probably very familiar
(18:10):
with right.
And it allows you to deployrouters and various versions of
them from various vendors withina Docker environment.
And you don't have to reallyknow Docker, you just have to
know how to work with ContainerLab, and there's plenty of
instructions on how to do so.
But the purpose behind that isyou're actually building desired
(18:31):
state for how you want yourtopologies and networks to look
like.
Now where would you want tostore that desired state?
It's configuration?
You want to store it somewhere.
You want to store it on yourlaptop in Notepad, like I used
to many, many years ago.
You want to store it somewhere.
One of the approaches manyyears ago was let's load it up
into some TFTP server so it canbe pulled in.
(18:53):
Other approaches use someversion control of some sorts.
The standard today would be touse Git.
Store this in Git, whether it'syou know you're using Bitbucket
or GitLab or GitHub.
You store it there, and now itbecomes a source of truth that
multiple individuals on yourteam and other teams can review
and interact with and evenprovide feedback across.
(19:14):
Now, to learn Git is not verydifficult in the sense of
understanding what you're tryingto do.
You're effectively trying tocreate a file and then make sure
that file gets uploaded intosomewhere right, but you're also
having this ability to trackwhat you've made modifications
to that file.
You can also track when someoneelse has made a modification to
(19:35):
that file which might conflictwith your modification.
And these become importantbecause it prevents overwrites,
it prevents clashing, it fostersmuch more collaboration.
So it's more of a collaborationtool and, in a lot of ways, a
tool to help you kind of buildgood practices around saving
your documentation in morecentralized repositories.
(19:57):
Now, once you've gotten pastlearning Git, I honestly feel
and I'm going through thisexercise too right Learning a
little bit of Python or someautomation style programming
language.
That really helps you simplifybasic tasks.
You know, the most rudimentarytask I can think of is like
having to log into a bunch ofswitches and then creating your
(20:19):
VLANs, and this was a pain to domany, many years ago.
You could do this very easilytoday with an API, a REST API,
because a lot of devices todayoffer that up, and then you can
use some of the tooling outthere.
Honestly, it escapes me nowbecause I haven't touched them
in a while, but you can useAnsible and Terraform to
provision a lot of yourinfrastructure and specifically
(20:42):
your networking infrastructure.
Napalm is another one thatallows you to actually help you
automate and deploy your networkinfrastructure as well.
But Container Lab is a sandboxenvironment where you can test
all of this out, and that'swhere I encourage network
engineers to get started,because I found my path into
cloud native through networking,through understanding how a CNI
(21:06):
works, how a container networkworks, and the one notable CNI
that provided a lot offamiliarity to me was the Cilium
CNI, the Cilium ContainerNetworking Interface.
Cilium was created by a CiliumContainer Networking Interface.
Cilium was created by a companycalled Isovalent who is now
part of Cisco, and what'sinteresting is a lot of the
(21:28):
technology and the backing ofthat technology is very network
engineering focused.
So a lot of network engineersare trying to understand
Kubernetes or microservices orhow to do this multi-cloud thing
.
That's a great place to start.
Spend up a cluster, spend up aKubernetes cluster and deploy
Cilium and learn how to workwith Cilium, and then it becomes
very familiar to you about howall of these different pieces
(21:50):
fit and how you get to tie backthat into the physical world,
which you can, by the way.
William (21:55):
That's a great.
So Cilium and I guess, forthose maybe uninitiated, you
know one of the or a few of thetechnologies that have really
been gaining traction in themarket.
You know, one of which is eBPF,or Extended Berkeley Packet
Filter, which has, you know,basically led to the creation of
amazing platforms like Selium,and I think I was listening to
(22:19):
one of your talks where youactually highlight, I think not
everything is like acloud-native architecture.
You have containers, you haveto connect workloads with VMs
and then in Kubernetes comingout of Kubernetes, you know, hey
, this is the real world.
So ebpf was kind of, you know,it was adopted by the linux
(22:40):
foundation, I think in like 2020or something, and, you know,
you know, thanks to isovalentmeta I think netflix was part of
that and a few other companiesand has evolved beyond being
just a packet filter to becomingreally like a general purpose
computing machine and inside thekernel, um and selium, you know
(23:02):
, which is ebpf based, is likeone of these awesome um
platforms.
Um, and something I see youtalking a lot about is selium
and ebpf.
What is your experience withgetting selium like the control
plane, like up and running andkind of setting up a brief
environment?
Marino (23:22):
It is so easy.
I mean you could be up inprobably about like five to 10
minutes.
Now, this is for a testenvironment.
If we're talking production,there's so much more to consider
.
Right and I bring this upbecause you're going to reach
multiple forks in the road Do Igo bare metal Kubernetes or do I
(23:42):
do Kubernetes on VMs and dothis as a service?
Do I use parts of Cilium?
Do I use all of Cilium?
And, quite honestly, there'salso the Cilium Enterprise
portion of it too.
Not all the features areavailable in open source as well
.
I don't know the full list offthe top of my head, but it's
just the consideration right Inthe lens of what am I trying to
(24:05):
do.
Do I need more of the BGPfunctionality or do I need to
lean on just a lot of the magicthat eBPF offers within Cilium
natively?
Now, there's so manyconsiderations here when it
comes to production too, becausethe reality is not everyone's
running Kubernetes everywhere.
It's not like my entireenvironment is Kubernetes.
(24:26):
You'll run into situationswhere I've got a little bit of
bare metal, I've got a littlebit of virtual machines, I'm
running native EC2 instances,I'm running ECS and maybe Cilium
isn't the right fit for all ofthat.
It could probably capture 70 to75% of that.
But how do you address thatremainder and that's a lot more
(24:47):
of the design considerations too, where you start to get a
little bit hacky?
Or maybe you begin to startusing some of the hooks, like
the Cilium virtual machineonboarding, or maybe you extend
the Cilium fabric into aphysical switch, which you can
do and this has been done withVXLAN previously, which I think
Cisco does it today.
(25:07):
Vmware's NSX used to do it witha bunch of switches way back
when.
I don't know if they still cantoday.
I don't know what's going onwith them, but in any case, hand
today I don't know what's goingon with them.
But in any case, the idea comesdown to the fact that to get
started with Cilium is easy.
To actually run it inproduction is a different
conversation altogether, becauseit requires so many moving
(25:30):
pieces and things likecertificate authentication, your
identity management, you haveto define what your applications
are going to look like and justa bunch of other considerations
as well.
Eyvonne (25:44):
That's an interesting observation.
You talk about the intersectionof certificates and identity,
and one of the things that I seeis folks are making transitions
from either on-premisesinfrastructure to cloud-based
infrastructure or even moremodern constructs.
It's that you don't have yourown separate authentication for
(26:08):
your networking constructs, butit's a larger holistic system.
You have to think aboutidentity, you have to think
about certificates and you haveto think about how all those
services work together.
Dns also is infinitely morecomplex than it was a decade ago
(26:30):
, and so all of those services.
Now the network is not a whollyindependent thing of all of
those services and constructs,so I I think it's really
interesting that you call thatout.
William (26:41):
And speaking of um, you know we've talked briefly about
service mesh, I guess, and oneanother talk that I thought you
know you said something reallyinteresting that I discussed
before we hit the record buttonbut you made this.
Hit the record button but youmade this parallel, I guess, of
(27:06):
service mesh is kind of like aVPN, which I think is an
absolutely great call out.
And I know that this is kind ofa Debbie Downer like in my
experience talking to app folks,because a lot of app folks that
I've talked to they're justlike VPN no, it's dead dead,
it's old technology.
But to kind of give credence tothis, I mean you could easily
make that case to say that, okay, well, these two do solve for
(27:26):
very different problems.
You know vpn is definitely inthe context of uh, connecting um
end users from the outside tolike private resources on the
inside, where service mesh ismore like connecting
microservices, containerizedworkloads or, you know, services
in the cloud.
But do you want to kind of liketalk through your thought
(27:48):
process behind?
Why even draw a parallelbetween these two?
Marino (27:53):
Absolutely so.
Let's talk about VPNs for asecond and let's talk about what
we were trying to achieve withthem.
Now, the first goal was toconnect two islands, two unique,
remote locations, together, sothat they can communicate.
You can have resources that cancommunicate with each other,
and the best way to do that wasby using branch devices that
(28:15):
supported technologies likeIPSec or some other similar
flavor of VPN technology.
But ideally, these two devicesat their respective locations
would communicate with eachother, negotiate a set of
protocols and then all trafficthat passes through these
devices effectively wereencrypted, so any third-party
(28:37):
individual that was sniffing inon those packets wouldn't be
able to replay them orunderstand what was going on or
even decrypt the payload.
Now that kind of technologycomes with many benefits, but
many, many drawbacks as well.
You're implementing a layer ofencryption, which means that's
additional latency on thatpayload and communication stream
(28:59):
, which also means that thedevices have to do both
encryption and decryption.
We solved that problem withexternal engines and offloads
and all of that cool stuff, butthat idea never left us.
That idea to be able to createa remote network or a virtual
remote or virtual privatenetwork of sorts, never really
(29:22):
left us, because we saw it comeup again with SD-WAN.
We saw it widely used withSD-WAN and we were trying to
achieve the same goals exceptfor like thousands of branches
for them to be able to connectto each other and communicate
across each other, if required,with the right policy in place.
Connect to each other andcommunicate across each other,
if required, with the rightpolicy in place.
And you know, centralizing yourmanagement plane while
distributing your data plane iseffectively what the goal was
(29:43):
with SD-WAN.
Now you know, while this is allhappening, you go off to the
side here and focus in on themicroservices world and
specifically what services aretrying to do to each other, and
the common challenges that cameup, probably about five years
ago, was how do we see what aservice is doing, how do we
(30:04):
provide some security around it?
And then how do we make surethat there's always connectivity
to that service?
Kind of similar to what a VPNdoes in a lot of ways, because
with those devices you're stillcapturing some telemetry, you're
still able to track connectionsand understand the source,
destination, flow and severalother bits as well.
(30:25):
That's what a service mesh isdoing.
That's exactly what a servicemesh is doing, except at a
smaller scale and it looksdifferent.
Now let me describe to you whata service mesh might look like.
So you have a control planethat's deployed somewhere, and
then you have data planes thatare also deployed alongside
workloads, alongside services.
(30:46):
Now these data planes arecommunicating with other data
planes using a protocol calledMTLS, but that MTLS protocol is
simply a tunneling mechanism.
William (30:57):
What is a VPN?
Marino (30:59):
A tunneling mechanism between two devices.
What did we do with clients?
We actually did the same thing.
We had VPN clients that wouldconnect into a head-end device
and then allow us to connectinto the network, which is
exactly what a service mesh isdoing.
Now there are some additionalcapabilities that service meshes
offer, like resiliencycapabilities, load balancing and
(31:22):
whatnot, and it's just takingin some additional networking
technologies and paradigms andjust bringing them into a more
consolidated platform within,say, Kubernetes.
Now, when you think about when aservice has to communicate with
another service in two distinctlocations, what happens?
There has to be a tunnel that'sformed.
The same situation happens withVPNs.
(31:45):
Whenever there is one client orone server that needs to call
out to another server, there isa connection that has to be
formed.
It's not like the tunnel isalways on.
The tunnel is just on demandand will come online for that
TCP session and then willdestroy itself afterwards, which
is exactly how MTLS operates.
So network engineers arelistening into this conversation
(32:09):
and wondering, like why thehell would I use a service mesh?
Well, it's where you're usingit.
You're not using it to solvethe branch location problem.
You're using it to solve andtreating Kubernetes as your
branch and you're allowingKubernetes clusters to
communicate across each other,with the services and
applications behind them, to dothe exact same thing, but over a
(32:30):
protected laneway or over asecured laneway, much like a VPN
is offering.
So the step up to understandhow a service mesh works I've
just explained it to you tolearn how to get it started and
get going with it.
It's not much more work either.
I think it's just a matter ofjumping into, understanding how
Kubernetes works andunderstanding how the workloads
(32:50):
are provisioned and deployed.
It gets a little bit morecomplex there too, but
fundamentally they're solvingsimilar problems just at
different layers.
Eyvonne (33:02):
That's an incredible comparison and one I think a lot
of people haven't made, butwhen I think about the history
of networking technology wetalked about this before we
started recording that there'salways been tunneling, whether
it's GRE, other types oftunneling that have happened in
(33:22):
networking, since its inception,really, and VPNs added a layer
of encryption over thattunneling.
And now it's how do we getthese two endpoints to see one
another more directly whenthere's something more complex
in between them, and servicemesh is just iterating on that
idea?
So that was an incredibledescription, but I know that
(33:52):
we're getting close on time.
Before we go, though, I wouldreally love to hear more about
your work in the CNCF.
I'd love to hear about whatyou're doing there and, yeah,
your involvement.
Marino (34:03):
So before I jump in, I'll provide some additional
context around something aroundservice mesh, and that ties into
the CNCF too.
So about a year ago or maybe ayear and a half ago, there was
this technology, open sourcetechnology called Istio it's
still there, it's doing a lot ofgreat things.
Open source technology calledIstio it's still there, it's
(34:25):
doing a lot of great things.
But they actually had a pivotpoint where they decided hey, we
want to have a sidecarlessapproach to service mesh.
In service mesh we deploysomething called sidecars, which
are just simply proxies, or youcould almost think, mini
routers, right beside services,so every service has a mini
router.
But that creates operationalcomplexity, adds more CPU and
memory overhead and just isintrusive in its own nature.
(34:49):
So you have to really planaccordingly, whereas a
sidecarless approach, which hasbeen offered before in different
formats, in different ways, issomething that Istio decided to
offer.
They called it Ambient Mesh,and I'm leading up to this
because you mentioned GRE.
Right, you brought up GRE, butwithin Ambient Mesh they have
(35:10):
these artifacts called Z-tunnels.
What Z-tunnels run iseffectively this protocol called
H-Bone.
What is H-Bone?
It is basically VXLAN.
I bring that up for networkengineers out there trying to
understand tunneling.
Well, that is a perfect exampleof how tunneling technologies
like VXLAN is used just underthe hood.
(35:31):
We just don't really see it Now.
How does that tie into the CNCFand the work that I've been
doing so for a long time?
I tried my best to really helpnetwork engineers understand
where they could leverage anduse and start to begin to see
the power of service mesh.
It's not a one size fits allbut it could solve a variety of
problems.
But also I needed to help themstep up a little bit more so
(35:54):
they can understand Kubernetes,primitives, kubernetes,
networking and whatnot,networking and whatnot.
So over the last I'd say threeyears I developed a network
foundations course that focusesin on Kubernetes, networking and
how to get from I'm a networkengineer to working inside of
networking, inside of containersand whatnot, along with a lot
(36:16):
of advocacy around justnetworking in general right, how
to use Cilium, how to use Istio, how to work with service mesh
technologies, how does that tieinto multi-cloud as well and a
lot of that was through gettingon stage and just sharing a lot
of my previous history andstories around how I used to do
networking things and how I dothem today, and it's been very
(36:40):
powerful because that generatesinteresting side conversations
around.
Hey, I'm trying to solve thisproblem, but I didn't realize
that we could solve this withTailscale.
Absolutely you can, because youdon't want to sit there
managing your control plane forVPN tunneling.
Just use this SaaS service,especially if this is all you
need and you begin to realizethat there are so many ways to
(37:02):
solve the same problem.
It goes back to what I saidmuch, much earlier, before we
started recording.
It's all about politics and thedecisions that are made at the
top level.
William (37:12):
Last question I had about service mesh was this is
something I get asked all thetime actually is when is it the
right time to look at servicemesh?
Is it a level of complexity orwhat you know?
Do you have any ideas on that?
Marino (37:27):
I have like, I have personal opinions, but I also
have just industry views.
So let me just stick to theindustry views right now,
because personal opinion youknow what Like there's so many
different ways this can go.
What I will say is that therehas been an overemphasis on
service mesh probably for agreater amount of time.
(37:48):
When Kubernetes launched, abouta year later, service mesh came
out and a lot of people thatwanted to adopt it saw so many
more challenges consuming it,managing the complexity of it,
managing upgrades, life cyclingand there's been a lot of
learnings throughout the way.
Autotrader is a perfect exampleof one of the first out there
using Service Mesh, but alsosome of the first to experience
(38:11):
a lot of the pains of it.
Now, five years later, serviceMesh is very mature, but we're
building things very differently.
We're not building on top ofKubernetes much like we thought
we would.
We thought we'd be doingeverything on top of Kubernetes
where service mesh would be thegreatest fit, and we're
beginning to realize that, whilethat is partially true, there
(38:37):
are a million more workloads outthere that don't require a mesh
, and I say this because whenyou think about gateways, api
gateways, for example we couldspend an entire conversation on
API gateways.
They fundamentally do the samething as service meshes do, but
gateways are also API.
Gateways are also like loadbalancers as well.
(38:57):
They are load balancers.
In fact.
The networking world has seenthis pattern so many times
before with application loadbalancing.
There's nothing different here.
It's just who actually usesthis technology, and it's more
so developers.
What I've noticed is developersjust want to build.
They don't want to sit thereand build for microservices,
(39:19):
they just want to build codethat works, and so we can't
force them into a microservicespattern.
But we can only provide themthe right guardrails, the right
pieces, the right environmentwhere those applications can run
but still have things like TLS.
We could still make sure weterminate connections
appropriately or load balancethem or circuit break them, but
(39:42):
we shouldn't have to depend onhaving Kubernetes.
We shouldn't have to forceourselves into a mesh.
Now, if folks are building ontop of Kubernetes, I think mesh
is a great technology for themto consume, because it's
probably the easiest way tohandle things like east-west
routing, implement things likeTLS and authentication as needed
and just scale appropriately.
(40:03):
But if you're outside of Meshor outside of Kubernetes, you'd
probably want to consider othertechnologies is my opinion, and
Mesh is probably like maybe 5%to 10% of what, or Kubernetes, I
should really say andcontainerization is like 5% to
10% of what's actually out there.
William (40:24):
There's so much other kinds of workloads, gotcha, and
sorry for derailing that, Ithink you know.
Back to Vaughn's question.
I'm curious as well about theyour work with the CNCF.
The CNCF is just doing greatthings right now.
Selium's part, yeah, selium'spart of the CNCF.
So yeah, and what is it like tobe an ambassador and what are
you working on these days?
Marino (40:49):
So I you know what.
There isn't a specific like setof tasks you're expected to do
as an ambassador, Like I justkeep doing the same things that
I'm doing anyways.
I'll still write tweets aboutyou know technologies, I'll
still host Twitter spaces, andif you want to hop on, let me
know.
I'm more than happy to host youboth, and I think that's like
for me, that's enough.
At the same time, you know I'llparticipate in the local
meetups that we have here andhelp organize them, and that's
(41:13):
how you give back to thecommunity, because I've been in
tech for like 20 plus years nowand I've learned a lot.
You know I've had a lot ofpeople that have mentored me,
given me so many differentdirections and pieces of advice
that have gotten me to the pointthat I'm able to talk to the
both of you, and that's massiveappreciation, by the way, for
that.
But it's also time to give backwhere you can, and this is one
(41:35):
of the best ways to do so, byproviding paths forward for
individuals that are trying tonavigate early on in their
career.
Where do I want to go?
Should I focus on Kubernetes?
Sure, but so many people are aswell.
Why not focus in on maybe alittle bit more of the
networking stuff that's outthere, specifically like proxies
(42:00):
, service meshes, cnis, maybesome of the automation behind
that or the GitOps behind thatas well, and that's generally
where I find myself.
I don't need to be the onethat's actively contributing to
code or to documentation,because we have plenty of people
that can do that, but we don'thave enough people out there
talking about the benefits ofthis technology or why it's
useful or how to use it, or howto get started even and break
down those barriers.
That's what I'm here to do orhow to get started even and
break down those barriers.
Eyvonne (42:23):
That's what I'm here to do.
So if there's somebody outthere who has interest in the
they've seen the CNCF, they'reinterested, they're curious,
they want to get more involvedwhat would you recommend they do
?
Marino (42:35):
Now, if it's within your affordability range, I always
recommend a KubeCon.
Kubecons are probably the mostimmersive experiences to really
just get your career and justyour mindset jumpstarted onto
what's going on in the CNCF.
It's kind of what did it for me.
Actually, I went to my veryfirst KubeCon in 2019 in San
(42:57):
Diego.
It was phenomenal.
Sorry for the background noise,it was phenomenal.
San Diego, it was phenomenal.
Sorry for the background noise,it was phenomenal.
And what I began to realize ishow immersive the community is,
how diverse the community is andhow engaging they are.
Kubecon has come a long waysince then.
It's a lot more commercializedand it's just more oriented
(43:17):
towards vendors, obviouslybecause of how big it is, but
there's a lot of the communityelement there.
So, if you can go to a KubeCon,if you cannot, try to go to a
local CNCF event like a KCDs oreven a KubeDays, and if that's
not within your availability,try to go to maybe even a CNCF
meetup.
There's probably a localchapter very close by and most
(43:41):
meetups happen quarterly or evenmonthly.
Try to go to one of those soyou can get a taste of what the
CNCF is like, and usually thosesessions or those meetups give
you the opportunity to see howother speakers talk about their
technology even gives youinsight as to what's going on as
a whole in the program, likefrom updates to Kubernetes to
(44:02):
how to be a CNCF ambassador, andusually you have ambassadors
running those meetups as well.
William (44:07):
Awesome, I know I want to be mindful of your time
because I think you have to jumpnow, but do you want to tell
the audience where to find you?
And I think we need to do apart two because there's so much
more we could dig into.
So maybe later on, maybe nextyear or sometime yeah, I'd be
happy to.
Marino (44:22):
But if you want to find me, I am absolutely on Twitter.
My handle is very unique.
In some ways it's virtualizedsix, but I use the number six to
kind of complete that.
Maybe Yvonne or William canshare that in the show notes
later on.
But I'm also on LinkedIn.
So if you want to connect withme there and you don't want to
be on Twitter, that's totallyfine too.
(44:43):
That's where I tend to hangaround most either LinkedIn or
Twitter.
I do occasionally make YouTubevideos and live streams, but
honestly, I don't have the timeand I just prefer to invest my
time gaming or doing otherthings at times.
But anyways, it's been apleasure being on the show.
Thank you so much.
Thank you both.
I really do appreciate it andhope to be back again.
Now these data planes are communicating with other
data planes using a protocolcalled MTLS, but that MTLS
protocol is simply a tunnelingmechanism.
William (00:09):
What is a VPN?
Marino (00:11):
A tunneling mechanism.
William (00:24):
Coming to you from the Cloud Gambit studio.
This is your host, William, andwith me, my co-host, the
world-famous, highlydistinguished cloud philosopher,
Yvonne Sharp.
How are you doing today?
Eyvonne (00:39):
Hello, I was trying to avoid the eye roll but I
couldn't quite manage it.
But thank you, William, forthat introduction.
William (00:48):
Awesome.
And also with us is Marino,with Jay.
How are you doing today, marino?
Marino (00:54):
I'm doing very well, it's Friday and that's the best
part.
It's like almost the weekendand, as I was talking about
earlier, friday is generally thebusiest day.
How are you both doing?
William (01:04):
All good here, busy with kids this morning, getting
them ready for school and allthat noise.
But other than that, yeah.
Eyvonne (01:11):
In theory I have a light meeting day.
I have high aspirations ofgetting some stuff done, so
we'll see how that goes.
William (01:18):
Good luck with that.
Marino (01:20):
Yeah.
William (01:21):
Yeah, so you come to us from the beautiful, usually
much colder than Kentucky,Ontario, Canada correct.
Marino (01:31):
That is correct.
I'm just outside of a verylittle city called Toronto.
I live in Whitby, but Torontois probably the most familiar
city I can use and people wouldimmediately recognize it.
And I've lived here all my life.
You know, I've kind of grown upin the area and seen how it's
transformed and morphed into.
(01:52):
You know what it is today.
It's a bit of a tech hub.
There's a lot of thrivingopportunity here and, just you
know, a very diverse culture outthis way.
So you know, I love being outhere, but I also love traveling
too.
It's fun to get around and seewhat other people are doing and
what other cities are up to.
William (02:11):
Awesome, yeah, and you're not a hockey fan, are you
?
Marino (02:16):
I'm actually not a huge sports fan.
You know what?
I will go watch basketballgames.
If my sister's like, hey, Isome tickets, let's go, let's go
hang out.
I'm like, yeah, sure, whateverthree hours, let's kill in the
stadium and hang out for a bit.
But I can't.
I don't have the patience orthe um, the focus level to pay
(02:36):
attention to like baseball orhockey or any other sport,
because it's just, I don't know,just me I hear you had to ask.
William (02:43):
I'm a hockey fan and every time I I'm a hockey fan
and every time I can findanother hockey fan is a special
moment.
There's not very many out therethat I talk to day in and day
out, so I'm always asking.
But yeah, so kind of back towhat I was saying.
Before we hit the record button, I had two separate individuals
reach out to me, like probablywithin a month of each other,
saying hey, you need to havemarino on the show.
(03:11):
You know you need to reach out.
So I I love suggestions forawesome guests you know to have
on in the future.
So if anyone in the audiencehas any ideas for future
episodes, avon and I are allears always.
Um, yeah, so do you want togive us a brief overview, just
kind of, of your background?
Marino (03:26):
Yeah, absolutely so.
Currently, as I reside inCanada, I work as a remote
solutions architect for an APIgateway company called Kong, and
a lot of my career whether inthe data center, in the cloud
space or Kubernetes a lot of ithad a lot to do with networking
and that kind of brought me tothis place, brought me to what
(03:49):
I'm doing today.
In a lot of ways, though,through my journey, I focused on
certifications, took a varietyof courses, changed job roles
quite a lot to try differentthings and see how different
roles function and how theyinteract with either the
community or within theorganization or across
(04:10):
organizations in across-functional manner.
So I've learned a lot.
But I've also sat there andrealized there's still so much
to learn, tech-wise,environment-wise, to understand
how organizations run.
And you know, I come down to therealization that a lot of the
decision-making that happens,especially in massive
(04:30):
organizations, tends to bepolitical decisions at times.
And I sat there kind of goingback and forth with this a few
days ago because I was askingone of my end users about some
decision that they made a whileback why did you decide that
you'd use this workloadenvironment along with this one,
when you could just accomplisheverything with one, and there
(04:55):
was a lot of dancing around theanswer and I came to the
conclusion that a lot of thiswasn't their own decision.
It was just coming from the top, from the top down, because of
some agreement that was made.
So to get to that point ofrealization, obviously I've had
to work through different partsof my career work in support,
work in pre-sales work, inarchitecture, work in
(05:16):
implementation and even thedeveloper relations side of
things and it just opens youreyes to what goes on in the
industry and how organizationsmake the decisions that they do.
Eyvonne (05:28):
I had a.
I had a.
I made a pivotal kind ofdiscovery at one point in my
career and I naively believedfor a long time that that the
right, the best technicalsolution wins.
And the goal was to be right,to find the right answer, to
find the best solution to meetall the requirements.
And that was what it was to besuccessful.
(05:53):
And I had this moment ofclarity where I'm like, wait a
minute, you can do all of thosethings and still not get
decision makers on board, andthat there's a human component
to our work.
And for me that's really when Istarted reading on
(06:13):
organizational psychology andKahneman and Tversky and trying
to understand more of the humanelement of decision making,
Because at the end of the day,people are implementing
technology and making technologydecisions and that really
shifted the trajectory of theday.
People are implementingtechnology and making technology
decisions and that reallyshifted the trajectory of my
career.
So it's interesting to hear youbring that up this early in the
(06:34):
conversation about yourtrajectory as well have.
William (06:37):
You've probably made a life living, you know, somewhere
in between the physical layer,like layer one of the osi model,
and like layer three.
You know the network layer ofthe osi model.
So you know basically from thatphysical connectivity of bits
up to the, the boxes that areswitching frames and on up to
(06:59):
the boxes that are routingpackets, and you know, I guess
you've established yourself askind of an expert in the area of
application networking.
So when you say that to someonethat's just been in the data
center and in the weeds withphysical network gear and BGP
connecting ISPs and stuff likethat, and you say application
(07:21):
networking, they're going to saywhat?
What do you mean?
Can you take your best shot atdefining to the audience?
Marino (07:31):
what application networking is?
Absolutely, I actually want togo back a little bit before I
even answer that one question,because a lot of what I do today
is heavily influenced by a lotof what I used to do, especially
in the layer one to three era.
Now, when I first startedgetting into physical networking
(07:52):
and messing around withswitches and routers, I was
we're going way back to like2007, ish, 2008, ish.
And that's when, you know, Ireally started to realize, look,
you know, when you plugsomething in, it's not just
lights up, there's actually somelogic going on behind the
scenes.
And oh, by the way, there'sactually a configuration that
(08:13):
needs to be loaded in to providesome additional logic.
Like we, we have to take thisswitch and compartmentalize it.
So it's doing different thingsand you provide some isolation,
boundaries there.
And when you think about that,you're doing that in service for
security, for an application,to provide some QoS, to provide
(08:39):
some boundaries, limit thecrosstalk, and a lot of those
patterns become very prevalent,especially when you work in the
data center, when you work invarious campus environments.
But they become very repeatable, right?
And you begin to realize thatyou're solving part of the
problem.
Part of the problem is buildingthe road.
The other part is knowing whatis on that road, and I began to
realize that a lot of what wenton my roads were virtual
machines and physical machines,a combination of both.
(09:02):
And it all came to a head when Iwas sitting in a hospital with
a tech team and they were tryingto design a data center, a
little mini data center, and itall came down to routing of
routing was working.
We're talking about a vSphereenvironment where we're talking
(09:26):
about vSwitches, standardvSwitches, nothing fancy.
There's no special routing here, and in order to route you have
to go to something top of rack,you have to leave the actual
host, especially if you have aworkload that might be adjacent
to you in the same node.
And I began to wonder why don'twe have anything software-based
that can handle this routinglike?
(09:46):
Why don't we have anythingsoftware-based that can handle
this routing?
Because we do run routing insoftware anyways.
It's not like this is foreignto us in any way.
And I started to dig a littlebit more and I stumbled upon
this notion of software-definednetworking.
Software-defined networking wasjust all this networking in
software.
We're creating these virtualnetworks as we need to, on
demand, for whateverapplications that we need,
(10:08):
keyword applications, and Ibegan to realize that the
application sets people who arebuilding the applications needed
to provide guidance on howthese networks should be built.
We can't just build networks forthe sake of building it.
We have to be very intentionaland purposeful about them.
If I want to build a very smallyou know slash 31 network,
(10:30):
there's a reason I'm probablydoing so.
Obviously, I only want to builda point-to-point network and I
only want two points to be ableto communicate with each other.
And this might be, you know, anoccurrence in a WAN environment
, whereas in a containerizedenvironment with thousands of
microservices, the networking isgoing to look differently.
And at the same time, you can'tsit there and go in and plug in
(10:53):
a wire every single time forevery one of those containers
that come online and then, oh,by the way, disappear like five
minutes later because of ashort-lived action or function.
So that's what I meant by.
Let's focus on applications fora second, because they are
dictating how networks should beformed and with
software-defined networking,you're basically codifying how
(11:14):
you build your network.
I'm going to build my network,but based off of this set of
criteria, of how thisapplication is defined.
But we're still talking aboutlayer three, four.
We're not talking aboutanything you know immense or up
at layer seven.
But where that layer sevencomes in is wait.
I need additional logic.
(11:35):
This layer four stuff isn'tgoing to give me what I need.
And that's where the applicationbit truly comes in, because we
write applications with themindset that they're going to
talk to other applications.
How they talk to thoseapplications is through either
HTTP or gRPC as protocols, butunderneath all of that it's DNS,
and then there's a TCP IP layerright below that.
(11:59):
And so when I go out and saythat I'm an application network
architect of some sorts, I'm notjust thinking about layer one
to three or layer one to four.
I'm also thinking about theseservices that are making HTTP
calls using a variety ofattributes to decide hey, I'm
(12:19):
going to communicate with thisresource or that, but I'm not
going to communicate with thisthird resource, because I don't
have the right authentication inthe header of that HTTP request
I'm about to make.
But that's applicationnetworking and it's so much more
advanced than that and I'msorry it was such a long way to
get there.
Eyvonne (12:35):
But as a network engineer, I feel like you need
to understand layer one to seven, all the way through, to
understand applicationnetworking need to understand
layer one to seven, all the waythrough, to understand
application networking, callingout the evolution and going back
to talking about moving thelogic behind the thinking,
(12:56):
behind moving networking tosoftware.
That's an evolution that's beenhappening for 15, 20 years at
this point, with differentiterations of SD-WAN or SDN, if
you go back to the Nicira daysor even before then, and then
(13:16):
there was an iteration of thatwhich was SD-WAN more software
defining than WAN, and I knowthat you did a lot of work in
that space as well.
And so this is just the nextiteration of how we need to
think about how our networksserve applications, because, at
the end of the day, the networkis there to deliver applications
(13:39):
and we've created artificialbarriers in our thinking that we
need to evolve, remove change.
Marino (13:49):
Yes, You're absolutely correct.
I mean, software provides asubstantially significant more
amount of flexibility in the waywe can construct our networks.
Hardware, on the other hand, iseffectively powering that, and
we're only able to get to thislevel because our CPUs got so
(14:12):
much faster.
We're able to fit moretransistors on that little chip
and we can process a variety ofdifferent kinds of things in a
matter of like sub seconds.
And that becomes so much moreimportant, especially when we're
trying to consolidate moreworkloads into less devices.
You know, conserve power, evenconserve like this, this notion
(14:34):
of having to consolidate thingsinto a few sets of cables, that
was a huge thing when I wasdoing the data center stuff.
And it still is like we don't.
We don't want to have like 10different cables leaving a
server, we want two, and forredundancy, for high
availability, for active-activesetups, and it's going to be
like 100 gig per server or 200gig, if you're thinking that way
(14:57):
.
Right, and it's because of thatcombination of fast CPUs and so
much available bandwidth thatwe can write software any way we
want to and develop thenetworks we want to, but we also
can destroy them very quickly.
Destroying is probably the keypart too, and that ties heavily
into the whole notion ofmicroservices and cloud native
(15:19):
and Kubernetes, becauseKubernetes likes to and even
other orchestration environmentslike to, treat objects as very
ephemeral.
Like I should be able to tossthis away if I don't need it
anymore, and it's only becausewe don't want resources to be
changing constantly.
If we need to change something,we change it elsewhere in our
(15:40):
source of truth, and then thatgets honored and recognized in
the environment that we run.
And that's how we have to adaptnetworks as well.
So a lot of the principles offoundational networking has made
its way into cloud native.
Right, we think about containernetworking for a second.
If we're building containernetworks, it's network
(16:01):
namespaces that we have toconstruct, which is straight up
Linux networking, which isstraight up Linux networking,
which is straight up things weused to do and we still do today
, like there's nothing differenthere.
It's just the level at whatwe're doing in this macro or
micro.
William (16:16):
That's a good point and that was a great sort of
foundation of the container youknow, just kind of working your
way from just what networkengineers see as network
engineering all the way up tothe application side and one
thing that's interesting justkind of to tack.
On another question, I feellike the tools and practices for
(16:38):
managing this application-basednetworking is really different
than what has been the statusquo for your network
professionals in the past.
And I think this is almostwhere a lot of the uncertainty
of wanting to take that nextstep is, because all the network
engineers I know, yeah, bgp,yeah, dns, yeah, namespaces,
(17:01):
yeah all those things, yes, yes,yes.
But when you talk about Gitlike oh hey, you got to do this,
or you have to create a pullrequest or you know some of
those, I feel like those arelike things you you pretty much
have to if you're going to getinto this space.
There's some fundamental toolsthat you kind of have to know a
little bit and they're not thathard.
(17:22):
That's the thing.
I think there's some fear anduncertainty there, but they're
not.
It's very you know, if you'vegone in the CLI and you've been
doing Cisco and Arista andworking with all these
complicated platforms using Gitis like low-hanging fruit.
At that point it is not thathard.
Do you see that as well?
(17:42):
Or do you have any advice toprofessionals that are kind of
wanting to take that next stepto get into the cloud-native
space?
Absolutely.
Marino (17:49):
I don't think you have to jump right away into
Kubernetes or containers, butthere are entry points to
leverage cloud-native styleoperations with a lot of the
networking stuff that you dotoday.
So about a year ago I stumbledupon something called Container
Lab, which I think the both ofyou are probably very familiar
(18:10):
with right.
And it allows you to deployrouters and various versions of
them from various vendors withina Docker environment.
And you don't have to reallyknow Docker, you just have to
know how to work with ContainerLab, and there's plenty of
instructions on how to do so.
But the purpose behind that isyou're actually building desired
(18:31):
state for how you want yourtopologies and networks to look
like.
Now where would you want tostore that desired state?
It's configuration?
You want to store it somewhere.
You want to store it on yourlaptop in Notepad, like I used
to many, many years ago.
You want to store it somewhere.
One of the approaches manyyears ago was let's load it up
into some TFTP server so it canbe pulled in.
(18:53):
Other approaches use someversion control of some sorts.
The standard today would be touse Git.
Store this in Git, whether it'syou know you're using Bitbucket
or GitLab or GitHub.
You store it there, and now itbecomes a source of truth that
multiple individuals on yourteam and other teams can review
and interact with and evenprovide feedback across.
(19:14):
Now, to learn Git is not verydifficult in the sense of
understanding what you're tryingto do.
You're effectively trying tocreate a file and then make sure
that file gets uploaded intosomewhere right, but you're also
having this ability to trackwhat you've made modifications
to that file.
You can also track when someoneelse has made a modification to
(19:35):
that file which might conflictwith your modification.
And these become importantbecause it prevents overwrites,
it prevents clashing, it fostersmuch more collaboration.
So it's more of a collaborationtool and, in a lot of ways, a
tool to help you kind of buildgood practices around saving
your documentation in morecentralized repositories.
(19:57):
Now, once you've gotten pastlearning Git, I honestly feel
and I'm going through thisexercise too right Learning a
little bit of Python or someautomation style programming
language.
That really helps you simplifybasic tasks.
You know, the most rudimentarytask I can think of is like
having to log into a bunch ofswitches and then creating your
(20:19):
VLANs, and this was a pain to domany, many years ago.
You could do this very easilytoday with an API, a REST API,
because a lot of devices todayoffer that up, and then you can
use some of the tooling outthere.
Honestly, it escapes me nowbecause I haven't touched them
in a while, but you can useAnsible and Terraform to
provision a lot of yourinfrastructure and specifically
(20:42):
your networking infrastructure.
Napalm is another one thatallows you to actually help you
automate and deploy your networkinfrastructure as well.
But Container Lab is a sandboxenvironment where you can test
all of this out, and that'swhere I encourage network
engineers to get started,because I found my path into
cloud native through networking,through understanding how a CNI
(21:06):
works, how a container networkworks, and the one notable CNI
that provided a lot offamiliarity to me was the Cilium
CNI, the Cilium ContainerNetworking Interface.
Cilium was created by a CiliumContainer Networking Interface.
Cilium was created by a companycalled Isovalent who is now
part of Cisco, and what'sinteresting is a lot of the
(21:28):
technology and the backing ofthat technology is very network
engineering focused.
So a lot of network engineersare trying to understand
Kubernetes or microservices orhow to do this multi-cloud thing
.
That's a great place to start.
Spend up a cluster, spend up aKubernetes cluster and deploy
Cilium and learn how to workwith Cilium, and then it becomes
very familiar to you about howall of these different pieces
(21:50):
fit and how you get to tie backthat into the physical world,
which you can, by the way.
William (21:55):
That's a great.
So Cilium and I guess, forthose maybe uninitiated, you
know one of the or a few of thetechnologies that have really
been gaining traction in themarket.
You know, one of which is eBPF,or Extended Berkeley Packet
Filter, which has, you know,basically led to the creation of
amazing platforms like Selium,and I think I was listening to
(22:19):
one of your talks where youactually highlight, I think not
everything is like acloud-native architecture.
You have containers, you haveto connect workloads with VMs
and then in Kubernetes comingout of Kubernetes, you know, hey
, this is the real world.
So ebpf was kind of, you know,it was adopted by the linux
(22:40):
foundation, I think in like 2020or something, and, you know,
you know, thanks to isovalentmeta I think netflix was part of
that and a few other companiesand has evolved beyond being
just a packet filter to becomingreally like a general purpose
computing machine and inside thekernel, um and selium, you know
(23:02):
, which is ebpf based, is likeone of these awesome um
platforms.
Um, and something I see youtalking a lot about is selium
and ebpf.
What is your experience withgetting selium like the control
plane, like up and running andkind of setting up a brief
environment?
Marino (23:22):
It is so easy.
I mean you could be up inprobably about like five to 10
minutes.
Now, this is for a testenvironment.
If we're talking production,there's so much more to consider
.
Right and I bring this upbecause you're going to reach
multiple forks in the road Do Igo bare metal Kubernetes or do I
(23:42):
do Kubernetes on VMs and dothis as a service?
Do I use parts of Cilium?
Do I use all of Cilium?
And, quite honestly, there'salso the Cilium Enterprise
portion of it too.
Not all the features areavailable in open source as well
.
I don't know the full list offthe top of my head, but it's
just the consideration right Inthe lens of what am I trying to
(24:05):
do.
Do I need more of the BGPfunctionality or do I need to
lean on just a lot of the magicthat eBPF offers within Cilium
natively?
Now, there's so manyconsiderations here when it
comes to production too, becausethe reality is not everyone's
running Kubernetes everywhere.
It's not like my entireenvironment is Kubernetes.
(24:26):
You'll run into situationswhere I've got a little bit of
bare metal, I've got a littlebit of virtual machines, I'm
running native EC2 instances,I'm running ECS and maybe Cilium
isn't the right fit for all ofthat.
It could probably capture 70 to75% of that.
But how do you address thatremainder and that's a lot more
(24:47):
of the design considerations too, where you start to get a
little bit hacky?
Or maybe you begin to startusing some of the hooks, like
the Cilium virtual machineonboarding, or maybe you extend
the Cilium fabric into aphysical switch, which you can
do and this has been done withVXLAN previously, which I think
Cisco does it today.
(25:07):
Vmware's NSX used to do it witha bunch of switches way back
when.
I don't know if they still cantoday.
I don't know what's going onwith them, but in any case, hand
today I don't know what's goingon with them.
But in any case, the idea comesdown to the fact that to get
started with Cilium is easy.
To actually run it inproduction is a different
conversation altogether, becauseit requires so many moving
(25:30):
pieces and things likecertificate authentication, your
identity management, you haveto define what your applications
are going to look like and justa bunch of other considerations
as well.
Eyvonne (25:44):
That's an interesting observation.
You talk about the intersectionof certificates and identity,
and one of the things that I seeis folks are making transitions
from either on-premisesinfrastructure to cloud-based
infrastructure or even moremodern constructs.
It's that you don't have yourown separate authentication for
(26:08):
your networking constructs, butit's a larger holistic system.
You have to think aboutidentity, you have to think
about certificates and you haveto think about how all those
services work together.
Dns also is infinitely morecomplex than it was a decade ago
(26:30):
, and so all of those services.
Now the network is not a whollyindependent thing of all of
those services and constructs,so I I think it's really
interesting that you call thatout.
William (26:41):
And speaking of um, you know we've talked briefly about
service mesh, I guess, and oneanother talk that I thought you
know you said something reallyinteresting that I discussed
before we hit the record buttonbut you made this.
Hit the record button but youmade this parallel, I guess, of
(27:06):
service mesh is kind of like aVPN, which I think is an
absolutely great call out.
And I know that this is kind ofa Debbie Downer like in my
experience talking to app folks,because a lot of app folks that
I've talked to they're justlike VPN no, it's dead dead,
it's old technology.
But to kind of give credence tothis, I mean you could easily
make that case to say that, okay, well, these two do solve for
(27:26):
very different problems.
You know vpn is definitely inthe context of uh, connecting um
end users from the outside tolike private resources on the
inside, where service mesh ismore like connecting
microservices, containerizedworkloads or, you know, services
in the cloud.
But do you want to kind of liketalk through your thought
(27:48):
process behind?
Why even draw a parallelbetween these two?
Marino (27:53):
Absolutely so.
Let's talk about VPNs for asecond and let's talk about what
we were trying to achieve withthem.
Now, the first goal was toconnect two islands, two unique,
remote locations, together, sothat they can communicate.
You can have resources that cancommunicate with each other,
and the best way to do that wasby using branch devices that
(28:15):
supported technologies likeIPSec or some other similar
flavor of VPN technology.
But ideally, these two devicesat their respective locations
would communicate with eachother, negotiate a set of
protocols and then all trafficthat passes through these
devices effectively wereencrypted, so any third-party
(28:37):
individual that was sniffing inon those packets wouldn't be
able to replay them orunderstand what was going on or
even decrypt the payload.
Now that kind of technologycomes with many benefits, but
many, many drawbacks as well.
You're implementing a layer ofencryption, which means that's
additional latency on thatpayload and communication stream
(28:59):
, which also means that thedevices have to do both
encryption and decryption.
We solved that problem withexternal engines and offloads
and all of that cool stuff, butthat idea never left us.
That idea to be able to createa remote network or a virtual
remote or virtual privatenetwork of sorts, never really
(29:22):
left us, because we saw it comeup again with SD-WAN.
We saw it widely used withSD-WAN and we were trying to
achieve the same goals exceptfor like thousands of branches
for them to be able to connectto each other and communicate
across each other, if required,with the right policy in place.
Connect to each other andcommunicate across each other,
if required, with the rightpolicy in place.
And you know, centralizing yourmanagement plane while
distributing your data plane iseffectively what the goal was
(29:43):
with SD-WAN.
Now you know, while this is allhappening, you go off to the
side here and focus in on themicroservices world and
specifically what services aretrying to do to each other, and
the common challenges that cameup, probably about five years
ago, was how do we see what aservice is doing, how do we
(30:04):
provide some security around it?
And then how do we make surethat there's always connectivity
to that service?
Kind of similar to what a VPNdoes in a lot of ways, because
with those devices you're stillcapturing some telemetry, you're
still able to track connectionsand understand the source,
destination, flow and severalother bits as well.
(30:25):
That's what a service mesh isdoing.
That's exactly what a servicemesh is doing, except at a
smaller scale and it looksdifferent.
Now let me describe to you whata service mesh might look like.
So you have a control planethat's deployed somewhere, and
then you have data planes thatare also deployed alongside
workloads, alongside services.
(30:46):
Now these data planes arecommunicating with other data
planes using a protocol calledMTLS, but that MTLS protocol is
simply a tunneling mechanism.
William (30:57):
What is a VPN?
Marino (30:59):
A tunneling mechanism between two devices.
What did we do with clients?
We actually did the same thing.
We had VPN clients that wouldconnect into a head-end device
and then allow us to connectinto the network, which is
exactly what a service mesh isdoing.
Now there are some additionalcapabilities that service meshes
offer, like resiliencycapabilities, load balancing and
(31:22):
whatnot, and it's just takingin some additional networking
technologies and paradigms andjust bringing them into a more
consolidated platform within,say, Kubernetes.
Now, when you think about when aservice has to communicate with
another service in two distinctlocations, what happens?
There has to be a tunnel that'sformed.
The same situation happens withVPNs.
(31:45):
Whenever there is one client orone server that needs to call
out to another server, there isa connection that has to be
formed.
It's not like the tunnel isalways on.
The tunnel is just on demandand will come online for that
TCP session and then willdestroy itself afterwards, which
is exactly how MTLS operates.
So network engineers arelistening into this conversation
(32:09):
and wondering, like why thehell would I use a service mesh?
Well, it's where you're usingit.
You're not using it to solvethe branch location problem.
You're using it to solve andtreating Kubernetes as your
branch and you're allowingKubernetes clusters to
communicate across each other,with the services and
applications behind them, to dothe exact same thing, but over a
(32:30):
protected laneway or over asecured laneway, much like a VPN
is offering.
So the step up to understandhow a service mesh works I've
just explained it to you tolearn how to get it started and
get going with it.
It's not much more work either.
I think it's just a matter ofjumping into, understanding how
Kubernetes works andunderstanding how the workloads
(32:50):
are provisioned and deployed.
It gets a little bit morecomplex there too, but
fundamentally they're solvingsimilar problems just at
different layers.
Eyvonne (33:02):
That's an incredible comparison and one I think a lot
of people haven't made, butwhen I think about the history
of networking technology wetalked about this before we
started recording that there'salways been tunneling, whether
it's GRE, other types oftunneling that have happened in
(33:22):
networking, since its inception,really, and VPNs added a layer
of encryption over thattunneling.
And now it's how do we getthese two endpoints to see one
another more directly whenthere's something more complex
in between them, and servicemesh is just iterating on that
idea?
So that was an incredibledescription, but I know that
(33:52):
we're getting close on time.
Before we go, though, I wouldreally love to hear more about
your work in the CNCF.
I'd love to hear about whatyou're doing there and, yeah,
your involvement.
Marino (34:03):
So before I jump in, I'll provide some additional
context around something aroundservice mesh, and that ties into
the CNCF too.
So about a year ago or maybe ayear and a half ago, there was
this technology, open sourcetechnology called Istio it's
still there, it's doing a lot ofgreat things.
Open source technology calledIstio it's still there, it's
(34:25):
doing a lot of great things.
But they actually had a pivotpoint where they decided hey, we
want to have a sidecarlessapproach to service mesh.
In service mesh we deploysomething called sidecars, which
are just simply proxies, or youcould almost think, mini
routers, right beside services,so every service has a mini
router.
But that creates operationalcomplexity, adds more CPU and
memory overhead and just isintrusive in its own nature.
(34:49):
So you have to really planaccordingly, whereas a
sidecarless approach, which hasbeen offered before in different
formats, in different ways, issomething that Istio decided to
offer.
They called it Ambient Mesh,and I'm leading up to this
because you mentioned GRE.
Right, you brought up GRE, butwithin Ambient Mesh they have
(35:10):
these artifacts called Z-tunnels.
What Z-tunnels run iseffectively this protocol called
H-Bone.
What is H-Bone?
It is basically VXLAN.
I bring that up for networkengineers out there trying to
understand tunneling.
Well, that is a perfect exampleof how tunneling technologies
like VXLAN is used just underthe hood.
(35:31):
We just don't really see it Now.
How does that tie into the CNCFand the work that I've been
doing so for a long time?
I tried my best to really helpnetwork engineers understand
where they could leverage anduse and start to begin to see
the power of service mesh.
It's not a one size fits allbut it could solve a variety of
problems.
But also I needed to help themstep up a little bit more so
(35:54):
they can understand Kubernetes,primitives, kubernetes,
networking and whatnot,networking and whatnot.
So over the last I'd say threeyears I developed a network
foundations course that focusesin on Kubernetes, networking and
how to get from I'm a networkengineer to working inside of
networking, inside of containersand whatnot, along with a lot
(36:16):
of advocacy around justnetworking in general right, how
to use Cilium, how to use Istio, how to work with service mesh
technologies, how does that tieinto multi-cloud as well and a
lot of that was through gettingon stage and just sharing a lot
of my previous history andstories around how I used to do
networking things and how I dothem today, and it's been very
(36:40):
powerful because that generatesinteresting side conversations
around.
Hey, I'm trying to solve thisproblem, but I didn't realize
that we could solve this withTailscale.
Absolutely you can, because youdon't want to sit there
managing your control plane forVPN tunneling.
Just use this SaaS service,especially if this is all you
need and you begin to realizethat there are so many ways to
(37:02):
solve the same problem.
It goes back to what I saidmuch, much earlier, before we
started recording.
It's all about politics and thedecisions that are made at the
top level.
William (37:12):
Last question I had about service mesh was this is
something I get asked all thetime actually is when is it the
right time to look at servicemesh?
Is it a level of complexity orwhat you know?
Do you have any ideas on that?
Marino (37:27):
I have like, I have personal opinions, but I also
have just industry views.
So let me just stick to theindustry views right now,
because personal opinion youknow what Like there's so many
different ways this can go.
What I will say is that therehas been an overemphasis on
service mesh probably for agreater amount of time.
(37:48):
When Kubernetes launched, abouta year later, service mesh came
out and a lot of people thatwanted to adopt it saw so many
more challenges consuming it,managing the complexity of it,
managing upgrades, life cyclingand there's been a lot of
learnings throughout the way.
Autotrader is a perfect exampleof one of the first out there
using Service Mesh, but alsosome of the first to experience
(38:11):
a lot of the pains of it.
Now, five years later, serviceMesh is very mature, but we're
building things very differently.
We're not building on top ofKubernetes much like we thought
we would.
We thought we'd be doingeverything on top of Kubernetes
where service mesh would be thegreatest fit, and we're
beginning to realize that, whilethat is partially true, there
(38:37):
are a million more workloads outthere that don't require a mesh
, and I say this because whenyou think about gateways, api
gateways, for example we couldspend an entire conversation on
API gateways.
They fundamentally do the samething as service meshes do, but
gateways are also API.
Gateways are also like loadbalancers as well.
(38:57):
They are load balancers.
In fact.
The networking world has seenthis pattern so many times
before with application loadbalancing.
There's nothing different here.
It's just who actually usesthis technology, and it's more
so developers.
What I've noticed is developersjust want to build.
They don't want to sit thereand build for microservices,
(39:19):
they just want to build codethat works, and so we can't
force them into a microservicespattern.
But we can only provide themthe right guardrails, the right
pieces, the right environmentwhere those applications can run
but still have things like TLS.
We could still make sure weterminate connections
appropriately or load balancethem or circuit break them, but
(39:42):
we shouldn't have to depend onhaving Kubernetes.
We shouldn't have to forceourselves into a mesh.
Now, if folks are building ontop of Kubernetes, I think mesh
is a great technology for themto consume, because it's
probably the easiest way tohandle things like east-west
routing, implement things likeTLS and authentication as needed
and just scale appropriately.
(40:03):
But if you're outside of Meshor outside of Kubernetes, you'd
probably want to consider othertechnologies is my opinion, and
Mesh is probably like maybe 5%to 10% of what, or Kubernetes, I
should really say andcontainerization is like 5% to
10% of what's actually out there.
William (40:24):
There's so much other kinds of workloads, gotcha, and
sorry for derailing that, Ithink you know.
Back to Vaughn's question.
I'm curious as well about theyour work with the CNCF.
The CNCF is just doing greatthings right now.
Selium's part, yeah, selium'spart of the CNCF.
So yeah, and what is it like tobe an ambassador and what are
you working on these days?
Marino (40:49):
So I you know what.
There isn't a specific like setof tasks you're expected to do
as an ambassador, Like I justkeep doing the same things that
I'm doing anyways.
I'll still write tweets aboutyou know technologies, I'll
still host Twitter spaces, andif you want to hop on, let me
know.
I'm more than happy to host youboth, and I think that's like
for me, that's enough.
At the same time, you know I'llparticipate in the local
meetups that we have here andhelp organize them, and that's
(41:13):
how you give back to thecommunity, because I've been in
tech for like 20 plus years nowand I've learned a lot.
You know I've had a lot ofpeople that have mentored me,
given me so many differentdirections and pieces of advice
that have gotten me to the pointthat I'm able to talk to the
both of you, and that's massiveappreciation, by the way, for
that.
But it's also time to give backwhere you can, and this is one
(41:35):
of the best ways to do so, byproviding paths forward for
individuals that are trying tonavigate early on in their
career.
Where do I want to go?
Should I focus on Kubernetes?
Sure, but so many people are aswell.
Why not focus in on maybe alittle bit more of the
networking stuff that's outthere, specifically like proxies
(42:00):
, service meshes, cnis, maybesome of the automation behind
that or the GitOps behind thatas well, and that's generally
where I find myself.
I don't need to be the onethat's actively contributing to
code or to documentation,because we have plenty of people
that can do that, but we don'thave enough people out there
talking about the benefits ofthis technology or why it's
useful or how to use it, or howto get started even and break
down those barriers.
That's what I'm here to do orhow to get started even and
break down those barriers.
Eyvonne (42:23):
That's what I'm here to do.
So if there's somebody outthere who has interest in the
they've seen the CNCF, they'reinterested, they're curious,
they want to get more involvedwhat would you recommend they do
?
Marino (42:35):
Now, if it's within your affordability range, I always
recommend a KubeCon.
Kubecons are probably the mostimmersive experiences to really
just get your career and justyour mindset jumpstarted onto
what's going on in the CNCF.
It's kind of what did it for me.
Actually, I went to my veryfirst KubeCon in 2019 in San
(42:57):
Diego.
It was phenomenal.
Sorry for the background noise,it was phenomenal.
San Diego, it was phenomenal.
Sorry for the background noise,it was phenomenal.
And what I began to realize ishow immersive the community is,
how diverse the community is andhow engaging they are.
Kubecon has come a long waysince then.
It's a lot more commercializedand it's just more oriented
(43:17):
towards vendors, obviouslybecause of how big it is, but
there's a lot of the communityelement there.
So, if you can go to a KubeCon,if you cannot, try to go to a
local CNCF event like a KCDs oreven a KubeDays, and if that's
not within your availability,try to go to maybe even a CNCF
meetup.
There's probably a localchapter very close by and most
(43:41):
meetups happen quarterly or evenmonthly.
Try to go to one of those soyou can get a taste of what the
CNCF is like, and usually thosesessions or those meetups give
you the opportunity to see howother speakers talk about their
technology even gives youinsight as to what's going on as
a whole in the program, likefrom updates to Kubernetes to
(44:02):
how to be a CNCF ambassador, andusually you have ambassadors
running those meetups as well.
William (44:07):
Awesome, I know I want to be mindful of your time
because I think you have to jumpnow, but do you want to tell
the audience where to find you?
And I think we need to do apart two because there's so much
more we could dig into.
So maybe later on, maybe nextyear or sometime yeah, I'd be
happy to.
Marino (44:22):
But if you want to find me, I am absolutely on Twitter.
My handle is very unique.
In some ways it's virtualizedsix, but I use the number six to
kind of complete that.
Maybe Yvonne or William canshare that in the show notes
later on.
But I'm also on LinkedIn.
So if you want to connect withme there and you don't want to
be on Twitter, that's totallyfine too.
(44:43):
That's where I tend to hangaround most either LinkedIn or
Twitter.
I do occasionally make YouTubevideos and live streams, but
honestly, I don't have the timeand I just prefer to invest my
time gaming or doing otherthings at times.
But anyways, it's been apleasure being on the show.
Thank you so much.
Thank you both.
I really do appreciate it andhope to be back again.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com