Home > Blogs > VMware Operations Transformation Services > Monthly Archives: August 2013

Monthly Archives: August 2013

A VMware Perspective on IT as a Service, Part 1: The Journey

By: Paul Chapman, VMware Vice President Global Infrastructure and Cloud Operations

At VMware, we now live and breathe IT as a Service (ITaaS). It’s a relatively new phenomenon, but many companies are beginning to make the shift.

In this short series of posts, I’m going to offer a VMware Corporate IT perspective on the journey to IT as a Service, looking at how we ourselves made the change, sharing some of the many benefits that ITaaS is bringing us, and offering some insights on how – if you’re considering taking the plunge – you might successfully make the transition yourself.

A Long Time Coming

First up, it’s worth remembering that the concept of IT as a Service is not that new. As a community of IT professionals, we’ve been talking about it for at least a decade. But for a long time, the obvious and daunting challenge of managing very complex IT infrastructures gave us an excuse not to act.

Fast forward to today: We now have Software as a Service, Infrastructure as a Service, Platform as a Service and so on – which creates a whole new consumption model for IT. These innovations make it very hard for IT organizations to keep hiding behind complexity as an excuse not to act.

Meanwhile, though, the pace of technological change has all but outstripped and outpaced internal IT’s ability to keep up with consumer-like demand, and that’s spurred the rise of successful innovation silos such as the Workdays, the Salesforce.coms, and the Amazons of the world – that have been happy to do the work instead.

You could say this is revenge of the business, with lines of business and developers now happy to bypass the IT infrastructure organization entirely, turning to external providers offering on-demand services and innovative business models.

In the face of this, most IT organizations struggle to keep up with demand for new services. Quite frankly, I think that even if they were funded to fully support the demand, most IT organizations still wouldn’t be able to keep up using traditional service delivery models. I think the inefficiencies and the lack of agility rooted in a heavy-human and “process-bound” way of doing things would just get in the way.  Even simply maintaining the status quo these days is enough to overwhelm and exhaust personnel.

Not Whether, But How Fast

That’s certainly how we saw things here at VMware. It wasn’t so much a question of whether to go on the journey to IT as a Service, but a question of how fast we could get there. In 2010, 99% of our servers were virtualized, and 20% of business applications were delivered by SaaS vendors. We saw the power of the shift to more agile service delivery. We established an executive mandate to further transform our IT services as soon as possible, and we also started to take an outside-in look vs. an inside-out look.

Our plan included four basic principles:

  • To get IT up to business speed;
  • To become much more efficient and agile in our operations;
  • To delight our users every day;
  • And to turn IT into an innovation center, not a roadblock.

These four principles still encapsulate what we expect ITaaS to deliver.

We knew that traditional service delivery models imposed numerous friction points between the business and IT. We also knew we had to significantly increase our levels of automation and self-service. We knew that our consumers were looking for us to act like an internal SaaS provider, and we knew that the solution was to move to a zero-touch, customer-centric model. With that, we committed to further increasing our SaaS portfolio, and we started our 1st private cloud initiative.

In 2012, 30% of our applications were delivered via SaaS providers, and we launched our 2nd private cloud effort. “OneCloud” is our internal IaaS private cloud based on a software-defined datacenter architecture. Within a year of launch, we now have 9 different large SDLC tenants groups internally and have approximately ~40,000 virtual machines in our private cloud.

Two Insights: Automation and Change Management

I’ll write another post about building a private cloud in the near future, but I want to share what I think is different today, that allows IT orgs to finally – and successfully – make the change to this new way of doing business. Here are two quick insights:

First: The move to third party cloud services offers IT a route back to relevance and value.

That may sound strange coming from a vendor that sells virtualization solutions, but the workloads we shifted to third party providers are the easily-siloed and more mature business processes – sending HR processes to Workday, say, or ITSM to ServiceNow, or SFA out to Salesforce. They are important, but they are not the mission-critical processes that differentiate us in the marketplace.

We found that by dismantling the “soviet era” systems that were running those paper-based processes and moving them to the cloud, we freed up a significant amount of internal resources from having to focus on the things that really did not differentiate us in the marketplace.

What remained, and what we’ve been aggressively moving to a private cloud SDDC environment, are the systems that are often more complex than what we moved to SaaS provider – systems like our license management system myvmware.com, or our online training hands-on labs (hol.com), or provisioning dev and test environments for hundreds of developers who use these applications every day. But the agility and efficiency we gain by maintaining them in house, in a private cloud, directly impacts our customers and supports our revenue growth objectives.

If you look at what many IT organizations spend on the services they don’t silo off elsewhere, 60-80% of it is spent in just keeping the lights on. And when you break it down even further, a lot of that goes to what I call “human middleware” – people doing standard repeatable work: install another database, install an operating system, maintain that database, maintain that operating system. We are actively and aggressively replacing our human middleware with end-to-end automation with impressive results that are a win-win for our customers, our business, and for IT.  Many of the traditional roles that are shrinking are shifting to more meaningful roles, and we are finding our IT professionals are learning new and more relevant skills.

The Promise of Change

That leads to my second insight: The shift to ITaaS is daunting to IT employees, but it offers them a great opportunity.

It’s not hard to make the case that an IT as a Service strategy unlocks levels of agility and efficiency we’ve never seen before. But we also need to consider how it impacts the people we’re asking to make it work. Fears, uncertainties, and doubts about the change are understandable, and it’s important to recognize that both personal and cultural challenges exist.

Change in our industry is inevitable and constant.  Who is still doing the IT job they did 10 years ago? But leading a transformation to ITaaS means that you need to paint a picture of a future state for your employees that highlights roles and opportunities that are much more meaningful than they’re used to under the traditional model. Who wouldn’t want to be relieved of rote and repetitive jobs and asked instead to be part of a forward-thinking and innovative sea change that can make a positive difference? This is important to keep in mind as you look to align employee incentives with the changes that you want to make.

