Coding Blocks - DevOps: Job Title or Job Responsibility?

Episode Date: October 28, 2019

We debate whether DevOps is a job title or a job responsibility as Michael finally understands dev.to's name, Allen is an infosec expert, and Joe wears his sunglasses at night.

You're listening to Coding Blocks, episode 118. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. Visit us at CodingBlocks.net where you can find shoutouts, examples, discussion, and a whole lot more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw.

This episode is sponsored by Datadog, the monitoring platform for cloud-scale infrastructure and applications, allowing you to see inside any stack, any app, at any scale, anywhere. And WayScript, a new way to build software that gives you flexible building blocks to seamlessly integrate, automate, and host tools in the cloud. And Educative.io, level up your coding skills quickly and efficiently, whether you're just starting, preparing for an interview, or just looking to grow your skill set. All right. And today we're going to be talking about DevOps and whether or not it's position,

a title, or role, or something else completely. But first, let's have a little bit of podcast news. And I guess I'm going to go first because it's my prerogative. I'm going with iTunes with Kev O'Kerr, Chase, and Matthew Summers. Thank you very much. We really appreciate that. Definitely. And then on Stitcher, we have Blocked Ticket. I like that a lot. I've been there.

We've had a few of those. So, as Joe said, this episode is going to be a little light compared to some of the ones uh you know leading up to this but we're basically discussing like uh devops and what it what it means in the world but basically like i wanted to give some background as to how this came about because where this whole episode is going to come from is from a personal pet peeve of mine. Where I've had discussions with friends and coworkers and whatnot where somebody will come up to me.

They'll be like, you know what? We need to hire a DevOps engineer. And I'm just like, oh. Like a little bit of my heart sinks. And I'm like, what? No. And so I've long held this belief or battle or whatever you want to call it. We'll see by the end of the episode where we all land, but I've long held this position that DevOps is not a title. It's not a job title. It's a function that everyone should participate in. And we've had some brief portions of this conversation, whether it be on air or in Twitter

or whatever, where it's like, oh, but you know, you're, what about like ops, you know, people in operations or it or whatever. And you know, but so that's what we're going to get into. So, so there's the framework of like some of the background behind it. And we'll go from there.

Yeah. Imagine, imagine you're at the office and somebody says, we need to hire a DevOps engineer. And Outlaw comes running across the room and is like, no, no, no. And then an hour-long conversation ensues. That's what this is. Busting in like the Kool-Aid man.

That's right. That's right. That's what I do on Reddit. Anytime someone says full stack on like Reddit or Dev2, I'm like smash. Matt, you know what? You should also share the link about that that you just did recently. I think – oh, no. That was just a tweet that you did. That was a tweet where you got irritated about people saying that full stack was a myth.

I don't know. Are you talking about the one yesterday or today? Right. Yeah. Yeah. It's funny. We all have, we all have those things that tweak us. So I think here's the first thing, right?

So knowing what this is, there's some people that have heard of DevOps or some people that haven't, but we should at least have a baseline here. So the very first thing that we need to answer is what is DevOps? So I'm going to go to this new relic page because they write a lot of stuff for, you know, automation and this, and they actually have an entire page dedicated to what, you know, DevOps and this whole notion of it. But there's some interesting history here. The word DevOps was coined in 2009 by Patrick Dubois, who became one of the gurus. So we have a starting date-ish, right? 2009. That's kind of interesting. That's 10 years ago now. Go ahead.

Well, I was going to say, it's also important that when we say that Patrick Dubois was one of the creators of the term, he's also one of the authors of the term. Like he's also the, one of the authors of the DevOps handbook, which we'll be going over at some point in time. So they actually, in that, in that book, they go over how the term came to be. Yeah. So in short, it combines the word development and operations, right? So dev ops. So we won't go too deep into this here, but I did want to read off this definition that New Relic even shared from Gartner. DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people and culture

and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology, especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a lifecycle perspective. So that was a whole bunch of words to say what devops is i still don't know well okay i mean the culture thing's weird like well okay but it's going to come back okay

i'm going to get to that i'm going to i'm so glad you said that i don't know if you see the excitement in my voice um but i have i have long been of the opinion opinion and and actually the devops handbook tells me i'm wrong but uh that that it's really more about finding ways to automate your your world right right uh whether that's the build the test the the deployment you know all the infrastructure, scaling out the infrastructure. But that view is not actually shared with the DevOps handbook. I think I would have been in that same camp, by the way. When I hear DevOps, I'm thinking of how do you deploy?

How do you build? How do you build? How do you stand up your infrastructure? How do you make sure it's running? Like all these, all these monotonous things that people tended to do themselves in the past, it's like automating the mundane out of your life is, is kind of how I've always looked at DevOps. And, and so like some of this, like the culture thing and some of those, they just seem kind of weird because it's like, wait, how is automation a culture?

And so I guess that's where I'm curious to see where you go with that. Do you want to skip to it now? I mean, we can, I don't know, Joe, what's your thoughts? Uh, um, I don't know. I still want to get my head around like kind of what we really mean by DevOps. So I want to get there, but I still am trying to understand what we're even really saying it is. I Google the same things. I see you talking about being a culture.

I know what I think about when I say I want DevOps or when I'm happy with a DevOps something or other. It basically means that I've got a nice continuous delivery delivery platform and it's reliable and I trust it. And when I think of kind of the opposite of that, I think about like kicking the can down the road, doing things manually, doing things because we don't have time now or because we're being scrappier in the name of being agile or lean. Sometimes we'll do things the same old crappy, inconsistent and manual way because, you know, as long as we think it's faster. And so when I hear someone say DevOps culture, I kind of think about pushing back on that and saying, no, let's take the time to get this done in like a professional and reproducible way.

And so that's kind of what I think about when we talk about it being a culture, but it's just so hard to define. But when you say that it's a cultural kind of thing, it's a company culture, then I understand why it makes sense to say that you can't hire culture. Just like you can't hire an agilista, right? You have to hire a programmer or somebody else. Yeah, that's actually a really good point, right? You can't hire a culture. You either adopt it or you don't you hire

people to fit the culture or sometimes enhance the culture yeah yeah so sometimes i think it's easier to describe it though if you talk about maybe like what it isn't okay because you're right it is it is it is kind of difficult like you know to describe what it is, but it's really easy to understand if you go back to the way we used to do things versus the way we want to do things. And I say that because sometimes the way we want to do them isn't the way we should. I mean, come on, man. We've all done that manual deployment. All right. So, I mean, think about it, though.

Let's go back to the days of the dot-com boom, right? And what did that mean? And, like, take, like, an honest approach to it. Let's honestly think about it and just brainstorm it out loud. What kind of things had to happen? And not just the project planning part of it, right? But, you know, the developers would would have to you know they would be given some kind of requirements but they would eventually build something

right and you know that something would be like oh hey uh it's going to require an apache web server uh or or it's going to require a webSphere or a Tomcat or something. ColdFusion. Yeah, okay, ColdFusion. There we go. It's going to need some kind of database, right? So, hey, I need you to, you know, here's a starting database that you could restore from, right? That's either going to be an Oracle or a DB2 or a SQL Server or something, right? And then it's going to be given to somebody

as a system administrator. It's going to be, you're going to tell him, oh, hey, by the way, go buy this hardware and stand it up. And this is the version of the operating system that I was using. If he's lucky, he's going to be told that. But definitely nothing about patches

uh or patch levels and you know other software he's really going to be given let's be honest he's gonna be told like hey this thing runs under ai x uh this version you know major minor version uh with db2 this major minor version and that's you know, that's about it. Go install it. Right. Go install that. No idea like what the, you know, credentials or security levels need to be right. Maybe like high level, like, Oh, Hey, this is the credential I'm going to use to connect to the database from my application. That's probably about as far as that's going to, that conversation is going to go. So then, you know, he's going to be responsible for setting that kind of thing up right networking engineers might be told like oh hey we got to add this new box to

the environment right uh you know if you were way ahead of your time you might have had security related people back then but let's be honest it was the 90s so you you didn't uh but you know going forward you know 10 years later you would definitely see where you would right so so now those people have to be involved to be like okay hey wait a minute whoa you you can't you can't leave that port open i don't care what the application is doing right so you see like all these different people that are involved, but they're involved in later stages of the game. Right. Like in that scenario that I just described, you didn't involve that sysadmin or that network engineer until it was like, here's my thing, go deploy it.

Right. Put it, put it on the website, make it real. Right? And in the DevOps world, though, and this is where the cultural part comes in, and this is why the handbook doesn't agree with my definition of just automating things where it doesn't agree, is you're involving all of those people earlier.

So the communication is happening sooner rather than later, and they're communicating and they're all contributing to the same automation goal. Okay. Right? Yeah, and they never go away. It's not just like some step that kind of comes and goes. It's like part of the process, and it's there forever.

Like, ideally, you're going to be automating security, you know, either scanning or something, you know, checks into the pipeline. You're going to be doing these kind of things like all along. And once you set it up, it keeps on with you forever. Not just like that one week you brought in that consultant. So we're basically saying here that the culture is getting everybody. Everybody has skin in the game, but communicating, right? As opposed to, hey, go run this task. Go do this, go put this out here, open up this port. Now people are involved and have some sort of input into the process is what we're saying.

Well, I mean, if you think about it, it makes perfect sense too. Because that other way I described things was basically like a waterfall approach to the deployment of your application, right? Like, well, there's nothing for the admin to deploy until the developers are done, right? And then when they're done, then we'll push it out to the production server and, you know, environment or whatever, right? Whereas today's environment is all about faster feedback loops, right? Whereas today's environment is all about faster feedback loops, right? We want to get things out in front of the customer sooner so that we can understand like, hey, did it work? Or was it a bad idea? And if it did work, what about it? Did they specifically like, was there any additional things that we could tweak? Right? And so those faster feedback loops

also require more communication and faster communication and communication happening up front. So just like we went from waterfall projects to agile, we went from manual deployments to this DevOps mentality. Okay, so let me throw us completely off the rails here with a sidewinder, and that's the cloud. So all of this stuff that you're talking about totally existed even up to five years ago, right? Like all these, all these, I don't know if you want to call them silos, but different departments, right? So you have your hardware department, you have your security people, you have your, your networking people, you have your developers, all that,

right? A lot of that's kind of converged in the cloud now because you have, like, are we saying that the definition of a DevOps person or somebody that's the people involved in DevOps, is it different now? Because you don't necessarily have those same groups of people managing hardware and infrastructure internally a lot of that stuff's virtual now right okay so so oh man it's almost like it's almost like an alley hoop and you just like set me up so because this has actually come up before like you know in that's a sports ball thing right yeah sports ball okay uh i think i think it's like the one with the big giant white ball that they use.

