5 ms·

And this is why I find DevOps work more interesting than programming. System integration is just endlessly challenging. I always enjoy reading a well-documented

• auggierose 7y ago
  In my opinion DevOps shouldn't exist at all.
  • icedchai 7y ago
    Okay. So based on 20+ years of experience, I can say that most developers have no interest in automating deployment, configuration, monitoring, performance, logging, etc... Who should do this work?
    • learned2code 7y ago
      Yeah, operations-focused engineers will continue to have a niche carved out for them because too many devs black-box infrastructure. Companies can either choose to have their devs take on ops responsibilities or continue having dedicated ops jobs. In either case, whether or not dedicated ops jobs exist, ops responsibilities always will. I'll be there to pick up the slack because designing and maintaining systems is an interesting job that has to be done that a lot of people can't/won't do and it pays accordingly.
      • tunesmith 7y ago
        People overlook that there's a common systematic belief that looks like this: 1) Developers don't code on prod 2) Prod needs to be protected 3) Therefore, developers need to be restricted from prod One of my teams went through the process of "let's do DevOps!" with the intent of giving developers the ability of pushing something all the way through to prod on AWS. Months later, this resulted in having a poorly-supported dev-only VPC with IAM/policy restrictions, and other "official" VPCs that devs are locked out of in various ways. Since then, devs had little incentive to learn and are again reliant on Ops for any deployment problems.
        • lostcolony 7y ago
          There's a common systematic belief of that because that's the sort of thing a lot of actual compliance regulations de facto require (i.e., they demand controls around software deploys, and putting enforcing that in the same hands as those wanting to deploy it, i.e., devs, will fail an audit). Source: My employer is currently undergoing SOX compliance
          • beat 7y ago
            And there's a good reason that separation of duties is in every compliance standard...
            • lostcolony 7y ago
              Not saying whether it's a good or bad idea, just that it's a common systematic belief because it's a required thing in many organizations.
    • oneepic 7y ago
      This might be achieved with software tooling, though we're a while away from having a great solution. Lots of stuff hasn't been automated yet, and we tend to be afraid of some of trying it, but I like to think we'll be able to automate that someday.
    • schnable 7y ago
      Interesting, I've observed many teams where the engineers seem to prefer the DevOps work to actually building features. To the point where I think some times we have too many engineers Opsing rather than Deving.
  • dmlittle 7y ago
    If you tackle the problem from an efficiency angle it makes sense. Just like how people advocate for keeping things DRY why should every developer worry about deployment pipelines, logging/monitoring/alerting systems, etc. It makes sense to have a dedicated team to worry about those issue so others don't.
  • goobynight 7y ago
    I think the best model is to have your "devops/sre guy" embedded right on the team. I market myself in interviews as a software engineer (on the same team as the other SWEs) that just happens to focus on what actually getting this product into production and keeping it going looks like. I got my start in this by working at a startup where we were responsible for everything just by the nature of the limited staff. I think that's how a lot of people in Devops get their start. I didn't even know coding without a thought about deployment was a thing until I joined a huge company.
    • outworlder 7y ago
      > I think the best model is to have your "devops/sre guy" embedded right on the team. And here lies the problem. We had "Ops" before. People would throw stuff over the wall from Dev to Ops, and now it became "Ops" problem. Operations would stonewall releases – because releases bring problems, and they want to keep things stable. Developers would push for releases, because that's what they are paid to do. To solve this conflict, someone came with the idea of "DevOps". You don't have a split organization now, you have some developers in your team that can wear the "Ops" hat. That way, they experience production issues first hand, and that allows them to architect the application better – as well as ensuring it is thoroughly tested – noone wants to wake up at 2AM. And, because they are developers at heart, they will do things to make their job easier and more predictable, like infrastructure as code. And heavy automation. Somewhere along the way, people misread the whole idea, and now think that "devops" == Terraform or some other tool. Then they rebranded their Ops org as DevOps and hired a few automation folks and called it a day. Ops rebranded is still ops. It was not supposed to be like that. If you have a "devops" team, you are not doing it correctly. Call it operations like it should be called. You may even have a dedicated team working on common tools or similar – which is fine – but you still need developers doing operations and ultimately responsible for their own shit, otherwise this is not devops. > I got my start in this by working at a startup where we were responsible for everything just by the nature of the limited staff. I think that's how a lot of people in Devops get their start. Yup. I got into that by trying (and ultimately failing) to launch my own startup. We didn't have dedicated operations folks, or time to manually tinker with servers, or to respond to repeated production issues. When you are sales, operations and engineering, you try your hardest to not have incidents (so that you don't lose customers), but you are trying to move fast to deploy features (so that you can sell).
  • beat 7y ago
    So should developers be doing all their own ops work in a half-assed, ignorant way, or should we go back to a world of throw it over the wall systems where the ops team doesn't understand the code or have a working non-adversarial relationship with the developers? Because I've lived with both, and to hell with both of them.
    • kazen44 7y ago
      this is the old issue of dev and ops having different goals in terms of their jobs. Ops wants stability because uptime and a non disrupting service is paramount, devs want velocity because they need to push new features to market. It's a delicate balance to strike, especially considering having a product with a ton of features but lackluster stability doesn't get you anywhere, and neither does having a super stable product that lacks basic features. "move fast and break things" doesn't work in a lot of sectors. It might work for an internet startup, but good luck applying that principle to fields like large infrastructures and datacenters.
  • nvarsj 7y ago
    Can you elaborate? You may as well say “software engineering should not exist at all”.
    • auggierose 7y ago
      No, I have just been throwing that statement out there. Pleased by all the comments it generated, was an interesting read :)