Re:A million-dollar engineering problem
by metafunctor on Friday March 17, 2017 @05:56AM
(#13892775)
Resizing, bursting, and duplicating on the fly aren't exclusive to AWS, though.
A lot of teams rent space from places like OVH or Hetzner because the raw power is so much cheaper, and they already have the talent and tools to scale and manage a computing fleet (people like to think it's harder than it actually is).
Are bursting and resizing an issue in the trough, though? GP's premise is that these companies have platform and load stability. There can be marginal gains in having a dynamic architecture, sure, but when it also costs "months of engineering," I don't see where the savings would be compelling, or even guaranteed.
Re:A million-dollar engineering problem
by QuinnyPig on Thursday March 16, 2017 @04:56PM
(#13889095)
There are companies "in the trough" who are contently spending tens of millions a year on AWS. It's hard to give generic advice for all situations-- as with so much else, context matters heavily.
Those marginal gains could potentially pay for a dozen engineers...
My point was based on how dynamic the architectures are (or aren't) of those in the trough, not their level of spending.
At the single instance very small scale, it simply doesn't matter all that much. "Our business failed because our infrastructure bill was $400 instead of $150 every month" isn't that common of a story.
Base load can be effectively migrated to AWS, depending upon how it's built / structured. It's hard to lose money on infrastructure by converting worker servers to spot instances or lambda functions, as a for-instance-- but it's VERY easy to lose months of engineering effort in doing so.
Remember as well: done right you're not just buying services from the cloud, but flexibility as well. Resizing on the fly, bursting, duplicating your infrastructure for a test-- these things add value.