Experience all of the Out of this World episodes
close

January 12th, 2012

Recently I signed up for an online music matching service. If you aren’t familiar, these services basically make your entire music library available from the cloud, and sync it across all of your devices as well. One of the really useful things about such services is that they let you selectively download artists/albums/songs onto your computers/devices vs. automatically adding them.

Recently I signed up for an online music matching service. If you aren’t familiar, these services basically make your entire music library available from the cloud, and sync it across all of your devices as well. One of the really useful things about such services is that they let you selectively download artists/albums/songs onto your computers/devices vs. automatically adding them.

This selective download capability got me thinking — why is it actually needed? The answer is obvious; you need to download your music so you can listen to it in places where you don’t have internet access. Planes, trains, and cars are some examples of places where you don’t get reliable, consistent, internet access. My home, however, is another story. I have excellent internet access. Despite this, prior to music matching, I was forced into an “on premise” music management process. Everything had to be stored on my home computer, and I had to manually plug each of my devices into the computer and manually choose what I wanted to sync over. The continued growth of my digital music and movies will very quickly fill up a 500GB hard drive, forcing me to play the “do I really watch/listen to this?” game over and over.

So after I setup music matching, I ran a few tests. I quickly realized that I could “delete” anything I wanted off my home computer, but when I did my music service would ask me if I wanted to keep it in the cloud. If I said yes, then it just meant that it would be streamed from the cloud vs. played locally, which is fine because I can stream from home as much as I want. But it was removed from my home computer storage, forever solving my ongoing need for local storage.

This is a great example of how the cloud decentralizes our worlds. In the pre-cloud days I had to think of my music library as one big centrally stored collection. It was up to me to back it up, buy more and more storage, move it around when I upgrade PC’s, you get the idea. Now with the cloud, all of that goes away, and the idea of “storage” means something totally different. Storage is now decentralized; downloaded fragments of my music library are scattered across my devices so that I can listen to them from places where I can’t get to the cloud.

There is a very similar phenomenon going on in the integration world. Old integration middleware applications that were built before the cloud existed were built with a centralized mindset. You would create these huge stacks of hardware/databases/queues/servers and run massive amounts of data through them. And they worked well, in the pre-cloud days, because the applications being integrated were within the same network. The cloud has now completely changed this paradigm. There is no one central place for IT anymore.

Between traditional data centers, private clouds, public clouds, PaaS, and SaaS, your IT landscape if officially decentralized. So then, must your integration strategy. While the centralization of development tools, administrative consoles, deployment and change management is more critical than ever, your integration “stack” must now be portable so that you can address integrations in all of the different environments you will contend with. By following this strategy, you will be approaching integration with a strategy that scales as your cloud adoption does.