Build and they will come…
“If you build it, they will come” is one of those cliches that have been proved wrong over and over again throughout history. Cities, railway systems, buildings, airports, luxury residents and other such structures have been built, but barely or ever used. There are many interesting reasons for such failures – cost, location, convenience, surrounding dependencies to name a few, but all of these boiled down to some aspects of planning or lack thereof.
It is always fun to build something, say for example, a new Cloud infrastructure. Ok, I am sure you saw this Cloud association coming ! With all the technology and tools available to us, building a Cloud environment to meet our business needs is a challenging but interesting venture. Once this infrastructure is built, now what ? It is one thing to have a kick-“donkey synonym” state-of-the-art Cloud Data Center, but a whole different ball game to actually put users on it ! This is what I want to focus on, the “..they will come” part.
For most enterprise environments applications and data have evolved over time and it’s fair to state that they have a very complex dependency model. At the same time, the network, servers, storage and other Data Center elements have also evolved. Cloud service providers, regardless of what flavor of Cloud (Private/Public/XaaS), will have to think about how to interface the new Cloud environment with existing, often legacy environments.
Migrating and on-boarding tenants and applications from an existing system to new Cloud environment is not an easy process. If this is not thought through and diligently planned, then you run the risk of a Cloud environment under-utilized or idle.
The assumption here is you have a multi-tenant enabled Cloud infrastructure with well defined service offerings that map back to Cloud elements. There could be several on-boarding scenarios but the most common ones are:
– new tenants with new workloads, fully sustained within the Cloud infrastructure
– current consumers of IT services (apps & users) being migrated to the Cloud infrastructure
In either case perimeter connectivity is going to be important – how are these consumers going to be accessing the Cloud resources. Figure 1 shows a foundation approach which takes into consideration inter and intra Data Center connectivity. There are many options here both for Layer 2 and Layer 3 depending on the requirements.
This interface into current or extended infrastructure provides the foundation for migration and on-boarding different types of workloads. Documenting all aspects of “what” and “how” and maintaining your attention in this blog is going to be impossible as the methodology varies between different environments. Figure 2 below shows some of the events that need to happen and the decision points on one of the three migration strategies – forklift, staged and parallel.
Application and data migration has a dependency on the underlying consumer model and the various service offerings. Infrastructure connectivity and resource planning has a critical impact to how the users of the Cloud resources will communicate with other systems:
– Network connectivity across all application/user touch-points have to be established
– Resource planning across all technology stacks to ensure scalability
– Compute resources have to be meticulously allocated ensuring elasticity characteristics of Cloud
– Data migration across storage networks have to be facilitated to ensure data integrity
– All common elements driving traffic policies like the firewalls and load-balancers must have appropriate rules to allow traffic
– Critical application common services like DNS, authentication, DHCP, license servers, etc. must be accounted for
– Operations elements across new and current systems must be aligned both from process and management perspectives
– and this list goes on and on into much more details of everything we talked about
Obviously there is much more to this discussion than what I have covered. There are technical and non-technical aspects of project planning, establishing move groups, operations analysis, high availability – BC/DR, SLAs, service assurance, testing and validation, facilities readiness, scheduling, etc. that also needs to be considered.
Cloud projects are very visible. Failed Cloud projects (and they do happen) are even more visible and most likely are resume generating events ! Enterprises build Private Cloud infrastructure with the hopes that it will drive IT service adoption across it’s business units, operating companies or departments – which in the short term, will shape into revenue streams and further business opportunities. The first issue in a production Cloud environment is visible enough to disrupt business, consumer confidence and pose a threat to future potential business. This is more visible in Public Cloud scenarios but it’s far more common than what we think in Private Cloud deployments. Bottom line, proper planning is not only critical in the Cloud build process, but also in how to move data into the Cloud planning.
Ok, now for my shameless plug. If you are currently involved in a Cloud project and attending Cisco Live 2012, in San Diego, then please do check out two sessions my colleague Kannan and myself are doing. We hope to walk though designing/deploying a Cloud solutions and then what we need to think about to move workloads to this Cloud environment. The session IDs are:
BRKDCT-2251: Designing and Deploying Enterprise Cloud Solutions
BRKDCT-3252: An Infrastructure Approach to On-boarding and Migration to a Cloud Environment
In summary, what I am trying to say here is, establish a solid migration and on-boarding methodology in parallel to building your Cloud solutions and they WILL come to the Cloud !
By the way, would love to hear about your experiences on this topic, the good, bad and the ugly !Tags: