DevOps and Docker Talk: Cloud Native Interviews and Tooling

Bret: Hello, I'm Bret.

And this is my show.

Thanks for listening to my podcast.

This comes from a weekly YouTube live that I do, and I hope you enjoy my guest.

I'm finally back in 2021 with a whole slew of new
episodes coming after, about an eight or nine month break.

Unfortunately last year.

Thanks for being patient and we're back.

Some people might call this season two of the episodes, but whatever.

Hey, we're back.

It's 2021.

We're launching all the old good stuff and all the new stuff we're
recording on YouTube live over at bret.live b-r-e-t dot l-i-v-e every

Thursday.

Bret: Welcome to the show, Brian Christner all the way from splits I'm I streamed from my
house, but I just want to get this out of the way that by the way, that is not a fake background.

Brian: so I go sit back here in this, my, my real background.

Bret: Yes.

Yes.

If you could just get a bourbon and then sit there with a, a vodka
or bourbon or something, that would be very classy and we can have
a conversation, but his background looks so great at the office.

I was like, that's that?

Can't be real like, Oh, those nice leather couches and a wonderful wall painting.

That's very twenties, right?

That's like kind of a, it feels like the twenties and thirties era.

Brian: We're ready for the roaring twenties.

Once again.

Bret: Oh, that's right.

That we are in the roaring twenties there.

Right now they're the COVID twenties, but eventually we're going to get rolling again.

Brian, those that don't know you from the Docker captain
days or from your courses, which we're going to talk about.

Tell us a little bit, your background, how you got here.

Brian: How I got into Docker generally is it's a very similar path as you breath, to be
honest is like before one dot O I was one of my friends in Silicon Valley told me that
there's this great new tool called Docker, and it's going to make the world better.

And, and I was like, yeah, okay, whatever.

I didn't believe it at first.

But then I started looking into it and I really thought, this is quite
amazing and is really changed how I was looking at application development,
as well as, how I'm going to deploy this into production in the future.

And when it first started, obviously there was no swarm.

There was no Compose, there's no Kubernetes, this, it was just containers.

And it was really.

Just amazing at this point.

And then it just kept on adapting and Compose came along then swarm and
Kubernetes, the ecosystem just continue growing and the CNC and F was adopted.

It just really changed course completely.

But I started with a company with called Swisscom here in
Switzerland as a national telecom and we were actually developing.

On Docker before one that, Oh, and we released some software database as a service using Docker.

And it was really quite amazing and really changed our use
cases on how we can, be most efficient with our infrastructure.

After that I started working more into the cloud and
start understanding how we can use Docker in cloud.

And then Kubernetes, this came along and eventually along
the way, I started my own consultancy along with Derek Reish.

We started 56 k.cloud, and we started doing consulting around DevOps, cloud and containers.

And it was really an exciting time.

We did it for quite some time and we learned a lot.

We traveled to all the Docker cons.

We are just everywhere.

We try to be everywhere and talk to everyone.

And it was really an amazing experience.

And just recently back in January, I decided to hand over the reigns to Dara and he's.

Continuing on with 56 K he's taking it to the next level
with 5g and some really cool projects are doing over there.

And that's when I start focusing on casinos, actually back to my roots because I
started in casinos back in 2000 crazy, but and now I worked with casinos for 10 years
and now I'm coming back and now I'm actually working in online casinos and we're trying
to bring it to the next level, more automation and all the buzzwords, AI, big data.

We're trying to bring this now to our online casino, jackpot.ch.

Bret: Jackpot that ch that.

It's funny when you told me that you were doing that.

I had to have a moment where I thought about, like so many
industries casino industry didn't start out in tech, it was a

very

Brian: it is mechanical and then it got electromechanical.

I remember like serial connection between the slot machines when I first started.

And that was like, stay the art.

And then we got to cat five and fiber.

And so I saw the whole evolution actually go through the slot machine as well.

Bret: Yeah.

And my, my, some of my favorite hacking or like heist movies are obviously casino based and
they always, there's always that component of them having to rig the machines or whatever.

And so when I started thinking about your job, I thought, wow, like online
casinos now just like the sheer amount of tech that has to be there.

And I thought of it as it's gotta be, I'm just guessing, but it's
gotta be something like banking combined, between safety and regulation
and protection and all that and money changing hands and all that.

I just thought about it.

There's a, so much of the world of tech that is involved in just that right there.

So I can see why you were excited to get back to that kind of product, because
there's a lot of hard challenges, which, for a lot of us, that's a fun thing.

Brian: Absolutely.

We have the technology aspect.

We're trying to move as fast as we can, but we're also the most regulated
industry, probably in the world, more than banking and everything else,
because they want to make sure that everyone is playing by the rules.

Bret: Yeah, for sure.

And so let's talk about this Docker thing for a minute.

Cause you, this is, we all been locked down for the last year.

I'm actually remembering all these fonts, all this fond memory nostalgia of all these conferences
that we were, I was just talking, we were just talking before the show about the last time.

Yeah.

Before, the last time I was in Europe and.

I don't remember the last time I was in Europe that wasn't for Docker or Kubernetes.

For years there, we were all just in the touring circuit of conferences and
seeing each other, whether it was coop con Docker, con O'Reilly you name it.

We were all seeing each other at these events.

And we were all super excited about basically all this new infrastructure tech that was
making it easy for developers or easier for developers to get their code on the servers.

And, not that luster is gone, but I'm really curious to see what it's going to be
like now that we, once we start eventually opening back up, what the conferences
are going to look like, what are we going to be talking about at those conferences?

Because,

Brian: Exactly.

To be totally honest.

If you look at the news, it's, the news has changed as far as tech goes,
because usually it was always around launches at events and conferences.

And now it's there's no steady, information announcements that we used to
get, we know like specific dates, we're going to get something from, a Dr.

Khan or cube con.

And now we have coupon.

