By Jung Hwang, Enterprise Solutions Architect, VMware
Imagine you are a
general contractor building a house for a family. Without meeting them, you decide it should have three bedrooms, two bathrooms, and a two-car garage. When the family moves in, you have to begin renovating immediately—they have four teenage daughters and a baby on the way.
We all know that adding another bedroom, another bathroom, and doubling the garage is more costly and time consuming than it would have been to build the house to fit the family in the first place. So why do IT organizations so often make the same mistake when building out the Infrastructure as a Service (IaaS) environment?
I recently saw this with a large financial institution that deployed their infrastructure to support an initial set of low complexity infrastructure use cases. Everything went fine until they started adding other IaaS use cases, including Database as a Service (DBaaS) and Big Data as a Service (BDaaS). To accommodate larger, faster, low latency, and high IO workloads, they were forced to scale up their existing blade servers but discovered their NFS storage environment wasn’t sufficient to support the new workloads. They ended up redesigning their underlying hardware platform, including compute, storage, network, and security.
It seems obvious that a lot of “renovation” could be saved by understanding which services will “live in the house” first. So why do IT organizations often fail to employ that foresight?
Simply put, it can be complicated. For each offering in the service portfolio, there are a number of questions to answer: Is this going to support a multi-tier application environment? What are the dependencies? What are the SLA requirements in terms of performance, scalability, availability, security, recoverability, and manageability?
Infrastructure as a service, however, is perceived as a simple choice. The traditional server farm is already built so it seems easier to replicate a subset of that farm into Infrastructure as a Service.
That’s why I use this 3-step methodology to help simplify this process, making it easier for IT organizations to start with the right foundation to support their ongoing growth.
1. Service portfolio management
Define which services you want to offer. It will be nearly impossible to identify all the different service offerings up front, but the IT organizations should be able to identify a few different tiers of service, or a classification of services. Many customers follow the standard T-shirt size model for IaaS: Small, Medium, or Large. Some customers break down the service tiers into a number from 1 to 6 (with tier-1 for the most critical) and assign SLAs to each service tiers.
2. Service delivery and quality management
Next, design your automation and orchestration architecture leveraging the underlying supporting infrastructure. From the infrastructure perspective (storage, compute, networking, security), how do you support the service portfolio? Let’s say it’s a tier-1 application; it requires X type of performance; it’s going to require X level of elasticity in the system in order to scale; it requires X level of availability from the uptime and recoverability perspective; it needs to be delivered in X minutes/hours. The underlying management and infrastructure layers have to be able to support those requirements.
3. Service financial management
Allowing the users to choose what to deploy, and the cost associated with the request. This is one of the consistent ways to change users’ behavior. If you allow users to deploy four CPU VMs, it’s difficult to reclaim two CPUs from the user even though it is not being utilized. With the service financial management process in place, you have an ability to bill users based on the actual usage and correlate that usage with cost. Now you can tell the customer, “If you decrease your resources from 4 to 2, then you’ll be realizing $X in savings.” This helps identify the right cost structure and model for the organization. Some companies have implemented an allocation-only cost model, but pay-as-you-go, utility based, and hybrid cost models are becoming more popular to address one-time and ongoing operational cost concerns.
Too often, I see IT organizations reverse these steps. They try to develop service delivery and quality or the underlying foundation without understanding what services they plan to offer. Then when the business introduces new use cases, they have to procure additional hardware and augment or introduce additional processes, which wastes time and money. This may also require a significant amount of effort in architecture augmentation and re-engineering.
When this situation happens too often, the lines of business decide the company’s private cloud cannot meet their needs and they start to look for alternative service providers who can meet their demands. For customers who want to avoid that and to be able to offer high-performance IaaS privately, these three steps will help them build their house the right way from the beginning.
Jung I. Hwang is an Enterprise Solutions Architect and a member of VMware’s Services organization. Jung is responsible for creating solution roadmaps and execution plans with VMware’s products and services portfolio to solve customers’ business and technology challenges and initiatives.
