Will Network DNA Sabotage Your Journey to the Cloud?

After more than four years “in the cloud,” I have come to the conclusion that one of the most difficult challenges for large enterprise customers to overcome on their journey to cloud is the DNA of the network. This is true regardless if the customer is simply consolidating standardized services to be delivered via an on-premise private cloud or consuming services from a cloud provider (private, hybrid or public.) Each Network DNA strand seems to oppose a core value proposition for cloud, such as virtualization, automation, self-service, and workload mobility just to name a few. Fortunately, “gene therapy” treatments are available which can significant improve the quality of experience and service from any cloud.

Before describing each of the Network DNA alterations needed, I would be remiss if I didn’t mention the No. 1 challenge enterprise customers’ face on their journey to cloud: human behavior. IT teams are accustomed to building services, but must be willing to enable automation and self-service and consume services. Internal customers used to IT meeting 100% of their requirements must be willing to use services that may only meet 80% of their needs, but do so in a more cost effective and timely matter. Without changing these basic behaviors, enterprises will continue to struggle with requirement bottlenecks, lack of business agility and issues concerning expense and/or compliance due to “shadow IT”. The bottom line is that changing human behavior is almost always the biggest challenge to harnessing the value of any disruptive shift in technology — the cloud is simply the latest.

Network latency and lack of network bandwidth have always presented challenges to enterprise customers. Amid the ever-expanding demand to quickly send larger amounts of data to more users around the globe, the network has always struggled to keep up. With the more recent explosive growth in enterprise mobile and real time services (e.g. voice, video, analytics, etc.), the network latency/bandwidth challenge has intensified. Moving to a cloud service delivery and/or a cloud service consumption model, can either cause the customer to lose this battle or gain the upper hand.

Many large enterprise customers have optimized workloads with dedicated environments (server, storage and network). Switching to a virtualized/shared environment can have a tremendous (and often under-estimated) impact on the performance and thus experience of the users. Consolidation also requires dealing with larger geographic distances, then this impact is even greater. I have seen many cloud experiments end here with an assumption that this application workload is not cloud ready but it doesn’t have to be this way.

The first step is leveraging Application Delivery Control (ADC) to optimize virtualized and remotely accessed applications. It is important to determine if the application has special optimization requirements and whether the ADC supports the preferred deployment. For example, cloud based SAP environments can only be fully optimized by certified ADC vendors. Similarly, some ADC vendors do not support KVM or Xen, which would then require physical appliances with limited elasticity. The IBM SmartCloud works with a variety of ADC vendors including Citrix, F5, Radware and Riverbed/Zeus so that we can work with a broad range of customer requirements.

A second step is directly related to global reach. Large customers often want to reach new markets (e.g. BRIC countries) via cloud based services. To deliver the highest quality of experience and with the required SLAs is only possible via the virtual network overlay (VNO) model. Network latency and bandwidth limitations that stem from basic laws of physics often require a distributed, rather than centralized solution. Other geographies may require business data to be kept within certain borders, which in turn means that the associated services are similarly restricted. Building cloud data centers in all required geographies will not resolve the issues since many cloud based workloads are distributed and loosely coupled (i.e. actually composite services whose individual components may be delivered from multiple locations and/or multiple vendors). Fortunately, IBM has long partnerships with Akamai and Virtela who provide VNO based services, that can patch together disparate services over large geographic areas.

Network virtualization and automation are essential to ensure that the cloud is truly elastic. Ignoring elasticity can cause your cloud journey to reach a dead end. This need for elasticity drives requirements in the following two areas:

Increasing the speed at which new services can be made available to new clients Decouple network services from the underlying physical equipment

Managing IP addresses with spreadsheets and homegrown database solutions cannot keep pace with the “need for speed” and this need will only increase with the need to accommodate new requirements like IPv6. Automating and managing network DDI (DHCP, DNS, and IP address management (IPAM)) services as part of a service orchestration/delivery is a key requirement for cloud. These DDI services are necessary as cloud services, VMs and connected devices proliferate. IBM, Juniper and BlueCat have partnered to help customers ensure that their journey doesn’t get sidetracked due to the lack of DDI automation (Building a Smarter Network with IPAM).

Standards organizations and cloud communities (e.g OpenStack) have only recently started to focus on virtualizing networks and providing these resources as a service. Networking equipment that implements these virtualization and automation services will be much more suitable to cloud computing. However, today’s networking equipment is relatively inelastic when it comes to most services. Fortunately, there have been great strides made in software defined networking. This is particularly helpful workload mobility requires substantial elasticity in network resources. There are a number of innovative software defined networking vendors who specialize in moving virtual application environments, independent from the underlying networking equipment. This can improve agile development and operations (Dev/Ops) and also significant reduces costs.

Understanding the end-to-end networking for a cloud environment is essential. Most software defined networking does a good job of enabling workload mobility between “like” environments. Unfortunately, the IT landscape within data centers is rarely homogeneous. In addition, most large customers want to leverage hybrid cloud and there is little chance that the on-premise IT landscape will be similar to a cloud service provider. There is also a misconception about the net value of live workload migrations that retain application state. While this may sound appealing, it even further solidifies the need for the mobility to be between like environments and forces “lock-in” to technology and vendors. For most workloads, it is more important to “capture” an existing application with its corresponding networking context and then quickly spin up a new virtualized environment for that application with its networking context intact. This approach not only allows the customer to move workloads between diverse environments but it also can help transition legacy application environments to the cloud. IBM SmartCloud is currently working with CohesiveFT and AppZero in the context of our Elastic Enterprise Application Services partnership (Elastic Enterprise Application Services).

I expect the network to make g
reat strides in developing “Cloud DNA” over the next few years. However, like all aspects of the cloud, the network will need to continually evolve keep up with the growing demands and expectations placed on it by applications and users.

The rest is here:
Will Network DNA Sabotage Your Journey to the Cloud?

Related Posts

Comments are closed.