We have Docker con, but I don't know.

It's it's different from in-person versus virtual

Bret: Right.

Brian: because you can just consume the information anytime,

Bret: yeah and it's also a lot of the stuff we've seen is very iterative.

Since the Dawn of containers and then Kubernetes I feel like a lot of this stuff out there is
very, small ideas stacked on top of it, previous ideas and nothing that's completely changed in
the landscape, which I'm actually totally cool with right now because I, I'm still the consultant,

and we spend so much of our time helping companies still adopting container practices and just
trying to automate code from a developer, getting onto a server, like just that whole middle piece.

There is still quite complex, tons of choice, tons of Compromise or
decisions that have to be made and what we can get in that later.

But that's been my like Bailey wig for the last year.

Brian: It's actually a great point, Bret, but the thing is the
challenge there is you asked three different companies for a strategy.

You get three different answers.

There's no standardization on how do you move from
a to B or from cloud to on-prem or on-prem to cloud?

Or how do I containerize this app?

Standardized it's really based on the consultant you deal with.

Bret: Yeah.

And there's a lot of opinion there, which isn't so bad always, but I think that
we, if you just think back a decade ago, we weren't really standardized on get.

So we didn't even have a common language for how we communicate changes.

Cause everybody, yeah yeah.

And even if you're on like material or a team foundation, server,
whatever, like you had different terms for different things.

And obviously it was different command lines, but the
pull request idea, wasn't really solid in the community.

And it's just amazing when we start to talk about what we have
now is as standards, they're still really low level, right?

Like the container is, I think is standard in the industry, at
least the container image the way we do changes into our code.

But not a ton.

Yes.

Okay.

Maybe Kubernetes is a standard, but we really, when we really say that we're really
talking about was like the core level resources, not like we're going to get into

traffic or

Brian: You're talking about really the infrastructure level.

I mean your standardized infrastructure, but how you put things on top of it is really up to you.

Bret: Yeah.

And the.

The amount of choice, there is one of the challenges that I'm constantly
dealing with, not just in my own consulting and my own projects, but
also in teaching because people really would like a guide, right?

Like people love courses that guide you through the decision-making process so
that you can, and for example, when you're teaching Docker, you don't teach them
five different container building tools and then say, it doesn't really matter.

Like we all tend to teach Docker.

And when we start talking about now at least server clusters in production, we all teach Kubernetes.

But there's all this stuff in the middle.

And then I would say argue that I would even say now traffic like proxies
and engine X and all these things that are just routing traffic around.

They're also one of those decisions that ends up having to happen before we now go to production
because you've got to figure out what Yamhill do I need to describe and all that stuff.

I'm on projects all the time when, where.

We have to figure out what Sierra we're going to use.

We have to figure out where we're going to store images.

We're going to, and there's a hundred decisions there.

How are we going to scan our images?

How, how are we going to test?

And I'm looking forward to the next decade of us, or maybe the decade where we S we
sure, maybe this does mean that there'll be a few products that we all standardize on.

Obviously help.

I feel as a standard at this point, even though there's some people
that still don't like the fact that it's a standard, but that's okay.

You can always deviate from

Brian: they still have to go out and grab code from there, even though they don't like it.

Bret: That's actually one of my points due to teams that
are in there, they're like what if get up goes down.

I'm like if get up, it goes down like basically everything's down.

Brian: Ship your laptop to production.

Bret: right.

If you're on Bitbucket, that's great.

But you're also going to be pulling everything from GitHub.

So yeah, you're not, you're

still going to be

Brian: a round Robin, but that, that's exactly it's a very valid point because I see
that a lot is we're focusing so much on like the fine details of the infrastructure.

And then you ask like a company and you ask them, Hey,
what about the features you bring into production?

What features are you bringing into your customers?

Oh yeah, we have that plan, but maybe, six months from now.

No, the real value trying to bring to the organization.

Yeah.

You're standardizing all these things, but a, the feature you're trying
to deliver to your customer, it's still taking a long time to deliver.

I should say.

Bret: Is that in, in now that you're back in the biz, are you like what's the hard things.

Brian: The hard things.

Now I am on the other side, so I don't have, my hands in the
code and I can't, get into the cluster or anything like that.

So we have a really good team that's working for us and now I'm looking at it from the outside in.

So that's also, one of my points is like monitoring.

How do you monitor like a SAS solution?

How do you monitor a SAS solution that you don't own?

And these types of questions, which totally changes the dynamic
and we're, exploring these possibilities and how to do it, but it
really changes the whole thing versus, me being deep into code.

Troubleshooting things to Hey, I see it's performance problem.

Please help us.

So it's a different role, but it's quite exciting because we're really defining architecture.

We're trying to modernize everything.

So it's really quite a lot of fun.

Bret: Yeah.

And so it sounds, I w to me, I love it when you get to that level where you're no longer
like your top priority, isn't the Docker builds, fail, whereas a lot of the projects
that I ended up being with, because I think people come out of my courses and they.

They want help containerizing.

And so there are a lot of people that are doing that now are a little
bit late in that journey and but it's still happening everywhere.

But at the same time there's teams maybe your teams as well, that are out there.

And like a lot of this infrastructure has been automated code
does get from a developer in a consistent way in almost completely
automated fashion from them to testing, to acceptance, to production.

And now it's more about SLS and, story

Brian: And it's really now you see the bug that has been automated, this automated bug that's made
the production, and how much it costs to actually fix it is all a whole different dynamic, right?

It's really the pain that you deliver to your customers and how fast
you can recover from this pain is where the automation really kicks in.

Bret: Yeah.

And that's actually, that goes into a little bit into the reasons behind DevOps and the
metrics and the things that we should be caring about versus the distractions of like, how
do I Jenkins, which the internet loves to make us think that it's the tool we should learn.

But but to me, it's really, it's talking about these high level performance
metrics, talking about customer that, that, that's why there's that infinity symbol.

