Think about components you rely on for your service. How long would it take you to stand up or migrate to an alternative. Consider that you've also got all your other business to do too. You can't spent a year just spinning your wheels from a business perspective, while you're migrating stuff between services because your upstream provider decided to stop building something. You've still got to keep growing. If you're lucky, you've got staffing for meeting your business growth needs, but odds are that's barely true.
On top of having to migrate, what are your replacement's performance characteristics? Are you replacing it with your own solution instead, and if so how do you operate it, what happens under load, how do you ensure durability? etc. etc. lots and lots of questions and you've got scant 12 months to figure out what you're doing and how to get off it _on top of your existing business needs_.
This criticism has been brought up so many times, and yet routinely we still see GCP saying "but we promise to give you a whole year's notice!" as if that's a good thing.
(disclaimer: I work for another cloud provider)
Also, I'm guessing larger companies could push for certain longer deprecation policies as part of their contracts on certain features. I have no insights here, just assuming from what other people on this thread are saying.
(Googler, opinions are my own)
That’s because the company is basically designed like a synergistic portfolio where even money-losing businesses have a purpose in the big picture.
And that’s where Google fails. It’s very well known how ruthless Google can be at killing business that don’t produce tangible results. The Alphabet re-org clearly showcases that they are playing a game of optimizing the allocation of their assets. That mentality bleeds down.
Unfortunately, you can’t run a Cloud Business like that. To Google’s merit, it seems that they are not running their cloud unit with that mentality (I don’t think I have heard about GCP services that shut down). But it’s clear there’s a generalized feeling in the industry that Google can at any point become impatient with GCP, leaving many stranded.
For Google to be a distant third in the Cloud game must be pretty hard. This is something that plays to their strengths and yet they are hardly closing the gap.
The big difference is that the companies that are winning (Amazon and Microsoft) are willing to lose in some areas to win in others. They excel at that. Google on the other hand seems to have a hard time with that shit...
Case in point; AWS SimpleDB. SimpleDB hasn't been available on the AWS console for years (since 2015?) but is still accessible through the SDKs and API calls. They don't promote it or even update it (AFAIK) but it's still there and you can still use it. Amazing!
As long as they don't visibly break it, that provides a reputation that is hard to beat without something much more than one year notice as a binding commitment.
But Google has an absolutely dreadful image to drop products and features at the drop of a hat.
Take Microsoft as a counter example, which went through absolute crazy length to provide backward compatibility for their products.
Google just doesn't have that credibility on long term commitments to bank your entire enterprise on its products.
I think this is one of the reasons MS Teams has been so successful, even when there are better apps out there that provide all the same functionality and more.
But for whatever reason, when Bezos brags about how making failed products is a core part of the company culture because it shows you’re tajing risks, HN shrugs. When MS kills off billion dollar consumer bets after only a couple of years, HN just goes “lol, why would anyone have used Mixer”.
It is a clear double standard that seems to have happened since memes are self-reinforcing.
Architect at a F500 here.
It would take us easily 2 years to roll out a solution, get migrated to it, and have it implemented, tested, and signed off. Probably another year (or more) to work out all of the kinks or handle the stuff that wasn't in the initial build (e.g. phase 2 expansions, etc.).
There is a reason we do 5 year TCOs, and it's not just cuz of the depreciation schedules. Also the reason we lean to things with 5-, or 10-year maintenance cycles. 1-year notice is not enough, full-stop.
Not talking about rolling our own solution here either, this is COTS being deployed in a 99.999% environment in multiple countries.
A year is crazy short if your job is to architect an ideal solution, but insanely long if your job is to simply migrate your employer onto a roughly equivalent solution. If a cloud customer isn't continuously testing a migration they're naive.
General best practice is to have a current best setup using all the first-party services on cloud-provider #1 using all their hosted services, and a fallback on cp#2 that self-hosts the services from cp#1 and uses their built-in services where better. It's what you should already be doing for benchmarking and testing but for a fallback if needed.
And once you've got the fallback planned you're free to move the active service around, almost at a whim. Even for a fortune 50 with petabytes of data - if your data isn't already hosted everywhere you're just begging to be wiped out with a simple account problem.
So, the message is implicitly there.
I do love me a well-formed customer query.
Yeah, it's supposed to work. I get paid more it if does. But in exceptional circumstances, it won't. And in more exceptional circumstances your alerts will fail too.
As an admin what do you do with the 90% of your time that isn't actively fixing something if not planning for how to fix the next thing? We did this years before cloud meant anything other than prepare for floods.
Not every cloud customer has a dedicated admin team, some even don't have any dedicated developer teams. They simply wanted a website done, contracted someone and they uploaded some HTML to a cloud instance.
Sure, if you're a large company, it makes sense to have redundancy. If you're running a small company with some esoteric webshop to serve AFK customers, it makes less sense.
Ideally we keep stuff running, but I don't want to be the kind of person who just tells you that we've got it. You need to know your airbag might fail so that you take your seatbelt seriously.
this is a dumb point of view, that only cloud providers (and their employers) can advocate.
if i'm a company, being "on the cloud" doesn't automatically makes me money. my business makes me money. if every two years i have to waste a year (or even six months) re-architecting then "the cloud" is costing me people money on top of the infrastructure money.
Most enterprises won't do this, either, but it's not because of recurring rearchitecting costs.
Yeah. Do you think I disagree? It's not for everyone.
> this is a dumb point of view, that only cloud providers (and their employers) can advocate.
No, it's the truth. Stuff fails.
And if you think that this is the company's messaging you're totally wrong.
Like, "it's insane to grow legs just to live, if you can just crawl like a worm".
If you can't afford a recovery plan then what you can't actually afford is the service that needs the recovery plan that you can't afford to develop and test.
All costs, including of switching away if it fails, have to be considered as the sticker price.
As for running your own servers, that too can fail meaning you still need a migration strategy (even just to new hardware) and you need to be testing it constantly.
And no, the benefit of a cloud provider isn't that normal stuff is easy or cheap but that otherwise impossible stuff can be attempted.
That's what DR is for. We have a main bare metal site and a secondary site. Throw a couple of spare servers / switches / PDUs / Hard Drives / whatever in that space too.
Cloud options need to be better and more effective than that.
> And no, the benefit of a cloud provider isn't that normal stuff is easy or cheap but that otherwise impossible stuff can be attempted.
A virtual server is a virtual server. A container is a container. The only thing the cloud offers me is the ability to change my CapEx spends into OpEx spends. Otherwise I have to hope that the vendor won't do me dirty, and will leave me in a stable, workable place 3+ years from now.
The bare metal colo operations will. Long track record of stability at everywhere I've been. Barring act of god or otherwise unusual circumstances I know my tier 4 colo will be there next year, and the year after. Will GCP be around?
That protects you against localized outages but not design failures or systematic outages or incompatibilities in new versions of your stack.
And it takes time to keep your DR plan up to date, patch the VMs, etc, and test it. Almost like this migration plan I'm talking about.
> The only thing the cloud offers me is the ability to change my CapEx spends into OpEx spends.
Ehh, not really. You can setup load-balancer pools larger than your entire colo, or use a globe-spanning backbone to create datasets that auto-replicate worldwide. And which are usually much easier than setting these services up yourself, let alone building the multiple zones. If the cloud is just a big colo to you then you probably shouldn't use the cloud. It's frightfully expensive.
Most cloud customers are naive, as the stream of major enterprise breaches caused by S3 buckets without security settings that have been default for many years demonstrates.
You see, there's strength in the truth. It doesn't matter if drunk drivers shouldn't hit you, that's why you check both ways before crossing the street, and you'd be naive not to. (In this analogy, drunk drivers are outages...)
Or am I missing something?
true or a team is slowly migrating so one day true
> Google does not run on GCP.
Ive heard other googlers say "GCP runs on google" as a somewhat tongue-in-cheek reference to the internal architecture
That's not a given.
At least in the early AWS days, internal sites had special configurations.
Source: worked there.
But in recent years, they run entirely on AWS. They even have solutions architects to help them build things in a resilient way. They also spent years ripping out Oracle and replacing it with RDS MySQL, PostgreSQL and Aurora.
It is true that Amazon runs on AWS.
Source: worked there.
...then they go and buy more of some the most expensive office space in the world per-sqft.
Source: I interviewed there 3 times and every time left me with a dystopic impression of the company. To add insult to injury their recruiter only ballparked me only slightly above half of my then-TC.
How is that a negative? Seems like a more efficient way to operate a company.
> Seems like a more efficient way to operate a company.
I do actually agree with you - it's just a matter of framing the company's practices.
https://news.ycombinator.com/item?id=21258127
That's what I was getting at. There's no way AWS is going anywhere if the entire store is running on it.
The terms of use for GCP does say any product that is shut down will give at least a one-year notice before it's shut down[1]. For any given product within GCP that has been shut down the lead time has been greater than a year as far as I'm aware.
The fact that Google is calling out GCP separately on its earning calls is actually somewhat of a commitment to trying to grow that business. Very few products within Google are called out separately, so that was a fairly big change.
[1] https://cloud.google.com/terms/
> (d) Discontinuation of Services. Google will notify Customer at least 12 months before discontinuing any Service (or associated material functionality) unless Google replaces such discontinued Service or functionality with a materially similar Service or functionality.