by Alessandro Perilli | November 19, 2013 | 37 Comments
A couple of weeks ago I attended my first OpenStack Summit in Hong Kong. It was an eye opener experience from a research standpoint, and I wrote some of my impressions in a post titled “What I saw at the OpenStack Summit” . In that post I covered three big a-ha moments for me, but omitted one.
What I saw at the Summit was a very strong desire to penetrate the enterprise market, which seems to be the hardest challenge for vendors gravitating around the OpenStack ecosystem. In fact, for the largest part, vendors don’t know how to articulate the OpenStack story to win enterprises. They simply don’t know how to sell it.
Don’t believe the hype generated by press and vendor marketing: OpenStack penetration in the large enterprise market is minimal. There are exceptions, like the way too famous PayPal case study. But PayPal is not your average large bank, your average large insurance firm, or your average healthcare organization. If you look at the excellent User Story page on the OpenStack website, you’ll see a lot of documented customer references, but not the traditional enterprise segment that vendors are after.
And yes, there are some ongoing deployments that can’t be disclosed yet, but for one promising or successful deployment there are several that fail and that will forever remain undocumented. When I evaluate a case study in Gartner I always assess what’s the stage of the project. If the project just started I don’t really know if the interviewed organization will fail and replace the product six months into the implementation. Sometimes it happens, demonstrating how a lot of the initial assumptions were wrong.
So why vendors can’t tell a resonating story about OpenStack to enterprise prospects?
There are at least four reasons:
1) Lack of clarity about what OpenStack does and does not.
Over the last three years, press mistakenly positioned OpenStack as an alternative to commercial solutions that in Gartner we call cloud management platforms (CMPs). In most situations, it’s not the case. Quite the opposite, from an architectural and functional standpoint, what OpenStack does must be augmented by a commercial CMP for many enterprises that need strong process governance, sophisticated capacity management, and advanced automation capabilities. I spent the last three years at Gartner researching on these topics, but you don’t have to trust my words. eBay’s Chief Engineer in charge of the OpenStack private cloud, Subbu Allamaraju, says it better:
“However, OpenStack is a cloud controller software. Though the community did a nice job at putting together this software, an instance of an OpenStack installation does not make a cloud. As an operator you will be dealing with many additional activities not all of which users see. These include infra onboarding, boostrapping, remediation, config management, patching, packaging, upgrades, high availability, monitoring, metrics, user support, capacity forecasting and management, billing or chargeback, reclamation, security, firewalls, DNS, integration with other internal infrastructure and tools, and on and on and on. These activities are bound to consume a significant amount of time and effort. OpenStack gives some very key ingredients to build a cloud, but it is not cloud in a box.”
It is totally acceptable that press cannot get the architectural and functional difference between OpenStack and commercial CMPs focused on private cloud computing. But vendors get this difference, trust me. And no one in three years stood up to clarify what OpenStack can and cannot do for an enterprise. The net result is that the large majority of my inquires with enterprises interested to learn more about OpenStack are focused on clarifying architecture and feature set versus solutions like VMware vCloud Suite or BMC Cloud Lifecycle Management.
To the contrary, all vendor marketing seen in last three years seems focused on building a very vague association between OpenStack and the general concept of “cloud”. Nobody acknowledges that OpenStack can solve a specific set of problems related to building a cloud, but not all of them. I won’t make specific examples, but I invite readers to open a multi-tab browser and display the OpenStack page of various Foundation members for each tab.
Enterprises don’t do business with vendors that cannot articulate clearly their value proposition describing what problem they solve and why they solve it better than others.
I look forward to address this lack of clarify from a technical standpoint with my next research document.
2) Lack of transparency about the business model around OpenStack.
During the press and analyst day at the OpenStack Summit I was fortunate to attend a panel with prominent vendors about their involvement in the project. One of the first questions, if not the first, submitted by the moderator was something like “You offer commercial solutions to build private clouds, and yet you are investing significant resources in this open source project. Why?”
What followed was the closest thing to a discourse at a philanthropy dinner I have ever heard in my life. Not a single panelist described the business model behind their decision to support OpenStack.
I have no doubts that some individuals truly believe in the promise of OpenStack and its long term potential (for example, one thing that was mentioned was greater cloud interoperability). However, vendors gravitate around OpenStack for profit, which can come in different forms:
- Some vendors can benefit from OpenStack’s complexity by selling professional services
- Some vendors can benefit from OpenStack’s lack of enterprise-grade functionalities and augment an OpenStack cloud with their commercial CMPs
- All vendors benefit from OpenStack’s open source nature by offering enterprise-grade support well beyond the 6-months life cycle of OpenStack releases.
- All vendors benefit from OpenStack’s open source nature by leveraging drivers for the various resource managers provided by other vendors, rather than developing their own integration points. It’s a massive R&D cost that is offloaded to the OpenStack community.
None of these business models were even briefly mentioned, and that reflects the reticence that vendors have in clarifying why they want to be in the OpenStack business.
Enterprises need to understand the long term viability of technologies they consider for adoption. An unclear business model doesn’t help.
3) Lack of vision and long term differentiation.
I mark some of my slide decks as “evergreen”. It means that I keep updating them even if there’s no imminent research document associated to them, simply because they are about a topic that comes up every day during inquiries. One of my evergreen decks describes the cloud management platform market profile and vendor segmentation. In that deck I keep track of commercial CMPs and OpenStack distributions among other information. And to my count, at today, there are 17 OpenStack distributions. I am fairly certain there are more.
What value they add to the vanilla OpenStack code that enterprises could (but don’t want to) download by themselves? What is the differentiation between all these distributions?
For way too many, it’s all about number of code contributors and simplifying the installation process, in this exact order.
Number of code contributors doesn’t tell anything about vendors’ vision and long term differentiation. How many developers contribute to a commercial CMP? Does it matter if the product doesn’t solve today’s and tomorrow’s needs an organization has? Andrew Clay Shafer, former VP of Engineering at CloudScaling (an OpenStack Foundation Gold Member), called it vanity metrics. I agree and invite technical press to dig deeper in writing their stories about OpenStack.
OpenStack installation issues is nothing new, and it’s somehow shocking that three years into the project the code is still so complex to install. So it’s positive that vendors are working to solve the problem. However, you can’t win enterprises with a smoother installation procedure. Did you ever install VMware vCloud Suite? Or BMC Cloud Lifecycle Management? Or Cisco Automated Suite for Clouds? Or Microsoft System Center? Or IBM SmartCloud Orchestrator? Or HP Cloud Service Automation? Or CA Automated Suite for Cloud? Most of these commercial CMPs are massively complicated multi-tier systems. In some cases, the vendor requires professional services even just to deploy them. Yet, large enterprises keep buying (some of) them to build their private clouds. Enterprise organizations demand software simplification, but if a smoother installation process is the only value an OpenStack vendor can provide that’s not really impressive.
When large enterprises decide to build a private cloud, they commit to a long and complex, multi-year, often million-dollar implementation. Accordingly, organizations evaluate the long term viability (i.e., Acquisition? Bankrupt? Radical change of the go to market strategy?) of their vendor of choice, if and how a vendor’s vision aligns with internal business goals, and if the technology roadmap will likely support their evolving needs over the many phases of the project.
Enterprises don’t buy a long term vision articulated around how great the software setup is and how many code commits you are responsible for.
4) Lack of pragmatism.
In my previous blog post, I described how OpenStack vendors divide into two camps that I called “purists” and “pragmatists”.
Purists keep telling enterprise prospects that OpenStack can’t be a general purpose cloud environment, able to host traditional multi-tier LoB applications as well as new cloud-aware applications. “Either your application can scale out or you are stuck in a VMware world”, I was told at the Summit. This, admittedly small, faction is the one that ignores how many large enterprises keep calling Gartner asking clarifications about what OpenStack is and how they could leverage it to reduce their dependency from VMware. This faction also ignores how incredibly hard and time consuming is for an enterprise organization embrace cloud design patterns.
Ironically, this faction includes players that waste no time in criticizing established virtualization or enterprise management vendors for not offering “true” cloud solutions. However, enterprise clients continue to buy “non-true” cloud solutions and OpenStack adoption in this market segment remains minimal.
Enterprises don’t particularly like vendors that show lack of awareness about the technical, organizational, cultural and political issues that plague their environments. How can these vendors be good business partners?
There are other, significant reasons why enterprises don’t buy OpenStack. I’ll talk about the technical issues in my upcoming research paper. The above are the ones why vendors can’t even get the attention they hope for.
Category: Uncategorized Tags: cloud management platforms, Gartner for Technical Professionals (GTP), OpenStack
by Alessandro Perilli | November 12, 2013 | 8 Comments
Last week I attended the OpenStack Summit in Hong Kong. What I saw, or what I think I saw, was so remarkable to me to be worth sharing in a more articulated way that Twitter (@a_perilli) allows me to.
Please note that being my first Summit, and being the event held in Asia, some of my observation may not reflect what I may see in a similar event in US or in Europe.
Specifically, I saw three things that merit a detailed report:
The emergence of a new class of IT organizations
The first day, during his keynote, Canonical founder Mark Shuttleworth asked the crowd how many were using VMware ESXi as their hypervisor of choice. Out of almost 4,000 attendees, only a handful of hands was raised. As a follow up, he asked if people preferred Open vSwitch or VMware NSX (formerly Nicira NVP). Again, very few hands raised (but truth to be told, VMware’s breakout session on the topic was very well attended). To me, it was a remarkable moment.
At Gartner, I focus on private cloud computing in the Gartner for Technical Professionals (GTP) division and in the last three years I interacted with many hundreds of large scale enterprise organizations, most in the Fortune Global 2000 group. The number of inquiries I get from this audience continues to grow exponentially, albeit most questions continue to focus on clearing up the confusion about OpenStack and understand its technical capabilities, maturity, and long term viability.
Traveling to Hong Kong, I expected to see a mixed audience, half composed of my typical enterprise audience and the other half composed of web scale companies, cloud service providers, and growing end user organizations. According to this expectation, I assumed to see a polarized audience of COTS software adopters and risk adverse large companies side by side with DIY believers and reckless organizations. It was not the case. What I saw is just the latter category, a world where VMware and many other mainstream vendors don’t have a place.
In further interactions with many people on site, my feeling grew significantly. I talked to organizations that show an attitude to risk more common in early stages startups than massive enterprises. These companies look at massive post-IPO web-scale firms like Google, Facebook, Netflix, and how they are rejecting packaged software in an unprecedented way and how they are building entirely homegrown computing stacks to become more efficient, more scalable, more competitive.
The OpenStack Summit attendees I talked to look at Facebook and how they developed their own automation stack to maintain their MySQL database, or at NetFlix and how they developed their own cloud infrastructure and management stack, or at Airbnb and how they developed their own uptime monitor system as models to follow. As result, OpenStack looks more attractive than most commercial solutions due to its inherent capability to mix and match different modules and deeply tweak the resulting cloud infrastructure stack.
The implications of a DYI approach are profound, and in some cases, organizations won’t see the impact of their choice for months, or years. While this is not the appropriate context to explore those implications (but my future research paper on OpenStack will touch on it), one point is out of question: there are a growing number of IT organizations that embrace risk in a new way and reject the established approach to enterprise software.
The question is if this new class of IT organizations will mature to a more risk adverse mindset as they grow, joining the pool of traditional enterprise companies, or if that risk tolerant mindset is here to stay. And if the latter: are vendors prepared to talk a language that resonates to this new class of IT professionals and offer them tools that can fit their needs? More on this in my third section below.
The divergence of opinions within the OpenStack community
The divergence of opinions within the OpenStack community is not news. Press, analysts (including Gartner’s Lydia Leong), and members of the OpenStack community covered this from many angles in the last three years. For example, just one day after the Summit ended, Andrew Clay Shafer, former VP of Engineering at CloudScaling (an OpenStack Foundation Gold Member), wrote a very relevant blog post on the topic.
Accordingly, I doubt I can add too much value to the chorus, but having experienced the divergence firsthand, I think it makes sense to highlight a point related to it. I saw two camps, polarized around what should be hosted on OpenStack:
- The “purist” camp, who believes OpenStack should be used exclusively to host “cloud-aware” applications (i.e., scale out, latency aware, fault tolerant, non-resilient workloads). In this camp, there are individuals who believe in, and vocally evangelize, a world where traditional multi-tier LoB applications should stay on VMware. They are telling to curious enterprises that there’s no place for traditional workloads in an OpenStack world.
- The “pragmatic” camp, who believes OpenStack can be used to host both cloud-aware and traditional applications.
Why am I calling the latter group “pragmatic”?
The emerging new class of IT organizations I mentioned in the previous section can afford to be more risk tolerant and enthusiastically embrace new, unproven technologies. That doesn’t mean that traditional large organizations wouldn’t want to do the same. An enterprise organization is subject to an enormous number of technical, organizational, political and cultural issues which bury most attempts to master the provisioning agility and operational scale seen at work in public clouds. Gartner for Technical Professionals advice (see my Field Research Actions to Take: Devising a Cloud Application Onboarding Strategy) to clients that prepare for application onboardiing in cloud environments is two-fold: focus on greenfield applications first, and develop an evangelization program to teach your developers how to think in terms of scale-out design rather than scale up. Hence, I understand where the “purist” camp comes from. However, we need to be pragmatic. The average large enterprise takes years to digest and execute the aforementioned advice. In some cases, it takes a generation change before their application portfolio starts to look how the OpenStack “purist” camp would like to like it to be. Meanwhile, these large organizations still see reasons to consider OpenStack (i.e., direct or indirect reduction of cloud infrastructure costs) as a hosting platform for their traditional LoB applications. The “purist” camp is telling this audience that OpenStack is not the product for them until they managed to develop scale-out greenfield applications, with the net result of freaking them out.
Whatever is the purpose and focus of OpenStack from this perspective, it’s time for the OpenStack Foundation to be more vocal, clarifying the message and work to align the message of participating members. The wrong message spreading too fast and too far has the only result of impacting in a negative way the perception of the industry at large being hesitant adopters, analysts, press.
The disruption within established vendors
As I briefly mentioned at the end of my first section, many established vendors may not be able to recognize the emergence of a new class of IT organizations, and many be unprepared to serve it as needed. You can tell by the legacy, tired messages that were prepared for the OpenStack Summit keynotes by too many distant, old school marketing teams. Those messages didn’t resonate to the audience and that was obvious to everybody, including the keynote speakers themselves.
And yet, during the event I talked to many talented and passionate individuals that were representing these many established vendors. Groups of people in engineering, marketing, sales, that see the emergence of a new IT world and the urgency to develop a new language and new tools. Those are the rebels within their vendor organizations. The ones that are fighting a battle against their own colleagues to change the mindset and to highlight the opportunity. It’s a difficult battle which requires a lot of political skills, determination, and time as far as I can tell.
These individuals are driving a change in their organizations but their attempts may be killed by the lack of vision and the slowness in execution. The biggest risk for vendors is to lose these talented individuals, defeated and departing to a technology startup where their skills can be put at better use. Vendors who don’t listen to their own OpenStack teams may lose the only resources they have to get in the new IT world I saw at the Summit.
Now it’s time for me to go focus back on the technology side of OpenStack and the way too many commercial distributions available on the market. A lot to be said on that too.
Category: Uncategorized Tags: cloud management platforms, Gartner for Technical Professionals (GTP), OpenStack
by Alessandro Perilli | July 19, 2013 | 2 Comments
In my many interactions with cloud management platform (CMP) vendors, a point of extreme concern is multitenancy. Of course, most of them recognize that a basic premise of multitenancy is network isolation. However, in too many cases, vendors can suggest that, above network isolation, implementing multitenancy simply is a matter of granular role-based access control. Too many times I heard vendors stating that if one user or group represents the cloud provider, and a number of sub groups represent the different cloud tenants, you have a multitenant environment. Of course, it’s way more complex than that.
A vendor that properly supports multitenancy must implement it at all levels of its CMP*. Some examples:
- Each tenant must be able to authenticate login credentials against its directory services. So, for example, tenant A may want to authenticate against Microsoft Active Directory, while tenant B may want to authenticate against OpenLDAP.
- Each tenant must be able to customize the self-service portal to reflect its identity. So, for example, tenant A may just want show its corporate logo and color scheme, while tenant B may want to completely mask any reference to the underlying CMP solution in the UI.
- Each tenant must be able to build and expose its service catalog in an autonomous way. And the cloud provider must be able to further populate tenants’ service catalogs with catalog objects that can be equally used by all tenants.
- Each tenant must be able to define dedicated resource allocation strategies. So, for example tenant A may want to allocate resources upfront, while tenant B may want to allocate resources as needed to address provisioning requests.
- If provisioning approval is enforced, each tenant must be able to define its approval policies, with specific levels of approval (if supported by the CMP solution), dedicated approvers, approval SLAs, and default approval action if no action is taken.
- Each tenant must be billed (or just metered) against dedicated chargeback (or show back) policies, and may enforce specific currencies. So, for example, tenant A may be billed against a pay per use charging model, while tenant B may be billed against a per-allocation charging model.
- Each tenant must have isolated automation workflow libraries for its instance of the orchestration engine. Automation workflows contain sensitive information about the whole IT infrastructures.
- Each tenant must have independent connections with preferred remote cloud environments. So, for example, tenant A may need integration with AWS, while tenant B may need integration with a vCloud service provider.
- Each tenant must be able to generate a variety of reports about the different aspects of the CMP though dedicated scheduling and customization.
The list goes on and on. In a truly multitenant cloud environment, each tenant must be able to setup and maintain all aforementioned policies and integration points without the intervention of the cloud provider.
Unfortunately, most CMPs on the market don’t implement multitenancy this way because it’s really complex.
The vendors’ argument is that most clients using CMPs to build private clouds don’t need this level of sophistication. This is certainly true for many organizations at the beginning of their cloud journey. However, in my interactions, all large organizations building an on-premises cloud serve (or plan to serve) different business units and departments that have different security levels and dedicated IT infrastructures. Additionally, many of those large organizations contemplate the idea of exposing their initially-private clouds to external entities (e.g., business partners, federated agencies).
In other words, beyond the public cloud use case, there are situations where poorly implemented multitenancy is a deal breaker.
If you are an end user organization, you should really evaluate how robust multitenancy is in your CMP of choice.
If you are a vendor, you should really anticipate the need of your maturing customers and stop pretending that multitenancy is just network isolation, group hierarchies and RBAC.
*If you are curious about what are the management functions and the capabilities that Gartner recommends for an enterprise-grade CMP, I recommend you reading our research titled: Evaluation Criteria for Cloud Management Platforms
Category: Uncategorized Tags: cloud management platforms, Gartner for Technical Professionals (GTP), mutitenancy, RBAC
by Alessandro Perilli | June 11, 2013 | 1 Comment
Twice per year, a number of Gartner for Technical Professionals (GTP) analysts are involved in a fascinating research project that we call Contextual Research.
We identify a highly interesting technology to our clients, and go interviewing a number of early adopters worldwide. We anonymize, atomize, analyze, and re-aggregate information captured during the interviews in the attempt to extrapolate adoption trends, common challenges, and best practices.
In first quarter of this year, I had the privilege of leading a contextual research project on cloud orchestration. A very talented team of colleagues and I met 15 end user large organizations and cloud service providers across North America and Europe with significant experience in private and public cloud automation.
These organizations customize the self-service provisioning process offered out of the box by their cloud management platforms (CMPs) through automation workflows that cross multiple IT silos, orchestrating the deployment and configuration of infrastructure resources, VMs, guest operating systems, middleware and, in some cases, full applications.
Some of the organizations we interviewed stumbled along the way but ultimately succeded, others failed (an invaluable experience that gave us precious guidance) and are rethinking their original approach. In all cases, unsurprisingly, we found out that orchestrating a cloud environment beyond out of the box capabilities is extremely complex and is worth the effort only to a certain point for most organizations.
Here’s a quote from one of our participants highlighting how complex orchestrating a cloud can be:
In theory everything should work with everything.
In practice, a backward compatibility issue on a component generates this domino effect where everything fails.
I will present our findings, including clients’ best practices, on stage at the Gartner Catalyst conference in late July in San Diego with the following presentation:
Cloud Orchestration: Client Insights and Best Practices
This session takes a deep look at lessons learned from enterprises and cloud service providers that participated in Gartner’s cloud orchestration contextual research project at the beginning of 2013. The session highlights the challenges participating organizations faced in their quest to orchestrate private and public cloud environments, which technical solutions they implemented, what they would have done differently, and what the real benefits and pitfalls are with respect to automation in a cloud world.
Category: Uncategorized Tags: cloud management platforms, contextual research, Gartner for Technical Professionals (GTP), orchestration
by Alessandro Perilli | February 26, 2013 | Submit a Comment
Last summer, Gartner for Technical Professionals (GTP) released an assessment framework to help organizations review and compare cloud management platforms (CMPs): “Evaluation Criteria for Cloud Management Platforms“.
In most cases, CMPs are massive software management, automation, and orchestration solutions that sit on top of a virtual infrastructure and turn it into a cloud environment. A CMP solution can include multiple software layers, as we describe in our reference architecture template for private clouds called “Infrastructure as a Service“. On average, CMP offerings certainly include a self-service provisioning portal, a back-end service catalog, and in most cases an orchestration engine. But the more sophisticated products can also present features in other areas, like performance and capacity management, life cycle and configuration management, charge back, as well as connectivity to and management for external clouds.
To meet the needs of our enterprise clients with large-scale production environments, all the software layers included in a CMP solution must be tightly integrated and offer new capabilities (or new implementations of existing capabilities) required to address the challenges of cloud computing. For example: do you think that capacity management is not too different in cloud environments compared to physical ones? Think again.
Evaluating the integration and feature set for such a broad and complex offering is a daunting task. Plus, the market is crowded by alternatives, as we describe in our “Market Profile: Cloud Management Platforms, 2013“.
That’s why, to help our clients untangle the intricacies of CMPs, our Evaluation Criteria for Cloud Management Platforms includes more than 200 criteria over 139 pages. And that’s also why Gartner is publishing a number of in-depth assessments for existing CMP solutions based on our own framework.
Microsoft System Center 2012 Service Pack 1
The first assessment we publish today is on Microsoft System Center 2012 Service Pack 1, a product that our clients look at with increasing interest.
Microsoft System Center 2012 Service Pack 1 only meets 58% of the criteria we consider indispensable in an enterprise-grade CMP for large scale production environments. There are a number of areas where the product can improve and mature, especially in terms of integration with third party tools, support for non-Windows guest operating systems, and functional areas like capacity management.
Anyway, the rating should not be considered overall negative. As our clients will see in subsequent CMP assessments that we will publish this year, no offering available today satisfies 100% of Gartner required criteria. We are in the early stages of the cloud management era, and major vendors are still redefining their technology road maps and adapting their current offerings (often augmenting them with a number of acquisitions).
Microsoft has some work ahead to evolve, refine and mature its CMP. Yet, the solution is still drawing considerable interest from our clients. Selecting a CMP is just as much about vendor relationship as it is about features and functionality. Some customers are willing overlook current deficiencies because they believe in Microsoft’s commitment to the platform and in its ability to deliver on that commitment.
Like Microsoft, all other CMP vendors have work to do, some more than others. Overall, I believe that game has just started and there will be ample room to compete and deliver what our clients are demanding.
Category: Uncategorized Tags: cloud management platforms, Gartner for Technical Professionals (GTP), in-depth assessments, Microsoft, System Center