16 ms·

What I Do as a DevOps Consultant

211 points by ilhicas 7y ago

asplake 7y ago
“a DevOps”
- meddlepal 7y ago
  One DevOps please.
  - smacktoward 7y ago
    "Sir, please drive through, this is a Burger King."
- jascii 7y ago
  He is not a native english speaker. What is your excuse? I find it somewhat ironic that you criticize someone else's language yet cant seem to be able to construct a full sentence..
tyingq 7y ago
"I’m not your...Sysadmin or other common role" What's described is very much like what a sysadmin was in the 90's, prior to more specialized roles.
- ilhicas 7y ago
  Dont read diagonally please. I never said i dont end up doing sysadmin/ops work
  - ilhicas 7y ago
    But yes. The devops movement is actually here to bring the 90s back when we didnt specialize to an extent where silos are created and the gaps between teams get in the way
    - somepig 7y ago
      it never left. you've just been blissfully unaware of it, and now that you've discovered it, you think it is new for everyone. everything in this article is what I do as a sysadmin. part of being a sysadmin is practicing devops. not the other way around
      - eropple 7y ago
        Like it or not, vernacular changes. Today, in most contexts, "sysadmin" suggests (at worst) a Windows pusher armed with a mouse and (at best) a heads-down computer toucher (which is also what this "devops consultant" document seems to outline, really, so you're not wrong!). You're totally right in that sysadmins can certainly practice (part of) devops, but anywhere I've ever gone it's less the rule then the exception and "sysadmin" is a career-limiting classification, akin to calling oneself a programmer [0]. Ends, not means, etc. [0] - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
        somepig 7y ago
        certainly won't disagree that it can be limiting to folks of some perspectives, but as someone who publicly has applied the sysadmin label for the duration of their career (starting in the early 00's), I've yet to see a downside. I've been obscenely compensated for working on interesting projects for much of my career. then again, part of it may be due to the confidence that comes with focusing on my work instead of fluffing my title.
        eropple 7y ago
        You also, candidly, may be experienced enough and have enough time-served to get away with it. ;) There's definitely an effect--I kinda want to call it a thermocline?--above which your actual achievements can speak for themselves, particularly if you've built a solid network. Today, if I had a notion to, I could probably call myself a "sysadmin" and not have trouble finding well-compensated work. But when I was freelancing, as well as when I was earlier in my career, I can tell you a lot of doors would have slammed right shut had I used the term regardless of my capacity. I do not particularly love the term "devops", but at this point its umbrella at least encompasses what we (like, you and I, not the general we) think about when we're doing this stuff, and it has a certain amount of loaned--or stolen--credibility. As I said in a top-level comment, I'm more twitchy at this description of being a consultant than I am at the devops part.
  - deleted 7y ago
    [deleted]
- chrissoundz 7y ago
  I'm someone who kind of skipped the whole sysadmin thing and went straight to 'devops'. I think it's exactly the same thing - just with containers, docker, Kubernetes, build pipelines and so forth. A better name might just be modern-sysadmin or sysadmin v2.
matthewcanty 7y ago
I particularly agree with the scripting nature of the role. I’ve played a major part at my company using many of the tools you mention to set up IaC/CICD/etc. However, day-to-day I’m in script land, which is where I want to be really.
mishingo 7y ago
Now with the advent of software such as Rundeck, the majority of tasks and automation can be consolidated into a singular control panel. Now I focus more on project based work and reduce time fumbling with random annoying tickets. It makes it more manageable to juggle the diverse work we are responsible for in a "DevOps" role.
- zbentley 7y ago
  It is customary on HN to disclaim when you work for/on a product that you are pitching or suggesting.
