To cloud or not to cloud? …

September 23, 2013

A long time ago I wrote a blog about how to set up a small business server to maximum efficiency for all the different components going on in that box (Window Small Business Server). While reviewing some old documentation I came across this article and thought about updating it to include SSDs, solid-state caching and tiering technologies. However, as I pondered this question and looked a little deeper, the question changed …

It seems the real question today, with the demise of SBS, is … “Do I put my data in the cloud or do I keep it inhouse?”

Now I’m totally isolated to my corporate inhouse network environment being a remote worker, so I look at this with a specialized viewpoint, but I thought I’d cover a few of the questions and seek your input. I hear from people a lot … I’m not putting my data at the mercy of my internet connection … good point – however a closer look tends to dispel a lot of that issue. This of course depends on your work type and environment, but there is a lot of commonality for all workers here so please read on.

I work remotely, while family members work in offices inside corporate environments. I have all my data in my laptop (backed up of course), while the wife has no data in her workstation – it all resides in the server. So what happens when the internet goes down? We both scream blue murder. Sure I can type a few blogs, and probably develop a few power-point presentations, but both my wife and I will surely fade away and collapse if we don’t get access to that next email we so keenly expecting and waiting for.

On the other hand, my wife uses an accounting package that she can spend many hours in without connection to anything except her local machine and merrily work away quite successfully without internet connection.

So what needs to be local and what can afford to be remote? Simply put (imho), if I’m a knowledge worker requiring local data then that data needs to be local so I can access without hinderance in both access and performance from the internet. My email, however, can live out on the internet because it doesn’t matter whether it’s local or remote, if the link is down and I can’t receive (or my email server can’t receive) then it matters little to me what the cause is, I just won’t get email (and can’t send either).

I see this sort of mentality more and more in small business across Australia – put my email in the cloud (normally hosted exchange) but leave me fast access to local data so I can open and close my large files quickly on my fileserver.

While this sounds very simplistic, it actually has quite an impact on the storage needs of the two locations. If the local server is just doing fileserving (unless it is for millions of people) then SATA drives in RAID 6 is fine. On the other hand, if the cloud-based storage is handling large numbers of virtual exchange installations, then it will need some serious grunt to handle that.

Now complicate the matter further and ask where the backup should be. Should that be local or across the internet or both? Likely both is the ideal answer but that again does not require much in the way of performance storage hardware.

So what impact is this having on a company like Adaptec? Simply put we, like everyone else, are rapidly getting our head around the datacenter – the place where all those virtualized exchange servers live in the above story, because that’s where the pressure on storage is today – the local stuff is pretty easy in comparison. So if you are in the datacenter industry – handling other people’s data, then look at our current and upcoming products – they offer some interesting features suited to those specialized applications.

What is your opinion? Data in the cloud or local for Small Business? What makes sense to you?



Leave a Reply

Your email address will not be published. Required fields are marked *

× 2 = sixteen

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>