Home > Blogs > VMware Operations Transformation Services > Tag Archives: “cloud computing”

Tag Archives: “cloud computing”

The Cloud Architect: Change Champion for the New IT

By Rohan Kalra

RohanKalra-crop“What direction should I take my career with all the changes happening in IT?”

I get this question a lot when working with my clients’ IT teams. The old way of doing things needs to change for the new IT. From an IT operating model standpoint, that means becoming more service-focused. And that’s not all that’s changing—roles within the IT organization are, too.

As practitioners, we need to adapt. For me, it’s always much more fun to be the change champion, imagining how things could be done differently and in completely new ways, than to get left behind in the old world.

I discuss adapting to be a cloud architect in this short video below. There’s also an infographic that ran earlier in this blog that you might be interested in—The Forecast Is Sunny for Cloud Careers—with stats on what’s driving demand for IT professionals with cloud-related skills.

I’d be interested in hearing from you—@kalrarohan.

======
Rohan Kalra is an operations architect with the VMware Operations Transformation global practice. Follow him on Twitter @kalrarohan

 

Transforming Operations to Optimize DevOps

By Ahmed Al-Buheissi

Ahmed_croppedDevOps. It’s the latest buzzword in IT and, as usual, the industry is either skeptical or confused as to its meaning. In simple terms, DevOps is a concept that allows IT organizations to develop and release software rapidly. By acknowledging the pressure the Development and Operations teams within IT place on each other, the DevOps approach enables the Development and Operations teams to work closely together. IT organizations put policies for shared and delegated responsibilities in place, with an emphasis on communication, collaboration, and integration.

Developers have no problem writing code and pushing it out, however their demand for infrastructure causes conflict with the Operations team. Traditionally it is the Operations team that release code to the various environments including Development, Test, UAT, and Production. As developers want to continuously push functionality through the various environments, it is only natural that Operations gets inundated with requests for more infrastructure. When you add Quality Assurance teams in the mix, efficiency is negatively impacted.

Why the rush to release code?
Rapid application development is requisite. The face of IT is changing very quickly and will continue to change even faster. Businesses need to innovate fast, and introduce products and services into the market to beat the competition and meet the demands of their customers.

Here are four reasons rapid application development and release is fundamental:

  1. This is the social media age. Bad code and bugs can no longer be ignored and scheduled for future major releases; when defects are found, word will spread fast through Twitter and blogs.
  2. Mobile applications are changing the way we work and require a different kind of design—one that fits on a smaller screen and is intuitive. If a user doesn’t like one application, they’ll download the next.
  3. Much of the software developed today is modular and highly dependent on readily-available modules and packages. When an issue is discovered with a particular module, word spreads fast among user communities, and solutions need to be developed immediately.
  4. Last and most important, this is the cloud era. The very existence of the Operations team is at stake, because if it cannot provide infrastructure when Development needs it, developers will opt to use a publicly available cloud service. It is that easy.

So what is DevOps again?
DevOps is not a “something” that can be purchased — it’s an approach that requires new ways of working as an IT organization. As an IT leader, you will need to “operationalize” your Development team and bring them closer to your Operations team. As an example, your developers will need the capability to provision infrastructure based on new operations policies. DevOps also means you will need to move some of your development functionalities to the Operations team. For example, the Operations team will need to start writing workflows and associated scripts/code that will be used to automate the deployment process for the development team.

While there are adequate tools that will facilitate the journey to DevOps, DevOps is more about processes and people.

How to implement DevOps
The IT organization needs to undergo both people and process changes to implement DevOps — and it cannot happen all at once — the change needs to be gradual. It is also very difficult to measure “DevOps maturity.” As an IT leader, you will know it when your organization becomes DevOps capable — it happens when your developers have the necessary tools to release software at the speed of business, and your Operations team is focused on innovation rather than being reactive to infrastructure deployment requirements.

Also, your test environment will evolve to a “continuous integration” environment, where developers can deploy their code and have it tested in an automated and continuous process.

I make the following recommendations to my clients for process, people, and tools required for a DevOps approach:

Process
The diagram below illustrates a process for DevOps, in which the Operations team develops automated deployment workflows, and the Development team uses the workflows to deploy to the Test and UAT environments. The final deployment to production is carried out by the Operations team; in fact Operations should continue to be the only team with direct access to production infrastructure.

devops flow

Service Release Process – Service Access Validation

However, it is critical that Development have access to monitoring tools in production to allow them to monitor applications. These monitoring tools may allow tracking of application performance and its impact on underlying infrastructure resources, network response, and server/application log files. This will allow your developers to monitor the performance of their applications, as well as diagnose issues, without having to consume Operations resources.