InternetOfStuff 7y ago
I wish the idea that DevOps was a role or activity would die.
- eropple 7y ago
  Upon joining my current company, I renamed the team that I lead "infrastructure" for exactly this reason. That team was not a "devops" team except insofar as things were getting hucked over the wall and they necessitated some dev out of the ops folks. My role here is arguably a more integrated one where we're working towards a devops-flavored culture, and the infrastructure team here is part of it: "we maintain the roads and set up the water mains and keep the power lines from falling down, but hooking up your house to power and electric and making sure it doesn't catch on fire--that's your responsibility."
- whalesalad 7y ago
  Agree. It is a mindset/lifestyle/approach.
- nhumrich 7y ago
  I wish the insistance on devops not being a role, because of pedantics, would die. Yes we all know devops is a culture. But we also know its a role. Someone has to drive the culture. HR people are now calling themselves people operations, sales teams have sales operations aka salesops. Its not farfetched to have devevelor operations, aka devops as a role. Lets accept that both the role and culture exists, and move on.
jhayward 7y ago
I appreciate the "I've had contact with <technology>" phrasing used here. 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.
otabdeveloper4 7y ago
"DevOps" == "sysadmin that can write scripts"
- goatinaboat 7y ago
  Or “a developer that does on-call” I’m being facetious. Sysadmins always wrote scripts and developers always got called at home.
  - emmelaich 7y ago
    The best always did. Many of the rest did, but not high quality scripts, and only in shell; not perl or python or tcl or ... The lower rungs of sysadmin were happy to point and click on guis and lug and plug hardware.
    - otabdeveloper4 7y ago
      Yes, "DevOps" is basically an attempt to weed out the best sysadmins from the rest in the job market, because if you look for 'an experienced sysadmin' you'd usually find a guy who laid cables and replaced mice for 1000 Windows workstations instead of 10.
- bdcravens 7y ago
  Somewhat, but I also think it means there's a less of a boundary between the product development and the product deployment than in the past.
1337shadow 7y ago
"DevOps" used to be a methodology where a Dev and an Ops share a same goal of delivering value into production, at least, that's in the book I have read. 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.
- eropple 7y ago
  > But I don't think you'd be doing "DevOps" all by yourself, unless you are what I call a full-stack, good at: communication, frontend, backend, and networking. This is pretty much how I sum up what you'd have to be to be "a devops engineer": an actually-full-stack developer with a strong facility for communication and for process. Such folks are hard to find. I only know a few, out of the dozens of folks I've worked with.
  - 1337shadow 7y ago
    They are rare because it takes like 15 yrs of day and night hacking & learning from books that range from software to sales, through system & networking and communication, and found ways to practice, not something many people are both willing and able to do.
chupasaurus 7y ago
Lack of monitoring is scary. > knowing a triple A (Authorization, Authentication and Access Management) solution AAA is Authentication, Authorization and Accounting. edit: formatting
eropple 7y ago
This article makes me...itchy. For background, I've been running SRE/infrastructure/"devops" teams for the last couple years, hung out my shingle as an independent consultant before that, and worked at a fairly large company as what we'd have called an SRE if the term had been a thing yet. And to me, feels like a lot of missing forests for trees. 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-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
- diamondo25 7y ago
  Though there's also the other side of the coin, people picking up a tech because they read about it, which ends up in the core business, without good rationale for the tech other than "i found it on the internet". This blog post really reflected my background, with most of the tech used being the same. However, most of the experience is by cleaning stuff up. I see stuff being used too many times that are not performant, effective or incorrectly configured due to people not taking care of said tech. Especially in the Javascript business. It is cleaning up tech debt that might not make cash in the short term, but many companies have it as a burden in one way of another and someone willingly to clean that mess up is very valueable, imho.