Something like that. Golf. Golf, yes. Oh, that's right. There we go. I was so close. But yeah. So, I mean, this has come up before where people have brought it up to me either on

a Slack or Twitter or whatever. And it's like, Hey, wait a minute, you know, you can't, you're still going to, you can't, um, like get rid of all those people. And you're not, you're, you know, you're not, it's not that it's not that, uh, you know, the developer themselves are going to be able to like automate everything away. Like, you know, everybody should be, should contribute to a part of the DevOps thing. And, and from my perspective as a developer, if that means that I can automate, you know, like, Hey, here's a Docker or here's a Kubernetes part of this puzzle, right? Then I should contribute that, right? But there are still going to be people that are going to build on top of that. Right. So, I mean, like,

for example, I don't know if you've bothered to look, but AWS is got, they, there's a lot there, right? Like it's not any small thing, right? So even if you were to say, okay, Hey, fine, I'm going to go and I'm going to set up a Postgres instance using AWS RDS. And, you know, I'm going to set up what I think it should be. And like, you know, I'm going to take a stab at, you know, what I think the subnets should be, the VPC should be, you know, all those different things, right? Somebody else, you know, that might have a grander view, a bigger picture view of the situation. It might be like, well, hey, that's cute,

but actually this is the security group that this thing should belong to. Let me make these changes. So everybody's going to contribute, but you're still going to have that same type of system administrator or same type of network administrator type of person and role

and mentality that's going to look at it from a different, come at it from a different perspective, right? And bring something different to the table, right? You're not getting away from all those things. And even though it's still virtual, it still has to be done. And by the way, it might not always be virtual too. Even in like an Amazon or AWS kind of scenario, if you use a VPC, you might have portions of that, of your on-prem network working with... The hybrid cloud. Yeah. And we've talked about even similar features that Azure has with connecting to on-prem resources. Doing something like Azure Stack. I mean, I guess the only reason I bring it up is, and I'm sure we'll have some information on this here in a minute, is it's really easy when you start looking at DevOps.

If you're talking about Azure things like ARM templates, right? You're basically telling it what the infrastructure is, right? You're telling it, I need these type of instances. I need this much compute, this much whatever. These services are going to run here. These are the networks that you spin up with all of it. So are we saying, because if we're kind of boiling it down to something like an ARM template, and I don't know what AWS calls theirs, they have like recipe type stuff too.

Formations? Yeah, cloud formations. Yeah, cloud formation. And then there's also Terraform, right? There's these type of things that exist that overlay all kinds of clouds. So my question is this, are we saying then that when you're building up these things that are essentially going to build up your infrastructure, because the whole point is infrastructure as code, right? Are we saying that you're going to have a security person involved and he's going to tweak this part of

the ARM template and we're going to have an application developer that only tweaks this part of the template? Is that what we're saying? Or are we saying that everybody's going to have their input and then there's going to be some developer that goes and makes this thing happen? then yeah, you would have people involved like throughout, throughout the life of that. Right. And so those other, those other people involved, they're going to be like, Hey, for your API calls, like specifically, like, here's how you're going to access that. Right. Like I'm going to set up the, you know, the, the secure, the proper security groups to allow this to come through, but this is, you know, how you're going to access it. Right. And so, you know, they're those, those roles now transition somewhat, uh, maybe even unbeknownst to them in a way that it's more like they're basically describing like, Hey, here's, here's the available API or how to access the API or

whatever. You see what I'm saying? Like they are involved and they are involved early and often and remain throughout the life of it right that that isn't going to go away it's interesting i i still it's harder for me to picture this in the cloud world than it is when everything's on prem right yeah that's what i keep getting stuck on is uh if i imagine like a small team like less than 10 people and you've got a product to say it's already running in the cloud it, it's just weird to me to think it's like, hey, we should all have a part in like, you know, moving this thing to Kubernetes or something. And like to think that all 10 people are supposed to run out and research that is just, you know, it's impractical. I don't think anyone's saying that.

But really, it's just kind of, I think it's more about speaking to the message that like, you can't just outsource DevOps to a a third party or one person like each person has to be involved and they need to own their piece all the way through to production so it's not that like 10 people need to go out and learn kubernetes but people need to know what ports what permissions uh what their you know application performs like and needs to perform like and is responsible for maybe what their key performance indicators are to know if their system is up or down or like it's not devops person's job to know if your app is healthy or not you need to provide that heartbeat and you need to be responsible for

communicating with whoever did set that up in order to kind of get those things working together is that kind of the gist just the things yeah i like a lot of the way you just worded that right because you know going kind of similar to your of things? Yeah, I like a lot of the way you just worded that, right? Because, you know, kind of similar to your previous statement about you can't like hire culture, right? You can't hire one person or two people and expect them to be able to do all of the DevOps related things for your entire environment because they're not going to know everything that needs to be done. Right?

Like that's why it's a cultural thing is like you said, Joe, everybody has to contribute their piece to the ultimate puzzle, right? It's not one. It's not a job title. It's not one person's thing to do. It's a,

it's a thing that everybody should contribute to and be a part of. I like that. But tell me this, there's going to be somebody that specializes in what this DevOps type thing looks like. Because let's take the heartbeat as a perfect example. That's one that I really like because a lot of times application developers, when they write their application, they write it in a way that assumes it works, right? Like, let's, let's be honest. Like you write your, your first e-commerce application. It talks to a database.

All your code is like, yeah, everything works. And then as more and more people hit your site or whatever it is, it starts going down and you start encountering errors, timeouts, locks, whatever. And, and then you start having to program defensively, right? Like check for this. Was there a problem? Retry, whatever. So this is where I'm kind of coming with the heartbeats is there's gotta be somebody saying that, Hey, in order for your application to be ready to deploy,

you need to provide us a hook that gives us a way to check the heartbeat of your application, right? Flip that. What if it was the other way around? Okay. What if, what if,

what if some network admin came up to you and said, Hey, look, ma'am. Um, so I took, I took the Docker image that you provided to us, and we're spinning up this other environment with it using that. Or maybe we're doing our own Kubernetes implementation or whatever. But hey, what I need from you is here's an endpoint that I need you to send a heartbeat to. So I'm going to provide that to you, right?

And based off of what I'm going to get from you from that heartbeat that you're going to send to the endpoint that I'm providing to you, then I'm going to know whether or not you died and I need to spin, spin up a new version of you or whatever. Right. Or maybe based on some latency, I can make a decision about like, Hey, maybe he's getting, maybe there's some kind of problem there or whatever. And I need to like start going horizontal or something. Right. Or whatever that metric is, you know, maybe, maybe part of it, maybe part of that heartbeat

includes like, uh, you know, utilization, some, some form of utilization that I might use to help determine that. Right. So in that, in that regard, you're just like basically throwing those, those heartbeats out there, out to whoever's listening. Right. But some network admin gave you the end point that he, the API that he wanted you to hit specifically, right. That you're just going to like fire and forget. Right. and then he's going to use that information to then decide to make decisions on like how to scale the app right i mean this is all like you know yeah i mean i think that's the thing is illustrating the point like there's got

to be somebody somewhere that says these are the things that are required for this to work. Like there's gotta be somebody that's coordinating those efforts, right? Like, it's not like you're going to have your network guy just talking to the app developer, right? Like maybe the network guy needs to be talking to the security guy. There's gotta be somebody that's putting this stuff together. And so sort of playing devil's advocate here, why wouldn't there be somebody that's in a DevOps type role that knows how to put all these pieces together? No, no, no, no, no, no, no, no, no, no, no, no. Like I said, playing devil's advocate.

There's got to be somebody that has that higher level picture that says this is how the pieces fit together. But that's only one part of the entire DevOps picture. Totally, totally. But it's a one part of the entire DevOps picture. Totally. Totally. But it's a big picture. Big part of it, though. Yeah. But we agree that automating the build is a part of that.

So now do you expect that network? Would you expect the network administrator to be responsible for that? For automating the build? Yeah. Why would he have to know? The DevOps guy would. Or Gal. Or Gal.

Or Gal. Or Gal. No, or Gal. Why would the DevOps person in your world have to be the expert in also everything related to security, everything related to networking, everything related to the operating system, everything related to how to build your application, everything related to it? That's what I'm saying. You as the developer can do your part to say, hey, here's the template, right? You could provide a Docker image or a Kubernetes, you know, file or a Docker composed file or whatever as a starting point, but they're going to come in with their own expertise to add on top of it. So everybody's contributing a little bit to this ultimate reality, right? And in that example, that network engineer, I'm not going to expect him to know or even care how to compile my application, let alone run the unit test for it.

And I think we can all agree that that is at least the easy version of, you know, one of the easy parts to the DevOps world to wrap your head around, right? Yeah. Well, maybe you should explain that because there's probably a lot of people that are still working in situations where they don't have anything automated, right? I mean, there's plenty of places that have not invested time in automating anything. So maybe they don't understand what you're talking about. Right. So maybe it's worth talking about a little piece of that in terms of like the

build and the deploy and what that means and why, why an application developer could easily be in charge of that and not a, a DevOps engineer or something like that. If that's even a title, which I'm sure it is, right? My guess is... It pains me when I see it as a title. I was going to say, I would lay money on the fact that if you went out and looked on LinkedIn

jobs or something, there's probably plenty of DevOps engineers type positions around. Every time I see that, anytime I see a job listing for a DevOps engineer, I always think to myself, they're doing it wrong. Because basically, the way I interpret that is they're asking somebody else to come in and figure out how to compile their code or deploy their code, right? And it's like, and in my mind, I'm like, well, why don't you,

why isn't everybody contributing to that? Why does it become that one person's responsibility to figure out, oh, Alan wrote some code. Now it's on me to figure out, hey, why won't this compile on another machine? Hey, how come when I run it on this other machine, it gives me a runtime error? And that's why I'm saying if you had provided some of those, hey, here you know, here's a Docker compose for it, right? Then you can at least have a starting point. Well, I think like someone needs to know what options are even available. Like if you aren't in this world, then you may not really know what heartbeats could do for you, right? So it's nice to have someone who kind of has that to drive it.

I don't think it necessarily needs to be that role. Maybe SREs like site reliability managers or engineers are something that's maybe a little bit closer to that where they're not DevOps, but they kind of have more of an ops kind of breadth of knowledge. Like I just know for me, like I don't have the knowledge to know that Helm charts. I basically know the name Helm charts. I don't know what they do. I don't know the knowledge to know uh that helm charts i basically know the name helm charts i don't know what they do i don't know how they help i don't know what problems they solve or you know there might be problems i have that i don't even recognize that maybe i need helm charts for maybe that's totally inappropriate for me but somebody needs to to know that stuff and at least know enough to see that and recognize that there's things out there that need to be researched and i just don't really know how to delegate that without kind of literally delegating someone or something.

