Categories
The Business of IT

Answers from OpenStack leaders

This week I attended the OpenStack Israel 2013 conference. The conference was sold out, with over 400 attendees in a standing-room-only auditorium. As I mentioned earlier, I moderated a panel entitled “If OpenStack is the answer, what was the question?” Here is the video. Below is a summary of the panel’s Q&A.

I want to thank the audience at the event for asking provocative questions, and the panelists:

  • Mark Collier, COO of the OpenStack Foundation
  • Chris Jackson, Manager of Big Cloud Solutions at Rackspace
  • Mac Devine, Director and CTO, Cloud Portfolio, Global Services at IBM
  • Mark McClain, Senior Developer at DreamHost
  • Sivan Barlizy, Product Line Manager, CloudBand Business Unit at Alcatel-Lucent

and, for joining the panel unprepared when I invited him on stage halfway through:

  • Florian Haas, CEO of hastexo.

Earlier I posted some questions I would ask the panelists. Time was short, so not all questions were covered.

Summary of panel discussions

What can be done to improve the operability of OpenStack?

Mark Collier said that The OpenStack Foundation actively listens to users and creates the roadmap based on their input, and operability has been improving: upgrading from Folsom to Grizzly is much easier than previous upgrades. The Foundation encouraged the writing of a book about how to operate OpenStack. We also need to remember that we have hindsight bias: it took many years for Linux to mature. OpenStack is maturing rapidly – but expectations are higher and keep rising. Although there are mostly developers, not operators, contributing to the project, we expect this to change over time as it is more widely deployed.

How does Rackspace keep its public OpenStack cloud consistently running the trunk version two weeks behind the project, without user downtime?

Chris Jackson differentiated between enabling OpenStack adopters to easily deploy and the procedures specific to Rackspace and maintaining compatibility with its legacy SliceHost infrastructure it still operates. But, although the Rackspace tech team shares some of their experiences on their blog, the techniques Rackspace uses to accomplish this particular feat are not shared.

OpenStack’s mission is to encourage an ecosystem of interoperable cloud providers. Why does Rackspace want to encourage that?

Chris Jackson said Rackspace encourages people to be able to stand up OpenStack easily. Their goal is to open up all the ways to build and run a cloud, and Rackspace will differentiate based on service quality. However Fanatical Support will not support just any cloud, only Rackspace’s OpenStack flavor, in order to deliver a consistent quality level.

Why don’t we see an ecosystem of public OpenStack clouds actually forming? Where are the billion dollar budgets backing the creation of these alternatives to AWS?

Rackspace views vendor choice as crucial to OpenStack success, so they sponsor choice by helping telcos build OpenStack clouds. Telcos have billion dollar budgets, and Rackspace has a program that helps them get to public cloud without reinventing the wheel.

Why aren’t we talking about Amazon anymore?

It’s because OpenStack has matured and we have real use cases, real OpenStack deployments, to point to. Rackspace claims that AWS and OpenStack may appear to be similar, but they serve very different functions: AWS gives you cookie-cutter infra resources and tells you how to consume them, while OpenStack gives you the freedom to build for your own custom needs, using any vendor you want, without worrying about any single vendor’s roadmap. Rackspace doesn’t see AWS as competitors. When Rackspace competes with AWS on price it’s just because it’s a necessary evil, to stay relevant in the public cloud market. Public cloud prices are based on the presumption of zero customer loyalty. However, hybrid cloud supports a price premium.

Won’t OpenStack always be playing follow-the-leader with AWS?

Mac Devine pointed out that there is a correlation of the roadmaps of these efforts because AWS blazed the trail. In the early days, OpenStack was playing follower. But from this point, from where we are today, it’s equally important to listen to the ecosystem and implement the features that are requested. Of note is that as AWS matured they began releasing services above the IaaS layer that encourage lock-in. The OpenStack approach is to provide a variety of vendors that can be used to supply services – such as relational database as a service.

Q: What is OpenStack displacing?

