Live data from Hacker News

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

cloud.google.com

551–560 of 633 posts

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

#551
post #488
post #273

Earlier quoted context omitted.

Thats for me the most frustrating thing with GCP, AWS and Azure. I would never use them as a very early small 3 people startup or for private reasons. There is no billing protection (which could make you very poor very fast) and every service has a certain cost and quality which is just not feasable in the beginning. Even GKE with its free kubernetes master does block a lot of resources on the nodes: https://cloud.go…

Both AWS and Google offer free tier products and pay-for-what-you-use products. Reserved instance pricing starts at around $25/year. Many other incredibly useful products (S3, Lambda, VPC, etc.) are free with an instance or start at $0. You can set billing alerts that will project your monthly budget every hour, and send you an alert when it's projected to be exceeded. IMHO your claim (that there is an entry cost bar…

My main concern is, that i can't define an upper limit. My billing alert is nice and im aware of it, but it doesn't help you if someone takes over your account, mines bitcoins on expensive machines and a day later you read your email.

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

#552
post #487

Earlier quoted context omitted.

From my link above: >"The EKS control plane is the easiest to understand with a fixed cost of $0.20 per hour."

AWS pricing changes over time (although they are careful not to trap or antagonize customers with changes like this one). You linked to a static blog post that has a price from the past. https://aws.amazon.com/eks/pricing/ is the up to date page. https://aws.amazon.com/blogs/aws/eks-price-reduction/ is the announcement of the price cut.

Oh wow, that price reduction is fairly recent too. Thanks for the updated info!

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

#553

Earlier quoted context omitted.

> This is great feedback, but clusters should be treated like cattle, not pets. I'd love to learn more about why your clusters must be so static. What’s inside our clusters are indeed cattle, but the clusters themselves do carry a lot of config that is set via GCP UI for trivial things like firewall rules. Of course we could script it and automate, but your CLI tool also changes fast enough that it becomes an ongoing…

Hmm - have you considered a tool like Terraform or Deployment manager for creating the clusters? In general, it's best practice to capture that configuration as code.

It could be totally unrelated but having an option such as equivalent TF along with REST and CLI options could dramatically speed up the configuration process.

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

#554

Earlier quoted context omitted.

Hmm - have you considered a tool like Terraform or Deployment manager for creating the clusters? In general, it's best practice to capture that configuration as code.

Cloud providers assume everyone is just like them, or like Netflix: Load balancers in clusters balancing groups of clusters. Clusters of clusters. Many regions. Many availability zones. Anything can be lost, because an individual data centre is just 5% of the total, right? Meanwhile most of my large government customers have a couple of tiny VMs for every website. That's it. That's already massive overkill because th…

Have you considered the Google App Engine on GCP in standard mode? That seems like a good fit based on your explanation but I could be wrong.

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

#555

Earlier quoted context omitted.

> Azure is more complete than GCP It has more features, yes. How well those features work is another matter entirely.

Can you give more details on this? Anecdotal is fine I loosely follow AWS, GCP and Azure but I always get mixed opinions on them, especially the last two

I use only small subsets of Azure, but every bit that I do use leaves me with a feeling that I'm the first user of a minimum viable product.

To pick a random example that I'm familiar with: Azure DNS Zones.

When I used AWS Route 53, the main issue I had with it was that I thought the cutesy marketing name was stupid. That's about it. By reading through the docs, I learned a little bit about DNS I didn't know, and I got to learn about the clever engineering that AWS did to work around issues with the DNS protocol itself. In the end, it had more features than I needed, and the basic stuff Just Worked.

When I tried to use Azure DNS, their import tool shredded my data. I then wrote a custom PowerShell import tool, but it took hours to import a mere few thousand records. The next day my account was locked out for "too many API calls" because I simply had the console web gui open. Not used. Open. The GUI showed entries different to the console tools. The GUI string limits don't match the console tool. The perf monitor graph was broken, and is still broken. Basic features were missing, broken, or "coming soon".

You would think DNS would be one of those services that "just works", but nope. Bug city.

