As a DevOps consultant I've actually worked with clients migrating stacks to and from GCE/AWS (Yeah, both ways, not the same client).
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.
(GCP support here)
This is a known bug, I've worked at least a few cases where this happened. There is a feature coming out soon that will allow different maintenance schedules to be set for masters/replicas, which will likely be automatically set for different times. And, once the kinks get worked out, hopefully we'll be able to re-deploy the feature that shifted traffic to failovers while the master is being updated, and eliminating maintenance downtime altogether.
I use Azure all the time (app services, storage, cloud services,VMs, SQL, CDN etc) and almost never run into this issue. Can you share some example on what you mean?
I use all that stuff and constantly run into it, are you using it in anger?
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.
No I'm using it happily. We don't use the scheduler and create new deployment slots when deploying (which maybe prevents locking issues). Sometimes I experience oddness in Azure portal and has to refresh but has never had it slow down. As for SQL latency it's been insignificant to us so I'm not sure if what we experience is better or worse than yours.
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.
Hi, I am not sure you will read this as it's 10 hours after posting. The cloud sql updating both copies sounds like a bug. If you want to email me your case number I can look into it. I know you don't work with GCP anymore but I like to resolve the issue for other users.
Email: tsg@google.com
Disclosure: I work on gcp support. Not paid to be here.
As a Database Engineer working for one of the largest e-company in the market, I can clearly see your point. Definitely AWS RDS is very matured when compared to CloudSQL. I think CloudSQL only provides MySQL and Postgres (still in beta?). So GCE needs to build their Database Arsenal soon.
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 !!
Cloud Postgres is also hilariously hard limited to 100 simultaneous connections (the default). Doesn't matter how much RAM you give it.
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)
I was super keen to switch to GCP (for cost saving etc) but this mirrors a lot of my experiences. Deploys to App Engine took 20 minutes, not 2 minutes, and I have absolutely no faith in their firewall settings actually working. I have no idea what the problem is, but it's basically impossible to boot a Rancher master node on Compute Engine. Even with all ports open. In the end I just bailed on the platform as a whole, and I'm moving to a hybrid approach on smaller providers like Packet.net and Digital Ocean.
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.
App Engine Flex takes a long time to deploy, and always has. App Engine standard is what deploys quickly, and also scales quicker.
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.
Isn't Flex the newer of the platforms? Is there a reason why it's so slow to deploy? I deployed an app via it that deploys in a couple of minutes anywhere else, including build time, but it took an insane amount of time on GAE, and I never managed to find a good reason why.
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.
Because a key-value store is a foundamentally simpler data structure (it's an hash) than a relational database, which tracks the relations between different data types. If you make an advanced use of the key-value store, you have a lot of logic in the application (for example to key management, cascade operations between related data...) which a relational database should do for you. It's not fair because there is a development cost in using the key-value you are ignoring.
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.