Neat! We use a similar Go based proxy for our tier 1 ingress and routing at Walmart Labs (global eCommerce), with Lua/Go plugins for edge/serverless style backends. It is a custom/proprietary codebase but the tech stack has served us very well. Great to see open source projects with similar use cases. I may have to play with this for use in some personal/hobby projects.
We skipper maintainers don't want to really comment on that, because it is very likely that if you do your own benchmarks you show only the good parts and not the bad parts.
From our benchmarks we can outperform nginx in the pure routing case, while nginx will outperform skipper in the pure sendfile case. HAproxy we did not tested, but I would bet it will be not different from the nginx case. IMO: in general use skipper as microservice router and nginx as streaming router that serves a lot of pictures or videos.
The main use case we tested with was for a data analytics pipeline to ingest telemetry events from video games, but would have been generally used across all our services, target was about 1m/RPS for our load test. The CoreOS ALB controller for K8s out performed it significantly (I don't have the exact stats now), albeit it's not as feature rich as Skipper.
We are looking at it to do dynamic routing from our system to the Internet and back. That means terminate the request on a client (server), route it to an exit node where it's more appropriate (for instance to bypass GEO restriction) and then send the response back to the origin.
We are looking at some other alternatives, like envoy + istio + gloo, but skipper seems more contained and less container depended.
I would be happy to help in case you see performance or scaling issues with skipper.
If you like join our Gopher slack channel #skipper in gophers.slack.com. https://invite.slack.golangbridge.org/
Can you share more information with us in a gh issue https://github.com/zalando/skipper/issues?
I am interested in getting details: payload size, resource configuration and access patterns in your test case.
Just to note, the CoreOS ALB controller [0] has very little in common with the design of Skipper.
The ALB controller configures Amazon Cloud "Application Load Balancers" and adds a Kubernetes service as the upstream. There's nothing in the data path.
13 comments
[ 40.3 ms ] story [ 494 ms ] threadFrom our benchmarks we can outperform nginx in the pure routing case, while nginx will outperform skipper in the pure sendfile case. HAproxy we did not tested, but I would bet it will be not different from the nginx case. IMO: in general use skipper as microservice router and nginx as streaming router that serves a lot of pictures or videos.
Feature wise we have a lot of things to add as HTTP router that you want to run in front of your microservices, please also see our docs: https://opensource.zalando.com/skipper/ Additionally we build a lot of Kubernetes integrations,for example https://github.com/zalando-incubator/stackset-controller which reduces boilerplate and enables you to do automated blue-green deployments and https://github.com/zalando-incubator/kube-metrics-adapter which enables you to do HPAs with custom metrics, for example hpa based on skipper route request per second.
We are looking at it to do dynamic routing from our system to the Internet and back. That means terminate the request on a client (server), route it to an exit node where it's more appropriate (for instance to bypass GEO restriction) and then send the response back to the origin.
We are looking at some other alternatives, like envoy + istio + gloo, but skipper seems more contained and less container depended.
Skipper serves well microservice workloads for Zalando and other companies, for example shopgun https://medium.com/@roffe/kubernetes-in-production-shopgun-2....
The ALB controller configures Amazon Cloud "Application Load Balancers" and adds a Kubernetes service as the upstream. There's nothing in the data path.
[0] Now adopted by SIG-AWS as https://github.com/kubernetes-sigs/aws-alb-ingress-controlle...