DOP 99: Do DevOps Engineers Need to Know How to Code?

Show Notes

#99: In the nineties and early 2000s, it wasn’t strange to see operations people copy and pasting “code” from Word documents, also known as runbooks, into their terminals to get their job done. It’s now 2021 and we still have people questioning whether or not they should be writing code to do their work.

Hosts

Links

• DevOps20 Slack Workspace

Rate, Review, & Subscribe on Apple Podcasts

If you like our podcast, please consider rating and reviewing our show! Click here, scroll to the bottom, tap to rate with five stars, and select “Write a Review.” Then be sure to let us know what you liked most about the episode!

Also, if you haven’t done so already, subscribe to the podcast. We're adding a bunch of bonus episodes to the feed and, if you’re not subscribed, there’s a good chance you’ll miss out. Subscribe now!

Transcript

Viktor: [00:00:00]
Now we have DevOps as a movement, as a way of thinking that essentially says Hey you cannot do Word based operations anymore. That's basically what it is. We knew that before. Everybody was saying that long before that but now we have that movement and that is shaking the certain profiles within company.

Darin:
This is DevOps Paradox episode number 99. Do DevOps Engineers Need to Know How to Code?

Darin:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin: [00:01:23]
I was recently on Reddit and saw the question do DevOps engineers need to know how to code? And I thought to myself, yes, they do.

Viktor: [00:01:35]
It's a question with such an obvious answer, isn't it? It's the whole point. Dev and Ops. We write code that is reflected as our operational tasks. We develop operations.

Darin: [00:01:50]
What would be the opposite of that? If you're not writing code, are you writing Google documents? Word documents?

Viktor: [00:01:58]
Yeah. Word documents Maybe? No maybe. Man, it's 21st century. README files. No more Word documents

Darin: [00:02:06]
Well, if it was a README file, that would infer that you're actually putting it into Git, which would already be sending you down the code route. I'm just saying that if you're not writing code, then what are you writing?

Viktor: [00:02:20]
If you asked me that question like 20 years ago, I would tell you yes, there is unhealthy high percentage of sysadmins, operations, who do not write any code, are hardly even writing shell scripts, only when there is no other way to do it. But today, I guess if we would qualify writing HCL files in Terraform and YAML files and stuff, we would qualify that as code. I sincerely hope that absolutely everything is writing something that is interpretable by machines and stored in Git. The bigger question is whether that's enough. Whether you can just be a user of some tools that enforce everything as code which is basically almost all the tools right now or you now need to go beyond that and potentially create your own tools, extend existing tools and things like that. I think that that's the real question. Now, I'm pretty sure that there is somebody over there that goes to AWS and clicks buttons, but I hope, I'm not even going to say we are, but I hope that most of us are using something as code type of tools

Darin: [00:03:29]
It's interesting that you brought up HCL talking about Terraform. If you're doing Terraform correctly, you're just defining things and not doing the hacks that we've talked about in the past to where you're trying to loop over things.

Viktor: [00:03:42]
Yes but those hacks are often sometimes unavoidable even.

Darin: [00:03:47]
Correct. But if you're going down the hack route and you're having to quote unquote write code then Terraform may not be the right tool. That might be where Pulumi might be a better fit since you're not able to use Terraform the quote unquote correct way.

Viktor: [00:04:04]
Yeah but I could play devil's advocate and say that you cannot use Pulumi the correct way either because there is a declarative part of what we're doing especially with infrastructure. There is always something declarative and there is often some code as well in terms of not machine interpretable because in that sense YAML is a code but some conditionals and loops and what so not. So you could say the same thing for Pulumi as well. Actually, if I go to Pulumi website and I look at their examples, I would say Hey actually most of your examples are something that is well suited as YAML but you put it in Python and then there is this tiny piece over there. There is that small if statement or while loop that justifies it. Now I'm not trashing Pulumi. I think Pulumi is great but it's only code in terms of programming. No, it's not.

Darin: [00:04:58]
Yes Joe please come back with us again someday. If somebody was to become a quote unquote I'm using quote unquote a lot today DevOps engineer, what the heck is that number one, but assuming that we know what it is where should they start writing code? Is it bash scripts or a scripting language of some sort?