Now mind you, most of those issues are fixed now, and they're adding more features and fixing the issues those new features are introducing.

But ask yourself: Why are buggy features being rolled out in production? Did nobody test this shit? Did they ever do a load test? Did they even try basic things like "have the console open with more than 10 records"? Why am I discovering this? Do they not have thousands of customers who have battle-tested this stuff?

Clearly they're just throwing things over the fence and letting support tickets be their QA feedback.

PS: It's even how they use DNS themselves that's just wrong. E.g.: If you use Azure CDN you end up with like 6 CNAME redirects in a row. The DNS standard says CNAMEs shouldn't point to other CNAMEs! At a minimum this is slower than it needs to be, but it's also less reliable because there's more points of failure...

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

#556

Earlier quoted context omitted.

As many have mentioned here already, $72/mo most likely a rounding error on workloads kubernetes is designed for. I think, most customers love the change because of SLA where even 1 minute of downtime per year is amplitude more costly than 10 years of cluster managing fee. This also showing the commitment from google to provide great and reliable service. If you're looking to run k8s "for free", Digital Ocean looks l…

> As many have mentioned here already, $72/mo most likely a rounding error on workloads kubernetes is designed for. There are _many_ reasons to use k8 beyond just workload scale and that amount per cluster per month isn't anywhere near a rounding error for many deployments.

I would be interested to know when you may need kubernetes for small types of workload and simple architecture.

For my understating, support contract alone for google cloud will cost you around $150/mo.

For small to medium workloads there are plenty of tools if you want to use containers: docker swarm and nomad. Docker Swarm is really simple and most engineers already know it because of `docker-compose.yml` they're using each day.

I can't really understand what type of workload you have because kubernetes cluster management requires you to have at least 2 full-time DevOps team. What is $72 compared to salary of two employees?

If you have an issue with $72 for SLA guarantee then I can't really understand why you need google cloud at all. They are literally bound to maintain zero downtime because of huge losses if something go down for their entire customer base.

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

#557

Earlier quoted context omitted.

This is an interesting exchange if only for the thread developing instead of a single reply from a rep; it’s nice to see that level of engagement. More importantly, this dialogue speaks volumes to Google’s stubbornness. Seth’s/Google’s position is: do it the Google way, sorry-not-sorry to all those that don’t fit into our model. Like we haven’t heard of infrastructure as code? That can’t paper over basics like being…

Google stubbornly resists the idea that their platforms have actual users who depend on things not being broken for them constantly. It's cultural. AWS has the complete opposite model.

[deleted]

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

#558
I was an early adopter of Google App Engine when it was first released and the consistency guarantees of the datastore burned me pretty badly. What I experienced in the test environment was not even remotely close to what I got in production.

Just last week, I was so tempted to give Google another shot over AWS. By all accounts, they have come so far, and more importantly, started using more of my preferred toolset as well. This is exactly the kind of thing that really scares me off.

I have a huge amount of respect for the world class systems scientists and engineers at Google. Unfortunately, they seem to counter it with a customer experience full of uncomfortable, often expensive surprises.

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

#560

Earlier quoted context omitted.

Hmm - have you considered a tool like Terraform or Deployment manager for creating the clusters? In general, it's best practice to capture that configuration as code.

Cloud providers assume everyone is just like them, or like Netflix: Load balancers in clusters balancing groups of clusters. Clusters of clusters. Many regions. Many availability zones. Anything can be lost, because an individual data centre is just 5% of the total, right? Meanwhile most of my large government customers have a couple of tiny VMs for every website. That's it. That's already massive overkill because th…

I think you're wrong -- containers aren't ready for legacy enterprise, VMs are a better choice of abstraction for an initial move to cloud.

Get your data centers all running VMWare, then VMDK import to AWS AMIs, then wrap them all in autoscaling groups, figure out where the SPOFs have moved to, and only then start moving to containers.

In the mean time, all new development happens on serverless.

Don't let anything new connect to a legacy database directly, only via API at worst, or preferably via events.

Post reply on HN