5 ms·

Yes, +1 on SNI support. I know there is a feature request on it, and I've already +1 there. We currently use GCP. We have custom domains. As it is, we're looki

by hosh 10y ago

Yes, +1 on SNI support. I know there is a feature request on it, and I've already +1 there. We currently use GCP. We have custom domains. As it is, we're looking to schedule time to roll our own multi-az load balancers and using the TCP load balancer because the HTTPS load balancer doesn't support SNI. If SNI were available for HTTPS LB, we'd jump on that in a heartbeat.

manigandham 10y ago
Just use Cloudfront or another CDN in front. This cant be worth the engineering time to build something yourself.
- stephenr 10y ago
  Load Balancing software is a thing. It exists, waiting for you to install and configure it. For a site called hacker news, its fucking depressing how many people here jump at every possible chance to give up control of the most basic things in their tech stack, for no other reason than "X already runs something similar as SaaS".
  - akanet 10y ago
    I don't think I would be so quick to dismiss this sentiment. I run a profitable SaaS business, and every opportunity to give up responsibility results in highly profitable refocusing of effort on the things we do that actually matter. I'd much rather have a team of Google engineers running our LBs than myself.
    - stephenr 10y ago
      This entire thread is about the hoops people are having to jump through to get pretty basic functionality from a load balancer, specifically because they took your approach. I didn't say it can't work for anyone, I said its depressing how it's the default/only approach for so many people who call themselves "hackers".
      - akanet 10y ago
        I think it's tempting to assume that sentiment expressed here is reflective of the majority - everyone whose use case is served well is happy and likely doesn't comment. As for the "hackers" comment - HN might have "Hacker" in the name, but it's about a lot of things, and a big focus is on making money. Farming out boring stuff to "the cloud" has been fantastic for making money for pretty much everyone.
      - manigandham 10y ago
        Where are you reading that? All of the GCP load balancers are the best available. There are no hoops to jump through. SNI based TLS is an additional feature that some would like, which is available now by just adding a CDN in front and should solve that need for most. I'm sure anyone here can spin up a haproxy instance, that's not a big deal nor impressive in any way and there are better things to spend time on for most people and companies. Do you write web apps in assembly code or something because you're a "hacker"?
        stephenr 10y ago
        > that's not a big deal So surely it wouldn't take that long then? > there are better things to spend time on Like putting CDN's in front of your load balancers I guess? A TLS terminating proxy that doesn't support SNI in 2017 is like a browser that doesn't support SNI in 2017.
        manigandham 10y ago
        You're just being flippant at this point but here goes: You will never achieve the same reliability, scalability, performance, and security, at the same cost, by doing it yourself. And it's fine to layer 2 services together to get all the functionality needed. That's completely normal - like how you can use multiple APIs to build an app - unless you have a specific scenario, like security regulations, to avoid a managed solution. Maybe building all that means you're a "hacker" but most users are acting on behalf of businesses and there are far better things to spend time on than creating a worse solution to a solved problem.
  - manigandham 10y ago
    This is not basic - load balancing needs to be more reliable than the service behind it, which is hard to do. You can run your own instances with nginx or haproxy but you'll never get to the same reliability, scale and performance without a significant amount of work. Google provides an incredible global load balancer tied into their networking fabric which you can't compete with. Why not use it? Businesses have limited resources and spending them on creating the same functionality at less scale and reliability just to have "control" (whatever that means here) is not worth it.
    - daliwali 10y ago
      Most servers don't need to handle anywhere close to Google traffic and some downtime is acceptable -- the network is more unreliable. Sacrificing 0.001% uptime and "scalability" (whatever that means) is worth it.
      - manigandham 10y ago
        Worth it for what exactly? I'm not sure what tradeoff you're talking about. You would rather spend the time, effort, and money to run your own worse load balancing solution that affects your business instead of clicking a few buttons in the console? Scalability means that you don't have to worry whether it's 10 or 1M reqs/sec. And downtime is not acceptable for us, which is why using a more reliable service makes a difference.
        stephenr 10y ago
        If it does things Google's Load Balancer doesn't do (e.g. TLS SNI) and still does balancing/failover between your backend servers, by definition it isn't worse. > And downtime is not acceptable for us You do know the Google SLA allows load-balancer downtime in excess of 20 minutes a month, right?
        manigandham 10y ago
        Functional parity isn't all that matters. Reliability, security, performance, ops overhead and cost make a big difference. It's a tradeoff which makes sense for probably 99% of the users. And yes, Google's SLA is fine with us, considering they will ultimately be far more reliable than we could be with our own team.
