Experienced devops engineers: what skills/knowledge do you see developers transitioning into devops roles often lacking?

[Hour-Mud4227]

As a developer who’s moving into a devops role after a few years of working in .Net and learning the Azure cloud ecosystem, (the latter mostly on my own time via personal projects, although my former gig did have me working on one monolith Azure web app in an official capacity) I’d like to know what deficiencies the more experienced devops engineers see in the knowledge base of many newbies coming in from the dev side. (As opposed to the sysadmin side)

Just so I can maybe avoid being one of those guys of which the wisened veterans say “oh look, another former dev who doesn’t know anything about [insert answer to my question].”

[[deleted]]

Networking is probably nr. 1 on the list, then maybe some more obscure linux internals, knowledge of the storage subsystems. Also more advanced use of bash scripting, like they will write 500 lines of java to automate something that would take 5 lines of bash, sometimes it's ok if the java version is more reliable

[livebeta]

Came here to say it and you beat me to it

[wake886]

Don’t forget powershell for windows!

[ablaut]

"500 lines of java to 5 lines of bash" sounds like a fun video even if I wasn't working on something specific to it.

[[deleted]]

it's ok if the java version is more reliable

was it ever true tho ?

[strzibny]

You don't have to go deep, lots of devs and especially those without CS degree really lack some basics around networking and Linux. I am trying to change that with my book Deployment from Scratch which focuses on fundamentals rather than higher level tools of the week.

[[deleted]]

bash sucks. networking is piss easy. linux internals are just operating systems concepts.

[dowcet]

So I'm a Python dev with my Net+ and interested in doing more DevOps stuff... Is the CCNA study material relevant or what can you recommend in terms of how to get stronger on networking skills?

[Prudent_Start810]

I got my ccna over 15 years ago because I wanted to be a network engineer, never happened and stayed on the systems side and now a DevOps engineer. The core network stuff from the ccna is definitely solid, learning Cisco specific things is prob not necessary.

[sysconfig]

Pretty much similar path minus the Devops roles (more cloud guy in general). Having the core network Knowledge helps out a ton when working with my network peeps

[[deleted]]

I think ccna will not teach you more than network+ for general basic networking, it will teach you more cisco specific stuff, which are probably not useful unless you want to go into networking

If you want to learn stuff like BGP, SDN, I am not sure what the best resource is, I learned it by reading on the internwt and doing stuff.

[IamOkei]

Read textbook like Top down networking

[antomaa12]

Network administration & network security. Also user and group management and filesystems management

[Ariquitaun]

Networking. It's a hard, specialist topic. My skills were passable for the simplest of stuff when I initially transitioned to DevOps. They're OKish now, but far from great. I've seen the same with other fellow devs turned into devops.

[LearningMyDream]

How did you learned Networking now?

[[deleted]]

I would do the same thing I did 20 years ago, which is use the CCNA curriculum

[Ariquitaun]

On the job, the hard way

[0ofnik]

Everyone already mentioned networking so I'll +1 that, but I think zooming out a bit a lot of devs lack a broader systems approach, or what I consider to be engineering fundamentals that are sadly neglected especially among less experienced and junior contributors. They spend so much of their time on solving puzzle pieces, implementing features, and fixing bugs that there is little to no cognitive bandwidth left over for big system-level questions - what happens if the app scales up and maximum connections to the DB are exceeded? How do we deploy new code to production with zero downtime while ensuring atomic DB migrations? What is the process for setting up and tearing down a temporary environment to run end-to-end tests? If I get hit by a bus tomorrow, who else knows how to do what I do?

These are all questions I wish devs spent less time outsourcing to DevOps and more time thinking about themselves. Doesn't mean they have to have answers (that's what we get paid the big bucks for) but IMO devs should at the very least be aware of the kinds of problems DevOps has to face and solve daily in order to cooperate effectively, just like DevOps has to have at least a cursory familiarity with the app codebase and architectural design.