So for once I can get back to course making and making new courses instead of updating
existing courses, that's one of those ones where I'd love to get a course out there.

That's really just the soft skills of DevOps to get us all back to that.

Cause we all get distracted, especially those of us that are engineers.

We get distracted a little bit on the day-to-day implementation
of tooling and we often we probably need more than we do that.

That moment where we pull ourselves back and we say,
okay, let's focus on the big picture for a minute.

It's not going to close any tickets, but let's focus on the big picture.

Why are we here?

Let's look at some of these performance metrics.

Do we even have what we need to measure the performance of our business?

Um,

Brian: we're a huge data-driven company, obviously.

Casinos is, very focused on the metrics and that's something that's, I'm coming from a monitoring
background and I'm very like I love data and digging into these trends and things, but it's
really important that we understand as a developer or anyone like building a new infrastructure.

If I have a shopping cart of CNCF technologies, I shouldn't take
like everything out of the cart and try to build everything.

Really in this scenario less is more, and I'm really emphasizing this because I see this very often
where people take, all the cool, the latest things out of the cart and tries to put it all together.

But at the end of the year, you're maintaining all these pieces
and that's where I always refer back to get lab is a great tool.

It, CACD, it does, your get repository security scanning.

It does all these things.

It's one tool, one interface, less context switching.

And I think that's really where we should start focusing is like how we can start.

Like limiting our tool sets and focusing on the value we can bring faster to the organization.

And that's another thing I also say about like visual studio code that's brilliant tool.

And I'm a huge fan because you can basically do everything with vs code.

You can SSH to your servers.

You could do Docker context, switch and switch to your cloud instance.

But you'd never have to leave your console.

You have the same screen the whole time.

You don't have to switch to 10 different apps or a hundred
thousand different Chrome tabs to find what you're doing.

Bret: Yeah, but, sorry.

Brian: It's really just this less context switching and really
focusing on trying to deliver with less is really something also key.

Bret: And that gets into the challenge of a lot of the
tooling out there is really just replacing old tools.

And why I'm a super fan of bash scripting, because that is like the go-to ops
utility a lot of these new tools and we talk about something like get ops, right?

A lot of this is about standardizing way that code and
binaries essentially move around your organization.

And one of the challenges I've had in the last year is I'm just like you I'm, I.

I, I like to say no, I think that the original Docker statement from the

Brian: it's hard.

It's hard to say, right?

Because you find these new tools and a new release and you're like, Oh, I got to try this.

And next thing you're down the rabbit hole.

Bret: Yeah.

And now it's another thing you gotta learn another CLI you gotta support.

And but at the same time, if you don't implement
that tool, do you still need that thing that it does?

And are you going to have to write scripts and things like that,
and now we're down the rabbit hole of nothing is standardized.

Your tooling is unique.

I think especially, you and I me in particular, I'm not the youngest
guy out there and one of the, one of the trends, because we're, we've
both dealt with hiring people, dealing with management like that.

People are switching jobs faster and faster, right?

When I, in the nineties, when I first started, it was very normal that I had people.

Yeah.

I had people working for me that had been working there longer than I had been alive.

That was a.

In government, that was a normal thing.

And they just looked at me like I'm just passing in the wind.

I'm just some dude that will be coming will come and gone before they even retire.

And they didn't really concern

Brian: still there.

Bret: But that's so long, so much not the case anymore.

And what I think really people under appreciate is part of the standardization that we're
all going through in terms of containers and Kubernetes and yam as a descriptor tool.

This is all about allowing I'm going to walk into your shop and not
need three weeks of to spin up and understand how your stuff works.

And if we can get a level of consistency, at least at the plumbing level you can,
you're gonna get people starting to focus on features and stuff like monitoring
the uniqueness of your custom application other than how do these things, all
pit fit together in the middle, which is, I think, will we get distracted on?

Yeah.

Brian: It's perfect example.

Standardization, I would say is probably easiest at the Docker and
Kubernetes level, because it's something that's very, well-documented,
there's lots of technology around it, but then you get into monitoring.

I remember Dara and I went to a customer and we walk in and there, we were
talking about monitoring and we're like what monitoring do tool do you use?

And they said, we use 10 different tools.

And what's the dashboard.

Do you watch, when you have 10 different tools it's quite amazing.

Bret: need 10 screens?

Brian: and it was a small organization, a medium sized organization, but
surprising they had 10 tools and not everybody was using these tools, obviously.

Bret: And everybody's in the same one and alert when we talk about this show
on occasion about alert, fatigue, and just how even with just one tool it's.

It's a lot of continuous amount of work to try to make sure that you're getting
notified and you're reacting to the things that are relevant and then ignoring
everything else because you have to otherwise your whole day is saying, yeah.

Yeah, I know.

Yeah.

I did have a two second spike in IO on that server.

I don't care.

So when we get to no, th there is good news here, right?

Because I feel like one of the things that permit the us did, and not to go down the permittees
rabbit hole, but I feel like we're at least starting to get standardized on bringing, not just
logging, but now event analysis or advent data coming out of our apps in a consistent way.

Cause I feel like even just 10 years ago, if apps were
monitored, they certainly weren't monitored consistently.

And it was very hacky, very much the ops team, trying to figure out how
to monitor rather than the dev team describing how to monitor, and I feel

Brian: And that was also like how Docker introduced this as well, because now
you're standardizing logging and monitoring on your application level, which was
brilliant before it was like every application you have to configure your monitoring.

Whereas now, Hey, at least I get.

Basic statistics on each container.

I know exactly, a CPU and everything out of monetary, everything.

So is really a revelation when permit, this came along and then now everyone see adviser came
where you just spin up a container and you get every statistic known to man off your computer.

And it's just wow, I didn't even know that stuff is running on my laptop.

And it just kept going down this way.

It's really a permit.