Finally, it is assumed that the DevOps tools and workflows will be used for all deployments, including production. This means that the Development and Operations teams must use the same tools to deploy to all environments to ensure consistency and continuity as well as “rehearse” the production release.

People

The following roles are the main players in facilitating a DevOps approach:

  • Operations: The DevOps process starts with the Operations team. Their first responsibility is to develop workflows that will automate the deployment of a complete application environment. In order to develop these workflows, Operations is obliged to be part of the development cycle earlier and will therefore have to become closer to Development in order to understand their infrastructure requirements.
  • Development: The Development team will use their development environment to determine the infrastructure required for the application; for example database version, web server type, and application monitoring requirements. This information will assist the Operations team in determining the capacity required and in developing the deployment workflows. It will help with implementing the custom dashboards and metrics reporting capabilities Development needs to monitor their applications. The Development team will be able to develop and deploy to the “continuous integration” and UAT environments without having to utilize Operations resources. They can “rip and replace” applications to these environments as many times as needed by QA and end-users in order to be production-ready.
  • Quality Assurance (QA):  Due to the high quality of automated test scripts used for testing in such an environment, the QA team can play a lesser role in a DevOps environment by randomly testing applications. QA will also need to test and verify the deployment workflows to ensure the infrastructure configuration used is as per the design.
  • End Users: End-user testing can be reduced in a DevOps environment, by only randomly testing applications. However once DevOps is in place, end users should notice a vast improvement in the quality and speed of the applications produced.

Tools
VMware vRealizeTM Code StreamTM  targets IT organizations that are transforming to DevOps to accelerate application released for business agility. Some of the features it offers include:

  • Automation and governance of the entire application release process
  • A dashboard for end-to-end visibility of the release process across Development and Operations organizations
  • Artifact management and tracking

For IT leaders, vRealize Code Stream can help transform the IT organization through a DevOps approach. The “continuous integration” cycle is a completely automated package that will deploy, validate, and test applications being developed.

DevOps can also benefit greatly from using platform-as-a-service (PaaS) providers. By developing and releasing software on PaaS, the consistency is guaranteed as the platform layer (as well as lower layers) are always consistent. Pivotal CF, for example, allows users and DevOps to publish and manage applications running on the Cloud Foundry platform across distributed infrastructure.

Conclusion
Although DevOps is a relatively new concept, it’s really just the next step after agile software development methods. As the workforce becomes more mobile, and social media brings customers and users closer, it’s necessary for IT organizations to be able to quickly release applications and adapt to changing market dynamics. (Learn how the VMware IT DevOps teams are using the cloud to automate dev test provisioning and streamline application development in the short video below.)

Many organizations have tackled the issues associated with running internal development teams by outsourcing software development. I now see the reverse happening, as organizations want to reach the market more quickly and have started to build internal development teams again.

For the majority of my clients, it’s not a matter of “if” but “how quickly” will they introduce DevOps. By adopting DevOps principles, their development teams will be able to efficiently release features as demanded by the business, at the speed of business.

====
Ahmed Al-Buheissi is an operations technical architect with the VMware Operations Transformation global practice and is based in Melbourne, Australia.

 

The Missing Link of IT: An Effective Service Costing Process

By Khalid Hakim

For years now, there has been much discussion about the urgent need for tighter alignment between business and IT. Why are we still talking about the “need for” alignment and not the “results of” better alignment? Because all too often, IT cannot answer one of the key questions business leaders ask: “What exactly does this service cost?”

In many cases IT does not have an adequate service costing process, which means it does not have a fast, accurate, consistent, fair way to provide cost information about IT services to constituents. And the lack of an effective service costing process is costing both IT and the business—big time.

Cost transparency is important not only because IT service users want to know what they’re paying for, but also because it provides an opportunity for IT to quantify its value to the business.

If IT can provide accurate cost information, both business and IT leaders can make better decisions about IT investments, outsourcing, cost cutting, business strategy, and competitive differentiation.

We’ve all heard the mantra “Minimize IT costs while maximizing business value,” or its short form: “Do more with less.” It’s a core principle of IT business management (ITBM). But without an accurate, transparent service costing process, how can IT leaders truly deliver IT as a service (ITaaS) and run IT like a business?

Take a closer look at your existing service costing process and ask yourself a few tough questions:

  • Is it accurate? Does it take into account all of the CapEx and OpEx elements of delivering an IT service?
  • Is it equitable? Does it charge the right constituents the right amounts for IT services, based on their actual consumption—or does it simply charge a lump sum based on voodoo economics?
  • Is it transparent? Can constituents get an accurate breakdown of what’s included in the final price tag and what isn’t?
  • Is it improving IT investment planning? Your service costing process should enable business and IT leaders to create more finely honed investment strategies that cut costs while creating new competitive advantages. Is it?

