[HN Gopher] Microsoft YARP
___________________________________________________________________
Microsoft YARP
Author : gokhan
Score : 92 points
Date : 2022-02-20 19:26 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| chaircher wrote:
| "...narp?"
| rafale wrote:
| How does this compare to nginx? Does it support websockets? I
| have an asp.net core websocket based app that need to support
| hundred of thousands concurrent websockets connection. I ll be
| taking a look at this because I don't wanna expose Kestrel
| directly to the internet.
| oleksandr_kot wrote:
| Used it several weeks ago at work in an app which actively uses
| WebSockets. It just works.
| politelemon wrote:
| The main difference I see is that YARP is added right into the
| dotnet project itself. See the getting started :
|
| https://microsoft.github.io/reverse-proxy/articles/getting-s...
|
| From my understanding Kestrel passes request to this.
|
| > The proxy server is implemented a plugin component for
| ASP.NET Core applications. ASP.NET Core servers like Kestrel
| provide the front end for the proxy by listening for http
| requests and then passing them to the proxy for paths that the
| proxy has registered.
| rafale wrote:
| I see. So it can operate in-process? Could in theory be much
| faster than nginx out-of-process model.
| tremon wrote:
| Why would someone need an in-process reverse proxy? I don't
| see what an in-process proxy would add that a request
| routing engine couldn't do. Or is the point that you can
| now add your reverse proxy configuration as just another
| project within the same solution?
| kcb wrote:
| I was assuming more the latter. Also benefit is you can
| extend and customize in C#.
| rafale wrote:
| And you could dynamically and efficiently add/remove web
| apps and endpoints assuming your entire codebase is in
| C#.
| riffic wrote:
| _Yet Another Reverse Proxy_.
|
| Cute.
| sockpuppet69 wrote:
| imwillofficial wrote:
| oneplane wrote:
| Sometimes it feels like Microsoft and/or C#-enjoyers just want to
| re-implement everything that already exists. While having many
| implementations to choose from if you need to select a solution
| to an outstanding problem is great, it makes me wonder why re-
| implementing something with no discernible benefit keeps eating
| time/resources all over the place.
|
| In similar cases of implementing reverse proxies in C, C++, Rust,
| Go and Java, there were generally benefits in various shapes and
| sizes like different security models, performance vs. capability
| trade-offs and integrated vs. specialised solutions. In this
| case, it just seems to be a "we don't want the stuff we didn't
| build ourselves" which is a shame considering the benefits of
| pooling resources on existing implementations would have.
| bob1029 wrote:
| > re-implementing something with no discernible benefit keeps
| eating time/resources all over the place.
|
| > is a shame considering the benefits of pooling resources on
| existing implementations would have.
|
| What exactly would you prefer these developers spend their time
| on instead of this work?
|
| There are a lot of benefits to being able to integrate your own
| reverse proxy directly into your software stack. C# developers
| enjoy these as much as anyone else would.
| jeeeb wrote:
| > There are a lot of benefits to being able to integrate your
| own reverse proxy directly into your software stack. C#
| developers enjoy these as much as anyone else would.
|
| I take this at face value but it would be nice to know what
| the benefits are vs nginx and other off the shelf solutions.
|
| The readme explains the benefit for Microsoft but not how it
| stacks against off the self solutions.
| akshayshah wrote:
| > The readme explains the benefit for Microsoft but not how
| it stacks against off the self solutions.
|
| Totally agree. Seems to me that the main benefit is that
| it's easy to extend in .NET, vs. C/C++/Lua/WASM.
| bob1029 wrote:
| > it would be nice to know what the benefits are vs nginx
| and other off the shelf solutions.
|
| Biggest difference in my view is being able to make
| synchronous blocking calls directly into any arbitrary
| business code in order to determine the fate of a request.
| This can include rule/policy engines as well as auditing &
| tracing frameworks.
| andreypopp wrote:
| Lua in nginx can you get very far in my experience.
| qbasic_forever wrote:
| > What exactly would you prefer these developers spend their
| time on instead of this work?
|
| Delivering value to customers.
| qbasic_forever wrote:
| It's only in the last 5 years that .NET was open sourced and
| made available officially for Linux systems. Up until then most
| C# use was strictly on Windows, and OSS especially for Windows
| server side stuff (IIS, SQL server, etc.) was (and still is)
| pretty rare. I've seen windows server places (Microsoft)
| implement everything from redis, memcached, queue systems,
| prometheus, lucene, DNS servers, to reverse proxies, etc.
| entirely from scratch out of necessity. Years and years of man
| hours going into building and supporting something that would
| be a simple debian package install on Linux.
|
| I have no insight into it but my gut tells me windows server
| exclusive shops are probably dwindling and have long ago
| realized they needed to start moving to Linux, especially now
| that .NET is officially supported there. I think the days of
| reinventing everything in C#/.NET/windows are coming to an end
| fast.
| codeulike wrote:
| Seems like the fact that its built in C# isn't really the main
| point. The main point it that it runs on asp.net infrastructure
| cakoose wrote:
| To clarify, are you saying that:
|
| 1. There are already good reverse proxy libraries in C#?
|
| 2. There are already good reverse proxy libraries in other
| languages?
|
| 3. There are already good reverse proxy _applications_?
|
| If it's #1, then yeah, it would be nice if the ReadMe explained
| why YARP is different. To be fair, they're at least
| consolidating a bunch of efforts within Microsoft:
|
| > We found a bunch of internal teams at Microsoft who were
| either building a reverse proxy for their service or had been
| asking about APIs and tech for building one, so we decided to
| get them all together to work on a common solution, this
| project.
|
| If it's #2, then what do C# developers do? Having to build your
| proxy in another language isn't a deal-breaker, but there are
| advantages to keeping your project/team/company on a single
| language.
|
| (And Microsoft does contribute to Envoy [1][2].)
|
| If it's #3, that only works up to a point. My old team used
| Nginx, which was perfect in the beginning. But over time we
| needed to customize things in ways that were difficult to do
| within Nginx's architecture (either in Lua or in C), leading to
| hackier and hackier solutions. Using a proxy library to build
| exactly what you need can make things much simpler.
|
| [1] https://blog.envoyproxy.io/general-availability-of-envoy-
| on-...
|
| [2] https://techcrunch.com/2020/08/05/microsoft-launches-open-
| se...
| zamalek wrote:
| > But over time we needed to customize things in ways that
| were difficult to do within Nginx's architecture (either in
| Lua or in C),
|
| Yup. Eventually a configuration language becomes a shitty
| programming language, _so why don 't we just use a
| programming language?_
| kristaps wrote:
| Can you share more specifics on what you needed to customize
| that went beyond nginx's capabilities?
| cakoose wrote:
| This was 5+ years ago so I'm a little hazy on the details.
| A lot of it was just plugging into our infrastructure for
| config, service discovery, rate limiting, logging, etc.
|
| - Logging the exact metrics we wanted to our metrics
| service. (We wrote a bunch of Lua code to do this.)
|
| - Loading the set of backend services from Zookeeper. (We
| had a sidecar process that would periodically sync from
| Zookeeper to a config file, then call `nginx reload`.)
|
| - Routing requests to different datacenters based on where
| the user's data was homed. (We had Go libraries to do this,
| and it would have been nice to be able to just call into
| that. I think we ended up putting this functionality in the
| sidecar.)
|
| - Changing the way we streamed a response based on an HTTP
| header from the application. (We ended up writing a C
| module for this.)
|
| - Changing the backend selection algorithm from "least
| connections" to "best of 3 random choices". Nginx added
| support for this in 2018, apparently.
|
| There were ton of things we solved with Lua, which wasn't
| ideal. Since that's the only Lua in our codebase, everyone
| who touches it has to make a mental switch to remember all
| the weird edge cases (as you do with any language), plus
| 1-based array indexes, plus no static types.
|
| Plus, any Lua or C you write has be contorted to fit
| Nginx's multi-stage request/response architecture. If
| you're writing a plugin that is meant to play nice with
| other plugins, then the contortions may be worth it. But
| for us, a proxy library would have given us the freedom to
| write code that was simpler and easier to understand.
|
| The team moved to Envoy after I left:
| https://dropbox.tech/infrastructure/how-we-migrated-
| dropbox-...
| bob1029 wrote:
| > But over time we needed to customize things in ways that
| were difficult to do within Nginx's architecture (either in
| Lua or in C), leading to hackier and hackier solutions. Using
| a proxy library to build exactly what you need can make
| things much simpler.
|
| This is the central argument for me regarding why we don't
| "just use nginx". We actually do use it for some corporate
| websites, but not for our main product.
|
| There is a ton of power hiding here... With a well-supported
| first-party RP framework, how long would it take for a
| determined developer to replicate the most important bits of
| the nginx feature set? Imagine being able to throw a blazor
| dashboard on top of this stuff. Wiring up real-time
| events/metrics would be super trivial if you are even
| remotely interested in learning how the DI system operates.
| Mix in a little bit of SQLite and you could have something I
| may argue provides a better UX than what nginx offers today.
| assttoasstmgr wrote:
| Would your reaction have been different if, instead of
| Microsoft, this article was submitted by some random person
| entitled "Show HN: I built a reverse proxy in C#"?
|
| By your logic, the world should be operating on a single OS,
| with a single web browser, paired with a single web server,
| because why re-implement something that already exists?
| pydry wrote:
| Pretty much every "I built a thing" post is met with the same
| response. MS isnt special.
|
| I think pretty much every open source project that wants to
| be taken seriously needs to compare itself with its
| competitors.
| assttoasstmgr wrote:
| From what I can tell they built a tool for themselves to
| use internally, and open-sourced it. I don't think they
| were looking for approval or to be taken seriously.
|
| Similarly, Igor built nginx to solve a particular problem,
| and I think it was a few years before it went open-source.
|
| I can't imagine most OSS developers have delusions of
| grandeur.
| throwuxiytayq wrote:
| Given that pretty much all of the recent Microsoft's open-
| source projects under the .NET umbrella, including ASP.NET
| Core, have been a resounding success in terms of communiry
| adoption, I don't think they're very shy about comparisons.
|
| I expect some of the comments under this post to age very
| badly.
| AlphaSite wrote:
| It competes with this: https://spring.io/projects/spring-cloud-
| gateway AFAICT.
| mrkurt wrote:
| There aren't a lot of good proxy development frameworks. There
| are decent lower level libraries, and proxy servers with
| limited scriptability.
|
| I've spent the last 4 years at Fly.io wishing for a nice, full
| featured, proxy framework. This looks pretty darn good to me.
| 123pie123 wrote:
| >Sometimes it feels like Microsoft and/or C#-enjoyers just want
| to re-implement everything that already exists
|
| It sometimes feels to me, like a huge percentage of developers
| reinvent the wheel
| civilized wrote:
| There are thousands of Java accounting apps and thousands of
| shitty medical billing websites.
|
| I think most devs are definitely reinventing the wheel for
| the ten thousandth time
| blibble wrote:
| mdasen wrote:
| https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re...
|
| https://aka.ms/aspnet/benchmarks (click on the "1 of 21"
| pagination at the bottom of the page and select "Proxies"). You
| can compare it to nginx, envoy, and haproxy.
| MortenToudahl wrote:
| Ah, beat me to it :-)
| sockpuppet69 wrote:
| Thaxll wrote:
| So this thing is 2x faster than Envoy, something wrong in the
| benchmark probably.
| akshayshah wrote:
| mdasen has already pointed out that "2x" seems to overstate
| the difference by quite a bit. YARP also has a spikier max
| latency, which I'd expect for a GC'ed language.
|
| I don't see a way to choose the benchmarking platform in
| the PowerBI dashboard, so I assume all these numbers were
| collected on Windows. In that case, it doesn't surprise me
| that YARP is faster: Envoy uses libevent for cross-platform
| I/O, but libevent is relatively slow on Windows. It exposes
| Windows-native I/O completion ports as a BSD-style socket
| API, and the implementation is both inherently somewhat
| slow and pushes buffering concerns into the Envoy code.
| Kestrel, YARP's underlying webserver, uses libuv instead.
| libuv is more actively developed (because of Node.js) and
| takes the opposite approach, exposing an IOCP-like API even
| on POSIX systems. Basically, YARP's I/O model is much
| closer to Windows' native model. This Envoy issue[0] is
| really informative if you're interested in the details.
|
| More broadly, the .NET team that builds the Kestrel
| webserver and contributes to YARP and gRPC is full of
| performance heavyweights. I'd start by assuming that the
| benchmarks for their projects are thoughtfully designed.
| Everyone makes mistakes, but start by assuming that James
| Newton-King, David Fowler, and their peers are brilliant
| engineers leading a talented team - because they are.
|
| I say all this as someone who doesn't particularly love
| Windows as a development environment, .NET as a language,
| or Microsoft as a company (quit after just 6 months).
| Credit where credit's due.
|
| [0]: https://github.com/envoyproxy/envoy/issues/4952#issuec
| omment...
|
| Edit: moogly points out that my info on the Kestrel
| implementation is out of date. Mea culpa!
| moogly wrote:
| > Kestrel, YARP's underlying webserver, uses libuv
| instead
|
| Kestrel (as used in ASP.NET) uses a Socket-based
| transport since .NET Core 2.1 The libuv transport was
| marked as obsolete in .NET 5 and has been removed as of
| .NET 6, I believe.
| akshayshah wrote:
| Ah, good to know! I'm barely C#-literate, so the Socket
| docs[0] aren't totally intelligible to me. Somewhere
| under the hood, though, there must be a common
| abstraction sitting in front of the relevant Windows and
| Linux syscalls - did the libuv stuff just move down a few
| layers, or is this using something completely different?
|
| Either way, I'd be shocked if this weren't designed top-
| to-bottom to have excellent performance on Windows.
|
| [0]: https://docs.microsoft.com/en-
| us/dotnet/api/system.net.socke...
| mdasen wrote:
| The benchmarks seem to show YARP doing around 35% more
| requests per second, having around 25% less mean latency,
| 20% less 90th-percentile latency, and 10% less 99th-
| percentile latency for http-http. Moving to https-https,
| it's around 10% more RPS, 10% less mean latency, 15% less
| 90th-percentile latency, while Envoy has 10% better 99th-
| percentile latency.
|
| I'm not sure where you're seeing 2x, but it might be the
| scale of one of the charts you're looking at being
| deceiving or I'm not looking at the same test you're
| looking at.
| davinci26 wrote:
| I don't think anyone is using Envoy for peak performance.
| It is slower than haproxy and nginx but it has other
| advantages:
|
| * it is super extensible * truly open-source and open to
| contributions by companies * the codebase is really modern
| and easy to reason about
| christophilus wrote:
| I'm on mobile, and that page is very slow and very tiny.
| Anyone got a TL;DR?
| blibble wrote:
| 50% slower than nginx and haproxy
| MortenToudahl wrote:
| https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re...
|
| More here: https://github.com/microsoft/reverse-proxy/issues/40
|
| It was hard to read on my phone, so I don't know if it shows
| what you want to see.
| [deleted]
| [deleted]
| [deleted]
| kwertyoowiyop wrote:
| They should've called it SNAP: Somebody Needs A Promotion
| murrayb wrote:
| It's a reverse proxy so it's "pray", not exactly confidence
| inspiring! :-)
| coredog64 wrote:
| What are the odds that there's an AWS employee that will
| backronym this as part of their L7 promo doc for 2023?
| bob1029 wrote:
| I'm glad to see Microsoft supporting more low-level magic like
| this. I've written my own version of ReverseProxyMiddleware more
| times than I can recall... The most painful parts were always
| around translating between HttpClient and HttpContext. Looks like
| Microsoft abstracted this exact concern away under the
| IHttpForwarder and ForwarderHttpClientContext types.
|
| Looking at the docs around this, I'd probably start w/ Direct
| Forwarding so I have more control over how things route:
|
| https://microsoft.github.io/reverse-proxy/articles/direct-fo...
| Shadonototra wrote:
| anything that requires a giant runtime to run is a big NO for me
|
| that's why languages like GO makes more sense for that kind of
| use cases
|
| microsoft not wanting to support CoreRT back in the days was
| their biggest mistake ever, shame on the people at microsoft who
| lobbied against it, shame!
| opan wrote:
| MIT license, nice.
___________________________________________________________________
(page generated 2022-02-20 23:00 UTC)