This really started this whole adventure with monitoring, I find.

And now if you even look at all the monitoring tools on the market, they all except
permit the us as an end point or their metric format, which shows you it's a standard.

It is now the

Bret: it's become the standard by a convention, that so many people have used it that, and it was.

They because they were creating something new not from scratch necessarily
in terms of the idea of the end points in the format of the data.

But I love that we have something we can point to in the industry.

And I can give to the dev teams and say look at this, look at how they're doing it.

And if you just conform, like we don't have to use permit this, but cause
I'm a big fan of SAS solutions, especially for monitoring and logging
solutions, I re would really not want to deploy my own and manage it.

We got too many things to do.

I don't want to have to manage my own custom monitoring solution.

And at a certain size, obviously at scale, like you ha you probably
have to do all that stuff yourself, regardless because sassy that
gets too expensive or just doesn't, isn't conforming to your needs.

But for a lot of the shops I'm working with, they're not that big, it's 30 or less people.

And and the dev and ops teams working together and they
could probably just do Datadog or, anything like that.

Brian: exactly back to the focus.

You only have, certain number of hours a day.

Do you want to spend it babysitting your monitoring system, getting it all, tuned up and everything?

Or do you want to focus on like this new feature for your customer?

Bret: I'm glad it's going well there.

And obviously you get a plus one for the excellent office space yeah.

And if we take the wide shot, there's actually a, there's a slot machine on one

Brian: is a slot machine in the office there.

Bret: Yeah.

And then and and I really nice

Brian: like a retro.

Bret: the best looking fridge.

Brian: It's actually functioning.

It's not

Bret: it's not just for

Brian: problem.

Bret: it looks like it was made in the fifties.

And it's still cool today yeah.

Okay.

Brian: Yeah.

Yeah, I'm a huge fan of monitoring.

If we get back to this monitoring topic again, just a permit, this, I remember we went to a
meetup in Zurich must have been a couple of years ago and CERN was there and CERN was, CERN
is the, they're building this huge Collider and, it's just trying to find, trying to create
a black hole and Switzerland, which is, very comforting, but what's really interesting.

They showed their Grafana graph with permittees running in the
background and there's a hundred thousand cores on this graph.

And then they're like the guy giving the demos like,
Oh, let me just spin up another a hundred servers.

And, it's like unbelievable.

And that's my tax money at work, it's really it was really impressive to see how well these things
scale, here, I can just download this and start running it off of GitHub or from Docker hub.

And it can scale to a certain size.

That's really this.

That still blows my mind today.

Bret: And we have we have solved some of these problems around the toil.

I love that term that came out of the SRE movement, that the toil of automation and DevOps.

And, yesterday we were, I was on a project and we were, I was manually downloading
Ruby gems and manually pushing them to our new Ruby gem, RF artifact store.

And I was just like, this is such toil.

Like why?

I had to put in, I had to put in more work for the future to automate all this.

This is dumb.

I think that a lot of us, if you're in an organization that doesn't appreciate removing
the toil as an actual role in your job I advise you to read up, read the DevOps handbook.

Like for those of you out there read the

DevOps

Brian: a free resource.

It's a free resource.

google.com forward slash SRE.

I think it is.

Bret: Yeah, there's a huge book on SRV from Google.

If you read those things, you can become an advocate to your management and
maybe change some of the culture so that don't, you, you don't spend all
your time on features and none of your time on improving the system itself.

Which is not it's funny how, like you nowadays, those of us that have used good
apps, and w we're all used to like these frequent updates on our phones, right?

This is a normal thing in the mobile space, frequent updates on our phones, constant updates.

And we've all gotten so used to that, that when you find an app
that doesn't do that well, and there, the bugs stay around forever.

It's just glaringly obvious that from those of us that
work in the biz okay, I know what their problem is.

They have a huge backlog and they're not, and they're
focused on features, not on, on the infrastructure itself.

And it's really hard to build and deploy things for them still.

Yeah.

And it's becoming glaring obvious.

Brian: A great tip for people trying to convince their management organization
to go like modernize to go to DevOps in this whole way is really start small.

I can recommend enough to like start with Grafana.

Grafana is a perfect example where you can spin up a dashboard and show
some really nice KPIs that are updating in real time to your management,
and then explain to them, Hey, this is actually running our infrastructure.

It's providing value back to us and we can probably bring it to the next level.

Cause once you show a dashboard to management, they're usually all in any way,
especially a Grafana dashboard, they see all these bleeps and signals moving around.

They don't really understand, but they like all the green and red.

And so they're usually all in.

But once you get this value, buy-in from management, then
you start small little projects and keep adding into it.

You don't tell them, Hey, I want to S spin up a giant Kubernetes, this cluster from day one.

You're not going to get buy in because first they're not
going to understand why, what it is and things like that.

So you really have to tackle it from, what management needs first,
they need visibility into what's going on and then keep going this way.

Bret: Yeah.

We have this one asking in chat the Google SRE book, is it sre.google ad is at that.

That's what it is.

Yeah.

Make sure I get that to them.

Cause that's a

great free resource that

Brian: a great resource.

google.com that SRE, back when we were doing conferences, I was doing the
monitoring and logging workshop for the Docker cons and different conferences.

And that was like, half of the session was.

Based on what you get in this book is really, the key signals you're getting from monitoring
the four golden signals and really just how you can like monitor your infrastructure and
not over alert yourself while you're mentioning earlier is you don't want your people to

start automatically setting a rule and just ignoring all the rules, all the alerts coming
in, you really want it to make, if an alert comes in, it should be the data centers on fire.

Not that your CPU is running at 20%.

It's really, that's what the alert is a ticket on the other hand is more like,
Hey I have an issue but it's something that human interaction needs and it should
be like, a JIRA ticket that opens up and we should schedule a task to fix it.

So that's really the difference.

You should really aim to have one maximum tooler today.