If you can look in the mirror and answer “yes” to all those questions, congratulations—you’re a member of a small minority of enterprise IT departments with an effective service costing process. If not, ask yourself the next logical question: How can you develop a better service costing process?

I’ll address that question in my next blog post. So stay tuned.
——-
Khalid Hakim is an operations architect with the VMware Operations Transformation global practice. You can follow him on Twitter @KhalidHakim47.

VMworld-graphicAnd if you’re heading to VMworld, don’t miss Khalid’s session!

Accelerate Your IT Transformation — How to Build Service-based Cost Models with VMware IT Business Management (ITBM)
A recent VMware survey showed 75% of IT decision makers list the number one challenge in IT financial management as lack of understanding of the true cost of IT services. ITBM experts and VMware Operations Transformation Architects Khalid Hakim and Gary Roos shed light on this alarming figure, and give practical advice for obtaining in-depth knowledge of the cost of IT services so you can provide cost transparency back to the business.

When you visit the VMworld 2014 Schedule Builder, be sure to check out the SDDC > Operations Transformation track for these and other sessions to help you focus on all the aspects of IT transformation.

The Forecast Is Sunny for Cloud Careers

This infographic distills data behind what’s driving the demand for IT professionals with cloud-related skills and why the hunt is on for top talent. Scroll through the entire image for a final section of lucrative careers and top companies hiring.

 

140123-VMWare-CloudCareers-Infographic

 

7 Key Steps to Migrate Your Provisioning Processes to the Cloud

By David Crane

dcrane-cropIn an earlier blog, my colleague Andy Troup shared an experience where his customer wanted to embark on a process automation project, which could have had disastrous (and consequently frustrating and costly) results, as the process itself was inherently unsuitable for automation.

Automating processes is one of the first projects that organizations embark on once a cloud infrastructure is in place, but why? The answer lies in legacy IT organizations structures that have typically operated in silos.

Many of the IT organizations that I work with have a number of groups such as service development, sales engineering, infrastructure engineering, and IT security that face similar challenges that can include (among many others):

  • Applications provisioned across multiple environments such as development, QA, UAT, sales demonstrations, and production
  • Managing deployments of application workloads in a safe and consistent manner
  • Balancing the speed and agility of deploying the services required to deliver and improve business results while meeting compliance, security, and resource constraints

With the agility that cloud computing offers, organizations look to the benefits that automating the provisioning processes may bring to overcome the above challenges such as:

  • Reduced cycle time and operating costs
  • Improved security, compliance, and risk management
  • Reduced capital and operating expenditures
  • Reduced need for management/human intervention
  • Improved deployment/provisioning time
  • Consistent quality in delivery of services

The IT organizations I work with are often sold these benefits without consideration of the operational transformation required to achieve them. Consequently, when the IT team kicks off a project to automate business processes, especially service provisioning, their focus is on the potential benefits that may be achieved. The result of this focus is that automation becomes a panacea, and not something that should underpin the IT organization’s overall operational transformation project.

As IT leaders, when considering migrating your provisioning processes to your cloud environment, you need to realize that automation alone will not necessarily provide the cure to problems that exist within a process.

You should not consider the benefits of automation in isolation. For example, too much focus on cost reduction can frequently lead to compromise in other areas leading to objections and resistance from business stakeholders. You should consider other benefits that have non-tangible (or direct) metrics, such as improved staff satisfaction. Automation frees your technical staff from repetitive (and uninteresting) activities, which results in both improved staff retention and indirect cost benefit.

As you select processes to migrate from a physical (or virtual) environment to the cloud, the subsequent automation of those processes should not be an arbitrary decision. Frequently my clients choose processes as candidates for automation for reasons based on personal preferences, internal political pressures, or because some process owners shout louder than others!

Instead the desired business benefits the organization wishes to achieve should be considered in conjunction with the characteristics, attributes, and measurable metrics of a process characteristics and a formal assessment made of its suitability for automation.

Your automation project should also be implemented in conjunction with an organization structure assessment, which may require transformation and the introduction of new roles and responsibilities required to support the delivery of automated and self-optimizing processes.

