Common Solutions Group, Spring 2009 at IUPUI
Indiana University hosted the Common Solutions Group this Spring. The principle theme this time was, ostensibly, Cloud Computing. While there are some notible exceptions, there was a general skeptisim among peer institutions in CSG that the Cloud is more than hype. To the extent that there was traction on the topic, it was mostly around one or another peer institution providing service to other EDUs for a given service.
From the high level viewpoint, I found this somewhat discouraging; a bit like putting heads in the sand and wishing a trend away. While there is a great deal of hype in this area, the idea of running services at will and scaling them at will on a variety of fungible computing resources is more than just hype, it’s happening. To be fair, that trend was recognized by many, there was very little consensus about how to take advantage of the Amazon EC2’s, and the like. My personal point of view which I expressed was that the hardest part of the effort to realize the power of this trend was in the modularizing services/apps to run on such “clouds”. This is much the same problem as modularizing to run in any one of a number of virtualized environments.
On a more specific note, there were breakout sessions (a new and refreshing format for some of the meeting) which took BoF together on a drill-down topic area. Michael Gettes (as of this writing, of MIT) and I ran a break-out session on Architectural, Technology and Security considerations of Shared Service computing. The presentation notes (pretty rough since they were just notes from the session) went over the various input we got from the ~ 20 or so folks that stayed for our session.
Another break-out session I attended was on Business Continuity and Disaster Recovery using peer institutions and/or other shared resources. I also presented those discussion points (hey, how’d I get stuck doing two?) in which both Duke and Stanford were able to speak regarding the recent successes of our mutual arrangement (BC of some limited services presented out of our respective campuses).
Essentially, the key came down to
- Can be replicated easily
- Reasonable volume of data
- Limited scope of dependencies
- Local expertise
- Low level uniqueness
- Low additional overhead
- Stable architecture & procedure
- If you cant peer it doesn’t qualify
As you can see in the slides, we thought of a few key services that were pretty well suited for such an arrangement but indicated what aspects of those or other services that were NOT well suited for such an arrangement. The trend in that conversation (trend seen for direction) was toward more multi-lateral EDU peer sharing like this i.e. presenting some replicated services services at one or more institutions.
There were other topics covered: report out from Greg Jackson on the resolution of the copywright issues… Also, there was a summary of UC Berkeley’s recent data compromise.
By Bruce Vincent, May 18, 2009 @ 2:32 pm
Just a little follow on about an expansion of the Amazon EC2 offering that I just saw…. http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9133203&source=CWNLE_nlt_pm_2009-05-18