スキップしてコンテンツを表示

Hidden dependency on Kinesis Producer Library?

0

We've been notified by AWS that some of our apps are using the Kinesis Producer Library (KPL) version 0.x, which won't be supported anymore next year. However, there is no trace of that library in our backend, which is written in Go, while the lib is in Java.

Before considering this as a false positive, we'd like to know if there could be an indirect dependency hidden somewhere in our usage of AWS. Right now, we produce Kinesis messages from Go code (standard SDK v2) living in ECS containers and lambdas.

Thanks in advance for your help!

質問済み 8ヶ月前41ビュー
1回答
0

This kind of hidden dependency can definitely be tricky to spot. Since your backend is Go and you’re using the AWS SDK v2 for Kinesis, you shouldn’t have a direct dependency on the Java-based Kinesis Producer Library (KPL). However, there are a few scenarios where the KPL could sneak in indirectly:

  1. Check if any other part of your architecture, maybe other microservices, sidecars, or third-party tools, could be using Java and KPL under the hood. Sometimes monitoring agents, analytics pipelines, or connector tools include KPL without it being obvious in your main backend repo.
  2. Look inside your ECS container images and Lambda layers. There might be bundled Java libraries or older SDK versions that include KPL transitively.
  3. Sometimes CI/CD jobs or build artifacts bring in dependencies that aren’t in your source code directly. Review your build and deployment configs for any Java tooling or Kinesis clients.
  4. Although Go modules are quite explicit, double-check dependencies in vendor directories or any native libraries that might call Java components.

In my experience, these hidden dependencies often come from auxiliary services or older components not maintained as actively as the main backend.

回答済み 5ヶ月前

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

関連するコンテンツ