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

CloudFlare Is Now a Google Cloud Platform Technology Partner

blog.cloudflare.com

Post reply on HN
Print view View original

21–30 of 88 posts

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#21

Post by Artemis2 »

nulltype wrote: post #9

How is this different from before they were a GCP partner?

It sounds like they are now peering directly. Google could also be operating Cloudflare's [Railgun](https://www.cloudflare.com/railgun) software at the edge of their network to reduce content transfer times.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#23

Post by relaunched »

oaktowner wrote: post #14
nezo wrote: post #6

Is it going to be beta or alpha, like most Google Cloud services?

Google Product Manager here. Not sure why you think most Google Cloud Services are in beta. The Google Cloud products page [1] lists 17 main products. Two are in alpha (Container Engine, Deployment Manager), one is in beta (Pub/Sub). The rest are fully supported. There are some beta features here and there...but saying "most" are in beta is certainly not correct. [1] https://cloud.google.com/products/

I recently just found out that PHP is in Beta (by the support team). That wasn't obvious to me when looking through the website / documentation

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#24

Post by lern_too_spel »

oaktowner wrote: post #14
nezo wrote: post #6

Is it going to be beta or alpha, like most Google Cloud services?

Google Product Manager here. Not sure why you think most Google Cloud Services are in beta. The Google Cloud products page [1] lists 17 main products. Two are in alpha (Container Engine, Deployment Manager), one is in beta (Pub/Sub). The rest are fully supported. There are some beta features here and there...but saying "most" are in beta is certainly not correct. [1] https://cloud.google.com/products/

I think that that it's beta because it's still the case that almost nothing works. Try setting up TLS on App Engine for anything other than your primary Google Apps domain. This has been broken for years, despite Google pushing TLS through Chrome policy changes.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#25

Post by throwaway000002 »

jgrahamc wrote: post #20
throwaway000002 wrote: post #18

This is sorta an internet architecture question for those in the know. Assuming there's no issue with client reachability/latency, what's stopping CloudFlare from having a single IP? Suppose the IP was behind a fat enough pipe, why not load balance behind it instead of DNS load-balancing in front of it (and additionally behind each as I presume now happens)? Also, if that IP was anycast then you could ignore the issu…

1. Non-SNI based SSL means you need an IP per host. 2. People attack IP addresses. Handy to be able to change the IP address of a web site. 3. Countries block sites based on IP addresses. Handy to be able to move sites around to prevent collateral damage.

In my defense, I was assuming SNI (aka the modern internet), and that the IP was reachable by those you care for it to be reachable by. Ignoring these issues, is there an "engineering" reason why a single IP won't work, in terms of, for example, hardware can't demultiplex the aggregate ingress volume of CloudFlare and handle DOS mitigation?

I guess I'm asking this because of how woeful looking the "load-balancing" solutions are from the major cloud providers. I feel they way they're externally documented, and how their APIs are specified, hitting them with more than a 40Gbps fat-server's load of traffic will cause issues, regardless of how many hosts you have serving that load.

I'd appreciate some insight from those who handle such crazy amounts of traffic.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#26

Post by jgrahamc »

throwaway000002 wrote: post #25
jgrahamc wrote: post #20

Earlier quoted context omitted.

1. Non-SNI based SSL means you need an IP per host. 2. People attack IP addresses. Handy to be able to change the IP address of a web site. 3. Countries block sites based on IP addresses. Handy to be able to move sites around to prevent collateral damage.

In my defense, I was assuming SNI (aka the modern internet), and that the IP was reachable by those you care for it to be reachable by. Ignoring these issues, is there an "engineering" reason why a single IP won't work, in terms of, for example, hardware can't demultiplex the aggregate ingress volume of CloudFlare and handle DOS mitigation? I guess I'm asking this because of how woeful looking the "load-balancing" so…

If you think of a connection is defined by the tuple (source_ip, source_port, destination_ip, destination_port) then you might run into problems if destination_ip was a single value, just because whatever hashing you are using/table lookups for connection management, DoS protection etc. etc. might have problems with the sheer size. We are doing a huge amount of traffic and I can imagine having to engineer around some things related to that.

But the real issues are the ones that outline above.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#27

Post by philip1209 »

throwaway000002 wrote: post #18

This is sorta an internet architecture question for those in the know. Assuming there's no issue with client reachability/latency, what's stopping CloudFlare from having a single IP? Suppose the IP was behind a fat enough pipe, why not load balance behind it instead of DNS load-balancing in front of it (and additionally behind each as I presume now happens)? Also, if that IP was anycast then you could ignore the issu…

My understanding is that they basically "fast flux" IPs to funnel traffic for targeted attack to a specific data center. So, while you normally may be sharing IPs, if an enterprise customer's website example.com starts getting attacked they will put it on dedicated IPs, then broadcast those IPs from one or two data centers. They will then reroute all other enterprise traffic away from those data centers, thus minimizing the attack effect on other customers. If these websites were all on the same IP, it would be impossible to distribute traffic selectively between data centers like this.

Another thing they can do is use anycast to load balance across data centers. So, if a data center rather than a website is a target - the attackers will need to know which IPs to attack. They can start flooding the broadcasted IPs from a particular route. However, if this happens then hypothetically Cloudflare could just stop broadcasting the IPs at this particular data center, re-broadcast them at all the surrounding data centers, and basically spread out the attack load across multiple sites. If the attackers change the IPs that they target based on new routes, then Cloudflare can continue fast-fluxing the IPs every 5 minutes and mitigate the attack.

It's pretty cool use of BGP and anycast, but being able to change IPs of website and where they are broadcasted in real-time is core to Cloudflare's security.

Post reply on HN