“Go West, young man.” This is the line attributed to Horace Greeley who, as editor of The New Yorker in the 1840s, was heavily promoting the settlement of the western United States. He helped touch off the massive western migration that brought my great grandparents to the West Coast.
If Horace was alive today, he would be saying “Go Cloud, young man (person?).” Today there is a massive ongoing migration to the “Cloud”. Whether companies and organizations are pursuing the twin sirens of lower operating costs and greater agility or reacting to an executive who read in an article in an in-flight magazine that the Cloud is in, every customer is trying to plot their path forward. Not unlike the migration west, the road is not always well mapped and the trip is fraught with perils.
It helps to be clear about the definition of cloud. The term speaks to both a service delivery model (SaaS, PaaS, IaaS, etc.) as well as a resource management model (pools of shared, elastic IT infrastructure). Thus for some, cloud speaks to the use of public cloud services such as exporting Exchange processing to Microsoft’s Office 365 or moving applications out to Amazon’s AWS. For others, it’s about building out an efficient internal (private) cloud infrastructure where applications can be spun up rapidly to improve business agility. For most, it will be some combination of these two models in what is known as hybrid cloud.
Regardless of the cloud model chosen, the most significant challenge will be moving applications to the cloud. When my relatives moved west, their biggest challenge was packing all their worldly belongings in a covered wagon and driving across 2,000 miles of rough trails, deserts, mountains, and rivers. Today’s path to the cloud is no picnic either. The applications are both the valued possessions of the data center as well as the anchor that greatly inhibits progress.
Most large organizations that have been in existence more than ten or fifteen years have collected a rich variety of applications. It is not uncommon to find legacy applications that date back decades into the primordial days of IT. As the organization grew and evolved, these applications were poked and prodded to try and keep up with the needs of the business. Monolithic mainframe apps became client-server apps, which evolved into multiple tiers, which were then interconnected with other apps and newer services and pretty soon we have spaghetti. Today, many of the interconnections between application components are poorly documented and built with fixed IP addresses or other mechanisms that force these components to communicate via a Layer 2 network. When we then try and move a specific application towards the cloud, we often discover we stretch and break these interconnections, causing applications to stop working.
We are left with three options. We can leave the application where they are. We can abandon the legacy applications and replace them with new third party applications, possibly leveraging a Software as a Service model. We can rewrite the applications, rebuilding the interconnections, replacing old components, and moving off legacy servers to facilitate the move to the cloud. Most organizations I talk with are doing a little of each. In the end they will end up with three or four different types of infrastructure:
• Legacy, non-Intel servers such as mainframes and Unix RISC servers. Generally these environments shrink over time as application migrate.
• Virtualized data centers built on virtualized, higher end Intel servers, probably running VMware, supporting high end storage, both Fibre Channel and NAS, all built to provide 5-9s of availability. This generally constitutes the bulk of the current IT infrastructure and applications.
• Internal cloud environments, built on commodity Intel servers, using NAS, iSCSI, or direct attached storage, probably using Open Stack orchestration and virtualization. These usually start small and grow over time.
• Public cloud infrastructure, leveraging a variety of Software, Platform, and/or Infrastructures as a Service based upon the functionality and ROI of the options.
Over time, applications will migrate from the first two environments toward the private and/or public cloud. The speed of the migration will depend upon the needs and resources of the organization. And like the move west, this migration will need a well marked path, a network that ties all four compute environments together to keep the applications running and the data flowing during the migration. This series of blog posts is intended to describe the vital role the network will play and the steps you should take as you head west towards the cloud.
