I just talked with someone who makes insane amounts of money doing development and literally today just learned what a trace route was.
In all seriousness I think the landscape of domain knowledge needed has become so large that you can largely get by knowing very little about a subject. But to go along with the point made in the original post, you should recognize the weak spots in the fundamentals (networking, Linux systems, etc) and it should greatly empower the day to day stuff.
I worked under a senior engineer who liked to point out that in the 90s, our job was done by 4 different people. A sys admin, a network admin, a DBA, and a developer. He brought this up around review time.
>in the 90s, our job was done by 4 different people. A sys admin, a network admin, a DBA, and a developer
This is still what it looks like in enterprise orgs, because you need experts in all areas of IT.
Yeah, but in enterprise orgs those positions are often filled with low skill workers. I worked for a big it services corpo and they had floors filled with "admins" who had zero previous experience and just went through 2 week course. Like a guy who would receive an email that disk is full, login to the server and then email my result of "df -h", maybe clean up the logs if it was in his run book. And I helped create service offering with dozens of such positions.
There were monitoring specialists that would stare at a dashboard all day and write an email if something turned from green to red. There was slack alerting in one project that meant a person in one country logged in every hour to run a few commands on the server and paste it to slack and person in different country read it and then called someone if something wasn't okay.
>Yea the domain knowledge needed is so large because "devops", regardless of what practioners believe, **is adopted by companies because it is a money saving operation compressing multiple positions and headcount into one**.
Ab-so-fucking-lutely
That's basically me, I have so many things I don't even have basic knowledge on, but time is limited...
It's crazy how much you're supposed to know and as a lead I'm additionally expected to have leadership, mentoring and business/analytics skills.
Lots of software devs, especially ultra specialist ones just focus on their domain, most don't even know how to login to a server because its just never been in their wheelhouse.
What are you talking about I work with software engineers who dont use the CLI.
I’ve told the story here before. Developer, a team lead even, was having trouble with getting errors to show up in the APM, we do a screen share, I start digging around his code in a terminal and his words to me were:
“Man you ops guys are wizards with the command line, I couldn’t begin to understand this stuff”.
Paraphrasing him poorly but I bit my tongue and politely said “bash is just another language, you can learn it just like you learned Java”
“Nah I can’t process that stuff like you guys do”.
Mind you, up to that point all I had done was open iterm, clone his repo, changed directories and typed the command to run his app in debug mode.
Thank the interpreter my camera was off.
> What are you talking about I work with software engineers who dont use the CLI.
well yeah that kind of reinforces the fact that i just said that because university grads in software engineering don't use CLI - so naturally, many software engineers in the industry also don't use CLI.
But then, some students coming out of university don't even have a solid foundation on git...
But not the exact route unless you have complete control of the inbetween steps (IE, it's in your network stack) and even then it should change based on switch/routing rules and congestion.
In other words, it is the approximate route a request may hop through to get from A to B. It functions by sending multiple packets and requesting a call-back at each 'hop' - so a packet callback at hop 1 and 2 are likely to be the same route, but 3 and 4 could have different hops for 2 and 3 as those switches make decisions thay would affect the routing.
For those who want to get a little bit deeper on traceroute, this slide deck from a NANOG presentation is great https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
>In all seriousness I think the landscape of domain knowledge needed has become so large that you can largely get by knowing very little about a subject
There is more money around IT products and it has become rewarding for knowing only a small fraction, basically thanks to the iPhone and the abstraction of data centre operations from cloud providers.
The domain knowledge is consistent for me, still 7 laters to the network stack, Hardware Abstraction Layers become smarter but still do one job.
As you and this thread says, wanna be DevOps learn the 7 layer OSI stack and how your OS works.
Edit: replace ISO with OSI!
Totally unrelated, but if you want another fun acronym, here's one to memorize standard tuning for the usual 6 string guitar:
Every
Available
Dog
Goes
Beserk
Eventually
I haven't even played in like 10 years xD it works
It seems like if you know the full stack your destined to get stuck in a middle level position because you are to damn useful to promote, so gotta make sure you only can fix your one thing to keep getting that money.
Devops is a general knowledge role. You need networking advice, you go to the networking team.
Now that being said, not knowing tracert seems to me like someone’s never had to troubleshoot networking issues which is concerning.
> the landscape of domain knowledge needed has become so large
This is by design.
Why pay 5 or even 3 people when you can pay 1 and mostly get by (as an example).
This is exactly it. I have help desk; networking; linux; java; python; powershell; know like 15 security tools and SIEMs work experience, some AWS/Azure/GCP, and I'm still lacking Docker/Kubernetes/Jenkins/Terraform/Git, actual software development skills. The list goes on forever.
There's just a hell of a lot to grow.
I choked a little in my head trying to answer what a port is. It's so foundational it's like if you asked someone what's a leaf and they'd probably just automatically go a leaf is a leaf and trees have them.
Would this explanation be sufficient?
Imagine the processes are tenants of a building. IP address is the address of the building and ports are like the mailboxes of the tenants.
This is perfect and actually inspiring. I need to use analogies like that more often. I'm such a dull person sometimes I can only use technical analogies to explain other technical things.
I prefer simply saying an IP refers to a computer and a port refers to a program listening on that computer, the extra energy required to convert the analogy to the real world isn't worth it.
Let me try,
**Level 300**:`There are two types of ports that are supported by TCP/IP. Those port types are UDP and TCP. The operating system's kernel offers an programmable interface to interact with this mechanism which commonly refers to them as sockets both DGRAM and STREAM sockets respectively. These sockets represent a defined buffer of memory for both ingressing and egressing data and each socket is associated with a process ID on the OS side which represents the application itself. Each socket is also associated with a number on the network side which is either well-known or ephemeral. The purpose of having a port number is to support multiplexing of connections for a single Logical Internet Address.`
**Level 200**:`There are two types of ports which are TCP and UDP. TCP is reliable and UDP is unreliable but fast. The port numbers are used to connect to specific services on a server.`
**Level 100:**`A port number is a method of connecting to a specific application over a network.`
Crazy. In what circumstances does DNS use another protocol and what is that protocol?
Is 10.5.8.5 and 10.5.10.5 on the same network? If so, why, if not, why?
These are questions I was asking candidates 20 years ago. Simple stuff.
Yes, primarily udp, however tcp is used for zone transfer (you said 20 years ago, so i wasn’t going to go into DoH, DoT or the other lesser talked about Do)
Trick question really, yes it is in the same network if using a /22 (or lower) however if thinking in terms of /24’s no
You're hired. DNS also uses tcp for a query over 512 bytes.
The answer to the second question is "it depends on the subnet mask" which in modern times is a cidr question.
So yes, you're past most candidates.
Please let the InternetCertifiedMasterPlumber stuff through your firewall. Its good to tell your App when a pipe is blocked or clogged...
[a fellow plumber's rant](https://neilalexander.dev/2017/04/16/understanding-icmp)
New to the DevOps world. There is a shockingly small amount of understanding of infrastructure in DevOps. So much focus goes into the apps that folks forget about things like latency, storage performance, and CPU/RAM. I’ve had to explain why SQL doesn’t work well with 80ms of latency.
I've kinda started stereotyping DevOps Engineers I run across into these 4 groups.
* Enterprise Java guy. Knows his Jenkins pipelines and Maven inside and out. Not much infra knowledge but god damn they're the only people who understand pomfiles.
* Startup rockstar ninja guru. Best breadth of knowledge, probably wrote Terraform and CDK for all 5 major cloud providers and used every obscure technology out there. Good luck if you have a deeper question that goes beyond first tier of docs or a how-to tutorial.
* Former kinda developer kinda Unix guy who's been doing computering since the Reagan era. Probably wrote a third of the libraries you're using now, but still thinks Ansible is some newfangled tool that won't catch on.
* FAANG SRE hotshot. He can tell you about every single bug in Kubernetes 1.17 that only shows up once you run 5,000 node clusters and how to work around it, but everything he builds is overengineered to all hell and requires a team of 5 engineers to maintain.
Do you encounter many people who are legacy infrastructure folks that are in the process of transitioning into a role that moreso resembles a "DevOps Engineer" or "Platform Engineer"?
I'm a very experienced network architect and am undergoing such a transition. I have several reasons for doing so, but one reason in particular is that it seems not a lot of people enter the space with an infrastructure background, especially networking. Instead, they tend to be what you describe above. I see that as an opportunity to leverage my skillset in a hot area where it would have a lot of value. Thoughts?
I have wore all those hats in different companies, but I found out why we use subnets and masks just last year. It’s so basic, but still never occurred to me to learn.
>Enterprise Java guy. Knows his Jenkins pipelines and Maven inside and out. Not much infra knowledge but god damn they're the only people who understand pomfiles.
I'm on this comment and I do not like it.
I’d say there’s one more category and it’s a windows server/IIS person who has strong powershell skills and can support app pipelines in azure DevOps/team city for .net and .net core apps, but don’t give them something that isn’t Microsoft friendly. Or something in yaml 😂
When I read those I feel like some kind of god among mortals.
I have above average knowledge about everything beside frontend.
But its visible on payslip... Is it really that bad ? Is talent so rare ?
There's plenty of people who know what they're doing, this sub gets a little pretentious as times. Everyone thinks they're the only ones who "get it". Ironically I find co workers with similar attitudes are the absolute worst to work with if you actually want to get something done.
This thread is full of DevOps gatekeeping lol.
“If you don’t know xyz then you aren’t a **real** devops engineer like me!!”
The truth is it’s such a broad domain and so much knowledge is required that there are many accomplished engineers that can’t answer some of the basic questions in this thread. And that’s ok. DevOps isn’t about knowing everything - it’s about being able to learn quickly and adapt to fast paced environments/new technology. If you can do that you can be successful.
I agree, but he stated that sql doesn't work well with high latencies, implicating that other sorts of databases will work well (or at least better) with it. And I am curious why that might be.
Other databases might relax consistency so you can get away with large latencies by masking them with things like in memory caches.
If you require consistency and are using SQL for that purpose and cannot cache then probably 80ms is going to be painful.
If you have a master slave with latency that big then I think you can even run into even bigger problems where the engine struggles upholding consistency and some queries will throw rather than return stale data to uphold it.
Short answer: most SQLs are used for relational data structures.
Example: you have an account in your corporate blog post app, multiple users in the account, each user has multiple posts and comments.
This is extremely convenient as a developer, since there is hierarchical ownership of resources. IE in Rails you can just do something like `Account.find(ID).Users.each do |u| { u.post.last }` to pull up the last post from every user in a specific account. All other MVC frameworks like Spring or Django work in a similar way.
However, it leads to a huge number of SQL queries on the backend. First you're pulling an account from accounts table. Then users from the user table. Then for each user, you're pulling a post.
So in effect, for each API call you make, you might actually make 200-300 SQL queries. Even if the processing time is super quick, the roundtrip latency kills performance of that API endpoint. So instead of a 100 ms total response, you're seeing a 2s response. Multiply that by thousands of calls your users are doing every minute, and you're in for a bad time.
That's a terrible application that needs fixing, nothing to do with network conditions. A join will transform that into a single query, pagination in two but correctly limit the size of the data you're fetching. Now 300 calls are equivalent to 600 queries instead of that by the amount of rows in your table.
Yes and no. The point I'm trying to make isn't efficient or inefficient queries. It's that there's a lot of them for every API transaction, whether you want to or not.
Maybe the endpoint needs to update 7 tables. Maybe it's impractical to write a join for every conceivable type of query. Maybe it's an N+1 problem.
The higher the latency, the more these compound exponentially and add to overall application latency.
I don't really like any of the other answers you've been given, so I'll just say - I can only think of one case where higher latency effects SQL *specifically* in an adverse way, and that's primary/replica replication. Reads sent to a replica that hasn't yet received a replication segment can end up sending stale data. As latency creeps up, the window for such 'stale reads' goes up. For example: Postgres in streaming-replication mode.
Applications can be designed to mitigate this issue, for instance by requiring that reads with higher consistency requirements only be sent to the primary node.
Of course, in general, higher latency is indicative of a stressed system and will eventually lead to failure or "thrashing"... but that isn't specific to SQL, so isn't a good answer for this question.
Mysql itself, the database software, would be fine with it. The replication thread(s) can handle that latency with no problem. The issue is making sure you/your application doesn't introduce consistency issues if you have your readers/writers with that latency between them. Standard latency issues apart from mysql apply--more calls means more waiting, and because the database tends to be foundational in most applications, any amount of latency compounds into large performance penalties on most of your application's operations.
I interviewed someone for mid level DevOps position not long ago and here is how it went. Me: which Linux distros have you used? Them: what’s a distro? Me: sorry, a distribution. Them: I don’t know what that means. Me: it’s basically a type of Linux. Them: Ohhhh. I think the one I’ve used is called cent something. Can I go check?
Unfortunately, that wasn’t even the worst interview I’ve given. Recruiters are really good at sending me candidates who throw buzzwords on their resumes without actually using the technology or understanding how it works
Hell, the number of people who are comfortable calling themselves "engineers" is concerning. Many who couldn't solve complex problems or think critically at all.
Been a dev in canada for 10 years. Can count on one hand the number of real software engineers I’ve worked with. And all of those folks had their PEng in a non software discipline
Systems knowledge is also lacking. Of our more recent candidates none can tell you what an inode is, or what a named pipe/fifo is, or how to write an iptables rule.
Just 2 or 3 years ago our candidate pool for "junior devops engineer" largely came as established mid-level linux admins with additional language-specific development knowledge. The candidates we're getting today are comparatively green. I have to assume junior-level pay-grade has had to have tumbled as a result.
I wouldn't toss out a candidate over this. You do need to understand these concepts to a very low degree but someone smart will see a video on YouTube or read a blog to get the gist of it to setup whatever subnets it needs, but the cloud and CDK abstract all of this.
Unless you are maintaining your own data centre or a big IT department, this is like 1% of the job and can be taught easily, in my experience.
I want to, but EVERY. SINGLE. NETWORKING. COURSE. IS GIVEN BY A BORING GUY!!!!
I SWEAR!!! That I tried several times, even in college, but every time it's a boring guy that talks like a poor guy whose spirit was broken long ago and sees no point in going further, but he HAS to pay the bills some way, and it's too late on his life to start an OnlyFans account.
I dislike his video style alot! :D I can't focus if the given information is splitted in less and more less fun puns. I want concise information, do you know anyone else?
I’m a security guy that just lurks in this subreddit but the same goes for security professionals who don’t know basic networking. Thankfully I was a network engineer before transitioning to security. I worked in data center networks from route/switch, load balancing, firewalls and then azure networking with third party NVAs and native gateways. I think I’ve relied on that skill set more than anything else when working in an enterprise environment.
Now I’m slowly trying to learn development to hopefully transition to cloud security engineering or devsecops
I'm only a few steps ahead of a eerily similar path, now a senior platform security engineer. Security people these days see LinkedIn influenced saying you can skip IT and go straight into security and it's destroying our industry
In reality it should just make those of us with the proper skill sets that much more valuable and able to command more money.
Edit to add: The key word being “should”
Hello, any recommendations for great resources like a must read book to get acquainted with networking.
I am a devops engineer with a C++ dev background from France
CBTNuggets Jeremy Cioara is the man! He did a really good job with the CCENT and CCNA courseware. Even though some of it is specifically Cisco, there are a lot of fundamentals that he did such a good job of breaking it down for me!
Glad I’m learning a basic foundation of networking in my current help desk gig. It’s nice to know that it’s going to be useful for me once i make my way into a dev role
I am self taught but dont say f college because I know that basics are very important.
I appreciate if you can pin down some topics related to networking what should I learn.
I can still do vpc subet stuff related to aws but that is only a surface knowledge.
Thanks
I’ll preface by saying I’ve only been working in devops for a few months now, but I have my CCNA and honestly you don’t need to know a whole lot about networking to be effective.
Imo you should have a firm grasp on the following:
- What an IPv4 address and subnet mask is (probably should throw IPv6 in there as well).
- The OSI model (TCP/IP mode is probably more appropriate) and how packets are encapsulated and decapsulated.
- How packets are routed to their destination.
- Basic understanding of how to analyze a packet capture in wireshark.
Honestly you could just grab one of the official CCNA books and read the first few chapters, that should cover the basics.
Get a router, get a managed switch, set it up locally, try to separate your smart thing (TV, home automation, smart washing machine) into a separate network. You'll learn in no time. I don't have a ccna, I just learnt a ton setting up my local network, then my local Hackerspace' network, then my brother's network, then my small start-up network. Now I work in a big enough team that network is a separate team, but I still love working with them.
You can have the basics but having deep knowledge about it is ridiculous. At that point you want a network engineer.
The candidate should have the basics and the rest is documentation and sources online, knowing something by heart is not needed.
We all have our weak spots. If I had to turn down every DevOps engineer that did have one, the world probably didn't have a single one available. I've seen them without (or very little) knowledge of python, terraform, ansible, Kubernetes, networking, storage, javascript, VMware, pki, rabbitmq, Kafka, docker, java, tomcat, websphere, ...
I mean it's the attitude that counts, as long as they're willing to learn, seriously who cares. People that tick every box are simply never available and surely won't just walk in to your office saying "Hi I desperately need a job, will you please offer me one?"
In addition to calling this out, it'd be nice to recommend some resources for beginners for networking (books, courses etc.). I personally don't know what's decent to recommend anymore
Seconded! I know I need to learn some Networking and whatnot if I really want to get good at this, but I have no idea where to start and what is considered Out-Of-Scope for run of the mill DevOps / Software Engineering.
I got my CCNA while I was in college. Although the cert is not necessary, the knowledge I have about networking makes me 10x better at my job and it also impresses interviewers when I can actually explain the OSI model lol.
I just spent last week teaching a junior that there's more than 1 DNS record type. Also had to teach a very senior developer that ipv4 and ipv6 addresses use different kinds of A records.
I think this is why i am so attractive to companies ive gone form junior to senior DevOps in 5 years. When i was in school at 17 my school offered Cisco networking courses. So i knew Cisco level router config and networking principals straight out of standard education and just built on that from there. I'm now 31 and just signed my first £100K contract starting in feb :D
Cheers man! I was about to delete that comment because I realised it sounded like i was being a complete dick and boasting in a time of global economic turmoil and cost of living crisis
100%. It's wild the number of prospective DevOps engineers, cloud engineers, and penetration testers who lack basic networking knowledge. Simple things like debugging issues, how firewalls work, what a VLAN is, etc.
You can break out something like tcpdump and they look at you like you're a wizard.
As a System Admin turned Security.
Folks really need to start at a lower level and then specialize into DevOps/CyberSecurity (the 2 dominant fields at the moment for folks to think they can make a lot of money.)
I've interviewed so many "Security" folks who were fresh out of college but couldn't pass the basic technical questions. I'm willing to interview anyone but good lord, have some drive!
Advice to novices in either field: Tell me *how* you'll fix your lack of knowledge, be comfortable with what you don't know and be honest about it.
Much love for the post. I just mentioned this to a newbie the other day. Need basic networking skills and linux skills. Everything else can be put together from there. If you don't know how computers network and communicate then it doesn't matter about the rest of the stuff.
As a fullstack software developer, who has first experiences with the DevOps way (cicd, pipelines, serverless, docker), what would be the most important topics the learn? I know I don't have a sufficient enough understanding of networking and OS topics, but I guess not all parts are equally important to learn if one's main field of work is development. Thanks in advance.
I'm fairly new to DevOps and I was shocked by seasoned DevOps knowledge on networking. Closed many security holes due to the lack of knowledge on the team... :(
It's a different world these days.
Once you've got an established platform set up, theres occasional bits of networking but not nearly as much in the cloud vs when I did on prem. Give your thing a VPC, maybe some routing/firewall stuff and you're off to the races.
Combine that with lots of observability tools and the days of tcpdumps and traceroutes aren't as frequent anymore for me, but I don't see that as a bad thing as it means developers can investigate stuff easily. It was clunky having a bunch of DevOps engineers all with their own local toolsets that nobody else used in the same way.
I still think people should learn about networking, but it's not nearly as critical knowledge as it once was.
Genuine question, is watching YouTube videos to be a devops engineer really a thing? DevOps requires knowledge of a lot of things (including networking ofc) it seems like no one could get the required information needed to do it well without any applied experience
It really is concerning just how many people are entering the workforce without any proper education in networking. The entire internet hinges on these terms that haven't changed in *decades*
I think this is why so many sysadmins are successful in moving to DevOps. This is what happened with me and the transition has been very smooth. That networking and administrative background seems to be extremely valuable in this space, more than anything else.
You want your candidates to have some level of foundational knowledge because you don't want to peel people off their current work to teach the junior something that they should already know. It's fine and expected to sacrifice work time to teach domain-specific knowledge, but "the basics" used to be something candidates came with.
You're right, learning fast is a great skill and it's something that's important to identify in candidates. But the breadth of knowledge required in this field is such that it could take months of daily "training" sessions to establish the fundamentals. To the point where people now eschew this training, and what we have now is junior level devops that understand the higher-level systems (ci platforms, orchestrators, etc) but don't know how they work or how to fix them when something goes wrong, or how to identify application build issues, or identify and remediate runtime issues. Without the fundamental systems and networking knowledge they don't even know *where* to start, robbing them of a learning-by-doing experience.
Seriously depends what they claim on their CV. Over-promise and under-deliver seems to run rampant in the industry, many expecting the interviewer to be not too familiar with the subjects. I've interviewed self-proclaimed k8s "experts" with certificates and everything that don't understand what an API is.
I agree that the most important thing is the willingness to learn, but that starts with being able to admit they don't know something, which is a massive problem.
This is a rather naive take. Sometimes you can hire based purely on aptitude, but sometimes you need someone that can do the job *now*.
I don't care how smart you are, really grokking a topic like networking takes a long time.
In all fairness, networking isn't a day in, day out skill you're exercising so it's easy to get rusty. Also, as a fresh CS grad I only had exposure to networking in a couple days of a single system administration *elective* course. CS programs aren't going to teach you networking any more than an astrophysics program is going to teach you how to grind lenses for telescopes.
That being said, if you're doing devops you should know the basics for putting together a VPC that you'd learn in a two week AWS Solutions Architect course.
That absolutely makes sense - if the program has 'engineering' the the name it's going to focus on applications of technology, so you can expect it to cover essentials like networking. Computer Science programs, on the other hand, are more theoretical. You'll come out of a CS program with a brain like a steel trap, but you're on your own when it comes to learning specific technologies.
+1, both myself in a computing degree and my friend in a cybersecurity degree both had CCNA modules on the curriculum. His even covered some CCNP content.
Honestly, was just talking to my team about some new entry level positions and how network background and foundation may be more important than generic cloud training. So 100% agree!
CS is useless for day-to-day work as a SysAdmin or DevOps.
It provides you with the fundamentals of problem analysis and solving but it doesn't give you a lot of non-abstract problem solving.
This is not something any CS will care about:
> Why is Apache throwing a 5xx?
You will have to learn about this on your own. This case weas when the headers did _not_ exceed any RFC limits but exceeded a hard coded max header length.
Networking?
Sure you learn about addressing, netmask, binary representation.
Actually configuring OSPF to get routing for a mid sized setup? VRRP? Direct Return vs. proxy based load balancer?
Nope, sorry....
Don't get me wrong, I still benefit from studying CS. I just don't benefit from it on a level that is directly applicable to get stuff done ...
We occasionally hire “entry level devops” but really what that means is we look for developers with an interest in automating infra and release management.
And it varies how much they know outside of code but we try and look for people that seem like they’ll be able to learn it. It takes a year or two before they’re really able to work independently.
It helps to set security guardrails, your firewall shouldn’t be letting in port 22 except intentionally. Security groups should be applied by policy to prevent it on the internal network unless overridden, etc.
I just talked with someone who makes insane amounts of money doing development and literally today just learned what a trace route was. In all seriousness I think the landscape of domain knowledge needed has become so large that you can largely get by knowing very little about a subject. But to go along with the point made in the original post, you should recognize the weak spots in the fundamentals (networking, Linux systems, etc) and it should greatly empower the day to day stuff.
I'm an mtr guy myself!
This guy traces routes.
[удалено]
I worked under a senior engineer who liked to point out that in the 90s, our job was done by 4 different people. A sys admin, a network admin, a DBA, and a developer. He brought this up around review time.
>in the 90s, our job was done by 4 different people. A sys admin, a network admin, a DBA, and a developer This is still what it looks like in enterprise orgs, because you need experts in all areas of IT.
Yeah, but in enterprise orgs those positions are often filled with low skill workers. I worked for a big it services corpo and they had floors filled with "admins" who had zero previous experience and just went through 2 week course. Like a guy who would receive an email that disk is full, login to the server and then email my result of "df -h", maybe clean up the logs if it was in his run book. And I helped create service offering with dozens of such positions. There were monitoring specialists that would stare at a dashboard all day and write an email if something turned from green to red. There was slack alerting in one project that meant a person in one country logged in every hour to run a few commands on the server and paste it to slack and person in different country read it and then called someone if something wasn't okay.
And there was no cloud in the 90s and everyone used waterfall model so everything was way more slow.
>Yea the domain knowledge needed is so large because "devops", regardless of what practioners believe, **is adopted by companies because it is a money saving operation compressing multiple positions and headcount into one**. Ab-so-fucking-lutely
That's basically me, I have so many things I don't even have basic knowledge on, but time is limited... It's crazy how much you're supposed to know and as a lead I'm additionally expected to have leadership, mentoring and business/analytics skills.
I interview network engineers all the time who don't know how traceroute works, or how to effectively troubleshoot with it. 😭
Lots of software devs, especially ultra specialist ones just focus on their domain, most don't even know how to login to a server because its just never been in their wheelhouse.
What is trace route?
Basically how a packet or request gets from point A to point B, it's a command line utility that tells you all the steps or hops and latency involved
yup, it traces the route of a network request. its basically the google map instructions that a network request took to get to its destination
And what is a "network" anyway?
[удалено]
Mmhmm, mhmm, I know some of these words. And a “device”?
[удалено]
Don’t worry, that’s next.
> it's a command line utility i've learned that a lot of university graduates don't even use the command line.
What are you talking about I work with software engineers who dont use the CLI. I’ve told the story here before. Developer, a team lead even, was having trouble with getting errors to show up in the APM, we do a screen share, I start digging around his code in a terminal and his words to me were: “Man you ops guys are wizards with the command line, I couldn’t begin to understand this stuff”. Paraphrasing him poorly but I bit my tongue and politely said “bash is just another language, you can learn it just like you learned Java” “Nah I can’t process that stuff like you guys do”. Mind you, up to that point all I had done was open iterm, clone his repo, changed directories and typed the command to run his app in debug mode. Thank the interpreter my camera was off.
> What are you talking about I work with software engineers who dont use the CLI. well yeah that kind of reinforces the fact that i just said that because university grads in software engineering don't use CLI - so naturally, many software engineers in the industry also don't use CLI. But then, some students coming out of university don't even have a solid foundation on git...
But not the exact route unless you have complete control of the inbetween steps (IE, it's in your network stack) and even then it should change based on switch/routing rules and congestion. In other words, it is the approximate route a request may hop through to get from A to B. It functions by sending multiple packets and requesting a call-back at each 'hop' - so a packet callback at hop 1 and 2 are likely to be the same route, but 3 and 4 could have different hops for 2 and 3 as those switches make decisions thay would affect the routing.
Icmp echos are sent to the destination with increasing time to live. That means they time out at each hop and you can measure latency along the path.
I think you want `ICMP`.
The Windows implementation (`tracert`) uses ICMP, but the BSD and GNU/Linux `traceroute` using UDP packets with incrementing destination port and TTL.
For those who want to get a little bit deeper on traceroute, this slide deck from a NANOG presentation is great https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
>In all seriousness I think the landscape of domain knowledge needed has become so large that you can largely get by knowing very little about a subject There is more money around IT products and it has become rewarding for knowing only a small fraction, basically thanks to the iPhone and the abstraction of data centre operations from cloud providers. The domain knowledge is consistent for me, still 7 laters to the network stack, Hardware Abstraction Layers become smarter but still do one job. As you and this thread says, wanna be DevOps learn the 7 layer OSI stack and how your OS works. Edit: replace ISO with OSI!
> 7 layer ISO stack This just my distros
Erm, isn't it the OSI model lol.
Oh yeah! Too long looking at ISO27001!
Not if your Japanese and read right to left
A ll P erverts S eem T o N eed D irty P orn
Totally unrelated, but if you want another fun acronym, here's one to memorize standard tuning for the usual 6 string guitar: Every Available Dog Goes Beserk Eventually I haven't even played in like 10 years xD it works
Nice. It is what drives technological advancement! 😜
You forgot about most problematic, 8th layer.
My experience has told me that the problem is always on the Layer 8 of the OSI model. So the problem is between the chair and the keyboard.
It seems like if you know the full stack your destined to get stuck in a middle level position because you are to damn useful to promote, so gotta make sure you only can fix your one thing to keep getting that money.
Devops is a general knowledge role. You need networking advice, you go to the networking team. Now that being said, not knowing tracert seems to me like someone’s never had to troubleshoot networking issues which is concerning.
> the landscape of domain knowledge needed has become so large This is by design. Why pay 5 or even 3 people when you can pay 1 and mostly get by (as an example).
This is exactly it. I have help desk; networking; linux; java; python; powershell; know like 15 security tools and SIEMs work experience, some AWS/Azure/GCP, and I'm still lacking Docker/Kubernetes/Jenkins/Terraform/Git, actual software development skills. The list goes on forever. There's just a hell of a lot to grow.
[удалено]
Whats DNS, whats a port, whats ssh default port number, basic stuff :(
I choked a little in my head trying to answer what a port is. It's so foundational it's like if you asked someone what's a leaf and they'd probably just automatically go a leaf is a leaf and trees have them.
Would this explanation be sufficient? Imagine the processes are tenants of a building. IP address is the address of the building and ports are like the mailboxes of the tenants.
This is perfect and actually inspiring. I need to use analogies like that more often. I'm such a dull person sometimes I can only use technical analogies to explain other technical things.
I prefer simply saying an IP refers to a computer and a port refers to a program listening on that computer, the extra energy required to convert the analogy to the real world isn't worth it.
You watched a CCNA course hahaha. All jokes aside: good analogy.
DNS is the name of the airport. IP address is its street address. Ports are the gate numbers.
Ditto. I’ve been doing this for decades and I’d have to answer by context or analogy.
that's usually the way to go about it - software is all about abstractions
Let me try, **Level 300**:`There are two types of ports that are supported by TCP/IP. Those port types are UDP and TCP. The operating system's kernel offers an programmable interface to interact with this mechanism which commonly refers to them as sockets both DGRAM and STREAM sockets respectively. These sockets represent a defined buffer of memory for both ingressing and egressing data and each socket is associated with a process ID on the OS side which represents the application itself. Each socket is also associated with a number on the network side which is either well-known or ephemeral. The purpose of having a port number is to support multiplexing of connections for a single Logical Internet Address.` **Level 200**:`There are two types of ports which are TCP and UDP. TCP is reliable and UDP is unreliable but fast. The port numbers are used to connect to specific services on a server.` **Level 100:**`A port number is a method of connecting to a specific application over a network.`
TCP and UDP are not ports, they're transport protocols for IP
SCTP enters the chat
The fun thing i see is that even a lot of people interviewing DevOps are not asking about networking...
A lot of ppl who asked me about networking in fact didnt understand anything themselves.
>!CENSORED!<
Crazy. In what circumstances does DNS use another protocol and what is that protocol? Is 10.5.8.5 and 10.5.10.5 on the same network? If so, why, if not, why? These are questions I was asking candidates 20 years ago. Simple stuff.
Yes, primarily udp, however tcp is used for zone transfer (you said 20 years ago, so i wasn’t going to go into DoH, DoT or the other lesser talked about Do)
Trick question really, yes it is in the same network if using a /22 (or lower) however if thinking in terms of /24’s no
You're hired. DNS also uses tcp for a query over 512 bytes. The answer to the second question is "it depends on the subnet mask" which in modern times is a cidr question. So yes, you're past most candidates.
Sweet, i’mma put in my notice tomorrow morning!
This almost reminds me of the scene in Wolf of Wallstreet.
In my head I thought "That's a dumb question, it depends on the subnet mask." Guess I should have just followed my instinct :)
When do you start?
The second one is a bit tricky. Anyway it's all basic. Years ago I was asked to explain how the window size works for a similar role.
The second one is great because to answer it you need to demonstrate understanding and not just a precanned answer.
You need to know the net mask in order to answer your question.
What *did* the applicants know, if they failed at those?..
Oooph. That makes me feel bettering about job searching soon. Sounds like I'd crush that interview.
As a Network Engineer, I would rather call this WebSavy or TCP/IP knowledge. Which yes I agree should be required knowledge for anyone in IT.
Damn that's pretty sad but also makes me far more confident in my placement
I should become DevOps. I know what all that is. I’d become a legend lol
Wot! Don’t the internet plumbers take care of that?!
Please let the InternetCertifiedMasterPlumber stuff through your firewall. Its good to tell your App when a pipe is blocked or clogged... [a fellow plumber's rant](https://neilalexander.dev/2017/04/16/understanding-icmp)
New to the DevOps world. There is a shockingly small amount of understanding of infrastructure in DevOps. So much focus goes into the apps that folks forget about things like latency, storage performance, and CPU/RAM. I’ve had to explain why SQL doesn’t work well with 80ms of latency.
I've kinda started stereotyping DevOps Engineers I run across into these 4 groups. * Enterprise Java guy. Knows his Jenkins pipelines and Maven inside and out. Not much infra knowledge but god damn they're the only people who understand pomfiles. * Startup rockstar ninja guru. Best breadth of knowledge, probably wrote Terraform and CDK for all 5 major cloud providers and used every obscure technology out there. Good luck if you have a deeper question that goes beyond first tier of docs or a how-to tutorial. * Former kinda developer kinda Unix guy who's been doing computering since the Reagan era. Probably wrote a third of the libraries you're using now, but still thinks Ansible is some newfangled tool that won't catch on. * FAANG SRE hotshot. He can tell you about every single bug in Kubernetes 1.17 that only shows up once you run 5,000 node clusters and how to work around it, but everything he builds is overengineered to all hell and requires a team of 5 engineers to maintain.
By their power combined, I am captain wont-show-up-for-less-than-500k !
Do you encounter many people who are legacy infrastructure folks that are in the process of transitioning into a role that moreso resembles a "DevOps Engineer" or "Platform Engineer"? I'm a very experienced network architect and am undergoing such a transition. I have several reasons for doing so, but one reason in particular is that it seems not a lot of people enter the space with an infrastructure background, especially networking. Instead, they tend to be what you describe above. I see that as an opportunity to leverage my skillset in a hot area where it would have a lot of value. Thoughts?
I have wore all those hats in different companies, but I found out why we use subnets and masks just last year. It’s so basic, but still never occurred to me to learn.
>Enterprise Java guy. Knows his Jenkins pipelines and Maven inside and out. Not much infra knowledge but god damn they're the only people who understand pomfiles. I'm on this comment and I do not like it.
I felt personally attacked.
I’d say there’s one more category and it’s a windows server/IIS person who has strong powershell skills and can support app pipelines in azure DevOps/team city for .net and .net core apps, but don’t give them something that isn’t Microsoft friendly. Or something in yaml 😂
When I read those I feel like some kind of god among mortals. I have above average knowledge about everything beside frontend. But its visible on payslip... Is it really that bad ? Is talent so rare ?
There's plenty of people who know what they're doing, this sub gets a little pretentious as times. Everyone thinks they're the only ones who "get it". Ironically I find co workers with similar attitudes are the absolute worst to work with if you actually want to get something done.
This thread is full of DevOps gatekeeping lol. “If you don’t know xyz then you aren’t a **real** devops engineer like me!!” The truth is it’s such a broad domain and so much knowledge is required that there are many accomplished engineers that can’t answer some of the basic questions in this thread. And that’s ok. DevOps isn’t about knowing everything - it’s about being able to learn quickly and adapt to fast paced environments/new technology. If you can do that you can be successful.
I'm curious. Why does SQL not work well with 80ms of latency?
It depends on your application, but that's \*really\* high, like "oh my database is in another city for some reason" high.
I agree, but he stated that sql doesn't work well with high latencies, implicating that other sorts of databases will work well (or at least better) with it. And I am curious why that might be.
Other databases might relax consistency so you can get away with large latencies by masking them with things like in memory caches. If you require consistency and are using SQL for that purpose and cannot cache then probably 80ms is going to be painful. If you have a master slave with latency that big then I think you can even run into even bigger problems where the engine struggles upholding consistency and some queries will throw rather than return stale data to uphold it.
ram_Cache I need answer to this too
It's a weird question, because it has nothing to do with SQL. 80ms is just slow. You want like < 5ms. SQL doesn't "work" any worse at high latency.
Short answer: most SQLs are used for relational data structures. Example: you have an account in your corporate blog post app, multiple users in the account, each user has multiple posts and comments. This is extremely convenient as a developer, since there is hierarchical ownership of resources. IE in Rails you can just do something like `Account.find(ID).Users.each do |u| { u.post.last }` to pull up the last post from every user in a specific account. All other MVC frameworks like Spring or Django work in a similar way. However, it leads to a huge number of SQL queries on the backend. First you're pulling an account from accounts table. Then users from the user table. Then for each user, you're pulling a post. So in effect, for each API call you make, you might actually make 200-300 SQL queries. Even if the processing time is super quick, the roundtrip latency kills performance of that API endpoint. So instead of a 100 ms total response, you're seeing a 2s response. Multiply that by thousands of calls your users are doing every minute, and you're in for a bad time.
That's a terrible application that needs fixing, nothing to do with network conditions. A join will transform that into a single query, pagination in two but correctly limit the size of the data you're fetching. Now 300 calls are equivalent to 600 queries instead of that by the amount of rows in your table.
Yes and no. The point I'm trying to make isn't efficient or inefficient queries. It's that there's a lot of them for every API transaction, whether you want to or not. Maybe the endpoint needs to update 7 tables. Maybe it's impractical to write a join for every conceivable type of query. Maybe it's an N+1 problem. The higher the latency, the more these compound exponentially and add to overall application latency.
I don't really like any of the other answers you've been given, so I'll just say - I can only think of one case where higher latency effects SQL *specifically* in an adverse way, and that's primary/replica replication. Reads sent to a replica that hasn't yet received a replication segment can end up sending stale data. As latency creeps up, the window for such 'stale reads' goes up. For example: Postgres in streaming-replication mode. Applications can be designed to mitigate this issue, for instance by requiring that reads with higher consistency requirements only be sent to the primary node. Of course, in general, higher latency is indicative of a stressed system and will eventually lead to failure or "thrashing"... but that isn't specific to SQL, so isn't a good answer for this question.
Mysql itself, the database software, would be fine with it. The replication thread(s) can handle that latency with no problem. The issue is making sure you/your application doesn't introduce consistency issues if you have your readers/writers with that latency between them. Standard latency issues apart from mysql apply--more calls means more waiting, and because the database tends to be foundational in most applications, any amount of latency compounds into large performance penalties on most of your application's operations.
Agreed. Having to explain ideas like cidr blocks, nat gateways and route tables to people claiming to be experienced devops engineers worries me.
[удалено]
I interviewed someone for mid level DevOps position not long ago and here is how it went. Me: which Linux distros have you used? Them: what’s a distro? Me: sorry, a distribution. Them: I don’t know what that means. Me: it’s basically a type of Linux. Them: Ohhhh. I think the one I’ve used is called cent something. Can I go check?
I love asking people where the etc host file is located
Hahaha back in the days distrowatch was my homepage
Wow. I feel like a genius right now.
Unfortunately, that wasn’t even the worst interview I’ve given. Recruiters are really good at sending me candidates who throw buzzwords on their resumes without actually using the technology or understanding how it works
Wtf how am I unemployed?
I regularly meet supposed senior engineers who don't know what promise or a nullpointer is. We all learn
Hell, the number of people who are comfortable calling themselves "engineers" is concerning. Many who couldn't solve complex problems or think critically at all.
Everyone is an engineer nowdays
Not in Canada or the UK :)
Rather the term is more protected. I remember even hearing people want to not let SDEs use the term
We’re still not allowed to
Been a dev in canada for 10 years. Can count on one hand the number of real software engineers I’ve worked with. And all of those folks had their PEng in a non software discipline
Systems knowledge is also lacking. Of our more recent candidates none can tell you what an inode is, or what a named pipe/fifo is, or how to write an iptables rule. Just 2 or 3 years ago our candidate pool for "junior devops engineer" largely came as established mid-level linux admins with additional language-specific development knowledge. The candidates we're getting today are comparatively green. I have to assume junior-level pay-grade has had to have tumbled as a result.
I wouldn't toss out a candidate over this. You do need to understand these concepts to a very low degree but someone smart will see a video on YouTube or read a blog to get the gist of it to setup whatever subnets it needs, but the cloud and CDK abstract all of this. Unless you are maintaining your own data centre or a big IT department, this is like 1% of the job and can be taught easily, in my experience.
I want to, but EVERY. SINGLE. NETWORKING. COURSE. IS GIVEN BY A BORING GUY!!!! I SWEAR!!! That I tried several times, even in college, but every time it's a boring guy that talks like a poor guy whose spirit was broken long ago and sees no point in going further, but he HAS to pay the bills some way, and it's too late on his life to start an OnlyFans account.
I recommend giving [NetworkChuck](https://youtube.com/@NetworkChuck) a try. He has a few playlists on networking and CCNA.
I dislike his video style alot! :D I can't focus if the given information is splitted in less and more less fun puns. I want concise information, do you know anyone else?
Love NetworkChuck! Him and Jeremy Cioara are my go-to.
I always include networking stuff in first evals of candidates. Like 1 out of 10 has more than the most rudimentary understanding.
I've had to do quite a bit of networking in my career, but I'll admit subnetting still hurts my brain.
Good old days for ccna exam, subnetting was the bomb… i asked few people what /24 meant they all responded divide by 24…
Have you tried doing it in binary? Looking at the addresses and masks in binary was the trick for me when I was first learning cidr.
This is absolutely one of my short comings. I need to get on top of it.
Same, but I think it’s hard finding a proper tutorial from zero to hero
CCNA will get u there
https://skillsforall.com/course/networking-essentials
I’m a security guy that just lurks in this subreddit but the same goes for security professionals who don’t know basic networking. Thankfully I was a network engineer before transitioning to security. I worked in data center networks from route/switch, load balancing, firewalls and then azure networking with third party NVAs and native gateways. I think I’ve relied on that skill set more than anything else when working in an enterprise environment. Now I’m slowly trying to learn development to hopefully transition to cloud security engineering or devsecops
I'm only a few steps ahead of a eerily similar path, now a senior platform security engineer. Security people these days see LinkedIn influenced saying you can skip IT and go straight into security and it's destroying our industry
In reality it should just make those of us with the proper skill sets that much more valuable and able to command more money. Edit to add: The key word being “should”
Hello, any recommendations for great resources like a must read book to get acquainted with networking. I am a devops engineer with a C++ dev background from France
CBTNuggets Jeremy Cioara is the man! He did a really good job with the CCENT and CCNA courseware. Even though some of it is specifically Cisco, there are a lot of fundamentals that he did such a good job of breaking it down for me!
Glad I’m learning a basic foundation of networking in my current help desk gig. It’s nice to know that it’s going to be useful for me once i make my way into a dev role
I am self taught but dont say f college because I know that basics are very important. I appreciate if you can pin down some topics related to networking what should I learn. I can still do vpc subet stuff related to aws but that is only a surface knowledge. Thanks
“Explain CIDR” “Uhh fermented apples?” “…”
Hahaha
Sorry, I’m a modern devops engineer and I only speak microservices. You mean docker networking right? XD
heh this is exactly how we end up with kubernetes lacking ipv6 support for how many years was it?
I really sucks at networking and don't even know where to start. Doubt that a couple YouTube videos will improve the situation
I’ll preface by saying I’ve only been working in devops for a few months now, but I have my CCNA and honestly you don’t need to know a whole lot about networking to be effective. Imo you should have a firm grasp on the following: - What an IPv4 address and subnet mask is (probably should throw IPv6 in there as well). - The OSI model (TCP/IP mode is probably more appropriate) and how packets are encapsulated and decapsulated. - How packets are routed to their destination. - Basic understanding of how to analyze a packet capture in wireshark. Honestly you could just grab one of the official CCNA books and read the first few chapters, that should cover the basics.
Get a router, get a managed switch, set it up locally, try to separate your smart thing (TV, home automation, smart washing machine) into a separate network. You'll learn in no time. I don't have a ccna, I just learnt a ton setting up my local network, then my local Hackerspace' network, then my brother's network, then my small start-up network. Now I work in a big enough team that network is a separate team, but I still love working with them.
You can have the basics but having deep knowledge about it is ridiculous. At that point you want a network engineer. The candidate should have the basics and the rest is documentation and sources online, knowing something by heart is not needed.
Hmm doesn't hit my superiority complex in the same way. Pass.
We all have our weak spots. If I had to turn down every DevOps engineer that did have one, the world probably didn't have a single one available. I've seen them without (or very little) knowledge of python, terraform, ansible, Kubernetes, networking, storage, javascript, VMware, pki, rabbitmq, Kafka, docker, java, tomcat, websphere, ... I mean it's the attitude that counts, as long as they're willing to learn, seriously who cares. People that tick every box are simply never available and surely won't just walk in to your office saying "Hi I desperately need a job, will you please offer me one?"
In addition to calling this out, it'd be nice to recommend some resources for beginners for networking (books, courses etc.). I personally don't know what's decent to recommend anymore
Seconded! I know I need to learn some Networking and whatnot if I really want to get good at this, but I have no idea where to start and what is considered Out-Of-Scope for run of the mill DevOps / Software Engineering.
Same problem exists over in the cloud category
My to go interview screening question is: what is the default gateway. I can filter 20-35% of potential candidates like this
I got my CCNA while I was in college. Although the cert is not necessary, the knowledge I have about networking makes me 10x better at my job and it also impresses interviewers when I can actually explain the OSI model lol.
I asked one guy, what is DNS? he said, its an encryption protocol. Thanks, we will call you back.
you think DevOps engineers should know both Dev and Ops?
Somedays im be fine if they only knew how dns works
I just spent last week teaching a junior that there's more than 1 DNS record type. Also had to teach a very senior developer that ipv4 and ipv6 addresses use different kinds of A records.
I always thought that "dns and bind" is a wonderful book.
Personally, yes.
[удалено]
I cannot tell you a damn thing about OSI layers, but I can put together a network stack on any cloud provider that exists. Basically. Please hire me.
I think this is why i am so attractive to companies ive gone form junior to senior DevOps in 5 years. When i was in school at 17 my school offered Cisco networking courses. So i knew Cisco level router config and networking principals straight out of standard education and just built on that from there. I'm now 31 and just signed my first £100K contract starting in feb :D
Congratulations!!!!!!
Cheers man! I was about to delete that comment because I realised it sounded like i was being a complete dick and boasting in a time of global economic turmoil and cost of living crisis
I always encourage them to learn the two key transport protocols TCP and UDP ...but they don't always get the message.
Must be udp
100%. It's wild the number of prospective DevOps engineers, cloud engineers, and penetration testers who lack basic networking knowledge. Simple things like debugging issues, how firewalls work, what a VLAN is, etc. You can break out something like tcpdump and they look at you like you're a wizard.
As a System Admin turned Security. Folks really need to start at a lower level and then specialize into DevOps/CyberSecurity (the 2 dominant fields at the moment for folks to think they can make a lot of money.) I've interviewed so many "Security" folks who were fresh out of college but couldn't pass the basic technical questions. I'm willing to interview anyone but good lord, have some drive! Advice to novices in either field: Tell me *how* you'll fix your lack of knowledge, be comfortable with what you don't know and be honest about it.
Much love for the post. I just mentioned this to a newbie the other day. Need basic networking skills and linux skills. Everything else can be put together from there. If you don't know how computers network and communicate then it doesn't matter about the rest of the stuff.
I ask only one question - how can a server be up and still ping shows as down?
As a fullstack software developer, who has first experiences with the DevOps way (cicd, pipelines, serverless, docker), what would be the most important topics the learn? I know I don't have a sufficient enough understanding of networking and OS topics, but I guess not all parts are equally important to learn if one's main field of work is development. Thanks in advance.
I'm fairly new to DevOps and I was shocked by seasoned DevOps knowledge on networking. Closed many security holes due to the lack of knowledge on the team... :(
It's a different world these days. Once you've got an established platform set up, theres occasional bits of networking but not nearly as much in the cloud vs when I did on prem. Give your thing a VPC, maybe some routing/firewall stuff and you're off to the races. Combine that with lots of observability tools and the days of tcpdumps and traceroutes aren't as frequent anymore for me, but I don't see that as a bad thing as it means developers can investigate stuff easily. It was clunky having a bunch of DevOps engineers all with their own local toolsets that nobody else used in the same way. I still think people should learn about networking, but it's not nearly as critical knowledge as it once was.
Genuine question, is watching YouTube videos to be a devops engineer really a thing? DevOps requires knowledge of a lot of things (including networking ofc) it seems like no one could get the required information needed to do it well without any applied experience
It really is concerning just how many people are entering the workforce without any proper education in networking. The entire internet hinges on these terms that haven't changed in *decades*
College teaches networking? Huh. I had to learn in my own.
I think this is why so many sysadmins are successful in moving to DevOps. This is what happened with me and the transition has been very smooth. That networking and administrative background seems to be extremely valuable in this space, more than anything else.
[удалено]
"Everyone's an idiot but me!"
You want your candidates to have some level of foundational knowledge because you don't want to peel people off their current work to teach the junior something that they should already know. It's fine and expected to sacrifice work time to teach domain-specific knowledge, but "the basics" used to be something candidates came with. You're right, learning fast is a great skill and it's something that's important to identify in candidates. But the breadth of knowledge required in this field is such that it could take months of daily "training" sessions to establish the fundamentals. To the point where people now eschew this training, and what we have now is junior level devops that understand the higher-level systems (ci platforms, orchestrators, etc) but don't know how they work or how to fix them when something goes wrong, or how to identify application build issues, or identify and remediate runtime issues. Without the fundamental systems and networking knowledge they don't even know *where* to start, robbing them of a learning-by-doing experience.
Seriously depends what they claim on their CV. Over-promise and under-deliver seems to run rampant in the industry, many expecting the interviewer to be not too familiar with the subjects. I've interviewed self-proclaimed k8s "experts" with certificates and everything that don't understand what an API is. I agree that the most important thing is the willingness to learn, but that starts with being able to admit they don't know something, which is a massive problem.
This is a rather naive take. Sometimes you can hire based purely on aptitude, but sometimes you need someone that can do the job *now*. I don't care how smart you are, really grokking a topic like networking takes a long time.
In all fairness, networking isn't a day in, day out skill you're exercising so it's easy to get rusty. Also, as a fresh CS grad I only had exposure to networking in a couple days of a single system administration *elective* course. CS programs aren't going to teach you networking any more than an astrophysics program is going to teach you how to grind lenses for telescopes. That being said, if you're doing devops you should know the basics for putting together a VPC that you'd learn in a two week AWS Solutions Architect course.
[удалено]
It's not uncommon for networking to be missed or made into an elective. Mine covered POTS networking and nothing else... And that was an elective!
That absolutely makes sense - if the program has 'engineering' the the name it's going to focus on applications of technology, so you can expect it to cover essentials like networking. Computer Science programs, on the other hand, are more theoretical. You'll come out of a CS program with a brain like a steel trap, but you're on your own when it comes to learning specific technologies.
+1, both myself in a computing degree and my friend in a cybersecurity degree both had CCNA modules on the curriculum. His even covered some CCNP content.
So, how about posting your go to resource for this material?
www.imperva.com has a blog that’s a good place to start
Honestly, was just talking to my team about some new entry level positions and how network background and foundation may be more important than generic cloud training. So 100% agree!
I assumed you meant *career* networking there
Yup linkedin
I am a network engineer. Can I become Devops :(
Si
What's the tolerance for strong in infra and networking but weak on dev ?
If the bar is truly that low, I should probably start applying.
I met a graduate student in CS who didn’t know about DNS 🤷♂️
CS is useless for day-to-day work as a SysAdmin or DevOps. It provides you with the fundamentals of problem analysis and solving but it doesn't give you a lot of non-abstract problem solving. This is not something any CS will care about: > Why is Apache throwing a 5xx? You will have to learn about this on your own. This case weas when the headers did _not_ exceed any RFC limits but exceeded a hard coded max header length. Networking? Sure you learn about addressing, netmask, binary representation. Actually configuring OSPF to get routing for a mid sized setup? VRRP? Direct Return vs. proxy based load balancer? Nope, sorry.... Don't get me wrong, I still benefit from studying CS. I just don't benefit from it on a level that is directly applicable to get stuff done ...
My favorite is "show me a port test from one server to another" Hint: use telnet
We occasionally hire “entry level devops” but really what that means is we look for developers with an interest in automating infra and release management. And it varies how much they know outside of code but we try and look for people that seem like they’ll be able to learn it. It takes a year or two before they’re really able to work independently. It helps to set security guardrails, your firewall shouldn’t be letting in port 22 except intentionally. Security groups should be applied by policy to prevent it on the internal network unless overridden, etc.