Hey Christopher
Adding to what my colleague, Abhijeet, said.
1. We plan to ramp traffic to HAProxy very soon where we will heavily rely
on SPOA. In our testing, we are satisfied with SPOE in terms of performance.
The flexibility to write SPOA in any language not only allows us to handle
“complex use cases” like connecting to non-http downstreams, but also helps in
observability – metrics and logging.
2. What is the best alternative to SPOE? Two options that we are aware of –
Write fetchers/converters in lua or write filters in other languages using the
Lua API. In your experience, how do they compare to SPOE in terms of:
* Performance
* Fault isolation
3. As Abhijeet said, can you share a list of issues with SPOE that make it
hard to maintain?
Be it SPOE or an alternate solution that allows us to handle complex use cases
with good performance, fault isolation (as much as possible) and observability,
we will be happy to help develop/maintain it.
- Lokesh
From: Abhijeet Rastogi <abhijeet.1...@gmail.com>
Date: Friday, March 15, 2024 at 8:23 AM
To: Christopher Faulet <cfau...@haproxy.com>
Cc: haproxy@formilux.org <haproxy@formilux.org>
Subject: Re: About the SPOE
Hi Christopher,
Thank you for starting the discussion here.
>Worst, other parts of HAProxy evolved,
especially applets part, making maintenance ever more expensive.
Can we elaborate on what makes maintenance expensive?
>We must be realistic on the subject, there was no real adoption on the SPOE and
this partly explains why no time was invest on it.
My company primarily uses SPOE in cases where we've to connect with
non-http downstreams, for example, connecting to the data layer
(Couchbase etc) that makes the proxy stateless. Other uses-cases are
SSO implementation etc.
We are a new user to HAproxy, with multi-million QPS on HAproxy
already, and we've plans to ramp multiples of that in the coming year
or two.
>Now we are open to discussion on this subject. Let us know your feeling and if
you have any suggestion, we will be happy to talk about it.
Our goal at my company has been to not modify HAproxy core and still
add features to it without running in the same memory space as HAproxy
for safety. Of course, we use config DSL and lua as much as possible,
but it falls short in terms of writing complex business logic.
(non-http downstreams etc).
If it's not SPOE, what is a true replacement? With my limited
knowledge, not a true replacement though, maybe lua filter API and
then write these complex in-flight operations in Rust?
With the learnings from today, what would be the ideal way to replace
it, considering we had engineers to maintain it?
Slightly off-topic, SPOE has its flaws too though. One of our
use-cases is to stream (kafka) HTTP traffic information (cookies,
request data etc) in an efficient fashion and we actually did not use
SPOE as the cost to exchange information was too high. In this
particular case, we ended up streaming data via txn/req variables to
logs instead (ring buffer).
Thanks,
Abhijeet
On Fri, Mar 15, 2024 at 7:10 AM Christopher Faulet <cfau...@haproxy.com> wrote:
>
> Hi all,
>
> It was evoked on the ML by Willy and mentioned in few issues on GH. It is now
> official. The SPOE was marked as deprecated for the 3.0. It is not a pleasant
> announce because it is always an admission of failure to remove a feature.
> Sadly, this filter should be refactored to work properly. It was implemented
> as
> a functional PoC for the 1.7 and since then, no time was invest to improve it
> and make it truly maintainable in time. Worst, other parts of HAProxy evolved,
> especially applets part, making maintenance ever more expensive.
>
> We must be realistic on the subject, there was no real adoption on the SPOE
> and
> this partly explains why no time was invest on it. So we are really sorry for
> users relying on it. But we cannot continue in this direction.
>
> The 3.0 is be an LTS version. It means the SPOE will still be maintained on
> this
> version and lower ones for 5 years. On the 3.1, it will be marked as
> unmaintained and possibly removed if an alternative solution is implemented.
>
> It remains few months before the 3.0 release to change our mind. Maybe this
> announce will be an electroshock to give it a new lease of life. Otherwise it
> is
> time to find an alternative solution based on an existing protocol.
>
> For all 3.0 users, there is now a warning if a SPOE filter is configured. But
> there is also a global option to silent it. To do so,
> "expose-deprecated-directives" must be added in the global section.
>
> Now we are open to discussion on this subject. Let us know your feeling and if
> you have any suggestion, we will be happy to talk about it.
>
> Regards,
> --
> Christopher Faulet
>
--
Cheers,
Abhijeet
(https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fabhi.host%2F&data=05%7C02%7Cljindal%40linkedin.com%7C9a34d3ec1e5e4df77e6e08dc4503e41e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638461130234909653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DiHIdWMoPy%2FcYZVSzrOxKnbrAQKMFeBZgwDAZI%2FmsMw%3D&reserved=0<https://abhi.host/>)