It's kind of saying like, I want you to be kind of lead on this thing. So you talk to whoever you need to talk to, but somebody needs to kind of drive this boat. So by the way, what he just said, I think is how people end up with the title DevOps, right? I think it's not because it should be a title because I agree with you. Like, I mean, so I've done DevOps type things right off the back of other people that have set up a lot of these things. And, and I agree, the developer, whoever's involved in whatever project should also be involved at that level. But I also think that what Joe just said is why it happens. Because ultimately, there's going to be, if you're in an organization that has absolutely zero automation, zero deployment stuff, zero anything set up, right?

It's still very much a manual thing. Hey, you want to deploy your app? Okay, go build it in the thing. Copy the binary somewhere and do it, right? It's still very much a manual thing. Hey, you want to deploy your app? Okay, go build it in the thing, copy the binary somewhere and do it, right? There's going to be somebody at some point that's going to get fed up and be like, I'm sick of building this thing 12 times a day and giving it out to somebody because I'm wasting time, right? And then somebody's going to go research it and they're going to get a lot of knowledge either in something like Azure DevOps or TeamCity or Jenkins or one of these other platforms. Right. And then at that point, at that very point is when somebody becomes a DevOps engineer because, oh, you need to know how that thing's being built and deployed.

You need to go talk to Outlaw because he's the one that set up the build and the deployment server. And that's, I think that's why I know you get frustrated with it, but I'm all, I'd lay money on the fact that's why this title exists because there's somebody that can come in and say, Oh, we need to automate things. I know how to do Jenkins. I know how to do team city and they can go to town and it's not two weeks worth of research to be able to get the first build up and running right and that's why you end up with that title it's specialized knowledge right like i mean but i don't want it to be specialized that's the thing

but it is the thing but but it's not though i mean like hold on. Let's say that among the three of us, because I've seen the stuff that we've done over the years, right? And I would say to our credit that the three of us, I think, do help contribute to the bigger DevOps picture, right? Like you might, even if we don't give ourselves the credit for it, you know, I've seen the three of us will provide like, hey, here's the Docker Compose file. Here's a Kubernetes file.

Here's the Docker image that I'm using for this. Here's the scripts to do this. In one way or another, or we've actually gone out to like if it was a specific tool that we were using, like you mentioned TeamCity before or Jenkins. Like, hey, here's the specific tool. And I set up, I automated this thing. Right. Um, you know, so, so, and, and to my point, like that to me is, is good. Like everybody's contributing a little bit, right. It doesn't fall on one person's shoulders to like carry that entire burden alone. Completely agree. Yeah.

Because that's where, that's where it frustrates me when, when I see it as a title, as a job title, instead of like something that everybody should do. Like, you know, you wouldn't expect one person to have the job title of,

uh, I don't know, pick something silly. Um, Oh, geez. Uh, stack overflow searcher, right? Like if you have a question to go that you want to Google or, or, you know, like, Hey, go to Joe because he does all of our Google searches for us. And, uh, you know, or like, he'll do a stack overflow search

for you. If like you wouldn't hire that, right? Like everybody's going to go and be resourceful and figure out like if they need to search out how to do something, they're going to go and do it on their own, right? Well, that's what you want. In my mind, this is similar to that, right? Like you're helping others in that respect. Okay. So maybe that's kind of the point there is like you want a team of people, those 10 people to constantly be asking how can we make this better? And if that means going out and researching to figure out why, whatever, like you should eventually stumble upon Helm charts if you need kind of communicating with your team and like always trying to do the next best thing in order to kind of automate or monitor or whatever

your, your work life, then maybe you will hit this stuff eventually. Well, I mean, let's even take it a step back. Like you might, you might decide like, okay, Hey, for my application, I want to use certificate based authentication using X five or nine certificates. Right. And, and you know, you provide your way of doing it, right? But I'm not expecting you to become a certificate... Guru.

Yeah, overnight, right? So you might have somebody else on your team that fits into that SecOps kind of role, they will be like, okay, here's how we're going to provide those certs for that authentication to you, right? Like, that's cute that you had your way that you were doing it for development purposes,

but in a production environment, this is how it's really going to happen, right? And, you know, yeah, I can't figure out a better way to describe that. I mean, here's the thing, right? I think, so what we're saying is a bigger part of DevOps is the culture of communication and people working together to create whatever the end product is. But along the way, there's the technical know-how and abilities that are, that are specialized,

right? It's, it's, it's like the difference between somebody who is an expert in SQL server versus somebody who's an expert in Oracle, right? There's a different set of tools. There's different programming syntax for the stuff.

Just like if you get into the world of automation, which is a part of what we're saying DevOps is, right? I think the key is, is when you say DevOps, if it truly encompasses culture, security, continuous delivery, monitoring, alerting, all that kind of stuff, that's a whole bunch of stuff, right? But when we start talking about when somebody gets shoehorned into a DevOps role, we're really talking about people with the knowledge to work with the tooling, right? The build servers, the continuous delivery pipelines, the, man, I'm trying to think of anything else that would come in it. Like some of the security things, access, hooking it up to source control. Like I think that's where, and it's probably because it's been coined,

a DevOps engineer, that's really what it boils down to. It's like, you know, we're full stack guys. All three of us are full stack guys. But it's easy when you see somebody who's called a front-end developer or a React developer or a JavaScript developer, right? There are also people that are C sharp developers or Java developers or whatever.

That's kind of how I see this DevOps name is right. I think, I think what you've talked about so far opens up my mind a little bit in terms of what it means to, to invest in DevOps, but I can still see where you say, Hey, this guy is specialized. It may be DevOps is the wrong name. Maybe you say this guy's a, an Azure pipeline expert, or this person is a team city guru, right? Like, I think, I think that's what most people

have in their heads. You know, like anytime you hear somebody say something about DevOps, what does it always come down to? Like, I know, I know we all have the same thought in our heads outside of like researching. Like, what are you usually thinking about when somebody's like, hey, we need to get some DevOps in place? Yeah, you know, I guess the more I think about it, it's like someone feels the pain. Someone's doing that manual deploy.

Someone knows that they're doing something manually that shouldn't be. And maybe that's the person that needs to solve that problem one way or another. That's where the change needs to come from and be driven from. Because the ops work has happened. The DevOps work, in fact, is happening. It's just not happening as efficiently. And I'm willing to bet that if you're doing one of those tasks manually, then you've got to know that there's

a better way out there, right? But you just said the same thing though, right? Like when you hear the word DevOps, you're thinking building automation, more or less, right? You're thinking of... Yeah, but I mean, that was me 30 minutes ago. Now I'm coming around. No, but I mean, that was what triggered. Anytime somebody's like, hey, we need to get some DevOps working. Like, we need somebody to focus on DevOps. It's almost always something around automation and deployment, right? I mean, we agree on that.

That's like, typically, if somebody says the word, we need somebody to focus on DevOps. What does that mean? I mean, I would agree that we typically think of the, you know, DevOps tends to manifest itself in the form of automating something. Right. Right? Is typically how we see it. Right? But, like, if we were to back up and maybe think like, Hey,

how did we ever get here? Right. Like how, how did this even start? Um, you know, go back, go back several decades and think about the way, like if you were to log into your favorite Unix platform and you wanted to compile something there, right? You typically included a make file with it, right? Like, you know, that was typically part of it. And that make file gave instructions on how to do, you know, to make the, to do the compiling, maybe to do a clean of it, maybe to do an install of it, right? So you can almost look at that as like an early predecessor to the ability to automate portions of it, right? Because now that you have it as code, it's very easy for all of us to be able to wrap our heads around like,

oh, hey, well, if I'm doing it on a Unix box, then, you know, that's a very scripty friendly kind of environment, right? I could script something out that could SSH it to another box, that other box could run on some kind of a cron job to, you know, hey, look at this input. If I get a new version of the file, then let me make it, let me install it. And boom, now the app is updated on that one, right? And you can like, and that's in a very batch kind of way, right. Where it's just going to run on some kind of a schedule, right? Like, like imagine, imagine 40 years ago, if you had like 10, 10 servers, cause you were like way ahead of your time if you had 10, but, um, you know, and, and you're like, Hey, uh, anytime we get a new application, this thing would just

be automatically, uh, you know, secure copied over, right. S SEP over to the other boxes. And those other boxes would be set up to just automatically, Hey, look for a new version of the installer in this directory. And if I find it, unzip it, make it, make install it, and, you know, make, yeah, I said make install already. So, right, so you could kind of already see in that type of world where I described, like, how we could iterate our way there, right? Now imagine if I gave you all that same source code, and yet you had to figure out that make file. Right? Would you hate me? How much would you hate me?

I think is the question. How much would you hate me if I said, here's all the source for the application. Why are you mad at me because I didn't give you the make file? I gave you all the source. Right? That would be a ludicrous statement. Right? Like nobody would stand behind that.

Right? statement, right? Like nobody would stand behind that, right? However, let's fast forward to 2019 and you live in, and your team lives in a world where maybe all of your source code is in, say like an Azure DevOps, for example, or even like a GitLab, for example, has similar functionality where, let's say, specific to the Azure DevOps world, you can include a YAML file that describes how to build that application. Right? Now, in my 40-year-old example, you would have been mad if I didn't give you the make file. But what happens in 2019 if you don't provide me with that YAML file? Is that acceptable? Shouldn't be. I need Docker Compose up.

Right. Exactly. Exactly. Great point. So the point there is that environments like GitLab and Azure DevOps and others, and even Amazon has a similar build service. You can provide a file that describes how to build the thing. And depending on the environment, it can actually be more specific than just the build. It could include the deployment of it, which is similar to my make install. Right. So, so, and that's just a part of it. Uh, you know, and so to Joey's point about the, the Docker compose, right? Like that greatly simplifies your ability to like spin up. You no longer need an, um, you no longer rely on an ops guy to, or an it guy in the department to be like, Oh, Hey, uh, Joe just started. Let me spin up a server for him. Hold on a minute. I got to procure the hardware. I need to, uh, install the latest version of windows. Oh my God. It's still

doing windows update. I'll get back to you next week when it's done. Okay, now I got to install SQL server. Like, you know, all of those kinds of things, right? Instead, now that same IT ops engineer can just be like, hey, here's the Docker file that we use, the developers are using. Or maybe the developers gave him a starting point and he like fine-tuned it or whatever but it's they're all still part of the same puzzle i mean there's even even a simpler one that anybody that's working with something like npm it has its own config.json or whatever right and when when you add dependencies to it you can say you know save or save and then dev and then that way when you go do anybody that goes to start up the application, I guess this is where everybody should be involved, right?