Period.

If you have more than that, then you really need to consider going back and readjusting your alerts.

Bret: Now do you is it an interesting metric you have there one to two per day?

Is that per team per person, per organization?

How do you,

Brian: Team because, the team is really watching these alerts.

Per organization, obviously you're tons of different departments and different
things, but for us, if the website is on or off, that's a major indicator.

I want to know that's the type of thing I want to know.

I don't care if there's a small little link that's broken, that's not alert.

That's something, that's a ticket that we should take care of.

People your visitors to your application, your website, they care about what three things.

They care if it's on right.

If it's a performance problem, if it affects them personally.

And the third one is like reliability, can I honestly rely on the
service to always be there and yet to protect that one at all costs.

Because if people don't believe that, then they won't come back.

And that's for internal or external tools.

Bret: And I think we all know, I was gonna say, yeah, we all know that one thing in our life, that
software that is not reliable, that we just can't, we can't seem to replace it or do without yet.

Or we haven't figured out a way to get rid of it.

And we all have that story of that app, that website, that thing on my computer.

And it's it that, that sticks in our brains so much more than, Oh yeah.

That's that website always works.

Brian: A website can be slow.

It can be different things like this, but if it's not on, then people won't trust it.

That's the thing.

Hey, that's really a game changer and you can see that with
outages of services that go for days or weeks at a time.

And then they, you don't get any answer from the organization.

What really happened?

This doesn't come across well.

So that's why, I those three things are really.

Sr.

The SRE book really touches upon and really emphasizes
that why we should protect those three things at all costs.

Bret: I have not read it page page by page.

What I did is I I tend to go searching for things in there that like a specific topic.

I'm like, okay, I want to talk to someone about this topic.

So let me go sound smart real quick.

And I'll go read that section of the book.

Cause it, is it the SRE book that also has the different parts are written by different people?

Or am I thinking of something else from Google?

Brian: it's exactly this.

And the thing is, you have to take this book with a grain of
salt because obviously it's built, it's written for Google right.

At the Google's scale, et cetera.

So you have to take a lot of things like, Hey, maybe like this particular thing or
this, how they treat this SLA doesn't work for my organization because they have
The triple six, nine SLA, like the , maybe that doesn't work for your organization.

So you have to like really consider these things.

But I would say like 75% of the book is brilliant.

It really helps you understand how to run your organization.

Tree operations is a software, right?

That's what they're trying to do.

Bret: And, there's a lot of times, I'm the first to say, You're not,
I'm not Netflix, I'm not Google, talk to people that, clients, people
that are asking for help or opinions on things in container land.

And but the same at the same time that those are the people that are pushing the boundaries.

And we need to pay attention to them at least a little bit with books like this.

And blog posts on Netflix tech blog, those are those are gonna end up on hacker
news when they have this is how we deal with it at Netflix kind of thing.

But those are the ideas that gets planted in our brains that eventually
result in something that we might change at our own organizations.

I can definitely tell when I walk into a team, if there's members of that team that are
going to these conferences that are watching these talks, reading these books, because their
mindset, eventually if you do this just a couple of times a year, your mindsets and your
vocabulary even starts to change as you mature in how, a decade ago was all about 12 factor.

We were all getting into 12 factor and learning 12 factor and today that is still very relevant.

It maybe isn't the thing that's on the top, the topic, it's not the topic does
you're at conferences and all that stuff, but it's still, it's amazing how some
of these ideas and concepts that DevOps handbook super relevant five years later.

However, so that's been out,

Brian: for sure.

Yeah.

Bret: And, now that we have this sort of latest job title of SRE, that's
the defining, I would say, larger teams having that kind of job role.

And but I still feel like that a lot of the topics in there are very relevant to people
that may or may not even need a dedicated SRE type of community because they're in most
cases and the projects I've been working on this last year, they're very much the same

way where they're going through transformations to operationalize their own software so
they can run it themselves, not just either sell it to customers or they're running it.

Maybe they're running it on a platform like Heroku, and they're wanting
to take a little bit more of that response ability for themselves to grow.

And they're having to learn these concepts on the fly rather than maybe prep themselves
with some of the, these things like books and documentation and, going to conferences,
which it's weird how you get used to going to conferences and you forget how much you learn.

Yeah.

Even though we all chat in the hallways, Brian.

I learned,

Brian: talk.

The hallway talk is really right.

Bret: I learned so much from talking in hallways with people like you.

Yeah.

Brian: And I can't emphasize enough just reading up on
things, asking people questions cause your community.

Both in Docker, Cuba, you need this and CubeCon, these communities are just amazing.

There's some amazing people out there that is willing to help you.

Don't believe all these trolls out there, just mute them and forget it.

And there's people really trying to help other people learn.

And that's where you come in, Bret.

And we're, I take some notes from you is really, we discussed it
earlier is at Docker con in San Francisco, we were sitting at the
top of this, some tower there and and I was kicking around the idea.

Maybe I should start a course and you're like, you should do it.

And I took it to heart.

And you said, you, you said this verbatim, you'll never learn
more about yourself until you try to do your own course.

And that is absolutely true.

A hundred percent of the word.

And I learned so much about it and the thing is right when I was done recording it.

I wanted to do it all over again.

Cause then you learn so much by the time you're done recording.

It's just amazing.

You're like the microphone the video, it just delighting just everything.

Yep.

Bret: Yeah.

And what Brian's talking about is this he has now multiple
online courses that he's built in the last few years, actually.

When did these, when did you launch these?

I forget

all in the last year.

Brian: year.

So Docker and visual studio code.

I actually did this at Docker con.

So I did like a, a quick session on it, about how
to use the Docker extension with visual studio code.

And so many people signed up for it and they're asking for more information.

So I turned it into a smaller course and it.

Yeah, it's really quite interesting as a small course to learn how to use the visual studio,
extension, Docker extension, and really help people, bootstrap projects and things like that.

