41–50 of 50 posts
Earlier quoted context omitted.
Although I get your point, fundamentally DevOps tools exist because shell scripting is so bad.
Now shell scripts are called from containers as defined at ci-cd.yaml
As someone that has never worked at a startup before, this seems to be the list of skills a startup might find reasonable for a 'DevOps Engineer'. Every other place I've interviewed or have worked has DevOps Engineer and Site Reliability Engineer being distinctly different roles (SRE focusing on monitoring and logging and DevOps engineer focusing on pipeline and build). There are also other places like where I am now…
As a careerlong DevOps guy, I’ve heard many times that “if your job title has DevOps in it, your company is doing DevOps wrong” – overwhelmingly from people with “DevOps” in their job title, delivered with a mordant laugh.
I'm not sure if this is the exact curriculum I'd pick but I do think it's one of the easier jobs to 'learn' and get a well paying job doing. If you want to get hired at Google (for example), one thing I think that is overlooked is that the SRE-SE interview is actually a lot more sane than the puzzles you see in the software one in terms of practicality, relationship to actual work, and 'learnability'. To have a prett…
It's pretty much shell scripts all the way down folks. Its all shell scripts being used abused wrapped invented and reinvented.
Seriously tho, I stepped to next level when I started doing Boto stuff in Python.
ill never get why people punish themselves with this devops shit. you could just learn 1 thing (networking) on a few vendors (cisco, juniper, whatever), pass a few tests and be making good money out the gate. i feel like devops is just a bucket for lost souls who like tech stuff. am i crazy?
Earlier quoted context omitted.
That's both true and a lie. It's true in that people can't agree on what words mean and slap them on anything, and it's a lie that it is ops/sysadmin, because it's not.
What’s the difference? Ops and sys admin has always been about automation at scale and monitoring.
Keep in mind that "ops" and "admin" really depends on 'how much you have', a half rack of hardware was also managed by "ops" and "admin", and generally bootstrapped by hand and maintained with individual remote access or kludges like cssh/pssh. Even legacy systems like puppet were mostly used in the context of cluster management, not an entire fleet of mixed systems. There was no API for any of this either, so any programmatic access had to traverse layers of incompatible proprietary systems.
Developers did (and do) none of this. This work hasn't disappeared or changed much, and also isn't part of the DevelopmentOperations amalgamation. The grey area that it creates used to be the realm of release engineers and technical application operators. Those are the roles that have largely disappeared when an environment goes from legacy to more modern organisational structures.
This overlap (and the legacy disaggregation and hyper-specialisation) exists for a reason: developers that don't have to wait to deploy and instrument can release faster and more often, which adds value. But specialisation to enable developers to do all this is now needed because that extra value that was created now needs to be protected and enabled at scale, something that is enough work to keep one or more FTE busy. This is where specialisation (in a business context) comes from in general. If administrating systems and operating those systems was a very small task and easy to learn, there would be no sysops/sysadmin specialisation and the janitor would do it.
Earlier quoted context omitted.
What’s the difference? Ops and sys admin has always been about automation at scale and monitoring.
Not really, it has mostly been about managing operating systems and servers, not much else. There was a whole mess of homegrown scripts, and the PXE mess, and an even worse IPMI mess. Keep in mind that "ops" and "admin" really depends on 'how much you have', a half rack of hardware was also managed by "ops" and "admin", and generally bootstrapped by hand and maintained with individual remote access or kludges like cs…
Even in the mid 90s when I worked on backend mainframe systems for lotteries, everything except physically changing out tapes and malfunction hardware was automated.
There has been an API to manage networked servers since networking existed.
The value add of DevOps was suppose to be developers and operations working together. When I develop something. I always do it with a mindset of how will it be deployed, scaled, monitored, etc
If “DevOps” is a role instead of an institutional behavior, you get none of those benefits.
And yes I know “Devops” [sic]. My day job is consulting companies on how to bring modern development and cloud operations, networking, CI/CD, monitoring, aggregate logging, etc together. I work up and down the stack from an empty AWS account to back end development and if you put a big enough gun to my head, I’ll deal a little with the clusterfuck of front end development