VMware should be very concerned. There is no lift-and-shift from VMware to OpenStack. People want an open, no-license model, and providers like Rackspace work with customers to help them transition from VM consumption to cloud consumption. Mac Devine said that even among accounts where VMware is dominant, there is increased interest and commitment to open, lockin-free environments for all new projects. These clients are using OpenStack to extend the features of apps that run in VMware. This will increase the pressure on VMware to be more open. Mac believes that that pressure is one reason why VMware spun off Pivotal Labs, with CloudFoundry inside it, into a separate unit.

How do we get enterprise apps into the cloud, then? What is the roadmap for these apps that were developed without cloud in mind?

There are several things missing in order to be able to do that easily. Bare-metal provisioning, single tenancy, location awareness, standards compliance, integration with management utilities, and network configuration are several examples. Alcatel-Lucent has been leveraging OpenStack as a platform that solves common problems, and adding code around it to provide these features, but these additions are not contributed back to the project. Mac Devine pointed out that legacy apps are still being maintained, but those teams maintaining and developing these legacy apps are already on notice that they’ll need to change the way they design apps. Mac’s division at IBM put almost 600 developers on a project to make DB2 aligned with OpenStack, and he is sure we’ll see traditional OLTP apps being adapted and reshaped for OpenStack gradually. The network is one of the things that is very different in legacy and OS. Each app has its own unique network configuration, a snowflake network. Mac recalled that one client rearchitected their application but didn’t think about the network, and when the new app running in OpenStack needed IP addresses it still took them 10 days to provision those manually.
Florian Haas said it’s silly to think that we will rearchitect legacy apps for the cloud. In terms of getting enterprise apps into OpenStack easily, Florian said we need a check box that says “give me this VM, and make it HA.” “We are about 80% of the way there, which means we only have the other 80% left.”
Chris Jackson pointed out that The Foundation is moving toward the convergence of IaaS and PaaS, so control will be given less to each individual app in the future.

What about OpenStack itself – are the internals HA?

Florian said we’re there already. The message bus, relational DB, the API – these things are done. The hard part that is left is the “I want to make a machine HA.”

Categories
The Business of IT

Questions for OpenStack leaders

I’ll be moderating a panel of OpenStack leaders next week at the OpenStack Israel 2013 event in Tel Aviv. Last year’s OpenStack Israel event was excellent, and this year’s gathering looks like it will knock it out of the park. Over 350 people are already registered for the conference, and the two days of technical training following the conference are already full. If you’re in the area you shouldn’t miss this conference. And make sure to introduce yourself to me as well.

In preparation for next week’s event I’ve been formulating tough questions to ask the OpenStack leaders. So far I’ve received great suggestions from Nati Shalom, Randy Bias, and George Reese. Here are some of the questions I’ll put to the panel:

  • How committed are you to ensuring compatibility of OpenStack clouds across different providers? What about between versions?
  • Why is it so difficult to operate OpenStack in practice? How do you plan to address this?
  • Is OpenStack the code or is it the APIs?
  • Public cloud providers are naturally incentivized to differentiate by adding proprietary features to their services, thereby increasing lock-in. Doesn’t this pressure to differentiate conflict with OpenStack’s mission to create multiple, interoperable clouds? And, doesn’t this pressure towards fragmentation undermine the value of OpenStack as an alternative to the Amazon Web Services ecosystem? What do you plan to do about this?
  • What existing systems are being replaced by OpenStack implementations?
  • For the vendors among you (e.g. IBM, HP), how do you plan to make money from OpenStack?
  • Why is OpenStack Foundation membership so expensive? What’s wrong with following the model provided by the Apache Foundation? Is the high barrier to entry in the Foundation really necessary?

Do you have a question you’d like to hear the OpenStack leadership address? Let me know, and I’ll report back on their answers.

Categories
The Business of IT

Not workloads – impact.

