내용으로 건너뛰기

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달 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

관련 콘텐츠