Because this is part of it. Like we all remember the days where you onboard somebody new to your company and it's like, dude, I got a wiki page over here that's, you know, 15,000 words long. And after you're done with this, you should have our application up and running. Right. If you start putting some DevOps love on this stuff, then hopefully that goes from a 15,000, you know, word document to where it's like, yo, dude, clone this repo and then, like you said, Docker compose up it. Or NPM init it.

Or NPM install it and then run it, right? I mean, I'll do you one better. In our world, I actually scripted it. It was like, hey, here's a repo, right? You don't even have to clone the repo. You can just copy the files down locally. But one of them is a config that you can say like, hey, what are my favorite? Here's the applications that you need.

But if you have any favorite code extensions or whatever that you want or other favorite tools that you want, you can add them to the list. And that thing will set up your environment for you, right? Install all your favorite stuff on your brand new machine that you just got, but it'll also get you the repo, get it set up for you. Now you're ready to run the application. So, I mean, that's a great example of where we're diverging from this whole notion where DevOps is just building and deploying, right? We're now talking about, hey, you're a developer. You want your system running?

Boom. Go run this, right? Like, go ahead. I was going to say, I've got a bunch of stuff on the next section that I wanted to get to, so don't steal my thunder. Okay, I won't steal your thunder. Actually, we should probably break and then come back to it. This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end

visibility quickly. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. Try it yourself today by starting a free 14-day trial and also receive a free Datadog t-shirt when you create your first dashboard. Head on over to datadog.com slash codingblocks to see how Datadog can provide real-time visibility into your application. Again, that was datadog.com slash codingblocks to sign up today. All right. If you haven't already left us a review,

then we would really, really, really love it and appreciate it. If you did, go to codingbox.net slash review and click one of those links and leave us a review. There's iTunes or whatever they're calling it now, Podcast. We'll have some links there. Also, there's other ways to do it that don't involve installing whatever it's called now. So we've got links there. And if you feel so inclined, uh, just know that we will love it forever. We'll love you forever. Thank you. All right. And with that, we will head into my favorite portion of the show. Survey says, all right, I saw you, Joe.

If you're wondering what I'm talking about, you'll have to watch this on YouTube to see what Joe does when I say it and what I do that he's mocking me. All right. So a couple episodes back we asked, Would you be interested in doing a Coding Blocks Fantasy Football League? And your choices are... How has this not been a thing for six years? Yes.

Yes. A thousand times yes. Or... Sportsball? Please. No. And lastly... A fantasy game for soccer?

Silly Americans. All right. I think Alan went first last time. So, Joe, I'm going to let you go first. Which one do you think would be the top answer and by what percent? I think that the top answer is going to be, how has this not been a thing for six years? Yes. With 79%.

79. Okay. 78. 78. I'm shocked. 78? 78? Okay.

Totally shocked by your answer. For sure. You got to be the change. But it's not the one you agree with necessarily. I mean, I know what I would want, but I think that people are going to say sports ball, please. No. And I hate that because I want it to be the first one. I'm going to go with 40%.

40%. So, Joe says, yes, house has not already been a thing for six years at 78%. Alan, Mr. Negative, says no. Just no. At 40%. And the survey says... You're both wrong. No way. What? Yeah. Fantasy football. 40% in the survey says you're both wrong. No way.

What? Yeah. Fantasy football. Are you silly, Americans? Are you serious? All right. That was the one. Yeah.

I appreciate that. That was the top, 43%. That is shocking. I love it. I love it. Now- Right answer. To Mr. Alan Negativewood. No, what is the second? 40?

No, it was like 37. That was close. Hey, that's pretty close. Hey, so for all of you people that like fantasy football out there, I'm the one that wanted this survey. So we only need 10. So if anybody wants to play fantasy football next year, I'm addicted to it.

I will play it. So, you know, hit me up. We will make this happen. All right. And so I'm thinking about what you want for a prize. Oh, man. Well, I'm going to win. I guess I'll just figure it out. Oh, okay. Yeah. I'm going to win. I guess I'll just figure it out.

Oh, okay. Yeah. I like the confidence. That's right. All right. Well, for this episode's survey, I forgot to do one. So we'll just say then, we'll keep it on topic then with this one and say, do you agree with Outlaw or not? Yes or no?

Or maybe? What is Outlaw's? That DevOps, do you agree that DevOps, well, how about we just word it as, is DevOps a, and then we'll say a position? Or I'll just say,

hold on, we're going to do this on the fly. Let me type this out. I like it. All right. So, so erase, erase, erase. If you've ever heard of that comedian. So the thing will be, is DevOps a dot, dot, dot, A job title. Hiring now. Or is it a job function? Whoops, I spelled that wrong. Job function. Get back to work.

How's that? It's one of the two. It's either you think it's a job title that you would hire a person to do full time, or it's a function of everybody's job. Just do what you need. Right. All right. I like it. This episode is sponsored by WayScript.

WayScript is a new way to build software. It's a drag-and- drop programming language that runs in the cloud. Wayscript removes the complexity of integrating with third-party tools and APIs all in a flexible environment with full programmatic logic. And when we say integrating with third-party tools, there's a lot of them. I mean, let me just run through a quick list here. Let's see. You've got Bing integration, Excel integration, Gmail, GitHub. What else have we got? Well, what's some big hitters who get all of everything that you would want to do in the Google world? So Google assistant, calendar sheets, you got hacker news, MailChimp, Reddit, Slack, because everybody loves Slack integrations, you know, creating custom Slack bots. So you could do that. You got Spotify, Twitter,

you know, just to name a few, right? So there's a ton of integrations right there for you. You can create and share your favorite scripts today by signing up at wayscript.com slash coding blocks. Also, feedback is super appreciated.

So there's a give feedback link right there in the top right hand corner of every page or interact with the developers in the Discord channel that's available at the bottom right of the page. So they are seriously looking for everyone to provide any kind of useful information back to them because they really want to make this platform just amazing. And in that vein, they also have multiple open source repos that you can contribute to to make it better. You know, and when I was talking about all the integrations, I forgot to mention that, like, you know, it doesn't have to be a, quote, integration to a third party necessarily. Like, hey, you want to write some JavaScript?

Boom. They've got you covered there. Oh, you want to write some Python? Boom. They've got you covered there. Oh, you want to write some Python? Boom. They got you covered there. And hey, if you can't come up with like what you want to write and you need some inspiration, they have ready-made templates available for you at wayscript.com slash library. And speaking of those templates, I set up one to grab all the CodingBox tweets,

my personal tweets, to see which were more positive. CodingBox won that one. So that was pretty funny to see. And it was really cool just to see how it operated. And now I'm actually working on automating the contest that we run. So I'd like to import a list of emails. I'm going to do a little custom Python script there to pick the random number of winners and then do whatever I can just to make that easier because I'm a programmer.

Why not? Yeah, i totally forgot to mention uh you know i i actually did some automation some scripts too to where like i can get a daily email just tells me what the weather is going to be so i can know like you know right away as i'm brushing my teeth like oh uh here's what the weather look is going to be like for the day when the sunrise sunset uh you know humidity and all that kind of stuff, as well as, here's the big one, here's the top five Reddit articles to read on slash programming. Very nice.

Hey, and like they mentioned, you can go to wayscript.com slash library for those templates or just go to wayscript.com and click the link there at the top of the page that says templates. But better yet, let's not just go straight to wayscript.com. Let them know that you came there through coding blocks by heading to wayscript.com slash coding blocks. And again, that URL is wayscript.com slash coding blocks. All right. So now we'll talk a little bit about what it takes to get into DevOps. But before we get there, I wanted to touch on something that just happened.

So Molly Struve, for anybody who hangs out on DevTogether, dev.to, Molly Struve is a popular author over there, and I'm a huge fan of hers. I always wondered why it was called Dev2. I did too. Oh, yeah, yeah. I never knew that. Well, so Molly Struve writes a lot of articles about site reliability engineering, SREE, Elasticsearch, operations, key performance metrics, things like that, measurability, observability. And so I've been following her for a long time now and on Twitter too. And she's just officially joined the DevTogether team as their first and their lead site reliability engineer.

And so I've been doing a little bit of reading kind of on that role and like what that means. And to me, it kind of picks up on a lot of things that are part of kind of DevOps culture, but they're kind of the other side of things. Because so often, and we're doing it tonight when we talk about DevOps, we're talking about continuous deployment. But a big part of that that we kind of forget about a lot of times, that just gets kind of like lost a little bit because we focus so much on the first part, is that of observability and the actionability of what comes after you're actually running. Like, how do you know whether your features are being used?

How do we know if your servers are running? How do we know if something bad is happening on your site? How do we stop it? What do we know if your servers are running? How do we know if something bad is happening on your site? How do we stop it? What do we do once it goes wrong? And so I really like kind of thinking a little bit about that sort of thing. And so I just kind of wanted to bring that up. I thought this was like a kind of a good, good point to talk about because it just ties into a lot of other things that I think of as being DevOps-y, but are like kind of obviously more centered around the specific roles. Like if you're implementing a feature, obviously you're the one going to be adding the feature flag. So you're going to need some sort of orchestration piece

for that, dealing with that setting of that flag or taking it back or maybe rolling it out for some people, not others and measuring that and reporting that. But I think of all that stuff as being kind of tied into DevOps. But I haven't seen a lot of that being written about in terms of or classifying that as DevOps. So I was curious what you all thought about that. Go ahead. Wait, I'm trying to wrap my head around the question again. Oh, do you consider observability, measurability,

and just kind of operations of your production environment wrap my hand around the question again. Oh, uh, do you consider observability, measurability, and, just kind of, um, operations of your production environment to be part of DevOps? Uh, yeah. Yeah. I think so too.

Uh, like, why do you think that there's so much focus on the kind of the build pipeline and you don't hear as much about the other side of things? Because that's our circle, our bubble? Okay, yeah, I think that makes sense. Well, I mean, it's easy for us to grok because it is the world that we live in daily. I think to Outlaw's point, yes. I think – so the three of us are in the process of building a SaaS-type product, right?

And I think once that thing turns on, then we will probably be very much in the world where we're looking at the things that you're talking about, right? Like the heartbeats, the logs, all that kind of stuff. So to your point, the world that we live in right now is we're all about, hey, when we make a change, we want this thing to be deployed. We want to see it live. We want all that stuff, right? Yeah, but we still won't become network engineers, experts. We still won't become SecOps experts,

InfoSec experts. I mean, I'm not saying that we won't be doing our darndest. I mean, I will be. Yeah, right? Right. Sure. I mean, I didn't mean to include you in that.

When I said you, I meant Joe and I. Right, right. Yeah, sorry. Sorry for that confusion. Thank you for clarifying. So the reason I bring it up is that I think that part of this is that because kind of DevOps is still kind of a newer concept in programming. These things take a while to go. And I think that there's kind of this notion of maturity in DevOps.

