Cloud computing has changed the way IT resources are designed and managed. Siloed IT departments have to adjust their business-as-usual approach.
As companies seek faster, better and cheaper IT resources, hybrid clouds seem like a natural fit. They allow IT to shift workloads between internal data centers and a commercial public cloud provider during peak periods. For growing businesses with variable needs, cloud computing can reduce costs while boosting project flexibility and time to market.
Cloud computing has begun to gain traction in corners of the enterprise.
But the cloud still raises IT hackles. Managers worry that clouds violate traditional departmental domains and practices, and organizational inertia can run deep. A cloud also imposes new demands on IT infrastructure, from networks to servers, and can strain the relationships between their respective teams. And cloud pricing and licensing continue to pose serious challenges that further entrench divisions and cut into cost savings.
Still, cloud computing has begun to gain traction in corners of the enterprise. So how can departments bogged down by inertia take the next step? They can start by considering some of the factors that block many cloud implementations, including their own long-standing silos. In this series, we'll look at each of these cloud blockers, starting with the network challenges and security fears.
Networking obstacles in the cloud
Cloud computing offers IT far greater flexibility in how it delivers services. When a new project crops up or a workload's demands shift suddenly, IT departments can move the work to a commercial provider or move resources internally until the peak period elapses.
But that flexibility can also pose networking challenges. By moving applications off-site, companies need good network connectivity between a data center site and a public cloud provider so users don't experience performance degradation. Good connectivity comes in two forms: necessary bandwidth and low latency. Most businesses have sufficient network connections to support email, Web browsing and general company communication.
Adding traffic to the connection between an external cloud provider and a company requires planning to protect the application or the original uses of the network connection. A typical data center network -- particularly one with gigabit networks -- has a lot of bandwidth and low latency.
IT managers can also monitor internal network equipment usage to diagnose problems. But when you move an application offsite to a cloud provider, it is no longer part of your data center network. To access the application, your network traffic must take a longer route across smaller network links and links with greater latency. My PC, for example, uses three network segments, or "hops," to reach my company's HR application and has a network latency of 0.3 milliseconds.
Moving that application to a commercial cloud provider creates additional delay of about 20 milliseconds to a server in a commercial cloud. It travels across network segments of unknown size and that cannot be monitored by internal IT staff. Some applications suffer greatly when network latency is introduced, especially if parts of an application, such as a database, are in-house and parts are in a commercial cloud.
Most commercial cloud environments charge for network use. Charges of 10 cents or 15 cents per gigabyte of traffic aren't exorbitant. But charges start to add up, especially when most organizations take their own fast network speeds and flat-rate pricing for granted. When you consider backups for your cloud-based apps and data refreshes, new deployments and other day-to-day operations with your applications, you may spend money in unanticipated ways.
Cloud security: Use what you know
Security always needs to be part of a cloud implementation plan. Private cloud challenges are similar to those in existing virtualization projects, though, so most enterprises shouldn't be surprised by the requirements. But hybrid and public cloud models change security measures somewhat.
More on private cloud
Private clouds can draw on your IT group's traditional security models, using classic network segmentation techniques, such as virtual local area networks, firewalling, and intrusion detection and prevention systems. Newer cloud technologies, such as VMware's vCloud Director, propose new ways of implementing firewalling and network isolation. While they aim to improve an IT staff's efficiency, these new techniques can run afoul of existing security and networking practices that establish policies, procedures and methodologies for securing environments. Getting these teams involved early in the process of developing a cloud is key for proper adoption.
Hybrid clouds present particular data access challenges. In response, some cloud deployments adopt fairly paranoid stances toward commercial clouds. They generally assume that you cannot trust the security of the network between an internal data center and a commercial cloud host, nor can you trust the security of the network between two virtual machines in a commercial cloud. They also often assume that you cannot trust the security of a cloud's underlying storage or storage network.
There are solutions to these problems, which are sometimes included in a cloud product or underlying virtualization technology. VMware, for example, offers virtual private networking capabilities as part of its vShield suite of products. The VMsafe application programming interface and other products, such as VMware vShield or Altor Networks' virtual security suite, can achieve virtual firewalling. But all these products add cost, staff training, and support time to a hybrid or public cloud deployment. So you need to consider whether you have personally identifiable information or just data that is crucial to your business, such as a customer list. Different kinds of data dictate greater or lesser degrees of security.
About the author:
Bob Plankers is a virtualization and cloud architect at a major Midwestern university. He is also the author of The Lone Sysadmin blog.