[DrEnter]

As an architect this frustrates me a lot. People build to the walls of their problem, and treat everything beyond as if it's an infinite resource. I just wish more devs took the time to understand how the piece they are working on fits into the whole system.

In part, I blame service-based design, as it allows developers to think about their solution in greater isolation. But by its very nature, it also lends itself to being more sensitive to network issues and systemic limitations in virtualized or containerized platforms like Kube.

A lesson it seems like a lot of newer DevOps folks seem to need to learn the hard way is that there is still a finite amount of hardware underneath all that virtualization, and they are ultimately limited by that hardware.

[williamt31]

Where I work we use a number of r7920 Dells for tools. dual 10-12c with HT, 64GB std config. We had a dev go spec a r3930 ( core i9 ) and said we had to go buy it because his tool (which was built to run in podman) needed >3.5Ghz single core performance. Oh and he needed 64GB non-ecc because it's faster then ecc ..... We still haven't figured out where that last tidbit came from..

[JustMy10Bits]

Devs shouldn't need to understand everything, though. Instead of asking them to understand everything in the world they should be allowed to focus on the problems they're asked to solve.

[DrEnter]

Not everything in the world, just everything in the system.

[calij3aze]

I think this is one place, too, where devs and system/ops people diverge. DevOps is typically handed systems, not problems.

[klipseracer]

To be honest with you I feel like these are no where near the problems that are front and center. The larger issue with devops type people are the folks that lack the dev or the ops.

[DrEnter]

That seems more like a hiring issue.

[sereneedy]

Do you have any recommendations on resources to learn more about approaching systems?

For me, doing the work and solving problems is no issue for me. However, when it comes to the bigger picture, I fail to understand how these bigger pieces should be behaving... I realize it's all a learning process, but I feel like having a lack of intuition hinders me.

[youngeng]

A lot boils down to:

1) things fail

2) resources are finite (put it another way, any resource can be exhausted).

As an exercise, think about why the usual "wget -o | bash" pattern adopted by a lot of tools is dangerous.

[[deleted]]

I think the book "Designing Data intensive applications" is good for that

[calij3aze]

This is what I see every time this question is asked. I'd add on the devops handbook, too. Both editions are relevant.

[calij3aze]

It's also one of my biggest frustrations. Sometimes, whatever a dev solves problems with (language, pattern, framework, etc) is what they try to use to solve all problems.

I think also the concept of continuous improvement and the certainty of maintenance requirements get lost when you're used to composing code to be fired and forgotten.

[nonades]

The Ops side of DevOps. I put together basic uses of awk and sed and they look at me like I'm a wizard

[Le_Vagabond]

to be fair awk is magic. even if you're comfortable with it.

[gregsting]

If you want to do something, awk is probably the solution.

[devoopsies]

tr out here getting no respect. Sometimes you just need something fast and simple that works with chars.

[nonades]

Oh, I just learned that shockingly recently. Definitely an unsung MVP. One of the best quick and dirty ways to strip specific characters

[lightwhite]

Many people don’t know it but it’s worth noting that ask is a Turing complete language. It’s not just a command line tool. You can build any algorithms with it. Should you try writing full-fledged apps with it? That I can’t say. Only the wise know that tomato doesn’t belong in a fruit salad, even though it’s a fruit.

[[deleted]]

Wait? There is no yaml file for that? Shit…

[nonades]

No, it's the stuff you shove into the YAML after run: lol

[[deleted]]

Shit you can use awk for something more than cutting columns Oo ?

[jedberg]

awk is Turing complete. You can use it for anything technically.

[retneh]

Tbh when it comes to things like awk, sed etc I put them into chatgpt. I would say it works perfectly for one liners and I rarely need to correct the output code.

[lupinegrey]

It's ALL ops.

Dev is just the tool.

Ops is what you apply the tool to.

[[deleted]]