hosh 7y ago
That is in alignment with the work I have done as a “devops” person. I have also worked as doing primarily backend development. 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.
denimnerd42 7y ago
devops in my department means developers they push into a full time support role to fill out release paperwork, oversee manual regression tests, and fix production failures.
benjaminwootton 7y ago
I founded a DevOps consultancy (Contino.io) and have been involved in hundreds of DevOps engagements. 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.
pjzedalis 7y ago
DevOps in my experience often stems from a breakdown of communication/trust between management and developers. Software production and deployment complexity has outpaced the deliverable(s). Traditional IT system admins struggle to keep up with deployments that are way beyond ftp/sync tools. Simultaneously developers are creating microservices each with independent multi-step build processes. 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.
m0xte 7y ago
Fix my tools instead of the product.
the_70x 7y ago
convincing my boss to let the machines and our code to do our job
c3534l 7y ago
To everyone in this thread: this is an article, not a question to HackerNews.
TurboHaskal 7y ago
In practice, and talking from my experience, unless you're one of the lucky few this is what it really means to do DevOps in 2019: - 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.
- fred_is_fred 7y ago
  This is so accurate it makes me want to cry. Devops has become "run Jenkins & take page outs". 99.99% of enterprise devs (99.99% of those code in Java) have 0 clue what happens to their code after they commit it to Stash, and worse yet, they don't want to know. It's so bad now I'm embarrassed to have it on my LinkedIn profile.
- dec0dedab0de 7y ago
  My company calls what I do DevOps but I write full stack webapps to support the network operations team. I prefer to call it OpsDev, but noone seems to agree with me.
soupdiver 7y ago
Nice article! I also do consultancy in that field and your article describes my work situation by 90%
specialist 7y ago
The times I've been stuck doing "DevOps", I mostly rue the loss of the quality assurance culture (values) we once had. 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.)
solatic 7y ago
Great DevOps practitioners are rarer than 10x engineers. It's the combination of: * 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.
- freehunter 7y ago
  At my day job I have a "devops" guy who is all-in on "devops". By which I mean he wants everything run through a CI/CD workflow, committed into change control, with passing unit tests, and tasks passing through a Jenkins pipeline. Did I mention we are information security consultants and work in neither dev nor ops? Yeah he wants our powerpoint slides checked into change control. I'm not joking.
  - mixmastamyk 7y ago
    I put docs in vcs, it is convenient. But, binary formats are less useful.
  - pts_ 7y ago
    At least put it in a CMS. Managing docs is so absent in workflows.
NicolasCornwall 7y ago
I'm a freelance DevOps consultant working in Germany 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
- tn890 7y ago
  I've been hopping from one DevOps role to another for the past 4-5 years and I've been meaning to get into freelancing recently. However, in my experience, I find that projects are incredibly hard to acquire, especially if it's your first freelance gig. Do you happen to have any advice for me on how to get into DevOps freelancing, particularly how to acquire projects? Thanks
nodesocket 7y ago
I founded and run a DevOps consultancy (Elasticbyte.net) and fundamentally the biggest difference between daily DevOps work and typical software engineering is tooling. DevOps is all about the tooling, knowing which ones to use, and organizing and memorizing lots of details. 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.
hydesnark 7y ago
Remember that scene in Back to the Future 2 at the Enchantment Under the Sea dance when 1985 Marty had to somehow neutralize Biff’s thugs from the catwalk before they jumped 1955 Johnny-B-Goode-playing Marty, all while trying to avoid seeing him or else the universe would explode in a space-time paradox? That’s DevOps.
mrmondo 7y ago
Just recently I wrote a brief post about how the title of ‘DevOps Engineer’ (and similar) were irking me, especially when looking for new roles / opportunities. DevOps isn’t a job title - it’s a culture and making click-bate / hipster job titles isn’t helping recruiters or business gain the value or plug the gaps they need: https://smcleod.net/tech/2019/08/08/camels-and-unicorns.html https://smcleod.net/tech/2019/08/08/camels-and-unicorns.html
bigbluedots 7y ago
One of the coolest things about devops is that nobody seems to agree on what it is, and articles like this one elicit many different opinions. So here's mine: devops is infrastructure as code, where code in this context is something that is checked in to an scm and is really more like configuration. It is not software development, which is more likely done by software developers. I'm still not sure where the 'dev' part came from.
brew-hacker 7y ago
Personally - I would consider some of the best DevOps engineers as the best generalist engineers around. 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.

