A step by step guide on how to become a DevOps engineer | Hacker News Reader

A step by step guide on how to become a DevOps engineer

github.com

81 pointsmooreds47 comments

1. Find out that DevOps Engineer is a made up title by hiring managers to mean "IT Operations Engineer That Knows Modern Tools" but shorter

2. Become an IT Operations Engineer

3. Years later, find out what DevOps actually is

4. Never actually practice DevOps

5. Become a DevOps Consultant

Ha! That’s not all that different from my experience. I was going to ask if we’ve collectively given up on arguing against DevOps as a title, role, department, etc.

missed process part. devops is not just automatization

great reply

IT operations engineer? How about sysadmin?

Yeah, pretty similar. The difference would be that a Systems Administrator mainly "Administrates" (maintenance, toil, etc), which doesn't have to involve an Engineering discipline. An IT Operations Engineer would take on more Engineering work and not necessarily "Administrate". And the "Operations" part can relate to either Business Operations or Operations Management.

Unless you are an especially forward thinking Operations Engineer, I don’t think this is necessarily true.

Most of the people I’ve worked with called like that stopped their professional development somewhere around the year 2000 and are now coasting along.

For the new title, I feel like they completely ignore the Dev part of DevOps.

Folks tend to get so upset about the title of "DevOps". I am unsure if it is because of:

  - just dealing with bad Ops engineers at work that "don't do much"
  - employees taking advantage of the DevOps movement to make more money
  - System Administrators complaining that 'this is what we have always done'

System Administrators, though skilled, had a much different mindset in the 90s when I worked closely with them. They were more focused on keeping Sun hardware running and keeping the SAN from filling up. That server room was their 'production'. They were still on call for when a server went down and it took days for a new server to be rebuilt. The best of them wrote scripts to make their lives easier but that wasn't often the focus. They were too busy keeping the systems running to automate much of it.

I find that DevOps is a different level of abstraction compared to Sys Admins. In general, they do not need to know how to build a server and fight with the OS as they can use tooling to spin up 100s of machines in the cloud. The amount of knowledge they need is much broader and less specialized than a System Administrator. Where the Sys Admin would need to know the ins and outs of Cisco Routers, the DevOps engineer only needs to know how to use a Load Balancer. If lucky, there is a tool that makes it easy to create them.

I find the list in the guide to be quite accurate but you do not need to be a master of everything in the list.

1. Identify a plethora of tools that are gaining steam

2. Start implementing tools into existing workflows

3. Pad resume with new buzz words

4. Leave for a more lucrative gig while midflight with current projects

5. Rinse and repeat

Dammit I was just going to post #5.

Can I give you all my upvotes?

I'm not sure if this is the exact curriculum I'd pick but I do think it's one of the easier jobs to 'learn' and get a well paying job doing. If you want to get hired at Google (for example), one thing I think that is overlooked is that the SRE-SE interview is actually a lot more sane than the puzzles you see in the software one in terms of practicality, relationship to actual work, and 'learnability'. To have a pretty solid shot you need to learn a scripting language and be able to do practical things with it -like opening files, regex, string manipulation, sets/maps, etc. Next is trouble shooting and linux internals (what happens when you boot a system or run a command at a relatively low level) - this may require dedicated study or just some brushing up depending on your background and general natural 'computer nerdiness' (i.e what OS are you using right now?). The design question needs a bit of preparation - it'd be helpful to read popular distributed systems white papers from the last couple of decades like the DynamoDB paper and understand some 'modern' primitives like RAFT/PAXOS or LevelDB/RocksDB and practice doing some back-of-the-napkin system sizing if you aren't great with mental math.

So it's definitely a lot but at the end of the day it's just knowledge you can self study. A focused course could probably teach it in 6-8 months and give you a pretty solid chance at landing the job vs the algo-puzzle coding path which has a high false negative rate even for talented software engineers. Plus once you have your foot in the door you can always look into a ladder change if you find you don't enjoy the SRE-style work.

Any suggestions to be better at Linux or SRE in general?

It's pretty much shell scripts all the way down folks. Its all shell scripts being used abused wrapped invented and reinvented.

Although I get your point, fundamentally DevOps tools exist because shell scripting is so bad.

Now shell scripts are called from containers as defined at ci-cd.yaml

It doesn’t have to be, we (the community) seem to just do it out of habit. Every CI system I’ve ever used is perfectly happy to shove your little script into any binary you have in the container. You could write them in Python or whatever but people don’t because it’s usually really verbose.

With, God help us, significant white space.

Try passing AWS Solution Architect Prof with shell scripts, then we’ll talk :)

Seriously tho, I stepped to next level when I started doing Boto stuff in Python.

  12. Learn DevOps
  What is Scrum?
  Ways To Learn About Scrum
  Software Development Life Cycle (SDLC) Phases & Models
  The Beginner's Guide to Agile in Jira: Course description
  Learn SAFe
  Learn Automation Testing

Well. That list is certainly something. But whatever it is, it's not DevOps. It's like "certified agile"? Which is also not agile.

To be fair, that's the last bullet point after all the other (pretty relevant) topics.

