Re: revisiting if SaaS backends should be Apache repositories

[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
> >
> >
> >
>