Hacker News Reader

Comment by xkgt | Hacker News Reader

This is silly and will further harm GCP's viability as alternative to AWS or Azure. Firstly, I can't find any official announcement regarding the rationale and suggested solutions for their customers to reduce their cost. Just adding a banner to docs pages is plain lazy and is not customer friendly.

Ideally IPv6 support should have been added or at least scheduled to be available at instance level [1] before enforcing such charges. This indicates a lack of engineering capability (more likely resource commitment) to implement such a critical feature on its platform in a timely manner, particularly given that its rivals already have the support in place. To me, that is more worrying than an increase in bill. What is the pace of innovation one can expect from GCP platform? How committed are its leaders as a public cloud service provider?

1. https://googlecloudplatform.uservoice.com/forums/302595-comp...

View on HN

I think this nets to a < 0.01% delta to our bill. Is this really that big an issue in practice? For hobbyist projects, maybe? But for larger customers, this is a drop in the ocean.

I actually think this is a (somewhat) smart move. It incentivizes you to use a NAT gateway to egress traffic to your instances. You can either run your own fleet (it's very easy - but you gotta fix it if it breaks), or use their managed NAT solution (more expensive, but with less worry hopefully) - and not just tack on a public IP to every instance that needs internet connectivity. We did this from the get-go (running our own NATs) - and only have a few public IPs relative to the # of instances we run.

If it’s 0.01% then why should google bother with it? All it does is cost goodwill for a negligible amount of money.

We have vm external ips turned off at the org level. It feels like every day we have to explain to a new person that no, that google written tutorial doesn’t work because it assumes public ips are available. Entire services don’t work with this flag on.

The other shitty thing is it feels like at least once a month we get some email of a price increase or deprecation that causes some fire drill, and then we ask our tam to tell us the actual cost and he can’t because he has no idea it’s happening so the burden falls on us

IP addresses are limited and even small costs are better at forcing people to conserve limited resources than "free".

For an example, 5 cents isn't much, but charge that per plastic bag and suddenly people are using a lot fewer disposable bags.

[our customer representative] has no idea it’s happening

Why do you continue to do business with GCP if their customer service is that bad?

my experince with GCP support during the free trial (with the advertising explictly saying that they provide "Technical Support for free trials") was:

    1. create ticket
    2. immediately receive email telling me I'm barred from free technical support and told I need to purchase a "Silver, Gold or Platinum Cloud Platform Support package"

Hah, the best part is I legitimately had to deal with GCP actually being broken (resource refused to delete) that could only be fixed by Google internally (both portal and cli returned http 500). Imagine the joy I had not having "technical support" as a benefit.

Because it's a lot cheaper than AWS, whose $500/month customer service is just as bad?

AWS support is indeed pretty crappy. $500 is not a fixed price. You pay 10% for the first 10K/month, 7% of $10K-$80K and so on. The Developer plan is 3%, but is pretty worthless - it should be renamed to rookie-plan or similar - you can get the same answers on SO for free within minutes instead of waiting days. Getting past first-level support on the Dev plan with harder technical issues takes weeks in my experience.

see https://aws.amazon.com/premiumsupport/pricing/

It takes time and energy to migrate, which is in progress

For many startups, using this more difficult but technologically sounder solution could mean hiring another engineer they can't afford.

Setting up an inbound proxy VM that NATs all your other machines is not "difficult".

There are plenty of tutorials online for doing this with nginx or Apache, and even a junior dev ops person should be able to do this in a few hours' work.

I highly doubt this requires hiring another engineer.

GCP has had CloudNAT for some time now. It’s a checkbox in the GUI and just works.

It's not about the cost. Every Internet connected system(at least in cloud. Ideally every system) should be publicly accessible but instead of providing it by default they are providing it as feature. If you don't want to show VM to the world then you use NAT but they have got this backward.

This is slippery slope. One day they might charge you to open a port to external world.

"Every Internet-connected system should be publicly accessible"

That sounds like a security or data leak nightmare waiting to happen. I would prefer not entrust my data with a company that feels there's value in having all of their instances publicly addressable.

Actually, Google professes in their "BeyondCorp" security model a zero-trust architecture. You shouldn't be assuming that just because your instance isn't publicly accessible that it is secure. (See: https://cloud.google.com/beyondcorp/)

Which makes this move even more surprising, because GCP reference architectures have traditionally been focused around public facing Internet access. Unless, it is a sign that GCP is getting more traction and Google is running out of public IPs to be handing out like candy. This could be an economic incentive to encourage people to conserve these IPs.

This is not what BeyondCorp means. It doesn't mean everything is publicly accessible. It means you don't make trust decisions based on "approved networks", but instead at the device level. It DOES NOT mean that you don't segment services, restrict access to systems that don't need public access, or follow any of the other appropriate security guidelines.

> You shouldn't be assuming that just because your instance isn't publicly accessible that it is secure

No one thinks this, and no one said anything of the sort. But likewise, making everything public because Google has a site called BeyondCorp, doesn't make it secure. There is a lot of effort to adopt a BeyondCorp model. None of which includes "make everything publicly routable".

Zero-trust architecture seem nice idea, and one you can implement when you’re Google and probably spend more on security than the gross revenue of most other companies reading your whitepaper.

I think the notion most infrastructure is not publicly addressed is prevalent, even in Google, i.e. you can’t SSH to the hypervisor hosting customer instances in GCP directly, it doesn’t have SSH sat on the public internet.

Public addresses are readily available on the secondary market but a /12 probably runs somewhere around $20MM.

Charging for IPv4 seems like a move designed to make all the smallest customers who care about $3/mo leave, GCP ends up with less customers and ARPU goes up probably significantly.

If you use IAP (Google's BeyondCorp secure proxy product) then your instances don't have a public IP; they are behind a firewall rule.

Also there is a big difference between BeyondCorp's "all internal services are on the public internet" and "all instances are on the internet". You don't want to put your DB server on the internet, for example.

NAT has messed up Internet so much that people can't even ensure security without it. You have firewall for security. If we had not relied on NAT for security we would have actually configured them.

Anyways, we are gonna have to configure firewalls for IPv6 because there is no NAT.

I understand that with IPv6 you don't need NAT to fix scarcity problems, but is IPv6 technically incompatible with NAT?

Heh,

The container network ecosystem is crap because of NAT and what seems to be a lack of understanding around networking

NAT is not a firewall. Whilst NAT does not necessarily hurt security, a system that becomes unsecure if not behind NAT is not properly secured.

Firewalls are a thing. Addressable has nothing to do with what's listening for who at the other end.

Which internet standard is the source for that claim?

> Just adding a banner to docs pages is plain lazy and is not customer friendly

We will be affected by the change (our prices will drop) and we received a proactive email about them this morning.

We will also be affected and also received a proactive email this morning.

Plus, this is chump change, but it reminded us that we really should migrate behind their NATs for outgoing traffic. I do think that they are doing this to motivate customers to reduce the IP usage as the IPv4 space is finite.

Not to detract from what you're saying about IPv6: support there is key. Azure and AWS both support IPv6.

That said, Azure charges for IPv4 external IPs. AWS does not, but I'd be surprised if the cost wasn't internally associated with ELB/ALB, EC2 instances, or other products. That is, you're still paying for it.

While elastic IPs are free for an active instance, AWS does charge for unused EIPs[1]. (You can also set a public IP on an instance, but it can change when the instance is restarted.) So if you need to hold on to an IPv4 address, it's going to cost you.

That seems like it's exactly the same model as GCP.

[1]: https://aws.amazon.com/premiumsupport/knowledge-center/elast...

It won't be the same, right? Per the article, GCP will be charging on active instances.

Oh, derp, I must have skipped past the article to the GCP page.

Not sure if I'm just misunderstanding you -- by "article" I mean "GCP documentation page", which for completeness states:

"Static and ephemeral IP addresses in use on standard VM instances

*Starting January 1st, 2020, you will be charged $0.004 per hour."

No they will charge you for addresses you don't use.

Which makes perfect sense imo.

> No they will charge you for addresses you don't use.

No, that is what they currently do. Starting January 1, 2020, they will charge you for addresses on active instances.

Current:

Static IP address (assigned but unused) $0.010/hr

Starting January 1, they add:

Static and ephemeral IP addresses in use on standard VM instances $0.004/hr

Static and ephemeral IP addresses in use on preemptible VM instances $0.002/hr

Sure, you're paying for everything you use, but the difference is when you compare costs. The less "addons" you need, the more true is the cost.

>What is the pace of innovation one can expect from GCP platform?

How committed are its leaders as a public cloud service provider? Has a customer GCP for the last 3 years I am concerned about the pace of innovation.

For example, CloudFunctions still can't be put behind a VPC.

I also run another product that's built on AWS and extensively uses lambdas, and the depth and breath of the solution continues to amaze me.

It works! https://stackoverflow.com/questions/57058395/when-will-googl...

That's progress! Though it's sill in beta - which might be OK for a side project but does make me nervous any critical aspect of a production application. https://cloud.google.com/vpc/docs/configure-serverless-vpc-a...

And I gave up on Step Functions... Probably announced at the next summit but we needed it 18 months ago... our move to AWS was beneficial with just that

Reply on news.ycombinator.com