Many times when we think of “cloud” we think of the elastic compute and storage, but we forget one very important thing, connectivity. Even though connectivity is no part of the cloud itself, it does have a direct bearing on how we access it, use it, and play around with it.
If our connectivity to our private or public cloud is slow, we stop using it. It’s that simple. But, if we do not experience any latency or lag when we access our cloud, we normally take full advantage of it.
Case in point: If we are paying for a public cloud, and our connectivity is slow, we automatically think it is our equipment that is failing. “How could a public cloud provider be slow?” you may ask.
The number one thing to do though is make sure “you” are not the slow one. No sense calling the provider up and breathing fire at them, if they are not the ones that are slowing your work down. I have made that mistake once or twice, but after feeling outlandishly stupid when I was proved wrong, I stopped it.
There are several sites out on the Internet that measure your Internet speed and connection type. I would highly recommend that you take advantage of them. If you should use any of them, and they show “good”, then its time to call for support. Once you get someone on the phone from tech support, there are a few things you need to share with him or her:
- Type of cloud (private, public, or hybrid)
- Type of connection you have (and name the provider)
- Number of individual instances you have in the cloud (do not count clusters unless the provider load balances for you)
- Account Number
Once you pass this information, and they run a system check on the Compute nodes, they will ask you what you are experiencing. That’s the problem, because it may not be slowness that makes things run in a degraded state.
Connectivity is pretty simple to diagnose. Many run “ping” to see the response times, but in corporate America, “ping” is disabled because of security concerns. As simple test would be to SCP or FTP a small file (e.g. 1MB). Notice your times “sending” and “receiving”. Then give those times to the support people.
This will help them see if it is actually a connectivity issue, bandwidth saturation issue, or an Instance (guest OS) issue.
So back to the main point of having good connectivity. Connectivity is the first thing that gets designed by the architects of your company, or your public cloud. The types of protocols and packets of data that are allowed to and from your cloud.
Also, many people take advantage of “instant on” connectivity. This is cheaper than having a dedicated circuit. Once someone tries to access the cloud, the network picks up the transaction, and activates the interface so it will make the connection to the cloud, and then establish traffic moving across it.
Regardless of how you access the cloud, it must perform in such a way, that you will want to use it. If not, build a local cloud and use your LAN to access it. There is always a way of getting to a cloud somehow!
By Richard Thayer
Richard currently is the Director of IT for OSG, an International IS/IT Company based out of Irving, Texas USA. With over thirty years of hands on experience, and 16 vendor certifications, he directs and/or assists many Fortune 500 companies in the direction of Cloud, Infrastructure and Migrations. He is a professional speaker and author of both Science and Non Fiction.