We were on DigitalOcean before GCP. They're okay. They're cheap, but can't really compare to GCP in terms of performance, stability, networking, object storage, etc. Their Kubernetes offering is also a GKE competitor, not a "Kubernetes first" cloud.

At least DO supports IPv6, for our application the 40ms latency penalty we encountered for half our customers when on GCP from not supporting IPv6 was not worth it. On that note, HE.net really peers with everyone over IPv6, even ISPs that won't peer with them on IPv4, its quite impressive how much better the routing can be on certain ISPs due to this!

Genuinely curious: how does the lack of IPv6 cause 40ms of latency?

Users on Centurylink Fiber can reach us in 4ms over IPv6 (despite it not being true IPv6) versus 45ms to 60ms with IPv4. DSL is similiar but not quite as notable, more like 30ms of saved latency.

The root issue is Centurylink has no peering with Hurricane Electric on IPv4, and ditto for peering with numerous other providers, versus on IPv6 they have a much more open peering policy. This seems to be common among a number of ISPs, though as time goes on this issue will hopefully ease.

Tunneling to a v6 provider.

More like the end user gets routed through bespoke connections hundreds of miles away due to ISPs like Centurylink not openly peering on IPv4 at Internet Exchanges, whereas on IPv6 they seem to have local routes to Hurricane Electric and many others on the West Coast, thus no need for traffic to go back east!

Last I checked, DO still fails to allocate as little as a /64 to droplets. They provide a shared /64 out of which you are allowed to use 16 individual IP addresses.

In IPv6 land, that can introduce a lot of pointless complexity.

It would be reasonable for customers to be able to expect the ability to get /48s or /56s. Instead they don't even get a proper /64.

It is silly that most IPv6 enabled VM providers are stingy with IPv6 addresses, hopefully that will get better over time.