Before you ask yourself “what can and can’t I do in the cloud,” stop to consider the larger picture. How will your customers know that you have adopted cloud computing? What resulting radical improvement will delight your customers? These questions help you focus on the impact you want to achieve with your initiative. The answers help you understand the facets that you’ll need to address – technology, skills, procedures, and behaviors – in order to achieve and measure that impact. Then you’ll be ready to talk nuts and bolts about vendors, tools, and cloud-appropriate workloads.

For example, my client, CIO of a media company, was enthusiastic about using cloud computing and wanted to get right down to details: what should he move into the cloud, how long would it take, who could help, and so on. After walking through the questions mentioned above we made several important discoveries:

  • External customers wanted a streamlined billing process.
  • Internal customers wanted to eliminate boring, error-prone manual work.
  • Neither group of customers cared what technology was used.
  • He didn’t know the effects of the current billing process on satisfaction, retention, and revenue.

It was clear that the project was more properly regarded as a customer retention initiative, not as a technology adoption effort. As a result, the CIO immediately knew what he had to do: measure the effects of billing on customer satisfaction, retention, and revenue; and he needed to recast the cloud computing adoption program as a program to substantially improve customer satisfaction. These guidelines provided the business context within which his staff was able to make intelligent, focused decisions about implementation details.

Next time you find yourself asking about what workloads to move to the cloud, think about the only thing that matters: what will delight customers?

Categories
The Business of IT

Three Critical Pitfalls to the Success of Cloud Offerings

Whether you operate IaaS, PaaS, or a SaaS service, watch out for these three pitfalls to the success of cloud offerings:

  1. Encouraging the wrong thing. Measuring the success of the offering by looking only at utilization metrics damages sales. One cloud service provider measured the success of its IaaS service – and compensated its sales force – based on virtual machine usage. Little surprise that, for all the years that this practice continued, the provider could not land strategically important accounts. Like in any mature sales operation, your prospective cloud service clients should be evaluated based on several criteria, including:
    • strategic fit
    • urgency
    • reputation
    • visibility
    • cost of sale
    • short-term sales potential
    • long-term sales potential.

    Make sure you evaluate all these elements, and that you prioritize your sales and marketing efforts toward prospects with the right combinations of all these factors.

  2. Ignoring the relationship. On-demand and pay-as-you-go are not simply usage models; they are components of a new type of customer relationship based on transparency and immediacy. Make sure your customer relationships allow for:
    • Seeing usage and  billing easily, and up-to-the-minute.
    • Setting custom notifications and enforceable consumption limits based on both usage and cost.
    • Getting quick notice of service degradations and their ongoing status.
    • Being reassured after service disruptions that you have identified the cause and taken steps to prevent a reoccurrence.

    Your service may have other ways to build a customer relationship based on transparency and immediacy. Identify and exploit them.

  3. Focusing on infrastructure reliability. Selling a cloud IaaS service that differentiates with higher level of service reliability is not sustainable; instead high-SLA workloads must be built using cloud-appropriate designs. Any IaaS provider who tries to compete against the commodity non-reliable infrastructure clouds by offering a higher SLA engages in an unwinnable battle: the cost structure will make it impossible to compete against commodity offerings. As computing services become more commoditized, previously established patterns of infrastructure usage (aka “best practices”) that called for highly reliable hardware and “N+1” architectures are architecturally moot. Following those patterns in the cloud will not increase overall workload reliability. Instead, workloads that use cloud infrastructure need to be designed for scale-out and rapid recovery from infrastructure failure, providing overall workload reliability via software. The overall cost of reengineering workloads for cloud-appropriate architecture will, in the end, be less than the cost of building and operating a cloud that delivers a “classic” hardware-based HA.

Don’t make these mistakes. They could be killing your cloud business.

 

Categories
The Business of IT

Cloud adoption flu season

This coming year tens of thousands of medium and large companies will conduct initiatives to adopt cloud computing – and most of these will fail. The cause of these project failures will be unrealistic expectations. The inoculation is a hefty dose of reality. Get your vaccine here.

