Live data from Hacker News

Goodbye Google Cloud, Hello Digital Ocean

lugassy.net

51–60 of 73 posts

Re: Goodbye Google Cloud, Hello Digital Ocean

#51

Huh. I have zero experience with using cloud services, but I'm a bit surprised by the complexity of both of those UIs. I always assumed it was way simpler than that. Like, I thought it was as simple as using a command-line tool, like "docker run " but "cloud run.." As there any cloud services like that? Where you just specify your environment and CPU features you need etc from a single console command?

You could script something like this pretty simply with the DO api, and there might well be programs out there already that operate in a similar way. My own needs are modest, but I have provisioning scripts that create and destroy DO droplets on-the-fly from the command line.

guys use ansible. it care less about who's the cloud provider and uses ssh (agent-less configuration).

Re: Goodbye Google Cloud, Hello Digital Ocean

#53
post #34

Earlier quoted context omitted.

+1 you said what I was going to say. GCP probably doesn’t want the business of small web sites and portals. I think that under Diane Green they have a clear vision of who their target (large/huge) customer base should be and what they need to do to attract those customers. For small projects, especially when I am paying the bills, it is difficult to beat OVH and DigitalOcean on costs. That said, GCP is still my favor…

I hear you. Miss most of the tools and infrastructure every day since I left. I was ecstatic when they made PubSub available to everyone. Wish they would expose more of the internal services, especially Colossus, Dremel, Borg, ...

dremel = bigquery, borg = GKE.

Re: Goodbye Google Cloud, Hello Digital Ocean

#54
post #50
post #46

Earlier quoted context omitted.

The high bandwidth is because with cloud services like AWS and Google Cloud you'd be serving most traffic from either object storage (like S3) or their CDN. Both of which are in the same region as the DO bandwidth figure you quoted. This not only reduces your compute bandwidth costs but also drastically improves your application performance when under load (and as an added bonus you also reduce your compute CPU costs…

S3 is $0.023/GB (still x4 higher), plus $0.004 per 10K requests CloudFront is $0.085/GB, plus $0.0075-$0.01 per 10K requests) GCP is $0.08-0.12/GB (same for all services), plus $5 per 1M requests) And who says most of the bandwidth goes towards static assets? 99% of our requests are dynamic (thus the NodeJS frontends)

> And who says most of the bandwidth goes towards static assets?

It obviously depends on the application but generally you'd expect that to be the case for web sites (ie not services that act only as an API backend).

> 99% of our requests are dynamic (thus the NodeJS frontends)

I don't know your business so you might be transferring more dynamic data rather than static but your argument here doesn't help explain your business as you're mixing metaphors. eg most of our requests are dynamic as well but JSON APIs will generally return smaller chunks of data compared to an image. So in real bandwidth terms on our application, more data is transferred for static content rather than dynamic. None of the static content touches our web servers though. In fact a fair amount of the dynamic content doesn't either since a lot of that isn't user specific so is served from caching services.

If you don't mind me asking, how much bandwidth you transfer each month? Even taking the above into account, our bandwidth costs (which is nothing compared to when we self-hosted) gets dwarfed by our computing costs (VMs and DB).

By the way, how are you finding node.js for your workload? I find it a weird choice if 99% of your requests are dynamic based on bottlenecks I've experienced when deploying test systems on it. But I ask about your experiences because I've not used node.js for anything at scale (ie just a few thousand requests a second).

Re: Goodbye Google Cloud, Hello Digital Ocean

#55
post #18
post #15

So he basically uses ec2 equivalent service and is complaining about the existence of other services.

yes. except DO bandwidth is $0.006 instead of $0.09/GB. am I paying extra for the sole existence of other services?

Why are you assuming that the additional cost is for the extra services instead of a more reliable infrastructure for example?

Re: Goodbye Google Cloud, Hello Digital Ocean

#56

Earlier quoted context omitted.

What do you do that serves 1.2mm requests / second? I don't disbelieve you, I'm just wondering what type of site that is since English Wikipedia is several orders of magnitude lower than that.

Ads, one of the most shitshow industries in the world.

So Google built a platform that is excellent for running ad networks. It seems so obvious now.

Re: Goodbye Google Cloud, Hello Digital Ocean

#57
post #23

Earlier quoted context omitted.

Did you know that DigitalOcean provides "High CPU" droplets?

Interesting, I missed this announcement. This is definitely a step in the right direction to competing for CPU bound workloads. "Achieve up to 4x more CPU performance on High CPU vs Standard Droplets." I guess we can take this to mean that standard droplets virtual CPUs are contended at 4:1 - I would of thought it be higher.

You should also check out Vultr's dedicated core plans [1]. I have ~50 instances running on Vultr and CPU performance / unixbench scores are significantly better than DO and Lightsail's similar sized instances.

[1] https://www.vultr.com/pricing/dedicatedcloud/

Re: Goodbye Google Cloud, Hello Digital Ocean

#58
post #23

Earlier quoted context omitted.

You're getting 2 (or X) virtual cores - which means absolutely nothing and can vary from minute to mintue / hour to hour - Linode was even giving 8 virtual cores with the cheapest plan 2/3 years ago. Virtual cores on Linode/DO/Vultr are shared/contended, basically undefined in terms of lower bound performance - you are at the mercy of other tenants - and there's a lot more tenants in the building too (where number of…

Did you know that DigitalOcean provides "High CPU" droplets?

Disclosure: PM of High-CPU Droplets @ DigitalOcean

I'd highly recommend people check out the performance of the High-CPU Droplets for any compute-bound tasks like CI/CD, batch processing or active front-end web servers.

Someone from our team put together a comparison of compute series machines which includes GCE and you can see the price-to-performance ratio here is pretty solid for DigitalOcean: https://imgur.com/a/o16t2

Re: Goodbye Google Cloud, Hello Digital Ocean

#59
post #53
post #34

Earlier quoted context omitted.

I hear you. Miss most of the tools and infrastructure every day since I left. I was ecstatic when they made PubSub available to everyone. Wish they would expose more of the internal services, especially Colossus, Dremel, Borg, ...

dremel = bigquery, borg = GKE.

Yes, those are using the technologies underneath the hood, but are not them itself. I would like to have access to them directly as I would like to build other things at top of them

Re: Goodbye Google Cloud, Hello Digital Ocean

#60

Huh. I have zero experience with using cloud services, but I'm a bit surprised by the complexity of both of those UIs. I always assumed it was way simpler than that. Like, I thought it was as simple as using a command-line tool, like "docker run " but "cloud run.." As there any cloud services like that? Where you just specify your environment and CPU features you need etc from a single console command?

What you are probably looking for is a PaaS (App Engine, Heroku, Zeit Now, etc) not IaaS

On GCP you can run:

gcloud app deploy

And it will deploy your app on App Engine, with auto-scaling built in. The thing is, that is just the start. Pretty soon you will need databases, caching, versions, etc, etc.

(I work for Google Cloud)

Post reply on HN