[DG: Open Forum] Sakai OAE Update

Fri Oct 19 12:26:15 PDT 2012

> Can you elaborate on how this rewrite-from-scratch proposal is different than the last two?

Read the code and follow the development team's work on Github [1].  The answer lies therein.  If you like what you see consider getting involved.

> Is Cassandra the appropriate option for a medium-scale app with a small-scale IT budget and a single data store?

If we do our job right, we think adopters of modest means will prefer joining a multi-tenant OAE cloud deployment over trying to run it on their own.

> Thanks again for the update. And good luck. You're gonna need it.

Luck we will always need, whatever the endeavor.  Sarcasm not so much.

Cheers,

Anthony

[1] https://github.com/sakaiproject

On Oct 19, 2012, at 11:22 AM, David Adams wrote:

> Nicolaas,
> Thanks for the detailed and thorough update. The attached documents in
> particular are very useful. I have a couple of questions that aren't
> addressed in these documents.
> 
> First, to my ear, this plan sounds eerily familiar to the original
> Sakai 3.0 mandate[1] and the rewrite proposal for "K2"[2]: essentially
> "we can rewrite essential core services quickly, and everything on top
> of that will work just fine". Then again in late 2010 when it became
> apparent that Jackrabbit was an inappropriate storage system, the
> sparse content map system was introduced[3] to quickly replace
> Jackrabbit and skyrocket performance.
> 
> So here we are two years later, with the same proposal: Rewrite 80% of
> the interfaces quickly on an entirely new platform. Performance tests
> show great numbers at this proof-of-concept stage. Can you elaborate
> on how this rewrite-from-scratch proposal is different than the last
> two?
> 
> My second question is about the risks involved with the platform
> choice. You mention Netflix, Reddit, and Twitter as places that use
> Cassandra to great success. Yet they do not use it as their sole
> database platform (at least not monolithically), and their IT budgets
> run into the eight figures, if not more. Is Cassandra the appropriate
> option for a medium-scale app with a small-scale IT budget and a
> single data store?
> 
> Thanks again for the update. And good luck. You're gonna need it.
> 
> -dave
> 
> [1] https://confluence.sakaiproject.org/x/TAAiAQ
> [2] https://groups.google.com/forum/#!topic/sakai-kernel/gSMswDyj7G4/discussion
> [3] https://groups.google.com/forum/#!topic/sakai-kernel/sWVM_1lqSjg/discussion
> 
> On Thu, Oct 18, 2012 at 6:25 PM, Nicolaas Matthijs
> <nicolaas.matthijs at caret.cam.ac.uk> wrote:
>> Hi everyone,
>> 
>> As most of you know, a number of Sakai OAE stakeholder organizations have withdrawn from the managed project over the last 6 months.  Key reasons cited for these departures include:
>> 
>> - Concerns about the scalability and viability of the Nakamura architecture
>> - Slower than desired progress on feature development
>> - Misalignments between stakeholders
>> 
>> These withdrawals have had a significant negative impact on the level of financial and in-kind contributions underwriting the development team.  In addition, reports from piloting institutions together with performance test data produced by the team have made it clear that OAE’s performance and scalability characteristics leave much to be desired.  While sufficient for small-scale pilots involving a few thousand users, OAE’s performance under load is wholly insufficient for adopters considering an enterprise production deployment supporting tens of thousands of users and above, including the web-scale deployments we are likely to see in the future.  Upgrading between versions also remains a challenging exercise for operations teams.  While the remaining stakeholders believe that the concepts embodied in OAE’s design work remain relevant and valuable, current circumstances dictate that we adopt a new technical approach.
>> 
>> In late August we recommended to the project stakeholders that the managed project cease development on OAE Nakamura, setting aside its technical debt in favor of a re-engineered back-end that re-positions the project as a multi-tenant, highly scalable, cloud-ready application.  The strategy that we set out involves an initial and temporary reduction in application scope; existing features will be disabled until their corresponding back-end services have been recreated.  Our proposal was accepted, and in early September a reconstructed and considerably leaner project team commenced work on providing a new back-end architecture written in node.js and using Apache Cassandra for persistence.[1]  The code is licensed ECL 2.0 and is publicly available in a Github repo named “Hilary”.[2]  Additional repos have been created for the test data model loader, Tsung performance tests, nightly performance test scripts and puppet deployment scripts.[3]
>> 
>> We have retained OmniTI, a web performance and scalability consultancy, to help guide our work.  A series of one-week sprints have been organized in order to keep the pace of development high as well as allowing for quick resets under the “fail fast” rule.  We start from a set of purposefully designed and documented REST APIs (see attachment).  Each REST API and its accompanying internal service will include unit and integration tests. The team will set up and maintain a reference deployment in the cloud, on which extensive nightly performance tests will be run. The existing UI, benefiting from a number of client-side performance improvements included in the OAE 1.4.0 release, will be retained along with the Widget Library and SDK.  Administrative UIs will be added and there's also a desire to start introducing some of the new unimplemented UI designs along the way, as these have been through several rounds of usability testing and were presented to the community at the summer Sakai/Jasig conference.
>> 
>> The team has set itself a mid-December deadline--with intermediate deadlines and sanity checks along the way--to produce working code that demonstrates that the chosen path is viable.  Attached is the September progress report outlining the first 30 days of work along with our API doc and “alternative scenarios” proposal.  While the proposed architecture remains under evaluation and could change, we believe that our recommendation to retire OAE Nakamura in favor of a re-architected multi-tenant, cloud-ready platform featuring  purposefully designed REST APIs and services that are properly instrumented and continually measured is the right approach to take.
>> 
>> Kind regards,
>> Nicolaas and Anthony
>> 
>> [1] http://nodejs.org/, http://cassandra.apache.org/
>> [2] https://github.com/sakaiproject/Hilary
>> [3] https://github.com/sakaiproject/OAE-model-loader, https://github.com/sakaiproject/node-oae-tsung, https://github.com/sakaiproject/oae-nightly-stats, https://github.com/sakaiproject/puppet-hilary
>> 
>> 
>> 
>> _______________________________________________
>> openforum mailing list
>> openforum at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/openforum
>> 
>> TO UNSUBSCRIBE: send email to openforum-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> _______________________________________________
> openforum mailing list
> openforum at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/openforum
> 
> TO UNSUBSCRIBE: send email to openforum-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"