In Summary:

  • ITaaS isn’t a new concept, but with new technologies, its time has come.
  • Even with better funding, most IT orgs wouldn’t be able to keep up with the demand they face today using traditional process-bound methods.
  • Shifting some applications to SaaS providers frees up IT resources and costs to automate and innovate where it really counts.
  • Shifting core differentiating business processes to a private cloud significantly improves agility, and creates new opportunities for innovation that weren’t possible in a traditional data center environment.
  • Finally, own the problem. Actively lead the cultural shift required to transform the architecture and operating model that enables IT as a Service.

In part 2 of this series, I’ll share specific details about just one of the IT groups that has transformed what it does based on a shift to private cloud. In part 3, I’ll look at agility: how we measure it and how we keep continuously improving. In Part 4, I’ll explain what it took to stand up and run our own internal private cloud with ~40k VMs.

Follow @VMwareCloudOps & @PaulChapmanVM on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Rethinking IT for the Cloud, Pt. 2 – The Cloud Services Financial Model

By: Khalid Hakim

Attending VMworld? Please join my group discussion on IT Financial Management (OPT1004-GD) on Monday, August 26th at 3:30pm PT in Moscone West, Alcove 3. Hope to see you there!

This series looks at what it takes to transform a traditional, passive-order IT operation into a cloud-based IT ‘shop’ selling services – turning what’s typically regarded as a revenue drain into a business enabler, revenue supporter, and value creator.

In part one, I suggested a few key points to help you identify how much each and every service in your cloud service catalog is costing your company.

Now, let’s place those services within a broader context: to deliver IT as a Service and run IT like a business requires a business mindset and a business model. So what should that model look like?

To start off, take the key business functions of manufacturing organization. These include (but aren’t limited to) product manufacturing and management, sales, marketing, HR, and finance. The product manufacturing department is responsible for using raw materials, machinery and labor to create a physical product (i.e. a mug). Its marketing and finance teams then establish a unit cost for the product and set a pricing strategy. Marketing helps with product promotion, sales does the actual selling, and finance is a horizontal layer across all these functions to ensure that the organization will stay in business.

Now look at the IT organization as a service broker. What does it need on top of the traditional IT planning, project and service management, architecture, development, and operations functions? Answer: a business practice within IT that penetrates every function across the stack.

If you want IT to be a business-trusted advisor, in other words, then functions similar to those of the manufacturing business need to be deployed to help run the IT service factory as a real business.

Product management (i.e. service management), sales, and marketing functions will facilitate and market service provisioning, and a finance function will account for service costs and encompass planning and budgeting for investments. It might sound like I’m just suggesting that IT requires an improved focus on investments that help the business generate more revenue. And sure, such an organization could be described as business within a business. But, in this case, IT is the business!

The Cloud Financial Services Model

I call this model the Cloud Financial Services Model. At its core is a focus on the Accounting, Budgeting, and Charging/Showback processes. These are the basic processes around which you can flesh out a full service broker business, as shown in the diagram below.

The model’s three core areas encompass the following:

–       Service Accounting: A full accounting of the service costs and expenses incurred will include tracking actual services costs, allocating all IT costs to services being offered, and correctly categorizing costs in terms of Fixed and Variable expenses, Direct and Indirect costs, Period and Service costs, and CAPEX and OPEX. Failing to allocate or miss-categorize these costs will impact your overall cost accuracy and transparency.

–       Service Budgeting & Forecasting: This covers the process of predicting, anticipating, and controlling your organization’s services investment and any other planned expenditures on both an annual and ongoing basis.

–       Service Charging and Showback: The showback is a reporting of cloud service consumption and costs, but is a step prior to charging as there is no actual billing involved. Charging is the process of pricing and billing cloud service consumers for cost recovery and value creation.

With these three areas in place, you can now build a set of Cloud Service Management Activities. Each has its own role to play:

–       Service Definition: Your cornerstone, 360-degree process for reviewing a  service, covering business and consumer management, and service and operations management. This includes identifying all the components making up the service chain and all cost drivers and their associated cost classifications & categorization, along with allocation bases. It will also, in turn, drive overall service costing accuracy and improve cost transparency.

–       Service Catalog/Portfolio Management: Your service catalog is the one-stop shop from which your consumers pick and choose services, so it must contain the right level of information, including cost and/or price. A service portfolio management budgeting and planning-based approach can help realize investment value far better than component- or project-based budgeting. Also, aligning IT cloud portfolio investment categories with business categories is a key step to the path to turning IT into a generator of business value.

–       Service Demand and Investment Analysis: Understanding the demand and performance requirements of both the business and cloud services will help drive a planned demand pipeline that in turns boosts the overall cloud service workload’s efficiency.

–       Standardization and Configuration Management: Standardization and realistic configuration management drive simplicity in service automation and provisioning, and hence efficiency in overall operations. Creating standard cloud service offerings with a high degree of standardization and automation results in operational expenses (OPEX) savings.

–       Service Operations Cost Optimization: Continuously looking for operations improvement opportunities is necessary along the operations journey. New cost drivers may continue to pop up during cloud service operations (especially privately operated ones) and thus IT management may run into cost overruns when unmonitored.

–       Value Measurement: It is generally important to consider a combination of financial measures (such as reduction in costs, revenue increases, and productivity improvements) and non-financial measures (such as performance, satisfaction and compliance).

–       Consumer and SLA Management & Reporting: Running strategic service reviews with consumer stakeholders ensures the continuous alignment and meeting SLA expectations – and that they’re getting value for their money. Producing a bill of cloud services consumption and total cost incurred to consumers is one of your key reporting and billing activities. It can kick off service improvement initiatives, driving service quality while optimizing and lowering costs.

