Sooo... About that "Doesn't work on Alpine Linux" thing. Any plans to fix that?

[cpruitt]

I've been using this gem to prototype our feature flag / experiments system. For performance reasons we need local evaluation and this SDK gem works great... in development. Deploying to production, for which we use Alpine Linux, fails in ways that are related to the linked Kotlin binaries. Debugging lead me to this mention which I had completely missed up until that point:

Well that's a bummer... My understanding is that this is an issue related to Kotlin binaries being unable to run on Alpine so I had a few followup questions:

1. Is this anything you have a roadmap for addressing? I believe you've already investigated this a bit here but I'm unclear on what we should expect moving forward. Is the path forward solely determined by Kotlin updates to support Alpine?
2. Is there any feasible workaround? For example some way we can compile alternative binaries ourselves?
3. Do you have any other recommendations for using Amplitude experiments in a performant way? The network overhead of using remote API calls for every user is a concern since we'd like to run experiments in some of our most critical, high volume application paths.

Thanks a bunch for any further info or suggestions you can offer!

[bgiori]

Hi @cpruitt, sorry you ran into this. I also ran into this after the whole implementation, which was a huge bummer. I can't believe you found that youtrack ticket!

I dont expect the JetBrains Kotlin Mutiplatform team to get started on musl (alpine) support any time soon. As this issue comes up more I expect that we (amplitude experiment) will need to work something out. Either rewriting is std C or native language support.

The current workaround I would suggest is creating a simple webserver container for the evaluation SDK as a sidecar for your main service. You can use Ruby w/ a non alpine base image or use Java/JavaScript local evaluation SDK with an alpine image. Requests from the primary service container to the sidecar should be fast enough, but a bit less scalable.

Another possible option would be to use JRuby to call our Java SDK from the jar. I have not explored this myself, so I cant give you much more than the possibility.

[cpruitt]

@bgiori Thanks. That's all pretty much inline with our initial thoughts but I'd hate to overlook something just because I didn't bother to ask. The scaling associated with spinning off a service in a second container does feel a little questionable but we're evaluating that route.

Thanks for the info and quick reply!