And I found, I learned a lot about it myself when I start going through it and trying to write the
course details and the outline, you start learning so much more about the product it's unbelievable.

And when you try to explain it to someone else, you learn even more.

And in this course, it's a small short course, but it's very to the point and I give you a
bootstrap project, how to bootstrap a Python project and how to run debug inside the Docker desktop.

And it's really quite interesting how well and mature this plugin is actually.

Bret: Yeah, I'm a huge fan of IES code.

In fact, I think you and I both saw the, sort of the transformation in the speaker community.

I and I, and to back up a second for those listening I tend to find that like it's at
the large conferences, especially like now that we're in the cloud native cloud, all
that stuff, velocity, the cube cons, Docker cons and Linux summits, all those things.

That community it's actually quite small.

There's maybe a thousand people that rotate speaking in a lot of these events, but
there is like that core 500, 300 people or whatever that are on a regular basis.

Some of them even make it a part of their career.

And something that interesting that I saw happen was,
to 2015, we were all, people had various editors, right?

Like when you see demos on screen, people talking at conferences, they're

Brian: Sublime and command line and different things.

Bret: which I still use.

I still use sublime actually have sublime up and running.

Now.

I love sublime.

It's one of the fastest editors out there.

Them, Emacs probably, the hardcore Vemone max people.

And I would say that the editor using often was a product
of your background and even the old West you were on, right?

Linux people were very, more likely going to be VIM and Emacs type people.

Mac people might be more sublime, or maybe they might
be like Ruby, mine, or some framework, specific editor.

Adam became really poverty.

I remember Adam.

And so Adam was like that first one of those first open source with plugins and it worked, it was

sublime was shareware.

Brian: be Nope.

Pad plus.

Bret: Yeah.

It was no Petrel plus open source.

I was using it back before even, and maybe it is, but

I was using it so long

Brian: way back when yeah,

Bret: it was before GitHub.

Brian: that's true.

Bret: But yeah, if you're on windows, you were notepad plus, cause I don't
know if they had a Mac binary, but anyway, long story longer there was
that vs code started showing up at the conferences and people's demos.

And it was weird to me because I always proceeded as a Microsoft product.

Especially because of the name.

And I did come from some of that background of visual studio, people that had the
full visual studio, they were doing.net, C-sharp and even old visual basic stuff.

And they obviously reuse the name, but they have
nothing in common other than them both being editors.

And I started to see people that I would never think
would run a Microsoft product, running demos with vs code.

And that was like the start of it, of the wave.

And eventually now it's to the point that if you see a conference
talk nine out of 10 times, they're probably running vs code.

Like it's

Brian: for sure.

Bret: Crazy.

How, yeah.

How much has become the standard.

If they're not, they're a holdover like they're a hardcore VM user or Emacs
user, and they're not going to change no matter what editors out there.

But anyway,

Brian: I was, it was also a Docker con and I have to look it up.

I think it was Patrick used to work at Docker.

Now he works at Microsoft.

I can't find the name off the top of my head anyway.

He now works at Microsoft and he actually gave a demo where
he was doing a live coding session with visual studio code.

And I was just blown away.

He had his, he was doing live students coding like
a peer coding and the student was in India, I think.

And he was in San Francisco and they're working collaboratively on
the code and you could see the highlights and the video in the corner.

And I was just like, Oh my God, what in the world is this?

And that was just like at the very beginning.

And now there's so many extensions.

The marketplace is growing exploding with a different plugins.

So it's really quite impressive how Microsoft is enabled.

Yes.

Bret: Yeah, and I've never been a F like, I've always tried to be a VIM by default person.

Not always, for the last, I don't know, 20 years and I find myself
using them less and less because the extensions in vs code are so good.

The Lindt automatic, linting the, like you said, the re the remote.

Yeah.

The remote code inside a WSL two containers on windows.

Like you, you go down the list of the remote pairing ease of use of remote pairing.

It just, it becomes so compelling that I it's now my, it's slowly become, and I hate to
admit this I'm a gooey first developer which I, not necessarily trying to brag about that,
because I always thought that it was cooler, especially from the CIS admin community.

It was all about, yeah.

I'll yeah.

I'm going to share my VIM.

My, my VMRC files through GitHub so I can have them on all my servers.

And anyway so take this course, people that's what I'm saying is if you don't, if you don't think,
if you think there's some more, you can learn about how to develop, especially in containers,
because debugging in containers from your native host environment can be pretty tricky.

I tried to do a little bit of it in my no JS course, and it's not the best.

So I probably advise you if you've taken that course to follow it up with this one,
to get a better example of how to enable debugging and containers while using vs code.

And then the other is, of course you have, which we were going to talk about.

Cause I'm obviously we're both traffic ambassadors.

We both love traffic in terms of its ease of use, especially
for things like less encrypt and container native stuff.

Tell me about that.

The complete traffic course real quick.

Brian: So this was my first course, and this is what really I thought about.

I really looked at the cloud native landscape and I said, okay, what.

Technologies do I really love and use quite often really
don't have a course or some sort of content behind them.

And that traffic just jumped out at me as they have really great
documentation, but there's no one creating courses around it at the time.

And that's when I reached out to traffic and I said, Hey, I'm really
interested to do this and let's collaborate and build this course.

So I really worked with the traffic engineers and we
went through and just went through every different step.

And initially to be totally honest, I was doing it on Kubernetes,
but the challenge I had there was I had so much support.

Questions about Kubernetes.

This is not about traffic that I switched to the Docker.

So it's running Docker and Docker Compose because the
support was just going crazy and Hey, how do I set up?

Kubernetes is how do I set this up?

And I, how do I get that going?

So it's focused on Docker.

That means it can run on any platform.

It's quite easy, but there's enough instruction in there.