–       Contract and Vendor Management: One way to look at cloud computing is as a new delivery channel for IT services. As a service broker, an IT organization acts as an advisor trusted to provide the required services to its consumers at the right quality and cost, regardless of where those services actually reside. Contract & Vendor management becomes even more important with public cloud services to ensure that service levels are being met and that demand is being proactively managed.

While the core Accounting, Budgeting, and Charging IT financial management processes are required for the cloud business management, those in the model’s outer layer represent the cloud-specific activities that will actuate your cloud financial management practices on the ground.

For example, Service Definition is a cornerstone activity as you need to define the boundaries of what you want to offer for each service. You can’t manage what you can’t control, after all, and you can’t control what you can’t define. Indeed, everything starts with defining your cloud services – of which service accounting and pricing become key activities – followed by publishing the right information to a broader IT service catalog. Service demand and investment analysis is then required to plan for future demand and to deliver services more efficiently at the right quality level, and so on, down the list.

The bottom-line: The Cloud Financial Services Model reflects how cloud service management activities are strongly tied to financial management core processes. Adopting it will help position you for success as you seek to transform IT from a cost center to value creator.

In summary:

  • Delivering IT as a Service and running IT like a business requires a business mindset and business model.
  • The Cloud Financial Services Model is a useful business model in this regard – offering a core focus on Accounting, Budgeting, and Charging/Showback (ABC).
  • The model also includes the various Cloud Service Management Activities via which you will deliver your financial processes.

In my next post in the series, I’ll take you though a cloud service costing exercise to show how you can calculate a cost for a specific cloud service.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Workload Assessment for Cloud Migration, Part 4: Getting Stakeholder Buy-in

By: Andy Troup

Successfully assessing workloads and placing them in the appropriate private, hybrid, and public cloud environments can make or break a cloud strategy, enabling greater agility and cost efficiency.

In this series, I’ve been reviewing four key areas to consider when performing a workload assessment. In the first three parts, I suggested a framework for classifying workloads as potential candidates for moving to a cloud environment, looked at service portfolio mapping, and examined how to assess the costs and benefits of moving workloads to a target cloud model.

In this final part of the series, let’s take a look at stakeholder analysis. How do you get stakeholder buy-in on your cloud strategy and roadmap?

First, Identify Your Stakeholders

When running a migration project, the first thing you should do is understand who your stakeholders are so you can make a judgment about:

  • Risks that specific stakeholders will hold;
  • Any unsupportive attitudes they might hold towards the proposed system;
  • How they can help indicate the overall socio-political feasibility of the system.

Here’s a sequence you can follow to be sure you have everyone (and their relative influence on the project) accounted for:

  • Identify each stakeholder by title and name.
  • What are his/her interests?
  • What level of influence and power will each have in the project?
  • In what capacity might each be most effective for the project?
  • How do you plan to communicate with each of them?

Don’t forget: There will be key stakeholders for the entire program of work as well as stakeholders for individual workloads (e.g. business units, application owners etc.).

Different Stakeholder Types

Stakeholders can be divided into four different groups. Each has their own set of concerns and drivers for putting workloads into the cloud:

  • Business Stakeholders:
    • Concerned about service disruption and service levels.
    • Drivers: Reducing costs and time to market.
  • Governance:
    • Concerned about compliance, risk impact, data security, provider certifications (SOX etc).
    • Drivers: Same as their concerns.
  • Technology:
    • Concerned about technical feasibility.
    • Drivers: Greater agility, not just keeping the lights on, but being able to implement more lights due to reduced firefighting, efficiencies, cost controls.
  • Operational:
    • Concerned about vendor stability/lock-in, SLAs, availability.
    • Drivers: Same their concerns.

The more you can understand your stakeholders drivers and especially concerns, the better equipped you are to ensure that they are on-board with your migration programme.

Applying Governance – A Matrix

Once you’ve identified your stakeholders and their concerns/drivers, you can place them in a matrix that calibrates their levels of interest and influence. This matrix will help you understand how to monitor and/or manage their concerns:


An Example

Take, for example, the case of supporting a decision around the feasibility of migrating your client-server application. Completing a stakeholder analysis will reveal that your proposed cloud migration will have many implications for the organization, including non-technical areas, such as the finance and marketing departments.

Overall, a positive net benefit may be clear to the business development functions of the enterprise and the more junior levels of the IT support functions. Yet the project management and support management functions of the enterprise might see a net zero benefit, while the technical manager and the support engineer functions might see a negative net benefit.

By doing your analysis, though, you will have identified all potential benefits and risks associated with the migration, and thus are able to accurately inform all stakeholders of factors that might either confirm or challenge their initial impressions.

The result: All stakeholders are heard and their perceptions accounted for, but none get to control the outcome without merit.


Remember the following points for successful stakeholder analysis:

  • Identify all stakeholders for both your entire program and your individual workloads;
  • Understand the concerns and drivers of your various stakeholder types;
  • Calibrate your stakeholders’ levels of interest and influence in order to best decide how to monitor and/or manage their concerns.

Finally, this blog is really trying to guide you in who to communicate to, how to communicate with them and when to communicate. If I can leave you with one message it is that communication is key to your success. The more information you can impart, the more confident your stakeholders will be in the success of the project. Tell them:

  • Why the project is important;
  • How the project will run;
  • The benefits for them and their department;
  • The benefits for the organization as a whole.

When you’ve finished telling them, start over and tell them again. Communicate, communicate, communicate.

Hopefully this series of articles has provided you with some insight into how to run your migration program with some snippets of information that you can take away and use. If you missed the earlier parts of this series, you can find part one here, part two here, and part three here. Also, check out our list of blogs on workload migration.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Your Official Guide to CloudOps at VMworld 2013