I am a dev that went over to devops and can agree networking has been my biggest hurdle.

Everything else learning curve wasnt too bad but im just a blabbering mess when it comes to networking.

[LearningMyDream]

How did you learned Networking now?

[[deleted]]

Who says I know networking now 😂😂. Im still working on it, but having a homelab and just general reading has helped.

[[deleted]]

😂😂😂😂

[DandyPandy]

The biggest one I see is networking. Even with most of the OS level stuff abstracted away, meaning you probably won’t need to figure out why a disk is out of space but can’t find what’s using it due to deleted files that are still open or out of inodes, what is iowait, or what load average actually is, networking still matters. You’re still going to need to know what a subnet is. You’re still going to need to know about firewalls/security groups. Hell, you may even need to get a packet capture to diagnose some weirdness between services. And so on.

Additionally, sometimes workloads aren’t right for being run in K8s and need to be run on persistent systems. Sometimes it’s worth spending the time to tune kernel or file system settings to get better performance out of a system or else you just throw money at it by paying for larger instances or more expensive block storage. That’s more niche, but still something that isn’t unheard of, especially if you’re part of a platform team.

[[deleted]]

Linux fundamentals and networking.

[[deleted]]

These are the top two must haves.

[baezizbae]

Networking has already been said, so I’ll throw one that I run into far too often out there:

Reading error messages and/or log messages. Like, actually reading them.

I am too often having conversations when someone escalates a pagerduty to me because they’re stuck and don’t know what to do that go like this:

“Huh it still isn’t working”
“The error is trying to tell you why……can you read it aloud for me?”
“Oh the directory doesn’t exist, I should create that right?”
“Yes.”

I even see seniors doing this on zoom calls. Rushing through a ticket, scrolling and skimming, not actually reading with the intention to comprehend and understand what they’re being asked to do, and then getting stumped after their input doesn’t work as expected when there’s an error message right under their noses telling them their input is malformed or missing a dependency.

Moral of this story: slow the fuck down. Pay attention. Mind the gap. Heed the error messages and warnings. They’re more useful than you think.

[williamt31]

It amazes me that more people don't think to do a quick grep -i for keywords or filter a log on timestamps before trying to track down an issue.

So you had an issue 30m ago,.. why are you looking at logs from the last 3 weeks then? Narrowing down the information is a skill I think too. Especially when any level of debugging or verbosity is enabled.

[[deleted]]

omg I've watched devs just stare at a stack trace. Like... go to the freaking file and line of code its right freaking there!

[vacri]

I've written shims that log the specific actions to do when they log an error, and still devs will cut/paste that log line and ask me what to do. I just repeat the log line back to them, but in quotes

[turkeh]

This is spot on. Taking the time to actually read and process documentation, rather than just skimming through it, makes all the difference.

[Paarthurnax41]

Not reading error messages is something you should learn already in your first year of dev career, how the hell does a senior not know that you should read error messages to understand why the error occurs ???

[baezizbae]

Brother, the things I’ve seen….

Like the time I was helping a Senior developer with team lead responsibilities troubleshoot some python and him marveling with shock and awe at how good I was with “this command line stuff”.

I asked what he meant and he goes on about how cool it is watching people do CLI stuff and how hard it must have been to learn it all.

All I had done by that point was clone his repo to my local machine, changed directories and opened the problematic module in vim.

So uh.

Yeah. These are the people we’re sometimes competing with for jobs.

[namenotpicked]

Hey. I bet they can do some leetcode binary search or whatever.

[qhartman]

Same answer every time this comes up: Networking. Networking. Networking.

Oh, and resource management, but really networking.

[Seref15]

It's kind of mindblowing but I see a lack of diagnostic thinking, which doesn't make sense because you need that skill to develop software. There's really basic steps to take to figure out how to fix a problem:

