Because the broad feature is called Savings Plans with two initial options of Compute and EC2 Instance, I have to believe AWS will at some point release a Database Savings Plan, a Storage Savings Plan, etc. As with RIs, the compute team goes first and the other service teams follow.
Savings Plans will always match as long as there is usage somewhere and you're not overcommitted. Standard RIs can get mismatched even with other uncovered usage, but can be disposed of via the RI Marketplace (that of course assumes there is a buyer out there somewhere). Once you make a Savings Plan commit, you are stuck with it. They have different "benefits".
Savings Plans are way more flexible and will automatically float, so as long as you aren't overcommitted, you'll get a discount. One of the benefits of Standard EC2 RIs however is they can be disposed of via the RI Marketplace if you do actually need to reduce your commit. That of course is predicated on the RI Marketplace having liquidity, and if people are moving to Savings Plans instead, there may be no buyers. People may still want inflexible but shorter terms. Will be interesting to see how it plays out.
I think so. GCP Committed Use Discounts allow you to commit in aggregate in terms of vCPU and Memory, but you are still constrained by region and the commits are bifurcated (gen 1, gen 2, custom, etc.). Savings Plans are dollar based so they automatically float to any region and instance. Way better than Committed Use Discounts imo.
Rackspace Cloud tries to balance delivering the power of cloud with the simplicity/constructs of traditional infrastructure. It doesn't have the complexity of AWS, but that strength is also a weakness since it lacks the features and sophistication of AWS. So, depends on what is desired. The AWS complexity can absolutely be challenging for small teams. That's one of the reasons Rackspace created Fanatical Support for AWS (http://www.rackspace.com/aws). While AWS provides economies of infrastructure, Rackspace Fanatical AWS provides "economies of expertise" via management tools and hundreds of AWS devops engineers, architects, etc. The two services are very complimentary and even small teams can tap into expertise at scale to overcome the AWS complexity hurdle. One option worth considering for those who want the power of AWS and are concerned about complexity.
[Full disclosure: I work for Rackspace. I helped build the Rackspace Cloud and now work on our Fanatical AWS team.]
Thanks for digging into the details. Please allow me to clarify a couple of things...
1. Average File Size - You have nailed the difference in request fee pricing but failed to point out that 2 of the 5 scenarios show an avg file size of 75KB. In fact, scenarios 1 and 2 are exactly the same with the exception of file size and were included to specifically highlight the difference in pricing both above and below the 100KB threshold. Also, in some instances, a smaller avg file size results in Amazon costs being even MORE expensive. For example, take a look at scenario #5 and set the average file size to 50KB. The savings with Rack INCREASE from $3,116.97 to $3,525.70. That's because Amazon charges CDN and origin fetch request fees, neither of which Rack/Mosso does. The point of the calculator was to make something that is difficult to compare more quantitative. Your assumption that file sizes over 100KB would always benefit Rackspace is a good example of why the calc was created. As scenario 5 shows, that's not always the case. We tried not to pull any punches and make the scenarios reasonable and fair (I'm an architect and don't particularly care for hyped up marketing). We believe in complete transparency which is also why we make the calculator available. We encourage anyone and everyone to run their own scenarios. If there are errors in the calc, that is another story and we welcome feedback so we can fix any that exist. We recognize we won't be cheaper in EVERY case, but at least people will have the data they need to make an informed decision.
2. Incoming Bandwidth Charges - You are correct that incoming BW is temporarily free. I can't speak in great detail here but we won't simply be introducing an incoming BW charge. Instead, we'll be making some broader cloud pricing changes that will also impact Files BW pricing. That's still a bit of a moving target but I have a newer version of the calc that includes these changes and it doesn't change the fundamental result. When the new pricing is released, we will be releasing a new version of the calculator. Again, full transparency. We thought about waiting until the pricing changes go into affect before releasing this analysis, but since there isn't a fundamental difference, we wanted to get the analysis out now. That said, even with the EXISTING pricing, adding in an incoming BW charge doesn't really change the result. For example, on the "Pricing" tab of the workbook, change the 0 to .10 for "BW in" under Cloud Files. We're still less expensive on all scenarios (with support) and less expensive (or roughly the same) on 4 of the 5 scenarios without support.
3. Gigabytes vs. Gibibytes - We measure in increments of 1024, not 1000 and the pricing breakpoints (see the Pricing tab) are the same. The amount of storage and bandwidth used is an input to the calculator so any number can be entered. We probably should have used 5120 instead of 5000, etc, etc. so your point is well taken. I'll update that for the next version.
Again, thanks for digging in. In general, we expect some degree of skepticism (as there SHOULD be when any company produces their own comparative analysis) but we felt there was a very quantifiable message that wasn't being told. We have tried to be as fair and transparent as we could be in the analysis and we don't necessarily want you to take our word for it. We encourage any and all to look at the cost and performance for yourself. If we've made a mistake, let us know so we can fix it.
If it would be of use, don't hesitate to e-mail me directly at erik[dot]carlin[at]rackspace.com.
It's unfortunate that HN has gotten so busy lately that your reply won't be seen by more people. Thankyou for taking the time here to clarify the argument.