And I agree, that's "certified agile". Pretty useless. You can pick whatever "agile" processes are being done in your company in 15min and just go with the flow. A "devops engineer" (whatever that is) hardly needs to know more than that to deliver.

That a fair point, but the whole thing is "learn yourself some devops". If that list ends up building up to that, then you've not gotten the point of any of it and you can't honestly call that last section "devops". There's also some weird excursions on that list, like securing a CI/CD pipeline before we've even gotten to that or getting to k8s way too early.

Spivak's approach is much more in line with what I'd suggest folks do: https://news.ycombinator.com/item?id=33398284

"certified agile" makes me think of gymnasts

As someone that has never worked at a startup before, this seems to be the list of skills a startup might find reasonable for a 'DevOps Engineer'. Every other place I've interviewed or have worked has DevOps Engineer and Site Reliability Engineer being distinctly different roles (SRE focusing on monitoring and logging and DevOps engineer focusing on pipeline and build).

There are also other places like where I am now where every team that works on backend infrastructure (Windows, Linux, Virtualization, Networking) also works on their own automation for their platform. We do have a Platform Engineering team that focuses on K8s and Dev tools such as Artifactory, Gitlab, Puppet.

I have an opinion that if a company has a specific role of 'DevOps Engineer' they are doing DevOps wrong. Also Jira and Scrum are absolutely not needed at all to do DevOps.

As a careerlong DevOps guy, I’ve heard many times that “if your job title has DevOps in it, your company is doing DevOps wrong” – overwhelmingly from people with “DevOps” in their job title, delivered with a mordant laugh.

I'm a bit cynically happy to find out I'm not the only one with this opinion. I've never held a DevOps title though.

The reality is that most companies that need the help or cultural change won’t have need to even use the term so it’s a catch 22.

devops or sre might as well be a euphemism for sysadmin that can write a little python

If a SRE only knows one language I'd be skeptical. Most SREs I know know multiple languages. That goes for SRE-SWEs and SRE-SEs.

SRE is a software engineering position -- someone needs to write the software (such as Kubernetes) that sysadmins use. It also requires a good understanding of lower-level languages, since someone who only knows Python will have a difficult time debugging a kernel panic or weird mutex issue in multi-threaded C++.

Professional devops/infra/ops whatever we're called these days engineer here. I have feelings about this.

1. Learn a programming language first. Pick something common. Ecosystems are more important than the quality of the language. If you feel overwhelmed by choice learn Python. The ideal learning path is high-level -> low-level -> low-level (advanced) -> high-level (advanced). You want the language to get out of your way at first so you can learn concepts, then get in your way as you learn how things really work, and then back out as you learn real software development. Learning version control first will feel completely unmotivated without knowing why the tools the way they are.

2. Absolutely 100% learn Linux. The best infra people have a strong strong background in sysadmin work. And learn networking through the lens of the kernel/low level userspace. Don't try to learn network protocols in a vacuum, learn how they're actually used on real systems.

3. From this point skip right to IaC. You are at the point where this will make the most sense. And unless you have quite the setup this is when you're gonna learn a cloud provider. Pick AWS. This isn't a bias toward them -- knowing AWS will make learning other clouds easier, the reverse isn't true. And tooling, guides, and documentation for AWS is more plentiful. Explore using the console but don't do anything except play around. Assembling the Cloudformation/Terraform will teach you much much more about how the pieces fit together.

4. Now learn CI/CD, and you'll find yourself reaching for containers here because it's such a huge pain without them. Now you have a real motivation to learn them that isn't contrived. Once it "clicks" you'll understand why you might want to deploy other things with it.

6. Don't bother learning "devops the process" -- it's worthless, nobody agrees what it even is, and every company will do it differently anyway. You want your "knowledge" about the process to be as rich as the flavor in a La Croix. All these processes are at their best when everyone only vaguely knows what they are because any sort of strict adherence only makes you lose sight of your real goals.

7. Do not learn k8s until the very end. It is literally the final boss that combines all the other knowledge you acquire in your devops journey and you genuinely cannot understand the architecture, the tools, and decisions until you experience the pain points of not using it.

8. If you can swing a job as a junior then don't bother to learn how to run production systems, you will learn so much better and faster on the job than anywhere else. Have a "homelab" running some semi-production services to play around with and talk about in the interview but be ready that the big leagues will be a lot more involved. Once you are reasonably self-sufficient at your job and ready to move from maintainer to architect then look toward sre books.

This will get you ready to work at shops in the cloud. If you want to do on-prem work it's a different path.

Having worked as DevOps, I would really start a guide with a qualification of the pro's and con's of DevOps to evaluate if DevOps is the right path.

The sad truth is that DevOps is a cost center which comes with all types of organizational disrespect, including lower pay and harder political battles.

If I have 100 physical servers that needs OS installation, software installation, DB installation and management, installation and management of Kubernetes clusters, building a pipeline to deploy software on them, setting up networking and load balancers and monitoring all of these so I know all things run smooth, fixing stuff that is broken, then what should I look after? Sysadmins, network admins, DevOps, Zen masters or Kung Fu pandas?