VMworld is fast approaching and, as usual, there will be no shortage of events and activities: We’ll be live-tweeting, taking photos and videos, holding Twitter contests, and writing recap blogs so you won’t miss a thing.

Sessions We’ll Be LiveTweeting

If you are unable to attend VMworld or don’t have room in your jam-packed schedule, we’ll be live-tweeting the following sessions from the Operations Transformations Track on the @VMwareCloudOps or @vCloud Twitter handle (keep an eye on our Twitter feed to see which sessions will be live-tweeted on either channel):


Moving Enterprise Application Dev/Test to VMware’s Internal Private Cloud – Operations Transformation with Kurt Milne and Venkat Gopalakrishnan


Operations Transformation – Expanding the Value of Cloud Computing with Phil Richards and Ed Hoppitt


Automated Provisioning with David Crane


The Transformative Power and Business Case for Cloud Automation with Rich Bourdeau and Rich Pleasants


IT Financial Management for the Cloud with Khalid Hakim


Automating, Optimizing, and Measuring Service Provisioning in a Hybrid Cloud with David Crane


Pivot From Public Cloud to Private Cloud with vCloud and Puppet with Edward Newman


Organizing for Cloud Operations – Challenges and Lessons Learned with Kevin Lees and Khalid Hakim


Balancing Agility with Service Standardization: Easy to Say But Hard To Do with Khalid Hakim, Dave Bartoletti, Ian Clayton, and Kurt Milne


SDDC IT Operations Transformation: Multi-Customer Lessons Learned with Valentin Hamburger and Bjoern Brundert


vCloud/SDDC Deployment with Venkat Gopalakrishnan


Transform IT Into a Service Broker – Key Success Factors with Paul Chapman, Kevin Lees, Rich Pleasants, Jeffrey Ton, and Heman Smith


Leveraging Hybrid Cloud to Transform Enterprise IT from a Cost Center to a Revenue Driver with Jeffrey Ton and John Qualls


Cloud Lifecycle Services with Rohan Kaira

CloudOps Contests

CloudOps Trivia

Show us that you’re a CloudOps expert for the opportunity to win some great prizes.

Here’s how to play:

  • Follow us on the @VMwareCloudOps Twitter handle, and look for tweets containing the hashtag #OpsTrivia.
  • #OpsTrivia questions will concern major VMworld announcements, as well as specific CloudOps-related activities.
  • Think you know the answer? @reply us at @VMwareCloudOps with your answer, and don’t forget the #OpsTrivia hashtag.

Winners will be chosen by accuracy and timeliness of response. By participating, you have the chance to win fun prizes such as laptops bags, flash drives, iTunes gift cards, and more.

Photo Caption Contest

The CloudOps Photo Caption Contest is our way of letting you have a bit of fun with the VMworld scene.

Here’s how to play:

  • Follow us on the @VMwareCloudOps Twitter handle and look for tweets containing the hashtag #OpsCaption.
  • #OpsCaption related tweets will contain a picture of a spontaneous VMworld moment.
  • What’s going on? What are they saying? If you have a clever or funny idea for a caption, @reply us at @VMwareCloudOps with your caption, and make sure to include the #OpsCaption hashtag.

Winning captions will be chosen based on pre-determined selection criteria.

VMUG Luncheon – Tuesday, August 27th 11:30am PT

Join us at our VMUG Luncheon for the opportunity to meet with other members of the CloudOps VMware User Group. Make sure to pay close attention to our Twitter feed during the luncheon – we’ll not only be live-tweeting, but #OpsTrivia or #OpsCaption could pop up on our feed during the luncheon as well. Don’t miss your chance to win!

Recap Blogs

We will be blogging throughout the week to keep you up to speed on all of the VMworld excitement: During the event, we will be summarizing the biggest highlights of VMworld, as well as going over upcoming activities that you won’t want to miss. For those of you who are unable to attend the festivities, we will also be posting blogs after the event to summarize key VMworld moments.

For even more Operations Transformations sessions, see our post highlighting some key sessions you won’t want to miss.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps, #SDDC, and #VMworld hashtags on Twitter.

Workload Assessment for Cloud Migration, Part 3: Assessing the Costs and Benefits of Moving to the Cloud

By: Andy Troup

Successfully assessing workloads and placing them in the appropriate private, hybrid, and public cloud environments can make or break your cloud strategy, enabling greater agility and cost efficiency.

In this series, I’m reviewing four key areas to consider when performing a workload assessment. In the first two parts, I suggested a framework for classifying workloads as potential candidates for moving to a cloud environment and then looked at service portfolio mapping and how to best determine the target cloud service and deployment model for each candidate workload. In the final part of this series, I’ll cover stakeholder analysis.

This time, I’m going to examine how to assess the costs and benefits of moving your workloads to your target cloud model. It’s pretty straightforward: The main thing to remember is to be as comprehensive as possible.

Start Me Up

The first thing to do is identify all your startup costs, including:

  • Licenses, such as investment in private cloud, and also public cloud costs. Licensing restrictions of certain technologies will also need to be considered due to the rules that are applied with them such as licensing per physical socket for all potential hosts of the service.
  • Production material
  • Payroll
  • Training. People will need to be educated in how to use the new environment. This includes the individuals supporting and maintaining the cloud environment as well as the end users who will have access to it. These costs should be relatively small compared to the benefits of self-service/self maintenance.
  • Travel

