Home > Blogs > VMware Operations Transformation Services > Tag Archives: hybrid cloud

Tag Archives: hybrid cloud

Optimizing IT Services for DevOps, Agility, and Cloud Capabilities

By Reginald Lo

ReginaldLo-cropA recent Gartner survey[1] revealed that 85 percent of IT departments are pressured by their customers to deploy new or changed IT systems or services faster. As the speed of business continues to increase, IT is having a harder time keeping up. As a result, 41 percent of business leaders attribute faster service delivery time or time to market as the reason they use outside IT service providers[2]. IT must transform itself into an agile organization in order to become a strategic partner to the business.

In the last several years, there have been some key technology and IT management innovations to improve time to market. DevOps, Agile, and cloud computing are all attempts at increasing the speed of IT. However, IT needs to systematically design its services to exploit these innovations.

In this post I’ll explore how to change the way you design IT services so they are optimized for DevOps, Agile, cloud computing, and the service broker IT business model. I’ll also provides suggestions on how to start transforming IT into a nimble organization.

Service Design and DevOps

DevOps describes an approach for re-thinking the collaboration between App Dev, QA, and IT operations. Its purpose is to remove barriers between these teams and align them to the common goal of reducing time to market while maintaining service quality. This alignment sounds easy but is actually difficult because App Dev and IT Ops have traditionally had different objectives: the former strove for innovation and speed, while the later preferred stability.

DevOps focuses on more frequent deployments, lower failure rate, faster mean time to restore and automated processes. In order to design an IT service for DevOps, you not only need to design the system that underpins the service, but also design how the release process will be automated. Nirvana is the ability to perform continuous deployments.

One mechanism you can leverage is the service request catalog and the back-end automation and orchestration. Since App Dev is familiar with provisioning IT services from the catalog, you can also use the catalog as the interface for App Dev to request automated deployments of specific systems. The same automated orchestration capability used to provision IT services, can be used to automate the deployment process by taking the binary outputs from App Dev from the source control system and deploy them into specified environments, such as test, prod, and so forth.

When designing the support process for your new or changed IT service in a DevOps environment, consider a model that integrates both IT Ops and App Dev in the process. In the past, IT Ops shielded App Dev from 24×7 support. However, to reduce failure rate and improve mean time to restore, increasing the App Dev’s role in support creates accountability for App Dev to reduce the number of bugs and develop ways to restore service faster.

Service Design and Agile Software Development

The Agile methodology is characterized by multiple sprints leading to a release. In fact, with DevOps, a single sprint may result in a release. App Dev teams maintain a backlog of stories—a way of describing requirements. It is important to note that the Agile approach is particularly useful when the requirements are not fully known at the start of the project. The implications to service design is that you cannot expect the waterfall approach of having all the requirements upfront and then build the IT infrastructure to satisfy the supposedly stable requirements. The very nature of the Agile approach means that requirements will be discovered or evolve over time. You need to plan and design with the assumption that requirements will change.

This has interesting implications on how infrastructure or supporting services are designed. IT has generally focused on the initial provisioning process when establishing its private cloud services. However, if we know requirements change, we should also invest effort into “day 2” activities, for example, making it easy to expand compute, memory, storage, or change network and security controls sometime after the initial provisioning. Hence, your catalog should not just be an entry point for provisioning requests; it also needs to be the entry point for change requests, continuous deployment requests (as I discussed with regards to DevOps), and retirement requests.

Service Design and Cloud Computing

Cloud computing can be a model for how to deliver business-facing IT services, software as a service (SaaS), or a way to deliver infrastructure and supporting services or infrastructure as a service (IaaS), and platform as a service (PaaS). Cloud-based services have certain characteristics that distinguish them from traditional IT services:

  • Self-service: The customer can easily request the service through a portal.
  • On-demand: Instantly deliver the service when it is requested.
  • Elastic capacity:  Dynamically provision more resources (and release those resources when they are no longer required) based on fluctuation in demand.
  • Highly available and resiliency: When the underlying infrastructure components suffer an outage, the service is architected in such a way that it is still available to the customer.
  • Pay as you go: The cost of the service is linked to the amount of the service that is consumed. This allows the business to make return on investment (ROI) decisions on how much of the service to consume. Contrast this to a cost allocation model for IT, where the business has no incentive to self-manage their demand of IT.

When designing an IT service, whether it is an IaaS, PaaS, or a business-facing service that sits on top of IaaS or PaaS, you should address these cloud characteristics.