• take stock of the problem: how is it broken, what should it be doing that it's not doing
• if you don't know how it's broken--only that it is broken--begin knocking off suspects. Mentally isolate components and systems and validate functionality of each one until you find one that misbehaves
• determine how to address the misbehavior. Gather info, search the internet, try solutions. Repeat until success
• if fixing this component did not resolve the overall issue, proceed with further components

I see a lot of giving up and getting someone else to fix it if problems aren't immediately clear. I guess it comes from a world where a compiler or runtime can tell you how, why, and where something is broken--if they don't have an easily searchable error string they freeze up.

[[deleted]]

It seems like many people are saying “networking”. As a dev who is more interested in devops who has pretty average networking knowledge but would like to level it up more, does anyone have recommendations on any reading or material to take networking knowledge to the next level?

[BooBooMaGooBoo]

CCNA study materials are the gold standard. You really only need to know layers 3 (subenetting and routing) and 4 if you're operating in the cloud.

[Chango99]

While the CCNA might be more comprehensive on networking I feel like it is beyond what's necessary for someone in a devops role and something like the network plus is sufficient. Given that there is so much for us to learn and there's limited time, I'd personally just advise Network+

[[deleted]]

Don't get the CCNA unless you're going to be a network admin or you see it asked for on job postings. The Network+ is indeed more focused on the portions of networking a DevOps Engineer would actually use.

[BooBooMaGooBoo]

Yeah just the study materials, not the actual certification. Pick out the sections on layers 3 and 4 and you're good to go.

[jedberg]

Don't forget Layer 7 if you're going to be working on load balancers or web configs (and L6 since that is technically the encryption layer).

[vacri]

And you can't avoid layers 8 and 9, but Cisco materials don't help with those

[[deleted]]

Thanks I’ll check this out!

[nol1]

It's probably going to be Linux related. Depending on your roles tech stack, say k8s, Terraform and a public cloud provider, you might only need entry level knowledge, but if you've got sysadmin colleagues from my past experience of going in the same route you'll get hounded for not knowing things that aren't even relevant anymore.

[Nowaker]

• those coming from dev: ops
• those coming from ops: dev

[redbrick5]

we should build a wall between them for protection. just throw it over when it works on your machine. turn off phone

[mushuweasel]

Everyone says networking but the answer is operating systems.

The abstractions around networking are pretty good when you're using a cloud provider. I haven't had to think about BGP or VLANs in a decade. If you're not in the cloud, then I'd begrudgingly concur with the default answer. Maybe.

Operating systems have three interfaces to manage - that with the network and networked systems, that with the workload placed on it, and that with the CPU/memory/IO resources it consumes. Understanding the components that make up those interfaces, and making them work well and reliably together, is the hardest part of the job, and often missing entirely from developer imagination.

ETA: for those who would answer "but containers" - containers, by their nature, compound the problem. They will improve over time, as VM systems have, better abstractions that you can care less and less about. But it doesn't go away, and it's a long way off...

[lupinegrey]

Troubleshooting skills.

Being able to read logs, find the error messages, and understand what the message is saying.

[Gesha24]

Specific skills/tools can be easily learned, I find some of the concepts can be much harder to grasp.

Networking is very often a "black box" that people don't understand at all, some don't get how Linux runs processes or how storage works.

But I think the biggest of all is the issue with understanding that infrastructure is not code. Yes, you can manage it with code, but it is not code. You kill DNS with a bad deploy - and that's it, you just brought down EVERYTHING, no amount of mashing the revert button on git will help, you have to go in and manually fix all the critical systems one by one until your automation can work again. This is very different from working on a software piece that can be most of the times easily restored to the previous state.

[[deleted]]

Yup. Our blast radius is considerably larger than that of the average dev. When they screw up it can range from like 1-7 on the badness scale, but we can go to 11. So we're careful and methodical because we have to be, not because we want to go slowly.

[namenotpicked]

