It's interesting to compare Google's strategy with AWS's.
AWS SimpleDB has been a dead product for years now. Afaik, nobody is developing it, nobody is advertising it, and I believe it's not been launched in any new regions in ages. Even internally, when I worked there, it was not a product you should use for anything.
Yet it's still supported. Customers are still using it. Somewhere, there is a team in AWS keeping the lights on.
Because AWS knows that customer trust is more valuable than whatever it costs to keep that product alive.
Google’s CI/CD and internal monorepo ecosystem building against latest have a high cost to maintain legacy code. You can’t just let something rot with minimal maitenance at google.
While fine for a customer tech ecosystem facing security threats, it’s really not ideal for enterprise offerings.
That's a weird take. Is that your first-hand experience? My personal experience was that google3 code can be on autopilot for decades and nobody will break it, because the testing system keeps people from breaking it, and the large-scale changes infrastructure won't break any tests.
There's only one version of each library allowed for essentially the whole company, including internal libraries. So if someone wants to upgrade it they may need to update the old codebase's call sites and get those changes approved.
My impression is that the hassle and pain of doing this is often why languishing projects are deprecated. I can't tell you how many times I've read TotT issues or seen threads on eng-misc or elsewhere that would either talking about some new test system and how it handles crufty codebases, or how one should check for dependencies, or what might happen with some internal app that lost its sponsor/maintainer because they either transferred teams or left the company. For a while, even somewhat important things like Dory were un-maintained (after Moh Musa left Google), and lots of times it's happened that reorgs caused deprecations.
Seeing how those sorts of things play out in actuality, it doesn't surprise me that unpopular or unprofitable products are killed rather than kept on life support. Lots of times, the people who would have to fight for them don't have the political will (or maybe even complete history of the product) to commit to staff allocation to keep them alive in the face of the alternative: chasing the next 10x dream.
The weight of managing depot wide upgrades are definitely not a factor in turning down customer facing services. In 10+ years doing low level libraries and infrastructure no one ever used my teams efforts as a reason to sunset an offering.
Although depot migrations are tedious, the burden of doing them for all but a subset of mothballed systems would not significantly changed my life.
Also, generally speaking, because the model is "library owner makes the LSCs," library consumers are happy to accept small/reasonable changes in API usage.
Off the top of my head I can only think of one time when an internal library deprecation caused a huge ruckus: some front-end framework was deprecated which led to a huge push to rewrite many of Google's internal websites.
When I left even BigTable, MapReduce and other services are still supported even though they have been deprecated and their replacements (Spanner, Flume) had been GA for more than a decade. (Although their API calls may just go through a translation layer, not sure.)
No the real reason is Google's internal systems do not depend at all on these services. Therefore no one values the maintenance effort required to keep the lights on.
If anything the CI/CD infra backing Google development keeps these services running longer than they would otherwise.
So the same is effectively true at Amazon? If a service in a version set isn't actively maintained then it'll eventually be unable to merge from live, and that means its dead code. Version sets do allow for services to exist in a degraded state (ex. can upgrade some dependencies, but not others) but without consistent maintenance services will fall off a cliff.
if you're referring to Z builds in version sets, where you build a specific package but not it's consumers, those have not been allowed for several years now.
if you just mean "you don't have to merge everything from live, you can just merge select packages, or build specific updates in manually" then yes that is true, but you won't have a fun time doing it for very long.
i mean the latter (have z builds been allowed in the past decade), and i agree that it’s not fun over the long term but possible and in a lot cases sustainable.
You think about product lifecycles differently when you have a monorepo. Breaking change in a library? Just fix all the breaks in the same commit. Dependency hell? Not a problem when you have an ancient version forked in your monorepo. These are real problems customers face when they're not in your ecosystem, and Google doesn't always realize that. It was this same for App Engine. It wasn't a model 95% of customers wanted, but for Google spinning up services internally, it was great.
AWS definitely deprecates features, but it's not near as common as Google killing products. Aside from that, AWS gives _plenty_ of notice, and good alternatives.
As far as I know, AWS has never shut down a service. They've stopped offering some services in new accounts, but if you already had it you still do (like SimpleDB).
Microsoft and Oracle are both well known for extremely long term support and creating easy migration paths.
I would only ever use GCP as an offsite backup or use some of their AI tools as part of toolchain that either operates on a copy of the data or lands its output on another cloud.
In other words I would always make sure to design in a way where I could exit Google in 30 days or less.
They shut down ec2 classic, PV instances too. Not recent, but it’s something. Nothing compared to the thousands of products google killed that tons of people used. I personally use two Google products - gmail and maps. That’s it. I don’t trust them to do ANYTHING else.
That's a fair callout. But also they provided a one year migration timeline, let you keep using it if you already were, and gave you tools to easily migrate what you had left.
So I'd say if anything they increased trust by showing how to do it right.
It is very much a product that if it were discontinued without an exit plan and working with large customers there would have been a world of hurt, a lot of legacy customers didn’t move off until they were forced into it.
I assume you're talking about EC2 classic? If so, I'm aware, I was one of those legacy customers who didn't move until forced. :)
But the point is, they hired people like you just to help people like me move to the newer better product that replaced all the functionality and then some. We didn't have to suddenly figure out a way to replace core functionality.
Curious which services under GCP have been shut down? I get that Google killed Reader and that GCP users used Google Domains, but for the time-being GCP has felt safe.
Cloud IoT comes to mind, and the linked thread claims cloud domains is on the chopping block. However, most Google cloud services have a Ship of Theseus thing going on, where they'll deprecate most features of a particular service without deprecating the service name as a whole. Nothing that was written stayed working without constant maintenance, no matter how trivial or important the features (e.g. spending limits in AppEngine).
Google Domains, Stadia, Firestore, Chatbase, IOT Core, Zync render, Cloud print, Jump, Cloud Messaging, Prediction API, Cloud Connect, and the video rendering service. But more importantly, Google has a reputation for shutting things down in general:
From what I've heard, the biggest selling point of GCP is its simplicity and easier development experience. Other than that, it's mostly inferior to AWS or even MS Azure.
AWS is designed to be very flexible and configurable (example: look at IAM). The tradeof is the complexity and amount of work required to set up even the most frequently used services (such as ECS Fargate or Lambda).
That being said, if somebody is looking for a simple, developer-first experience, and wants to use AWS (and have all of its power/flexibility), have a look at https://stacktape.com (I'm a founder).
Actually particularly shocking that they've sold Google Domains to SquareSpace. I couldn't think of a less aligned company. They deal with novice end users who want to make web sites with minimum technical knowledge but give them premium support. Meanwhile Google Cloud's ideal customers (generally) are engineering heavy, people who want to automate everything with APIs and manage seamless automated operations, but are happy with support from a python script.
The best I can think is that maybe Google did that analysis and found that all the customers for Google Domains were high maintenance novice users so it made sense to sell it off to a business designed to support them?
I think the answer to all of this is that Google did not see Google Domains as part of the GCP umbrella. Unlike AWS Route 53, it had its on website separate from GCP. What that website did do was sell and bill Google Workspace.
SquareSpace is a reseller of Google Workspace (for people who use SquareSpace for their company homepage), and will not only be taking over the domains, but for those who bought Workspace within Domains, they will become their new reseller.
Google has had a big problem for over a decade with having multiple overlapping products, leading to wasted effort and customer confusion. It also leads to a bunch of extra work when one product is rolled into another or shut down.
It's unclear to me why they didn't migrate everyone over to GCP Cloud Domains. I'm also not sure that most customers really care if they're using Google Domains vs another registrar vs GCP Cloud Domains.
> It's unclear to me why they didn't migrate everyone over to GCP Cloud Domains.
Doesn't that require a GCP account? There are a lot of minimally-technical users who would be very confused going into a big cloud console, dealing with projects and IAM and all that stuff, just to renew their domain. They will have no trouble dealing with Squarespace.
No effect for them as far as Workspace goes. If they domain was bought from Domains, it will move to Squarespace, but they will only bill the renewals not the Workspace.
I really wish they had spun off Cloud as an alphabet company with Kurian at the head (he is CEO of Google Cloud, which isn't a CEO because Sundar is his boss), and transferred all the Cloud employees to the spinoff.
(I'm a xoogler, worked in cloud and launched actual products in it, and I strongly prefer AWS. I still don't think Cloud- specifically, GCE and GCS- will go away but I do expect them to continue trimming all the "barely profitable" services)
I'm a Cloud xoogler (2015-2023), too, and I'm not sure whether that would have made things easier or harder. There were quite a few "shiny object" solutions Cloud commercialized from other parts of Google/Alphabet over the years, and regardless of all the organizational duplication, fiefdoms and chaos that accompanied having three Cloud CEOs in six years, I think the commercial interest via Google's "innovation story" and One Google pitches created a lot of value. As a third place laggard until TK was hired, Google Cloud didn't really have much of interest to offer beyond the legacy internal data products (BigTable, BQ, Spanner) and GKE/Anthos, so having things like Google Maps, several Verily products, a few things that emerged from Brain/RMI, Google Health, etc made a real difference.
That said, I think Cloud has matured enough that it would now be a good time to consider spinning it off, especially as the regulatory environment around Search & Ads is heating up again in multiple countries. It would be much better in the long term to have Cloud separate; not as good as if Search & Ads were separate but I don't think that's really viable without enormous costs and much difficulty.
Technical Infrastructure- historically, a division inside google which was responsible for the software and hardware infrastructure that runs google. Search, ads, cloud, youtube, etc all ran (run?) on top of TI software and hardware. TI existed before google cloud did and was (is) basically its own cloud with a service API, with borg, google clusters, networking, storage, databases, etc. Historically it was run by Urs (https://en.wikipedia.org/wiki/Urs_H%C3%B6lzle). At some point, TI and cloud got mixed up together to get more TI people to work on Cloud products. Many cloud products represent either TI services or variations/ports/reimplementations of TI services.
TI was absolutely enormous and it was key to google's early and continued scaling of compute and storage. I don't know if it still exists within Google or got renamed, or what.
Is there any official guidance for how a company/product can migrate away from Firebase and onto self-hosted infrastructure - or something akin to “decomposing” a Firebase system so it can be incrementally-migrated to self-hosting? I know open-source reimpls of Firebase exist, but those aren’t official - and they represent mirgration risks. (At least Microsoft put the “Migrate to SQL Server…” wizard in MS Access - why won’t Google do the same?)
I’m asking, because I am genuinely interested in using Firebase for prototyping, RAD, and whatnot - but I don’t want to put all my eggs into one basket, especially not a basket that I can’t defenestrate.
The timeline of Google’s domain registration business, according to Wikipedia:
* 2005: Google became a domain name registrar.
* 2015: Google Domains was publicly launched under a beta test mode.
* March 2022: Google announced that Google Domains was officially out of beta.
* June 2023: Squarespace concluded an agreement to purchase the Google Domains business.
Exiting beta in 2022 after seven years suggests Google planned to get serious about Google Domains. What happened between 2022 and 2023 that made them decide to kill it? I guess when a hobby becomes a business, the bar to keep it going is a lot higher.
If that turns out to be true that’s extremely short sighted. The whole point of the beta designation is to indicate “this might go away” to customers. They will lose more from burning their customers than they would have gained. Unlike other google products, cloud is something that 1) they have paying customers, 2) it is competitive, 3) Google is not the market leader. So they don’t have any room to be fucking around with customers.
I'm not disagreeing, but so far I have never seen evidence that Google cares about any of its customers. And they don't really have to as long as they're the incumbent market leader in a ridiculously profitable industry (advertising).
Eventually Google Cloud will die and Azure will buy it for a song. It may take 10 years but it's going to happen.
Google really annoyed early adopters of Google Apps (now workspace) with the legacy to paid migration, then oh no you don't have to pay here's 300 free user licences nonsense.
I can totally see how CIOs and other tech savvy leaders in business really look at anything they use Google related and wonder to themselves if it might be wise to look at alternatives.
I agree with lot of comments in that Twitter thread.
More than the shutdown itself, the lack of any communications from Google has been frustrating. It gives the sense that this is a complete shitshow internally. Nobody seems to have an official answer on the fate of Cloud Domains, which is marketed as a separate product but runs on the same infrastructure (Gergely’s thread says insiders have been told that it is also going away).
Interesting in that thread that they mention that Google Cloud’s DNS service uses Google Domains NS records, and they haven’t said whether that is going away or not. I only use Google Cloud for personal stuff, but I know that I would cry if AWS suddenly said “there’s no longer a way to get public DNS names for your services through our tooling” at work.
Cloud DNS is just nameservers. Google Domains is a registrar. Two very different things. There is no reason for Cloud DNS to be affected by Domains going away.
Google is completely rudderless. Sundar has completely trashed Google's once impeccable reputation and killed all innovation. I really don't understand why they have't fired him.
It is quite fascinating what a reputation bonfire they've held over the last 10 years. I keep wondering when their reckoning will come but they really do seem to be oblivious to it even while they struggle to generate meaningful revenue outside of their ad business.
It's kind of shocking to me but I was internally debating whether I should spend my time learning how to develop on top of Bard or OpenAI and the whole thought process was around unreliability of Google to support the platform. Just think for a second about that, the 20-year well established software giant vs startup from 2 years ago and all the negative was on Google's side in that equation.
Google was doomed from the start. Their focus on engineering first and customers second always held them back. The only reason Google has been successful is they get so much funding from Ads that everything else can float. Every single product Google shipped was supported by the never dry ads-fountain.
maybe. initially it seemed like they can pull off the impossible and just make it work for everyone. (providing adequate self-service tools, nice undo/redo features, keeping scope very focused, working a lot of behind the scenes magic.)
of course then complexity hit, and the paranoia of fake ad impressions ate the whole company.
Google has had a solid reputation for canning services people use and like, and disabling API access to things, ever since I can remember. Perhaps pre-IPO they had the reputation you suggest. Memory fades..
This was a hell of a way for me to learn that my Google Domain account will be transitioned to SquareSpace. An email would've been nice (unless I missed it).
Gruber spotted this delightful bit of surrealism, in case you’re using Gmail.
> Turns out that even though I used an @gmail.com address to register the domain, every single email from Google Domains was being flagged as spam. So Google’s own email service considers all emails from Google’s own domain name service to be spam.
I didn't even know they sold Google Domains. How does this kind of transfer work if I'm not a Square Space customer? Do I get a free transfer out of I don't want to use them?
I imagine it will initially be migrated to SquareSpace hosted services for your interaction that you then use your Google account to oauth into, so a pretty seamless transfer from the end-user perspective.
Likely the total transition will take over a year to complete. You will probably get a notification a few months after the transfer of control that the registrar name is changing and you dont need to do anything but make sure your contact info is up to date. At some point, probably 2-3 years down the line, domains.google will cease redirecting to SquareSpace domains.
I'm a Workspace customer, hosting my family's domain for mail. Some of us use sheets or docs or drive.
Where do I flee to from here? Protonmail? Office365?
I'm willing to spend $5-$10/mo per user. Apps would be nice but mail is critical. I'll miss Google's spam filtering but so be it.
I know Workspace isn't dead yet but I'm not going to wait until it is. I'm done. My DNS has always been somewhere else which will make this a lot easier.
I can totally imagine a spinoff either to Oracle or IBM. Possibly Cisco as an outlier.
BTW I have to deal with Google Cloud as a “partner” and they’re a major pain in the ass - everything we do is mandated as custom, we have to come to them, etc - compared with their competitors who actually feel like partners. We’re always one Google reorg away from throwing away our efforts to be replaced with another goat rodeo.
I think Google is good putting ads on front of people and get money by advertisers, but awful by selling stuff directly to consumers. So in general the brand image is very damaged for people who pay for things.
The opposite of Apple who people who pays for things is his cash cow and they take care much more on that.
And what get Google's brand with only being good with ads? Love from advertisers and skepticism by consumers.
One of my life lessons: Never do business with Google.
It's served me well. I've seen so many businesses torched to the ground by doing business with Google.
That's not an indictment of Google. There are things specific companies are good for and bad for. Google is bad at any sort of B2B, partnerships, or similar.
The cloud compute market is probably 1000x? bigger than the domain market right now and will continue to widen that gap since it is on a different growth curve. It's certainly possible that Google or AWS will be forced to divest their cloud business into a separate entity or sell it by shareholders or regulators, but it's not going anywhere and it might work a lot better with more focused leadership.
I work for a Fortune 100 company. When we were deciding which cloud platform to settle on years ago, Google Cloud Platform was thrown out first because of this very concern. I would not be shocked to hear tomorrow that they are shutting it down. This is Google. I wouldn't even be surprised that Google Maps of Google Docs are being shut down. Search is the only one that would surprise me.
Google will spin out YouTube, Maps, Chrome and Gmail into a separate company.
It will shut down Google Cloud.
All that will remain is Google search/ads.
The AI opportunity has already been fumbled and will soon be completely dropped.
And Sundar Pichai, who has destroyed everything except googles advertising cash firehose, will stay there and continue to run the empty shell of googles potential.
I moved all of my domains to Cloudflare Domains last night. It was pretty easy, and I believe I fit everything in the free tier. One less thing to be reliant on Google for, I guess.
Google just isn't a serious services vendor. They're infected by some MBA virus where they attended a class in biz school that said you focus on your core competency and divest of everything non-core. Of course this is often nonsense because it turns out some of the non-core things were required in order to have the core products.
Reminds me of an episode long ago when I worked in hardware design: someone in biz planning completed their MBA and made a spreadsheet ranking all our SKUs by profitability. They recommended shit-canning several products, including the custom cables required to plug in our most profitable product.
I was referring to companies making decisions on which cloud to go with.
If a board member is google hostile and asks questions about it all the time, there is pressure to switch away from GCP just to get the board to stop asking the question.
Similar things were seen when companies all announced blockchain strategies so they could report to the board that they’re on top of it.
> Similar things were seen when companies all announced blockchain strategies so they could report to the board that they’re on top of it.
It's not just board pressure that led people go for Blockchain crap - it was the craze to find the next Bitcoin-style unicorn. Blockchain everything and hope it's your tokens which explode 10.000x in value.
Did you miss that Google Cloud Domains is going down with this sale? It's not about drawing parallels, they're literally shutting down a core part of GCP.
> Just to be clear: this is not just the consumer product (with no Google Cloud connection) going away. Google Cloud Domains is deprecated and discontinued as part of this sale / shutdown.
> Google told employees internally: but not it’s customers. Yet.
Sure, he's had good scoops from time to time. I've also seen him claim stuff that never panned out.
The reason I'm waiting is that if/when Google confirms Cloud DNS (the nameserver functionality) is going away I can have a more productive discussion with my google cloud rep once things are announced officially.
AWS SimpleDB has been a dead product for years now. Afaik, nobody is developing it, nobody is advertising it, and I believe it's not been launched in any new regions in ages. Even internally, when I worked there, it was not a product you should use for anything.
Yet it's still supported. Customers are still using it. Somewhere, there is a team in AWS keeping the lights on.
Because AWS knows that customer trust is more valuable than whatever it costs to keep that product alive.
Google does not understand that.