rogerdonut

Joined 9 years ago

Karma

Submissions

Member since

Jun 27

View on Hacker News

Recent submissions

Comment · 5 years ago

HAProxy can as well (as well as listen on unix sockets)

HAProxyConf 2021 Call for Papers haproxy.com

2 rogerdonut 5 years ago 0 comments

Comment · 5 years ago

HAProxy Technologies | Pre-Sales, Software, & Systems Engineers, Technical Marketing Engineer | Waltham, MA | Paris, France | REMOTE

HAProxy Technologies is the company behind the world's fastest and most widely used open-source software load balancer.

- Technical Marketing Engineer: We are looking for a Technical Marketing Engineer that can aid in creating and promoting technical content. This position requires a unique combination of technical understanding, a high level of creativity, attention to detail and eagerness to learn, as well as the goal to teach others. Basic Linux experience is a must. An ideal candidate has real world experience in a DevOps or SysAdmin environment (bonus if you have programming exp.)

- Pre-Sales Engineer We are looking for a skilled Pre-Sales Engineer with in-depth knowledge in Linux who will help to expand our client base. Experience with load balancing and networking is a requirement.

- C: We are looking to reinforce the development team of HAProxy and are looking for developers who have solid skills in Shell, C, HTTP, TCP/IP and Git. Knowledge of cloud environments is a plus. We are looking for people who are not afraid of patching the Linux Kernel and who can quickly become autonomous.

- Golang: We are looking for Go developers with 2+ years of experience in Kubernetes and Cloud environments, as well as load balancing. A Bachelors or higher degree in IT is desirable. If you want to contribute to the software enabling performance and reliability of some of the largest websites on the internet.

- Senior Systems Engineer: We are seeking Senior Systems Engineers (Linux) to work out of our Waltham, MA office or remotely in the EST/CST/MST/PST time zones. Knowledge of HAProxy is a plus.

Please send cover letter and resume to [email protected]

Comment · 5 years ago

While I have not tested this specific use case, I would start by exploring map files [1] and/or stick tables [2]. Map files can be updated on-the-fly through the HAProxy Runtime API. With stick tables you can persist a session/client based on anything found within the request headers, which would include a users session id.

[1] https://www.haproxy.com/blog/introduction-to-haproxy-maps/

[2] https://www.haproxy.com/blog/introduction-to-haproxy-stick-t...

Comment · 5 years ago

IMO you would use OpenResty as a web server and HAProxy as a load balancer in front of it. HAProxy focuses on being a high-performance load balancer. OpenResty is built ontop of NGINX and many of the load balancing features in NGINX are locked behind their "Plus" product, all of which are provided by default within HAProxy. In order to take advantage of these features in OpenResty (such as active health checking and DNS service discovery) you would need to use Lua scripts where in HAProxy they are implemented in the core.

Comment · 5 years ago

Thanks for the feedback. I've provided a few replies below but I think you have made some great points and I will share them internally.

> - the site does not do a good job of describing the products and what they do.

The page does lead off by telling you it is a software load balancer, but I agree, we can do a better job of giving more information on the product itself. Most people who pursue HAProxy Enterprise are already familiar with HAProxy. With that said, we're actually working on a complete overhaul to this page and I believe the new version will address this.

> - it is hard to find requirements from the first page.

This is just a reference point and typically organizations are working closely with a sales engineer.

> - is there a simpler HA setup than the 3 layer one here:

A simpler version is found under active/standby here [1]

[1] https://www.haproxy.com/documentation/hapee/2-2r1/high-avail...

Comment · 5 years ago

I have not tested that use case but I do not think so. It has the ability to parse FIX tag values and make routing decisions from the initial Logon message.

Comment · 5 years ago

It has the ability to route by FIX tags. You can find an example here [1]

[1] https://www.haproxy.com/blog/haproxy-enterprise-2-3-and-hapr...

Comment · 5 years ago

You can pass along timing data from every aspect of the request [1] currently there are approximately 20 events supported. You can also send over just about anything that can be stored within an HAProxy variable / header through a tag. Here's an example configuration for HAProxy (simple) [2] (advanced) [3] and the OpenTracing specific configuration (simple) [4] (advanced) [5]. I've included both simple and advanced configurations.

[1] https://github.com/haproxy/haproxy/blob/master/addons/ot/REA...

[2] https://github.com/haproxy/haproxy/blob/master/addons/ot/tes...

[3] https://github.com/haproxy/haproxy/blob/master/addons/ot/tes...

[4] https://github.com/haproxy/haproxy/blob/master/addons/ot/tes...

[5] https://github.com/haproxy/haproxy/blob/master/addons/ot/tes...

Comment · 5 years ago

Well said, to add to this, HAProxy is also closing the gap on convenience with its recent addition of AWS EC2 service discovery [1] and Consul service discovery integrations [2].

[1] https://www.haproxy.com/blog/announcing-haproxy-data-plane-a...

[2] https://www.haproxy.com/blog/announcing-haproxy-data-plane-a...

Comment · 5 years ago

Author of the blog post here, happy to answer any questions about this release.

Comment · 5 years ago

disclaimer: I work at HAProxy Technologies

More control/flexibility (i.e. cloud provider usually gives you a limited number of "checkboxes" that they want you to be able to modify), generally better observability (HAProxy timing metrics [1] and session state at disconnection codes [2] are very helpful for debugging), and granular control over timeouts [3]. You also get builtin rate limiting [4], which from what I have seen with most cloud load balancers usually requires an up-charge through their "WAF" product.

Better health checking, circuit breaking, and layer4/layer7 retries [5].

Another consideration is whether you have spiky traffic patterns. For AWS load balancers at least, they need time to "warm up" to larger traffic levels. If you manage your own load balancing tier you can scale on demand.