You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zipkin.apache.org by Adrian Cole <ad...@gmail.com> on 2019/02/14 00:52:13 UTC
revisiting if SaaS backends should be Apache repositories
Hi, folks.
SaaS providers such as Google, routinely change their apis and not
always is the support good when that occurs. Many have an agenda to
use their own native clients as well (regardless of naming prefix).
Controlled ecosystems, whether that's private apis or golden path to
3rd party libraries can be tricky. While Amazon and Google currently
don't actively try to stop Zipkin ecosystem, we hardly ever get any
support from either. Notably, the GCP repository has had numerous
complaints and while Google originally helped write it, they no longer
help.
All this in mind.. should we move repos like this into the ASF?
Notably, the google one is more troubling support wise, but also the
Amazon X-Ray component of the aws project has been incomplete for
years. OTOH, notably in zipkin-aws, there are many stable used things,
like SQS transport.
I think the tension is around lack of support around cloud tracing
backends and this causes a bad user experience.
What do you think? If we did move the SaaS backends into Apache, what
could we ask google or amazon for to ensure their health? When would
we delete these backends if they drifted and ceased to help?
For consideration, the last wiki I wrote on this topic is here
https://github.com/Netflix/denominator/wiki/Adding-new-Providers
-A
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org
Re: revisiting if SaaS backends should be Apache repositories
Posted by Brian Devins-Suresh <ba...@gmail.com>.
Adrian reminded me that this thread existed.
I'll offer my 2 cents here, I think that the storage/reporter
implementations
that send to the vendor backends do not belong in the same repos as the
Zipkin and Zipkin library extensions that enable Zipkin use within cloud
environments. The distinction between this being that, the components
that are usable within the Zipkin ecosystem, no matter the backend, and
those that provide system interop with other ecosystems. IE: we treat
StackDriver and XRay the same way we would NewRelic or Datadog
or Haystack exporters if they existed.
With the current status of these repos, that would mean zipkin-gcp does
not get moved to the ASF, and zipkin-aws would have the XRay
components extracted out of it to a new repo, perhaps: zipkin-xray, and
then it would be in a good place to be moved.
- Brian
On Wed, Feb 13, 2019 at 9:15 PM Adrian Cole <ad...@gmail.com> wrote:
> Currently the biggest technical risk beyond api drift is Google's use of
> gRPC over ssl. This is not a problem for Amazon.
>
> gRPC is a crazy sensitive dependency tree including BoringSSL native
> drivers. This is very time consuming to debug. Some of this goes away JRE
> 11+ but the "slim" images provided by openjdk are huge (350MiB where our
> while image is less than 150)
>
> StackDriver adds to that oauth etc. but most support problems have been
> around grpc unless memory is incorrect.
>
> On Thu, Feb 14, 2019, 10:08 AM Andriy Redko <drreta@gmail.com wrote:
>
> > Hey Adrian,
> >
> > I think this is a difficult choice to make, for any project which faces
> > similar challenges.
> > From one perspective, those repos (GCP and X-Ray integration) are
> valuable
> > contributions,
> > the Google Cloud and AWS are very popular platforms so having Zipkin
> > presence there is
> > a huge plus. But maintenance wise, as per your concerns, neither Google,
> > nor Amazon have
> > interest in supporting it (building own solutions?). I think there are at
> > least two
> > questions to ask and, depending on the answers, make a decision:
> >
> > 1. Do we have contributors who could / are interested in maintaning the
> > projects?
> > 2. Any risks that at some point, Google or Amazon would make the
> > integration difficult / impossible?
> >
> > We may ask Google or Amazon folks, as you suggested, if they could help
> us
> > out. If not, could we
> > involve community members? If there is no interest, we probably are
> better
> > off not moving them.
> >
> > Thanks.
> >
> > Best Regards,
> > Andriy Redko
> >
> >
> > AC> Hi, folks.
> >
> > AC> SaaS providers such as Google, routinely change their apis and not
> > AC> always is the support good when that occurs. Many have an agenda to
> > AC> use their own native clients as well (regardless of naming prefix).
> > AC> Controlled ecosystems, whether that's private apis or golden path to
> > AC> 3rd party libraries can be tricky. While Amazon and Google currently
> > AC> don't actively try to stop Zipkin ecosystem, we hardly ever get any
> > AC> support from either. Notably, the GCP repository has had numerous
> > AC> complaints and while Google originally helped write it, they no
> longer
> > AC> help.
> >
> > AC> All this in mind.. should we move repos like this into the ASF?
> > AC> Notably, the google one is more troubling support wise, but also the
> > AC> Amazon X-Ray component of the aws project has been incomplete for
> > AC> years. OTOH, notably in zipkin-aws, there are many stable used
> things,
> > AC> like SQS transport.
> >
> > AC> I think the tension is around lack of support around cloud tracing
> > AC> backends and this causes a bad user experience.
> >
> > AC> What do you think? If we did move the SaaS backends into Apache, what
> > AC> could we ask google or amazon for to ensure their health? When would
> > AC> we delete these backends if they drifted and ceased to help?
> >
> > AC> For consideration, the last wiki I wrote on this topic is here
> > AC> https://github.com/Netflix/denominator/wiki/Adding-new-Providers
> > AC> -A
> >
> > AC> ---------------------------------------------------------------------
> > AC> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> > AC> For additional commands, e-mail: dev-help@zipkin.apache.org
> >
> >
> >
>
Re: revisiting if SaaS backends should be Apache repositories
Posted by Adrian Cole <ad...@gmail.com>.
Currently the biggest technical risk beyond api drift is Google's use of
gRPC over ssl. This is not a problem for Amazon.
gRPC is a crazy sensitive dependency tree including BoringSSL native
drivers. This is very time consuming to debug. Some of this goes away JRE
11+ but the "slim" images provided by openjdk are huge (350MiB where our
while image is less than 150)
StackDriver adds to that oauth etc. but most support problems have been
around grpc unless memory is incorrect.
On Thu, Feb 14, 2019, 10:08 AM Andriy Redko <drreta@gmail.com wrote:
> Hey Adrian,
>
> I think this is a difficult choice to make, for any project which faces
> similar challenges.
> From one perspective, those repos (GCP and X-Ray integration) are valuable
> contributions,
> the Google Cloud and AWS are very popular platforms so having Zipkin
> presence there is
> a huge plus. But maintenance wise, as per your concerns, neither Google,
> nor Amazon have
> interest in supporting it (building own solutions?). I think there are at
> least two
> questions to ask and, depending on the answers, make a decision:
>
> 1. Do we have contributors who could / are interested in maintaning the
> projects?
> 2. Any risks that at some point, Google or Amazon would make the
> integration difficult / impossible?
>
> We may ask Google or Amazon folks, as you suggested, if they could help us
> out. If not, could we
> involve community members? If there is no interest, we probably are better
> off not moving them.
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
>
> AC> Hi, folks.
>
> AC> SaaS providers such as Google, routinely change their apis and not
> AC> always is the support good when that occurs. Many have an agenda to
> AC> use their own native clients as well (regardless of naming prefix).
> AC> Controlled ecosystems, whether that's private apis or golden path to
> AC> 3rd party libraries can be tricky. While Amazon and Google currently
> AC> don't actively try to stop Zipkin ecosystem, we hardly ever get any
> AC> support from either. Notably, the GCP repository has had numerous
> AC> complaints and while Google originally helped write it, they no longer
> AC> help.
>
> AC> All this in mind.. should we move repos like this into the ASF?
> AC> Notably, the google one is more troubling support wise, but also the
> AC> Amazon X-Ray component of the aws project has been incomplete for
> AC> years. OTOH, notably in zipkin-aws, there are many stable used things,
> AC> like SQS transport.
>
> AC> I think the tension is around lack of support around cloud tracing
> AC> backends and this causes a bad user experience.
>
> AC> What do you think? If we did move the SaaS backends into Apache, what
> AC> could we ask google or amazon for to ensure their health? When would
> AC> we delete these backends if they drifted and ceased to help?
>
> AC> For consideration, the last wiki I wrote on this topic is here
> AC> https://github.com/Netflix/denominator/wiki/Adding-new-Providers
> AC> -A
>
> AC> ---------------------------------------------------------------------
> AC> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> AC> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>
>
Re: revisiting if SaaS backends should be Apache repositories
Posted by Andriy Redko <dr...@gmail.com>.
Hey Adrian,
I think this is a difficult choice to make, for any project which faces similar challenges.
From one perspective, those repos (GCP and X-Ray integration) are valuable contributions,
the Google Cloud and AWS are very popular platforms so having Zipkin presence there is
a huge plus. But maintenance wise, as per your concerns, neither Google, nor Amazon have
interest in supporting it (building own solutions?). I think there are at least two
questions to ask and, depending on the answers, make a decision:
1. Do we have contributors who could / are interested in maintaning the projects?
2. Any risks that at some point, Google or Amazon would make the integration difficult / impossible?
We may ask Google or Amazon folks, as you suggested, if they could help us out. If not, could we
involve community members? If there is no interest, we probably are better off not moving them.
Thanks.
Best Regards,
Andriy Redko
AC> Hi, folks.
AC> SaaS providers such as Google, routinely change their apis and not
AC> always is the support good when that occurs. Many have an agenda to
AC> use their own native clients as well (regardless of naming prefix).
AC> Controlled ecosystems, whether that's private apis or golden path to
AC> 3rd party libraries can be tricky. While Amazon and Google currently
AC> don't actively try to stop Zipkin ecosystem, we hardly ever get any
AC> support from either. Notably, the GCP repository has had numerous
AC> complaints and while Google originally helped write it, they no longer
AC> help.
AC> All this in mind.. should we move repos like this into the ASF?
AC> Notably, the google one is more troubling support wise, but also the
AC> Amazon X-Ray component of the aws project has been incomplete for
AC> years. OTOH, notably in zipkin-aws, there are many stable used things,
AC> like SQS transport.
AC> I think the tension is around lack of support around cloud tracing
AC> backends and this causes a bad user experience.
AC> What do you think? If we did move the SaaS backends into Apache, what
AC> could we ask google or amazon for to ensure their health? When would
AC> we delete these backends if they drifted and ceased to help?
AC> For consideration, the last wiki I wrote on this topic is here
AC> https://github.com/Netflix/denominator/wiki/Adding-new-Providers
AC> -A
AC> ---------------------------------------------------------------------
AC> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
AC> For additional commands, e-mail: dev-help@zipkin.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org