No one questions the fact that IT is undergoing a revolution and cloud is at its center. You need only glance at the article titles in any business and tech publication to see this. Cloud is a critical element in achieving unprecedented agility and supply-chain optimization.

However, will cloud alone get you these purported benefits? No, it won’t. Nor will any single vendor’s solution. Nor will the time and resource investment required to get there be small, as I’ve discussed previously. Shame on the vendors, analysts, and pundits who claim so or set this expectation in meetings with their prospective customers.

Reality. The flu vaccine for cloud-high cloud project expectations.

Let’s set some proper expectations. Real change requires serious investment, time, resources, and oversight. The larger the ship, the more difficult it is to adjust course. Here’s what to expect a successful cloud adoption program to look like:

  • It will be a multi-year effort.
  • It will require investing a significant percentage of your current IT budget just to properly plan. And significantly more than that to execute.
  • It will require adopting new technology and changing the way your people work.
  • It will demand the participation of your customers – internal and external.
  • It will demand executive-level leadership, involvement, support, and prioritization.
  • It will fail if you think otherwise.

The cloud adoption flu season is upon us. The best way to protect yourself is to understand the reality of cloud adoption initiatives – that’s the vaccine.

Categories
The Business of IT

Hungry for change?

Meeting business and technical requirements is important, but to what extent is your organization ready to accept the changes that your new initiative will introduce? In my work with global clients I’ve identified three critical elements that govern the success or failure of these initiatives:

  • Diet: How much is risk-taking accepted, encouraged, and rewarded?
  • Taste: How much does past experience support or undermine the changes that will be introduced?
  • Appetite: To what degree do people see their jobs getting easier as a result?

Like we (should!) do with our eating habits, we should create a change program that respects the diet, taste, and appetite of the organization – or changes those elements if needed – to ensure maximum health. Only when you and your organization are in good health can you maximize your success and capitalize on unforeseen opportunities.

Categories
The Business of IT

You don’t need a cloud strategy

It may sound strange, but your organization does not need a strategy for cloud computing. You no more need a strategy for cloud computing than you need a strategy for toothbrushing: as long as your teeth are healthy, who cares if you brush from top to bottom or from left to right, or what brand of toothpaste you use!

So it is with cloud computing: your organization has a business strategy (if not, give me a call). Does that strategy include developing enhanced agility, improved time to market, and increased innovation? If so, then take a deeper look at cloud computing, and build a concrete plan to use cloud computing to fulfill your business strategy.

You don’t need a cloud strategy. You need a business strategy, and a concrete plan to achieve it. If cloud supports that business strategy – then go for it.

Categories
Cloud Developer Tips The Business of IT

Do you have what it takes to build and run your own private cloud?

Building and operating a private cloud ourselves is simple, right? Give our experienced IT folks a budget for hardware and software, a clear mandate, and deadlines, and we’re likely to succeed. That’s what we’ve always done, and it’s worked out tolerably well. Private cloud isn’t so different from running our own virtual machine environment, and we do that already, so why wouldn’t we succeed? I hear this sentiment expressed often so it seems to be a widely held belief. But it’s wrong precisely 97.73 percent of the time – I measured. Unfortunately, too many organizations act on this mistaken belief and experience unnecessary hurt as a result.

My good friend Keith Hudgins made this point cogently in his presentation at the CloudConnect conference in Chicago. Keith is one of the few people who really knows what it takes to build and run a cloud: he was part of the core team with me building KT’s public cloud service in South Korea, and he is currently Senior Cloud Engineer at enStratus where he helps enterprises get their private clouds to work properly. Keith’s presentation was sobering for the audience members, several of whom said they plan to reevaluate their private cloud initiatives as a result.

If you want to succeed at your own private cloud you need to consider these four critical aspects: your users, your competition, your skills, and your technology. Know these four and you have a fighting chance to make it. If not, get help – or prepare for disappointment.

Know your users