You’ll also have non-monetary costs, such as:

  • Imperfect processes (will they need to be improved?)
  • Potential risks (both of migrating and not migrating)
  • User acceptance after the migration
  • Time. To perform analysis, migration and testing as well as the time it takes for the migration. These should not be underestimated and will be very dependent on the quality of your date and your organizations acceptance of the migrations.
  • Lost production, such as downtime during migration. Migrations should ideally be scheduled during routine maintenance windows to mitigate this as much as possible.
  • Reorganization to accommodate the new cloud services. This may include ensuring that the help desk can support the new services, and a new support model to engage with public cloud providers to guarantee that they achieve their SLAs
  • Market uncertainty
  • Influence on reputation

Make sure to assign monetary values to these costs, too. To ensure equality across time, monetary values should be stated in present value terms. If it’s hard to create realistic cost values, consult market trends and industry surveys for comparable implementation costs in similar businesses.

Now it’s time to figure out your ongoing costs, including:

  • Ongoing CapEx and OpEx expenses (at equivalent SLAs). These will vary depending on the destination cloud environments you will be using. When more workloads are placed into public clouds, OpEx costs will most likely outweigh CapEx costs whereas for private clouds CapEx will most likely outweigh OpEx.
  • Ongoing Cost of Compliance. Again, this will be dependent on the clouds you are migrating to. The costs will be greater for private clouds as it will be your responsibility to ensure compliance of the cloud infrastructure as well as the cloud services. In a public cloud, the compliance of the cloud infrastructure will simply be part of your SLA with the cloud provider and you will only need to ensure compliance of your cloud services.

Depending on the current status/age of the workload you are assessing, you will want to establish the period over which you want to calculate the ongoing costs and benefits. For example, if the workload is nearing the end of its life, the period for which you perform your calculations will be shorter than for newer services. The minimum period should be 1 year. If you discover a workload whose lifespan is shorter than this, it is very unlikely that a migration is worthwhile, and a decommissioning plan should be put together.

Finally, add up all your anticipated costs to get a total cost for startup and continued operation.

On the Other Hand

Now it’s time to move on to the benefits. Start by making a list of all the benefits you expect to see upon implementation and thereafter. These should include:

  • Better insight into your workloads via a comprehensive inventory of all your workloads
  • Capex reduction due to resource redeployment and efficiencies, especially when using public cloud services.
  • Redeployment of the physical technology after migrations
  • Optimized Opex due to new cloud capabilities such as pay-per-use, as well as reduction in operating costs due to providing some operating capabilities to the end user such as self service provisioning.
  • Opportunities for new applications and integrations due to cloud architecture. It is now possible to place workloads into the cloud rather than making huge investment, for example, with High Performance Computing applications.
  • Expansion into new markets as a result of cost reduction and more agile approach to service creation. It also becomes much easier to move into other geographies by utilizing cloud services that are local to the geography. For example a South American organization can move into European markets by using local European cloud services, thus removing the concern over data location.
  • Current SLAs provided at reduced cost, or improved SLAs at the same cost. For example, a non-protected service could now have protection in the cloud. However, you will also need to bear in mind that it may not be possible to exactly match the current SLAs your workloads operate under, so some work may need to be done to establish how to migrate the SLAs too.
  • Management of risk at the service level

Establish a monetary value to these benefits, again utilizing known values where you have them, or by evaluation of market trends and surveys.

Now, Compare!

The final step is to weigh the costs and benefits in order to determine if the proposed action is worthwhile.

To do this, compare the total costs and total benefit values:

  • If the total costs are much greater than the total benefits, it’s pretty clear that the project is not a worthwhile investment of company time and resources.
  • If total costs and total benefits are roughly equal, it’s best to reevaluate all the costs and benefits that you’ve identified and to revise the cost benefit analysis. Items are often missed or incorrectly quantified. Fix the errors, and you’ll very likely get a clear pointer in one direction or the other.
  • If the total benefits are much greater than the total costs, then bingo! Your move into the cloud is potentially a worthwhile investment and should be further evaluated as a realistic opportunity.


Most of this is pretty straightforward, but it’s what you have to do nonetheless – and it’s important to make sure you do it carefully.

To summarize, first assess all your costs and benefits of moving to the cloud, then:

  1. Add up all your potential costs
  2. Add up all your potential benefits
  3. Compare the two!

If you missed the first two parts of this series, you can find them here and here.

Check out our list of blogs on workload migration and stay tuned for Part 4, where I’ll dive into stakeholder analysis.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Problem Management with vCenter Operations: Dealing with Events and Incidents Before They Impact Users

By: Pierre Moncassin

In some more traditional IT environments, if you have “problem manager” anywhere near your job title, you are probably faced with formidable challenges.

Let me guess… your mission is to steer the IT infrastructure clear of forthcoming issues – sometimes referred to as root causes – that will lead to incidents. Most of the time, though, you can only see what occurred in the past. To take a page from the famous TV Series, an incident has occurred and detective Columbo is called to the scene. What has occurred, he asks? Is there a pattern? Did anyone notice other incidents occurring around the same time?

That kind of thing you can probably do in your sleep. But however talented a detective you may be, this fact remains: You likely have little visibility into future incidents. You see some clues scattered around (also known as alerts), but these alerts cannot be readily interpreted without hours of manual work.

Fortunately, a tool like vCenter Operations Manager allows you to accelerate the scenario for Problem Management. Think of it as an assistant that can connect all the clues together and link them to potential suspects (root causes). The groundwork is done for you so that you can focus on the truly proactive work.

But vCenter Operations Manager pushes the envelope even further. Proactive analytics can detect impending outages before users are impacted. In detective terms, not only can you identify the suspects faster, you get an advance notice on their next move.

Now enough theory – let’s see how that works in practice.

Fig 1.
First off, let us look at the Health Badge (Fig 1.) which is built in as standard with vCenter Operations Manager. It is a dashboard that can provide you with instant visibility into the current state of the infrastructure. You can not only identify immediate issues but also use proactive capabilities like the risk badge to detect which areas of the infrastructure might fail in the future. In a nutshell: You don’t need to wait for an outage before responding.

