- So a lot of y'all are tossing up between these
two different options of whether you wanna go down
the software engineering route or the DevOps engineer route. So today I'm gonna help
you make that decision. (upbeat music) Hey, what's up, I'm Will Button
from DevOps for Developers. And so first thing is if
you are leaning towards the software engineer route, because you aren't sure that
there is a valid long-term career in DevOps, be sure and check out the video that is up here, over here, that I recorded about whether or not DevOps is just a fad or whether it's something
that's here to stay. Now, if you're undecided
because you aren't really sure what the subtle details
and the distinction between those two career paths are, that's what we're gonna
cover in this video. In either one, you're gonna
be writing a lot of code. So technically you're a
software engineer in either case the distinction just comes into the details of what type
of code you're writing. And it's also important that
you make the right decision, because this is a long-term commitment, but that doesn't mean you're
stuck with that forever. You can always change your mind. And as a matter of fact, I've done that multiple
times throughout my career. I think one of the most
important considerations is for you to choose the one
that you're most excited about. 'Cause you're gonna be doing
this for the next 10 or 20 or 40 years, which is a long time. So you've gotta be excited
and you've gotta be passionate about what you're doing, or
it's gonna be a long 40 years. If you don't wake up in
the morning thinking. Fuck yeah, I'm gonna
DevOps some shit up today. Then it's probably not the
right career path for you because you're gonna be frustrated. You're gonna be unhappy, and
it's just simply not worth it. I don't care what they pay you. No amount of money is
worth 40 years of suffering and self hatred. So with that super pleasant news out of the way, let's talk about some of the
differences between the two that can help you make that decision. So I'm gonna give you a couple
of different options here. We're gonna talk about a
couple of different projects that are just projects
that you may encounter down either career path. And in either scenario, I want you to picture
that you're gonna spend the 30 days on this project, determining what the solution should be. And then you're gonna
spend the next six months implementing that solution. Now the timelines I made up
are just completely arbitrary, but I wanted to pick something that's, a little bit out there so
that you really think through what this is gonna be like and think about some of the
longer term implications of it. Project number one, this one is more along the lines of a software engineer route. So I'm gonna give you that one. And then the other one
then we're gonna talk about which one is most appealing to you. So let's say that your job is to create a new algorithm that looks at what a user
clicks, or likes, or comments on, within your app. And then you create an algorithm that takes that information. Plus the other information that
you have stored on that user and your job is to find
more content like that to keep them engaged and
interacting with it with your app. That may sound a little familiar. I don't know, I just made it up. So that's the software engineer problem is designing the algorithm. Now a similar style DevOps problem would be you've got this application and your job
is to build a software that captures the monitoring and the performance of this application. And we're gonna say that
you have an influx of heavy utilization from your
users in the evening U.S. time. So you are gonna build
a system that monitors your application performance
when it sees the utilization starting to rise and the
performance starting to go down. It's gonna launch more
containers or more resources to eliminate the bottleneck and make sure that your user experience is fast and responsive. And then it's gonna continue
that monitoring process to identify when the users
have finished using your app for the evening. And then it's gonna scale
those resources back in so that you don't have
a bunch of extra systems running within your infrastructure, costing you lots of money that
aren't actually doing work to provide value for your company. So those are the two problems. One we're creating an
algorithm to keep users engaged with our application. The other we're creating
a system that scales our application servers and resources in and out to meet user demand while maintaining a certain
performance threshold. Now there's a lot of similarities between these two problems. Both of 'em, you're gonna be writing code to solve that problem. Both of 'em you're gonna be
relying heavily on metrics to understand when and where
the problem is occurring. In our software engineering example, you're gonna be using metrics from what the user is clicking on, what they're commenting on. You're gonna be pulling data from what their other interests
are that you have. And in some of the
specific metrics will be how many posts have they clicked on? How many of the have they liked? How many have they commented on? How long have they been
using your app today? All of those are important
data-driven metrics that are gonna help
you solve this problem. Over in our DevOps engineering problem. The metrics that you're gonna have there will be something like the
number of users online, the API response time, how fast is your API
responding to user requests and things like CPU
utilization, memory utilization, network throughput, all of those things that you're gonna use to determine when your application has reached the lower end of that performance threshold, and you need to start
adding resources to it. I think the real distinction
between those two problems comes in who your customer is almost. Because and the software
engineering problem that I created the customer is the actual
person or human using your app. But in the DevOps problem I've presented, the customer can really be thought of as your application infrastructure. You want to improve its user experience I guess for lack of a better term. And so you measure that. And so you're solving the
same problem in each case. It's just who the customer is. Now that's important because
you're gonna probably have a preconceived notion or a preference for which type of problem
seems appealing to you. And it's really important that
you're honest with yourself and you identify which one's appealing and why it's appealing to you. And then ask yourself, is this problem something
that I'm willing to spend the next three to six
months on working diligently regardless of success. Am I willing to bang my head
against the wall every day for the next six months until I just brute force my way through solving this problem? And if the answer is no for one of those, then that kind of tells
you what you need to know about being a software
engineer or a DevOps engineer. So let's talk about one more example. Maybe it'll help you out. Problem for the software engineer, whenever you're looking at
the UI for your application, does it really bother you If things aren't either
center aligned or left aligned or something is left aligned, but certain things are more
left aligned than the other one. Or do you have a really
strong opinion about which shades of blue go with which shades of purple or something, is that something that
really like you see it, you identify it and you're like. I gotta fix that. If you really like solving
those kinds of problems, you're not gonna encounter that a lot as a DevOps engineer. But from a DevOps problem
of a similar magnitude, let's say that you've got a CICD pipeline and every time your developers
open a merge request, it triggers a build process
on your CICD server. And that takes five minutes to complete. So you look at that and you start thinking about the problem. Can I make that go faster? Because they have five
minutes they have to wait before they can open their merge request once they commit their code, can I do something like increase
the memory or CPU available to the build server, or maybe there are
certain known dependencies for our application. So can I create a new base Docker image where those dependencies
are already pre-installed and the build process
doesn't have to manage those. Or maybe part of your
merge process involves spinning up a pull request environment so that the application can be tested. And are there parts of that infrastructure that don't need to be
spun up and torn down every time that you can have sitting idle and then you just drop
the Docker container for that pull request
into that environment. And so you cut down the time that way, and you get the time
down from five minutes down to three minutes. May not seem monumental, but to someone sitting there
and waiting to click on the pull request button, it's
probably pretty significant. And that differs from the
software engineering problem, because it has nothing
to do with visual layout. There's no design,
there's no color palette. It's just backend system analysis and understanding the workflow and understanding the
parts of the infrastructure that make up that workflow, and identifying which parts of that can be improved for performance. So those are two different
examples from each software engineering
and DevOps engineering, that hopefully will help you
understand a little bit more about what each career path is like. And see which components of that align with your own personal interest so that you make the right
choice in your career. And again, like I said,
back in the beginning, if you start down one path and decide that that's not for you, you can always change because especially with these two career paths, software engineer and DevOps engineer. I mean, a DevOps engineer really is a software engineer anyway. It's just that you write
infrastructure code instead of user-facing application code. So you can always switch. If you decide that one
might be better for you than the other. If you found this video helpful, do me a favor and click
the like button down below, and also go ahead and
subscribe to my channel. And then you'll see in your YouTube feed whenever I release new videos. And with that, I'll see y'all next time.
