Subscribe
About

The princess cloud bride

A realistic plan is essential to get data into the cloud, and back out again.

Lori MacVittie
By Lori MacVittie, Technical marketing manager for Application Services at F5 Networks.
Johannesburg, 30 Sep 2011

If you're not familiar with the cult classic: “The Princess Bride”, well, you ought to be, but that's neither here nor there. The premise of this particular scene, chosen for its appropriateness to the discussion, focuses on the intrepid heroes briefly discussing their plan of attack to storm the castle and save the princess from the clutches of the dastardly Prince Humperdinck.

If it took a FedEx truck to get the data into the cloud, it's almost certainly going to take a FedEx truck to get it out of the cloud.

Lori MacVittie is technical marketing manager for application services at F5 Networks.

The finer details of a rendezvous inside and ultimate escape are, of course, brushed aside. This all too familiar scene can often be seen replicated in broad discussions regarding cloud, and specifically, the “escape” of big data from within.

Westley: All right, all right. Come on, help me out. Now I'll need an SCP connection eventually.
Inigo: Why? You can't even type.
Westley: True, but that's hardly common knowledge, is it? Thank you. Now, there may be problems once the data is inside the cloud.
Inigo: I'll say. Namely, how do I find the cloud? Once I do, how do I find the data? Once I find the data, how do I get it out?
Fezzik: Don't pester him. He's had a hard day.
Inigo: Right. Right. Sorry.
Fezzik: Inigo?
Inigo: What?
Fezzik: I hope we win.

Early in the days of cloud computing, 'big data' focused on the applications themselves; the virtual images needing transfer from the data centre to the cloud computing provider. This was a huge roadblock then, and in many cases, still is - unless you accept the most often proffered solution of a modern 'sneaker net' using FedEx and UPS to transfer the Latin-word-for-huge-bytes of data required.

While certainly, WAN optimisation services, increasingly able to be deployed in a virtual form factor and thus fit better into a cloud computing model, are helping to solve limitations and issues arising from the size of such images, these same solutions do not necessarily solve the other “big data” problem of database consistency and “escape” from the cloud computing environment.

After all, if it took a FedEx truck to get the data into the cloud, it's almost certainly going to take a FedEx truck to get it out of the cloud. And it's going to cost. It's worth noting that Amazon charges per hour to import and export data, which gives some indication of the amount of time it takes to handle big data even in the cloud.

Getting smart

Cloud computing and virtualisation have had, thus far, very little impact on application architectures, because it has not been necessary to make changes to adapt to a cloud computing model. But in the world of data, this is not necessarily true. Cloud computing and the promise of faster, cheaper compute is bringing to the surface the realisation that perhaps an enormous, monolithic database model is not really appropriate for the more modern, highly distributed world of motile applications. Smarter application architectures, particularly around the data tier, will eventually be necessary to combat data transfer fatigue on the part of both networks and people.

With big data in the enterprise, backup and transfer window times increase sometimes exponentially as the volume of data requiring transfer continues to grow. The same is true of data in traditional database systems, and it is reality that cloud is not the primary deployment site for most applications today. It is secondary or ancillary to critical business applications, and eventually - often sooner rather than later - the data in the cloud must escape.

We need to plan better, and that may mean significantly altering our application architectures as it relates to the data tier. We may need to explore distributed databases or alternative data storage sources such as Hadoop, NoSQL, or even cloud-based data storage services. But to do so, we'll need to really think about our applications and where and how data flows between where they'll be deployed and where we ultimately want - and need - that data to be at rest.

It's true that our intrepid heroes - even without a solid plan of rendezvous and escape - saved the princess and defeated the evil Prince Humperdinck. Though we may be inspired by such a “fly-by-the-seat-of-your-pants” approach, it's important to recognise that it's fantasy and not reality. Reality is that we need a plan, not only how to get data into the cloud, but how to get it back out. And not only do we need to worry about getting it back out, but how to get it back out when we need it - not when the FedEx truck makes its next delivery.

I hope we win at that.

Share