Hacker News new | ask | show | jobs
by kimcheekumquat 3914 days ago
>X1 instances will feature up to 2 TB of memory, a full order of magnitude larger than the current generation of high-memory instances. These instances are designed for demanding enterprise workloads including production installations of SAP HANA, Microsoft SQL Server, Apache Spark, and Presto.

>The X1 instances will be powered by up to four Intel® Xeon® E7 processors. The processors have high memory bandwidth and large L3 caches, both designed to support high-performance, memory-bound applications. With over 100 vCPUs, these instances will be able to handle highly concurrent workloads with ease.

Can't wait to launch one of these.

1 comments

I assume I'll have to declare personal bankruptcy as soon as I launch one.
As a point of comparison, the Dedibox Extreme SP launched in 2013 and has 1TB of RAM and costs €1899.99/month.

http://documentation.online.net/en/serveur-dedie/offres/serv...

Physical servers at other providers are almost universally cheaper than AWS. At AWS, you're paying for it to be in your same account, have access to your other AWS resources, etc.

EDIT: This is not to hate on AWS. I love AWS! (I do devops and infrastructure). Its to say, if you need what AWS offers, buy it. If you don't, architect your solution around other providers.

> At AWS, you're paying for it to be in your same account, have access to your other AWS resources, etc.

You're forgetting the biggest part: you're also paying for the flexibility. Subject to availability, you can provision and deprovision AWS resources at will, which gives you far greater granularity than you can do with your own hardware.

This flexibility enables you to save in the long run if you manager your resources appropriately, but it also comes at a per-unit premium.

Very much this. If you're starting out or have a very dynamic load pattern (Netflix), AWS is for you. If you have a fixed load pattern, you can see quite a bit savings going to dedicated hardware (Stackoverflow/Stackexchange).
Don't forget the insanely good availability, and the low level management AWS guys do for you.
Ignore availability. You should be architecting your app so availability doesn't matter.
There's a lot wrong with this. Availability when you're managing some servers in a rack in a Colo is a whole other kettle of fish to what you get with AWS. The key is how leverage those AWS resources in different zones and regions to avoid single points of failure. But that's so much harder outside of the cloud.