And so I think a lot of times it starts with you getting those builds integrating continuously and then leads into testing and then into deploying. And you have to kind of do all these things before you get to that other side, right? You can't monitor things until you're like reliably getting them up there. So I think that's part of it is I think there's just a lot less people that have kind of gotten to this good side of things. We're still kind of getting there. But also I think that this side of things is particularly hard to kind of gotten to this good side of things. We're still kind of getting there. But also, I think that this side of things is particularly hard to kind of learn on your own. If you want to learn, you know, Vue, then there are 10 million articles that will tell you how to get started with Vue.

And you can get very specific about the little things you want to do, like SVG animations with Vue or, you know, whatever. It's very targeted. But when it comes to dealing with graphing your number of orders and setting up an alert if the number of orders goes too high or too low, then

that's something that's very specialized. There's not many people doing that because they haven't reached that point in maturity. You just can't really run off and do that stuff on yourself. You need to have real-life streaming data before you can even work on work on that, right? That kind of goes back to what I said earlier too.

And it ties in perfectly with it is you build stuff. As developers, you typically build things assuming that they'll work, right? It's only as time goes on that you find out these things that you know that you need to look for. Like you said, somebody that's not worked in e-commerce, you go and naively write an e-commerce application. And at the beginning, it's going to be fine. But as you start, you know, like imagine Amazon, right? Like I forget there was, you remember when it went down for like 15

minutes, there were all these articles about how many millions of dollars they lost per second. Right. The thing is, until you get to a scale or you get to some sort of level to where you can actually start seeing trends like, why did my orders drop off? I was getting 100 a minute, you know, most of the time. Why did it drop to two a minute? Right. You only find out that you need to look for those things when those type of events eventually happen to you. And so it is a maturity thing.

It's an experience thing. There is another approach that you could take to it, though. Machine learning? AI? No, no, no. I like where your head's at, though. But no, you could take the Netflix the netflix approach with the chaos monkey right that's just you know imagine imagine if you if you weren't in the cloud you had a server room

and you just let a monkey go in and like you know bounce around and pull cords or whatever cables right and the netflix approach to that was okay, let's create something that will just randomly create chaos in our infrastructure that is in the cloud and make sure that our environment can sustain those types of random outages by having things automated in a way that it'll be like, oh, that went down, spin it back up over here. That's also another level of maturity. It is. It is. That's kind of why there is. It is. It is. And that's kind of why there is such a dominant player. Right.

I mean, it's the other side of this is it's like you said, it's super hard to know what to do there because it's incredibly difficult to simulate. Right. Like you don't know what you don't know until it happens. Right. Like you don't know that your server is going to get deadlocked transactions. Like, man, that never happened before. All of a sudden our traffic doubled and now we have these issues, right? And so then you find yourself putting things in that say, all right, if I see this, then do this, right? And it's after you've hit that level, hopefully you do reach that level to where your software has enough success to where you have to deal with that.

And then you start looking at things like these heartbeats and all that. But I also want to bring up, one of the reasons why we've mentioned Kubernetes so much on this is because it's sort of like the, I don't know, is it what we want to call it? The popular way of doing things? The big daddy?

It's, man, if we're counting lines of code, I think it counts as the biggest. Yeah, it's pretty close. What, two million? I don't know. I can't say how many lines swarm is. Let me see. Maybe we can find out.

I think Kubernetes is specifically, or one of the reasons this is so exciting is because you can do that on your own on a single computer to get started. So it's really hard to spin up 12 different cloud services and turn them off and on and see if they work or not without spending a bucket of money. If you've only got one server, good luck with that semi-army, right? But Kubernetes is something that you can start with now and you can get started cheaply like five bucks a month all you need is like a simple linode server and you can get going on this and publish your site it's not going to be very good it's not going to perform nearly as well as if you just kind of deploy it manually but it is something that you can do today to get started

so if you wanted to kind of start building your DevOps muscle, then that's something that you could absolutely go buy a course on or read an article and get started today. And that's been rare up until recently. Well, one of the things to add on to that that is so cool about Kubernetes is it sort of brings in a lot of everything we've talked about so far, right? So, so like you said, it's kind of hard to do the heartbeat and the site reliability type stuff and all the metrics and all that. If you just go deploy your thing out, you know, you set up a server and all that, because you have to build all those pieces into your application. Kubernetes kind of gives you a little bit of everything. So yeah, so you can stand up your infrastructure with code. So there's your build and your deployments.

Like you could have your application gets built, right? Then you have something that will deploy it into an image, a container image, so that it can then run on Kubernetes. Well, then once you have this thing set up to where it's running on Kubernetes, it's already got stuff built into the Kubernetes platform to be able to look at heartbeats, to be able to ship logs, to be able to do all that kind of stuff. So one of the reasons why we've been talking about it so much is because they've kind of, I mean, Google has been a thing for a minute or two, you know, since they've built, you mean being, yeah, being, um, they built Kubernetes and open sourced it. Right. And they ran into a ton of these problems and

they realized early on, they needed ways to find out is my service alive? What's going on in my service? You know, how do I track this stuff? There's dashboards for it. Like there's all kinds of things you can do. So I wanted to call that out. Like we've said it a lot in this episode. And that's one of the reasons is because it gives you a lot of tooling and it's already there. Yeah. I mean, there's a Stack Overflow answer that I'll include that is the accepted answer. And this was from a couple of years ago. And at the time Kubernetes was like 1.2 million lines of code versus Docker, not swarm, but just Docker was over 200,000 lines of code.

And because the question was, Hey, why is Kubernetes source code an order of magnitude larger than other orchestrators? And you know, the the the answer was talking about like well you know there's a lot of bloat can coming from other supporting libraries but it's also way more feature rich to your point um than others so you know but yeah i mean it it's since you know gone eclipsed two million lines, so this answer should be updated.

Oh, Lord. We talked about Docker for developers in April of 2018. And at the time, I remember feeling – I absolutely felt bait and switch. I was like, I learned Docker. I fell in love. This is great. And I go to deploy it, and everyone's like, you've got to learn Kubernetes now. And it was frustrating because I felt like, oh, Docker did all the things that I need.

But now that I've learned more about the space and got more experience, I absolutely see, like, oh, there's a lot more to really running in production and deploying the whole pipeline. Even, like, rolling upgrades is a great case where, like, if you need to upgrade the software and you take Node one down at a time. And there's just a lot of complexity there. And Kubernetes deals with that complexity and it provides templates and kind of actions and almost like interfaces around common type actions that need to take place. And so I think any company now that's starting today and is looking to go to the cloud and is looking at growing and building, scaling to a billion users, I think Kubernetes is going to factor into that. And so I hate to say it because I felt like with Docker, it's Kubernetes is going to factor into that. And so I hate to say it because I felt like with Docker, it's like everyone needs to learn Docker. And now I'm saying like, yeah, well, now we all need to learn Kubernetes too.

But it just makes so much sense if you're going that direction. It's obviously not everybody. If you're doing desktop software, it's not that big of a deal. But the good news here, the thing I'm kind of clinging to is that kubernetes is right now something that you can pick up and learn today this isn't that's not behind behind some like giant paywall like the the cloud has been for so long and so i'm really excited about it and i'm also scared and terrified don't know enough about it you know our friend john he he made a great point he was like you know the way way to think about Kubernetes is it's like spinning up your own cloud.

It is. You know, I mean, if you really wanted to think about it, right? Like, you know, because you could spin up your entire application in Kubernetes and, you know, but yeah, we're kind of a little bit off topics, but, you know, yeah. Kubernetes. Kubernetes, awesome. Docker was yesterday's news. No, no. No, just kidding. Or they use No, no. No, just kidding.

Or they use containers. I'm just kidding. So going back, I wanted to wrap all that in because, you know, again, I think Joe hit on a very good point in that there are a lot of sides that aren't just building and deploying, right? There's the stuff after it's running what's happening. It needs to stay running, right? That's part of, of this DevOps culture is, Hey, how do I know when it's dead? How do I know when I need to spin up another one? How do I know when the load has exceeded my capacity and I need more infrastructure, right? Like there are so many bits and pieces to this whole DevOps world that is just insane in scope. It's, it's hard to keep up with. Yeah.

Like how do I know if my AWS bill is going to be three times what it was last month? Oh God. Yeah. That can happen too. So, uh, I put together a little list here. I'm actually, I went through the DevOps checklist from DevOps checklist.com, which was put together by the, some of the writers of like a DevOps handbook and a Phoenix project. And I put, I plugged a couple of those out and added my own, just we don't have to go through all these, but I just kind of wanted to say like,

you know, we talked about DevOps kind of being like a maturity scale. So I kind of wanted to look at, it's like if you were kind of working on a web develop a web app, you know, today, right now, if you're trying to kind of gauge where you're at and how far you have to go and or and if you have nothing you know to start with like basically how you would kind of get

started and if you've already started where like kind of what your next steps are i thought i thought it might be kind of cool to breeze through these a little bit but some of the early questions on that i came up with were basically just dealing with continuous integration. Like, are you building on every commit to master and does the build block when the build fails? Are you running tests? Things like that.

Rhetorical. Am I supposed to be answering to any of these? No. No. And, um, but if you want to jump in on something, please do.

Um, I mean, it's definitely like, you know, you, you want to jump in on something, please do. I mean, it's definitely like you mentioned building on commits to master, but even better than that, all of the environments, GitLab, GitHub, Azure DevOps, I mean, you can build on pull request. So before it even gets to master or whatever your branch, you know, mainline branch is, you can build and know whether or not it's going to work and run the test for it. In some environments, you can even like deploy an instance of that branch out to see like for others to be able to see like, hey, this is what it would look like.

And, and one other thing to add to this too, this also goes back into the culture thing that we talked about before is when you first start doing this stuff, there will be pushback, right? Oh yeah. Like,

are you building on every commit? Can a pull request be merged in before it's successfully billed? Will you allow pull request if the unit tests haven't passed, right? You will get pushback. I didn't even touch that project. I don't care if it fails. Right. Yeah, but the rest of us do.

So even this very beginning that we're talking about here, this is where like, you can start making the culture see the value, right? Like, yo, if this thing fails and the pull request gets merged in, you're going to break every single developer that pulls this branch next. Right. And you'll get pushback because people will be like, I don't want to wait five minutes for my, for my PR to get merged in. It's like, wait a second, dude. No, no, hold on, dude or dudette. Hey, this is helping everybody, right? This isn't to stop you from being able to do something. This is to ensure that everybody is able to work all the time. So, all right. Well, what do you mean you can't wait five minutes?