211 points by ilhicas 7y ago

asplake 7y ago

“a DevOps”

meddlepal 7y ago
One DevOps please.
- smacktoward 7y ago
  "Sir, please drive through, this is a Burger King."
jascii 7y ago
He is not a native english speaker. What is your excuse? I find it somewhat ironic that you criticize someone else's language yet cant seem to be able to construct a full sentence..

tyingq 7y ago

"I’m not your...Sysadmin or other common role" What's described is very much like what a sysadmin was in the 90's, prior to more specialized roles.

ilhicas 7y ago
Dont read diagonally please. I never said i dont end up doing sysadmin/ops work
- ilhicas 7y ago
  But yes. The devops movement is actually here to bring the 90s back when we didnt specialize to an extent where silos are created and the gaps between teams get in the way
  - somepig 7y ago
    it never left. you've just been blissfully unaware of it, and now that you've discovered it, you think it is new for everyone. everything in this article is what I do as a sysadmin. part of being a sysadmin is practicing devops. not the other way around
    - eropple 7y ago
      Like it or not, vernacular changes. Today, in most contexts, "sysadmin" suggests (at worst) a Windows pusher armed with a mouse and (at best) a heads-down computer toucher (which is also what this "devops consultant" document seems to outline, really, so you're not wrong!). You're totally right in that sysadmins can certainly practice (part of) devops, but anywhere I've ever gone it's less the rule then the exception and "sysadmin" is a career-limiting classification, akin to calling oneself a programmer [0]. Ends, not means, etc. [0] - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
      - somepig 7y ago
        certainly won't disagree that it can be limiting to folks of some perspectives, but as someone who publicly has applied the sysadmin label for the duration of their career (starting in the early 00's), I've yet to see a downside. I've been obscenely compensated for working on interesting projects for much of my career. then again, part of it may be due to the confidence that comes with focusing on my work instead of fluffing my title.
        eropple 7y ago
        You also, candidly, may be experienced enough and have enough time-served to get away with it. ;) There's definitely an effect--I kinda want to call it a thermocline?--above which your actual achievements can speak for themselves, particularly if you've built a solid network. Today, if I had a notion to, I could probably call myself a "sysadmin" and not have trouble finding well-compensated work. But when I was freelancing, as well as when I was earlier in my career, I can tell you a lot of doors would have slammed right shut had I used the term regardless of my capacity. I do not particularly love the term "devops", but at this point its umbrella at least encompasses what we (like, you and I, not the general we) think about when we're doing this stuff, and it has a certain amount of loaned--or stolen--credibility. As I said in a top-level comment, I'm more twitchy at this description of being a consultant than I am at the devops part.
- deleted 7y ago
  [deleted]
chrissoundz 7y ago
I'm someone who kind of skipped the whole sysadmin thing and went straight to 'devops'. I think it's exactly the same thing - just with containers, docker, Kubernetes, build pipelines and so forth. A better name might just be modern-sysadmin or sysadmin v2.

matthewcanty 7y ago

I particularly agree with the scripting nature of the role. I’ve played a major part at my company using many of the tools you mention to set up IaC/CICD/etc. However, day-to-day I’m in script land, which is where I want to be really.

mishingo 7y ago

Now with the advent of software such as Rundeck, the majority of tasks and automation can be consolidated into a singular control panel. Now I focus more on project based work and reduce time fumbling with random annoying tickets. It makes it more manageable to juggle the diverse work we are responsible for in a "DevOps" role.

zbentley 7y ago
It is customary on HN to disclaim when you work for/on a product that you are pitching or suggesting.

InternetOfStuff 7y ago

I wish the idea that DevOps was a role or activity would die.