Fig 2.
Another way to identify potential issues is by setting up Early Warning Smart Alerts in vCenter Operations Manager. These are alerts designed to tell you that some infrastructure components underpinning your cloud services are not operating “normally”. Unless it’s a traditional incident/response scenario, your overall service may well be operating perfectly fine – but the alert tells you that an issue will soon need attention and gives you a chance to be pro-active about it.

vCenter Operations Manager deploys advanced analytics to determine whether a component is operating within a “norm.” For now, it’s enough to say that once vCOps detects “abnormal” components beyond a certain threshold, an Early Warning Smart Alert is issued. It is the signal for the detective (a.k.a. the Problem Manager) to start investigating.

As soon as a potential issue is identified, you can drill into potential root causes (as shown in Fig. 2, right hand side). It is only a short step then from detection to active prevention and remediation. If the vCenter Configuration Manager (vCM) toolset is also deployed, you can directly access the virtual infrastructure configuration and review what recent change events have occurred. If the issue is related to a known change event within VCM, you may be able to roll back the change with a single command.

In summary, the toolsets not only accelerate detection, they also allow you to take appropriate preventative actions.

Right, but is it always that easy? Not always, of course. There are situations where there are so many alerts triggered (e.g. “Alert Storms”) that the root cause becomes harder to identify. But again, the good news is that there are known ways to cut down the noise – see our earlier blog, “Tips for Using KPIs to Filter Noise with vCenter Operations Manager” for more details.

The bottom line is that if you are a Problem Manager using vCenter Operations Manager, you will see your work increasingly shifting from reactive to proactive tasks. This is because you can let automation do the groundwork. (I digress a little here, but you will find that the same happens across many traditional IT roles when moving to a vCloud Infrastructure. Less time spent on physical-world “nuts and bolts” frees more time for proactive planning. By the way, if you are curious to see how the roles evolve, check out our “Organizing for the Cloud” white paper.)

In conclusion, here are three technical reasons why VMware vCenter Operations Manager will be a game-changer for you:

  • You will accelerate root cause analysis with instant drill-down access into infrastructure issues that may impact your overall services.
  • You get a comprehensive view of the infrastructure situation via visual summaries, like the Health dashboards.
  • Last but not least, you leverage proactive analytics to get an early notice of impending incidents. Now that is something that even detective Columbo did not have.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Workload Assessment for Cloud Migration, Part 2: Service Portfolio Mapping

By: Andy Troup

Successfully assessing workloads and placing them in the appropriate private, hybrid, and public cloud environments can make or break a cloud strategy, enabling greater agility and cost efficiency.

In this series, I’m reviewing four key areas to look at when performing a workload assessment. Last time, I suggested a framework for classifying workloads as potential candidates for moving to a cloud environment. Next time I’ll look at the approach for assessing the costs and benefits of moving particular workloads to the cloud, and then in the final part I’ll cover stakeholder analysis.

For now, though, let’s think about service portfolio mapping and how to determine the target cloud service and deployment model for each candidate workload.

First Steps

Let’s assume you’ve established which workloads you’d like to put in the cloud. Now you need to establish a catalog of standardized services that will be placed in the cloud to offer to your customers, as well as to assist in your workload migration.

A service catalog may already exist. But if it doesn’t, this post shows you how to go about establishing one, and how it evolves over the lifespan of a migration project.

To do this successfully, you need to understand the impact that workloads have on the service catalog and vice versa, including:

  • Placement strategy – where workloads can be placed & the impact of placements on the service catalog
  • Workload strategy – how to fit workload analysis with placement strategy
  • How to use the workload and placement strategy to build a service catalog
  • How to use the service catalog to help with workload analysis

Defining Your Placement Strategy

Your workload placement and cloud strategy are based on trade-offs around cost, quality of service and risk.

It’s best to first establish what types of cloud services would be most appropriate to provide and build a roadmap of service types into your cloud strategy. This strategy should be very closely aligned with the requirements of your business partners to ensure you can service their needs when required. So you need to ask: what’s your service model?

  • Infrastructure as a Service (IaaS) only? Offering IaaS services is the most common first service type for new cloud adopters. This is especially true when these adopters already have workloads running on their virtual infrastructure, as they have gained experience of offering virtual machines to their customers.
  • Platform as a Service (PaaS)? This is typically a follow up to providing IaaS, as you can build on your lessons learned and the technology stack you have already created. However, if you have business demands for PaaS over and above IaaS, then this service type should be taken on board right away.
  • Software as a Service (SaaS)? Whether you provide SaaS services is directly influenced by the business requirements that exist. For example, certain application environments might need to be upgraded/replaced and a logical replacement SaaS offering would need to exist in the marketplace. Initially, these SaaS services will more likely be procured from public cloud providers rather than hosting them yourself.

Then you need to formulate your deployment strategy to decide where those services should run:

  • Private Cloud: (most common initially for IT) where dedicated cloud infrastructure is operated to provide cloud resources for a single organization. It may be managed by the organization or a third party and may exist on or off premise.
  • Public Cloud: the cloud resources are made available to the general public or a large industry group over the internet and are owned by an organization selling cloud services.
  • Community Cloud: the cloud resources are shared by several organizations and support a specific community that has shared concerns (e.g., educational organizations, government organizations). They may be managed by the organizations or a third party and may exist on or off premise.
  • Hybrid Cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology to provide cloud resources that enable data and application portability (e.g., cloud bursting for load-balancing between clouds).

For the official definitions of both the service models and deployment models, please refer to The NIST Definition of Cloud Computing.

Assessing Workloads for Best Fit

