The stability of your production environment depends directly on the stability of your vendors. And right now, one of the biggest vendors in tech looks deeply unstable.
A recent discussion on Hacker News captured this perfectly, asking "When did Google get so weird?" The author points to declining search quality, a graveyard of killed products, and a general loss of a coherent vision. For CTOs and architects, this isn't just tech commentary. It's a five-alarm fire drill for assessing Google platform risk. When your foundational provider acts erratically, every API call, every deployment target, and every SDK you rely on becomes a potential liability.
This isn't about whether Google builds good technology. They do. It's about whether they can be trusted as a stable, long-term platform partner. And the evidence suggests that for many of their products, the answer is a resounding no. That has massive implications for how we build software.
The Dependency Audit You Didn't Know You Needed
Most teams have a tangled web of Google dependencies they don't even track. You might think your exposure is limited to a few services on Google Cloud Platform, but the roots go much deeper. Your actual surface area of Google platform risk is probably ten times larger than you think. It's not just about GCP.
Think about the full picture. There's your core infrastructure, the obvious part. You might be running containers on GKE, using Cloud Functions for serverless workloads, or storing data in Firestore. But then there's authentication. Millions of apps use Firebase Auth or Sign in with Google. What's the cost to your team if they suddenly deprecate a key authentication API or change the data access scopes in a way that breaks your user profiles?
Then you have the constellation of APIs. The Google Maps API famously jacked up its prices years ago, forcing a reckoning for thousands of businesses. But what about the Google Drive or Sheets APIs that your internal tools depend on? Or the new AI APIs, like Gemini, which are being integrated into core business logic as we speak? These are often silent dependencies, humming along in the background until they're suddenly not.
It even extends to the developer tooling we use every day. Android, Flutter, Angular, and Go are all open source, but Google's stewardship and corporate investment dictate their roadmaps. We all remember the painful migration from AngularJS to Angular 2+. That was a direct result of a strategic shift inside Google. And finally, there's the most critical dependency for many businesses: SEO and Google Ads. A single, opaque algorithm update can destroy years of work and tank your lead flow overnight. This isn't a code-level dependency, but it's a profound platform risk all the same.
From 'Don't Be Evil' to 'Don't Be Reliable'
Google's internal chaos is manifesting as external instability. For engineering teams, this translates into unplanned work, emergency migrations, and a constant, low-grade anxiety about which service will get the axe next. The "weirdness" has become a direct tax on our productivity.
The Deprecation Treadmill
The Google Graveyard is a long-running joke, but it has very real engineering costs. This isn't just about losing a beloved RSS reader. It's about being forced onto a treadmill of migrations that serve Google's internal priorities, not your product roadmap.
Take the forced march from Google Cloud Messaging (GCM) to Firebase Cloud Messaging (FCM). It was a necessary move for Google, but for countless mobile and backend teams, it represented weeks of non-trivial engineering effort. You had to update server-side code, release new versions of your mobile apps, and hope your users updated in time. All of that was time you couldn't spend building features your customers were asking for.
More recently, the uncertainty and breaking changes around Manifest V3 for Chrome Extensions threw an entire ecosystem into disarray. Many popular developer tools and ad blockers had to be completely rewritten, and some features were made impossible. When your platform actively breaks your product, it stops being a platform and starts being a liability.
The AI Gold Rush and Unstable APIs
Nowhere is this instability more apparent than in the current AI gold rush. Google is scrambling to compete with OpenAI, and it's launching, rebranding, and deprecating AI products and APIs at a dizzying pace. We've seen PaLM, LaMDA, Bard, Duet AI, and now Gemini, with a dizzying array of sub-models and APIs under the Vertex AI umbrella.
Building on these APIs is like building on shifting sand. You might integrate with the gemini-1.5-pro-latest model today, only for it to be deprecated or radically repriced in six months in favor of a completely different API endpoint under a new product name. The risk is that the change isn't just a simple string replacement.
Consider this pseudo-code for what a migration could look like:
// What your code might look like today
import { GoogleGenerativeAI } from "@google/generative-ai";
const genAI = new GoogleGenerativeAI(API_KEY);
const model = genAI.getGenerativeModel({ model: "gemini-1.5-pro-latest" });
const result = await model.generateContent(prompt);
// What you might have to rewrite in 9 months
import { VertexAI } from '@google-cloud/vertexai';
const vertex_ai = new VertexAI({project: 'my-project', location: 'us-central1'});
const generativeModel = vertex_ai.getGenerativeModel({
model: 'gemini-2.0-flash-001',
});
const resp = await generativeModel.generateContent({contents: [{role: 'user', parts: [{text: prompt}]}]});
Notice the differences. The SDK is different. The authentication model might change from a simple API key to a full GCP service account. The data structure for the prompt ({contents: [...]}) is completely new. This isn't a refactor. it's a rewrite. This is the hidden cost of adopting bleeding-edge services from an unstable provider.
Architecting for Vendor Volatility
So what do we do? We can't just stop using Google. But we can and should start architecting our systems to be resilient to their volatility. This means treating vendor risk as a first-class architectural concern, just like performance, security, and scalability.
The Abstraction Layer Is Your Best Friend
Rule one is to never let vendor-specific SDKs infect your entire codebase. Your business logic should not know it's talking to Firebase. It should be talking to an authentication service that you control.
Create your own internal interfaces for common services. For example, instead of calling Firebase Auth methods directly from 50 different places in your app, define an IAuthService interface with methods like signIn(email, password) and sendPasswordReset(email). The concrete implementation, FirebaseEmailPasswordAuthService, is then hidden behind this interface.
If Google ever decides to kill Firebase Auth or change it in a way you can't tolerate, you don't have to refactor your entire application. You just write a new Auth0AuthService or SelfHostedPassportAuthService that implements the same interface. This adds some upfront development cost, but it massively reduces the cost and risk of a future migration. It's a strategic investment in your own freedom.
Favor Open Standards and Portability
When you have a choice, favor services built on open standards over proprietary, black-box solutions. Instead of a hyper-specific, proprietary database like Google Cloud Spanner, consider using a managed PostgreSQL service like Google Cloud SQL. PostgreSQL is an open standard. Migrating your data from Cloud SQL to Amazon RDS or a self-hosted instance is a well-understood, achievable task.
Use infrastructure-as-code tools like Terraform or OpenTofu. Defining your infrastructure declaratively decouples you from the specific cloud console's UI and CLI. While not a magic bullet, a well-written Terraform configuration is far easier to adapt for another cloud provider (like AWS or Azure) than clicking through a web UI. This isn't about the fantasy of active-active multi-cloud. It's about maintaining portability so you always have options.
Recalculate the Build vs. Buy Equation
The classic "build vs. buy" decision for any piece of technology always involves a risk calculation. Google's current unpredictability fundamentally changes the variables in that equation.
The convenience of "buying" (using a managed service) is now weighed against a much higher platform risk. A service that looked like a clear "buy" three years ago might now be a candidate for "build" or, more likely, "buy from a more focused vendor."
For example, if you need transactional email, do you use a generic cloud provider's offering that is a tiny part of their portfolio, or do you partner with a service like our own MailStack, whose entire business depends on that one service being excellent and reliable? The focused vendor is often the more stable choice because their survival depends on it.
What This Means for Your Team
This isn't just a theoretical discussion. Google platform risk has immediate, practical implications for how you should operate.
- Audit your Google dependencies now. Go beyond GCP. Map out every API, SDK, authentication method, and business-level dependency (like SEO) you have. You can't manage a risk you haven't measured.
- Quantify the cost of churn. The next time a Google service you use is deprecated, track the exact engineering hours required for the migration. This turns a vague annoyance into a hard dollar figure you can use to justify architectural decisions.
- Prioritize abstraction over tight integration. Every raw, vendor-specific SDK call in your codebase is a piece of technical debt you might have to pay down on their schedule, not yours. Isolate vendor code behind your own interfaces.
- Treat vendor stability as a first-class feature. When choosing a new technology, ask "How likely is this company to support this exact product, with this pricing, in five years?" Right now, for many Google products, the answer is far less certain than it used to be.
Google's identity crisis has created a new, measurable category of risk for every engineering team that depends on them. Ignoring it is no longer an option. The most responsible thing an engineering leader can do today is to assume this volatility is the new normal and start building a more resilient architecture. Your roadmap, and maybe your business, depends on it.
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.