The term “cloud” was first used by the telecomm industry in early schematics of the Internet to identify the various, non-specific uses data was put to at the end of their cables. The transmission of data was the telecomm industry’s primary focus. What happened in the cloud was someone else’s concern.
Today the attention has shifted so much to all the amazing uses data can be put to within a cloud environment that there is an unfortunate tendency to overlook how all your data is going to get safely and reliably to the cloud and back. It’s a little like focusing on all the great things you plan to do in Paris without considering how you’re actually going to get there.
Critically evaluating your network options may be less exciting than focusing on your ambitions in the cloud, but before you send your data off on its great adventure, you better be sure you know how it’s going to get there and get back.
Rest assured: You can safely assume that there are secure network options for every cloud implementation, but there are many details to be considered to before you decide which options are best suited to your needs and resources.
Admittedly, unless you are a network geek, thinking about networking can be a daunting task so, if you don’t know CCIE from TCP, here’s a primer on the network options you can use to connect to the cloud.
There are basically three basic network options to connect to the cloud:
Virtual private network technology makes it possible for businesses to securely and affordably create geographically dispersed business networks on top of the public Internet infrastructure. A key advantage to VPN access is that it is relatively inexpensive because your data is traveling for free over the Internet. It is also relatively uncomplicated to implement. These advantages essentially launched a wave of businesses into the Internet, and from there to the cloud.
VPNs provide security by the use of tunneling protocols and through security procedures such as encryption. Encryption protocols include Internet Protocol Security (IPSec), Transport Layer Security (SSL/TLS) and Datagram Transport Layer Security (DTLS).
While your data is out hopping from router to router around the Internet, it is also kept separate from everyone else’s data by Multiple Protocol Label Switching (MPLS), a mechanism that basically establishes a virtual path for your data between your outgoing router and its final cloud destination. MPLS is the technical counterpart to the multi-tenant technology which keeps your data secure in its own virtual container in a public cloud environment.
Wide area networks connect multiple Local Area Networks (LANs) across an enterprise. Most WANs include virtual LANs (VLANs) that are connected by VPNs through local exchange carriers to the Internet. Here again MPLS protocol protects your data from mingling with other data within your WAN or on the Internet.
Organizations that adopt this option still take advantage of free Internet transmission of their data. Implementation, however, is more expensive and complicated. Accessing the cloud as a VPN extranet on your WAN is appropriate for mid-sized organizations that have a widely distributed WAN environment.
If you can’t get comfortable with the idea of your data hopping around the Internet with everyone else’s, point-to-point leased line connections (also known as private circuits) provide dedicated, always-on, fixed bandwidth connectivity between your data center and your cloud environment.
All three network options are secure, but point-to-point connections are the most secure. They are also the fastest and by far the most expensive option.
Point to point connections are appropriate for large organizations that have critical need and/or compliance requirements that require an exclusive, direct connection to the cloud. These could include financial organizations that require very high speed bandwidth, Government agencies and suppliers that require absolute security, and healthcare organizations that need to guarantee the privacy of patient data.
There are many variations and levels of speed, quality and security within each of these three options. Drilling down into the pros and cons of those variations is beyond the scope of this column. Suffice to say, one, or some combination of them, can be tailored to adequately and securely get your data to your cloud environment.
Combining more than one option, in fact, is the only way to guarantee against downtime. Every connection has the potential to go down—even direct point-to-point circuits, so having more than one connection is the only way to protect against the risk of losing access to your data in the cloud.
Acceptable risk varies with the criticality of the use case. If you are just spinning up virtual servers for a test dev sandbox environment, you don’t have to worry about losing access to your data. If you are a hedge fund involved in high-speed trades, on the other hand, any risk of downtime is unacceptable.
There are two other key considerations you need to address in your choice of network option: bandwidth and latency.
Bandwidth requirements depend on what you plan to do with the cloud services. If you are accessing IaaS in the cloud, it takes little or no bandwidth to manage monitor and maintain the virtual container a cloud provider provides you. If you are going to run a SQL database or do transactions in real-time or nightly backups in bulk, however, you are going to need additional bandwidth to accomplish your tasks within an acceptable timeframe.
Most application providers publish bandwidth guidelines. According to Microsoft, for example, a SQL database requires bandwidth ranges of 3 megabits per second (Mbps) (dual T1) and greater with latencies less than 100 milliseconds (ms) – operational range. You can quantify your bandwidth requirements by adding up the required throughput of the applications and services you intend to access from the cloud. If you are already accessing these services within your data center, you should know that number
Latency is basically a measure of the delay between when a packet of data is dispatched and when it arrives at its destination. Every medium of transmission—cable, optical fibre, etc.—causes latency. Latency limitations determine the distance you can be from your cloud environment.
Latency is also determined by the relative well being of your network environment. It’s not your ISP’s fault of data from your cloud is delayed unduly because your firewalls, routers and servers delay transmission once the data arrives at you door. With all the demands that virtualization, collaboration, BYOD and a host of other hot trends have made on your network environment, if you haven’t done a comprehensive assessment of the health and capacity of your network, making that a priority before your journey to the cloud would be an excellent idea
Using the cloud metaphor for the underlying technologies involved in delivering IT as a service runs the risk of encouraging a sense that the cloud is some stack of servers out in the ether that belongs to someone else. As soon as you make a commitment to use cloud-based services, in fact, you expand your corporate environment to encompass your internal IT environment, your network connection to the cloud and the cloud itself. They are each mutually interdependent and need to be addressed as integral parts of a whole system. Nothing works, unless they all do. Leave one out of your overall IT strategy, as a result, and no matter how innovative, creative, and cost effective your cloud destination may appear, you still won’t be able to get there from here.
By Mike Johnson