Different users need different applications, and your cloud must be designed to support the required applications. Private clouds might have three different types of users:

  • Regular desktop users, the kind of user most likely found in your Finance, HR, Sales, and Marketing organizations, will need your cloud to support the applications your IT department currently supports already: CRM, accounting, ERP, and business applications your IT department is already familiar with.
  • Software R&D staff will need your cloud to support the development environment, tools, and deployment processes they’re already using. This group will also likely need training to properly architect and operate reliable applications in a distributed environment.
  • IT staff will need your cloud to support core capabilities such as backup, directory management, and file sharing.
Ask your users what applications they are using and what they need the cloud to support.

Know your competition

Odds are your users already use public cloud services, and – like it or not – your own private cloud will be competing against those public alternatives. How well do public cloud services meet your users’ needs?

  • How reliable is their service? How does this compare to your own historical reliability?
  • How easy are they to use? Do public cloud service customers need multiple levels of corporate approval to acquire resources, or is the ordering and fulfillment process seamless and extremely short – a few minutes at most from order to delivery? Can you deliver the same or better usability?
  • How good is their support? Are there multiple sources for expertise and communities where users can share solutions and experience?
  • How rich is their ecosystem? How easy is it to employ a vast variety of tools and seamlessly integrated value-added services?
Determining how well your users’ needs are met by existing public cloud alternatives will give you a good idea of what you need to provide in order to achieve successful adoption of your private cloud.

Know your skills

The skills required to build and operate a cloud are not taught in classes, they’re learned by experience. These include:

  • System administration. Okay, this one is taught in classes, but the issues you’ll experience in a cloud environment are much more complicated and at a larger scale than you will normally encounter elsewhere. Keith suggested that OpenStack and Eucalyptus will be a challenge for your team if they lack linux administration skills.
  • Storage management skills are critical because storage is the most complicated technical aspect of a cloud. Keith emphasized the importance of NAS and iSCSI setup and management experience.
  • Networking is a key element of the cloud and networking expertise must be a part of your core cloud engineering team.
  • Automation will dictate how quickly you can recover from problems, so you must be experienced in its use and integrating automation tools into your workflow. Identical inputs (that is, identical hardware revisions) must always yield identical outputs, and that is only possible at a large scale with automation. Keith pointed out that automation takes time to produce. Make sure your team is proficient with the automation tools that work best with your technology choices.

Get these skills if you don’t have them. They will influence your choice of hardware and software.

Know your technology

Cloud is powered by technology, so you’ll need expertise in at least the following four technical areas to build and run it yourself.

  • Cloud Management Software is the layer that provisions cloud guests and sits between the API and the hypervisor. If you can’t explain the differences between the four major cloud management software options – CloudStack, OpenStack, Eucalyptus, and OpenNebula, then you do not have the expertise to choose the right one for your needs.
  • Storage, Keith pointed out, is by far the most complicated technical aspect to get right in a cloud. Local guest storage is the simplest to build and operate, but limits the range of applications that can be easily supported on the cloud. Attached storage increases flexibility at the cost of complexity. And object storage requires lots and lots of disks. Your options will be influenced by your choice of cloud management software, and any change to the default configurations will require serious development and testing to get it right.
  • Hardware and the way you manage it is the most important choice you can make. Of all the components in a cloud the hardware is what is going to break, so the ease with which you can replace hardware will dictate the maintenance headache. Keith provided some hard-won tips: make sure your hardware vendor can supply identical hardware down to the BIOS revision, create (automated) procedures to verify or reject hardware as it is delivered, and diligently avoid hardware inconsistencies since they greatly increase the complexity of the endeavor.
Your choices in the above three technology categories should be guided by your needs, but remember: you can only choose wisely if you have appropriate expertise in these technologies.

Do you have what it takes?

The above four aspects are critical to successfully building and operating your own private cloud. There are other success factors – know your strategy, know your business model, and use effective project management – that are part of any successful technological change. But the above four are critical in any private cloud initiative. So, how do you rate on these aspects?

