by ilhicas on 8/11/19, 1:51 PM with 78 comments
by TurboHaskal on 8/11/19, 6:29 PM
- Forget what the books said, theory, semantics and idealism. You are a DevOps Engineer, working in a platform specific team.
- You deal with Jenkins or similar, and consult other teams or developers to write scripts for it, or worse, do the work for them since they're too busy doing actual programming.
- Contrary to what they say, other than tiny scripts you are not programming much anymore, unless you consider configuration management to be programming.
- You are not allowed to come up with your own abstractions. Proposals to develop anything are automatically declined by your Product Owner, who simply points you to whatever tool with a fancy logo he could find listed in the Cloud Native Computing Foundation.
- You pride yourself for being an engineer, but decisions end up being only made in terms of getting free open source labor and ease up hiring, so you end up doing what everyone else is doing.
- Half of your team co-workers are perfectly fine dealing with churn, software updates and other sort of manual, classic sysadmin tasks.
- You are repeatedly being paged at night for problems that your fellow developers won't feel responsible for. You hear buzzwords and talks about this SRE thing or "you built it, you run it", but it never seems to materialise due to politics.
- You are getting a feel that cloud providers are not really making things easier nor cheaper.
It used to be a lot of fun back in the day, and a great chance to get paid to solve interesting problems related to system and infrastructure engineering instead of the boring CRUD work that plagued the last decades, but seeing the "App Store" that this turned into, if you are a creative individual with a software engineering background and you're considering a career in DevOps, my advice is to run away while you can.
by 1337shadow on 8/11/19, 4:50 PM
A sort of extension of the Lean System where workers from different areas share a common goal of delivering value to the final customer (in production), the same card may require a backend dev, frontend dev, and an ops to share the goal to take this card from idea to production, and then monitoring how it behaves in production.
For people who have not read the same books, "DevOps" mean things like "applying dev method in the operation field" ie. with ansible and the likes, coding the infra. After all, that's what that word seems to mean at first glance.
This reminds me of the term full-stack, some people consider it's just about being good at both frontend and backend, in my opinion a good full-stack is also a good networking engineer as well as good at customer acquisition.
For best ROI:
- integration must be automated and continuous
- delivery must be automated and continuous
- tech debt includes untested code and being late in dependency versions
- the above should be treated as impediments
The purpose of "DevOps" being to deliver faster from idea to production, it does necessarily include a toolchain of CI/CD/IaaS & monitoring tools. From this "DevOps toolchain", taylorists opened positions for developers that can maintain it around a software, they called that position "DevOps", which explains how we got there on having different meanings for the same word.
I highly recommend "Continuous Delivery & DevOps: QuickStart" by Paul Swartout for a first quick read on the matter.
by solatic on 8/11/19, 7:37 PM
* Systems knowledge through the lens of Conway's Law: what does an ideal even look like in terms of organizational efficiency
* Leadership to get disparate teams in an organization to cooperate instead of compete
* Technical competency to help disparate teams adopt the principles, because telling people on the fence to "go Google it" is a plan for failure
People who get bogged down in CI/CD/IaC/containerization miss the forest for the trees and it's why most organizations never see any value out of their DevOps initiatives. If you don't know what to automate then WIP increases your costs. If you don't have leadership on board then you can't reorganize teams to prevent "cycles" and re-work inside the "factory". If you don't have technical competency then you have people re-inventing the wheel, poorly.
You need all three.
by eropple on 8/11/19, 4:55 PM
Elsewhere in the thread, 'somepig notes that this sounds like what a sysadmin does. I replied there because, just as you shouldn't call yourself a programmer[0], calling yourself a sysadmin is probably similarly mindset- and career-limiting, but I kind of have a bigger beef with calling this "consulting" than I do "devops". Of course this stuff is "devops", but--"properly" applied (and I scare-quote the word because you can call damned near anything "devops", up to and including "the development team hurls a tarball over the wall at some sysadmins in the basement and flees at top speed")--it's not consulting. It's a list of hands-on work. There's only a cursory nod to the most important part of any devops-facilitating role (whether it's called an SRE, an "infrastructure engineer", a "devops engineer", whatever): alignment of technical initiatives with business needs.
I don't mean to be harsh in saying this, but if you're spending most of your time in the code mines grinding at this or that, you may not be a great "devops consultant". You might be a great infrastructure developer or SRE. But in my neck of the woods at least, clients hired me to make sure they were doing the right thing and to make sure that their employees were adequately prepared for the workflows they wanted to implement, not to do last-mile CI/CD computer touchery. (Which I'd do as well, of course, when time allows--but there's more value in being a multiplier than an adder, and at the rates I charged I'd better be the biggest multiplier I could.)
[0] - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
by benjaminwootton on 8/11/19, 5:53 PM
I’ve always been comfortable with the idea of DevOps as a role. If you work on Terraform, CI/CD, container platforms etc and have knowledge of both Dev and Ops practices and engineering mindset then it seems like a fine label.
We really took a bet in the early days that DevOps as a discipline as well as an operating model and culture would emerge. We are now approaching 400 people so we are happy with how it’s playing out. I think it’s very early days too.
by tyingq on 8/11/19, 4:17 PM
What's described is very much like what a sysadmin was in the 90's, prior to more specialized roles.
by InternetOfStuff on 8/11/19, 4:40 PM
by specialist on 8/11/19, 7:25 PM
Best I can tell, like Agile Methodology, Skype, and open offices, "DevOps" is edgy jargon the financial people came up with to screw us knowledge workers.
I imagine myself trailing a parade, wearing oversized shoes, a rainbow fro, painted on happy face, and red nose, pushing a wheel barrow, scooping up the messes left by horses and elephants.
Some orgs seem to have figured out how to turn lemons into lemonade. That dude from Gilt has a "Test Into Prod" thesis that seems to square the circle. (I can't say from personal experience, but someday hope to work somewhere willing to try it.)
by nodesocket on 8/11/19, 9:34 PM
The majority of my time is either wrangling AWS, GCP or in tools such as Packer, Terraform, Ansible, Docker, Kubernetes, and writing bash scripts. I prefer DevOps now to writing traditional code as it is less down in the trenches nitty gritty code/math/logic and more higher level architecture and applying changes. I think it lends itself toward a slightly different personality type than a software developer.
by chupasaurus on 8/11/19, 4:53 PM
> knowing a triple A (Authorization, Authentication and Access Management) solution
AAA is Authentication, Authorization and Accounting.
edit: formatting
by bigbluedots on 8/12/19, 5:26 AM
by pjzedalis on 8/11/19, 6:10 PM
The complexity and problem solving of the job is not automating some widget or service. That is very easy and not a challenge to someone with a deep programming background. The challenge is knowing what to build to a) enable developer productivity and flexibility to b) increase development speed to c) provide products/services the business side can iterate on quickly while d) not completely destroying the infrastructure and lessons learned that already exist and e) providing training and leadership to system admins and developers not used to these processes.
by mrmondo on 8/12/19, 2:28 AM
https://smcleod.net/tech/2019/08/08/camels-and-unicorns.html
by NicolasCornwall on 8/11/19, 8:24 PM
I consider my duty as 50% as consultant regarding DevOps culture and agile culture and to 50% "building pipelines and all that automation stuff" This shows quite clearly how DevOps as a term is used in Germany. Either the fusion of responsibility of Dev and Ops is meant or just someone who does this modern cloudy stuff One thing I really like in the DevOps space is that I never had a problem with the tech stack at a customer. Some want more cloud, some more pipelines, some more infrastructure, still I could do every project and never had problems with my qualification. So when I have calls from recruite I kinda skip the tech stuff, since it won't be the issue anyway. I'm more intersted in how much the company really does DevOps and Agile. I just recently declined a job opportunity bc the company wanted to buy this modern DevOps stuff but actually couldn't risk an actual change.
The customer I currently working for is a mess. It's a middle sized company who has to finish 3 projects at the same time and do neither the "new world" nor the "old world" They overthrown a lot of the old world rules and took a lot of power from the project managers. But what they are doing now is taking random parts of the new world and implement it in a broken way and say "we are modern!" Like this they are doing neither of it and they end up with basically just chaos. Companies often want a change without having a change. And for me it's kinda annoying to run against corporate walls, when I was hired (as an expensive external!) to solve those problems but then getting ignored. So they throw more people at the problem and just churn them. As you guys already know, what 1 guy in IT can do within 1 day, 2 guys can do it in 2 days.
P.S.: I'm planning to relocate from germany to NY. If someone needs a DevOps, give me a shoutout to: jjdjnrjfifj@gmail.com Also open for non-work contacts. Don't want to be alone in NY
by hydesnark on 8/11/19, 10:35 PM
That’s DevOps.
by matthewcanty on 8/11/19, 4:32 PM
by hosh on 8/11/19, 5:23 PM
The single-most useful skill I have used is problem solving in an unknown context. Knowledge of architecture patterns help a lot in both cases. There have been times when I have had to read code just to figure things out.
There was a technical interview for a devops role I did recently. Whomever designed it was brilliant: a deceptively simple task (install an obscure blogging platform and get it running) with many hidden landmines and gotchas, compressed into 45 mins. Just another day at work.
by denimnerd42 on 8/11/19, 5:26 PM
by brew-hacker on 8/12/19, 11:50 AM
DevOps engineers are thought as limited to CI/CD or infrastructure management. I would 100% consider them to be able to pick up development and understand the full stack (including networking, database management, etc.).
Kudos to you and others that expand "DevOps" to be more than just a simple shift of SysAdmins to Cloud.
by asplake on 8/11/19, 4:15 PM
by jhayward on 8/11/19, 4:49 PM
It gives just the right characterization of qualification - "I've used it and been paid. I'm not necessarily an expert" - needed when living in a rapidly churning set of technology ecosystems.
by otabdeveloper4 on 8/11/19, 4:50 PM
by soupdiver on 8/11/19, 7:20 PM
by m0xte on 8/11/19, 6:11 PM
by the_70x on 8/11/19, 6:15 PM
by c3534l on 8/11/19, 6:15 PM
by mishingo on 8/11/19, 4:33 PM
It makes it more manageable to juggle the diverse work we are responsible for in a "DevOps" role.