Anyone who thinks Google will get out of Cloud (already more than an $8 billion business [1]), as if it were comparable to Reader (which made $0, AFAIK), isn't looking at the economic realities here.
I repeat: Google Cloud has more than $8 billion in annual revenue. And AWS proves that clouds are a profitable business.
I just can't understand how anyone can suggest with a straight face that Google might shut it down.
[1] https://www.sdxcentral.com/articles/news/google-cloud-annual...
Corporate leaders set stretch goals all the time -- that's part of their job. Not meeting them just means certain VP's might not get their full million-dollar bonuses -- not that a billions-dollar business will shutter and lay off 1000's of people.
It is all their own fault though I think: They worked long and hard to build that reputation.
https://www.lastweekinaws.com/blog/google-cloud-is-probably-...
Commercial cloud revenue, which includes Microsoft Office 365 Commercial, Microsoft Azure, the commercial portion of LinkedIn, Microsoft Dynamics 365, and other commercial cloud properties, increased 43% to $38.1 billion.
The first step of a major cloud migration is often a combination of hybrid solutions and lift and shifts.
Revenue is inconsequential. What is there profit? Cloud is profitable for AWS and MS. We don’t know what the margins are for GCP.
And in what universe is revenue inconsequential? Profit comes whenever you want to stop investing in growing. There is zero reason to believe that Google will be unable to turn a profit off GCP whenever it decides to. Particularly given that it was building datacenters for Search before AWS even existed.
GCP and Google are completely different. Nothing except a few inconsequential internal Google apps run on GCP.
Building servers and knowing how to address the needs of the enterprise are completely orthogonal.
Sorry the only citation I have is a podcast.
> Seems like it would be risky for companies to switch to Google Cloud because it might end up in the graveyard.
Yeah, there's definitely that risk, and in one of those cases, I disagreed with the move because of it.
That said, depending on what you're doing, GCP's key-value store (BigTable) and analytical DB (BigQuery) struck me as technically more sound than the AWS versions (DynamoDB, Redshift/Athena). As an ecosystem, AWS was far superior, there are more offerings, and they tend to have more features. It's just that they're most likely a managed version of an open-source project.
One place moved specifically because of BigTable. They were on HBase (and not happy with it), so it was the least painful migration option.
The structure for VM use and their Live Migrate capability for upgrading the hardware underneath with no downtime has been excellent on my more long-lived servers.
My biggest wish is some equivalent of Aurora for PostgreSQL.
I am however fairly pessimistic about their chances. Especially considering the person at the helm is ex-Oracle VP.
I also don’t understand their alternatives... do they want AWS to own the cloud market? They’ve operated Android as the bulwark against Apple, why not view GCP in a similar light?
Android has a lot more synergies with their consumer ads business. It's the extreme version of writing your own browser.
GCP is completely different; it's in the B2B space, and it's a pretty standard business relationship between businesses and a supplier. Being customer-focused and business-focused isn't in Google's DNA.
On GKE, you don't need to define node-pools if you tick enable node-autoprovisioning. This is effectively an EKS fargate profile without any of the limitations (discrete node size, inability to mount volumes etc)
On GKE there's no need for bastion hosts, you can connect to private nodes automatically by tunneling through identity-aware-proxy
On GKE, there's no faffing about with aws-auth-configmap, nodes automatically join the cluster
On GKE, you can use regional persistent disks if you need to store state rather than single zone EBS
On GKE, you can use a single static ip for your nginx-ingress load balancer without needing to faff about with AWS global accelerator (which in any case gives you multiple ips)
On GKE, managed node pools are automatically repaired and upgraded with the choice of google's OS or ubuntu unlike Amazon Linux which is currently the only choice for EKS' managed node pools. GKE can automatically use spot instances unlike the farce on AWS with a 3rd party (spotinst) charging a premium for the same functionality
On GKE, managed istio is ticking a box versus a self-install on EKS
On GKE you need to worry much less about ip exhaustion as they use alias ips vs dedicated ENIs for EKS
Associating IAMs with kuberenetes service accounts is much easier with GKE workload identity than with EKS' oidc webhook
GKE has several features which EKS doesn't (calico, vertical pod autoscaling, binary authorisation, export of cluster data to bigquery)
But balloons to deliver internet in rural areas? They're the leader in that space.
It's sort of a Catch-22 for them. They are this far behind in part because people fear they might not be around long term, and they might not be, because people don't want to sign up, because they fear it might not be. :)
They could still make money by being far more efficient when running their software natively on their own stack.
API compatibility is not the biggest blocker to changing clouds -- moving one's data is.
The could work out a deal where outbound data from Google to AWS is free, but that probably wouldn't be in their best interests either.
I think their strategy of being the best place to run K8s is a good one. If you standardize on K8s you can run on any cloud, and they want to be the best place to do that.
Still have the data problem though.