2 ms·

I think the GP is talking about things like provisioning AWS resources, not having root on the production box. Anyone should be able to provision new resources

I think the GP is talking about things like provisioning AWS resources, not having root on the production box. Anyone should be able to provision new resources without harming production. Most of the time you don't see this, because management has still not gotten it through their thick heads that in order for the business to move fast, devs need the agency to implement solutions fast. Cost-cutting of AWS leads to one (or several!) groups that are the gatekeepers to AWS, purportedly in order to make it more "efficient" by everyone doing everything one way, or having one group of experts handle it. But that's just one group of plumbers handling repairs for an entire city. Leaks spring up and nobody is there to fix them, and meanwhile, the developer is sitting there staring at the leak, going "will you please just let me duct tape this leak so I can get back to work!?"

scarface74 9y ago
Exactly. When the last company I worked for decided to "go to the cloud", it took weeks to get simple EC2 instances setup because we had to go through my manager, say why we needed it, then wait on an outside vendor. We had layers of consultants getting in the way. I still ended up doing stuff suboptimally like using all of the stuff I would use on prem like Consul (instead of Parameter store),Fabio (instead of load balancers), Nomad (instead of ECS), VSTS (CI/CD - when I should have use the Codepipeline, Code Build, code deploy ) and even a local copy of Memcached and RabbitMQ just so I wouldn't have to go through all of the red tape just to provision resources so we could get our work done. Our projects ended up costing more because it took so long to get anything approved, I would overprovision "just in case". Anytime that I wanted to stand up VMs for testing, I would send a Skype message to our local net ops person for an on prem VM and have it within an hour. I was the "architect" for the company - I couldn't afford to make excuses and it's never helpful at my level of responsibility to blame management when things don't go right. I had to get it done. So, I learned what I could, studied AWS services on a high level inside and out, got a certification and left for greener pastures. And people wonder why I never do large organizations.

scarface74 9y ago

Exactly. When the last company I worked for decided to "go to the cloud", it took weeks to get simple EC2 instances setup because we had to go through my manager, say why we needed it, then wait on an outside vendor. We had layers of consultants getting in the way. I still ended up doing stuff suboptimally like using all of the stuff I would use on prem like Consul (instead of Parameter store),Fabio (instead of load balancers), Nomad (instead of ECS), VSTS (CI/CD - when I should have use the Codepipeline, Code Build, code deploy ) and even a local copy of Memcached and RabbitMQ just so I wouldn't have to go through all of the red tape just to provision resources so we could get our work done. Our projects ended up costing more because it took so long to get anything approved, I would overprovision "just in case". Anytime that I wanted to stand up VMs for testing, I would send a Skype message to our local net ops person for an on prem VM and have it within an hour. I was the "architect" for the company - I couldn't afford to make excuses and it's never helpful at my level of responsibility to blame management when things don't go right. I had to get it done. So, I learned what I could, studied AWS services on a high level inside and out, got a certification and left for greener pastures. And people wonder why I never do large organizations.