cloud tableAnother aspect of service design is “Where is the service going to be hosted?” —in the private cloud, the hybrid cloud, or the public cloud?  The answer may not be straightforward. You may want to pilot the service in the public cloud and then when it grows, bring it back into the private cloud in order to manage costs. Or you may have a service hosted in the private cloud but have the ability to burst into the hybrid cloud to handle peaks in demand. These design decisions impact how App Dev might build the application. For example, if an application starts in the public cloud but may be migrated into the private cloud in the future, App Dev cannot use the public cloud provider’s proprietary technologies, such as an AWS NoSQL database, that isn’t available internally.

Service Design and Becoming a Service Broker

If your internal customers or lines of business are using shadow IT—external IT service providers—in order to meet their time to market requirements, instead of taking an adversarial position against using those external cloud services, your IT department should embrace these vendors and leverage the value that they can provide. IT must become a service broker, helping your IT service consumers select the most appropriate platform for the service they require, whether it is private, hybrid, or public.

A service broker is more than just the ability to show VMware vCloud Air, AWS, or Azure services in your catalog. In fact, showing all the offerings and options from these vendors could become confusing to your customer. Instead, the catalog should ask questions about the requirements, such as:

  • Is the environment for dev, test, or prod?
  • Will the environment store any confidential information, such as PII (personal identifying information), HIPAA, and similar?
  • Does the environment need to adhere to certain levels of compliance such as SOX, PCI?
  • What service levels do you need?

And the based on the answers, automatically provision the environment into the right cloud—private, hybrid, or public—through the automatic enforcement of policies, as shown below.

Figure 1: Service broker—providing the service regardless of where it resides

Figure 1: Service broker—providing the service regardless of where it resides

Becoming a service broker raises some interesting questions:

  • Does supplier management need to be matured in order to manage the cloud providers better and ensure they are meeting their service-level obligations?
  • How does IT provide a seamless user experience regardless of the underlying cloud provider?  How do you make the user perceive the private, hybrid, and public cloud as “one cloud”?
  • What is the support model—for example, are there hand-off points between IT and the cloud vendor?  How do you get visibility into the full incident lifecycle as it moves from IT to the cloud vendor?

Where Do You Start?

I’ve introduced how service design needs to change in order to take advantage of DevOps, Agile, cloud, and the service broker model. The next question to answer is: “How do I transform IT so that our services are designed differently?”  Here are some suggestions:

  • Build momentum and support—First, you need to educate stakeholders on what the vision of success will look like, the problems that this “new IT” will solve, and the value that this “new IT” will deliver. This article is a good starting point but you will need to give presentations, conduct workshops, and continue to provide information to stakeholders on where the IT industry is going.
  • Establish new roles—As part of the transformation, you will need to establish new roles such as service architect, service developer, automation engineer, and so forth. And it’s not sufficient just to define their responsibilities. You also need to give the people in these new roles the training and enablement to be successful.
  • Pilot the new service design model—It may be easier starting with industry-recognized services to demonstrate how the new operating model will work end to end, such as establish IaaS or PaaS an exemplar of the new way of delivering services.
  • Think “service lifecycle”—Traditional IT is project-based. Infrastructure is built in response to specific application projects. In a service lifecycle approach, the infrastructure services are designed and built outside the context of a specific application project. Once the infrastructure service is available, application projects then request the infrastructure service as needed. This challenges the way you fund the infrastructure, as the initial creation of the infrastructure service is not tied to the business justification of the application project.
    ITIL presents a service lifecycle, but it does not going into depth regarding the specific activities in each stage of the lifecycle (instead, it focuses on the service management processes in each stage). Your organization will need to develop a methodology that defines the specific activities within the service lifecycle.

Next, you will need to tie together the new roles and the new activities from the service lifecycle. Again, a high-level example is provided below.

Figure 2: Service lifecycle example

Figure 2: Service lifecycle example

Conclusion

I’ve described how service design needs to change to take advantage of the innovations brought about through DevOps, Agile, and cloud, along with tips on how to become a service broker. And, I’ve given pointers on where to start your transformation journey. Ultimately, this transformation will help your IT organization deliver at the speed of business, resulting in exploiting business revenue opportunities earlier or realizing business cost savings sooner.

====
Reginald Lo is Director of Service Management Transformation with VMware Accelerate Advisory Services and is based in California.


[1] Gartner, Inc., “2014 Service Transition Survey”

[2] IDG Research Services , “Dual Perspectives on ITaaS:  The World According to IT and Business”

Why Service Owners Are Integral to IT-as-a-Service Delivery

By Kai Holthaus

kai_holthaus-cropThe Service Owner Role