Important Steps to Your Successful Process Assessment
Based on my experience assisting customers in this exercise, I recommend taking these steps before you embark on a process assessment:

  1. Understand automation and what it actually means and requires. Many organizations embark on automation without actually understanding what this means and the context of automated processes and their capabilities. Subsequent delivery then either leads to disappointment as automation does not meet expectations, or the process is not truly automated but instead has some automated features that do not deliver all the expected benefits.
  2. Identify and document the expected business benefits to be achieved through introduction of process automation. This is an important task. Without understanding the benefits automation is expected to achieve, you cannot identify which processes are the correct choices to help you do just that.
  3. Understand cloud infrastructure system management capabilities required to support process automation (e.g., ability to detect environmental changes, process throughput monitoring capability) and implement if required.
  4. Identify ALL processes required to support automated provisioning (e.g., instantiation, governance, approval) to create a process portfolio.
  5. Identify the common process automation characteristics that exist across the process portfolio (e.g., self configuration, self healing, self audit and metric analysis). Note that process characteristics are unique, high-level identifiers of automation across the portfolio.
  6. Identify the common attributes that the process characteristics share. These are more granular than process characteristics and thus may be common to more than one characteristic in the same process.
  7. Identify the metrics available for each process in the portfolio, and apply a maturity assessment based on their ability to be measured and utilized. Metric maturity is an essential part of the assessment process as it determines not just the suitability of the process for automation, but also its capability to perform self optimization.

Process Assessment Weighting and Scoring
When undertaking a process assessment program, an organization needs to understand what is important and prioritize accordingly. For example, if we consider the business benefits of automation, a managed service provider would probably prioritize business benefits differently to a motor trade retail customer.

Once you’ve prioritized your processes, they can be assessed more accurately and weighted based on each identified business benefit. Prioritization and weighting is essential, and you need to carefully consider the outcomes of this exercise in order for your process assessment to reflect accurately whether processes are suitable for automation or not.

And remember, as previously mentioned avoid considering each assessment criteria in isolation. Each process characteristic and associated attribute can have a direct impact on the desired business benefit, however if its metric maturity is insufficient to support it, then the business benefit will not be fully achieved.

For example, let’s say that you have identified that a business process you wish to automate has a self-healing characteristic. One of the attributes the characteristic possesses is the ability to perform dynamic adjustment based on real-time process metrics. The characteristic and attribute would lead you to expect the realize benefits such as reduced cycle time, reduced OpEx, consistent quality of service, and improved staff retention.

However, although you’ve identified the metrics required to meet the characteristic and attribute needs, they are neither measured or acted upon. Consequently, because the metric maturity level is low, then the expected business benefit realization capability is also lowered.

Figure 1 below shows a small sample of the assessment of a process in relation to a single process characteristic, common attributes, anticipated business benefits and their weighting and the impact that a poor metric maturity has on their capability to deliver the anticipated business benefit.

Figure 1. Assessment displaying impact of low metric maturity

Contrast this to Figure 2 below, which assesses a process with exactly the same characteristics, attributes, business benefits, but has supporting management capabilities and consequently much improved metric maturity:

Figure 2. Assessment displaying impact of high metric maturity

Based on this small data sample, the process in Figure 2 is a more likely candidate for process automation. The assessment process also then identifies, and allows the IT organization to focus on, areas of remediation needed to optimize processes to enable them to be suitable automation candidates.

The result is the IT organization is able to realize not just the business benefits that have been promised by automation more effectively, but they are also able to set realistic expectations with the business, which brings benefits all of its own.

In summary, automation is not the “silver bullet” for broken or inefficient processes. IT leaders need to consider expected business benefits in conjunction with process characteristics, attributes, and metrics and in the context of what is important to the business. By assessing the suitability of a process for automation, you can save the cost of a failed project and disappointed stakeholders. Finally, you should not undertake any provisioning process project in isolation to other operations transformation projects, such as organization structure and implementation of cloud service management capabilities.

I will discuss the steps to success mentioned above in more detail in my next blog.

===

David Crane is an operations architect with the VMware Operations Transformation global practice and is based in the U.K.

 

To Succeed in the Cloud, CIOs Must Look Beyond Technology

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

I’ve watched with interest as cloud solutions and services have matured in recent years to offer more agility, cost optimization, security, and quality of service for the full range of enterprise needs.

Yet I continue to see many businesses adopt cloud services in an ad hoc—rather than holistic—fashion. This is often driven by business leaders who feel the systems they need can not be delivered fast enough by corporate IT, if at all.

CIOs and IT leaders can’t wait any longer—now is the time to lead development of an enterprise cloud strategy that strikes the right balance between agility, efficiency, security, and compliance. I found Forrester’s “Achieve Cloud Economics for Operations and Services” provided some great guidance for how to do just that.

As the paper points out, IT organizations tend to focus on the part of a cloud transformation that comes naturally to them—the technology. It’s easy to see why. But success equally depends on transforming how IT operates, factoring in people resources, processes, financial management, governance, service delivery, communication, and more.

