It is hard to recommend Google Cloud
ashishb.net
ashishb.net
I get it, it was a "consumer" product essentially, hence selling the business to Squarespace instead of someone like Cloudflare. But anything related to DNS is going to make infra folk very wary of what else you might be willing to kill or neuter. It's just at that level of fundamental things that make operators skittish.
> I get it, it was a "consumer" product essentially, hence selling the
> business to Squarespace instead of someone like Cloudflare.
Ironically, I moved all my Google Domains domains to Cloudflare. Their revenue from being a domain registrar is likely a rounding error compared to their other products, but (1) now they have my credit card on file for value-add services, and (2) sometimes people with corporate spending authority ask me for advice about who they should buy cloud services from.Grocery stores don't make their money from selling bread and milk, but a store that doesn't sell bread and milk is run by fools.
CF could probably get a lot more customers if they would allow you to use custom nameservers for your domain.
Why would they want that? The whole point of CF as a registrar was so you could use the other services. The registrar is sold at cost. It's a way to lock you in.
So that's not the use of the domains. It's to make it easier / lock in existing customers.
But they never marketed it, among all the backlash over turning down Google Domains there was never any true call-out to this. To this day I suspect many people don't know about Cloud Domains (which still exists and accepts new domains). I can't fathom any user-related reason for this - the contract in selling to Squarespace must have forced Google to be unable to properly market Cloud Domains as a transition option. If not, the Google Domains PM truly didn't know the existence of Cloud Domains?
> Caution: Transferring a registered domain from a third-party domain registrar to Cloud Domains is deprecated and removed.
So, maybe, it will be killed soon then.
Squarespace's domain panel crashed with a nondescript error when I tried to update nameservers prior to transferring out, and they shut off the Google nameservers as soon as the transfer went through on their side. To add insult to injury, Squarespace makes you wait 5 days for a transfer, with no way to expedite -- and in my case, they waited 6 days, taking me offline on a Friday night. This was the worst experience I've ever had using a domain service.
You shouldn't ask people to migrate before having a documented, tested, tool-assisted, clear and intuitive migration flow that takes very little time.
At its core, alphabet is a services company, it does not sell goods (to the most part). Their board needs to decide if the company should focus on business services or consumer services and replace the executives with people who have experience in that area.
The actual quality of GCP is superb in my opinion. They have a flair for architecting excellent solutions. I prefer GCP over any cloud from a purely technical perspective. Their leaders just don't get that it isn't enough. They're not operating a toy or a museum of technical marvels. Actual people need to use it.
I saw tickets from high-paying, top-10 customers, go unanswered for days; no one senior enough on the team to answer felt it was more important than the day-to-day, and no one from the support/account executive staff felt they had the authority to demand it.
I see it otherwise. I think solving customer support is crucial to GCP's success, and since I agree with you that GCP is the better underlying product, there is a deluge of money passing Google by, just waiting for the right executive team to start caring about this to pick it up. Kind of like Microsoft pre-Satya.
* https://yosefk.com/blog/people-can-read-their-managers-mind....
I'n guessing that's because AWS support engineers live in eternal fear of ending up on a PIP if I rate them less than 5 stars.
After leaving Google I started working at a startup that runs its production environment on AWS. We debugged an issue and experienced exactly what you're describing: our MSK cluster refused connections. Eventually that was solved by rebooting something on their side. It took less than 24 hours from when we opened a ticket until the issue was resolved, with a few back-and-forth messages between us and the AWS support engineer.
Maybe it is a strategy for cleaning up old apps or something, but I doubt it
Contrast to Azure who despite their SLA had significant outages every few months that were very noticeable, sometimes even requiring us setting up an entire new K8s project from scratch. AWS is better in terms of reliability. Their UX is not great though, I often feel like I'm a wizard waving my wand with permissions and connecting things like audit trails. Many actions are a bit delayed in their effect. I've also had to contact support at times to raise arbitrary limits in the platform.
In balance I would recommend GCP. Their product closures have not affected me enough to scare me away. I guess experiences vary depending on which product we are using.
Full downtime for 2 days, no apologizes, no answers, had to pay 3% extra for support, no credits.
Special award to the dude representing Google trolling on Twitter that they will do another "wild Friday release".
Shitty.
AWS has slightly improved with their "budgets" and "budget actions", but it’s far from something I’d call a "spending limit".
Yeah they had to do something so they came up with a half-solution that basically informs you with a delay, doesn't prevent any quick damage and - if you decide to use budget actions - requires you to know what is actually causing the problem. Better than nothing I guess.
I wanted to link the specific article mentioning that, but it seems like this works now :)
I haven't tried it myself, and I hope it's true (:
So, TL;DR: Azure still doesn't allow you to set spending limits on Pay-as-you-go subscriptions
[1]: https://learn.microsoft.com/en-us/azure/cost-management-bill...
[2]: https://azure.microsoft.com/en-gb/support/legal/offer-detail...
Example is a sidebar that opens for adding an email during OAuth flow, after adding it clicking "Add" once did nothing, there was no feedback. Had to click it at least 5 times for it to go away and save correctly. In fact this is even specified in the documentation for the third-party tool (Google Drive downloader[1] step 18) that you have to click it multiple times. I don't think this is normal.
And also I should mention, depending on hardware specs the GCP portal was nearly unusable. So hopefully one will not need to rely on creating OAuth resources for a CLI program on the same computer. Although to be fair, I wasn't benchmarking against AWS/Azure on that hardware (since I needed to use GCP Google APIs).
[1] https://github.com/glotlabs/gdrive/blob/main/docs/create_goo...
Large shops - aka, a shop where you're not part of the controlling entity - tend to prefer either AWS, or Azure depending on how hard the CIO got wined and dined previously (and existing inertia - older shops that used AWS as an early adopter seems to stay with AWS).
> Their UX is not great though
i agree, but nobody really cares enough. On the other hand, i'd not pay more for better UX. Judging by the current state, i say a lot of customers fall into this category.
A decision maker can basically choose from where they want to get bribed, so it won't be a crucial factor most of the time.
azure is microsoft, so this explains that
gcp has "a vision": if you do not share it, it's a pain. Also, gcp has some sick design for core products : checkout load balancers if you want a "good" laugh. It's a stack of hack, put one on top of the others
I would not recommand against GCP, it's the average player: not the best, definitely not the worst.
This is an option, not a fact. Many of us don't agree. After working on all 3 I feel AWS is, by far, the worst experience for tech people. My perspective is that it's only doing great for execs and PowerPoint engineers.
In opposition with people who enjoy taking a product of the shelf and call it a day
But you are right: this is my opinion, not a fact
"More than half a million UniSuper fund members went a week with no access to their superannuation accounts after a “one-of-a-kind” Google Cloud “misconfiguration” led to the financial services provider’s private cloud account being deleted, Google and UniSuper have revealed."
https://cloud.google.com/blog/products/infrastructure/detail...
https://hacks.mozilla.org/2022/02/retrospective-and-technica...
I don't know if media or the readers are at fault. The article doesn't even make sense.
> More than half a million UniSuper fund members went a week with no access
If Google really caused such a huge loss there would be no joint statement. The buyer i.e. UniSuper would be trying to sue them. The fact that it is a joint statement implies the two parties are sharing the responsibility. Now complaining about UniSuper is boring and so spinning it on Google Cloud gets clicks.
“During the initial deployment of a Google Cloud VMware Engine (GCVE) Private Cloud for the customer using an internal tool, there was an inadvertent misconfiguration of the GCVE service by Google operators due to leaving a parameter blank. This had the unintended and then unknown consequence of defaulting the customer’s GCVE Private Cloud to a fixed term, with automatic deletion at the end of that period.”
https://cloud.google.com/blog/products/infrastructure/detail...
Are you saying that Google lied about being responsible for it? What would they possibly gain from that?
The original news article says Google deleted the account. As per your quote and official statement - no account has been deleted.
So that news article is completely false. Point proven.
Or did I get poe's lawed?
That reminds me in their interview process with me. So you are hinting they also use bots for hiring developers. Would explain everything.
A company that maintains that many TLDs is expected to have long term commitment to the domain related businesses but it turns out to be just a fleeting interest.
I used Google Photos on the iPhone for a while though, it worked fine you just have to open their app so it syncs.
These vendors underestimate the impact of having something so fundamental managed by a weird 3rd party. Route53 gives me a lot of confidence that I'm not going to be jerked around with domains and DNS. This factors heavily into my purchasing decisions.
Azure I can't use at all. Impossible to find the products I want in the UI.
They're a trash company, and anything you get from them, even when you pay for the storage, is at best accidentally delivered to you and they could roll over in their sleep at any moment and snuff it all out.
Unfortunately, they're also notoriously unreliable as a dumb pipe.
You're not wrong, but advertisers are a cancer on society that not only do not contribute any value but actively destroy the world around us. it's difficult to assign anything but deeply negative value to their needs and concerns.
Is this "hate" coming from the actual buyers though? Often the 1s commenting are the actual "users" just not the 1 that's paying the bill.
(that said, if the discounting came from another division say ads, then it could be buried... no idea if Google is doing this...)
Smaller cloud providers cannot (and do not want to) afford the costs of constant product churn. So you get a smoother, long term relationship with a smaller company that's more likely aligned with your goals.
Disclosure: I work for a European second tier cloud provider.
It doesn't help that the platform has stagnated and customers are afraid of committing due to loss of features. In comparison AWS doesn't remove features for customers or always provide alternative ways to migrate to. SimpleDb is the prime example here.
1 - https://ashishb.net/tech/how-to-deploy-side-projects-as-web-services-for-free/
2 - https://cloud.google.com/run/docs/configuring/services/gpuI also found GCP's developer tools and docs to be quite solid, better than AWS. Example: It's nice that they provide Terraform snippets for most of their resources.
> "had to migrate my domain after Google decided to shut down Google Domains decided to shut down."
In my experience GCP's core services are very stable: I had a site running on free tier App Engine for over 10 years without any supervision.
However it is clear that many GCP products are run by skeleton crews and will not improve. Documentation is also lacking sometimes.
Dataform for example is conceptually a great tool, but hampered by really basic UI bugs.
I found Datastream (change data capture tool) impossible to use. You would think that shoveling data between 2 GCP products (Postgres and BigQuery) would be easy, but I spend a week fiddling with obscure network settings before giving up.
I agree.
> In my experience GCP's core services are very stable: I had a site running on free tier App Engine for over 10 years without any supervision.
I won't be surprised that Google App Engine is already in maintenance mode.
> In my experience GCP's core services are very stable
Would you call Google Domains a core service or not? Would you call Container Registry a core service or not?
A cloud load balancer is $20/month before you even handle traffic.
I think they are introducing a $1.50 charge for every uptime check, when they were initially free.
So I see the myriad of services offered by GCP, I pick: https://console.cloud.google.com/products/solutions/details/...
Dynamic web application with Python and JavaScript. Okay, I've built these things before, let's see the Google way.
Nice, there is a diagram, there's Firebase, there's Django, there's PostgreSQL, something called cloud storage. A bit of an overkill, but let's roll with it.
Okay, let's click Deploy.
This should give us some sort of ready to use stub, placeholder, template right?
Wrong.
Resources tab shows 65 actions/resources created. All nice green checkmarks, there is IAM, there Firebase, there is Cloud Storage, Secret Manager, and everything else under the sun.
65 green checkmarks - that is good right?
However the app itself is not ready to be shown to the world!
Apparently there is something missing in Firebase config (remember this is the default deploy for a new user):
Google helpfully informs me
Why am I seeing this?
There are a few potential reasons:
You haven't deployed an app yet.
You may have deployed an empty directory.
This is a custom domain, but we haven't finished setting it up yet.
How can I deploy my first app?
Refer to our hosting documentation to get started.
So I go hosting documentation link and that is just generic: https://firebase.google.com/docs/hosting/Meanwhile all this nice setup is costing about $2.40 every 24 hours.
The issue isn't the complexity of the solution, or the lack or over abundance of documentation.
The issue is that their sample "Hello World" app is not ready.
I should not need to go through stacks of extra documentation to find out what is wrong when trying a sample product of some complexity.
Why should I be forced to fight abstraction leaks immediately when starting to use GCP?
GCP is fairly reliable and has a great developer experience. I wish more AWS folks used GCP to make AWS a better developer experience.
- don't use Firebase
- don't use GKE
- use Google Cloud Run for such simple setups1GBps internet connection
12 vCores CPU
24 GB RAM
640 GB NVMe SSD
Unlimited outbound data.
Cut backs have finally forced AWS to sunset services, but they just hard refused for many, many years. People like using it because the workflows evolve, but AWS will not force migrations on you, sometimes to your own detriment.
When you first build an app, everything is fresh because developers haven't had to hamfistedly shove assumption breaking models and patterns into their program yet.
Cloud customers want to evolve to the latest tech, but redoing 20 years of the company for no business reason makes programmers happy but executives nervous.
Sadly, that seems to not be the case anymore, and it’s a worrying development. AWS giving up on their customer obsession makes it easier for the other CSPs, who aren’t as customer friendly, to compete.
From the outside I dont perceive the promotion dynamics for engineers working on old services is that different at AWS than Google or Azure. Finance and engineering do conspire to kill off things despite customer annoyance, perhaps as they should.
There is also a constant churn of retiring EC2 instance types, security certs, old database versions, EMR versions, OS versions, security practices, cost optimizations, etc to suck up your time with minimal business value. This is not different fundamentally than on prem, you just have slightly less control and an outside party forcing your hand to do the right thing isnt purely a bad thing...
AWS is pretty good about giving you a grace period to migrate off and informal warnings if they strategically want you to move to a different service of theirs before stuff gets killed if you are looped in with a TAM (e.g Data Pipelines vs more-expensive Glue). They seem to have recently migrated to a strategy where they disable services for new customers but actually dont kill them completely off but keep them on life support.
The only product I know well in your list is pre-VPC ec2 instances, which (to be fair) are a terrible product : it is cross tenant (as in : you can impact other customers). Good riddance.
I think many AWS services are well designed : isolated software-only components. They build a lot on top of a very stable infrastructure (VPC / s3 / ec2 / IAM), which means supporting a service is really cheap : they are just a couple of containers running somewhere
Customer obsession (ugh) is just not in their DNA. I can tell firsthand they care more about what they want to do than what the customers want.
Maybe the upside is that Google is in exchange able to offer:
> Google Cloud - great engineering, good product.
I wonder if you guys have any example of those nicer primitives.
1 - https://ashishb.net/tech/how-to-deploy-side-projects-as-web-services-for-free/
2 - https://ashishb.net/programming/how-to-deploy-docker-images-on-microsoft-azure/
Even Google Cloud CLI is far more usable than AWS CLI.Basically as if you had S3 bucket policies for everything.
Though I'm sure you'll find someone saying the exact opposite is more useful
But it's still a rather nasty environment to handle, as is all the big clowns. There's lock-in, confusing products, lots of general weirdness. Unless the corporation I'm taking control over has exercised discipline and restraint and stuck to a rig with simple EC2 instances every project makes me hate them more.
As far as I can tell the way to go if you enjoy this kind of operating environment is to buy on-prem OpenShift. The guys I've met that run that seem to think it's the lesser evil.
The URLs might be mentioned in many different places. Why break URLs just to make a "better product"? Why couldn't the new product keep old URLs working?
If I recall correctly they do have concept of users and then user gets SSH key and you can't just put SSH key on instance out of the box as on any other VPS...
Where might one go?
Most should just own their infrastructure, or use a more simple hosting service. Most companies could go very far with that.
Unless youf business is a global one with hundreds of millions of users in many jurisdictions, there is really no reason to go for cloud services. They tend to be much more expensive then the alternative, and have many ways to lock you in by making migration very expensive and time consuming.
Otw the cheaper operational cost would be to setup a few hetzner servers and manage your own infra via kubernetes or docker/ansible runbooks. But you should budget a few days each month for maintenance and general support, plus you'll need someone skilled in server maintenance to set it all up (becoming a rarish skill these days).
If on a ramen budget, you can set it up and let it rot until everything breaks, then migrate to EKS. :)
Unless there is a team of 20+ engineers, I cannot recommend Kubernetes to anyone. It is a great primitive that's too primitive for smaller teams.
When your needs are low, AWS and friends are very competitive: quicker deploy, no CAPEX, lower OPEX
If your needs are high, you should indeed build your stuff on top of instances
If your needs are higher, then rent rack space and build on top of baremetal
If your needs are even higher, then build your datacenter
As an example, I put my personal backups in the "cloud". Is 1€/mo for 100GB cheaper than using a VPS ? Hell yeah !
They are evil now
Probably everyone. It’s the best solution for work emails, docs, calendars, etc.
It's the least worst solution for "whole-workplace" systems, but most people who are saying "won’t use Google for anything cloud" probably self-host or use something like PurelyMail (https://purelymail.com/) or FastMail (https://www.fastmail.com/) for their own emails
Why Hotmail? Because if the name isn't enough indication it's because I've had it for well over 25 years at this point and I like Microsoft anyway.
In the last 4 compagnies I worked for (the multi-billions kind of compagnies), everybody uses workspace, there are no office 365
- Does Chrome keep nagging you for login and bookmark sync, when you use O365?
- Google’s way of handling shared inboxes is awful (Want an extra email? Create a …Google Group! Then assign members, tune the perms, etc.) How does it work in O365? Can I just create an email and assign 7 users on it?
Anyway: big corps disable Chrome sync; most people will use Edge in enterprise because it integrates seamlessly into M365 and supports multiple work profiles (e.g. privileged accounts, service accounts, etc.)
Shared mailboxes are built into Active Directory; most enterprises have automated ways to create those -- usually the big concern is managing removing members when they're not supposed to be members anymore, hence the centralized management. There are also M365 groups you can create yourself, but that's just a distribution list. And generally, Teams is the way to go for any kind of collaboration work now - shared mailboxes seem to be a bit of a relic, usually meant for external interfaces that require an email address.