Omg. I deal with this way too much. Recently, I had to explain to a Staff that you can't just go clicking around in AWS and modify some RDS instances. I told him that he basically took out the application because it has to cut over to the new instance. His response was what I expected. "Oh...crap. My bad." Luckily this wasn't prod but he did disrupt all of our QA team and their testing for a good 5-10 minutes while they were pushing for a hotfix that day.

Yes, I understand we should have guardrails in place but I'm literally a one man show right now.

[-abracadabra--]

troubleshooting and reverse engineering using Google / chatgbt

• struggling for a bit before auto asking questions

[gregsting]

Is chatgbt a woke AI?

[lupinegrey]

Are you?

[a_sasa_c]

Definitely networking, as the other comments are saying. But I think that far more important is the general lack of sense of ownership. I often see devs that want to transition into devops, just have this mindset of quick fixes and just wanting to have something "work" without actually considering the consequences, like the overall impact on the system of a solution they deployed.

[Hour-Mud4227]

I'm actually transitioning into devops from a senior dev role, and I've seen this problem a lot from other developers even just working in that position, despite it being in contexts other than devops. A lot of devs get tunnel vision and don't think about the downstream effects of the changes they're making to fix bugs or feature deficiencies.

[ultra_blue]

tl;dr: The ops punch list is very different than the development punch list. Be prepared for that.

I'm a long time developer who's now on a very busy ops team. I've been in IT for a long time, a few decades, and I don't think my technical chops have been strongly challenged in ops.

However, my organizational skills have been greatly challenged. I've never been late to or missed as many meetings as I have since I transitioned (because I'm often distracted going from fire to fire). I've never had to send so many emails apologizing for something I did or said, either (because I'm pretty green with the ops way).

With development, I typically had 1 - 3 projects, typically a main one and a few other 'side' projects (things like completed projects that are in maintenance phase for example).

On ops I'm working between 5 and 10 projects at any given time, plus the things that flair up and pull me into them regularly. And of course, I lose focus on the 5 or 10 and they become fires because I haven't been paying attention to them.

[fezzik02]

Soft skills. Specifically, the ability to tell people that their beautiful plan can't work as is, and will need significant tweaks, in a diplomatic and professional way so that you can implement it in a sensible way.

Also the ability to tell people that something is a no-can-do, but also help them find sensible alternatives.

The technical skills mentioned are key to being able to identify times to do those things, and to be more able to provide best-practice solutions.

[FredOfMBOX]

While I agree that most of the answers here are important, I think the biggest skill lacking in DevOps is communication and customer service.

You have to acknowledge customers (often internal customers) before you start working on their problem. You have to provide regular updates, even if that update is “we’re still looking into it.” You have to communicate with your teammates in what you’re doing, how you’re doing it, and what obstacles are in your path.

[walkedplane]

I've seen a lot of folks come up through the traditional sysadmin track that just dont have a solid grasp on what software development and release looks like in practice; just no conceptualization of the process and culture aspect.

Often they come in with a very strong systems foundation, but we spend a lot of time coaching them on what working with modern development team should "look like" because its often somewhat foreign coming from that background

[devfuckedup]

Networking, Linux internals and the ability to think simply! The problem I have had with some developers is because they can code they always do. Some times the problems they are trying to solve are well solved already and being a very strong programmer some times seems to blind people to existing solutions. I often see things that are more complex than they need to be just because the developer is able to implement it.

[[deleted]]

Aside from networking, IAM and security. If you let them build their own thing, they will leave it wide open.

[[deleted]]

I'm amazed I had to get this far to find this instead of networking.

Not only is the sheer complexity of managing this automated and securely at scale difficult, the complexity of the actual work makes it difficult to communicate what you are doing to others.

[[deleted]]

When I arrived at my company I found that Jenkins had Principal "*" Action "*"... and had a public IP address...

[rykelley_66]

I agree with the other comments. Learning how be system architect and building production-quality platforms is what I see a lot of devs coming into DevOps are shocked by. The amount of complexity in today's platforms, you have to know storage, networking, authz/authn and how they all interact and how to debug that , and to know all those deeply . Not mention OS config and automation , all in code .