A cloud strategy that doesn’t include these elements will never reach its full potential for business transformation. CIOs can avoid that fate by developing or enhancing the following key competencies. You can further explore these elements of a successful cloud transformation in this interactive infographic.

  • Service Delivery:  The business demands agility and finance demands efficiency. Virtualization up and down the stack, combined with automation of standard repeatable tasks, is an essential first step. These advancements enable IT to meet service-level agreements independently of hardware, and to deliver innovative approaches to service delivery, such as on-demand and self-service models.
  • Talent Acquisition and Development: IT’s transition to the cloud demands new talents and skills. Leaders should ask themselves: Do I have the right people, competencies, and expertise in my organization to enable next-generation IT and business innovation? Strategies to address these needs include:

– Hiring new talent with the right skills
– Retraining and educating current team members
– Building a culture that encourages team members to embrace new responsibilities
– Working with sourcing and vendor management professionals to build up cloud skills

  • Financial Management: By investing strategically in the right technologies, IT leaders can help fund future IT transformation. To take advantage of the cloud’s pay-as-you-use cost advantages, procurement and budgeting will need to be updated for “elastic” resources. Financial transparency will also be key to positioning IT as a business driver, not a cost center.
  • Governance: Traditional IT policies and procedures will not be adequate in governing cloud solutions. Although it may prove challenging, designing combined roles, responsibilities, and accountabilities for combined marketing and IT teams, for example, is critical.
  • Sales/Marketing/Communication: IT Leaders traditional approach of “pitching” ROI, cost-benefit analysis, and business cases is no longer sufficient to develop relationships with executive management and elevate IT to a more strategic, consultative role. Professional “trusted partner”-level selling needs to be an iterative process of developing IT capabilities, marketing those capabilities, managing stakeholders, generating demand, and presenting line-of-business leaders with resonating and often proactive proposals.
  • Business Strategy: IT leaders will need to strengthen their business acumen and develop a deeper understanding of the company’s business, as well as the operations of each line of business. By researching and proposing technology innovation that is business-driven, and by designing solutions around corporate priorities and business outcomes, IT can become an active participant in business strategy development.

To be clear, I’m not recommending you tackle all these initiatives at once. I suggest building a tiered change management strategy and transformation roadmap that identifies top priorities, then sequencing broader changes over time to avoid chaos and facilitate adoption to ensure success.

Are you focusing on operational transformation to support a successful cloud strategy? Which areas are proving the most challenging? I welcome your thoughts and experiences with this set of challenges.

=====

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

Configuration Management in the Cloud

by Kai Holthaus

kai_holthaus-crop“The Cloud” is one of the biggest paradigm shifts in the IT world. Instead of provisioning physical hardware in a physical data center and then managing applications running on the physical hardware, virtualization has allowed IT organizations to decouple logical infrastructure from physical infrastructure, and thereby deliver new-found flexibility to provide and manage value-add services.

Additionally, IT organizations can now provision the cloud infrastructure itself, along with the infrastructure they are already running themselves. Infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) are now available to supplement or even replace traditional IT offerings. One common use case is to monitor the performance of a web server.

Once the performance reaches a certain limit, a new service is automatically provisioned in the cloud. The cloud-based server is used as long as performance demands require it, and once demand drops below a certain threshold, the additional cloud-based server is decommissioned. All of this can happen in a matter of minutes and can be fully automated.

Different cloud-based offerings need to be managed differently, in terms of configuration management, to ensure that the needs of the customer can be met.

Configuration Management Principles
According to ITIL, the purpose of the service asset and configuration management process is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.

The objectives of configuration management are to:

  • Ensure that assets under the control of the IT organization are identified, controlled and properly cared for throughout their lifecycle
  • Identify, control, record, report, audit, and verify services and other configuration items (CIs), including versions, baselines, constituent components, their attributes and relationships
  • Account for, manage and protect the integrity of CIs through the service lifecycle by working with change management to ensure that only authorized components are used and only authorized changes are made
  • Ensure the integrity of CIs and configurations required to control the services by establishing and maintaining an accurate and complete configuration management system (CMS)
  • Maintain accurate configuration information on the historical, planned and current state of services and other CIs
  • Support efficient and effective service management processes by providing accurate configuration information to enable people to make decisions at the right time – for example, to authorize changes and releases, or to resolve incidents and problems

In summary, configuration management supports the management of services by providing information about how the services are being delivered. This information is crucial to the other service management processes, especially such processes as change management, incident management, or problem management. It is also crucial to ensure meeting all agreed-to service levels.

Configuration Management and the Cloud
Let’s take a look at three common cloud-based offerings and the configuration management aspects to keep in mind.

20140421 SACM in the Cloud

