3 ms·

Sure, that happens. If you can save millions of dollars a month and move your business from non-viable to viable, I think it's a good tradeoff. That's what I do

by skuhn 10y ago

Sure, that happens. If you can save millions of dollars a month and move your business from non-viable to viable, I think it's a good tradeoff. That's what I do for a living, so I see value in it. Not everyone should have to deal with it though. Also, AWS is not problem free. When low level issues (like a firmware problem) strike, which they sometimes will, you often cannot identify or fix the issue yourself. AWS instances still run on that same shitty hardware, and while your odds are better that Amazon figured out most of the issues before you encountered them, your odds are also worse that they tested your particular special use case. So you can wind up playing the 'debug by support ticket' game. Check everything on your end. Check your deployment times for correlations to the problem. Finally give up and reach out to AWS support. Insist that the issue isn't on your end. Find out that the issue can't be resolved until their deployment next week. It's all understandable given the scope of what Amazon is doing, but they will never be as incentivized as you are to solve your problem.

xorgar831 10y ago
I don't think non-viable to viable is exactly what's going on however, at least in most cases. I think the costs are not being fully understood, the impact to the mindshare of the team, the quality of service and redundancy, the additional headcounts and quirky management code that someone's going to be toiling away on when a cloud provider can handle it at a much lower cost. Yes, you still have to open tickets, and yes, they still have problems that suck up a lot of time, however they spend the brunt of the time burning folks out fixing those issues, not you. If you talk to folks working with physical systems, that consumes their mindshare to the point that they're not focusing on their core product anymore.
- skuhn 10y ago
  > If you talk to folks working with physical systems, that consumes their mindshare to the point that they're not focusing on their core product anymore. All I can say is, it isn't always the case and it doesn't have to be with the right organizational and design decisions.
coredog64 10y ago
That story isn't much different from my interactions with the on premise infrastructure team.

by skuhn 10y ago

xorgar831 10y ago

I don't think non-viable to viable is exactly what's going on however, at least in most cases. I think the costs are not being fully understood, the impact to the mindshare of the team, the quality of service and redundancy, the additional headcounts and quirky management code that someone's going to be toiling away on when a cloud provider can handle it at a much lower cost. Yes, you still have to open tickets, and yes, they still have problems that suck up a lot of time, however they spend the brunt of the time burning folks out fixing those issues, not you. If you talk to folks working with physical systems, that consumes their mindshare to the point that they're not focusing on their core product anymore.

skuhn 10y ago
> If you talk to folks working with physical systems, that consumes their mindshare to the point that they're not focusing on their core product anymore. All I can say is, it isn't always the case and it doesn't have to be with the right organizational and design decisions.

coredog64 10y ago

That story isn't much different from my interactions with the on premise infrastructure team.