Cloud technology is reminding me of all of the past “green technology” talk.. a little annoying. Everywhere you go, read, etc. you hear this & that about the CLOUD. I understand the concept, just like I understand the GREEN concept but this annoying marketing term is starting to make me not like clouds like I now do not like the color green. Is that extreme? Yeah probably but I am extremely immersed in this technology world, life business here & it is very annoying to see the word cloud so many times a day. Again, I get the concept, I resell managed services DUH. So I understand the “value” of it. But I still hate the word & I’m very sick of reading about it.
I just read ANOTHER cloud article just now that was interesting & I think it is worthy enough to share. Sooooo the concept of the CLOUD is to store data in the cloud rather then relying on internal hardware & systems. Cool. Well there is an issue with bandwidth going to & from the cloud with all of this data & information. Not enough bandwidth Betty. And with more & more companies going into the CLOUDS the problem is going to be more & more difficult. So how do you deal with the “SKINNY STRAW”? This is what Bernard Golden from CIO.com says..
Evaluate and price application data transfer needs: Obviously, the foundation of dealing with the skinny straw is to evaluate how much data you’re likely to be transferring. This is particularly important when considering an external cloud provider, because they typically charge a network traffic fee based on volume, unlike internal applications which usually do not have a granular pricing mechanism in place. Furthermore, because application use changes over time (which is one of the reasons the scalability of the cloud is so desirable), incorporate projections of data use into the evaluation. Obviously, this is challenging; after all, one of the reasons cloud scalability is so desirable is because, as application providers, it’s nearly impossible to predict potential application growth. A Monte Carlo-like simulation will prove helpful here just to illustrate the potential issues with regard to network traffic, both from a technical and economic perspective.
Another important aspect to evaluate is the variability of data transfer. Some applications, particularly those associated with analytics, have large load early in the life of the application, when ETL is performed; subsequently, there is little data transfer in as incremental updates are loaded. The download portion of an analytic is typically reports or aggregated data structures, which may not be that expensive. Understanding the patterns of data transfer is important, therefore, as the variability can make it difficult to predict costs using a too-general assumption of traffic.
Evaluate application architecture and consider application partitioning: An application may have sections that transfer lots of data and other sections that do not. It may make sense to partition the application so that data transfer-heavy portions reside where data transfer is cheap (i.e., an internal data center or a hosting provider), while other portions reside with a cloud provider. In a sense, this is a continuation and extension of the move to service-oriented applications, which are built by integrating independent components that communicate via well-established protocols. However, careful evaluation is important because one might run into the issue identified in the previous section—unexpected surges in data volume causing increased costs. The thing you want to avoid is to end up with an application where part of it resides in an external cloud and has high data traffic along with low latency requirements—that’s a recipe for high costs and poor performance.
Broaden the assessment to an application portfolio:Some applications, due to data transfer needs, just don’t belong in an external cloud environment. Instead of trying to figure out some way to make them work, recognize the fact. Application partitioning is a good strategy, but can be challenging to manage. Moreover, many applications are not architected such that partitioning can be implemented; unfortunately, the move to well-structured, service-oriented applications is not universal. A better approach is to examine the portfolio of current and future applications and identify which ones have the right architecture and data transfer needs to work in a cloud environment. If one were really dedicated (and clever), the portfolio could be evaluated to see how common functions could be factored out and implemented as stand-alone services; however, that is the premise of the SOA revolution, which has ended up more of a whimper than a bang, so aiming for this kind of outcome may be overreaching.
Recognize the importance of this issue and don’t get caught in the hype:The issue of bandwidth and data location is critical and won’t go away. I’m not a big fan of the current catchphrase of “cloudbursting” because I feel it overstates what cloud computing can achieve. Virtualization does imply that systems can be migrated, and once you migrate a system to a separate server inside the data center, why not to a different data center that is a cloud provider? However, migrating a system does not migrate the data it operates upon, assuming the application executes in a shared storage environment, which most virtualized environments do (eventually, anyway, even if they start with DASD).
So to cloud or not to cloud that still remains a question… but now you know just a little more information..!!!
