From: [email protected] [mailto:[email protected]] 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]>' via Everything List <[email protected]> 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. _____ From: "[email protected]" <[email protected]> To: [email protected] Sent: Monday, April 28, 2014 8:09 PM Subject: Re: anyone super-geek here? On Monday, April 28, 2014 3:43:35 PM UTC+1, [email protected] wrote: Hi, off topic, but I need to throw a few things onto the cloud, and it's important to get package right. So can anyone answer...is it OpenStack ? No need to answer unless you feel you have serious amounts of exposure That could have conveyed a message I didn't intend. All I meant was I've got engineers..it just occurred to me the list might have super-genius experts. I don't want to end up with an infrastructure that isn't going to keep up,. OpenStack looks good though. -- 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. -- 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. -- 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. -- 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.
