1. 8
  1.  

  2. 7

    TIL: we need more managers sitting in rooms enforcing processes. Cool.

    1. 4

      I think it’s more like we still need the usual amount of managers enforcing process.

      Just like scaling a server backend requires certain coordination technologies (load balancers, container orchestration), scaling a human organization does too (including managers sitting in rooms reviewing change plans).

    2. 7

      You may not “need” to treat your servers as cattle today, but you certainly need to be able to bring one up next week when one of your three pets crashes. How are you going to accomplish that? If your answer is “I don’t know,” then you need to figure things out. If you’re going to figure things out, you may as well codify it so that it can happen at the push of a button. If you’re going to make it happen at the push of a button, you may as well use that to deploy every time. If you don’t, your automation will rot and you’ll be back at step one.

      1. 2

        If you’re going to figure things out, you may as well codify it so that it can happen at the push of a button

        That’s a big assumption about allocation of engineering resources in what might be a very constrained environment like a startup.

        1. 3

          It doesn’t have to be a gold-standard blue/green deployment with full automation of server management, networking, and so on–but you should at minimum have Ansible playbooks or an equivalent that will set up your software on a fresh machine. Doing this is not much harder than merely taking notes of changes you need to make to a machine in order to get something to run.

        2. 1

          but you certainly need to be able to bring one up next week when one of your three pets crashes

          Or when an admin finally notices that your 100 active EC2 instances have been idling for a year.

        3. 5

          This guy has obviously not read The Phoenix Project and doesn’t actually understand what the Devops philosophy is actually trying to promote.

          He’s railing against a virulent mutant strain of process improvement that large enterprise orgs enact so they can say “LOOK! We’re DOING DEVOPS! We HIRED A TEAM FOR IT AND EVERYTHING!”.

          The article does a good job of pointing out why this is stupid, but I wish he would take the time to learn why the actual devops philosophy can have positive implications for just about any organization if the actual spirit of the idea is followed.

          1. 1

            Perhaps putting programmatic safeties into your deployment processes would make you not need so many managers?

            1. 1

              In the one company, where we actually needed to push changes to production via change requests, all I saw was an idiot half way across the world, incapable of running a sequence of 4 commands without a mistake, so you’d have to nudge him/them until things seem to work. Obviously, by the time your change seemed to make it into production, you’d be exhausted and whether those idiots made any mistake that would compromise security or anything like that would be beyond your ability to care. Oh, and since they were half way across the world, this nudging would happen well beyond working hours.

              In summary, my view of the alternative to DevOps might be skewed by my traumas.