3 ms·

One more, speed. When in a corporation you have the options of "work with IT" or "AWS", AWS may make sense. Additional cost, sure, but when you need changes you

One more, speed. When in a corporation you have the options of "work with IT" or "AWS", AWS may make sense. Additional cost, sure, but when you need changes you can just make them. You don't have to file a ticket and wait a week. (And as a note, it is likely to be an easier battle to get AWS permission in a stodgy corporation, than it will be to increase the pace of IT)

toomuchtodo 11y ago
God help whoever needs to support an environment where AWS makes sense because you can "just go make changes". Developers want to make changes at will? Be prepared for your PagerDuty onboarding email and your rotation schedule.
- lostcolony 11y ago
  Not changing production systems at will; obviously you need processes and permissions in place to ensure you're not just trampling over prod whenever a dev thinks a change should happen. But I've been in corporate environments where "We need to deploy a new instance" requires four weeks of lead time. Or a new release is tested and ready to go, and rather than just running Chef to deploy it, both the devs and the devops people had to work with a team whose sole job was to run prod, setting up a time with them, and then handholding them through running the right commands, because they weren't sufficiently involved (or maybe one was, but the person you got today to run it wasn't). Etc.
marcosdumay 11y ago
I meant risk to include "we need an unexpected deployment just now", but I do agree it's important enough to point separately.
- lostcolony 11y ago
  Yeah, but a lot of companies view risk management as -preventing- deployments unless every stakeholder has signed off on it. The process generally doesn't leave room for making decisions quickly when everything is on fire. But I wasn't just referring to that; I was also referring to lead time in hardware requisitions and changes. I've been in environments where, to get Jenkins running, we put in an order for a box. It finally arrived (it actually came pretty quickly, within a week of our order, since we just expensed it, rather than went through the approved channels of requesting one from IT). We configured it. We needed to punch a few ports open in the corporate firewall so we could get push notifications when our hosted git repos were updated. We requested it, specifying only ~these~ ports, ~from~ this IP, ~to~ this other IP...aaaand, the powers that be denied it. To remain in process we could have escalated, taking even more time, but instead we just did what we should have done in the first place; we put our Jenkins in AWS (which we already have permission to use, and is not subject to the corporate IT policy), and the box we purchased was used for broadcasting to a monitor various data visualizations of our systems.

toomuchtodo 11y ago

God help whoever needs to support an environment where AWS makes sense because you can "just go make changes". Developers want to make changes at will? Be prepared for your PagerDuty onboarding email and your rotation schedule.

lostcolony 11y ago
Not changing production systems at will; obviously you need processes and permissions in place to ensure you're not just trampling over prod whenever a dev thinks a change should happen. But I've been in corporate environments where "We need to deploy a new instance" requires four weeks of lead time. Or a new release is tested and ready to go, and rather than just running Chef to deploy it, both the devs and the devops people had to work with a team whose sole job was to run prod, setting up a time with them, and then handholding them through running the right commands, because they weren't sufficiently involved (or maybe one was, but the person you got today to run it wasn't). Etc.

marcosdumay 11y ago

I meant risk to include "we need an unexpected deployment just now", but I do agree it's important enough to point separately.

lostcolony 11y ago
Yeah, but a lot of companies view risk management as -preventing- deployments unless every stakeholder has signed off on it. The process generally doesn't leave room for making decisions quickly when everything is on fire. But I wasn't just referring to that; I was also referring to lead time in hardware requisitions and changes. I've been in environments where, to get Jenkins running, we put in an order for a box. It finally arrived (it actually came pretty quickly, within a week of our order, since we just expensed it, rather than went through the approved channels of requesting one from IT). We configured it. We needed to punch a few ports open in the corporate firewall so we could get push notifications when our hosted git repos were updated. We requested it, specifying only ~these~ ports, ~from~ this IP, ~to~ this other IP...aaaand, the powers that be denied it. To remain in process we could have escalated, taking even more time, but instead we just did what we should have done in the first place; we put our Jenkins in AWS (which we already have permission to use, and is not subject to the corporate IT policy), and the box we purchased was used for broadcasting to a monitor various data visualizations of our systems.