To be sure that you select the right location to host your services, you also need to analyze your proposed workloads in more detail. In Part 1 of this series I provided some thoughts about how to identify and analyze workloads. Now that you have also established a placement strategy, you can start asking some additional questions:


  1. Will migration into the cloud give me the benefits I expect?
  2. Will this migration help me achieve my goals for cloud migrations? For example, will the service be more reliable, will it be more agile, will I reduce my overall costs?


  1. How will the migration be performed?
  2. How difficult will it be? For example, if a large amount of data is to be moved, that move may not be achievable in the outage window provided.
  3. What challenges will you face?

Asking these questions might change where you decide to place your workloads and your approach to their migration.

  • The workload placement might need to change due to particular functional or non-functional requirements.
  • You might need to reevaluate your selection of cloud providers.
  • You might need to renegotiate with your cloud provider.
  • There might be a requirement to re-architect the workload.
  • Risk of migration might be high, thus requiring additional remediation activities.
  • The migration approach might change from being a migration to instantiating a new service from the service catalog.
  • The migration might simply not be worth performing.
  • The workload SLAs (if they exist) may need to be renegotiated.

Using Your Workload and Placement Strategy to Build a Service Catalog

By taking the approach I’ve described, you’re now in a position to start thinking about how the workloads you’re assessing will impact the offerings you want in your service catalog.

During the process, you’ll discover workloads that have attributes and functions that are in demand from some of your other customers. For example, you may find a LAMP stack application that contains the version of RHEL that is your standard within your organization along with versions of Apache, MySQL, and Perl that make this workload one that you’d like to offer as a standardized service to other customers. In that case, you would want to prioritize its migration and also take the workload and put it into the service catalog (after performing any clean up work that may be required).

By taking this approach, you are ensuring that your org’s cloud service catalog is being populated with the best-of-breed workloads that have been deployed into your environment.

Leveraging Your Service Catalog to Analyze Workloads

Whether you already have a service catalog for your cloud services or are putting it together while performing migration, you can work the other way around, and leverage your catalog to analyze and migrate workloads.

When it comes to assessing workloads, you can start using the service catalog more and more as it grows to decide whether a migration is required or whether deployment of the service from the service catalog would be a better approach to provide you with a best of breed implementation based on your agreed standards.

Also, depending on your deployment strategy, you may have a number of different potential destinations for your workloads, with each having its own unique service catalog. Your goal should be to mask the complexity of all those catalogs by presenting a single enterprise service catalog to the users of your cloud. This puts you in control of the destination for all the workloads being instantiated into the cloud.

Finally, you’ll be able to compare the requirements that you have for each workload against the services you’ve established for it in the enterprise service catalog. You’ll get two possible answers:

  • A component exists within the enterprise service catalog that matches the requirement.
    • The service might be provided from the public cloud.
    • The service could be already within the private cloud service catalog.
  • No component exists within the enterprise service catalog that matches the requirement, i.e. neither service provider or the private cloud provider have this workload within their catalog.
    • You might want to develop this service within the private cloud and add it to the private cloud service catalog.
    • You may choose not to develop this service within the private cloud.

For a private solution, you can test which workloads fit the service catalog you have defined and potentially alter the catalog based on your results.

For a public or managed solution, you would need to understand which workloads fit the technical and nonfunctional requirements of your targeted public or managed cloud.

For all services, you will want to consider any service-level agreements and penalties for noncompliance that might influence price or cost.

Set For Life

As you can see, over time, the service catalog will mature and feature more and more services within it that you have accepted and that are properly compliant with your organization’s policies.


To create a service catalog that evolves over the lifespan of a migration project consider:

  • Placement strategy – ask where workloads can be placed & the impact of placements on the service catalog
  • Workload strategy – ask how to fit workload analysis with placement strategy
  • Use your workload and placement strategy to build a service catalog
  • Leverage your resulting service catalog to help with workload analysis

If you missed part one of this series on identifying and analyzing your workloads, you can find it here.

Check out our list of blogs on workload migration and stay tuned for Part 3, where we’ll look at cost/benefit analysis.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

More Thoughts on the Benefits of Standardization

By: Pierre Moncassin

A couple of months back, Rohan Kalra and I looked at how modern IT organizations are helping their clients trade control over compute assets for control over business processes.

In the cloud era, we explained, IT can give developers and users immediate access to standard IT services that are accessed and then scaled on demand. By accepting this increased standardization, their users are gaining unprecedented agility at the business level.

For this to happen, though, IT consumers need to understand the business value they can reap by accepting increased standardization. If your job is to help them reach that understanding, here are three other points that might help you make the case:

1. The False Allure of Control Over Physical Assets

It’s good to be clear that in moving to standardized commodity compute resources, the associated loss in control over ‘nuts and bolts’ physical assets is much less of a problem than it might appear.

Traditional IT consumers might balk at the move, despite the real improvements it will bring to agility, because they like feeling in control of their technical environment. They might still feel the need for dedicated, physical servers that they can almost see and touch, for example. Or, they might still want an assigned applications team sitting in a nearby office that they can visit whenever a technical issue comes up.

But that ‘control’ can be both illusionary and restricting. When new business requirements come in and the existing infrastructure needs to evolve urgently, traditional IT consumers can find that:

  • They can’t respond to new requirements anywhere near fast enough
  • The cost of changing the environment they own is high, and even prohibitive
  • The current state of the infrastructure is only partially documented (or worse)

Moving to a cloud infrastructure (and, more generally, cloud services) does require that consumers let go of some control over the ‘nuts and bolts’ side of their IT. Instead of dedicated physical servers, for example, they may have to choose from a pool of virtual servers within a choice of standardized builds.

But what they gain massively outweighs that inconvenience: control over factors that really matter for the business. They now control which services to consume and when, for example. They gain choice over the cost and quality of these services, too. And they are agile in a way they have never been before.

