[DG: Open Forum] openforum Digest, Vol 35, Issue 8

[Ian Boston]

Dear Anthony & Nico,

David brings up some valid points. I have read your report and looked
at the code base including running it locally. Your report states the
motivation for this work was a loss of confidence in the architecture
of OAE and I will be the first to agree that the previous two attempts
to implement that architecture failed over time.

This third attempt does not change the conceptual architecture of OAE,
evidenced by the same UI, the same shared nothing approach and the
same major components. It does not change; the access everything by
pointer concept and the publish model, which where central to the
first two attempts. Perhaps your report should have said the steering
committee lost confidence in the current implementation, rather than
the architecture, since if they have lost confidence in the conceptual
architecture, they have already lost confidence in what you are doing
? (BTW I am not suggesting you claim to have changed the architecture,
since that would really be going out on a limb and against 1000s of
successful internet applications)

David asked the question, what is different this time ?
There are 2 things that are fundamentally different this time. The
team structure and the decision process.

Let me deal with team first. Previously there were 3 teams. UX
designers, UI developers, and server. This created a waterfall process
even though internally activities were agile. By the time the outputs
of the UX designs reached the server team they were set in stone, and
at best contrary to the technical concepts at that level, at worst
unimplementable. Reversing decisions was impossible as 2 of the other
teams had committed to the concepts and designed APIs.

This time, there is one team responsible for everything. They would be
unbelievably stupid if they committed to implement something that they
had no chance of delivering or made a total mess of what they had
already done. If the team thinks it cant be done, the UX design will
never be presented as an option to the SG/URG.  Hence this team
structure has every chance of succeeding where K2 and Nakamura failed.

Decision process. In October 2010 I built the first version of
Sparsemap on Cassandra. I reported (in the project README) that it was
capable of concurrently adding 4000 users per second almost 100 times
the performance of the system we had before that. I made repeated and
strong recommendations that it should be used. On consultation with
the community it became apparent that none of the infrastrucutre teams
(even the largest Universities) had the hardware or skills to support
a Cassandra based deployment. Although that code has remained in that
code base, we had no option, driven by the requirements of our
community to implement a RDBMS based approach borrowing heavily from
the metadatastore at YouTube.

This time, the decision has been made to use Cassandra. I dont have
enough inside information to know if institutions are now comfortable
with the hardware requirements and retraining required, of if they are
willing to sign up to a shared service. I didn't see or hear of any
consultation. Personally I have my doubts about a shared service since
I havent seen a willingness institutions in higher education to self
organise their own shared hosting. Obviously everyone could just sign
up with a SCA (eg rSmart) and let them take care of hosting.

With this new streamlined structure and decision making process this
time will be different and may well deliver OAE in a record timeframe.
It remains to be seen if it will deliver a sustainable community
project?

Ian


BTW There were some factual inaccuracies in the report, but to point
them out would be nit-picking and distract from the more important
questions.



>
> ------------------------------
>
> Message: 4
> Date: Fri, 19 Oct 2012 10:22:22 -0500
> From: David Adams <daveadams at gmail.com>
> Subject: Re: [DG: Open Forum] Sakai OAE Update
> To: openforum at collab.sakaiproject.org
> Message-ID:
>         <CAN3s8zYgWsGzouEiA+LDH185GyYyFJTpVX0ro5JDwCn_1o-pMQ at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> 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
>