It started also in Kubernetes, this, but we go into, How the architecture is built
and the auto configuration, which is, what initially attracted me to traffic, because
if you're been around containers a while we started out with engine X or Apache,
something like this, and you had to manually write all these routes and maintain them.

And every time something changed, you had to go back and change it.

And with traffic, it just, auto discovers all your
containers that are running and does all the routes for you.

And it was like black magic running, in the background,
I was like, what in the world is going on here?

And as I dug deeper into the technology, it was just really amazing.

And you can scale it.

It's really great.

And the community is just amazing.

Patricia, over there does a great job with the community and it's something that was.

Really a passion of mine traffic.

Cause I use it for a very long time and it just continued growing and I kept on adding to it.

And it's not just focused on Docker, Kubernetes, this, you
can also do a just file level type of configurations as well.

And it has, Amazon ECS.

It has a bunch of different different configuration possibilities.

And it's really a great tool that continues to grow and
they're adapting more technology on the back end of it.

But I really focus of course, on the open source
because I want to make sure it's inclusive for everyone.

And it's gotten a lot of great feedback and I continue to try
to update it and add to the course as features come available.

And traffic it's just, yeah.

What more can I say?

It's a great project.

And I have a lot of samples that you can get started with, like how
to set up like a monitoring stack with permit via Grafana and traffic.

Just like one click, you download it, you deploy it and it's
everything deployed for you with domains and DNS and all set up.

So it's really cool.

And I think Bret, you have quite some similar projects that you have, I think a swarm rocks or

Bret: Yeah,

Brian: your link

Bret: mine, but that is a good one.

That was a good one.

Yeah, it has swarmed.swarm.rocks.

I think it's a website or something like that.

I have the dog, I have the dog versus cat thing.

Yeah.

Brian: Yeah.

I love that to me.

Cause it's

Bret: Oh, well,

Brian: yeah.

Bret: was actually the story behind that is I was trying to see, cause it was that, that whole
voting app was a great demo that Docker belt of, multi it showed off a lot of the ways that Docker
help a team because it showed how you could take different languages and put them all together.

And it was seamless.

And but I got the, I have had an addiction to buying domains for a very long time.

And Laura taco also has that same affliction and we were talking one day about, this
talk, I was going to give this talk at DockerCon and I wanted a trendy domain for it.

So we were looking at all these different ways to make a domain.

And then it just turned out that dogs versus.cat was a domain that was available.

Brian: I love

Bret: Uh, so yeah, I love it.

When you can get a perfect domain for your example and, spend $7 on $110 or whatever.

And then, let it expire a year later and someone else picks it up, but.

Brian: How many people have done that though?

You've maybe had an adult beverage and you go out and start searching domains.

You're like, Oh, I'm going to start this project tomorrow.

And next thing you had 20 domains of sitting idle.

Bret: Yeah.

Oh, I do.

I have tons of those.

And then every year it's a tough decision of, do I really want to buy this again?

I'm not going to have I

Brian: Renew because you're going to do it.

Bret: Yeah.

Yeah.

Yeah, I've got 12 startup ideas, all sitting there waiting for me.

I already own the domain, which is the first step in all good products is you have to buy the

domain first.

Yeah.

Step

Brian: need the great name.

Bret: You've got to

Brian: we have a couple of questions in the chat here.

Bret: Yeah, actually a pretty good one.

Then this is like a whole separate conversation we can have, but do you
think with all these automations Emmanuel asks making everything easier and
creating many system administrators that don't want to understand the system?

So I have lots of feelings about that question.

It's a great question.

Okay.

Brian: Yes.

Yes, automation makes everything easier.

But getting to that point, upskilling to you understand the automation,
for example, Terraform is brilliant, but then you start unraveling
the Terraform spaghetti, and you start like terraforming, everything.

You start terraforming your home router.

You really go down the rabbit hole with Terraform and
it's something that you have to really draw a line.

Where are you going to stop the automation?

Where does it make sense to where it doesn't make sense?

I think that's the biggest thing and system administrators.

If you really want to automate everything, you should do it.

I'm totally a fan of automation, but you need to find the cutoff and Bret could
probably help me here is how do you understand what and what not to automate?

And I think the biggest time sinks are easy.

So if you do it more than three times, you should automate it.

That's an old system administrator

Bret: Yeah.

Brian: iron,

Bret: that's like the definition of toil, is it?

Yeah, it did.

Now is considered toilet after the third time of doing it the
there's a couple of things to read into that question, Emmanuel.

And thank you for that.

So one read the question.

I could read into it and say the system administrator doesn't want to understand a system.

They won't no matter what you do.

If they're just not interested, that's you, can't, that's a different problem, right?

That's staffing.

But I would argue that automation in all of its forms to a certain extent, I think are necessary.

And if you think about what we have now is the higher internet and the way we all use it
as developers and it pros or whatever, it's all a levels of abstraction at this point.

So I don't have to concern myself with the size of my packets
and TCP anymore because we've basically automated that problem.

And so I would argue that in any good organization, that's
trying to deliver more stuff faster and that's essentially the.

That's DevOps stuff more reliably, better, faster shipping
and then learning better and faster from your customers.

So if you're doing that, you have to automate at all levels,
or you're never going to be able to succeed at those goals.

So in that you, there, you're basically creating systems that sure.

Maybe not everyone fully understands because they don't have to toil and manually do things anymore.

But at the same time, we have to do that.

And if those things, cause if.

I'm trying to think of a good example, if an example of TCP packet size, when those of
us have that problem on very rare occasions nowadays, unlike 30 years ago, when I was
first implementing TCP back in Novell NetWare days when windows three, one, one, yeah.

When does windows for net for work groups or whatever back in those days, right?

Like you had to concern yourself with that.

You had to concern yourself with full or half duplex connections or,
collision domains because you weren't a fully switched packet network.

You were hubs.

And there was all these concerns and you had to know that stuff, or your network
would not function in your server would not talk to your client nowadays.