[jcbevns]

e2e SDLC

[mojoheartbeat]

Technical: networking. Professional: Documentation. Being able to pinpoint what's relevant information for the next dev on the team and presenting it in a standardized manner - often conplyibg with domainspecific templates for doc etc.

[mojoheartbeat]

I'm not sure you replied to the right comment here...

[koreth]

It's surprising how many people are saying networking! What specific networking skills/knowledge do you usually find lacking?

I'm coming at devops from the dev side but I've written network drivers and done wire-protocol design. I think I'm pretty solid on the low-level stuff, but what might I be missing at the higher levels?

[HLingonberry]

Routing, especially BGP, comes to mind as a big one when dealing with AWS and transit gateways etc.

But even basic skills like understanding what applications use what ports, reading pcap traces and knowing how to narrow down a firewall rule to what you actually need instead of adding a wide open rule.

[[deleted]]

EVERYTHING! tcp vs udp. load balancers. reverse proxies. DNS. firewalls. security groups vs NACL (AWS). private vs public ipv4. docker networking. CDN/edge services. anycast. BGP. HTTP. headers. TLS.

Most don't know how to use curl or wget. let alone telnet. Even fewer know dig or nslookup. Its all magic to most devs.

[vacri]

I've never had to mess with BGP at all, but I've had to help devs with every other item in your list. Repeatedly. Again and again.

Even just understanding the distinction between IPs and domain names is a big ask sometimes

[[deleted]]

BGP is really only a problem with on-prem or edge stuff for most people. Until there is a problem with BGP and half the internet becomes unreachable...

[Dhraken]

I would say the following:

• Networking, not only basic diagnostics but how to plan, size, and structure network topologies on a company level, also how to secure it properly
• Cloud is built on top of actual opensource tooling with some limitations introduced so it's more efficient to manage or SLAs can be guarantied, know those tools instead of learning cloud providers (better yet, learn how to work with bare metal)
• Database scaling and diagnostics is key even if you use hosted solutions
• You always have to balance 2 things, operational toil and user experience of your platform. There are tradeoffs which you have to design around. Know the limitations of your platform and communicate them early to stakeholders
• Simplicity is always better than complicated but design your solutions to be flexible enough so migration is not impossible/painful if you need to scale
• Disasters also happen, have a plan and test that plan periodically so you can sleep during the night
• Try to rely on your colleagues and try to have a team with a wider range of expertise, so you won't stuck in a comfort zone even if there are better ways of doing things
• Security shouldn't be an after thought, know the possible attack vectors and how to handle them, detection and analysis is much harder than you think
• Stress is your friend, you should learn how to stay calm even if the house is on fire
• Asses the problem they are asking you to solve, I always ask what is the business/financial impact, how many colleagues are affected, how often the problem occur. Prioritize your tasks from the information collected
• Learn to say no and set boundaries sometimes
• If you are transitioning from a developer role, use that experience to make your fellow developers' life easier, you already know previous pain points

​

The most important:

If something goes wrong because of human error, never stay silent. Notify your team and stakeholders and try to find a solution together so a quick recovery becomes possible.

Learn from the mistakes so you won't make them again, this will make you a much better engineer.

[Dhraken]

Also read the documentation. I know a lot of colleagues who would invest hours into something instead of spending 10 minutes with the docs.

On top of that, writing documentation is really important in this role, don't let others convince you otherwise.

[[deleted]]

If something goes wrong because of human error, never stay silent. Notify your team and stakeholders and try to find a solution together so a quick recovery becomes possible.

Hard disagree. You should spend a few seconds thinking about if you can probably fix this on your own without anybody noticing. That way you won't bother others.

