Comment by halfmatthalfcat | Hacker News Reader

Comment by halfmatthalfcat | Hacker News Reader

halfmatthalfcat

I love DigitalOcean. The simplicity of their UI, friendly CLI tooling and (as a hosted k8s customer) the frequency of updates to their offerings.

BUT:

1. Their web UI stability is terrible (constantly hangs and errors out)

2. Their hosted DB IOPS aren't competitive with other PaaS providers. There's also no way to scale DB size dynamically without upgrading to a new price tier which is overkill.

3. Their Kubernetes Control Plane scaling is obfuscated. I had to contact support to realize that the control plane nodes are somehow tied to the size of your node pool when you create the cluster? That's not documented anywhere and was the cause of many control plane timeouts.

4. No ALIAS dns record, no way to serve Spaces from an apex domain. (I know this is a vendor specific implementation but it's table stakes imo)

Again, I'm a (mostly) happy DO customer and wish them the best but if they really want to be seen on the same level as AWS or GCP in terms of some parity, they need to include some of these QoL features.

They also have some of the best technical documentation on the web.

They really do. And it goes in tangents and details I wouldn't have expected. Their support is great.

As I started learning how to spin up and manage Linux servers and then deploy my own (unmanaged) k8s on them, half of my bookmarks are DO documentation.

Content growth done right.

Yep great SEO Strategy and raising Brand awarness. Win-win for people searching. Find out about how to install nginx on Ubuntu and then memorize that next time you need a VM you go that blue website with great tutorials.

This is a major reason that I became a customer and have been for 8+ years.

Couldn't agree more. I wanted to setup nginx and add users in the sudo group and almost always their articles were the first to appear.

I'm sure their own documentation is good, but certainly early on the tutorials always seemed to be a mess. Lots of similar articles written by different people with different structures and advice, without referencing other related tutorials. There seemed to be very little in the way of editorial control, but maybe that's better now. It was a good, cheap content strategy for SEO, but not a genuinely good resource.

Having 5 people install slightly different varations of a stack provided so much value it was and still is the best resource when installing a new stack.

Thats because a lot of it was lifted directly from the web. They paid people a stupid price per article to either write articles or copy paste documentation online while barely vetting it, only taking it down when people took the time to send in reports to staff. I'm sure things have improved since then.

I agree, I had limited knowledge on a few things and was able to get it all sorted with their guides. I think they offered an exchange of credits for tutorials or something. My favorite part of their guides, the drop downs to pick your version. Google can give me results to a simple ubuntu question that is ten years old, they had the option to pick which version you were using to get you the correct guides. Brilliant

I hold up this part of DO as one of the single best uses of the amazing tech writers our industry has, under appreciated and under paid, to punch way above their weight in a crowded market.

Really really well done DO!

I actually think their UI is too form over function. One particular annoyance I had recently was with the DNS zone editor.

It truncates both the record contents and the domain name, which means that if you've got a bunch of long domains with TXT records, telling them apart means copying the contents into a text editor to see the truncated text.

e.g

  somekey._dkim.subdomaina.domain.com     k=rsa; t=s; p=MIGfAAAA
  somekey._dkim.subdomainb.domain.com     k=rsa; t=s; p=MIGfBBBB
  somekey._dkim.subdomainc.domain.com     k=rsa; t=s; p=MIGfAAAA

getting truncated down to

  somekey._dkim.subdo...     k=rsa; t=s; p=MI...
  somekey._dkim.subdo...     k=rsa; t=s; p=MI...
  somekey._dkim.subdo...     k=rsa; t=s; p=MI...

Compared to AWS, which is visually unappealing, but I can actually see my DNS records....

I agree, but I seem to recall creating/editing records much easier than Route53... particularly with the console redesign.

I agree. I think their UI is actually a little too creative at times. It has lots of whitespace and a single color and that means people will say "clean", "minimal", "modern", "artsy fartsy".

But I agree, that with something that coins itself "the developer cloud" it should provide critical information first. It is ok to kill some whitespace or put some monospaced fonts in there. You aren't trying to sell me an iPhone, I am trying to manage a server.

Route53 on AWS is what I have been using for domain management and I like it because it doesn't mess around with cute UIs. It is strictly function. Instead of form fields for each TTL line and host line like other sites do, you just get a big multi-line text box and you use spaces and line breaks (gasp) to create your dns listings.

I actually like their UI - I think Azure or AWS looks fairly scary to me, someone not that familiar with cloud architecture.

5. Their IPv6 support is pants on head.

https://www.digitalocean.com/docs/networking/ipv6/

Yes, you read that right, they assign a /124 if you enable IPv6. There is no provision for getting anything larger. All configuration is totally static as well. It's really incredible how botched the setup is, and it has been like this for years.

If you're wondering if you're sharing the same /64 with an entire datacenter worth of droplets, the answer is of course.

This -- this has me a bit frustrated and I'll eventually email them about it.

I haven't contacted them about it but that makes sense sadly. So they're getting a /64 from their upstream and just sharing that out to everyone. This isn't IPv4, they need to make this right.

Vultr, OTOH, gives each HOST a /64. I've been doing most of my work on Vultr right now so I can use more than 16 IPs on a single host. I was/am hoping that providers would standardize somewhere in the middle: Every customer account in each datacenter gets a /64. I wouldn't mind all of my hosts having their own /64 to subdivide.

The smallest allocation a customer should ever get with IPv6 is a /64. You break a lot of stuff when you go smaller. DigitalOcean's approach is kind of like sticking an entire datacenter behind a single IPv4 address.

It's not like it is hard to get IPv6 address space either. All they have to do is ask. A VPS provider like DO can get a /32 easy peasy.

DigitalOcean has /32s from ARIN and RIPE.

(And a /48 from APNIC???)

(Edit: And a /36, /40 and /48 from APNIC?)

That's OK, OVH gives you a single IPv6 address with some VPS configurations.

I don't know if I'm doing something wrong but am I right that a droplet firewall doesn't have any ability to create source exceptions to lock an open port down to a singular IP. Seems like a basic enough feature but I can't seem to find it.

Not being on the same level of feature parity with AWS/GCP can be considered a feature. Not everyone wants to drown in service orchestration and configs

100% - it's clear how everything works because they've pared down to the essentials. For their target market of small dev teams who just need to ship code, it's a godsend.

5. You can’t upload a custom image and assign a Floating IP to the Droplet, one of the most basic of the functionality of any cloud.

Just double-checked my DO console — yes you can, I have a droplet with both.

Edit: I'm wrong, see below.

Maybe we're talking about different things, docs here[0]

> You cannot assign a Floating IP to a Droplet created from a custom image.

Edit: I wanted to double-check because this would make my life so much easier, but no, I still can't use Floating IP with Custom Images. I imported a FlatcarLinux image from a URL and created a droplet; once the droplet launched, I still see this:

> Floating IP: Disabled

> Public IPv6 Address: Not available with custom images.

[0]https://www.digitalocean.com/docs/images/custom-images/

Interesting — checked again and what I'm using is actually a snapshot. Not sure why that makes a difference, sorry for the confusion.

I guess that would be a slightly laborous work around? Install vanilla linux, configure as needed. Save snapshot. Treat it as a custom image :)