Infrastructure as a service (IaaS) — IaaS is a service that offers computing resources, such as virtual machines, virtual networks, or virtual storage as a service to customers. The consumer of IaaS services usually has control over the configuration aspects of the resource, such as which operating system to run on a virtual machine, or how to utilize the storage resource.

This means that the resources provisioned in an IaaS model would be CIs that should be managed in the traditional way, as if they were physical CIs. IaaS offers customers a lot of control over the configuration of these resources.

Platform as a service (PaaS) — PaaS is a service that offers a computing platform to its customers. A computing platform could include an operating system, programming language, execution environment, database, and web server, so that developers have a ready-made platform for their development tasks that can quickly be deployed in various environments.  The management of the components of the PaaS is left to the service provider, who will need to meet service level agreements (SLA).

With PaaS, configuration management could be performed on the individual components of the platform, such as the virtual machine, the operating system, and the database, for instance. The configuration management could also be performed at the service level, meaning that there would only be one service-type CI for the platform to be entered into and managed in a CMS.

Software as a service (SaaS) — SaaS provides entire application environments, such as HR or procurement applications, as a service. The service provider must meet SLAs, so that customers of the service will be able to use the software when and where they choose. Such service levels can include all aspects of utility and warranty, as well as incident resolution, problem resolution, or promised delivery time frames for specific service requests, such as a new login for the application. With SaaS, there should only be a service-type CI in the CMS to be managed.

In summary, the need for good configuration management practices does not end when services (or parts of services) are moved to the cloud. It is still the service provider’s responsibility to ensure that services are being delivered as agreed to with the customers. Different cloud-based services, such as IaaS, PaaS, or SaaS, will require different levels of configuration management.

—-
Kai Holthaus is a transformation consultant with VMware Accelerate Advisory Services and is based in California . Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags

Forensic IT: Discover Issues Before Your End Users Do

by Paul Chapman, VMware Vice President Global Infrastructure and Cloud Operations

If you’ve ever watched five-year-olds playing a soccer game, there is very little strategy: all the kids swarm the field and chase the ball trying to score a goal.

Most IT departments take a similar sort of “swarming” approach to service incidents and problems when they occur.

For most of my career, IT has been a reactive business: we waited until there was a problem and then scrambled very well to solve it. We were tactical in terms of problem solving in a reactive mode, yet monitoring was focused on availability and capturing degradation in services, versus being proactive and predictive, analyzing patterns to stay ahead of problems. In the new world of IT as a service, where expectations are very different, that model no longer works.

New and emerging forensics tools and capabilities give IT the tools to be proactive and predictive—to focus on quality of service and end-user satisfaction, which is a must in the cloud era.

Forensics: A new role for IT
As an example, with new network forensics tools to monitor and analyze network traffic, it may seem a natural fit for network engineers to use them, but at VMware we found the skillsets to be quite different. We need people who have an inquisitive mindset — a sort of “network detective” who thinks like a data analyst and can look at different patterns and diagnostics to find problems before they’re reported or exposed into user impact.

Those in newly created IT forensic roles may have a different set of skills than a typical IT technologist. They may not even be technology subject matter experts, but they may be more like data scientists, who can find patterns and string together clues to find the root of potential problems.

Adding this new type of role in the IT organization most definitely presents challenges as it goes against the way IT has typically been done.  But this shift to a new way of delivering service, moving from the traditional swarm model to a more predictive and forensics-driven model, means a new way of thinking about problem solving. Most importantly, forensics has the potential to create a significant reduction in service impact and maintain high level of service availability and quality.

Quality of service and reducing end user friction
Every time an end user has to stop and depend on another human to fix an IT problem, it’s a friction point. Consumers have come to expect always on, 100 percent uptime, and they don’t want to take the time open a ticket or pause and create a dependency on another human to solve their need. As IT organizations, we need to focus more on the user experience and quality of service—today’s norm of being available 100 percent of the time is table stakes.

With everything connected to the “cloud,” it’s even more important for IT to be proactive and predictive about potential service issues. Applications pull from different systems and processes across the enterprise and across clouds. Without the right analysis tools, IT can’t understand the global user experience and where potential friction points may be occurring. In most experiences, IT finds out about a poor quality of service experience when users complain — perhaps even publicly on their social networks. Unless we get in front of the possible issues and take an outside-in, customer-oriented view, we’re headed for lots of complaints around quality of service.

At VMware, we have seen a significant reduction in overall service impact since using network forensics, and we’re keeping our internal customers productive. Focusing on quality of service and finding people with the right skillsets to fill the associated roles has us unearthing problems long before our end users experience so much as a glitch.

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

The Case for Upstream Remediation: The Third Pillar of Effective Patch Management for Cloud Computing

By: Pierre Moncassin