We can't worry about that stuff anymore.

So it's all been automated, but it still is a problem for a very small amount of people.

And then of course, if that problem happens to you, you have to go down
the rabbit hole of learning a crap ton just to be able to troubleshoot.

And it sucks, but.

It doesn't happen very often.

So the same thing I think is true in DevOps is we're learning these new ideas
around, get ops, even better CIO like CII that has zero shell scripts in it.

That's the CIA that I want.

I want pure Yammel CGI.

Yeah, no code CGI.

I want that world.

I want the drag and drop point and click CEI to deployment methodology.

That's what I really want as an administrator.

Now, granted it all, what I want is that drag and drop
UI, that then saves it as Yammel in a get repo somewhere.

But I don't want to have to memorize all the Kubernetes AML.

I would really rather to drag pieces together, it save it properly, anyway, that's
eventually we may get to that kind of thing, with templates and automation stuff.

But the whole point there is that yeah, the point there is that eventually
I won't have to, nor those things, no those things, because we're going to
have higher levels of abstraction that we all have to concern ourselves with.

And maybe someday we'll have one DevOps person per 10,000 servers.

If you can think about like the levels of automation that we have to get to, right?

Yeah.

Cause I started where it was like one administrator to 10 servers in the nineties.

Or thereabouts, maybe even one to every five servers.

And then over the years you could get like one administrator once this
admin to 50 servers, once you got into data center automation and whatnot.

And now we're obviously with cloud-scale we're into the hundreds, if
not thousands, if you're in a really high efficiency organization.

But we've got it.

We were all driving.

We're all on that journey.

And that journey is layers of abstraction.

So I'm now

stepping

Brian: we continue.

But also Regarding automation.

I can also say, there's a term in Switzerland called and that's like a sniffing day.

And I can really recommend this and you go with the team, another
team and you say, Hey, I know you're having this pain XYZ.

I'm going to sit with you next to you and watch you do your workflow and understand how that works.

And then it clicks in your head like, wow, I can actually automate
that and really change this whole dynamic of this this workflow.

And you just keep on doing this.

You keep on iterating through this by sitting next to someone, not like watching
the screen with them, but really sit next to them because to get the paper out of
their desk or, you really have to see the whole workflow to really understand it.

And I've done this a couple of times and it's very
helpful, and you really understand the problem much more.

And it's like the DevOps again, you're really getting this
feedback and providing it back and automating, automate,

Bret: You're also creating a little bit of empathy there too.

I imagine when you're watching someone else work through the problem.

Yeah.

Brian: Yeah.

And that you can see the hate directly in their eyes when,
they have to like manually copy something here and there.

It was like, Oh yeah, I can see that pain now.

Very clearly we have a couple more questions popping up here.

Huh?

Bret: Oh, which are the best procedures to agree and SLI SLO with the dev team.

Brian: That's a very specific question.

And I would recommend you read the SRB book, but you have to
understand really what you're offering for your customers.

What's your SLA S hellos that's coming down on you
and that's how you calculate it down to your dev team.

And you build some some cushion in there for upgrades and some out outages and things like that.

And that's how you really calculate and you got to play
around with it, but it's not exact when you first started.

Bret: And it doesn't probably stay the same.

It.

But the change rate slows over time, I imagine, but it's it may change based on moving requirements.

That's for sure.

There is no perfect right.

Scenario in any of this stuff anyway

Brian: Yeah.

Google obviously has a whole division, probably just for this and to figure out your SLO and SLA

Bret: They're the think

Brian: team.

But

Bret: Yeah, they're the think tank, we're just, we'll let them do the
hard thinking and write the books and give away the free resources.

Brian: But the book has some great resources on how to calculate that.

So I can recommend that.

Just look for these chapters and I'm sure you can find that.

Bret: yeah.

Okay.

Yeah.

W biker is asking some specific Cade's questions that I'm probably not going to have the answer to.

Sometimes we actually have active troubleshooting, ongoing inside of chat and this a show.

So it's great.

I'm glad.

We got the regular showing up and bringing their problems to the community.

Brian: That's great.

And the people are answering each other.

That's good.

That's what community is all about.

And Hey, by the way, speaking of community.

So way back in our OJI, Dr.

Docker, captain days, I created my first Docker repo is the permit, this repo.

So I, I dockerized permit this.

I created one of the first Compose stacks for permit the us and Grafana and things like this.

I think Laura was actually the first one to be honest.

And I just came in behind her and kept on improving on it.

Anyway, I took that repo.

I made it open source and I really focus on documentation.

I help people can kickstart it and get up and running as quickly as possible.

And just this week at crest cross 3000 stars, to be honest.

And it's just a repo that I've, put together.

I don't really maintain much anymore because it's just self-explanatory documentation.

Bret: what'd you

Brian: yeah, it's quite nice.

Hey podcast listeners at this point in the live show , I had
technical difficulties where Brian could no longer hear me.

So we had to cut

Bret: Thank you, Brian so much for being on the show.

I'm going to share some of his links since he's not able to
share all these himself, but you saw me share his website.

I will also share his podcast, which he does on a regular basis called
TheByte B Y T E cause it's all about the computer bites and bits.

And then of course he has the two courses as well as other resources.

We were actually getting ready to show off his GitHub has to GitHub
repo, but he may have that on his website over at brianchristner.io.

.
there we go.

I want to thank you so much, Brian, for being on the show
and I'm definitely going to have you more on more often.

Cause we've got lots to talk about.

We didn't even get into some of the topics I wanted to cover.

We didn't get into the news of the day, which was at Docker, just
released the M1 general availability of Docker Desktop for M1

So that just released today.

So if you have an M1 Mac you now have a production or what not really
production, whatever, a released version of Docker Desktop waiting for you.

Which is great news for those of us that are interested in arm.

And thanks again, Brian.

Chat, everybody.