It's certainly easier to launch a droplet on Digital Ocean but Security Groups and VPCs save so much time for just about any application I've ever put in production. I badly want Digital Ocean to have a service similar to Security Groups and VPCs so I don't have to munge my Ansible scripts to setup iptables rules and PKI for encryption between droplets.
Could you please explain why this is so important for you? I googled a little bit and the only use cases I found were (1) blocking communication between web & db servers and (2) to whitelist SSH only for your corporate network. Thanks!
Droplets without private networking communicate over the public internet. Your traffic can be listened to and if it is plain text and if you have sensitive data (every app I've ever worked on always has) then that sensitive data is flying around free and clear.
If you have Droplets with private networking you can communicate within that data center but other Droplets in the data center could still eavesdrop on your packets. To feel secure you need to encrypt data that goes between your droplets.
As for iptables: if you don't need a port open, don't open it.
Both Azure and GCE are competitors, both have pretty feature rich clouds. They may not have feature parity but I'm guessing what they do have fits 70-80% of peoples needs (Compute, Database, Storage, DNS, Load Balancing).
>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.
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.
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.
This is not intended to be silverbacking, condescending, anything like that at all: Have you ever tried to provide uptime with physical equipment?
I have been able to provide the same level of uptime over ~15 years (in various environments, ranging from corporate america to the department of energy to startups) with physical servers as I have with AWS. The initial capital expenditure outlay is higher, but its cheaper over 1-3 years than AWS.
AWS isn't the only solution out there. Its great for proof of concept, its great when you don't know how much capacity you're going to need, but it is very expensive comparatively.
> 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).
I know it's happening, but I'm so surprised to see them cater to technologies like SAP HANA. 3 years ago, there was basically no overlap between people who wanted to run products from SAP/Oracle and people who influenced product offerings from AWS.
It's amazing to see the progress from anti-cloud (or private-cloud) to "we're cloud only" within that timeframe (I'm referring to companies that was hard-on on-premise).
AFAIK, SAP HANA is being used by NBA (NBA.com/Stats), NFL, NHL (http://www.nhl.com/ice/news.htm?id=754248) to provide real time statistics for the whole league. I wonder if they want to move their infrastructure to AWS.
My take is that people are doing it piecemeal. The datacenter guys got a mandate to make everything cloudy because of the obvious benefits (scale, provisioning time, lower TCO), but the data / application teams had already invested in something like HANA. If you can just forklift everything up to the cloud, there's at least the theory that you can start to peel off bits as they need to and integrate further with Amazon. If you're starting a streaming ingest process, it's appealing to forklift your existing batch ingest, then use Amazon's services to build the new one. Similar with DB upgrades (RDS), backups (S3 / glacier), or anything else that has a dedicated service. But the first thing to do is get the core application running so you're not trying to patch around some unholy hybrid cloud mess.
It'll be nice, I'm in the middle of building a 14 node HANA cluster, and it would be much easier to just have it all on AWS provided I get the same performance.
edit: let alone the fact I could take it down when not in use. That's a ridiculously cool thought. the price of this thing all together is insane.
2TB of RAM would cost $31k or so when built out of 32GB chips.
I don't know if EC2 is done this way, but imagine if the T2.micro class was running on these servers (to save physical footprint). At 1.3¢ per hour, the server would bring in $227k/year.
> "I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time … I keep bumping into that silly quotation attributed to me that says 640 K of memory is enough. There's never a citation; the quotation just floats like a rumor, repeated again and again."
- Bill Gates, 1996
33 comments
[ 2.7 ms ] story [ 60.5 ms ] threadIf you have Droplets with private networking you can communicate within that data center but other Droplets in the data center could still eavesdrop on your packets. To feel secure you need to encrypt data that goes between your droplets.
As for iptables: if you don't need a port open, don't open it.
>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.
http://documentation.online.net/en/serveur-dedie/offres/serv...
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.
I have been able to provide the same level of uptime over ~15 years (in various environments, ranging from corporate america to the department of energy to startups) with physical servers as I have with AWS. The initial capital expenditure outlay is higher, but its cheaper over 1-3 years than AWS.
AWS isn't the only solution out there. Its great for proof of concept, its great when you don't know how much capacity you're going to need, but it is very expensive comparatively.
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.
Obviously, that's different today.
It's amazing to see the progress from anti-cloud (or private-cloud) to "we're cloud only" within that timeframe (I'm referring to companies that was hard-on on-premise).
AFAIK, SAP HANA is being used by NBA (NBA.com/Stats), NFL, NHL (http://www.nhl.com/ice/news.htm?id=754248) to provide real time statistics for the whole league. I wonder if they want to move their infrastructure to AWS.
PS: I work for SAP
My take is that people are doing it piecemeal. The datacenter guys got a mandate to make everything cloudy because of the obvious benefits (scale, provisioning time, lower TCO), but the data / application teams had already invested in something like HANA. If you can just forklift everything up to the cloud, there's at least the theory that you can start to peel off bits as they need to and integrate further with Amazon. If you're starting a streaming ingest process, it's appealing to forklift your existing batch ingest, then use Amazon's services to build the new one. Similar with DB upgrades (RDS), backups (S3 / glacier), or anything else that has a dedicated service. But the first thing to do is get the core application running so you're not trying to patch around some unholy hybrid cloud mess.
[0] https://reinvent.awsevents.com/
edit: let alone the fact I could take it down when not in use. That's a ridiculously cool thought. the price of this thing all together is insane.
I don't know if EC2 is done this way, but imagine if the T2.micro class was running on these servers (to save physical footprint). At 1.3¢ per hour, the server would bring in $227k/year.
I can't wait to spin up a 64 node cluster of these new X1's.
https://en.wikiquote.org/wiki/Bill_Gates#Misattributed