Patch Management fulfills an essential function in IT operations: it keeps your multiple software layers up to date, as free of vulnerabilities as possible, and consistent with vendor guidelines.

But scale that to an ever-dynamic environment like a VMware-based cloud infrastructure, and you have an extra challenge on your hands. Not only do the patches keep coming, but end users keep provisioning and amending their configuration. So how to keep track of all these layers of software?

In my experience there are three pillars that need to come together to support effective patch management in the Cloud. The first two, policy and automation, are fairly well established. But I want to make a case for a third: upstream remediation.

As a starting point, you need a solid patching policy. This may sound obvious, but the devil is in the details. Such a policy needs to be defined and agreed across a broad spectrum of stakeholders, starting with the security team. This is typically more of a technical document than a high-level security policy, and it’s far more detailed than, say, a simple rule of thumb (e.g. ‘you must apply the latest patch within X days’).

A well-written policy must account for details such as exceptions (e.g. how to remedy non-compliant configurations); security tiers (which may have different patching requirements); reporting; scheduling of patch deployment, and more.

The second pillar is Automation for Patch Management. While the need for a patching policy is clearly not specific to Cloud Infrastructure, its importance is magnified in an environment where configurations evolve rapidly and automation is pervasive. And such automation would obviously make little sense without a well-defined policy. For this, you can use a tool like VMware’s vCenter Configuration Manager (VCM).

VCM handles three key aspects of patching automation:

  1. Reporting – i.e. verifying patch levels on selected groups of machines
  2. Checking for bulleting updates on vendor sites (e.g. Microsoft)
  3. Applying patches via automated installation

In a nutshell, VCM will automate both the detection and remediation of most patching issues.

However, one other key step is easily overlooked – upstream remediation. In a cloud infrastructure, we want to remediate not just the ‘live’ configurations, but also the templates used for provisioning. This will ensure that the future configurations being provisioned are also compliant. Before the ‘cloud’ era, administrators who identified a patching issue might make a note to update their standard builds in the near future – but there would rarely be a critical urgency. In cloud environments where new machines might be provisioned say, every few seconds, this sort of updates need to happen much faster.

As part of completing any remediation, you also need to be sure to initiate a procedure to carry out updates to your blueprints, as well as to your live workloads (see the simplified process view above).

You need to remember, though, that remediating the images will depend on different criteria from the ‘live’ workload and, depending on the risk, may require a change request and related approval. You need to update the images, test that the updates are working, and then close out the change request.

In sum, this approach reflects a consistent theme across Cloud Operations processes: that the focus of activity is shifted upstream towards the demand side. This also applies to Patch Management: remediation needs to be extended to apply upstream to the provisioning blueprints (i.e. images).

Key takeaways:

  • Policy and automation are two well-understood pillars of patch management;
  • A less well-recognized third pillar is upstream remediation;
  • Upstream remediation addresses the compliance and quality of future configurations;
  • This reflects a common theme in Cloud Ops processes: that focus shifts to the demand side.

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

Shifting from ‘Free Services for All’ to ‘Gold/Silver/Bronze Service Bands’

The art and science of leveraging VMware’s IT Business Management solution to manage demand

By: Pierre Moncassin

Here is a real-life customer challenge that I encountered at a workshop with a global pharmaceutical company. The challenge boils down to the question: How do you use tiered service offerings to manage demand in a culture where users are used to receiving only ‘gold plated’ services?

The team I met with is a central IT function delivering centralized, cloud-type services to multiple lines of business distributed globally. Each line of business tends to provision its virtual infrastructure independently, based on project-specific requirements. Many projects are business critical (or at least linked to substantial revenues), so teams tend to ask for the highest service levels offered without really thinking about lower service level alternatives. In absence of a mechanism to charge business units for their consumption, teams opt for the ‘gain’ of highest service offerings.

In the past, the IT organization tried to temper demand by standardizing its offering on a few median-specification offerings while requesting more justifications for the high-specification services. This approach encountered some success, and I believe it was going in the right direction because it shared the “pain” of higher IT costs.

However, in the absence of a use-based-on-consumption cost allocation method, their users still prefer high-end, or non-standard, configurations with a higher internal cost. And they will keep doing this as long as they experience all gain and no pain.

The solution is “simple” in principle: The IT organization needs to “share the pain” and cross-charge users according to chosen usage and service levels. But ‘simple,’ of course, does not mean ‘easy.’

Given the complexity of the effort and the potential pitfalls it can encounter, let’s break down the process for getting cross charging into place into three discrete steps:

Step 1 – Start with the Essential Tools: Deploy VMware’s Chargeback Manager

