zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <adrian.f.c...@gmail.com>
Subject Re: revisiting if SaaS backends should be Apache repositories
Date Thu, 14 Feb 2019 02:15:26 GMT
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
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message