4 ms·

Two main reasons: Elasticity and Availability. Our services are highly elastic, and can vary from processing 8 million events/day to 600 million events/day. Sa

by Tehnix 7y ago

Two main reasons: Elasticity and Availability. Our services are highly elastic, and can vary from processing 8 million events/day to 600 million events/day. Same as with our users, which are mainly active during work hours, with some running night shifts, and then fewer running weekends. We are probably the prime-case for cloud, since elasticity is where you save cost by going away from dedicated hosting. As for availability; our customers are highly dependant on us processing their data live, and them being able to monitor, get alarms and react on their data. They rely on us to notify whichever technician needs to fix their production line when it's stopped, since they loosing money for every minute the line is not running (true for almost any manufacturing company). This means that we need a lot of redundancy, and these things are built-in to almost all AWS offerings. -- There's a case for dedicated servers still, I'll agree on that, but we are definitely benefiting from the cloud.

einpoklum 7y ago
I'm no cloud expert, but - I'm not sure your argument is convincing. Let's say that, for a unit of computing work, ,the cloud price is N times of non-cloud. I'm being a bit vague here for generality; plus, when not on a cloud, the cost structure is different, but bear with me. Ok. Now, your load varies by a factor of up to 133x. But unless your peak load is over N times your average, it is still cheaper for you to keep machines which support the peak load and have a bunch of idle time. Extra benefits: * Can do other computational work (e.g. experiments) during off hours without impacting system responsiveness. * Can perhaps put some machines to sleep, or other power-saving measures, during off hours. Extra detriments: * You have to take care of more system and cluster administration work than on the cloud. Above N, the cloud makes sense. Close to N - not sure. Well below N - doesn't seem to make sense. You'll need to tell us that N is low enough.
- vidarh 7y ago
  My rule of thumb is that you need peaks shorter than ~6 hours for most "normal" type setups before AWS becomes viable from a cost perspective. Of course that depends on how significant the peaks are. Most consumer websites with an international audience for example, rarely have significant enough peaks. This is exacerbated because the alternative is not either-or - the most cost effective system is often dedicated hosting + the ability to spin up cloud instances to take the peaks. Doing so lets you provision your dedicated servers to run at much higher utilization most of the time, and make pure cloud setups look far more expensive, and most people with setups like that end up needing the cloud instances very rarely. That's not to say there aren't exceptions with genuinely massive peaks, but even then it doesn't take a huge base load before a hybrid system starts to have the potential to bring substantial savings.
- satanspastaroll 7y ago
  Also to keep in mind, despite it's name, 600m shouldn't blow anyone's socks off in upkeep. It translates to about 7krps/day. Assuming it's all in one region at day time, it's 14krps/12hrs, or 42krps/4hrs. It's well within a couple high-powered servers even in the worst case

by Tehnix 7y ago

einpoklum 7y ago

I'm no cloud expert, but - I'm not sure your argument is convincing. Let's say that, for a unit of computing work, ,the cloud price is N times of non-cloud. I'm being a bit vague here for generality; plus, when not on a cloud, the cost structure is different, but bear with me. Ok. Now, your load varies by a factor of up to 133x. But unless your peak load is over N times your average, it is still cheaper for you to keep machines which support the peak load and have a bunch of idle time. Extra benefits: * Can do other computational work (e.g. experiments) during off hours without impacting system responsiveness. * Can perhaps put some machines to sleep, or other power-saving measures, during off hours. Extra detriments: * You have to take care of more system and cluster administration work than on the cloud. Above N, the cloud makes sense. Close to N - not sure. Well below N - doesn't seem to make sense. You'll need to tell us that N is low enough.

vidarh 7y ago
My rule of thumb is that you need peaks shorter than ~6 hours for most "normal" type setups before AWS becomes viable from a cost perspective. Of course that depends on how significant the peaks are. Most consumer websites with an international audience for example, rarely have significant enough peaks. This is exacerbated because the alternative is not either-or - the most cost effective system is often dedicated hosting + the ability to spin up cloud instances to take the peaks. Doing so lets you provision your dedicated servers to run at much higher utilization most of the time, and make pure cloud setups look far more expensive, and most people with setups like that end up needing the cloud instances very rarely. That's not to say there aren't exceptions with genuinely massive peaks, but even then it doesn't take a huge base load before a hybrid system starts to have the potential to bring substantial savings.
satanspastaroll 7y ago
Also to keep in mind, despite it's name, 600m shouldn't blow anyone's socks off in upkeep. It translates to about 7krps/day. Assuming it's all in one region at day time, it's 14krps/12hrs, or 42krps/4hrs. It's well within a couple high-powered servers even in the worst case