On Wednesday, April 30, 2014 5:17:40 AM UTC+1, cdemorsella wrote: > > > > > > *From:* [email protected] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of *Jason Resch > *Sent:* Tuesday, April 29, 2014 8:08 AM > *To:* Everything List > *Subject:* Re: anyone super-geek here? > > > > I work at a company who's primary business is making large-scale private > cloud storage systems, supporting both Amazon's S3 and OpenStack > interfaces. While OpenStack has the advantage of being more open, Amazon's > S3 protocol seems to have a larger mind share, and more traction as far as > becoming a de facto standard. If you are developing client-side > applications against cloud APIs, I think you will find the S3 API more > powerful and better designed and thought out than the Openstack API, but > for simpler use cases that just involve read, write, delete, etc. there's > very little difference between them. > > I think Chris's comment below is particularly good advice. You ought to > build an abstraction layer that sits between your application logic and the > storage layer such that in the future you can more easily transition to > other APIs should the need or desire arise. > > > > I would also add that doing so is a lot easier when first building a > system. After dependencies creep through a code base it becomes > increasingly difficult to retrofit an abstraction layer into a body of > code. Believe me I know, I have tried and seen a lot of other attempts. > Have worked with some code for some very large software companies that is a > forest of pre-processor commands that make it almost impossible to follow > the code through the forest of #ifdefs, #elif, #defines, #endif directives > AND_A_WHOLE_BUNCH_UGLY_LONG_STRINGS… in this one instance I believe they > still struggle with the massive bleed through of dependencies throughout a > very large code base. Once a body of code becomes inherently coupled by > dependencies it can become impossible – in practice – to achieve loose > coupling. On the other hand sometimes strong dependency makes perfect > sense, but for anything that is peripheral to the core function of the > software it often makes sense to emplace abstraction layers early on in the > life-cycle. > > It is a case of do it now; or risk not being able to do it later… > architecting an abstraction layer is also an opportunity to reflect on > actual requirements and what kind of models and system topologies make > sense. It can lead to better design over all. > > Chris > > > > Jason > > > > On Mon, Apr 28, 2014 at 8:03 PM, 'Chris de Morsella > <[email protected]<javascript:>>' > via Everything List <[email protected] <javascript:>> wrote: > > I looked at it a while back and of the various open source cloud > initiatives it looks like the one best positioned to succeed also because > it is heavily backed by Rackspace -- a large hosting, col-location service > based out of Texas. > > My advice though, whatever cloud solution you go with would be to try as > much as possible to abstract the specific bridge code behind an opaque > interface that cleanly separates it from bleeding out into other code. > > This will help to isolate this layer from other layers in your code. In > general an extra layer of indirection is almost always worth it if it can > decouple responsibilities and functions. Clean separation is one of the > keys to managing mushrooming complexity as code grows and evolves over time. > Alberto, Chris, Jason, cde : I was grateful for your comments which were very helpful. I'll pass drinks back if anything changes as a result. Many thanks"!
-- You received this message because you are subscribed to the Google Groups "Everything List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/everything-list. For more options, visit https://groups.google.com/d/optout.
