> Provisioning is conceptually cheap, and this is their killer feature. You click the "Make a new VPS" button, you pick your distro, how much RAM you want, and an SSH key, and they spit out an IP address less than a minute later. `ssh [email protected]`
> There's also an API for automatic provisioning if that's your thing.
Oh, it is, and I wish these comparisons would consider the API more, since deploying a node via Linode's API and DigitalOcean's API are probably comparable. Declaring "my UI is faster!" as a sales point is disingenuous, since Linode is merely offering more choices during the provisioning workflow. Since you're saying "click", I assume you mean the UI too; at scale, absolutely nobody uses the UI any more. I manage a fleet in the thousands on AWS, and the last time I logged in to the AWS Web Console was about six months ago. It takes at least two minutes of clicking to spawn an instance in Amazon, but earlier today I launched 38 instances in about thirty seconds using the API.
> - No kernel upgrades. The kernel is kept outside of your virtual machine, which means that if you upgrade your kernel, then you'll get mismatched modules and your network interface won't come back. They've pinned kernel updates in ubuntu so this shouldn't be a problem, but you have to say "IgnorePkg = linux" in your /etc/pacman.conf if you're on arch. Security updates will be a pain though...
This isn't unique to DigitalOcean and is fundamental to the way Xen works (the kernel is loaded by the host, not the domU). However, Linode solved this problem better by providing kernels with most modules that you'd ever need built-in. You can upgrade all you want on your filesystem and not run the risk of hosing your machine, because your modules generally aren't considered at all. You can still add them by compiling against the upstream Linux sources, but the core modules aren't loaded from your filesystem (on my Linodes, my modules/ directory for the running kernel is empty). There's also a loader for your own kernel on the filesystem, PV-Grub, which DigitalOcean doesn't do.
> - You can't boot into a recovery image/liveCD. If the above happens to you, I assume you'll have to either restore from backup or file a ticket and ask them to pick things out of your VM's hard drive. (You do get raw console access provided by an HTML5 VNC client, which can be useful)
Only if you screwed networking. Lack of recovery = showstopper.
Here's the docs for DO's API: https://www.digitalocean.com/api I agree that UI isn't strictly necessary, but the reason why I brought up the UI was because as an "amateur" user, that's what I care about.
Using external kernels isn't in any way fundamental to the way Xen works. Most standard setups (even PV) have the kernel inside the VM, which allows for standard upgrades, etc.
Why are you mounting customer images on your host fleet? Put another way, what do you supply for "kernel=" in xen.conf? A file from your customer's filesystem?
> There's also an API for automatic provisioning if that's your thing.
Oh, it is, and I wish these comparisons would consider the API more, since deploying a node via Linode's API and DigitalOcean's API are probably comparable. Declaring "my UI is faster!" as a sales point is disingenuous, since Linode is merely offering more choices during the provisioning workflow. Since you're saying "click", I assume you mean the UI too; at scale, absolutely nobody uses the UI any more. I manage a fleet in the thousands on AWS, and the last time I logged in to the AWS Web Console was about six months ago. It takes at least two minutes of clicking to spawn an instance in Amazon, but earlier today I launched 38 instances in about thirty seconds using the API.
> - No kernel upgrades. The kernel is kept outside of your virtual machine, which means that if you upgrade your kernel, then you'll get mismatched modules and your network interface won't come back. They've pinned kernel updates in ubuntu so this shouldn't be a problem, but you have to say "IgnorePkg = linux" in your /etc/pacman.conf if you're on arch. Security updates will be a pain though...
This isn't unique to DigitalOcean and is fundamental to the way Xen works (the kernel is loaded by the host, not the domU). However, Linode solved this problem better by providing kernels with most modules that you'd ever need built-in. You can upgrade all you want on your filesystem and not run the risk of hosing your machine, because your modules generally aren't considered at all. You can still add them by compiling against the upstream Linux sources, but the core modules aren't loaded from your filesystem (on my Linodes, my modules/ directory for the running kernel is empty). There's also a loader for your own kernel on the filesystem, PV-Grub, which DigitalOcean doesn't do.
> - You can't boot into a recovery image/liveCD. If the above happens to you, I assume you'll have to either restore from backup or file a ticket and ask them to pick things out of your VM's hard drive. (You do get raw console access provided by an HTML5 VNC client, which can be useful)
Only if you screwed networking. Lack of recovery = showstopper.