What is DevOps

[00:00:00]
>> So, if we start from scratch and we take the definition that we had before, well then what is DevOps, right? What is DevOps in the sense for us, right? And the goal of it really is to improve the speed and reliability of software releases by automating. Parts of the software development and deployment process, and by fostering culture of collaboration and experimentation among teams.

[00:00:26]
Now, I'm gonna pause here really quickly because one of the biggest things that people will make a mistake of even here is they'll jump on the automation. They won't jump on fostering a culture of collaboration and experimentation among teams. Because of that, if you just do the automation part, you're missing half of the solution, right?

[00:00:48]
This is why it's so crucial, to not just create automating parts that help you click a button faster and move through something faster. But it's also good for your teams to understand what that automation is. It's good for IT or QA to be able to look at something and say, okay, we automate this like this, we're all on the same page.

[00:01:08]
We're not confused by what's happening or anything like that. So again, DevOps is two things, it is first collaboration and essentially a joining of minds and the second one is programming which is the part we all love. So, what is it not, right? We said, okay, well, this is what DevOps is, well, what is it not?

[00:01:33]
It's not a tool or technology. I'm gonna say it 5,000 times. It is not a tool or technology. It's not even a job title or job description. I technically am not titled as a DevOps engineer. I am a senior software engineer. I did not want, in all seriousness, to have my title as a DevOps engineer because that doesn't really describe what I actually represent myself as.

[00:02:01]
I do DevOps, I follow practices and things like that, but it's not a job. It's not a tool, right? And it's not a standalone practice of one thing that you do versus another. It's a whole, again, ecosystem and much other things as well. Again, I'm just gonna say it one more time, DevOps is never tools or technologies, and thank you, Moss.

[00:02:27]
It really isn't. If somebody comes up to you in your company and says, hey, we really want to try this out to solve this problem, then you should say, okay, cool, remove the technology and ask yourself if we still have the problem, right? If we could do that, then we should be able to solve it with almost anything, right?

[00:02:46]
We don't necessarily need that one piece of technology. So again, DevOps is never tools or technologies, it's much more practice and theory and things like that. It's really a philosophy is what I'm trying to say. And again, it's a mindset that emphasizes collaboration, communication, and integration between software and developers teams.

[00:03:09]
So if you're at a company and maybe they're not looking at it as much of a philosophy. That's gonna be a barrier you're gonna have to hit first. A lot of companies do not fully adapt the philosophy of it, and so because of that, not really interest and adaption of the philosophy, it is so hard to do anything.

[00:03:33]
And this is something that a lot of DevOps engineers have dealt with too where you want to start, you get into a new company, you see all the things that you'd like to start changing. And as I said before, they're not drinking the Kool Aid. So, what do you do?

[00:03:48]
And this is another part of DevOps where it's up to you, if you want to sit down and say, okay, let's break this down and figure this out or let's just keep doing what we've been doing. And that's why you have to define your DevOps, right? We're not just generalizing DevOps here.

[00:04:06]
We're not saying that again, as I said before, it's something that you can take from one company to another. What you're really doing is is you're defining what DevOps means uniquely to you and the company that you work at, yeah.
>> So, how do you handle that fact of most places have different understanding of what DevOps is?

[00:04:24]
>> Right, the easiest way to handle that different understanding is really just being open-minded, being collaborative. If you go from one company to another, you can't be disruptive unless it has very good intent. And a good example of this is when I even joined the company I work at now, we migrated all of our services from GCP to AWS and we did it in about three months.

[00:04:55]
And we're talking about 60 to 80 services. And think about moving almost 400 people from one platform to another in three months, how do you do that, right? Well, you convince them. That's what you do, you sit down and you, again, break it down right out of the document, figure out ways of getting people to buy into the team DevOps isn't just programming, it's working with people.

[00:05:27]
It's getting people on your side so that you can do the programming that you want to do. If you don't have that, then that becomes very challenging. And so, if you go from one company to another, for example, you want to make a lot of change, that's good.

[00:05:41]
First, you're gonna have to get buy in. First you're gonna have to get comfortable with the people who I basically don't want you to break anything. But yeah, once you can get past that, then you can start defining DevOps at the company that you work at, yeah.
>> Earlier, I feel like you mentioned something about companies trying to put their own spin on DevOps.

[00:06:03]
I'm wondering how is that different from defining DevOps for yourself?
>> Sure, so, companies putting a spin on DevOps versus defining it yourself. Most companies try and define DevOps from a marketing perspective. So, companies like HashiCorp, AWS even, they're focused on developer tools, developer productivity, and stuff like that.

[00:06:24]
But the prompt is normally very contrasting. So something that you can kind of catch is, when you're looking at a product from, again, any of like these big cloud providers or anything like that, they're going to show you one way of solving a specific problem, right? But what we're saying is, is that we're gonna start with the problem first and then figure out the tool to get there.

[00:06:46]
So when you define DevOps, if it's being defined as a tool that's solving something, then that's where you kind of say, okay, well is this for me? Is this actually the tool we need? And that is, again, what's really kind of challenging about DevOps right now. Listen, I love a lot of the companies I've talked about.

[00:07:10]
I mean, HashiCorp is incredible, AWS as well as well as a lot of other these companies that have, literally said, we see what people are dealing with, let's move quickly. And that's why Amazon's got 9,000 different products that solve the same thing. But, their hope, and this is what they don't talk about, I think as much, is that they're trying to hit your target of your problem.

[00:07:35]
You know what I mean? And if they can do it with this one, then they'll do it with this one. And if they can do it with this one, then they'll do it with that one. They're just gonna keep making more tools to solve your problem. Whereas your problem might be quicker solved by just sitting down and writing it out and being like, okay, cool.

[00:07:51]
So, that's, I guess the contrast between the two is one will normally be focused on tooling, solving a specific problem. Whereas the other one is more focused on, how do we solve our problem and then find the tool for that.