Date   

Re: peanut-gallery thoughts about GRPC

Brian Grant
 

+Varun and Jayant to answer that

On Fri, Oct 21, 2016 at 10:57 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

I'd like to understand why gRPC doesn't work with HTTP 1.x


On Fri, 21 Oct 2016, 18:45 Ben Sigelman via cncf-toc, <cncf-toc@...> wrote:
Hi all,

"I am not on the TOC, but" I did want to share a few thoughts about GRPC per the call the other day.

I was recently at one of those moderated VC dinners where everyone gets put on the spot to say something "insightful" (sic) – I'm sure we all know the scenario. Anyway, we had to go around the table and talk about "the one OSS project that's poised to change the way the industry functions". There were lots of mentions of Docker, k8s, etc, and for good reason. I had the bad luck of being last and felt like it wasn't useful to just +1 someone else's comment, and I realized that GRPC was in many ways an excellent answer.

Varun alluded to this in his presentation, but to restate it in different words: the value of an RPC system is mostly not actually about the RPC... it's the service discovery, client-side load balancing, well-factored monitoring, context propagation, and so on.

In that way, a high-quality RPC system is arguably the lynchpin of the "user-level OS" that sits just below the application code but above the actual (kernel) syscalls. An alternative approach moves things like RPC into its own process (a la linkerd(*)) and I think that makes sense in certain situations... but when the RPC system depends on data from its host process beyond the RPC payload and peer identity (which is often the case for more sophisticated microservice deployments), OR when "throughput matters" and extra copies are unacceptable, an in-process RPC subsystem is the right approach.

As for whether GRPC is the right in-process RPC system to incubate: I think that's a no-brainer. It has good momentum, the code is of a much higher quality and works in more languages than the alternatives, and Google's decision to adopt it internally will help to ensure that it works within scaled-out systems (both architecturally and in terms of raw performance). Apache Thrift moves quite slowly in my experience and has glaring problems in many languages; Finagle is mature but is limited to JVM (and perhaps bites off more than it can chew at times); other entrants that I'm aware of don't have a strong community behind them.

So yes, this is just an enthusiastic +1 from me. Hope the above makes sense and isn't blindingly obvious. :)

Comments / disagreements welcome –
Ben

(*): re linkerd specifically: I am a fan, and IMO this is a "both/and" situation, not "either/or"...

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: peanut-gallery thoughts about GRPC

alexis richardson
 

I'd like to understand why gRPC doesn't work with HTTP 1.x


On Fri, 21 Oct 2016, 18:45 Ben Sigelman via cncf-toc, <cncf-toc@...> wrote:
Hi all,

"I am not on the TOC, but" I did want to share a few thoughts about GRPC per the call the other day.

I was recently at one of those moderated VC dinners where everyone gets put on the spot to say something "insightful" (sic) – I'm sure we all know the scenario. Anyway, we had to go around the table and talk about "the one OSS project that's poised to change the way the industry functions". There were lots of mentions of Docker, k8s, etc, and for good reason. I had the bad luck of being last and felt like it wasn't useful to just +1 someone else's comment, and I realized that GRPC was in many ways an excellent answer.

Varun alluded to this in his presentation, but to restate it in different words: the value of an RPC system is mostly not actually about the RPC... it's the service discovery, client-side load balancing, well-factored monitoring, context propagation, and so on.

In that way, a high-quality RPC system is arguably the lynchpin of the "user-level OS" that sits just below the application code but above the actual (kernel) syscalls. An alternative approach moves things like RPC into its own process (a la linkerd(*)) and I think that makes sense in certain situations... but when the RPC system depends on data from its host process beyond the RPC payload and peer identity (which is often the case for more sophisticated microservice deployments), OR when "throughput matters" and extra copies are unacceptable, an in-process RPC subsystem is the right approach.

As for whether GRPC is the right in-process RPC system to incubate: I think that's a no-brainer. It has good momentum, the code is of a much higher quality and works in more languages than the alternatives, and Google's decision to adopt it internally will help to ensure that it works within scaled-out systems (both architecturally and in terms of raw performance). Apache Thrift moves quite slowly in my experience and has glaring problems in many languages; Finagle is mature but is limited to JVM (and perhaps bites off more than it can chew at times); other entrants that I'm aware of don't have a strong community behind them.

