Stuff is just really immature and you'll get blocked by lots of things that make no sense.
If you have to get vendor locked in your quest to not have to manage servers while learning unintuitively misnamed parts of a computer, choose Amazon.
Here's a few I can remember off the top of my head:
- A (relatively) huge 6ms lag between the website and the DB
- One (random) site will mysteriously max out on memory on app-pool startup and take all the others down
- Their scheduler has no concept of timezones
- Their scheduler uses your local time when setting up the job, but UTC for other parts (this has been an open issue for over a year I think)
- Files will get mysteriously locked in deployments and the deployment process will silently fail
- Deployments will suddenly take an absolute age for no reason
- The entire admin UI will slow to an absolute crawl for hours on end
- Some admin tasks always claim they've failed, even though they've succeeded
- Their API wrapper is just wrong on almost every level
Add on top of that the worse management UI I've ever had to deal with and it makes Azure very painful to use at times. Some-one thought nesting menus in a standardised format was a good idea. It wasn't. Everything is fairly terribly named too. Want to see how your deployments doing? That's under "Deployment Options".
Performance is also dogshit compared to the cost, my 4 year old laptop is faster than their "premium" offerings.
Portal i agree is partly confusing/messy but we set up things once and then do deploys via CI infrastructure. And even the initial setup we try to automate using PS instead (to make it reproducible).
When it comes to pricing I agree, but my laptop does not do multi-datacenter so well.
Im not questioning anything you say of course. Maybe I've gone blind or don't see the issues as critical as you, or maybe I'm just more lucky.
Email: [email protected]
Disclosure: I work on gcp support. Not paid to be here.
Next, your client faced issues with replication in GCE, thats not good to hear, but we do face issues in our AWS RDS MySQL and Aurora very frequently. RDS MySQL error logs not generated properly. Aurora has weird memory leaks, connection spikes, starting to behave sporadically when the memory crosses 80% and so on. We are working with AWS to figure out the issue still (credits to the AWS Support for trying to help us). So, to conclude whether you are in AWS or GCE this is the trade-off of "cloud". We need to live that, if you are moving to cloud !!
My experience with GCP in the past 4 months has led me to revise my "friends don't let friends use App Engine" motto to "friends don't let friends use Google Cloud", there isn't a single service I touched (except maybe Compute Engine) that didn't have half-baked client libraries, documentation, bugs in the server part, or a complete failure by Google to even have their engs use the competitions tooling before inventing their own shitty clone (DNS)
And I would have been totally fucked over by that Postgres connection limit when we went into production, I'm glad I dodged that bullet! I hadn't bumped into that when playing with dev environments, and I haven't seen that limit mentioned anywhere.
Firewall settings work just fine for our platinum clients with complex network architectures, I don't see why it wouldn't in your case unless something was misconfigured.
Normally I'd think I had configured something wrong, except in this case it was insanely simple. A network label that allows all ports both ingress and egress, to any destination/source, definitely applied to the servers, and yet they had constant connection issues with each other.
It probably was something I did, but the combination of those issues, surprise egress bills, very laggy UI, and various other little niggles just made it not worth my time for now. I'm keen to avoid vendor lock-in anyway, so GCP and AWS don't have that many extra features over smaller providers for me.
DDB -> NoSQL, No Automatic backups, No support for ad-hoc querying, eventual consistency (though you can set to get consistency with few tradeoffs) Spanner DB -> RDBMS, Automatic backups, Enriched SQL, Strong consistency.
Let me if you still think its fair to compare these 2 databases.
What I've found in aggregate is that GCE is a bit easier to use at first as AWS has a LOT of features and terminology to learn. When it comes down to it though, many GCE services felt really immature, particularly their CloudSQL offering.
One client recently moved from GCE to AWS simply because their CloudSQL (Fully replicated with fail-over setup according to GCE recommendations) kept randomly dying for several minutes at a time. After a LOT of back and forth Google finally admitted that they had updated the replica and the master at the same time, so when it failed over the replica was also down.
There were other instances of unexplained downtime that were never adequately explained, but overall that experience was enough for me (And the client) to totally lose faith in the GCE teams competence. Even getting a serious investigation into intermittent downtime and an explanation took over a month. By that time our migration to AWS was in progress.
GCE never did explain why they would choose to apply updates to replica + master SQL at the same time and as far as I know they are still doing this. I asked if we could at least be notified of update events, was told that's not possible.
There were other issues as well that taken together just made GCE seem amateurish. I'm sure as they mature a bit things will get better, and it is cheaper which is why I wouldn't necessarily recommend against them for startups just getting going today. By the time you are really scaling it's like they'll have more of the kinks worked out.