Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Kubernetes Engine is introducing a cluster management fee on June 6

cloud.google.com

Post reply on HN
Print view View original

231–240 of 633 posts

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#231

Post by GKE_Greed »

thockingoog wrote: post #228
alasdair_ wrote: post #218

Earlier quoted context omitted.

>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 it…

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…

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.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#232

Post by GKE_Greed »

pcj-github wrote: post #214

Thomas Kurian is going to be the Steve Ballmer of Google, and he's currently tearing up Google from the inside. Google leadership need to wise up and give this guy his walking papers.

he is like GKE, once you start him, you can't stop :)

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#233

Post by sethvargo »

mleonard wrote: post #203
sethvargo wrote: post #136

Earlier quoted context omitted.

I think you'd be interested in our Google Cloud for Startups program: https://cloud.google.com/developers/startups

It's a good program. I'm currently in the stage one step before that program. Would your team consider tweaking the pricing as I mentioned, with the goal of helping early stage startups choose GCP? GKE/kubernetes is increasingly not just for big enterprise. Personally I find GKE as easy as app engine or cloud run but much more future proof and more flexible/powerful... the real heart of a GCP to rival AWS. Just this…

> Would your team consider tweaking the pricing as I mentioned, with the goal of helping early stage startups choose GCP?

To be clear, it's not my team. I'm relaying feedback, but I can't make any guarantees or promises.

All this feedback is super valid and important, and it's being synthesized to the product team.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#234

Post by zzzcpan »

thockingoog wrote: post #206
jerendy92 wrote: post #8

Time to dump GCP then. It's not even that the fee is that large, but rather that this is once again Google failing on a long term commitment and shafting those on their platform once again. This was one of the benefits that was pushed by their sales team when they called us up to market GCP over AWS and their EKS offering. Doesn't matter that they are price matching, Google's inability to actually commit to long term…

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 h…

> 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.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#235

Post by nimos »

sethvargo wrote: post #96
kwils wrote: post #35

Note: Azure does not charge a master/cluster management fee (bias disclosure I work for Microsoft)

Attempting to capitalize on a competitor's announcement isn't cool and doesn't look great.

Seems fine to me. Frankly, what isn't cool and doesn't look great is you not disclosing you work for Google in this comment.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#236

Post by thockingoog »

rcconf wrote: post #227
thockingoog wrote: post #212

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=22487110

Honestly I understand the hard work it takes to manage all the clusters, but this was a total bait and switch and hurts the reputation that everyone has with Google Cloud. Telling us to DIY because we cannot pay $71 just sounds like someone who works at Google would say, which you do work at Google. The sentiment with my clients before was that Google Cloud was a great choice because of the security and expertise wit…

I understand the emotional response here, but I don't think it's rational. GKE has to work as a business, or else the whole thing is in trouble.

I think GKE provides tons of value, but people tend to under-estmate that. In order to keep providing that value, we need to make sure it is sustainable.

I'm really, truly sad that you perceive it as bait-and-switch, but I disagree with that characterization. If you want to move off GKE, I'll go out of my way to help you, but I urge you to take a big-picture look at the TCO.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#237

Post by erdii »

agoell wrote: post #200

After this, I've been exploring other places to host our team's clusters... copied pricing below - EKS: $0.10/hour/cluster - Digital Ocean: Free (only charges for the nodes) - Azure: Free (only charges for the nodes) In the long run we'll probably try and build our stack on vendor-agnostic tools.. - Rancher - https://rancher.com/products/rancher/ - Infra.app - https://infra.app (mentioned a few weeks back on the Kube…

Shameless plug: https://www.kubermatic.io Disclaimer: I work at Loodse (the company behind kubermatic)

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#238

Post by aludwin »

mrbrowning wrote: post #178
lvh wrote: post #100

Earlier quoted context omitted.

This highlights a sorta-weird consequence of this pricing change: suddenly pricing incentivizes you to use namespacing instead of clusters for separating environments. (As a security person: ugh.)

I suspect I'm in the minority on this, but I would love for k8s to have hierarchical namespaces. As much as they add complexity, there are a lot of cases where they're just reifying complexity that's already there, like when deployments are namespaced by environment (e.g. "dev-{service}", "prod-{service}", etc.) and so the hierarchy is already present but flattened into an inaccessible string representation. There ar…

Hey - I'm a member of the multitenancy working group (wg-multitenancy). We're working on a project called the Hierarchical Namespace Controller (aka HNC - read about it at http://bit.ly/38YYhE0). This tries to add some hierarchical behaviour to K8s without actually modifying k/k, which means we're still forced to have unique names for all namespaces in a cluster - e.g., you still need dev-service and prod-service. But it does add a consistent way to talk about hierarchy, some nice integrations and builtin behaviours.

Do you want to mention anything more about what you're hoping to get out of hierarchy? Is it just a management tool, is it for access control, metering/observability, etc...?

Thanks, A

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#239

Post by rstupek »

whalesalad wrote: post #125
geerlingguy wrote: post #101

Earlier quoted context omitted.

To be fair, what is the best way to handle expiring credit cards? For one of my SaaS products, I give a 30 day grace period, then delete the data. If they didn't have a backup, that's on them... If they delete the droplet the second a single CC payment fails, that's one thing, but I don't believe that's how their system works.

If you are literally in the business of enabling, storing, and protecting production workloads, data, etc.. then catastrophic data loss should be an asbolute last resort. In both of these instances I am referring to a balance of less than $20. So for less than $20 (a few weeks late) DO says, welp fuck this customer we are going to terminate all of their resources immediately. This is what DO and others need to do: Pu…

I think the saying "you get what you pay for" would apply in this case. People want to not pay for things, they don't get the things.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#240

Post by thockingoog »

seneca wrote: post #62
thockingoog wrote: post #54

Earlier quoted context omitted.

I think this trend is not good overall, and people will eventually be very unhappy with it. I'd rather help you figure out how to use fewer clusters.

Tim, would you be willing to elaborate on why you dislike the "many small clusters" pattern?

Many small clusters just do not deliver on a lot of the value of Kubernetes. Clusters are still hard boundaries to cross (working to fix that). Utilization and efficiency are capped. OpEx goes up quickly.

There are reasons to have multiple clusters, but I think the current trend takes that too far.

TO BE SURE - there's more work to do in k8s and in GKE.

Post reply on HN