Viktor: [00:05:20]
Yeah if you're just starting I think that the best thing to do is to turn around to see what are others doing in your company, assuming that not everybody in the company starting which happens and then that's a really complicated situation then you should run away. If others are using Python, use Python. If others are using shell script, use shell script. That's all okay. You need to start somewhere. I don't have a strong preference what should be the first language somebody starts with. The more important thing is that for you to start. Now, if you're talking about infrastructure, maybe not Java, maybe not heavy languages like that but just start. Python. Shell. Anything. Go.

Darin: [00:06:00]
Your point that you made though is critical. Pick what other people are already using within the organization.

Viktor: [00:06:07]
Generally speaking what you want what I hope that you want is to be in a company where you're not left on your own. You want others to lift you up. You want others in a company wherever you're working your team to take you to the next level, whatever the next level is in your career. That really depends from one person to another and not leveraging your teammates for your own improvements would be silly.

Darin: [00:06:38]
The other side of that is you don't want to put your teammates at a disadvantage because you've gone off and done your own thing.

Viktor: [00:06:46]
That as well because Hey if everybody's using Python and now you're clever. You're going to write Go and nobody else wants to write Go, then you might have a problem. That is completely unrelated whether Python or Go or shell or whatever you want is better appropriate for the task. It is a team effort after all and others might need to work on top of your work and you will work on top of other people's work. It needs to be some kind of consensus about things, assuming that that's possible.

Darin: [00:07:18]
It's always possible. The question is is it probable.

Viktor: [00:07:22]
There are also cases when you go against everybody because you believe in something. You know that's the right thing to do and then by doing that eventually others might see the benefits of that and come to your side as well. It's not as easy as it's always a team effort. Very often improvements are also made by going against the current but it's whether even that is happening. I had to spend three months on my own ignoring everybody else to get to the point where I can show the benefits of that something that's a smell of something being terribly wrong in that organization. But if you go back to the question I think that the question was wrong. It's a question with an obvious answer. Yeah should DevOps people or people being involved in Dev and Ops code? Of course. The answer is of course. Yes. The real question is should every single engineer in every company working with software write code? I think it's a much more global question. Now we have the term DevOps just to enforce the answer to that question to operations, but I could say the same thing for testers. I could say the same thing for almost any other type of engineer. Should you write code? Hell Yeah!

Darin: [00:08:41]
Wow. That's an emphatic

Viktor: [00:08:43]
You just said the word I don't know

Darin: [00:08:45]
Strongly worded. Emphatic. Strongly worded. So you're saying testers need to be able to write code?

Viktor: [00:08:52]
Absolutely everybody working in software industry needs to write code or in some cases to at least understand code. I'm putting that exception over there to understand because okay if you're a product owner and that's your full time 100% job, maybe you don't have to write code but at least you need to understand, so that you understand what you're owning. Excluding management, yes, everybody writes code. You cannot have a company where increase in business requires equal increase in manpower. We probably agree with that because if you're a million dollar company, you probably have two millions in expenses. You're basically losing money. Your goal is to increase business and decrease the costs over time so that you become profitable. That's how more or less everybody is going through or wants to do. If you need one person to test 50 features that your applications have, when that application has hundred features, you will need two people. You will be always increasing the number of people exponentially or you will need to start skipping things. Hey, we cannot do full regression. How many times did you hear we cannot do full regression anymore because we are too big?

Darin: [00:10:18]
more than I can count

Viktor: [00:10:19]
Exactly and that's because you grew beyond what you can do with people with humans. You're probably in the situation that you grew but you did not start writing tests when there was time and now it's so big that nobody can write tests as code anymore and then you cannot do regression. You cannot test your system. You need to test specific features because your capacity is not increasing as fast human capacity as business which is normal which is how it should be.

Darin: [00:10:51]
What should happen in an organization that refuses to do that? They believe that they can scale linearly with a human.