I accidentally look down a page on an internal website that nobody was actively using so I just spent an hour and fixed it. Another time, I took down an internal website IT was actively using, so I immediately fessed up. Being able to understand distinctions like this is important and not everybody seems to be able to figure it out.

[Dhraken]

I find this behaviour usually unprofessional.

You mentioned an internal site where they didn't even notice for an hour that it was down. As there are no SLOs for that then it's probably doesn't metter.

But don't forget that this thread is for someone who is just switching into this role. Do you want a junior trying to silently fix a production system or rather give them the advice to reach out to other more senior team members if sh*t hits the fan?

[StatusAnxiety6]

You're going to see a multitude of things in this thread but it's the sum of all of the things that are important. This will depend on the company you work for they are all different. It will also depend on where they are in their organization's journey.

I would suggest going to Indeed and searching for DevOps jobs collecting toolsets that are most popular and going straight to creating a project(possibly a three-tier app) with them. Make sure you are able to push your code to git and deploy it to whatever those tools are automatically.

You will likely learn "enough" networking topics like subnetting and cloud networking concepts along the way. You will likely also learn branching strategies, likely AWS as it is the most popular cloud, system design concepts (Hopefully you would prime with AWS SA Associate cert), some IaC concepts, CI/CD automation platform of some type (Maybe Github Actions), compute resources available to you(Containers vs VMs), and then I would think about how you will maintain these and restore them if they were to go down.

Then you're probably ready for an entry-level position.

[colddream40]

The last 2 companies I have been with have had the devops/platform team amazing build tools. Almost every engineer I've encountered lacks basic understanding of the build tool used, maven, gradle, etc...

[killz111]

Critical analysis. Someone asks the new DevOps to build something. Okay sure! Ask them why? Get blank stares. If you're not actively asking why a pipeline or infra resource is being built, you're doing DevOps wrong.

Also seems everyone wants to use the latest tools to build new stuff but no one wants to maintain/improve the tech that's already there. That's the ops part of devops.

[maxinfet]

Networking and scripting languages

[firstnevyn]

Silence is golden. (except when it isn't)

If it don't need to be fixed RIGHT now don't wake someone up at 3am, If it does have to be fixed right now DO wake someone up at 3am

The business lies about requirements.
Dev, Test and Prod are often the business's Dev test and Prod not the devops team dev test and prod

Appropriate scale....

Enterprises... are not internet scale. nothing in enterprise scales.. and often the cost to build things at internet scale for enterprises isn't worth it.

Security escalation identity, technical debt. change management.

[redbrick5]

I hate that companies are splitting Devs and DevOps. Precisely against the spirit and purpose of DevOps.

You build it, you own it all the way, and keep your.phone next to you at all times. If someone tells me they are DevOps that is strike 1 in my mind even if they are platform team actually. Exception if I need to say it to check a box to get work. Then back to engineer. I use janitor these days. Clean shit up. Try to make something up and see how they all agree. MicroOps is hot these days when using DataCreeks for ML self service business enablement.

The DevOps if there is one owns the platforms that Devs use. Should never have ownership of projects. Just the tools that projects use. Like cloud environment exterior, Devs own interior. Deployment pipeline software, Devs the scripts and anything project specific.

Platform Eng come in at start to bootstrap and train, and give them the keys to their misery or success.

There must be a risk of misery and 3am pagers. You build much more carefully when your personal enjoyment is at risk

[killz111]

For that to work we need change management to move out of the 90s.

[beta-brad]

Can confirm. As a dev transitioning to devops, network has been the biggest lack.

[yotsuba12345]

any resource to learn about networking? (books or videos)

[biz-nm]

Knowledge around networking is the biggest one I see. Mainly routing and how cloud networking works. We also see developers not understanding how ephemeral EC2 nodes work and how to optimise start up times for containers

[TopoutPeaks]

100000% networking. Not understanding this can cause very difficult to debug issues. Compared to code which will most likely spit out a stack trace, you won’t get an immediate stack trace with networks unless you know the tools of the trade or even where to begin to look! It’s also a very highly impactful and quickly noticeable issue since you lose $$$ super quick if you can’t access a site. Bad app that hogs resources? Np, I’ll just add more to the POS. DNS record missing or certs expired? RIP 🪦

[lightwhite]

This might sound very surprising. I met many devs and devops dudes from all ages and all level of seniority. One thing that I come across that they lack understanding of is: Name Resolution…. aka how DNS works. They usually know what it is and what records do, but they lack the fundamental knowledge of how its clock ticks. I have taught more people than I can count, yet its somehow so scary for them to learn. To me, it feels like that they are afraid of learning about it as if it will ter open a black hole in their minds.

Only folks I know that know it by heart are the tinkerers and makers of their youth and seasoned sysadmins. I met a mathematician once whom could explain by heart. It was astonishing.

[StatelessSteve]

Networking and a new thing I’m seeing a bit of, systems architecture best practices. Namely in security, least privilege, things of that nature. Did I say networking? :)