Okay. I said it. You need a new tool.  Spreadsheets just don’t work over the long term. VMware Chargeback Manager enables accurate metering of the cloud-based resources being used. Beyond that, it offers pre-defined cost models that make it easier for consumers to be billed according to their usage (with a range of allocation methods).

In addition, Chargeback Manager establishes a stepping stone to VMware’s IT Business Management – the comprehensive solution for managing IT budgets for the cloud. But, for now, let’s assume that you have introduced Chargeback Manager just so that each resource has a cost and an associated ‘bill of IT’ to the consumer (whether internal or external). Is that enough in itself to manage demand?

In my view, there is an implicit, but critical, additional assumption when presenting consumers with the ‘bill of IT:’ that the bill will show items that the consumers will a) clearly understand, and b) appreciate for their quality.

To compare, for example, with a restaurant service, clients would not normally expect an itemized bill showing a breakdown of heating, water rates, and raw ingredients (meat, vegetables) measured by weight. They expect to be charged by dish. But beyond accepting the costing model, they also have an implicit quality assumption. They expect that:

  1. Dishes must meet a minimum quality standard, or they will simply leave
  2. There is some link between the price offered and the quality of the dish

If these tacit assumptions about price/quality are not met, chances are that the customers will never come back (or in the case of a private cloud, move on to a public cloud provider).

Step 2 – Offer Tiered Service Categories

Similarly, charging for internal cloud-based services also needs both a well-defined ‘menu’ (i.e. a catalog of services) and a clear relationship between services and price.

In earlier blogs, we commented about the importance of standardizing cloud services and the trade-offs that this implies.

Standardization is a pre-requisite for charging, as this defines the ‘menu’ of services offered. It also underpins economies of scale and automation – which make the costs of cloud services attractive in the first place.

However, the introduction of a ‘price tag’ for services means far more than an accounting figure. It means a cultural change – introducing a buyer/seller relationship between the IT organization and the business units. The natural response for the ‘buyer’ side is to focus on price. This is why the IT organization needs to respond – like any experienced retailer would – with a focus on both price and quality of service.

A popular way to communicate service quality is to offer tiered service categories (e.g. ‘bronze/silver/gold’ with associated price bands).  These price/quality levels can be then published in the service catalog.

Step 3 – Facilitate Cultural Change Through Communication

Introducing tiered service categories will have ripple effects throughout the IT organization and beyond, as it will foster – and perhaps enforce – a service-oriented attitude. Externally, it will shift the image of the IT organization from a cost center to that of a commercially-focused service broker.

It’s a cultural change that can’t be left to chance, however – so I highly recommended that this should be supported by a communication management plan.

In an earlier blog, I shared some ideas for making your communication plan as effective as possible. But I want to emphasize a couple here that can help speed your move to a tiered service approach – and mindset.

Internally to the IT Organization, we want to empower the Tenant Operations teams not just to deliver the best possible service (as a matter of course), but also to manage end-user expectations. In practice, a workshop such a Cloud Operations’ Service Definition Process Optimization can go a long way in helping these internal IT teams crystalize their thinking around what to promise their users by way of IT services: setting the foundations for clearly-understood, two-way agreements between themselves and their ‘consumers.’

When it comes to communication with the end-users (consumers), I’d recommend thinking in terms of a sales campaign (whether pitched within the same company or not) that emphasizes both short term and long term ‘wins’:

  • Short-term ‘wins,’ such as increased control over their provisioning spend, and clearly-defined service quality underpinned by written service levels
  • Long-term ‘wins,’ such as being more closely involved in the service definition process – i.e. having more say in how services will be adapted to their evolving needs.

The Way Forward: Service Differentiation Beyond ‘Gold/Silver/Bronze’

The global pharmaceutical company I was working with is already embracing many of these concepts, and has introduced a tiered service model at the infrastructure component level (e.g. server, storage). That, in turn, has paved the way for further service development: once the tiered service approach has full adoption, the next step will be to expand the model towards the application level – offering numerous opportunities to add further value for consumers. The tiering model can be extended even further, to more complex application-related services, such as continuity management, database services, etc.

This ‘win-win’ perspective is at the core of the Cloud Operation’s approach to managing demand: it is not about taking capacity away from end users – instead, it’s about offering a more informed range of choices with a clear trade-off between cost and quality. Given the right choices, even the most vocal consumers will rethink picking the ‘gold-plated’ option every time.

Summary – Key Steps to Manage Demand for Cloud-Based Services:

  • Introduce Chargeback Manager to establish a robust foundation for service costing
  • Link service quality to service prices – think like a retailer
  • Offer a simple, tiered range of choice to consumers
  • Differentiate the end-to-end services, not the service components
  • Facilitate cultural change with a communication plan (internal and external)

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