From the Netflix side, Edda is still used, but does not get a lot of attention and mostly just works. Unfortunately the internal version and open source version diverged over time, which is why there are few Netflix contributions at this time. We may try to remedy that in the future, but it just isn't a priority at the moment. We have been trying to give some attention to community contributions so the project is not completely blocked if others wish to improve it.
I'm not aware of any direct alternatives to Edda. That said, depending on which use-cases are important to you, there may be some options. Originally Edda had two main use-cases:
- Read-only cache of AWS state. This was mainly because we had trouble with getting throttled by AWS and they would not support the call volume we needed for our operational tooling. This is still what we rely on Edda for today with the internal version. Some other services have some of this, but one benefit we have with Edda is that the JSON output is based on the AWS object model. We have a number of teams that use a proxy client that allows them to access Edda using the client interfaces in the AWS SDK. That makes it easy to transition between using Edda and going direct to AWS in those apps. If you do not need the full resource state or to be able to do things like the proxy client, then you might be able to collect some of this information using CloudWatch events assuming it covers the resources you care about.
- History of resources over time. Internally we no longer use Edda for this. We have other tracking via a variety of tools including AWS Config, CloudTrail, and a handful of other internal auditing and logging tools. There were some benefits with Edda in that it could show us diffs over the entire resource, but overall it wasn't worth it to us and the historical views created some reliability issues that impacted the read-only use-cases cases that were more critical to us.
Brian