4 ms·
Contrary to popular believe, the case for going to the Cloud isn't cost saving, it is flexibility and value for money. It'll likely cost you around the same if
by gizdan 5y ago
Contrary to popular believe, the case for going to the Cloud isn't cost saving, it is flexibility and value for money. It'll likely cost you around the same if you run it in a DC, but you won't have features like auto scaling, increased security, and much more.
- luckylion 5y agoAbout the same? Last I checked for our somewhat static work load on a bunch of webservers, AWS would be x10 in pricing. Not to mention that you need someone who has deep AWS knowledge and experience to manage your system, just like you need someone who manages your dedicated servers in a DC. It's great for workloads that fluctuate extremely, or require massive scaling in very short time. Not sure about the increased security. If you run your images on EC2, it's still up to you to not mess up the config.
- sokoloff 5y agoLightsail is more reasonably priced for a lot of simple web serving use cases.
- fermentation 5y agoIt’s also super easy to use. I have an instance hosting a game server for friends. I might be wasting money since the server sits idle about half the time though.
- maccard 5y agoWe're actively planning an aws workload right now, and with reserved instances for the baseline workload, the pricing is closer to 1.5-2x, but the cost savings of only needing to scale up for a couple of hours per week make up for that. Yes it would be cheaper to run out own infra for the baseload and burst into aws, but that adds operational load onto the development team, which defeats the purpose of going with AWS in the first place
- jimmaswell 5y agoHow many workloads actually fluctuate so extremely and unpredictably?
- genewitch 5y agoThere was a coupon site that I moved to AWS because all the customers were in EU, but our servers were in Los Angeles. I implemented it in two t1.micro servers, db+nginx. Every night at 10PM in LA the first week I'd get a slew of notifications from monitoring that the CPUs were pegged out. I think I put squid or something on the nginx instance so that the most common stuff came out of the proxy instead of having to be php-unblinkered. However another thing that could have been done is to use a slightly larger instance for the DB to get more ram for cache, and then use a single front end until 9PM, spin another up, and spin one down at like 1AM. This is obviously a trivial example, but lots of sites and apps get everyone refreshing at once maybe once or twice a day, and that's when scaling helps, at least from a "costs $X per hour, so don't use it unless we need it". Loads were under 20% the other 23 hours during the day, averaged.
- Viliam1234 5y agoFrom the perspective of a developer, flexibility is a double-edged weapon. Before cloud: we have database quota of a few gigabytes, and once in a few years we need to justify to management why the quota should be doubled. After cloud: whenever we add a new table, or a new column, or import lots of data, the invoice slightly increases, the management notices, and we need to justify the extra megabytes.