Out of curiousity, why go with AWS when Linode, Digitalocean, etc appear to be so much more cost effective? Is the simplicity of spinning up AWS instances really great enough to counterbalance what appears to be a significantly greater cost? Is it the flexibility of different AWS services?
Article author here. So, you're right that while AWS does continue to lower prices, they're still not the cheapest game in town. Frankly, they're not even necessarily the most performant game in town.
What they are really competing on is breadth and depth of service. The article goes into a lot of those services, but, as one example, if you launch an instance in EC2 you can allow it to access secured buckets in S3 without any need to store keys/passwords on the instance itself thanks to IAM roles.
Another example is services like AWS Lambda, which is a hosted way to run a function without any need to manage servers.
The list goes on and on...direct VPN connectivity, Hosted Active Directory, CloudHSM. While I'm biased, my perception is that AWS is pretty far ahead of the pack.
Thanks for all the replies. I am just researching all of this for my own startup and it is important to understand all the tradeoffs. And it is clear from your article that AWS has a very deep feature set. Its a good article!
Actually, technically, StackExchange is not profitable yet: (http://www.joelonsoftware.com/items/2015/01/20.html). However, "We could just slow down our insane hiring pace and get profitable right now, but it would mean foregoing some of the investments that let us help more developers."
I think that's spot on, it is all of the bells and whistles along with a fairly predictable management cost, even if you are new to AWS, that make it a safe choice for a big swath of the market.
Kudos to you for touching on containerization, I would just like to add that the many emerging platforms and tools (https://pbs.twimg.com/media/B33GFtNCUAE-vEX.png:large) are rapidly starting to provide an alternative to AWS that was not there before in their ability to realize more competitively priced hosting alternatives without sacrificing on administrative overhead.
For 99% of startups the cost of web hosting is negligible next to the cost of labor. Even the tiniest gain in productivity will overshadow hosting savings.
Not valuing your time is easily among the biggest mistake you could make.
That is very true, time is quite valuable. It appears that for my use case AWS would be at least 5x as expensive though. I won't know for sure until I actually try running some benchmarks. Have you had experience showing AWS to be significantly faster to deploy and administer than Linode, DigitalOcean, etc?
IME, AWS is slower to set up initially. Since you are starting out with it, I'd say it will take longer to do things "the AWS way". This article should help quite a bit with that part.
The real trick with AWS, IMO, is figuring out what you want to do yourself vs what you want to have hosted. For example, they offer a hosted cache such as memcached or Redis. For my app, I run Redis myself as it required roughly 15 minutes of work total to set up and maintain in 2014. OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow (even though by the specs, it was using a more powerful VM than the EC2 box I was running my instance on).
Basically, once you grok AWS, things become more productive AND you don't need to spend time on doing things like setting up VLAN's, transferring data between boxes, etc. You can do cool things like detach a virtual disk from one VM and attach it to another, rather than pushing 100 GB's of data over a network. This, AFAIK, is not something that Linode or Digital Ocean can do.
Having said that, DO is great for lots of things. It's a good place to experiment and to run lots of really small things. For me, that's side projects or things that I am trying out before thinking about moving them to the "big iron".
> Basically, once you grok AWS, things become more productive
> OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow
These two statements are contradictory.
You would have been better off just renting a dedicated host for your DB and doing the tuning yourself (either in person or getting someone to do it) - because the AWS offering is slower than your own instance, and database is a service thats often ripe for easy optimisation by using a dedicated host/cluster of hosts vs virtualised host(s).
Of course dedicated hardware is faster. It is also very inflexible. You cannot clone your DB box to 10 more instances wishing minutes. You cannot detach and reattach volumes withing minutes. You cannot resize the box to 2x size withing minutes. You cannot move it to a different VLAN within minutes. AWS is not the speediest, but it certainly is flexible.
According to your comments though, you'd have been just as well served with a regular VPS at a regular VPS host - you wouldn't have wasted time to found out RDS is slow, and you wouldn't have issues with slower than usual disk IO on EBS.
My point about physical was just another common optimisation for performance critical DB servers, you could probably get close to bare metal speed with the flexibility of virtualised by using a "single VM on hardware" model that some providers offer now.
Thanks for the perspective. Right now I am still just in the experimental phase of building things and even an early beta is 6 months out for my project. Like you said there definitely are a bunch of useful tools on AWS. This article definitely convinced me to actually spin up an AWS instance and see how well it works before just going with Linode or DigitalOcean.
I don't think doing it the AWS way is always necessary from the start. You can do a lot of simpler stuff with ElasticBeanstalk or OpsWorks and you'll still be in a better position to scale than working straight on a VPS.
The advantage of AWS is the scale at which it can operate and the rich ecosystem of services (S3, ELB, CloudFormation, RDS, etc) that you can use as building blocks for your app. DigitalOcean, Linode are more like VPS providers and are only suitable for a subset of the use cases AWS covers (or Azure or Google Compute Platform)
If you are/have skilled sysadmin staff, there is very little if anything AWS offers that you can't run on your own rented/owned phsyical/virtual servers.
I'm not suggesting that's ideal for all companies, but this idea that somehow it's impossible to run a load balancer or store files without using AWS/Azure/Google 'clouds' is a bit ridiculous.
I've spec'ed out S3 alternatives for clients, and pretty much no matter what criteria they have for redundancy, managed hosting solutions or co-location comes out much cheaper than S3. E.g. typically half or less of the S3 costs for triply redundant servers, on RAID arrays, in separate data-centres with replication (e.g. using OpenStack Swift, or Gluster / Ceph + an API layer for example)
For larger setups you can do it at 1/3 or less of the cost if you're prepared to go the colo route (rather than managed servers) and leasing your own hardware.
If your average bandwidth usage per object is high you can trivially cut costs far beyond that, as the EC2/S3 bandwidth costs are atrocious.
The exception would be if you can't avoid huge amount of object accesses from within EC2 even if you move the storage out of S3.
For the vast majority of people, S3 means cheap, mass storage.
For the majority of those people, a simple SFTP/rsync/NFS/whatever endpoint (potentially with replication to provide redundancy) would more than fit the bill, and would actually be simpler to use than the S3 API.
I store about a terabyte on S3. It costs us $25 a month. If I spend more than a few minutes a month administering an alternative setup, I've lost money compared to just paying S3.
That entirely depends on how you use the data. If you store files that are accessed over the general internet, and each file is downloaded just once in the month, you've just quadrupled your monthly cost, thanks to AWS' high data transfer fees.
Are there any resources out there that teach developers weak on scaling/architecture how to manage this themselves? What architectures are the "best practices" of today? What tools are proven? Any books/articles/papers to recommend?
Good point, it becomes clear that if you are operating at the scale of a large company the large scale and rich ecosystem are important. It was just a bit surprising to me that for smaller scale instances AWS is so much more expensive. It would seem they should be cheaper due to economies of scale.
AWS is definitely aware that their costs can be prohibitive for brand new startups. Check out AWS Activate[1]. If you can demonstrate that you're a legit startup, there's a decent chance you can get free AWS credits, not to mention free support.
Getting the business level support is absolutely necessary if you don't have someone with AWS experience and are doing anything substantially complicated. The free-ish support is, on the whole, pretty abysmal. The availability of solution architect time is not always useful. You ask 3 people and get 3 different answers. I've given some thought to doing consulting around this for equity but haven't figured what that would have to look like. There's a lot of wrong turns one can go down pretty easily. Bottomline, Activate is helpful but not sufficient.
Consider that whenever you are paying for AWS you are also paying for whatever proportional part of the AWS infrastructure is sitting idle at any one time - Amazon still need to cover those costs - it just get amortised over the paid resource usage.
Really? I know reserved instances lower the price but they still have shown themselves less performant for the dollar in the benchmarks I have seen. Are there any good articles you could recommend with benchmarks showing AWS to be more cost effective?
My experience is similar. EC2 performance is mediocre in general and quite poor compared to dedicated bare metal. Disk I/O is abysmal (yes, even on "SSD" EBS).
Any citations? There are lots of people using EC2 at appropriate instances sizes to do compute intensive loads. Provisioned IOPS and, again, appropriate instance types are necessary to get high performance disk I/O.
My "citation" is my own experience managing infrastructure for several AWS-backed startups. I think public cloud services have a role and make sense in certain cases (particularly for very early stage companies), but I'm realistic about their performance characteristics and tradeoffs. The biggest danger is in overuse of proprietary AWS services, which makes it much more difficult to migrate off when the business outgrows the public cloud.
EBS is not intended for high-perf applications. This is well-known and well-understood. As far as CPU perf being poor compared to bare metal--you might be the one person out there who actually needs it, but I'm betting not.
I use AWS, and will continue to use AWS, because it means less screwing around with stupid things and more time making important things work.
CPU-bound workloads are not particularly rare. Also, EBS is your only storage option for any data you might care about. 90% of the reason RDS exists is because I/O is so bad on normal EC2 instances.
You can run a database just fine using provisioned IOPS EBS especially in a RAID 10 configuration. I'd like to see some data to the contrary as I've actually done it.
There's some disadvantages to using RAID 0 with EBS volumes in a performance dependent situation.
Since you're writing to multiple EBS volumes for the RAID 1 portion of the RAID 10, you're going to require more EC2 to EBS bandwidth.
EBS volumes are replicated across multiple servers, so you don't necessarily need the reliability, especially if you're replicating the data elsewhere.
YMMV, of course, and everyone has different priorities and different levels of what constitutes acceptable risk, but RAID 0 with EBS isn't quite the data death wish it is with physical hardware.
> EBS is your only storage option for any data you might care about.
No, it's not. It is if you want data-at-rest storage, but I don't care about that when I have multi-master MySQL and Postgres running on instance stores. Or when I have replicative NoSQL databases (Riak is more than happy running forever in instance stores and duping across AZs).
I only have a general comment about this, but that kind of performance is almost not worth thinking about in most cases. Just like NBA players need to be "tall enough", your cloud needs to be "fast enough", and AWS is just that.
Having said that, nothing beats getting real hardware in terms of performance/$. I used to work for a company that exclusively worked on SoftLayer's hardware servers. These were $500+/month each, but they were fast. The point is that if you can devote a dual octocore machine to what you are doing, and are willing to pass up on the SAN, flexible networking, etc. then you get a very fast box. If what you are doing requires lots of very fast hardware, then yea AWS or anything like it is not really for you. But if you are like most people, your AWS bill is not going to break the bank and you can just spend one less billable hour figuring out why the server is slow, and just double its size.
Compared to provisioned IOPS SSD, it's about the same. Compared to regular "burstable" SSD it's much much better. The gp2 EBS SSD is not actually meant to be used for data storage, something which AWS hasn't done a good job of making clear.
2 years ago I would've gone with a vanilla 3 tier app in AWS with cloud formation... Now I'd pick DO with a CoreOS cluster running Docker containers for each service... or maybe Atlas by Hashicorp [1]... No vendor lock-in, still flexible and fun to build... =)
I'm a real newbie in terms of web server deployment, but for my first web app I went with an EC2 VPS because I had no idea what sort of traffic to expect and how I would handle spikes. Despite having a pretty decent VPS from Inception hosting (whom I recommend, no affiliation), I wouldn't know what to do to scale up.
EC2 seems to handle all that nicely by letting you just upgrade instance types as you need them, and providing burst performance for spikes in traffic. It seems like a pretty fire-and-forget solution and I've not paid them any money yet (10 days, 30,000 hits)... So far I'm happy but really I've no idea what I'm doing.
It can also totally depend on what you need, instance-wise. I have a workload that includes a lot of processing and high-memory requirements.
A 60GB r3.2xlarge spot instance on AWS will cost you about $50/month while on DO you'll be paying $640/month for a 64GB machine.
Granted, the DO machine will be way more performant, and you have to have a workload that suits spot instances.
Every time I look at things like DO to see if I'm missing out I price up my current AWS setup and they're always astronomical (for my use case).
Then there's all the other control around AWS; it's so much more advanced than all the other services. Nobody else really comes close to the flexibility they give you.
For a lot of (probably even most) web apps that probably doesn't matter. Have a look at your use case and decide if AWS is worth it.
You're comparing apples with watermelons. The only thing vaguely similar is the memory, and it's only cheap because you get it randomly as the market fluctuates.
In every other regard - disk space, CPU cores, data transfer, availability - the AWS spot instance option is MUCH worse than a regular VPS like from DO, or even a dedicated physical host.
Ignoring the CPU core difference, a regular (i.e. so you can use it all the time) instance with extra EBS storage and data transfer to match the DO instance you mentioned, would be $1500/month.
Places like Rimuhosting will rent you a pre-used dedicated server with 128GB RAM, 2TB HDD + 200GB SSD Dual Xeon (12 cores, 24 HT) physical server (which you can then run a single Xen VM on, for better portability) for $400 a month. Yes it's more than your $50 a month, but its completely yours, for as long as you want it.
To truly take advantage of a spot instance and NOT have it impact your business, your workload needs to be very tolerant of interruptions and variable processing time per day. For the vast majority of people using EC2 (web/app servers running 24x7) it's not a realistic option.
Agreed. But that was also my point - it depends on your application.
Aside from that though, spot instances aren't that volatile. I have some that have been running for months. Obviously they're not always at the low low price they can be, but if you average it out, they're not much higher than that.
In total honesty, I don't use those machines I mentioned. I use ones with 32gb ram and much better CPU performance. I need that ram for what I'm doing and any other provider I've found comes in a lot more expensive to satisfy that requirement. The CPU I get is good enough for what I'm doing.
But again, I don't know anyone other than Amazon that has an infrastructure that flexible at that price.
To me AWS still suffers from the same problem that most others do - their pricing is based around fixed allocations of everything (i.e. CPU, RAM, local disk space) - what if you want lots of RAM but don't need lots of disk space? Or Vice versa.
Oh for the.... Could whoever down-voted this please have the decency to chime in with a reason?
If there's anything incorrect with what I've said, please point it out. I'd love to know about other providers that would give me more bang for my buck.
Is it the assertion that spot instances are a viable option for some use-cases? Is it the fact that I compared something to DO?
