3 ms·

I agree with a lot of what you're saying-- but that trough is a lot wider than most people think. At the single instance very small scale, it simply doesn't ma

I agree with a lot of what you're saying-- but that trough is a lot wider than most people think. 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.

rhizome 10y ago
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.
- QuinnyPig 10y ago
  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...
  - rhizome 10y ago
    My point was based on how dynamic the architectures are (or aren't) of those in the trough, not their level of spending.
    - QuinnyPig 10y ago
      Ah, my apologies! It depends. I have a toy service that exists entirely as an autoscaling group. That's pretty dynamic! Counterpoint: Mainframes.
      - rhizome 10y ago
        A toy service is not what I'm thinking of as being in "the trough." The trough is where scaling and bursting aren't generally necessary.
metafunctor 10y ago
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).

rhizome 10y ago

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.

QuinnyPig 10y ago
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...
- rhizome 10y ago
  My point was based on how dynamic the architectures are (or aren't) of those in the trough, not their level of spending.
  - QuinnyPig 10y ago
    Ah, my apologies! It depends. I have a toy service that exists entirely as an autoscaling group. That's pretty dynamic! Counterpoint: Mainframes.
    - rhizome 10y ago
      A toy service is not what I'm thinking of as being in "the trough." The trough is where scaling and bursting aren't generally necessary.

metafunctor 10y ago

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).