3 ms·

Devs writing Terraform means ops doesn't move fast enough. Fix ops instead of forcing the teams to roll their own.

brodouevencode 4y ago
But, as the article points out, centralized ops teams many times do not have the capacity to handle all the requests coming from the dev teams.
- candiddevmike 4y ago
  So fix that by hiring more ops folks...? Ops should scale with the dev teams, if they aren't you're burning them out and will have even more problems.
  - brodouevencode 4y ago
    Scaling ops teams is a lot like scaling dev teams - stick with the two pizza plan. That's where you get start finding the need for enablement teams (cross cutting) to ensure compliance, standardization, etc.
- encryptluks2 4y ago
  I don't think that is fair or accurate. My experience with larger enterprises is you have legacy ops and a whole bunch of people that know how to keep a few things running. They are like the systems administrators, but when it comes to development and automation they don't like change because that means for the most part they are irrelevant. With all the segregation in bigger companies if you asked a systems administrator to do cloud networking, storage, etc. they are going to not so politely tell you to F off. They are comfortable with just knowing how to manage vSphere or SQL Server. The more automation makes them feel uneasy because they simply don't want to adapt to the change and learn something new. They'd rather throw a fit and try to make your job more difficult.
claytonjy 4y ago
No matter how capable and well-staffed ops is, it will always take them much longer to provision my stuff than if i did it myself. I like having more eyes on stuff before it hits prod, but waiting days to get things setup in dev is not just unproductive, but demoralizing.
- candiddevmike 4y ago
  Who owns it when it goes to production? You, by yourself? What happens when it breaks, you're on call 24/7? You really want that? You're going to stay on top of keeping it up to date, in line with governance/security requirements? When do you have time to work on features and bugfixes?
  - magicalhippo 4y ago
    We don't use Terraform or similar, though we do manage our own VMs. We devs can setup our own stuff for dev, and then ops will do test/staging and production. Seems like this should solve GP's complaint while allowing ops/support to "own" once it leaves dev.
- deckard1 4y ago
  > waiting days to get things setup in dev not really an ops thing. This is just the reality of large corps. Microservices are the same way, with devs partitioned off. You put in a Jira ticket and wait a month for a turnaround on a task that would take an hour to do. Eventually management wants it done now and, like always, they bust open and manipulate the process for their own purposes. Rules for thee, not for me.
bsuvc 4y ago
> Fix ops Good luck. Let me know how that works out.

But, as the article points out, centralized ops teams many times do not have the capacity to handle all the requests coming from the dev teams.

candiddevmike 4y ago
So fix that by hiring more ops folks...? Ops should scale with the dev teams, if they aren't you're burning them out and will have even more problems.
- brodouevencode 4y ago
  Scaling ops teams is a lot like scaling dev teams - stick with the two pizza plan. That's where you get start finding the need for enablement teams (cross cutting) to ensure compliance, standardization, etc.
encryptluks2 4y ago
I don't think that is fair or accurate. My experience with larger enterprises is you have legacy ops and a whole bunch of people that know how to keep a few things running. They are like the systems administrators, but when it comes to development and automation they don't like change because that means for the most part they are irrelevant. With all the segregation in bigger companies if you asked a systems administrator to do cloud networking, storage, etc. they are going to not so politely tell you to F off. They are comfortable with just knowing how to manage vSphere or SQL Server. The more automation makes them feel uneasy because they simply don't want to adapt to the change and learn something new. They'd rather throw a fit and try to make your job more difficult.

claytonjy 4y ago

No matter how capable and well-staffed ops is, it will always take them much longer to provision my stuff than if i did it myself. I like having more eyes on stuff before it hits prod, but waiting days to get things setup in dev is not just unproductive, but demoralizing.

candiddevmike 4y ago
Who owns it when it goes to production? You, by yourself? What happens when it breaks, you're on call 24/7? You really want that? You're going to stay on top of keeping it up to date, in line with governance/security requirements? When do you have time to work on features and bugfixes?
- magicalhippo 4y ago
  We don't use Terraform or similar, though we do manage our own VMs. We devs can setup our own stuff for dev, and then ops will do test/staging and production. Seems like this should solve GP's complaint while allowing ops/support to "own" once it leaves dev.
deckard1 4y ago
> waiting days to get things setup in dev not really an ops thing. This is just the reality of large corps. Microservices are the same way, with devs partitioned off. You put in a Jira ticket and wait a month for a turnaround on a task that would take an hour to do. Eventually management wants it done now and, like always, they bust open and manipulate the process for their own purposes. Rules for thee, not for me.

bsuvc 4y ago

> Fix ops Good luck. Let me know how that works out.