I attended three great open source related meetings in the last weeks. The first was our S3E2 meetup at Netflix. The second was a great conference in Raleigh - All Things Open (ATO) 2015. The third was the Research Triangle Park area Triangle Devops meetup. At all three of these I talked about why we do open source at Netflix. At the ATO 2015 conference I heard from people doing open source better than I personally am doing. These meetings inspired me to write this blog post to be more open about one of my personal projects that is struggling and motivated me to do better on this project - Prana. Prana is our sidecar process we run alongside non-Java code to provide access to our cloud platform services. Prana(-Zuul) runs on 1000’s of servers in the Netflix cloud and is a key technology that allows Netflix to work across multiple language implementations.
When we released Prana to open source, we open sourced a version we expected to be used internally before it actually was. This was at a time where a majority of the Netflix cloud platform was looking towards adoption of RxNetty networking and reactive RPC and service hosting mechanisms. Given both RxNetty and reactive RPC were evolving at the same time, all services of Prana open source were based on, at the time, prototype codebases. Let’s call this version Prana-OSS.
While all of this external work was going on, there was a different version of Prana used internally that originated out of our Edge team. Given its origin, it was based on Zuul and Jetty for service hosting and an older internal version of Ribbon for RPC. This version, while a bit crufty due to its age, had more functionality with regards to reliability and was more battle tested in production. Let’s call this version Prana-Zuul.
Prana-Zuul is based upon our cloud platform libraries (configuration, service registration and discovery, RPC, etc). Prana-Zuul is maintained by the same cloud platform team as these base libraries. In thinking through strategically what Prana (and Prana-OSS) should become, we decided that Prana should be based on the newer supported versions of both cloud platform services and RPC. This is an evolving space in our cloud platform today and therefore we are waiting to update Prana-OSS until this cloud platform update occurs. In the meantime, we have been continuously battle hardening Prana-Zuul for our wealth of internal non-JVM customers.
This has meant that external users of Prana-OSS are using an OSS project that, while valuable, isn’t used internally. Given the code isn’t the code we use internally, this has meant that PR’s and issues on github are going unanswered. It was Christine Abernathy’s talk at ATO 2015 that reminded me that such behavior isn’t acceptable for an open source project. At Facebook, such a project would likely come to the attention of the open source project office and then executives and they would take action. To be more responsible with this project, I will post this blog article to each of the open PR’s as well as on the front readme asking people to read it to understand the status. I will also go ahead and address as many of the PR’s as I can easily to keep the code live across external contributors, knowing that we are resolving them for open source, but they will not be tested internally.
Longer term, as our cloud platform updates land in Netflix open source themselves, we will update Prana-OSS based on the roll-out of a reworked Prana version inside of Netflix. We could decide to release the current Prana-Zuul in open source instead, but the cleanup required and timing in relation to cloud platform updates makes this a less attractive option. At the point where we release this updated Prana in open source, people will see a much more healthy Prana externally.
I do apologize for the confusion and pain this caused to our Prana open source users. I hope to be better in the future. Keep me accountable, please.