Yeah, it's ridiculous. But hey, oh, by the way, though, I mean, we keep talking about build, but like I've actually been in environments where the your pull request can fail because of other metrics, not not necessarily compilation. But you can have like maybe style is one. Like if you didn't if you didn't adhere to whatever the accepted style is... That's really lame, by the way. Well, I mean... There's formatting tools for that that you can plug into your source control system. Yep.

I don't disagree that you could automate that, but I have seen environments where it's like, hey, we gave you the tools to automate it and you didn't run it, and you still try to commit it anyways. And so we're failing it. You know, a good one is if we go back to something like independent or sonar cube is something like the cyclic complexity.

Complexity. Yeah. That's not quite where I'm going. But that could be one. If it goes above a certain number, fail it. Right. But that could be one. If it goes above a certain number, fail it, right? Like, hey, you just introduced some crazy complexity to this particular file, class, whatever. Well, where I thought you were going to go was on if the code coverage drops, right? So, in other words, you set some minimum threshold for the accepted code coverage that you have tests for.

And if you were to introduce a large body of new code that might lessen the code coverage percentage, you could fail the pull request. I'm not as on board with that. Because you obviously haven't included tests to cover that new code. Yeah, I don't love that one as much. I think when we went through the clean code, clean arc, I don't remember which one it was,

but the whole thing of testing your public APIs is more important than testing every little individual thing like that. I'm still torn on that one. I still don't know where you draw the lines. I mean, you're assuming that the large body and new code that you introduced was all private. Just saying. I don't know that I love that.

That would still mean, though, if your code coverage dropped, it would still mean that you have private code that none of your public methods are running through that your current tests cover. And so that's what it's trying to capture is that you, you're, you're testing. It's the 80, 20 rule for me. And this is, this is completely off track,

but I mean, that's what we do best. Right. But it's test the code that is being used the most, right? Like if you're writing unit tests for code that gets hit once every million tries and that million tries over a year period. And it's like, okay, what value did you add?

So I'm not as huge of a stickler on code coverage as I am just making sure that the things that are important are actually being done. Well, I mean, you could still say, though, like you could say, hey, our code coverage percentage is, you know, 50%. Like 50% of the code has to be covered by unit tests or we won't, you know, allow new code in.

Yeah. Right? So now you introduce a large body of new code. Like you're like, hey, Outlaw, here's 20,000 new lines of code. Right? And the code coverage now, you know, but there were no unit tests to go along with that. Right. And even though it might have been like all private functions and now the code coverage drops to 48 percent. Yeah. Right. Yeah.

I mean, still, it does illustrate the point, though, that there are multiple things that you could use to to look at your code and determine whether or not should I go on, should I not? Yeah, and you can decide what's right for you. Like maybe, you know, you're willing to slip on coverage for a little bit, but it doesn't mean that you have to block at this step. Right. So, you know, we're talking about quality metrics.

It doesn't mean that you can't deploy to production until you get 100%. You know, you can mix and match and do what feels right for your team. But kind of on that note, like our other KPIs for production. So I've put this one in next. So I put this even before you're deploying to production. It's just figuring out what your key performance indicators are.

Maybe it's number of orders per hour. Maybe it's CPU percentage. Or maybe it's, you know, average request response. Like what metrics matter to you and how can you get those? I was like, I figured that's something that you could get even before you start automatically deploying to production just to know, you know, what kind of the baseline is. And, uh, you know, that kind of goes along with getting basically ideally one spot to view them all. I know that that's tough, especially if you're talking about like orders and CPU,

like getting those into one dashboard, like that's, that might take some work or be out of your hands, but, uh, you know, it's a nice goal and it's nice to know at least where your holes are. If there's some key performance indicators that are critical to your business that you can't see, then that's a pretty big problem. Right. Well, and that can also help define like, okay, well, when do you start to scale horizontally right so that like the cpu utilization might be one or you know i mean when you look at utilization factors it could be cpu network or disk memory response times yeah i mean there's a whole bunch of different things in that regard that you you could use as deciding factors or maybe a combination of them to say like

okay add one more or add two more or whatever, right? So, deploying after every bill, that's kind of an obvious one. Do you have a disaster recovery plan? A lot of companies don't. A lot of organizations don't. And then even after you have the plan, there's, of course, actually testing the plan, which I've got quite a bit further down on the list because I know how scary that can be. But, of course, you can do whatever matches for you.

Of course, you should have all this stuff all the time before you even code or whatever. But we know how things are in the real world. And so whatever makes sense for you, we all have stakeholders that we have to be held accountable to. That's an important one. I don't know that I agree with that last statement though, where you said that like you should have all of this. Of course we should have all of this ahead of time. I mean, I think we've all like grown up to now understand like, Hey, you know what?

It's impossible to ask for it. And even if we did have it by the time we would get it, it would be outdated. So it's better to not even try to aspire to that goal. Like why waste the time? I think it depends on what you're doing. And I think I either heard something or I read an article about this. If you are writing a service, and this was the example that was given, if you're writing a service that people can upload their family photos to and you are their backup mode, you better have a disaster recovery plan in place because people are trusting you with their life memories, right? So if they're giving you money and their data and you don't have a disaster recovery plan in place, that's wrong, right? Like morally you live first. Let's start trying, right?

Let's get it out there. And then, you know, maybe we only introduce it in the beginning to close family and friends with like, hey, you're going to lose everything. You know, we're still iterating towards making this better. But, you know, hey, there's this one checkbox that we haven't gotten to yet. No, that's fair. Know that that's there. That's fair, but I guess what I'm saying is... So it could still be in production use,

quote production, but what do you call it where you limit... Closed beta. Yeah, exactly. Closed beta. Right? Yeah. I mean, that's fine. What I'm saying, though, is be aware

of what you're making, right? Yeah, I mean, that's fine. What I'm saying, though, is be aware of what you're making. Right? Yeah, it all depends. Right. It all completely depends. You know, there are certain things that you need to take more seriously than others. Right? Like, if you're just doing the next, you know, car club on people who own the new Toyota Supra, then, yeah, you probably don't need a disaster recovery plan.

Right? Yes, it is sick. But on the flip side, you know, it's very well played. Know what you're doing. All right. I just,

I just been like, you can find someone on Twitter that will wag their finger at you for it. Just about anything. Like, yeah, there's people who work at Google on a thousand member teams, whatever. And they'll say,

what? You didn't have your, uh, you weren't HIPAA compliant before you launched your Supra app? Like give me a break. There's just all sorts of different orgs and you really can't compare someone that has 1,000 employees to a team of three. Definitely. The needs are different.

The ways you need to work together are just all different. There's also some out there, though, that work for these large teams like your 1,000-member team that you just mentioned where you might be able to afford like, hey, you know what? This team of 200 people out of our 1,000 are going to focus solely on these aspects of our DevOps world. But I still can't get behind it, but, but it exists. It exists. I'm not fan again. Deep specialization.

Yeah. Specialization. I think specialization in the tools makes sense, but the overall overarching encompassing thing of who needs to be involved. I think you're right. I think everybody should have their hands in it. That's what drives me nuts. I got it. You know, I got to go there when people think everybody should have their hands in it. That's what drives me nuts. I got it.

When people hate on full stack developers because they're a specialist, there's people like Jeff Atwood wrote Stack Overflow by himself. Was he full stack or back? Was he back or front? It doesn't even make sense, but it just depends for everywhere. It drives me nuts to see

people who have dramatically different experiences telling other people whether or not they're a myth. Right, right. Especially when you know that you're one of those because you've got experience in Elasticsearch, C Sharp, JavaScript, SQL. Now, he's a unicorn. Look at him. Joe's a unicorn. Look at him.

You can see the rainbow dust just like every time he like wipes off his shoulder like a little bit of a little bit of rainbow flies off yeah feature flags is one thing I wanted to bring up because I just think it's really cool like I you know launch darkly is company that does specializes in feature flags and like a lot of people when I first heard

about I was like okay that sounds like settings to when i first heard about i was like uh okay that sounds like settings to me but when i heard about all the different things that they can do with feature flags like being able to turn them on and off at runtime or turn them on for people on the west coast or the east coast or 10 of your users and and tying that into the metrics that you get back so you can say like i'm going to start rolling out this feature slowly and if it's successful and it doesn't fail then maybe i'll continue otherwise maybe i'll roll back and be able to control that stuff outside of the application is really awesome. But that's something that you don't get until you're like far along in the maturity process,

right? Yep. And that's part of your DevOps thing too, that we're talking about because typically how you deploy that stuff, how you flip those things on and off is, is very much part of that world. Well, I mean, they actually talk about that in the handbook too, which they describe it as like your feature has been out in production long before it actually gets used. You just have it turned off by some kind of a toggle. I think they were actually referred to it as feature toggles. But you have the feature

turned off so that you can keep integrating it into the application, right? So that sooner rather than later, you're like, you could imagine a world like, you know, like picture a long running branch, right? Like what would be easier if you could go ahead and merge that thing in sooner rather than later, but the code just not be live yet. That's not getting hit yet. Or, you know, a year later you have to do a merge, right? You have to do the merge. Right, right. I have to do the merge for you, right? Like that, that's just an awful environment, right? So, you know, they describe it like, you know, you kind of already have some ideas. Like, hey, is this thing even going to compile? Right?

Because you're like, oh, of course it is. It's already been out there a lot. It's already been in the running application for a long time. It just hasn't been getting used. Right. So, which, by the way, we mentioned before, like, the DevOps handbook is on our agenda at some point. I don't know when we'll get to it. Hey, wait.

You skipped over the SLO. I don't know. Yeah, I kind of covered it. Service level objectives. So if I say, like, I want all page requests to be finished within 200 milliseconds, something like that. You basically have some sort of SLA. I want to have such and such latency or so many messages delivered per minute or never more than this backlog, whatever.

I didn't know what the O was. The book we're reading next, we'll talk about it quite a bit. Data Intensive Applications. Do you have a post-mortem process in case anything goes wrong? It's an if. If anything ever goes wrong not a win yeah because it's never going to go wrong right and this one really should be way at the beginning but uh are all your

configurations basically versioned and encrypted and you're able to kind of like see inspect rule keys all sorts of stuff like that that depending on what you're doing, that should be way sooner in the process. Dude, I will say on this note with configurations, I never had sat down and thought about how complicated that can be because you can either have configurations as code that gets stored as files in your repository. You can put them in a database and centralize them that way. There's so many different ways you can attack configuration and they all have wide reaching implications of what, what route you choose. And there are actually tools. I want to say that, um,

new relic actually has tools for that. And there there's, there's tons of them. Like configuration management ends up becoming a problem when you start really getting deep into automation and that kind of stuff. So it was pretty interesting. There's some – what am I thinking of for New Relic? What's their main product or something? There must be something that I've heard of. Are they Ansible? That name sounds familiar, and I can't place it.