2. The Problem of ad hoc Service Delivery

The move towards standardized service levels means moving away from ad hoc service delivery – where IT staff create tailored solutions to any problem that rears its head.

Ad hoc service can feel comfortable and become an entrenched custom. For example, we may be all-too happy with being able to walk over to the server administrator or service desk analyst from time to time for a ‘small’ request or fix. It can be hard to give up that kind of service – but it’s worth noting that ad hoc service delivery has a considerable downside, too.

Think about service levels. In organizations where the services are not standardized, SLAs might be severely out-of-date, or irrelevant – meaning there are no SLAs to speak of. Consumers instead just go directly to the IT staff for fixes or changes, a habit that makes planning a nightmare.

In moving to a cloud model, the consumer needs to shift from ad-hoc delivery to services with well-defined, standardized SLAs. Indeed, one of the first challenges in the journey to standardization is to accurately answer the question: ‘What service levels are we getting today?’

The primary benefit, though, is obvious. Service levels, commitments, and expectations are clearly outlined and therefore much more likely to be delivered and to match actual needs.

There is also a secondary benefit to standardization. It is more efficient to maintain and support a standardized service (with standard configurations and procedures) than an ad hoc one (sometimes featuring idiosyncrasies accumulated over decades)! I would call this a domino effect – standardizing one service can boost effectiveness and standardization in other areas.

Of course, the IT consumer might find that with standardized service levels, they can’t just call the IT staff directly to resolve an issue like they used to. But they also now know that if there is an incident after the usual IT staff are gone home, they can rely on resolution processes backed by well-defined SLAs.

3. Getting the Service Quality you Paid for

When moving towards a more standardized, cloud based service, it’s not just the true Service Levels that emerge, but also the true costs.

Standardizing the service means you can precisely define service cost versus quality. For example, a popular way to describe the quality/price ratio is to present the services in ‘Bronze, Silver and Gold’ flavors, each with a pricing band.

For some customers this can be the ‘Aha!’ moment where they realize that they may have been paying for ‘gold’ in the past, whilst actually getting ad hoc services closer to ‘Silver.’ And they might just decide the ‘Bronze’ quality does the job fine. Now that is a culture change!

Lesson learned: once the quality/price ratio comes into the light, you may not always need, or even want, to pay for ‘gold.’ It might be just fine to settle for ‘bronze’ once in a while, and to use the resulting savings to add value to your business elsewhere.


In sum, here are three more arguments for moving away from tightly controlled, ad hoc service delivery and towards delivering standardized services via the cloud:

  • There’s less value in controlling physical assets than your clients might think
  • Standardized service delivery is easier to plan around and more likely to reflect actual needs
  • With standardized service delivery you can make smart(er) budgeting trade offs

For more on this topic, join us at VMworld 2013 for the special session, Balancing Agility with Service Standardization: Easy to Say But Hard To Do (OPT5705).

The panel – featuring VMware’s Khalid Hakim, Paul Chapman, and Kurt Milne along with Dave Bartoletti of Forrester Research and Ian Clayton of Service Management 101 – will explore what works and what doesn’t when it comes to delivering standardized services that truly meet business needs.

Hope to see you there! For more CloudOps sessions at VMworld, check out our highlights of the Operations Transformations track.

Clouds are Like Babies

By: Kurt Milne

While preparing for the Datamation Google+ hangout about hybrid cloud with Andi Mann and David Linthicum that took place last week, I referred to Seema Jethani’s great presentation from DevOps Days in Mountain View.

Her presentation theme, “Clouds are Like Babies,” was brilliant: Each cloud is a little different, does things its own way, speaks its own language and of course, brings joy. Sometimes, however, clouds can also be hard to work with.

Her great examples got me thinking about where we’re at as an industry with respect to adopting hybrid cloud, and the challenges related to interoperability and multi-cloud environments.

My guess is that we will work through security concerns, and that customers with checkbooks will force vendors to address technical interoperability issues. But then we will realize that there are operational interoperability challenges as well. In addition to cloud service provider decisions to use the AWS API set, there are tactical nuances that make having a single runbook for cloud tasks difficult across platforms.

From her presentation:

  • Cloudsigma requires the server to be stopped before making an image
  • Terremark requires the server to be stopped for a volume to be attached
  • CloudCentral requires the volume attached to the server in order to make a snapshot

The availability of various functions common in standard virtualized environment varies widely across cloud service providers – such as pausing a server, creating a snapshot, creating a load balancer, etc.

We don’t even have a common lexicon to describe a “Machine image” in AWS. VMware calls it a “Template vApp,” Openstack calls it an “Image,” and CloudStack call it a “Template.”

So in an Ops meeting, if you use an OpenStack-based public cloud and a private cloud based on CloudStack, and you say “we provision using templates, not images,” and someone from another team agrees that they do that too, how do you know if they know that you are talking about different things? It confuses me even writing the sentence.

I led a panel discussion on “automated provisioning” at DevOps Days. Due to templates/images/blueprint terminology confusion, we ended up using the terms “baked” (as in baked bread) to refer to provisioning from a single monolithic instance, and “fried” (as in stir-fried vegetables) to refer to building a release from multiple smaller components, assembled before provisioning – just to discuss automation!

Bottom line: Why not avoid all the multi-cloud hybrid-cloud interoperability and ops mishmash and use the vCloud Hybrid Service for your public cloud extension of VMware implementation?

Don’t miss my sessions at VMworld this year:

  • “Moving Enterprise Application Dev/Test to VMware’s internal Private Cloud” with Venkat Gopalakrishnan
  • “VMware Customer Journey – Where Are We with ITaaS and Ops Transformation in the Cloud Era?” with Mike Hulme

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps, #SDDC, and #VMworld hashtags on Twitter.