This is a big list to tackle from zero. Chances are you’re employable if you get through a third or half of this list. You’re probably senior if you can do all of it.

Every so called “DevOps” person I have worked with turned out to be an arrogant and failed programmer who made an absolute mess out of everything they touched. While spending months doing it. And when they eventually left/got fired we would rip out their work and put a much simpler/easier to maintain solution in place instead.

Standard rant: if an individual “is doing DevOps”, then they are in “operations” and just doing what operations has done forever using a fancy name.

No there was never a time in modern history (ie at least since I’ve been around in the mid 90s) that operations at any scale wasn’t using some type of tooling - either DCL for VAX machines, Perl, PowerShell, etc.

That's both true and a lie. It's true in that people can't agree on what words mean and slap them on anything, and it's a lie that it is ops/sysadmin, because it's not.

What’s the difference? Ops and sys admin has always been about automation at scale and monitoring.

Not really, it has mostly been about managing operating systems and servers, not much else. There was a whole mess of homegrown scripts, and the PXE mess, and an even worse IPMI mess.

Keep in mind that "ops" and "admin" really depends on 'how much you have', a half rack of hardware was also managed by "ops" and "admin", and generally bootstrapped by hand and maintained with individual remote access or kludges like cssh/pssh. Even legacy systems like puppet were mostly used in the context of cluster management, not an entire fleet of mixed systems. There was no API for any of this either, so any programmatic access had to traverse layers of incompatible proprietary systems.

Developers did (and do) none of this. This work hasn't disappeared or changed much, and also isn't part of the DevelopmentOperations amalgamation. The grey area that it creates used to be the realm of release engineers and technical application operators. Those are the roles that have largely disappeared when an environment goes from legacy to more modern organisational structures.

This overlap (and the legacy disaggregation and hyper-specialisation) exists for a reason: developers that don't have to wait to deploy and instrument can release faster and more often, which adds value. But specialisation to enable developers to do all this is now needed because that extra value that was created now needs to be protected and enabled at scale, something that is enough work to keep one or more FTE busy. This is where specialisation (in a business context) comes from in general. If administrating systems and operating those systems was a very small task and easy to learn, there would be no sysops/sysadmin specialisation and the janitor would do it.

As far back as 2000, our “ops” person wrote Perl scripts using the Win32 module to automate tasks on our 20 windows job servers.

Even in the mid 90s when I worked on backend mainframe systems for lotteries, everything except physically changing out tapes and malfunction hardware was automated.

There has been an API to manage networked servers since networking existed.

The value add of DevOps was suppose to be developers and operations working together. When I develop something. I always do it with a mindset of how will it be deployed, scaled, monitored, etc

If “DevOps” is a role instead of an institutional behavior, you get none of those benefits.

And yes I know “Devops” [sic]. My day job is consulting companies on how to bring modern development and cloud operations, networking, CI/CD, monitoring, aggregate logging, etc together. I work up and down the stack from an empty AWS account to back end development and if you put a big enough gun to my head, I’ll deal a little with the clusterfuck of front end development

Step 0: Understand that “DevOps” is a really bad name for “Industrial Engineering principles applied to IT.”

ill never get why people punish themselves with this devops shit. you could just learn 1 thing (networking) on a few vendors (cisco, juniper, whatever), pass a few tests and be making good money out the gate.

i feel like devops is just a bucket for lost souls who like tech stuff.

am i crazy?

You are not crazy - you can definitly specialise. Though I think this is a good way to find out areas you may be interested in

It depends on what you want, what you like, and what you're good at. If you just want some IT primitives that are common across many COTS products and then become a vendor tentacle, you can definitely do that and make plenty of money. But for plenty of people that's not enough and just makes them sad.

> i feel like devops is just a bucket for lost souls who like tech stuff.

Yup, that's me. I would call my self a generalist with a slight tendency towards cloud infrastructure. But I love ALL the tech!

* Let me install the newest WiFi hardware and rehaul the local network - I'm happy

* Let me dig into the newest cloud-native tools to enhance the developer experience- I'm happy

* Tell me about the small problem you have in a step of your build pipeline - I'll sink 10 days into it and optimize the whole pipeline - I'm happy

* Let me put all the infrastructure configuration into code - I'm happy

The list is endless. The / one downside is that I'm juggling priorities all the time and the backlog of things I would like to do is also - endless.

> just learn 1 thing (networking) on a few vendors (cisco, juniper, whatever)

Sure, if you're only motivation is money. To a lot of folks that sounds miserable.

> i feel like devops is just a bucket for lost souls who like tech stuff.

I don't understand...do you not like "tech stuff"? We're posting on hackernews here...

Networking is boring and difficult at the same time. Most of the tools are very outdated (i.e. cli - except probably palo alto and juniper gear) and troubleshooting is a nightmare. Modern infra is also not a piece of cake, with k8s everywhere nowadays, but it’s linux under the hood and most of the times troubleshooting is easy. Also, it is much more fun for me, but it’s about personal preferences. (Switched to systems/devops after ~15 years of networking and couldn’t be happier)

Reply on news.ycombinator.com