- numbsafari 10y ago
  A CDN might be fine for public, static content, or certain kinds of APIs, but a CDN does nothing for most "transactional" APIs. If you are trying to host a multi-region deployed API, and your customers are evaluating your infrastructure against NIST and other security guidelines and recommendations, a TLS proxy is considered a security problem (go back a few months to CloudFlare's massive data exposure). You want your TLS terminated directly at your own service hosts. In that situation you want an SNI aware LB that simply does host-based routing. You cannot achieve this today with GCPs HTTP(s) LB. Which is a pain, because it's otherwise awesome sauce.
- hosh 10y ago
  > Just use Cloudfront or another CDN in front. This cant be worth the engineering time to build something yourself. It is not worth the time to build something ourselves, but we can't wait much longer. I don't see any SNI support for Google CDN yet. We'd like to keep the data inside the Google network if we can. We don't really need edge caching so much of what a CDN provides other than availability is overkill.
  - manigandham 10y ago
    That's fair. Yes there are bandwidth costs and 1 extra hop, although minimal performance impact - but it is an option available and might be a good stopgap solution until the feature is released.

by hosh 10y ago

manigandham 10y ago

Just use Cloudfront or another CDN in front. This cant be worth the engineering time to build something yourself.

stephenr 10y ago
Load Balancing software is a thing. It exists, waiting for you to install and configure it. For a site called hacker news, its fucking depressing how many people here jump at every possible chance to give up control of the most basic things in their tech stack, for no other reason than "X already runs something similar as SaaS".
- akanet 10y ago
  I don't think I would be so quick to dismiss this sentiment. I run a profitable SaaS business, and every opportunity to give up responsibility results in highly profitable refocusing of effort on the things we do that actually matter. I'd much rather have a team of Google engineers running our LBs than myself.
  - stephenr 10y ago
    This entire thread is about the hoops people are having to jump through to get pretty basic functionality from a load balancer, specifically because they took your approach. I didn't say it can't work for anyone, I said its depressing how it's the default/only approach for so many people who call themselves "hackers".
    - akanet 10y ago
      I think it's tempting to assume that sentiment expressed here is reflective of the majority - everyone whose use case is served well is happy and likely doesn't comment. As for the "hackers" comment - HN might have "Hacker" in the name, but it's about a lot of things, and a big focus is on making money. Farming out boring stuff to "the cloud" has been fantastic for making money for pretty much everyone.
    - manigandham 10y ago
      Where are you reading that? All of the GCP load balancers are the best available. There are no hoops to jump through. SNI based TLS is an additional feature that some would like, which is available now by just adding a CDN in front and should solve that need for most. I'm sure anyone here can spin up a haproxy instance, that's not a big deal nor impressive in any way and there are better things to spend time on for most people and companies. Do you write web apps in assembly code or something because you're a "hacker"?
      - stephenr 10y ago
        > that's not a big deal So surely it wouldn't take that long then? > there are better things to spend time on Like putting CDN's in front of your load balancers I guess? A TLS terminating proxy that doesn't support SNI in 2017 is like a browser that doesn't support SNI in 2017.
        manigandham 10y ago
        You're just being flippant at this point but here goes: You will never achieve the same reliability, scalability, performance, and security, at the same cost, by doing it yourself. And it's fine to layer 2 services together to get all the functionality needed. That's completely normal - like how you can use multiple APIs to build an app - unless you have a specific scenario, like security regulations, to avoid a managed solution. Maybe building all that means you're a "hacker" but most users are acting on behalf of businesses and there are far better things to spend time on than creating a worse solution to a solved problem.
- manigandham 10y ago
  This is not basic - load balancing needs to be more reliable than the service behind it, which is hard to do. You can run your own instances with nginx or haproxy but you'll never get to the same reliability, scale and performance without a significant amount of work. Google provides an incredible global load balancer tied into their networking fabric which you can't compete with. Why not use it? Businesses have limited resources and spending them on creating the same functionality at less scale and reliability just to have "control" (whatever that means here) is not worth it.
  - daliwali 10y ago
    Most servers don't need to handle anywhere close to Google traffic and some downtime is acceptable -- the network is more unreliable. Sacrificing 0.001% uptime and "scalability" (whatever that means) is worth it.
    - manigandham 10y ago
      Worth it for what exactly? I'm not sure what tradeoff you're talking about. You would rather spend the time, effort, and money to run your own worse load balancing solution that affects your business instead of clicking a few buttons in the console? Scalability means that you don't have to worry whether it's 10 or 1M reqs/sec. And downtime is not acceptable for us, which is why using a more reliable service makes a difference.
      - stephenr 10y ago
        If it does things Google's Load Balancer doesn't do (e.g. TLS SNI) and still does balancing/failover between your backend servers, by definition it isn't worse. > And downtime is not acceptable for us You do know the Google SLA allows load-balancer downtime in excess of 20 minutes a month, right?
        manigandham 10y ago
        Functional parity isn't all that matters. Reliability, security, performance, ops overhead and cost make a big difference. It's a tradeoff which makes sense for probably 99% of the users. And yes, Google's SLA is fine with us, considering they will ultimately be far more reliable than we could be with our own team.
numbsafari 10y ago
A CDN might be fine for public, static content, or certain kinds of APIs, but a CDN does nothing for most "transactional" APIs. If you are trying to host a multi-region deployed API, and your customers are evaluating your infrastructure against NIST and other security guidelines and recommendations, a TLS proxy is considered a security problem (go back a few months to CloudFlare's massive data exposure). You want your TLS terminated directly at your own service hosts. In that situation you want an SNI aware LB that simply does host-based routing. You cannot achieve this today with GCPs HTTP(s) LB. Which is a pain, because it's otherwise awesome sauce.
hosh 10y ago
> Just use Cloudfront or another CDN in front. This cant be worth the engineering time to build something yourself. It is not worth the time to build something ourselves, but we can't wait much longer. I don't see any SNI support for Google CDN yet. We'd like to keep the data inside the Google network if we can. We don't really need edge caching so much of what a CDN provides other than availability is overkill.
- manigandham 10y ago
  That's fair. Yes there are bandwidth costs and 1 extra hop, although minimal performance impact - but it is an option available and might be a good stopgap solution until the feature is released.