4 ms·
I used to be a huge fan of GCP and bet on it to power my startup, and have come to greatly regret it. Recently, I needed to increase a CPU-limit quota from a s
by stevencorona 6y ago
I used to be a huge fan of GCP and bet on it to power my startup, and have come to greatly regret it.
Recently, I needed to increase a CPU-limit quota from a small number (like 16 vCPUs to 64 vCPUs) - nothing crazy. In the past, the quota increase system was more or less automated and would only take a few minutes to process.
This time, however, GCP denied my quota increase and forced me to schedule a call with a sales rep in order to process the quota increase. It was the biggest waste of time and kind of goes against the entire point of instant cloud resizing.
It also feels like the velocity of new features, instance types, etc has slowed down dramatically in the past year. Also, while I'm ranting, Google Cloud SQL is probably the worst cloud service I've ever used (and it costs an arm and a leg for the pleasure!)
- mhh__ 6y agoIs the call just so they have a window to upsell you?
- stevencorona 6y ago100% upsell. Felt like sitting through a high pressure timeshare sales pitch to get the free gift at the end
- marcinzm 6y agoI got the same treatment but I think I came off as annoyed enough in my message to sales (with an implied threat of just moving to AWS) that I didn't get an upsell conversation.
- eyal_c 6y agoI just started using Google Cloud SQL – the allure of a managed Postgres service was strong. Can you share some of your experiences with it?
- stevencorona 6y agoSure. - No way to upgrade major postgres version without full export and import into new cluster. - Incredible delay between postgres versions. IIRC, it took nearly 2 years for them to add postgres 11 after it was released. - HA is basically useless. Costs double, still has 4-5 minute window of downtime as it fails over, doesn't avoid maintenance window downtime (both primary/standby have same maintenance window) and you can't use it as a read replica. Honestly, feels like a borderline scam since I'd imagine a new instance could be spun up in the same amount of time a failover takes (but I haven't tested) - With default settings, we experience overly aggressive OOM-killer related crashes on a ~monthly basis during periods of high utilization. On a 32GB instance, OOM killer seems to kick in around 27-28GB and it's incredibly annoying. - Markup over raw instances is almost 100%, with no sustained use discount outside of a yearly commit. It's just a lot of money to pay for a crashy, outdated version of Postgres.
- cakoose 6y agoI need to run Postgres in production soon. I've used AWS RDS (MySQL) in the past, but am also considering Google Cloud SQL. Things that seem similar in AWS: - For major version upgrades, you need to bring up a new instance from a snapshot and catch it up with replication. - HA failover results in a few minutes of downtime. (They claim using their SQL proxy will reduce this.) - Lag in providing the latest Postgres versions. GCP seems to be a bit ahead of AWS here. Is there a managed Postgres offering that you prefer? Aiven looks nice, feature-wise.
- stevencorona 6y agoTo clarify, it’s a lot more work than bringing up a snapshot. You need to do a full export as SQL and reimport as SQL. Super annoying, slow, and requires hard downtime. Am using SQL proxy but doesn’t do much re: HA. I don’t know, I’ll probably just run my own Postgres at some point. The only peace of mind that I get from Cloud SQL is the automatic backups.
- x86_64Ubuntu 6y agoWhy don't they make the upgrade seamless? If it's truly an export/import process, then it should be dead simple for them to do that on their end. Especially after they've snatched your db from serving requests
- cbushko 6y agoCloudSQL was slow for us until we do the following: 1) Increase the disk size to 100GB as this increases the IOPs 2) Switch to using private IP addresses. Huge speed increase 3) get rid of cloudsql-proxy. Another huge speed increase These 3 things have kept our database instances very small and costs low.
- ransom1538 6y ago3) get rid of cloudsql-proxy. Another huge speed increase ^ Do not use cloudsql-proxy ever. GCP docs are wrong. DO NOT proxy all your db requests through a single VM.
- cbushko 6y agoOurs cloudsql-proxies were on running on GKE so they were not "that bad". Switching to private ip definitely had the largest impact by far on performance.
- DangitBobby 6y agoIf you need very high throughput I can appreciate this advice. Generally though, cloudsql-proxy is fast enough for most use-cases.
- nlightcho 6y agoWhat about running it as a sidecar in the backend pods?
- lukeschlather 6y agoThis causes some other problems... Kubernetes doesn't do a very good job of treating the sidecar as part of the main container so you will get random disconnects in your app when the proxy is restarted unexpectedly. This is actually why we abandoned it, just to deal with the random hiccups. Hadn't even benchmarked it.
- stevencorona 6y agoYeah, have hugely over provisioned disks for IOPS. Am still using public ip + cloudsql-proxy because the alternative didn't exist when I first deployed, but I'll try switching.
- Aperocky 6y agoWait what, it's not available through an API? That's ridiculous.
- Clewza313 6y agoOf course there's an API for creating and resizing instances. The issue is there are quotas that cap how many CPUs you can have, and increasing that is a manual process.
- Aperocky 6y ago64 is awfully low for a sudden manual process though.
- pid_0 6y agoYour project is limited to quota ceilings. Those can be increased if you spend enough money on GCP. AWS has a similar thing.