If the main value of GKE over DIY is $73, you should totally DIY.
I mostly try not to be too Google-focused here, but I have to say...
I'm pretty proud of GKE, and I think it offers a lot of value other than just being cheap. Managing clusters is not always easy. GKE handles all of that for you - including integrations, qualifications, upgrades, and patching clusters transparently BEFORE public security disclosures happen.
We have a large team of people who deal with making GKE the industry-leading Kubernetes experience that it is. They are on-call and active in every stage of the GKE product lifecycle, adding value that you maybe can't see every day, but I promise you is there. When things go sideways, there isn't a better team on the planet to field the tickets.
I don't understand the anger here - you're literally saying you'd rather pay more for a service of lower quality because... why? Because they will continue to charge you more? Does not compute.
For those people who use a large numbers of small clusters, I understand this may make you reconsider how you operate. As a Kubernetes maintainer, I WANT to say that a smaller number of larger clusters is generally a better answer. I know it's not always true, but I want to help make it true. GKE goes beyond pure k8s here, too. Things like NodePools and sandboxes give you even more robust control
GKE is the best managed Kubernetes you can get. And we're always making it better. Those clusters actually DO have overhead for Google, and as we make GKE better, that overhead tends to go up. As someone NOT involved in this decision, it seems reasonable to me that things which are genuinely valuable have a price.
Also, keep in mind that a single (zonal) cluster is free, which covers a notable fraction of people using GKE.
I believe everything that you say. The value it provides is very good.
If Google Cloud would have charged 73$ from the start (or after beta), i think there wouldn't be so much anger.
The anger comes from, a product was free and now it is not. A lot of people made architectural choices that depended on the price of 0. (You mentioned these cases in your post).
However, i believe the bigger issue is, that Google Cloud broke essentially a promise.
As a customer I need to be able to trust my cloud provider, because I am literally helpless without it.
Can I trust an entity that breaks promises ? No, I can't. I need to worry.
Especially, if I cannot follow the reasoning behind it.
If it is true, that Google's overhead went up, because of improvements, then it would have better to have two kinds of clusters (better and paid, old-school and free).
You would have not broken the promise. People can choose on their own pace to upgrade if they need to.
Also keep in mind, that you also carry the Google brand. Hence, if other teams of Google break promises (like f.e. Stadia) this will also reflect on the Google Cloud team. Unless you keep a crystal clear track record, i need to assume it can get worse than what you have done right now.
My conclusion is that, I will design the cloud architecture I am responsible for, such that it has minimal dependencies on Google Cloud specifics.
> I don't understand the anger here - you're literally saying you'd rather pay more for a service of lower quality because... why? Because they will continue to charge you more? Does not compute.
This response, right here, is everything you need to understand about why Google Cloud is failing to sell to the enterprise market.
The enterprise market only really cares about one thing: rock solid stability. It doesn't care about features, and it doesn't (really) care about price. It wants a product that it can forget is there.
What's really sad is, technically, GKE is that product. It just works. It is solid. You do get to forget that it's there. Until you get a random email telling you that you get to explain to your boss that your bill is going up next month and your project might end up running over budget as a result.
If you can understand why a large segment of the market prefers to pay a higher but stable charge over a lower but undependable charge, then you can understand why Google Cloud is failing at selling to enterprise.
I'm the CTO at a very small company. All our stuff is running on GKE. Our monthly bill tends is a lot less than $10,000/mo. We're currently in the process of splitting our stack into separate projects and clusters, because co-locating projects in a single cluster has gotten messy. We'll probably end up with 4-5. That will increase our bill by $292/mo, worst case, assuming the first cluster is free. For a company our size, it's not a huge expense. But these things add up.
Since moving from DigitalOcean, our Google Cloud setup has more than doubled our monthly bill. We're paying for more compute, but certainly not twice the amount, as we've only gone from 14-15 nodes to around 20; it's just more expensive across the board, both node cost and ingress/egress. We're even cost-cutting by using self-hosted services instead of Google's; for example, we use Postgres instead of Cloud SQL. I ran the numbers earlier today; the equivalent on Cloud SQL would be 3.4 times more expensive.
In short, Google Cloud is expensive, and it's not like the bill is getting smaller over time.
Developments like these factor in my choice of cloud provider for future projects.
Not sure what size a "very small company" size is, but I'm just curious as to why you chose GKE. I make tech decisions for a (probably) much smaller company, and I found things like App Engine Flexible Environment, Cloud Run and Cloud Functions let me do much of the stuff I can do with k8s but with much, much less complexity (at least on my side of things). The main factor is that I don't have a full-time infrastructure expert, and my experience in the past is that k8s essentially requires that.
We have about 200 long-running pods right now. On Cloud Run, that would cost us more than $12,000 in CPU alone, and that's excluding memory and request costs.
That also excludes stateful apps like Elasticsearch that would not be able to run on Cloud Run. Not sure what Google product is appropriate there.
So let's say you have a small pile of apps that are all <app_server>, <redis>, <jobqueue/workers>, <db>, <frontend>, but not all the same DB, language, etc. They're all low traffic and you want to automate/simplify and containerize them. On developer machines docker compose works great, but you need to deploy in a cloud provider. What are choice do you have other than K8s?
Less than 15 employees. Several products, two teams, <= 20 nodes.
We migrated our stuff from DigitalOcean around 2018. At the time, we briefly toyed with the notion of self-hosting Kubernetes on DO, but it's complex to manage, and we don't have any dedicated ops staff. GKE is significantly easier to manage.
At that time we migrated, the things you mentioned weren't available/mature, I think. Even today, I'd choose Kubernetes over a complex mishmash of different systems. I like the unified, extensible ops model. In fact, I'd go so far as to say that I wish all of GCP could be managed as Kubernetes objects.
That's very cool, thanks! Note that this allows selectively creating Kubernetes resources backed by GCP resources. Looks like it will not automatically sync everything that already exists, which seems like a missed opportunity.
Would never happen. Just the amount of time needed to dedicate to onboarding a temporary contractor would be really disruptive to the developers, not to mention the disruptive effect of the technical migration — databases to move over, persistent volumes to copy, DNS to repoint, lots of downtime, etc. There's a good reason companies don't switch clouds often.
If it takes more than a month to migrate a 20-node K8s cluster, then that's a red flag. Too much tech debt or a strong vendor lock-in? Either deserves attention.
Doing the migration might take a few late evenings; deploying all our apps and Helm charts to a new cluster takes just a few commands. Learning what needs to be migrated, deciding on how the configuration should look on the destination end of it, and designing a detailed plan and checklist for the whole process is the big task. Adding the onboarding of someone who's never seen the inside of your company and you're talking about a longer, more disruptive process. Tech debt isn't a factor here.
Indeed, for small apps that average 2 instances or less during the month it's now cheaper to run App Engine Flex than GKE. Each instance costs about US$ 50/month in US central.
For those that are not aware, App Engine Flex runs services based on Docker containers with autoscaling similarly to Kubernetes. It has way less features than GKE, but if you are just running a standard app that only needs to connect to a database that is more than enough.
Bonus points: you can have multiple services, like back-end and front-end and make them available in the same subdomain - to avoid CORS problems. You can also host your front-end for almost nothing with App Engine Standard. It has an awesome CDN built-in if you know how to use it.
For sure, though I will say if you're trying to cut costs, it's my understanding serverless is quite cheap. So if you can turn some of your services into serverless containers/functions. I'd highly recommend it.
How much would it cost for you to provision and colocate your own hardware, run a k8s cluster, and manage upgrades?
You might not be at the scale where this is feasible yet since that's probably multiple full-time engineers, but eventually the cost functions intersect.
> I don't understand the anger here ... Does not compute.
The saying: “the market’s perception is your reality”, is especially apt here. Google’s decision makers tends to forget that in the end they are dealing with human customers not machines. Contrary to the concept of economic rationality, humans are notorious for exhibiting behavior that, to the untrained eye, appear irrational.
A commenter helpfully explained their perception of the new pricing change:
“The anger comes from, a product was free and now it is not. A lot of people made architectural choices that depended on the price of 0. (You mentioned these cases in your post).
However, i believe the bigger issue is, that Google Cloud broke essentially a promise.”
IOW, from their perspective, the pricing change was framed as a loss [1] which opened up a host of negative emotions (anger, mistrust, etc) that come with mitigating a loss that is imminent.
Google as an engineering company may look down on fields like psychology or behavioral econs, but if they genuinely want a fighting chance against AWS and Azure, they will need to court sales leaders with a strong humanities tinge, to avoid these kinds of decision-making that achieve the opposite intended effect — eroding people’s trust in GCP.
>If the main value of GKE over DIY is $73, you should totally DIY.
It's not the fee itself, it's the worry that GKE will do what Google Maps did and massively increase fees with very little notice, causing people to scramble to migrate.
Google has a really bad reputation right now when it comes to cancelling projects that people have built their businesses upon, or jacking up fees quickly. The $73 is irrelevant on its own - the issue is (a lack of) customer trust.
Google and Google Cloud are largely different businesses, though I understand it's hard to keep that in mind in the context of things like this.
I encourage everyone to always stay nimble and keep your eyes on portability. I also encourage you to try to assess the REAL costs of doing things yourself. It's rarely as cheap as you think it is.
As a Kubernetes maintainer, I am fanatical about portability.
As part of the GKE team, I think we provide tremendous value that people tend to under-estimate.
NOTE: I was NOT involved in this decision, but I understand it, and I want to help other people understand it.
If you brand it as "Google," you can't expect the positive associations to transfer and the negative associations not to transfer. That's not how it works. You get both or you get neither.
Keep in mind that you aren't selling to me, you are selling to middle management who hears "it's different we promise" and then goes home to have nightmares about their rival manager piling on: "GCP canceled a service from under you? Who could possibly have seen that coming? Oh, the salesman told you it wouldn't happen, my mistake. (Everyone laughs at manager's stupidity.)"
GCP needs to give these guys ammunition. AWS burns goodwill like they've got a city to light: surprise bills, abandoned (but technically not canceled) services, poor performance, sticky abstractions, shameless grand announcements of services that upon further investigation only exist in the sense that you can ask support and wait 5 days (rDNS), etc. Broken software and subtle (or overt!) killer caveats abound. Go with AWS, we scale to the moon! Oh, "the moon" is >5GB of data through our time series ML? Lol no. Hard limit. Oh, we let your buddies exceed that limit and we're advertising that you can exceed the limit? Lol -- not our problem. Yet nobody holds them accountable. Nobody gets fired for choosing AWS, because AWS over-promising and under-delivering is not a meme. It's reality, especially by Google standards, so GCP marketing could make it a meme if they had any sense about them, but as far as I can tell they aren't interested.
If GCP stays the course, the results are 100% predictable and frustrating as hell, because AWS is a real steaming pile and I hate to see them continue to win The Game because Google, of all companies, can't figure out how to advertise and manage their reputation.
Google and Google Cloud are not largely different businesses to the world at large. That may be true internally, but what you do reflects on the other.
Aside from that, Google has a reputation for pulling this shit, and now Google Cloud does too.
The value you provide is irrelevant to how you make people feel with decisions like this.
sorry that you have to work with such low-IQ people that made this decision. Followed your work on k8s, thank you, its better because of people like you and others.
It's not about whether it's worth it. I have no idea if $73/mo/cluster is more or less than what GKE is worth, but you can't ignore the time-varying aspect of this change. If GCP had started at $100/mo and just announced a price drop to $73/mo, your customers would probably be cheering, even though you'd be charging them the same! They'd be happy about being loyal to you, thankful that your offering gets better over time without asking, etc.
Let me put it another way. Lunch perks at Google are probably worth way more than $73/mo. Googlers would probably not feel too great about having to start paying that amount... Even though it's also worth it, people working hard to prepare food, etc.
It happens time and time again that GCP paints itself in a corner with an unsustainable offering and finds itself in a situation where it has to dent customer trust by hiking prices or retiring products on short notice.
Why?
GCP is in no position to pull this off, competitively. Now doesn't seem like the time to pull unit margins up. Google could do so on ads or with Maps API because it has the best product by far in those areas. But not in Cloud, a market where stability is a feature, and GCP is a late, small player against larger competitors who are giving customers a much more stable product.
It doesn't matter if GKE is the best thing since sliced bread, and keeps getting better — as the CTO of a cloud-based business, you have to decide whether you want to build on it over the long run and take the risk of it becoming super expensive over time; there's not a lot of reassurance that this is even a concern at Google at this point.
> Now doesn't seem like the time to pull unit margins up.
Tbf, you don't have the data to say that. Maybe GCP hit the growth targets they had and are not interested in growing more; maybe they've grown so much that service quality is going down; maybe they want to stall and build up other parts of the offer... there are a lot of reasons why they might want to cash in. Whether they could have foreseen it happening at this specific point in time, and how they managed the communication, is another matter. As others said, Google is saddled by default with a perception of commercial unreliability among the tech-savvy, so any new service they launch should factor that issue in terms of long-term optics.
> Maybe GCP hit the growth targets they had and are not interested in growing more; maybe they've grown so much that service quality is going down; maybe they want to stall and build up other parts of the offer...
> If the main value of GKE over DIY is $73, you should totally DIY.
I'm with you here, and the price feels about right (looking at GCE prices)--it doesn't feel like it's a ripoff or someone's trying to squeeze out more revenue.
> I don't understand the anger here
This is Google being Google. The fee probably makes sense, but as flawed humans, we're subject to the endowment effect and feel like Google's taking something from us. Amazon's all about this customer. This move is all about accurately pricing services, and it's Google putting correctness before emotions.
The problem is you are charging more without providing a clear case that the value is worth it. It looks like a bad deal from an existing customers view point.
73/month is not a lot, but it’s still turning back on the original value proposition. If it’s such a small amount, absorb the cost as cost of doing business, so you can retain customers better and grow new ones.
> As a Kubernetes maintainer, I WANT to say that a smaller number of larger clusters is generally a better answer.
I'm not trying to nitpick here, but that justification is awful. It goes against reliability engineering on a deeply fundamental level, pretty much guarantees to make already not that reliable things even less reliable. Generally the more isolated entities you have and the smaller they are the less they affect each other and the environment when something bad happens, the faster they can be recovered, the fewer end users they affect, etc. If I remember correctly, this is even how some Kubernetes people justified ideas behind Kubernetes itself that you want to drop now.
I mostly try not to be too Google-focused here, but I have to say...
I'm pretty proud of GKE, and I think it offers a lot of value other than just being cheap. Managing clusters is not always easy. GKE handles all of that for you - including integrations, qualifications, upgrades, and patching clusters transparently BEFORE public security disclosures happen.
We have a large team of people who deal with making GKE the industry-leading Kubernetes experience that it is. They are on-call and active in every stage of the GKE product lifecycle, adding value that you maybe can't see every day, but I promise you is there. When things go sideways, there isn't a better team on the planet to field the tickets.
I don't understand the anger here - you're literally saying you'd rather pay more for a service of lower quality because... why? Because they will continue to charge you more? Does not compute.
For those people who use a large numbers of small clusters, I understand this may make you reconsider how you operate. As a Kubernetes maintainer, I WANT to say that a smaller number of larger clusters is generally a better answer. I know it's not always true, but I want to help make it true. GKE goes beyond pure k8s here, too. Things like NodePools and sandboxes give you even more robust control
GKE is the best managed Kubernetes you can get. And we're always making it better. Those clusters actually DO have overhead for Google, and as we make GKE better, that overhead tends to go up. As someone NOT involved in this decision, it seems reasonable to me that things which are genuinely valuable have a price.
Also, keep in mind that a single (zonal) cluster is free, which covers a notable fraction of people using GKE.