Odds are, you don’t have the expertise required to do it yourself.

Categories
The Business of IT

Where is the value?

Back in the early days of computers, or so the legend goes, when an entire room housed less computing power than in today’s iPhone, a large government agency had a serious problem: their computer system stopped working. Though it was only three weeks since the system had been certified, the startup sequence refused to complete, leaving the agency lacking critical operational capabilities. Work on the project ground to a halt while every engineer on staff checked and rechecked wiring, tubes, and relays to find the issue. But two weeks of troubleshooting amounted to nothing, and the Director of the agency was beside himself with frustration. He decided to hire the worldwide expert on such computer systems, a retired professor who was known for his sense of humor.

The professor arrived on site in a white lab coat, was briefed by the Director, and immediately asked to be given access to the computer room. Once there, he proceeded to walk around the room from cabinet to cabinet. The Director and his staff watched with increasing curiosity as the professor paused before each cabinet for a moment, scratched his beard, muttered under his breath, and moved on to the next cabinet. Finally, after forty five long minutes of this, the professor stood up more erect, smiled at the Director and his staff, withdrew a piece of chalk from his coat pocket, walked over to one machine cabinet and marked a large “X” on the side of the cabinet. “Your problem is in here,” he said confidently. And, sure enough, as the technicians opened up the marked cabinet, they discovered a subtle wiring issue that had been missed by all previous inspections. Gratefully, they fixed the problem and were able to resume operation. “Please, send me your bill – whatever it is, I’ll see that it is paid promptly,” said the Director.

The professor sent a bill to the agency, a one-line invoice for “troubleshooting: $1000”. Unfortunately, as government policy dictated, the Director needed a detailed itemized invoice, and he was forced to delay payment and request the proper details from the professor. The professor’s corrected invoice arrived, and it read as follows:

One piece of chalk, with which to mark the problem: $0.01
Knowing where to place the mark: $999.99

The real value to your customers is in knowing how to fulfill their needs. All the rest is a commodity.

Categories
The Business of IT

Wanted: Change. Generous Reward.

Simon Wardley recently satirized the typical response of corporate IT departments to technology change as follows:  Ignore, ignore, ignore, “no”, “no”, “I said ‘no,’ dammit”, “Oh no”, “Oh, f**k”. It reminds me of the classic Toys-R-Us TV commercial from the 1980s featuring children singing about not wanting to grow up. Resistance to change is not unique to children or to IT departments – it is a feature of every organization. How can you help your organization avoid being stuck, and instead drive change before it’s unnecessarily painful to “grow up”? The key is urgency. Growing up is a good metaphor for organizational change: both are normal, both feature resistance, and in both the stakes increase over time. Immature people, like immature organizations, do not reliably achieve their goals. And the longer that inertia dominates, the further behind they remain. Failure to adapt – getting stuck – can be fatal, as it was for the Eastman Kodak Company. In personal as in organizational growth the pressure to change – the urgency – is fostered by discomfort. To increase urgency you need to cause people to feel discomfort with the current state of affairs. John P. Kotter’s seminal work Leading Change offers several kinds of tactics to increase urgency:

  • Show that the present isn’t working: Allow a crisis to happen, publicize poor results, force encounters with unhappy customers, publicize lost opportunities.
  • Change the metrics: Create performance targets that are high enough and/or broad enough they can’t be reached with business-as-usual.

These tactics to increase urgency all work by fostering discomfort with the present. A client found himself spending inordinate lengths of time evaluating opportunities and procrastinating a decision on which ones to pursue. When I showed him how his lengthy decision process was limiting the number and quality of opportunities that presented themselves, he realized that he could grow his business significantly by streamlining this process. He saw the urgency of addressing the issue, we worked together to fix it, and his business has grown threefold since.

Creating a sense of urgency is the first step in a successful change program. Kotter describes further steps to a successful change effort, but urgency underlies them all.

In short:

Ouch! Now, change.