So yes, this is just an enthusiastic +1 from me. Hope the above makes sense and isn't blindingly obvious. :)

Comments / disagreements welcome –
Ben

(*): re linkerd specifically: I am a fan, and IMO this is a "both/and" situation, not "either/or"...

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


peanut-gallery thoughts about GRPC

Ben Sigelman
 

Hi all,

"I am not on the TOC, but" I did want to share a few thoughts about GRPC per the call the other day.

I was recently at one of those moderated VC dinners where everyone gets put on the spot to say something "insightful" (sic) – I'm sure we all know the scenario. Anyway, we had to go around the table and talk about "the one OSS project that's poised to change the way the industry functions". There were lots of mentions of Docker, k8s, etc, and for good reason. I had the bad luck of being last and felt like it wasn't useful to just +1 someone else's comment, and I realized that GRPC was in many ways an excellent answer.

Varun alluded to this in his presentation, but to restate it in different words: the value of an RPC system is mostly not actually about the RPC... it's the service discovery, client-side load balancing, well-factored monitoring, context propagation, and so on.

In that way, a high-quality RPC system is arguably the lynchpin of the "user-level OS" that sits just below the application code but above the actual (kernel) syscalls. An alternative approach moves things like RPC into its own process (a la linkerd(*)) and I think that makes sense in certain situations... but when the RPC system depends on data from its host process beyond the RPC payload and peer identity (which is often the case for more sophisticated microservice deployments), OR when "throughput matters" and extra copies are unacceptable, an in-process RPC subsystem is the right approach.

As for whether GRPC is the right in-process RPC system to incubate: I think that's a no-brainer. It has good momentum, the code is of a much higher quality and works in more languages than the alternatives, and Google's decision to adopt it internally will help to ensure that it works within scaled-out systems (both architecturally and in terms of raw performance). Apache Thrift moves quite slowly in my experience and has glaring problems in many languages; Finagle is mature but is limited to JVM (and perhaps bites off more than it can chew at times); other entrants that I'm aware of don't have a strong community behind them.

So yes, this is just an enthusiastic +1 from me. Hope the above makes sense and isn't blindingly obvious. :)

Comments / disagreements welcome –
Ben

(*): re linkerd specifically: I am a fan, and IMO this is a "both/and" situation, not "either/or"...


RFC: Project Proposal for Fluentd

Chris Aniszczyk
 

At yesterday's TOC meeting, we discussed formalizing a Fluentd project proposal after having a great experience collaborating with the Fluentd community:

For the TOC and wider CNCF community, please take a look at the proposal (https://github.com/cncf/toc/pull/20/files) and make any comments/suggestions on the PR.

If there aren't any major issues, we will call for a formal vote towards the end of next week.

Thanks!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] CNCF Code of Conduct

Jonathan Boulle <jonathan.boulle@...>
 

Yes

On 20 October 2016 at 17:12, Benjamin Hindman via cncf-toc <cncf-toc@...> wrote:
Yes.

On Thu, Oct 20, 2016 at 7:59 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
From yesterday's TOC meeting, we had discussion around adopting a code of conduct for the CNCF community. We decided to go with what the k8s community has already established:

The raw text of the CNCF code of conduct is here:

This is a call to formalize the Code of Conduct, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

Watch the Video .See how DC/OS elastically runs
containerized apps and data services
 

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: [VOTE] CNCF Code of Conduct

Benjamin Hindman
 

Yes.

On Thu, Oct 20, 2016 at 7:59 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
From yesterday's TOC meeting, we had discussion around adopting a code of conduct for the CNCF community. We decided to go with what the k8s community has already established:

The raw text of the CNCF code of conduct is here:

This is a call to formalize the Code of Conduct, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

Watch the Video .See how DC/OS elastically runs
containerized apps and data services
 


Re: [VOTE] CNCF Code of Conduct

Brian Grant
 

YES


Re: [VOTE] CNCF Code of Conduct

alexis richardson
 

Yes


On Thu, 20 Oct 2016, 15:59 Chris Aniszczyk via cncf-toc, <cncf-toc@...> wrote:
From yesterday's TOC meeting, we had discussion around adopting a code of conduct for the CNCF community. We decided to go with what the k8s community has already established:

