[sakai2-tcc] Infrastructure discussion for future meeting?

[John Bush]

I agree its would be a big change and I'm not even suggesting we go
there yet, because I'm not convinced that would even be necessary.
I'm just trying to draw out requirements at this point.  Clearly one
process is preferred over something more complicated.

But I would challenge some of your assumptions.  First of all is our
market really the same market as Moodle?  Watch Chucks 10 year video,
we have much more traction in big schools and big deployments.  Moodle
might be great at throwing up on a server under some guys desk, and
that's probably why there are so many Moodle deployments around, but
is that who we are, is that who is really going to feed us moving
forward ?  Maybe we are better served by having an architecture that
actually supports the big guys, the big guys whoever they are bring
more resources to the table in the end, and that is the path towards
sustainability.

Second, deployment and configuration tooling is nothing like what is
used to be.  Puppet, chef, capistrano, vagrant, the list goes on and
on.  The big nasty .com's have given us able tooling for deployment
and configuration, and make things easy.  A lot of us just don't use
any of that stuff.  So the assumption that more than one process makes
deployment and configuration harder isn't actually the case, its
something you can engineer your way out of with the right tools.

But again, I'm not suggesting we move to requiring more than one
server, I just like to argue with you.


On Wed, Mar 13, 2013 at 2:32 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>> future.  What if only certain things didn't work in a one jvm/tomcat
>> demo world, that be consistent with how things are now.   I mean
>> things like ldap don't work ootb right now without an ldap server
>> living somewhere.
>
> Yes, but users can still login without LDAP because there is local
> user management support included. Obviously LDAP or AD or something
> like that is a more scalable and enterprise option but we don't fail
> to run if there is no LDAP server.
>
> I am all for having a modular system with swappable parts. You won't
> be able to use a classroom clicker with Sakai without some external
> system and hardware. That's fine. But requiring an extra server just
> to run it is not comparable to that situation. For example, I don't
> think Moodle would adopt something that meant you needed to run tomcat
> or a ruby server alongside your PHP webserver. I don't think I am
> "thinking inside the box" or "stuck in the past" or "not thinking
> about current tech" here. This is an app that people need to install
> on multiple platforms and the harder we make that for them and
> ourselves the less successful we will be.
>
> I think this discussion (deciding that Sakai will no longer run in a
> single JVM) is a huge one and needs a new thread.
>
> It is also nowhere near being a low hanging fruit issue like some of
> the others on the list that don't require changing the way users
> install and run the software.
>
> -AZ
>
>
> On Wed, Mar 13, 2013 at 4:12 PM, John Bush <john.bush at rsmart.com> wrote:
>> I think David is asking why is that the requirement ?  We shouldn't be
>> letting our demo dictate our platform.  Maybe that not the compelling
>> reason, but then if not one only one process?  What makes that a
>> non-starter ?  I understand this has been our position in the past but
>> what is the reason we need to work towards that necessarily into the
>> future.  What if only certain things didn't work in a one jvm/tomcat
>> demo world, that be consistent with how things are now.   I mean
>> things like ldap don't work ootb right now without an ldap server
>> living somewhere.
>>
>> On Wed, Mar 13, 2013 at 12:57 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>> I mean it should run in one JVM and tomcat. I don't think I can add
>>> much to that.
>>> -AZ
>>>
>>>
>>> On Wed, Mar 13, 2013 at 3:47 PM, David Adams <da1 at vt.edu> wrote:
>>>>
>>>> Aaron Zeckoski wrote:
>>>>> Mostly I mean running in the same tomcat (think the Sakai demo).
>>>>> If it won't work as part of the Sakai binary/demo then that's a
>>>>> non-starter IMO.
>>>>
>>>> Could you explain more what the issues with this would be? Is there a
>>>> reason why the demo/binary couldn't start up and manage two processes
>>>> just as well as it does one?
>>>>
>>>> -dave
>>>> _______________________________________________
>>>> sakai2-tcc mailing list
>>>> sakai2-tcc at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>
>>>
>>>
>>> --
>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>>
>>
>> --
>> John Bush
>> 602-490-0470
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile



--
John Bush
602-490-0470