Earlier this week I was on the telephone with a potential client discussing their intended cloud use and the volume of data they aim to upload. We discussed who would use this data and when and why. As our conversation progressed, it became apparent that this customer could have some real issues in data retrieval and use. I was concerned that they could experience cloud gridlock.
In a shared environment such as your company’s network, or even a public network like Starbucks or McDonald’s, how many times have not noticed the Internet was slow? Meanwhile – we are additionally presented with hundreds of data choices. Today data is one of the single most important assets to any company. If you cannot access your data or access it quick enough, you may find yourself out in the cold.
After our conference call I jotted down a few notes that may be useful for you to think about. Some of these are obvious while others remain an ongoing annoyance.
Know your cloud provider – do they have their shop set up in a data center or in the back of their on site server room? This could be an issue because if your provider is using their locale to house their hardware, it means you will be relying on their local Internet connection as well, not to mention their failover and disaster recovery procedures.
Know what speed your data can safely travel – how will your normal users access this cloud? Users typically connect to the Internet from various locations including work, home, retail outlets, restaurants to name just a few.
How much data are you serving up – will your users be accessing your cloud and data a little at a time or will they be drinking from a fire hose? If you are trying to serve up all the data you have in one big chunk, your users may be waiting for some time to view their data.
Does your data need to access remote data – do your users have data on their work computer, what about their notebooks?
Will you data be served up exactly the same – will your users see the same data, or will they be able to customize the data views and content?
How many clouds do your users need to access – is all your data stored in one central repository, or do your users need to connect to several locations to access their data? And what if your cloud uses multiple cloud sources? How long to you need to wait to obtain all the data?
Do your users know how to use your cloud – this is probably one of the most overlooked areas when it comes to any technology. It is assumed that the user can understand the logic behind your application and figure things out for themselves. If this is the case, you may be setting yourself up for a rough ride. Untrained users can spend a lot of time poking around looking for their coveted data, and this takes bandwidth.
What are the cost associated with the above items? Think of it this way – some cloud service providers charge for bandwidth usage. Meaning if your user is viewing data, you are paying for the transfer of that data to your user’s computer or notebook screen. This can lead to some pretty huge monthly bills. Plus the fact that your users may not have the right or current information they need.
In the most simplistic form, some people think of cloud gridlock as a slow data transfer, but it is much more than just a slow Internet connection. If you are using a home-grown application, how is it written? Do your programmers use the latest technologies? What programming language is your application written in? ASP.NET, Java, Ajax, Drupla, Joomla, Ruby on Rails, XML or something far worst like Cold Fusion, Cobal, C+, these languages are not always Internet or security friendly? I am not trying to single out bad programming languages here, That should be a different topic all together. I am just pointing out that you should know what languages your cloud application is using and the pros and cons. Do you homework.
If you would like, we provide a Free Technical Assessment, this can be beneficial to new and startup companies that are not sure where to start.