The raw text of the CNCF code of conduct is here:

This is a call to formalize the Code of Conduct, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


[VOTE] CNCF Code of Conduct

Chris Aniszczyk
 

From yesterday's TOC meeting, we had discussion around adopting a code of conduct for the CNCF community. We decided to go with what the k8s community has already established:

The raw text of the CNCF code of conduct is here:

This is a call to formalize the Code of Conduct, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


DRAFT slides for TOC call tomorrow

alexis richardson
 

All,

Slides are here -
https://docs.google.com/presentation/d/1xbMsdJdLZzokm8Lf4-S4lr5HauOWOs46V9XSbh011ig/edit#slide=id.gd5ae4e962_2_136

Expected changes:
- gRPC slides to be added
- some mods on End User Ref Arch

Comments to me on list please.

a


Re: FYI: OpenTracing formally joins CNCF!

Julius Volz
 

Congrats from the Prometheus side and welcome :)

On Tue, Oct 11, 2016 at 11:59 PM, Ben Sigelman via cncf-toc <cncf-toc@...> wrote:
Thanks, Chris and the TOC... the OpenTracing folks are excited about this! Hopefully we'll have the opportunity to chat in person at Kubecon next month.

Best wishes,
Ben


On Tue, Oct 11, 2016 at 12:48 PM, Chris Aniszczyk <caniszczyk@linuxfoundation.org> wrote:
I just wanted to let people know that OpenTracing has formally joined:

Thank you CNCF TOC and community members for commentary/voting!