Yeah, Snapshots work quite well, you can even transfer them between accounts and copy them between regions in the same account, but it's a "transfer" meant to be used as a migration mechanism, not distribution.

It seems like Amazon et al have full-fledged SDNs while DigitalOcean is a little more primitive. Even customer-level VLANs are new. Prior to that, "private networking" was just a way to save on transit quota; you shared a LAN with everyone else in the datacenter.

Speculating and recalling old memories here, but: floating IP is implemented as an additional IP on an existing interface. DHCP can't assign multiple IPs for the same MAC. So there's got to be some DigitalOcean magic in the base images to figure out that a floating IP is assigned and configure the interface for it. You might be able to replicate this yourself, they just don't want to be responsible for support.

Perhaps over time they will grow a more complex network fabric that will enable floating IPs to be their own DHCP-enabled interfaces straight on VMs, instead of the "dumb" forwarding rules they appear to be today. But also perhaps the lack of such things is why DigitalOcean is cheaper than Amazon.

Agree on all points (and definitely, a mostly happy customer too).

(3) was the cause of numerous production incidents for us. We had to contact support to have it scaled up, and sometimes they'd take up to 3 working days to get back to us. Happily paid more for AWS to get better support, and stability.

Nothing is perfect. We use DigitalOcean Droplets because they're more bang-for-buck than AWS EC2 instances, especially if you're doing a lot of disk IO. However, even though it's more expensive we use AWS S3 instead of DigitalOcean Spaces because it's faster, more reliable, and replicated automatically. I wrote about these decisions recently here:

https://wakatime.com/blog/46-latency-of-digitalocean-spaces-...

I would add the DO API being all or nothing with permissions to that list.

Not being able to give just DNS access to a script for updating LE/ACME DNS challenges means it'd be a non-starter at work.

Their support is also very lacking, multi thousand a month spend with them buy tickets still take hours. But support seems the hardest thing to scale especially with the number of tickets they get about things not their fault.

We had the chance to buy a support plan with DO in a previous job. May be worth asking if that's something they can help with?

I'm _really_ disappointed with the managed DB service. The "75 simultaneous connections per gigabyte of usable memory" limitation means cost wise it's cheaper just to spin up a 'real' database droplet.

> means cost wise it's cheaper just to spin up a 'real' database droplet.

This is the case for literally every managed database service that I'm aware of.

You pay a premium for the managed aspect.

That's an entirely fair point, but frustrating that the connection limits are not clearer in the docs.

FWIW, if you’re using 75+ connections, it’s probably a good idea to add some kind of Postgres proxy in the middle like pgbouncer. Postgres doesn’t handle lots of connections well because each connection forks off its own full OS process, and the performance can degrade noticeably when you have too many connections to Postgres as a result.

That’s been my experience, at least.

And DO's hosted Postgres allows you to easily configure pgbouncer.

I'm very happy with the managed DB service. A few gotchas, but the service itself has been incredibly stable with 100% uptime from what I can tell.

Reply on news.ycombinator.com