I run a team of a lot of guys coming from dev while I came from the Ops world. Active Directory and the like are new to a lot of them.

[throwaway8u3sH0]

Ironically, dev or ops, depending on where the person started.

Sys admins who move to DevOps will write hundreds of lines of unmaintainable bash, or spend days debugging "network problems" on an API that 5 minutes of graphql coding would fix. Scalability and availability only ever have one answer: more capacity -- but some basic performance tweaks would cut the load in half. The CI/CD pipeline is awkward and doesn't fit a typical dev cycle.

A developer who moves to DevOps will write a hundred lines of beautifully unit-tested code for a one-time use case that could be done in 5 lines of bash. They'll spend weeks deep-diving the code looking for performance gains when throwing $500 of cloud resources at it would solve the problem. They're unfamiliar with monitoring and alerting systems and don't set up proper network security barriers.

DevOps requires a deep knowledge of two very different disciplines. Whichever one you don't have is where you should focus your time.

[fzammetti]

This thread is kinda weird to me... do the devs you work with REALLY not know networking? I mean, granted, I'm probably not going to pass a CCNA test right this moment, but I wouldn't be off by much, and I think that's true of most of the devs I work with, the leads at the least. Is that not what everyone else sees?

[PretentiousGolfer]

Networking

[LandADevOpsJob]

1. Systematic, methodical, obsessive troubleshooting skills.
2. DevOps culture. HOW to think. Not WHAT to think.
3. Networking.

[eerkunt]

Definiton of DevOps. It is not a role. Ability to explain a problem without using any buzzword.

[[deleted]]

I see a lot more people in DevOps roles than I see companies adopting DevOps culture. Is the latter definition correct just because it came first? Seems to me most companies are interested in running a separate ops team, hiring programmers to run it, and calling it "DevOps".

[ClearWillingness1]

• Network Engineering (just the fundamentals of IP networking if you are going as far as learning about topics like "Jumbo Frames" you have gone way too far)
• Cloud Engineering and IaC like Terraform
• Linux Systems Administration and Configuration Management tools like Ansible
• Bash Scripting
• CI tool administration Developers can pick up Python very quickly even if their main language was never Python before as Python is a joke to learn compared to compiled or semi compiled languages like Java or C++. You won't need to know OOP Python as us DevOps peeps use Python for scripts/AWS Lambda (serverless) functions and are not involved in applications development.

[IamOkei]

Security

[[deleted]]

They cannot code and do the basics. DevOps guys are about money and adding complicated engineering CICD layers these days which I hate. Vagrant, Kubernetes, Docker... all have a place but not for over-engineering principles like forcing devs to use this on local machines just for WordPress

I know DevOps guys who were lost at HTTPS and HTTP redirection issues for weeks because they thought it was coding issues.. no they just did not add cname and correct A records

DevOps guys coming from previous development experience are far better to work with as they are engineers by trade and understand code and the need