We will be working with the OpenTracing community over the next few weeks to get them fully on board. The OpenTracing community also plans to be at CloudNativeCon/KubeCon (http://events.linuxfoundation.org/events/cloudnativecon) in about a month and we will make sure there is space for collaboration for those that are interested in tracing topics!

Anyways, here's a warm welcome to the OpenTracing community for joining CNCF!

If you have any questions, feel free to reach out!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: FYI: OpenTracing formally joins CNCF!

Ben Sigelman
 

Thanks, Chris and the TOC... the OpenTracing folks are excited about this! Hopefully we'll have the opportunity to chat in person at Kubecon next month.

Best wishes,
Ben


On Tue, Oct 11, 2016 at 12:48 PM, Chris Aniszczyk <caniszczyk@...> wrote:
I just wanted to let people know that OpenTracing has formally joined:

Thank you CNCF TOC and community members for commentary/voting!

We will be working with the OpenTracing community over the next few weeks to get them fully on board. The OpenTracing community also plans to be at CloudNativeCon/KubeCon (http://events.linuxfoundation.org/events/cloudnativecon) in about a month and we will make sure there is space for collaboration for those that are interested in tracing topics!

Anyways, here's a warm welcome to the OpenTracing community for joining CNCF!

If you have any questions, feel free to reach out!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: FYI: OpenTracing formally joins CNCF!

alexis richardson
 

Excellent!


On Tue, 11 Oct 2016, 20:48 Chris Aniszczyk via cncf-toc, <cncf-toc@...> wrote:
I just wanted to let people know that OpenTracing has formally joined:

Thank you CNCF TOC and community members for commentary/voting!

We will be working with the OpenTracing community over the next few weeks to get them fully on board. The OpenTracing community also plans to be at CloudNativeCon/KubeCon (http://events.linuxfoundation.org/events/cloudnativecon) in about a month and we will make sure there is space for collaboration for those that are interested in tracing topics!

Anyways, here's a warm welcome to the OpenTracing community for joining CNCF!

If you have any questions, feel free to reach out!

--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


FYI: OpenTracing formally joins CNCF!

Chris Aniszczyk
 

I just wanted to let people know that OpenTracing has formally joined:

Thank you CNCF TOC and community members for commentary/voting!

We will be working with the OpenTracing community over the next few weeks to get them fully on board. The OpenTracing community also plans to be at CloudNativeCon/KubeCon (http://events.linuxfoundation.org/events/cloudnativecon) in about a month and we will make sure there is space for collaboration for those that are interested in tracing topics!

Anyways, here's a warm welcome to the OpenTracing community for joining CNCF!

If you have any questions, feel free to reach out!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: linkerd

Louis Ryan <lryan@...>
 

FWIW I kicked off a thread about service meshes on the Network-SIG mailing list to gauge how those folks feel about making improvements to the k8s config model to facilitate solutions like Linkerd.


On Thu, Oct 6, 2016 at 2:41 PM, Louis Ryan <lryan@...> wrote:
@Alexis,

For taxation overheads as a strawman

- a simple HTTP/1.1 roundtrip latency percentile distribution at 10^n (n = 2..5) qps with a 4k response payload
- CPU time measurement of the proxy under these loads
- RSS size under load

Bonus points for doing the same with HTTP2.

As William mentions having good LB & other network function control improves utilization & latency more holistically throughout the cluster but I do think these numbers will be helpful for folks

On Thu, Oct 6, 2016 at 12:06 PM, William Morgan <william@...> wrote:
We have HTTP/2 in alpha. Gory details here: https://github.com/BuoyantIO/linkerd/issues/174

Performance: a heady topic. That post is still accurate. Note that it's focused on a sidecar / low-mem configuration--as I'm sure you know, the JVM exhibits a, shall we say, "complex" relationship between memory footprint, CPU, throughput, and latency, and changing constraints can dramatically change the resource profile. (This complexity is not ideal for us, of course, but it's a result of a conscious decision to go with production-tested Finagle as opposed to starting with fresh code--just to give you context.)

E.g. the K8s configs in our recent Kubernetes post deploy linkerd as a DaemonSet--allowing us to amortize resource cost per node rather than per process, which gives us more breathing room--at the expense of a Horrible Hack to determine the node-local linkerd.

Finally, our assertion is that, with better load-balancing and flow control, end-to-end tail latencies can actually be *reduced* even when introducing a per-hop cost--though I'll admit that we don't have a nice experimental setup to back this up yet.

HTH,

-William

On Thu, Oct 6, 2016 at 10:59 AM, Brian Grant <briangrant@...> wrote:
Thanks for that additional information, William.

Are there plans for linkerd to support HTTP2?

Is the most recent performance and overhead data available that in https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/?


On Wed, Oct 5, 2016 at 6:38 PM, William Morgan <william@...> wrote:
(adding Oliver, linkerd's maintainer)

Hi Brian,

Good point about Amalgam8, I should have mentioned them. Also maybe Netflix's Prana?

In my mind Traefik, Vulcand, etc. are largely targeted at ingress / "API gateway" use cases. Whereas linkerd, Envoy, Amalgam8, and Prana are focused explicitly on service-to-service communication. Not 100% familiar with all of those projects so I hope that's not a gross mischaracterization.

Differentiating features / advantages of linkerd:
  • Focused on production-tested / used-in-anger code. Sticking close to Finagle, not writing our own load-balancing, etc. This stuff is hard to get right, tons of edge cases, etc. E.g. what happens when service discovery down? When it's up, but it's lying? Etc.
  • Production users across the globe (see below), lots more on the way.
  • Plugin architecture, tons of integrations, explicitly easy to drop in custom stuff.
  • Routing layer (again, used in prod) that is extremely powerful and decouples routing topology from traffic-serving topology.
  • Focus on modern operational affordances, e.g. retry budgets and deadlines over retry policies and timeouts.
  • Lots of contributors, active community and friendly Slack!
Current real-life prod users that we know of (and can talk about--some we can't) are Monzo (UK), Quid (US), Douban (CN), CentralApp (EU), NCBI (US). Lots of other companies in various staging / QA environments that we're tracking and helping to productionize. Of course open source is a funny thing and people will occasionally drop into the Slack and say "so, I've been running linkerd in prod for a few weeks and I noticed this one thing..." so we don't have a complete picture.

Let me know if that's helpful. Happy to go into lots more detail.

Also, thanks for having me this morning, was really fun to present and you have all been super friendly and supportive!




-William

On Wed, Oct 5, 2016 at 5:40 PM, Brian Grant <briangrant@...> wrote:
Hi, William. You briefly mentioned other similar proxies, such as Envoy. What do you see as linkerd's differentiating features or advantages compared to the others (Envoy, Traefik, Amalgam8)?

Also, are any of your users using linkerd in production?







Re: linkerd

alexis richardson
 

thanks Louis, that is helpful



On Thu, Oct 6, 2016 at 10:41 PM, Louis Ryan via cncf-toc
<cncf-toc@...> wrote:
@Alexis,

For taxation overheads as a strawman

- a simple HTTP/1.1 roundtrip latency percentile distribution at 10^n (n =
2..5) qps with a 4k response payload
- CPU time measurement of the proxy under these loads
- RSS size under load

Bonus points for doing the same with HTTP2.

As William mentions having good LB & other network function control improves
utilization & latency more holistically throughout the cluster but I do
think these numbers will be helpful for folks

On Thu, Oct 6, 2016 at 12:06 PM, William Morgan <william@...> wrote:

We have HTTP/2 in alpha. Gory details here:
https://github.com/BuoyantIO/linkerd/issues/174

Performance: a heady topic. That post is still accurate. Note that it's
focused on a sidecar / low-mem configuration--as I'm sure you know, the JVM
exhibits a, shall we say, "complex" relationship between memory footprint,
CPU, throughput, and latency, and changing constraints can dramatically
change the resource profile. (This complexity is not ideal for us, of
course, but it's a result of a conscious decision to go with
production-tested Finagle as opposed to starting with fresh code--just to
give you context.)

E.g. the K8s configs in our recent Kubernetes post deploy linkerd as a
DaemonSet--allowing us to amortize resource cost per node rather than per
process, which gives us more breathing room--at the expense of a Horrible
Hack to determine the node-local linkerd.

Finally, our assertion is that, with better load-balancing and flow
control, end-to-end tail latencies can actually be *reduced* even when
introducing a per-hop cost--though I'll admit that we don't have a nice
experimental setup to back this up yet.

HTH,

-William

On Thu, Oct 6, 2016 at 10:59 AM, Brian Grant <briangrant@...>
wrote:

Thanks for that additional information, William.

Are there plans for linkerd to support HTTP2?

Is the most recent performance and overhead data available that in
https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/?


On Wed, Oct 5, 2016 at 6:38 PM, William Morgan <william@...>
wrote:

(adding Oliver, linkerd's maintainer)

Hi Brian,

Good point about Amalgam8, I should have mentioned them. Also maybe
Netflix's Prana?

In my mind Traefik, Vulcand, etc. are largely targeted at ingress / "API
gateway" use cases. Whereas linkerd, Envoy, Amalgam8, and Prana are focused
explicitly on service-to-service communication. Not 100% familiar with all
of those projects so I hope that's not a gross mischaracterization.

Differentiating features / advantages of linkerd:

Focused on production-tested / used-in-anger code. Sticking close to
Finagle, not writing our own load-balancing, etc. This stuff is hard to get
right, tons of edge cases, etc. E.g. what happens when service discovery
down? When it's up, but it's lying? Etc.
Production users across the globe (see below), lots more on the way.
Plugin architecture, tons of integrations, explicitly easy to drop in
custom stuff.
Routing layer (again, used in prod) that is extremely powerful and
decouples routing topology from traffic-serving topology.
Focus on modern operational affordances, e.g. retry budgets and
deadlines over retry policies and timeouts.
Lots of contributors, active community and friendly Slack!

Current real-life prod users that we know of (and can talk about--some
we can't) are Monzo (UK), Quid (US), Douban (CN), CentralApp (EU), NCBI
(US). Lots of other companies in various staging / QA environments that
we're tracking and helping to productionize. Of course open source is a
funny thing and people will occasionally drop into the Slack and say "so,
I've been running linkerd in prod for a few weeks and I noticed this one
thing..." so we don't have a complete picture.

Let me know if that's helpful. Happy to go into lots more detail.

Also, thanks for having me this morning, was really fun to present and
you have all been super friendly and supportive!




-William

On Wed, Oct 5, 2016 at 5:40 PM, Brian Grant <briangrant@...>
wrote:

Hi, William. You briefly mentioned other similar proxies, such as
Envoy. What do you see as linkerd's differentiating features or advantages
compared to the others (Envoy, Traefik, Amalgam8)?

Also, are any of your users using linkerd in production?

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: linkerd

Louis Ryan <lryan@...>
 

@Alexis,

For taxation overheads as a strawman

- a simple HTTP/1.1 roundtrip latency percentile distribution at 10^n (n = 2..5) qps with a 4k response payload
- CPU time measurement of the proxy under these loads
- RSS size under load

Bonus points for doing the same with HTTP2.

As William mentions having good LB & other network function control improves utilization & latency more holistically throughout the cluster but I do think these numbers will be helpful for folks

On Thu, Oct 6, 2016 at 12:06 PM, William Morgan <william@...> wrote:
We have HTTP/2 in alpha. Gory details here: https://github.com/BuoyantIO/linkerd/issues/174

Performance: a heady topic. That post is still accurate. Note that it's focused on a sidecar / low-mem configuration--as I'm sure you know, the JVM exhibits a, shall we say, "complex" relationship between memory footprint, CPU, throughput, and latency, and changing constraints can dramatically change the resource profile. (This complexity is not ideal for us, of course, but it's a result of a conscious decision to go with production-tested Finagle as opposed to starting with fresh code--just to give you context.)

E.g. the K8s configs in our recent Kubernetes post deploy linkerd as a DaemonSet--allowing us to amortize resource cost per node rather than per process, which gives us more breathing room--at the expense of a Horrible Hack to determine the node-local linkerd.

Finally, our assertion is that, with better load-balancing and flow control, end-to-end tail latencies can actually be *reduced* even when introducing a per-hop cost--though I'll admit that we don't have a nice experimental setup to back this up yet.

HTH,

-William

On Thu, Oct 6, 2016 at 10:59 AM, Brian Grant <briangrant@...> wrote:
Thanks for that additional information, William.

Are there plans for linkerd to support HTTP2?

Is the most recent performance and overhead data available that in https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/?


On Wed, Oct 5, 2016 at 6:38 PM, William Morgan <william@...> wrote:
(adding Oliver, linkerd's maintainer)

Hi Brian,

Good point about Amalgam8, I should have mentioned them. Also maybe Netflix's Prana?

In my mind Traefik, Vulcand, etc. are largely targeted at ingress / "API gateway" use cases. Whereas linkerd, Envoy, Amalgam8, and Prana are focused explicitly on service-to-service communication. Not 100% familiar with all of those projects so I hope that's not a gross mischaracterization.

Differentiating features / advantages of linkerd:
  • Focused on production-tested / used-in-anger code. Sticking close to Finagle, not writing our own load-balancing, etc. This stuff is hard to get right, tons of edge cases, etc. E.g. what happens when service discovery down? When it's up, but it's lying? Etc.
  • Production users across the globe (see below), lots more on the way.
  • Plugin architecture, tons of integrations, explicitly easy to drop in custom stuff.
  • Routing layer (again, used in prod) that is extremely powerful and decouples routing topology from traffic-serving topology.
  • Focus on modern operational affordances, e.g. retry budgets and deadlines over retry policies and timeouts.
  • Lots of contributors, active community and friendly Slack!
Current real-life prod users that we know of (and can talk about--some we can't) are Monzo (UK), Quid (US), Douban (CN), CentralApp (EU), NCBI (US). Lots of other companies in various staging / QA environments that we're tracking and helping to productionize. Of course open source is a funny thing and people will occasionally drop into the Slack and say "so, I've been running linkerd in prod for a few weeks and I noticed this one thing..." so we don't have a complete picture.

Let me know if that's helpful. Happy to go into lots more detail.

Also, thanks for having me this morning, was really fun to present and you have all been super friendly and supportive!




-William

On Wed, Oct 5, 2016 at 5:40 PM, Brian Grant <briangrant@...> wrote:
Hi, William. You briefly mentioned other similar proxies, such as Envoy. What do you see as linkerd's differentiating features or advantages compared to the others (Envoy, Traefik, Amalgam8)?

Also, are any of your users using linkerd in production?






Re: linkerd

William Morgan
 

We have HTTP/2 in alpha. Gory details here: https://github.com/BuoyantIO/linkerd/issues/174

Performance: a heady topic. That post is still accurate. Note that it's focused on a sidecar / low-mem configuration--as I'm sure you know, the JVM exhibits a, shall we say, "complex" relationship between memory footprint, CPU, throughput, and latency, and changing constraints can dramatically change the resource profile. (This complexity is not ideal for us, of course, but it's a result of a conscious decision to go with production-tested Finagle as opposed to starting with fresh code--just to give you context.)

E.g. the K8s configs in our recent Kubernetes post deploy linkerd as a DaemonSet--allowing us to amortize resource cost per node rather than per process, which gives us more breathing room--at the expense of a Horrible Hack to determine the node-local linkerd.

Finally, our assertion is that, with better load-balancing and flow control, end-to-end tail latencies can actually be *reduced* even when introducing a per-hop cost--though I'll admit that we don't have a nice experimental setup to back this up yet.

HTH,

-William

On Thu, Oct 6, 2016 at 10:59 AM, Brian Grant <briangrant@...> wrote:
Thanks for that additional information, William.

Are there plans for linkerd to support HTTP2?

Is the most recent performance and overhead data available that in https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/?


On Wed, Oct 5, 2016 at 6:38 PM, William Morgan <william@...> wrote:
(adding Oliver, linkerd's maintainer)

Hi Brian,

Good point about Amalgam8, I should have mentioned them. Also maybe Netflix's Prana?

In my mind Traefik, Vulcand, etc. are largely targeted at ingress / "API gateway" use cases. Whereas linkerd, Envoy, Amalgam8, and Prana are focused explicitly on service-to-service communication. Not 100% familiar with all of those projects so I hope that's not a gross mischaracterization.

Differentiating features / advantages of linkerd:
  • Focused on production-tested / used-in-anger code. Sticking close to Finagle, not writing our own load-balancing, etc. This stuff is hard to get right, tons of edge cases, etc. E.g. what happens when service discovery down? When it's up, but it's lying? Etc.
  • Production users across the globe (see below), lots more on the way.
  • Plugin architecture, tons of integrations, explicitly easy to drop in custom stuff.
  • Routing layer (again, used in prod) that is extremely powerful and decouples routing topology from traffic-serving topology.
  • Focus on modern operational affordances, e.g. retry budgets and deadlines over retry policies and timeouts.
  • Lots of contributors, active community and friendly Slack!
Current real-life prod users that we know of (and can talk about--some we can't) are Monzo (UK), Quid (US), Douban (CN), CentralApp (EU), NCBI (US). Lots of other companies in various staging / QA environments that we're tracking and helping to productionize. Of course open source is a funny thing and people will occasionally drop into the Slack and say "so, I've been running linkerd in prod for a few weeks and I noticed this one thing..." so we don't have a complete picture.

Let me know if that's helpful. Happy to go into lots more detail.

Also, thanks for having me this morning, was really fun to present and you have all been super friendly and supportive!




-William

On Wed, Oct 5, 2016 at 5:40 PM, Brian Grant <briangrant@...> wrote:
Hi, William. You briefly mentioned other similar proxies, such as Envoy. What do you see as linkerd's differentiating features or advantages compared to the others (Envoy, Traefik, Amalgam8)?

Also, are any of your users using linkerd in production?





Re: linkerd

alexis richardson
 

"standardized assessment" meaning "assessment"? or do you have something in mind?


On Thu, 6 Oct 2016, 19:26 Louis Ryan via cncf-toc, <cncf-toc@...> wrote:
I think it would be useful to have some standardized assessment of the CPU, latency & memory footprint tax that products in this space have.

A feature comparison matrix would be nice too.

On Thu, Oct 6, 2016 at 10:59 AM, Brian Grant <briangrant@...> wrote:
Thanks for that additional information, William.

Are there plans for linkerd to support HTTP2?

Is the most recent performance and overhead data available that in https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/?


On Wed, Oct 5, 2016 at 6:38 PM, William Morgan <william@...> wrote:
(adding Oliver, linkerd's maintainer)

Hi Brian,

Good point about Amalgam8, I should have mentioned them. Also maybe Netflix's Prana?

In my mind Traefik, Vulcand, etc. are largely targeted at ingress / "API gateway" use cases. Whereas linkerd, Envoy, Amalgam8, and Prana are focused explicitly on service-to-service communication. Not 100% familiar with all of those projects so I hope that's not a gross mischaracterization.

Differentiating features / advantages of linkerd:
  • Focused on production-tested / used-in-anger code. Sticking close to Finagle, not writing our own load-balancing, etc. This stuff is hard to get right, tons of edge cases, etc. E.g. what happens when service discovery down? When it's up, but it's lying? Etc.
  • Production users across the globe (see below), lots more on the way.
  • Plugin architecture, tons of integrations, explicitly easy to drop in custom stuff.
  • Routing layer (again, used in prod) that is extremely powerful and decouples routing topology from traffic-serving topology.
  • Focus on modern operational affordances, e.g. retry budgets and deadlines over retry policies and timeouts.
  • Lots of contributors, active community and friendly Slack!
Current real-life prod users that we know of (and can talk about--some we can't) are Monzo (UK), Quid (US), Douban (CN), CentralApp (EU), NCBI (US). Lots of other companies in various staging / QA environments that we're tracking and helping to productionize. Of course open source is a funny thing and people will occasionally drop into the Slack and say "so, I've been running linkerd in prod for a few weeks and I noticed this one thing..." so we don't have a complete picture.

Let me know if that's helpful. Happy to go into lots more detail.

Also, thanks for having me this morning, was really fun to present and you have all been super friendly and supportive!




-William

On Wed, Oct 5, 2016 at 5:40 PM, Brian Grant <briangrant@...> wrote:
Hi, William. You briefly mentioned other similar proxies, such as Envoy. What do you see as linkerd's differentiating features or advantages compared to the others (Envoy, Traefik, Amalgam8)?

Also, are any of your users using linkerd in production?




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: linkerd

Louis Ryan <lryan@...>
 

I think it would be useful to have some standardized assessment of the CPU, latency & memory footprint tax that products in this space have.

A feature comparison matrix would be nice too.

On Thu, Oct 6, 2016 at 10:59 AM, Brian Grant <briangrant@...> wrote:
Thanks for that additional information, William.

Are there plans for linkerd to support HTTP2?

Is the most recent performance and overhead data available that in https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/?


On Wed, Oct 5, 2016 at 6:38 PM, William Morgan <william@...> wrote:
(adding Oliver, linkerd's maintainer)

Hi Brian,

Good point about Amalgam8, I should have mentioned them. Also maybe Netflix's Prana?

In my mind Traefik, Vulcand, etc. are largely targeted at ingress / "API gateway" use cases. Whereas linkerd, Envoy, Amalgam8, and Prana are focused explicitly on service-to-service communication. Not 100% familiar with all of those projects so I hope that's not a gross mischaracterization.

Differentiating features / advantages of linkerd:
  • Focused on production-tested / used-in-anger code. Sticking close to Finagle, not writing our own load-balancing, etc. This stuff is hard to get right, tons of edge cases, etc. E.g. what happens when service discovery down? When it's up, but it's lying? Etc.
  • Production users across the globe (see below), lots more on the way.
  • Plugin architecture, tons of integrations, explicitly easy to drop in custom stuff.
  • Routing layer (again, used in prod) that is extremely powerful and decouples routing topology from traffic-serving topology.
  • Focus on modern operational affordances, e.g. retry budgets and deadlines over retry policies and timeouts.
  • Lots of contributors, active community and friendly Slack!
Current real-life prod users that we know of (and can talk about--some we can't) are Monzo (UK), Quid (US), Douban (CN), CentralApp (EU), NCBI (US). Lots of other companies in various staging / QA environments that we're tracking and helping to productionize. Of course open source is a funny thing and people will occasionally drop into the Slack and say "so, I've been running linkerd in prod for a few weeks and I noticed this one thing..." so we don't have a complete picture.

Let me know if that's helpful. Happy to go into lots more detail.

Also, thanks for having me this morning, was really fun to present and you have all been super friendly and supportive!




-William

On Wed, Oct 5, 2016 at 5:40 PM, Brian Grant <briangrant@...> wrote:
Hi, William. You briefly mentioned other similar proxies, such as Envoy. What do you see as linkerd's differentiating features or advantages compared to the others (Envoy, Traefik, Amalgam8)?

Also, are any of your users using linkerd in production?




7141 - 7160 of 7555