Edda's status at Netflix

369 views
Skip to first unread message

Avery Regier

unread,
Nov 4, 2015, 3:06:44 PM11/4/15
to Edda Users
So commits seem to have slowed down on Edda, and this forum doesn't have a lot of recent activity, and there's a bunch of pull requests that are open.  Is Edda still in use at Netflix?  Has this been abandoned now?

If so, are there any reasonable alternatives out there?  Or is this still the only game in town?

Thanks,
Avery

William Strucke

unread,
May 25, 2016, 11:10:50 AM5/25/16
to Edda Users
+1

Aravind GV

unread,
Sep 18, 2017, 6:37:22 AM9/18/17
to Edda Users

Aravind GV

unread,
Sep 18, 2017, 6:38:00 AM9/18/17
to Edda Users
Installing Edda is nightmare is this still supported ? If any one has alternatives ?


On Thursday, November 5, 2015 at 1:36:44 AM UTC+5:30, Avery Regier wrote:

brharr...@netflix.com

unread,
Oct 23, 2017, 12:36:12 PM10/23/17
to Edda Users
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
Reply all
Reply to author
Forward
0 new messages