eropple 7y ago
Upon joining my current company, I renamed the team that I lead "infrastructure" for exactly this reason. That team was not a "devops" team except insofar as things were getting hucked over the wall and they necessitated some dev out of the ops folks. My role here is arguably a more integrated one where we're working towards a devops-flavored culture, and the infrastructure team here is part of it: "we maintain the roads and set up the water mains and keep the power lines from falling down, but hooking up your house to power and electric and making sure it doesn't catch on fire--that's your responsibility."
whalesalad 7y ago
Agree. It is a mindset/lifestyle/approach.
nhumrich 7y ago
I wish the insistance on devops not being a role, because of pedantics, would die. Yes we all know devops is a culture. But we also know its a role. Someone has to drive the culture. HR people are now calling themselves people operations, sales teams have sales operations aka salesops. Its not farfetched to have devevelor operations, aka devops as a role. Lets accept that both the role and culture exists, and move on.

jhayward 7y ago

I appreciate the "I've had contact with <technology>" phrasing used here. 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.

otabdeveloper4 7y ago

"DevOps" == "sysadmin that can write scripts"

goatinaboat 7y ago
Or “a developer that does on-call” I’m being facetious. Sysadmins always wrote scripts and developers always got called at home.
- emmelaich 7y ago
  The best always did. Many of the rest did, but not high quality scripts, and only in shell; not perl or python or tcl or ... The lower rungs of sysadmin were happy to point and click on guis and lug and plug hardware.
  - otabdeveloper4 7y ago
    Yes, "DevOps" is basically an attempt to weed out the best sysadmins from the rest in the job market, because if you look for 'an experienced sysadmin' you'd usually find a guy who laid cables and replaced mice for 1000 Windows workstations instead of 10.
bdcravens 7y ago
Somewhat, but I also think it means there's a less of a boundary between the product development and the product deployment than in the past.

1337shadow 7y ago

"DevOps" used to be a methodology where a Dev and an Ops share a same goal of delivering value into production, at least, that's in the book I have read. 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.

eropple 7y ago
> But I don't think you'd be doing "DevOps" all by yourself, unless you are what I call a full-stack, good at: communication, frontend, backend, and networking. This is pretty much how I sum up what you'd have to be to be "a devops engineer": an actually-full-stack developer with a strong facility for communication and for process. Such folks are hard to find. I only know a few, out of the dozens of folks I've worked with.
- 1337shadow 7y ago
  They are rare because it takes like 15 yrs of day and night hacking & learning from books that range from software to sales, through system & networking and communication, and found ways to practice, not something many people are both willing and able to do.

chupasaurus 7y ago

Lack of monitoring is scary. > knowing a triple A (Authorization, Authentication and Access Management) solution AAA is Authentication, Authorization and Accounting. edit: formatting

eropple 7y ago

This article makes me...itchy. For background, I've been running SRE/infrastructure/"devops" teams for the last couple years, hung out my shingle as an independent consultant before that, and worked at a fairly large company as what we'd have called an SRE if the term had been a thing yet. And to me, feels like a lot of missing forests for trees. 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-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

diamondo25 7y ago
Though there's also the other side of the coin, people picking up a tech because they read about it, which ends up in the core business, without good rationale for the tech other than "i found it on the internet". This blog post really reflected my background, with most of the tech used being the same. However, most of the experience is by cleaning stuff up. I see stuff being used too many times that are not performant, effective or incorrectly configured due to people not taking care of said tech. Especially in the Javascript business. It is cleaning up tech debt that might not make cash in the short term, but many companies have it as a burden in one way of another and someone willingly to clean that mess up is very valueable, imho.

hosh 7y ago

That is in alignment with the work I have done as a “devops” person. I have also worked as doing primarily backend development. 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.

denimnerd42 7y ago

devops in my department means developers they push into a full time support role to fill out release paperwork, oversee manual regression tests, and fix production failures.

benjaminwootton 7y ago

I founded a DevOps consultancy (Contino.io) and have been involved in hundreds of DevOps engagements. 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.

pjzedalis 7y ago

