Holy crap is AWS bizarre to set up. I got it done without too much trouble in the end, but man, the UI is just atrocious. It took way too long just to find the right place to go to get started with the process.
phpMyAdmin is great when you're first learning to work with the LAMP stack; it lets you fiddle with values, manually create databases, munge columns, etc.
But.
If there are multiple instances of your system running "in the wild" (even just within your own company), and their versions will ever have even the slightest chance of getting out-of-sync? You really want the entire change-history of your modifications to the database checked into git. You want to be able to take any previous sorta-known database state, and move it toward the current well-known database state. To do that, you need programmatic migrations.
And as soon as your software ships a "db/migrate" folder, (non-readonly) phpMyAdmin access becomes anathema to proper configuration management.
AWS can be thought of as a big database that contains your EC2 instances and snapshots, your S3 buckets, etc. At scale, you only want to interact with this database programmatically.
So: if this was the correct hypothesis for why the GUI sucks, what would be an expected prediction? That the programmatic APIs for manipulating AWS would be great.
And they are! All the HTTP APIs for AWS--the ones you would use in any automated provisioning script--are simple, clear, and pain-free. They're definitely the "first-class" road to AWS, documented to heck, and it's clear that Amazon itself dogfoods them directly.
But I think there are plenty of mid-sized comapnies with multiple AWS accounts, with many machines in each one where no one is quite sure what they do or if they can be switched off.
Disclaimer: Sysadmin/Devops
So how does DO's api compares to EC2?
Meanwhile AWS has this nasty outdated SOAP API that you don't want to touch by hand with a 10-foot pole, you had better have a good AWS library for your existing language of choice or know how to make sense of a WSDL.
Um, no. Every AWS service has a REST API. The only difficult thing is calculating authentication headers, but that's nitpicky for a good reason.
S3's API is extremely RESTful -- not perfect, but really good. Some of Amazon's newer APIs aren't as RESTful, but they're usually still better than what many people call "REST" today (i.e. "Hey it's not SOAP, so who cares if every flipping thing is a GET request, it must be REST!").
Yeah, AWS has some functionality/scaling features that DO and Linode don't, but it's a smaller set of functionality than I think some people initially assume.
Some examples:
* DNS can be set up to round robin * auto-scaling can be built in * load balancers are available and easy to use * For companies with multiple employees various levels of access can be granted to the system via IAM roles * you can add and subtract hard drives from an instance on the fly (EBS volumes) * You can set those volumes up as RAID if you so desire. * You can easily move IP addresses from one instance to another.
These are just the ones off the top of my head as I've been off AWS for about 6 months now. This doesn't even count how well the servers play with other amazon web services, like SQS, SNS, SES and RDS (queue, notifications, email, database).
That being said, I use DO for a few small sites I host because I don't need any of the features AWS provides.
I'd think round robin DNS has nothing inherently to do with the infrastructure - that's a function of the DNS server, right?
Yes, there are some things AWS has that other services don't. My own experiences have been that people default to thinking AWS==cloud and that's the 'best' option, and this thinking was prevalent years ago, well before SES, SQS, RDS, etc were extra reasons for integration. They've got good services, but have done a hell of a branding job over the years as well.
EC2 has two types of storage: local disk "ephemeral/instance storage" and network storage "EBS". Digital Ocean only provides local disk. In EC2 you can mix and match, but EBS is the most convenient.
If you do a stop and start on EC2 (very different to picking "reboot"). You will lose what's on local disk because stop/start is basically requested that you be moved to a different physical box. Data stored on EBS is not affected. On Digital Ocean if you "power off" you remain on the same host, but get billed at full rate whereas on EC2 you don't get billed for the time it's stopped. Rebooting on EC2 is the same as rebooting on DO.
If you use EBS for storing everything your data survives even if the hardware your instance is running on breaks. If the hardware breaks on Digital Ocean or on EC2 if you only use ephemeral (local) storage you lose your data. It's the same story on DO as it is on EC2. The only difference is that EC2 gives you the option of storage which can survive the physical box you are on dying (EBS).
Is that really the case - neither are using a SAN or RAID or other backup method to ensure data is preserved in (almost) all circumstances? Not so bothered about EC2 (due to EBS) but for Digital Ocean..? Poor show if that's the case.