I don't know either. It's going to eat at me. Here are products. Here we go. I don't know. Yeah, I looked, and I was like, I'm not seeing it. I think it's like logging and exception handling. Oh, okay.

One thing that we didn't touch on that much that I also thought was a big part that in this whole DevOps world is this constant feedback loop. So they talked about agile in, at least in the new relic article about how agile is part of the whole DevOps thing. And really what they're talking about is, Hey, you want a fast feedback loop. So if somebody decides that they want a new feature in your software, right, and that might be coming from the business, and as a development team, you're able to get that in place in three days. The fact that they can see it quickly is a big deal, right? So that's part of that culture thing of it's not necessarily the agile methodology it's the whole thing of hey we want something you can see it quickly because we've enabled it through you know this mixture of development

operations you can now once this code's done you'll be able to see it somewhere maybe it's on a dev server but it's not something where it's like oh we're gonna have to get the build team in on saturday to do this then we're gonna have to get it deployed out. It's this constant feedback loop, which we've talked about as iterations in the past, but DevOps enables you to do that. Having that culture allows you to do those things quicker. Yeah, one other thing I wanted to mention too, going back to a conversation earlier,

we were talking about the ability to script out or automate the dev environment system. We didn't mention Vagrant. Have you ever heard of Vagrant? With Vagrant, it's a tool where you can build and maintain virtual development environments. Whether it's like VirtualBox or Docker containers or AWS,

you can spin up your environment. I have heard about them, and it's been a long time. Instead of like Docker run or compose up, it could be vagrant up. Yeah, I see that. Yeah. Cool. Cool, right? I thought you might like that one.

I thought it might be interesting, you know, as we wrap this up, though, to go through some of the myths of DevOps that as outlined in the handbook. You want to do that? Let's do it. All right. So tell me what you think. All right. DevOps is only for startups. No, it's a lot easier.

Yeah. So much better. They don't have those. There's so many things like whenever you get some DevOps magic sprinkled on, it's like so much better. And you're like, why didn't we do this sooner? Right. Yeah.

The newer ones don't have the old bad habits or just old habits ingrained into the culture. So for a startup, it's easier. But no, it's not just for startups. I think that's really the key is the old habits. People just, oh, this is how we do it. Right, right. We just always build the app, and if you see it, then right-click and say publish, and then here's the IIS server that you're going to publish it to.

Yep. What a disgusting way to even think about deploying your app, right? Oh, man. All right. DevOps replaces Agile. No. Sounds like it's a part of it. I mean, it seems like they're good friends. Yeah. I mean, to your point that you made

earlier, right, was that it's part of the fast feedback loop or feed book loop as I almost said. Those are good ones. Okay. This one I had to like, I'm going to make sure I had the definition because I was like, what? What? All right.

So DevOps is incompatible with ITIL. I don't know what ITIL is. Thank you. All right. ITIL is Information Technology Infrastructure Library. Still don't know what that is. Right? Okay, good.

Yeah. Yeah. So Wikipedia says it's formally an acronym that is a set of detailed practices for IT service management that focuses on aligning services with the needs of the business. Great. So the point is DevOps is not incompatible with that. To your point, it's about that feedback loop again. It's all about trying to align these things

so that you can get faster feedback loops and, you know, hey, is this working? Or, hey, I've got an experiment. Can we try this? Can we see if this is even, you know, worth our time? What's next?

DevOps is incompatible with information security and compliance. It's way better. Yes. I think that was the official answer in the book. Way more better. Way more better. Yeah. You do it all the time.

You're not trying to chuck it on in the end. Like, okay, we got three days to figure out if and how to make it sound like we're hipaa compliant and in this one or this one i really like because this one kind of drives home uh you know maybe i should say this one for last no i won't uh devops means eliminating IT operations or no ops. No, it's mo ops. Also the accepted answer in the book. More consistent and reproducible ops, I would say. Yeah, it's more like they say instead of IT ops doing manual work that comes from tickets,

it enables developer productivity through APIs and self-service platforms that create environments, test and deploy code, monitor, display production, telemetry, and so forth. Yeah.

Think about how nice it'd be to have, like, if you do have ops people now be like, instead of them doing your deploys, they're, um, tracking and monitoring and learning whenever the response times go less than this,

or they're alerting if new products aren't being sold or, you know, just stuff like that, that would help the business more. Yeah. Uh, so myth number, uh,

8,000, I wasn't counting. Um, D dev ops is just infrastructure as code or automation. Before this podcast. Yes. Yeah. Now I think it's culture.

Honestly, even before the handbook, right? Because I definitely was of the opinion like, hey, when I think of DevOps, I think of automating things, right? Yep. And I still largely feel that way, though. But I do believe in the culture part, right? Yeah. I think, again, it just goes back to vocabulary and how people communicate that. And typically, when they say that,

that is what they're referring to. Yeah, so the way the authors of the handbook word it is, while many of the DevOps patterns shown in the book require automation. DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. I like it. Right? So, yeah. And that was a key part that we haven't even hit on really, was that the architecture of your application needs to allow for this, right? So that's a whole mindset right there to even consider as part of it. All right.

The last myth, DevOps is only for open source software. No. I don't think that one's a myth. I think that one was just true, right? Not even close. Oh, I got that. They tricked me. Yeah. no i don't think that one's a myth i think that one was just true right not even close oh i got that they tricked me yeah so uh i i totally look forward to going through that in that book in a deep dive though it's free for a lot of open source like uh like circle ci's uh what's the

javascript cypress free for open source oh yeah yeah. Yeah. Um, even, even, um, like platforms like Azure DevOps that we've talked about earlier in the show, they have, uh, you know, one of the, one of the tiers for Azure DevOps is, um, you know, if it's a community or free open source project, then, you know, you can use the tooling for free. And even if your business, uh, pays for Azure DevOps, if you have projects that the business does that are in the open, then they can use Azure DevOps for portions of Azure DevOps for free.

Yep. So in terms of like parallel builds and deployments and whatnot, so, uh, not to mention, you know, the capabilities of like get hub or GitLab or whatever. This episode is sponsored by Educative.io.

Every developer knows that being a developer means constantly learning new frameworks, languages, patterns, and practices. But there's so many resources out there. Where should you go? Meet Educative.io. Educative.io is a browser-based learning environment allowing you to jump right in and learn as quickly as possible without needing to set up and configure your local environment. The courses are full of interactive exercises and playgrounds that are not only super visual, but more importantly engaging. And the text-based

courses allow you to easily skim the course back and forth like a book. So there's no need to scrub through hours of video to get to the parts that you really care about. And incredibly, all of their courses have free trials and a 30-day return policy. So there's no risk to you. You can give it a try and see if you like it. And, you know, last episode we were talking about trying to find, like, hey, what's going to be next, right? And just when I thought I was going to be giving Rust a go, they announced their latest one, Grokking Data Science. Like, how can you not give that one a go?

Well, the one I've still got my eye on is Machine Learning for Software Engineers. I was just looking at the stats on it. So there's 87 lessons with 8 quizzes, 115 challenges, 163 playgrounds, 2 code snippets, and 36 illustrations. And the illustrations are really, really cool. A lot of times they're

animated, just really neat. And you can actually see a lot of that stuff that's available, a lot of the content, just by going to this course. And you can get kind of a glimpse of what it's like. And if you think it's right for you or if you're just interested in it, you can give it a shot. And you've got the 30-day return policy if you're not feeling it. All right. Well, I'll see your 36 illustrations on the machine learning for software engineers and raise you 208 illustrations

on grokking data science because let's face it, data science is all about visualizing the data and understanding what's there, right? That's amazing. So start your learning today by going to educative.io slash coding blocks. That's educative, E-D-U I V E dot I O slash coding blocks and get 20% off any course. All right. So, uh, I hope you've, you've had an opportunity now to like hear my side of the argument as to, uh, uh, you know, if, if DevOps is a, a job title or if it's a job function. And you can let me know if I'm wrong by emailing Joe at, or just hit him up on Slack and he'll let me know.

No. All right. So with that, we'll have a bunch of links for the resources we like related to this episode. The DevOps Handbook is absolutely going to be in that but the book that even came before that uh the phoenix project which is by some of the same authors which basically is like a um a story version of of devops will be in there but there's some other links as well. And with that, we will head in. Whoa, whoa, whoa, whoa, whoa, whoa. Yeah, so I would say the Phoenix Project

is kind of like Office Space, but for DevOps and a book. So good, entertaining, but you also learn a few things. But really important, there's a new book called The Unicorn Project that is coming out really soon, November 26th of 2019.

That's the much-anticipated follow-up to the Phoenix Project. So I'm very excited about that, though I will probably wait for the audio version. Is this going to be on our shopping spree for Black Friday? Whoa, whoa, whoa. Yeah. Well, we've already got a link to it. You can pre-order the hardcover version right now.

Boom. Or the Kindle version. Kindle pre-order the hardcover version right now. Boom. Or the Kindle version. Kindle's much better. Won't hurt your wrist. I'll wait for Audible. DevOps Handbook is on Audible. Oh, nice. It is. Yep. All right. Well, now I can un-woe. What would that be?

Woo, woo, woo, woo, woo. How, how, how, how, how? Something. Yeah. And with that, we will head into Alan's favorite portion of the show. It's the tip of the week. I'm going first because I've got a scoop outlaw. Had to get in there.

Okay. All right. So I got this message. Oh, no, no, no. We're not doing this. Gary K. Ray. Gary Ray K. Thank you very much, Gary, for sending me a wonderful Git tip and sending it to me before using it to outlaw, I'm sure, because why would you send it to both?

So this is – I'm pretty sure it was sent to me first. This should be my tip. No, this is definitely my tip because i'm going first uh thank you gary ray k and this is a really nice blog post on how to write good messages and it's got a great example of the best alleged uh geek bit that this person ever saw and it's long you know so don't get scared but he talks about why this is so good and i got a couple of the reasons down here um basically it boils down to there being the reason for the change it being searchable which is something i never think about uh in terms of commits uh telling a story and it teaches and finally it builds trust well i don't care about building trust but i do think it's really cool that it's searchable and it just tells a story it tells you what the problem was how you

reproduced it why the fix was in there and it's just wonderful like if i saw this in history like you know i can imagine looking up the gifts like why the heck is oh but then you look at the commit that went along with this and it looks like uh it was pretty measly so it's pretty funny to see. It's basically a small configure change. I mean, it totally is. Yeah, it's tiny. The commit message is 20 times longer than the one line

change that was made. I don't want to burst your bubble, but he cheated on you guys with me, too. Yeah. So, Gary, we're on to to you we know you're double dipping but um you know thank you anyway and i'm glad that i got to uh present that get tip first no that was my tip thank you uh thank you gary all right all right fine uh on the fly let me pick up something oh hey here you go all right since we're talking about slack because that's how that one was given to us, by the way, if you want to, uh,