The service owner role is central for an IT organization that is operating IT as a service (ITaaS). Why? Because the service owner is accountable for delivering services to customers and users, and accountabilities include:

  • To act as prime customer contact for all service-related enquiries and issues
  • To ensure that the ongoing service delivery and support meet agreed customer requirements
  • To identify opportunities for service improvements, discuss with the customer, and raise the request for change (RFC) for assessment if appropriate
  • To liaise with the appropriate process owners throughout the service management lifecycle
  • To solicit required data, statistics and reports for analysis, and to facilitate effective service monitoring and performance
  • To be accountable to the IT director or service management director for the delivery of the service

Please note that I emphasize  “accountability” instead of “responsibility.” The service owner is accountable, meaning they set the goals and oversee the execution.  The actual execution is performed by individuals or functions that have the “responsibility” for each activity.

Let’s take a closer look…

The service owner is the main escalation point for all service-related compliments, complaints, and other issues. You can think of the service owner as a sports coach, directing how the team should play a particular game, but not really participating by playing in the game. As the coach is accountable to the team’s owner for the team’s success, so is the service owner accountable to the customer(s) and the service management director for ongoing quality of the service.

Responsibilities Throughout the Service Lifecycle

The service owner role has accountabilities in each of the five lifecycle stages, as defined by ITIL:

  • Service strategy
  • Service design
  • Service transition
  • Service operation
  • Continual service improvement

I recommend to my clients that they assign a service owner very early in the lifecycle, so that there is a single point of accountability throughout its creation and life.  If we compare this to the product world, a service owner is like a product manager at an automotive company who is accountable as the new car model is designed, developed, and built—and ultimately for the satisfaction of the car’s buyers.

Shifting to an ITaaS Model

While the idea of the service owner role is just as valid in an ITaaS world as it is in a more traditional IT service provider world, there are a few important differences.

Service Owners Must Enable a Faster Time to Market
Moving to an ITaaS model typically requires faster development and release cycles than in a more traditional model. This is usually accomplished by moving to an Agile development model, such as Scrum. Using such models means that the full set of requirements for a service to be released will not be available at the time when development starts. Instead, development begins with the best set of requirements available at the time, and relying on future development / release cycles to address missing requirements.

The certainty of receiving a fully defined set of utility and warranty of a service is being exchanged for more rapid improvement of the service. Service design and transition activities are executed more in a spiral-type model than in a waterfall-type approach.

The service owner in an Agile environment becomes the Scrum product manager, representing the view of the customer in the Scrum model. As the product manager, the service owner is responsible for the pipeline of customer requirements driving the development of the service.  Business decisions on whether to advance the service through another round of development and release is based on the available information at the time.

Service Owners Need a Better Grasp on Future Demand
Some services, particularly infrastructure services, such as providing CPU power or storage, become utility-type services, comparable with the utility services everybody experiences at home, such as electrical power, natural gas, or water. Instead of provisioning dedicated infrastructure at the time of service development or deployment, the service owners must ensure there is enough capacity when needed, e.g., storage should be available instantly available when required— similar to water flowing immediately when you turn on the faucet at home. This requires a much better understanding of future demand, patterns of business activity, and user profiles than is typically the case today.

Service Owners Will Give up Some Control to Enable Automation
Due to the nature of ITaaS, service owners will be required to give up some control over the configuration of the service. For example, automation tools already move virtual machines from one physical host to another based on current workloads, without any human control. To fully deliver on the ITaaS promise, this type of automation must increase. Increased automation will require either defining more changes as standard changes, which can be implemented without approval (and in this case, automatically, after the tool has recorded the change), or give up change control completely, and let the tools handle them. Such automation tools can also automatically update the configuration management system, so that valid information will always be available.

How Will Services Operate in the Cloud?
While today’s services are largely delivered from in-house data centers, the ITaaS model makes full use of hybrid and public clouds.  Service owners must understand the ramifications of moving parts of the service infrastructure (or even the entire infrastructure) into the public cloud. This requires a better understanding of required service levels, and what will happen if cloud providers experience incidents or even disasters.

To conclude, the specific accountabilities associated with the service owner role don’t change dramatically when an IT organization moves to an ITaaS model. Primarily, a service owner will need to shift from defining architectures and infrastructure as part of the service design to defining the service in terms of requirements, and necessary service levels for supporting services. Also, traditional controls over the infrastructure may no longer apply when automation is used to fully deliver on the promise of ITaaS.

While the shift in the service owner’s responsibilities isn’t dramatic when transforming to an ITaaS model, the importance of the role grows significantly.  If you haven’t already explored implementing or expanding this role as you transform to deliver ITaaS, be sure to include this as part of your roadmap for moving forward.

=====
Kai Holthaus is a senior transformation consultant with VMware Accelerate Transformation Services and is based in Oregon.

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.