Viktor: [00:11:01]
That company is bound to disappear unless it has some sort of monopoly so that they have guaranteed market share if you exclude those cases no matter what I do I will always have business that company will disappear It will become equivalent of I don't know of Kodak The problem is the monopolies though because if they are the only option, they're not going to go anywhere and they're going to continue doing what they've been doing, except doing it worse. But only for a while longer than they would normally do because even monopolies get threatened and broken sooner or later. Right now in Spain, I don't know how it's in US, there is a monopoly on internet that you need to have certain things that you don't need in order to get internet in your home. There is a certain level of monopoly even though there are multiple companies. What happens if Starlink becomes a thing for real? That I don't need actually that wire that is provided by one company, no matter which company I use as my provider. Starlink and I'm now talking about Tesla Starlink Elon Musk thing only as example because others are coming, they will break that monopoly. So sooner or later monopolies get broken and then there is absolutely nothing that those companies can do to survive unless they convince governments to do some nasty things that will keep them alive. You can say the same thing with banks. FinTech sooner or later will shake, actually it is already shaking the monopolies of banks.

Darin: [00:12:36]
Banks. Hedge funds. One word. Cryptocurrency.

Viktor: [00:12:42]
Now some attempts like that fail. Some are successful but sooner or later, no monopoly survives forever.

Darin: [00:12:48]
As people are moving into their positions and this question came from someone that appears to be probably newer. If they believe that they should not have to learn how to code, should they just move on?

Viktor: [00:13:04]
They should go somewhere else, move on somewhere else. I mean that I don't know like I want to be in Formula 1 team. Doesn't matter what's my role going to be there and I don't know how to drive. I mean is there such a person?

Darin: [00:13:16]
I'm sure there is

Viktor: [00:13:18]
Okay I stand corrected but uh yeah simply everything is code. Now we have DevOps as a movement, as a way of thinking that essentially says Hey you cannot do Word based operations anymore. That's basically what it is. We knew that before. Everybody was saying that long before that but now we have that movement and that is shaking the certain profiles within company. Same thing was happening with tests. Unfortunately I don't think it was really successful always but it will come again. It's like a tree. Every time you shake a tree, few apples fall down and sooner or later, you will be out of job If you don't code.

Darin: [00:14:02]
It's interesting that you brought up Word-based operations. Can you believe we actually even did that back in the nineties? The two thousands?

Viktor: [00:14:13]
Through

Darin: [00:14:16]
I contributed to that suffering I believe. Even when it was okay this will be hard but man it would be much easier if we just had a script to run and people made decisions not to even write a script because they said Oh no a human can check the boxes off on this Word document. Oh wait which version do they have? Well okay well I have this version but this wasn't the real version because actually we had copies of the Word document

Viktor: [00:14:42]
Even READMEs in Git are already an improvement on that

Darin: [00:14:45]
But that was assuming that you actually had some sort of version control

Viktor: [00:14:49]
Did you have those cases where you would copy and paste from Word document only to realize that Word changes certain characters like for example double quotes?

Darin: [00:15:01]
It added in extra words and that's the reason why I had I had a client at one time It's like oh yeah we do everything in Word. I said not any longer you don't. We're going to be using plain text for no other reason than that. It was like yeah but we can't format it. I went exactly. Okay. We've diverged way from here of knowing how to code. I guess a Word document because of the formatting is

Viktor: [00:15:25]
Yeah is if machines can interpret it, yes. I've yet to see some somebody uploading Word document to S3 and then that being converted into Kubernetes pods or whatever.

Darin: [00:15:43]
So as people start to learn code, if they're new into an organization, talk with the people in your organization and find out what it is they're using. If you're on the infrastructure side, are they using Terraform or are they using CloudFormation? Are they using Pulumi? Are they using fill in the blank? Start with that then if you want to experiment with the not what people are using, go for it. Then if you want to start going further down that route, start learning a language. Python is probably one of the ones to start with. My only problem with Python is getting the runtime right. That's where we're running it via Docker makes it much easier because trying to maintain Python on disc in these times is a pain. Especially if you're still running Python 2. By the way, Python 2 has been end of lifed in case you didn't.

Viktor: [00:16:38]
it. It's pre-installed everywhere

Darin: [00:16:40]
know but it's because that's what was still live when they baked that version of the OS. Okay. Do DevOps engineers need to know how to code? The answer is,

Viktor: [00:16:59]
there is no such thing DevOps engineers but if there would be DevOps engineers, they would need to know how to code.

Darin: [00:17:09]
and therefore there's the paradox.

Darin:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.