leave us any more, uh, you know, if you want to leave us a tip, you could hit us up on Slack and, uh, share your tip that way. There's actually a tips, uh, Slack channel, uh, where you can also maybe give it to me, but you could maybe give it to Joe or to Alan or secretly to all of us, and then we'll fight for it. There's also cb.show slash tips. Yes, there is slash tips. All right. So this one I'm stealing from Alan because I didn't realize this, but if you are in Slack and you're like, oh, man, I typoed it, and you want to, like, you know, fix it, or, you know, maybe you hit enter too soon or whatever,

you can actually – wait. It's just up arrow. Yeah, I took it out. It's just up. Oh, I thought it was control up arrow. You don't have to out. It's just up. Oh, I thought it was control up here. You don't have to do that. Oh man. Yeah.

I'm helping you out here. It's just up arrow and you can, uh, you, so you, you up arrow and it will take you to your last message to, uh, edit.

And I'm going to give you a link to, um, uh, Slack actually has a documentation, has a page of documentation where it has various commands without the keyboard shortcut. So I'm going to leave you that. It is awesome. All right.

So then, because it is my favorite portion of the show, I've got 20. All right. So here we go. So the first one, Dave Follett, super opinionated Dave Follett at this point in time, I'm sure it will change eventually. He had one that was kind of cool. And I'm just going to give you the title of this one. And we'll have a link in the show notes for it. You can integrate your Linux commands into Windows with PowerShell and the Windows subsystem for Linux. So it's basically, if I remember right looking through this,

the gist of it, it's almost like having wrappers. So you can actually access Linux commands in PowerShell, which is super cool for people who automate things in Windows. All right, this one, this next one, grew out of a pain that I was experiencing. So I was working on a piece of open source software and running things. And it was, I think it might've been an Ubuntu. I don't remember, but you know, like,

have you guys ever LSD directory and you'll see that, Oh, well, this folder actually points to another folder via symlink, right? Like you'll see an arrow and there'll be nice little color showing see that, oh, well, this folder actually points to another folder via a symlink, right? Like you'll see an arrow and there'll be nice little colors showing you that, hey, this isn't really the directory it points over here. So that's cool and all, but what you don't get is if you then cd over to that directory and you ls it, you'll see that it actually symlinks somewhere else, right? So you could actually have something in this case, it was Java and it was driving me crazy is it was actually sim linked like four or five times. And I was like, where's the end of this rabbit hole, right? Like at some point I got so tired of trying to trace down where I was going and losing where I'd been that I couldn't keep track of anything.

There's a command in Linux called read link that will actually give you the end of the rabbit hole. So if you are in a directory and you know that there's some links in there by doing an LS and you see it, if you want to know where that thing actually ends up, you can do read link dash F and then whatever the thing is that sim linked and it will show you the ultimate destination. Beautiful. Save me time. Save me the few extra hairs I still have left on my head. Hey, I want to just like, uh, give some more, uh, love to that one from, um, Dave. Yeah. Dave? Yeah, super opinionated. Super opinionated Dave, yes. Come on now.

He used to be super, what was it, nice? Super good. Super good Dave. Super good Dave. Now he's super opinionated, which I like both versions. I mean, show some respect. That's right. All right.

All right. But because what you would... I don't know that you gave this the credit, but this allows you to invoke your favorite bash commands from PowerShell. Yeah, that's what I said. That's what I said. I must not have heard that part, man. So I apologize. Fine.

Fine. You know what? Just call me Super Owned Opinionated Mike. We needed some more love on it. It is awesome. Like I said, for people that are automating things with PowerShell, but you want some of that Linux love, you can get it. But this was with Windows Subsystem for Linux.

Yeah, but that's the part that kind of gets me to those. Because usually if you're in PowerShell, you can automate all kinds of things in PowerShell, right? Because in PowerShell, you have the ability to use all your favorite.NET tools, even though you're a Go programmer or a Rust programmer. You still love.NET, right? I guess where this would come in super handy is anytime that you're on a Stack Overflow or something and they give you this Linux command, like curl something with and with like 20 other things at the end of it,

this would allow you to just run that. Well, my favorite is the lack of tail, right? Like you could do a get content dash weight in PowerShell, but this gives you tail. There's tail in that too. Yeah, that's what I'm saying. No, no, no. Get content, you can tail it.

Right. That's what get content dash weight, and that's what that'll saying. No, no, no. Get content. You can tail it. Right. That's what get content dash wait. And that's what that'll do. No, no, no. It has a tail feature too. That's what I'm saying. Yeah, that's what the dash wait does. No, no.

Dash wait follows. Dash wait is the equivalent of follow dash tail. Oh, I'm sorry. Yes. Yeah. Okay. The equivalent of tail minus F for the follow. Yes.

Right. Right. Right. Right, right. But usually when people want to tail something, they want to follow it. Or at least that's always been my default. I never want to just look at the end of the file. I do sometimes. Really? Yeah, on occasion.

Who does that? I do it. I want to see the last five lines that were written because I'm a psychopath. I do it. Hey, why do I got to be a psycho? Because only a psychopath would want to look at the last five lines. Of course, you want to see the next five also, and the five that are coming after that, and the five that are coming after that.

I just want to see what happens when... I want to look at a random piece of time. When it exited. That's all I care about. I'll break the tie. Alan, that is psychopathic. Jeez, come on, man. Hey, I know you guys. Jeez, come on, man. Hey, I know you guys have like a little shell command that's like tail last 50. I don't even want to hear about it.

All right. So my – hold on. What else do I have? Not with a dash F. Okay. So I have two more in here, guys. Like seriously, I have two more. So one, this is actually something that goes back to – I don't know if it was last episode. Yeah, I think it was last episode.

We talked about serverless was part of the last episode. Serverless. So one of the things that came up with this is we were talking about stateless, right? And it was awesome. So Devin Goble, a.k.a. Catch in Slack, who is an awesome contributor to that community, Azure has what's called durable functions, and they're really cool because it allows you to have stateful functions, which means that, you know, you could have functions that sort of communicate and operate with each other to get

things done. And there's a link to the page about durable functions. And the cool part is it has a bunch of different patterns. So situations where you need state and how that might actually help you out and how you would architect that thing to work. Things like function chaining, fan out, fan in. What else they got? Async HTTP APIs. So there's several on here,

but the key is there are ways to make serverless functions actually be stateful. So excellent, excellent heads up on that one. And then the last one, I'm only bringing this one up because I actually told somebody about it today and they're like, and I just said it in passing, you know, like, that's amazing. So I've sung praises about Connie Moo in the past and more recently commander, which is sort of like a rapper for Connie Moo with additional functionality. Well, the default theme, I don't know exactly which one it is. It's pretty decent if you're in your command line but if you like tailing the last 50 lines of a log like most normal people do and there's an error in there then usually the text is like a super dark red and it's really hard to see like it's

very difficult to see there is a theme in one. If you go to general settings or settings general, and then there's a section over there where you can choose your color palette. There's one called Babin or Babin. Say again. Babin. Babin. Okay. Whatever we want to say. It's B-A-B-U-N. It's amazing. Like it's still a darker theme, but they changed the color. So like errors are more of like an orange red. And so they stand out, you can read them. And then the other commands and Shelly type, uh, keywords stand out really nice. So, uh, just, you know, if you've been living with the other one and gotten frustrated by it, go into your theme and change it. I think I'm at the end. Yeah.

After, after we did, um, I don't even remember how long ago back it was now. Remember? Cause there was, we'd talked about over the course of several episodes about, uh, dark themes being bad on the eyes and everything. And I was like, you know what? I'm going to switch everything. So, so I i did right i switch i went from all of my favorite tools being a dark theme to undoing that and so specifically for commander i used uh solarized light as my theme of choice to be easy on the eyes yet not dark.

Yeah. I don't like that. And it's basically like a tan, a tannish kind of background on it. But I, I find it like super easy to read everything. Yeah, it is nothing. Nothing is difficult,

but your screen looks dirty. Like that's, it's weird. I feel like there's dirt on my screen. Like even when I did it, I was like, that needs to be washed. I'll break the tie. Yeah. Outlaw, you're a psychopath.

Yeah, right? Thank you. But I will say, though, like, I mean, do you think it was a year ago that we started talking about that? It's been a while. Like, I don't miss the dark themes now. And now when I go back and I look at some of those dark themes, I'm like, whoa. Because even like this one that you were mentioning, the baboon. Babin.

Babin. Whatever. Tomato, tomato. You know, I was looking at that and like some of the blues were like just – they just blended in too much. Right? blues were like just they just blended in too much right man i remember i remember something on color theory where they were talking about like uh blue isn't such a great color it's a it's a better color for backgrounds than it is for things in focus um which is crazy that like it's the default color for hyperlinks hyperlinks right you know what's funny though i i will say one of the things that's helped me out so

depending on on what i'm doing like sql server management studio still it has a dark theme it's awful like there's parts of it that still don't work one thing that actually helps me and i don't mind the bright stuff like the white backgrounds is turn down the brightness on your monitor. Like seriously, if you, if you cut the backlight on it, then it doesn't bother me as much. But I do find that when it's like a flashlight staring in my eyes, like I think Joe's right now,

he's staring into a flashlight and it looks like it's burning his retinas. Yeah. I can't see anything anymore. Yeah. So, yeah, I definitely do turn down the brightness. Yeah, mine's almost down to just about nothing.

All right. Well, with that, you can decide which one of us is the psychopath. Clearly, it's Alan. Right. And subscribe to us on iTunes, Spotify, Stitcher and more using your favorite podcast app in case someone

happened to like pass this along to you to listen. And if you haven't already, we would greatly appreciate it if you would leave us a review.

You can find some helpful links at www.codingblocks.net slash review. And while you're up there at codingblocks.net, check out our

show notes, examples, and our discussion and more. And send you're up there at CodingBlocks.net, check out our show notes, examples, and our discussion and more. And send your feedback, questions, and rants to, I can't read it, Slack. CodingBlocks.net slash Slack. And make sure to follow us on Twitter at CodingBlocks or head over to CodingBlocks.net

where you can find all our social links at the top of the page. Hey, wait, hold on. I wear my sunglasses at night. Yeah. So for those listening, Joe threw on some sunglasses and cranked up the brightness on his monitor. It looks like a welder sitting in his room. I was expecting either that song, that old song that you were just singing, or some kind of like, for him to come in and it's like, you're listening to the smooth

sounds of JZ103.3 WJZ101 on your FM dial. That's so good. That was good. Veteran nice. What is that, Probe?

Borat. Borat. Very nice. I wasn't quite expecting that laughter. It's infectious. That was so good. Oh.