DevOps in my experience often stems from a breakdown of communication/trust between management and developers. Software production and deployment complexity has outpaced the deliverable(s). Traditional IT system admins struggle to keep up with deployments that are way beyond ftp/sync tools. Simultaneously developers are creating microservices each with independent multi-step build processes. 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.

m0xte 7y ago

Fix my tools instead of the product.

the_70x 7y ago

convincing my boss to let the machines and our code to do our job

c3534l 7y ago

To everyone in this thread: this is an article, not a question to HackerNews.

TurboHaskal 7y ago

In practice, and talking from my experience, unless you're one of the lucky few this is what it really means to do DevOps in 2019: - 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.

fred_is_fred 7y ago
This is so accurate it makes me want to cry. Devops has become "run Jenkins & take page outs". 99.99% of enterprise devs (99.99% of those code in Java) have 0 clue what happens to their code after they commit it to Stash, and worse yet, they don't want to know. It's so bad now I'm embarrassed to have it on my LinkedIn profile.
dec0dedab0de 7y ago
My company calls what I do DevOps but I write full stack webapps to support the network operations team. I prefer to call it OpsDev, but noone seems to agree with me.

soupdiver 7y ago

Nice article! I also do consultancy in that field and your article describes my work situation by 90%

specialist 7y ago

The times I've been stuck doing "DevOps", I mostly rue the loss of the quality assurance culture (values) we once had. 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.)

solatic 7y ago

Great DevOps practitioners are rarer than 10x engineers. It's the combination of: * 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.

freehunter 7y ago
At my day job I have a "devops" guy who is all-in on "devops". By which I mean he wants everything run through a CI/CD workflow, committed into change control, with passing unit tests, and tasks passing through a Jenkins pipeline. Did I mention we are information security consultants and work in neither dev nor ops? Yeah he wants our powerpoint slides checked into change control. I'm not joking.
- mixmastamyk 7y ago
  I put docs in vcs, it is convenient. But, binary formats are less useful.
- pts_ 7y ago
  At least put it in a CMS. Managing docs is so absent in workflows.

NicolasCornwall 7y ago

I'm a freelance DevOps consultant working in Germany 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

tn890 7y ago
I've been hopping from one DevOps role to another for the past 4-5 years and I've been meaning to get into freelancing recently. However, in my experience, I find that projects are incredibly hard to acquire, especially if it's your first freelance gig. Do you happen to have any advice for me on how to get into DevOps freelancing, particularly how to acquire projects? Thanks

nodesocket 7y ago

I founded and run a DevOps consultancy (Elasticbyte.net) and fundamentally the biggest difference between daily DevOps work and typical software engineering is tooling. DevOps is all about the tooling, knowing which ones to use, and organizing and memorizing lots of details. 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.

hydesnark 7y ago

Remember that scene in Back to the Future 2 at the Enchantment Under the Sea dance when 1985 Marty had to somehow neutralize Biff’s thugs from the catwalk before they jumped 1955 Johnny-B-Goode-playing Marty, all while trying to avoid seeing him or else the universe would explode in a space-time paradox? That’s DevOps.

mrmondo 7y ago

Just recently I wrote a brief post about how the title of ‘DevOps Engineer’ (and similar) were irking me, especially when looking for new roles / opportunities. DevOps isn’t a job title - it’s a culture and making click-bate / hipster job titles isn’t helping recruiters or business gain the value or plug the gaps they need: https://smcleod.net/tech/2019/08/08/camels-and-unicorns.html https://smcleod.net/tech/2019/08/08/camels-and-unicorns.html

bigbluedots 7y ago

One of the coolest things about devops is that nobody seems to agree on what it is, and articles like this one elicit many different opinions. So here's mine: devops is infrastructure as code, where code in this context is something that is checked in to an scm and is really more like configuration. It is not software development, which is more likely done by software developers. I'm still not sure where the 'dev' part came from.

brew-hacker 7y ago

Personally - I would consider some of the best DevOps engineers as the best generalist engineers around. 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.