by Alessandro Perilli | January 18, 2014 | 3 Comments
My first client interaction for 2014 was with a large enterprise busy building a private cloud. Like hundreds of customers I talked to in last three years, this organization is struggling to enforce service catalog standardization, to the point that I sarcastically commented on Twitter: “Hello 2011…I mean 2014“
My own comment triggered the urgency to look back at all observations on cloud management platforms and private cloud computing that that I publicly shared on Twitter (@giano) in 2013. The full list is below*.
How much of what I said last year will still be true in 2014? How the CMP market will evolve and solve some of the issues that I highlighted in last 12 months?
- Unsurprisingly (and unfortunately), selecting a cloud management platform is often a matter of perception.
- Only during an in-depth assessment of a CMP you realize how much a vendor wants you to do in a manual/custom way. And it usually is too much
- In the race to build the perfect CMP, acquisitions will focus more & more on configuration and lifecycle mgmt, performance and capacity mgmt
- “Support for multiple hypervisors” in CMPs must go beyond feature parity on basic life cycle mgmt. Example: what about scalability limits?
- Dear vendors: “multi-tenancy support” should mean support at all layers of your cloud management platform, and for all supported hypervisors
- Believe or not, one of the many challenges in evaluating a CMP is understanding exactly what it does/doesn’t. Fear poor documentation.
- Be careful with products included in a CMP bundle. Some editions may lack the features you assume available and there may be no upgrade path
- Most CMPs from major vendors are evolving from a bundle of repurposed apps. For some, it may work over time. Others should consider a reboot
- How cloud management platforms sell: 99% perception, 1% features.
- Always investigate customer references. Always interpret customer references. What you assume can be far from reality.
- Another two clients struggling to move from VM provisioning to application provisioning in their private cloud. Almost on daily basis now.
- “cloud platform” and “cloud management platform” are not the same. Not a matter of terminology. What ppl mean with those terms is different.
- Reviewing notes from our ongoing field research study. Orchestration engines in cloud mgmt platforms are not as sophisticated as they should
- Inquiries on multi-hypervisor private clouds keep growing. Awareness that multiple hypervisors must be supported at all CMP layers doesn’t.
- The more I assess cloud management platforms the more I wonder: are startups focusing their differentiation effort in the right direction?
- Question from client: “Which cloud management platforms match these RFP requirements?” Me: “How many days do you have for this answer?”
- Pleasing changes: more and more when I visit clients to discuss CMPs, at the table sit together guys from arch, infra & ops, apps, and sec.
- Clients keep asking about managed private clouds. I keep answering that lack of expertise and transparency are key aspects to consider.
- Venerable enterprise org, you didn’t know but you actually invested in a false cloud. Sorry. Oh, does it work well for you? Never mind then.
- This whole idea that there is a “true cloud” is always entertaining.
- The more I do it the more I’m convinced that reviewing cloud management platforms’ doc is close to legal doc review in patent litigation…
- I see IaaS, PaaS and SaaS definitions are more confused than ever in 2013. Great progress.
- Flash news: there are plenty of orgs considering or implementing multiple virtual infrastructures and/or multiple CMPs. Business as usual.
- A mostly undifferentiated crowd of CMP startups only generates confusion. In a confused landscape orgs step back and go for trusted vendors.
- Without an early, well defined private cloud strategy, orgs can end up with multiple CMPs, followed by an expensive, complex consolidation.
- Choose your early adopters carefully because much of your CMP success depends on how their feature requests impact your product roadmap.
- CMPs offering multiVM catalog objects must support them at all layers: performance/capacity/lifecycle mgmt, etc. Provisioning is not enough.
- I reviewed over 4K pages documentation for just 3 cloud management platforms since Jan 2013. Reset expectations about Zero to Cloud in 20min
- Impressed by the growing number of orgs asking for a cloud management platform able to support both VMware VMs and IBM Power LPARs
- Many underestimated VMware Lab Manager popularity (and how big the demand for virtual lab automation features is). A big missed opportunity.
- Designing a cloud management platform for large scale deployment should influence product architecture, features, API, and UI. All of them.
- OpenStack distro sprawl, and their common characteristics, should tell something about the project.
- With a growing focus on orchestration and software-defined networks, I wonder when we’ll start talking about self-defending clouds.
- After ongoing market consolidation, at some point, new startups entering CMP market will have to come up with new ideas, not AWS/vCD clones
- Despite top down mandate, not all organizations need a private cloud. Really.
- Many orgs recognize need for process gov in private cloud too late, when dealing with cat obj sprawl & uncertain forecast for capacity usage
- Year 2013. Still this sneaky suspicion that “private cloud” is “virtualization” and “public cloud” is “hosting”. Nobody finds courage to ask
- 3 out of 4 clients -just today- said they want to build a private cloud to automate application provisioning, not just OS. Growing trend.
- Typical sign of CMP immaturity: extended feature overlap across its management modules. From mktg bundle to converged product = huge effort.
- The implementation of multi-tenancy in today’s cloud management platforms is entertaining in most cases.
- Eventually, people will realize that provisioning is just part of catalog object life cycle in the cloud. You have to govern those objects.
- Yet another org looking for a Cloud Mgmt Plat able to support both x86 and Power virtual infrastructures and dissatisfied by market maturity
- Many orgs would prefer a managed private cloud to building their own. Challenge is assessing claimed expertise and get proper env visibility
- Another day, another call with a client preferring to consume a managed private cloud rather than building its own private cloud.
- While virtualization vendors were busy killing their virtual lab automation tools, app owners were busy installing Vagrant, Chef, and Puppet
- Fascinating how our US and EU clients have same burning questions about cloud. I am glad we have plenty of written research to address them.
- Top Qs from clients in Spain: how to build a private cloud, who is best MSP for a managed private cloud, how to become a service broker.
- I thought that keeping an up to date list of CMP vendors was hard. I see that keeping a list of OpenStack distros is even more challenging.
- Who’ll be faster? Next gen config mgmt tools at becoming CMPs, or CMPs at swallowing next gen config mgmt tools?
- AWS blindsided too many cloud management vendors. All building same product. Not enough trying anticipate the imminent needs of large orgs.
- Despite massive ongoing consolidation, the cloud management market still is a sea of opportunities. Missed opportunities, apparently.
- Yet another large org complaining for VMware LabManager EOL. Amazing how many people used it as “just enough” cloud management platform.
- I started advocating the use of automation in 2006. Sad to see in 2013 we are still far away from where we (orgs & vendors) would like to be
- I love “we-manage-a-single-VM-with-a-wiki-which-is-thousands-miles-away-from-any-real-need-large-enterprise-prospects-we-target-have” demos.
- Too many cloud management offerings look great on paper but disappointing at implementation time. For RH, it will be a matter of execution.
- Unsurprisingly, orgs building private clouds find licensing a limiting issue in automated provisioning. Time to rethink your approach ISVs?
- Once you enable perf monitor in your cloud env you’ll instantly have a big data problem.Can you easily scale your on-prem CMP to address it?
- Cloud management platform vendors should seriously consider a SaaS delivery model. Today’s solutions too complex to deploy, scale, expand.
- “What cloud do you think is more secure? Private or public?” Audience overwhelming answer: private. #GartnerCAT
- eBay’s Chief Engineer: “OpenStack is Not Cloud” - goo.gl/GyLQ8f > Amen. I wrote 139 pages on what’s missing: goo.gl/j4MpBT
- Most of the innovation we saw in cloud management so far was focused on provisioning. Can we innovate the remaining part of the life cycle?
- In cloud management platforms, “multi-hypervisor” and “multi-tenancy” are two dangerous terms. Beware of what vendors actually mean by them.
- From where I stand, given the cloud management market demand and evolution, I see at least 3 startups that have a remarkable opportunity.
- Fulfilling the promise of cloud computing requires a programmable infrastructure. HW that didn’t adapt rapidly enough is now virtualized.
- Problem is automating (re)actions based on monitored performance and events occurring in the cloud.
- Cloud success requires a lot of tweets.
- Not enough ambitious startups in Europe. Plenty of untapped opportunities in cloud, virtualization, and enterprise management markets.
- Typical inquiry of mine: Top management said we need a private cloud up and running in X months (where X is borderline surreal).
- Private clouds are maturing at an incredibly slow pace. Most adopters are still stuck in the “building” or “re-building” phase.
- When a vendor’s customer reference *just* implemented a tech you never know the outcome. In 6 months it could be replaced because inadequate
- These days the “de facto standard” status is achieved by ubiquity in press, not implementations. Especially in cloud computing.
- Can a technology be considered a “de facto platform” when everybody is talking about it but very few actually implement it in production?
- Dear mainstream vendors: you better simplify and cut features overlap in your CMP *now*. Your clients are losing faith. You won’t recover it
- More than ever, complexity and cost plaguing CMPs from mainstream vendors is driving clients’ attention towards startups’ alternatives.
- Inquires about skilled and trustworthy consulting firms to build a private cloud, and best providers for a managed private cloud skyrocketed
- During evaluations, always ask to your customer references how often they used PSO, and to the vendor how many fixes went back into product.
- Don’t confuse *interest* with *adoption*. A lot of people talking about a product/tech doesn’t mean they are actually using it.
- Ask your vendor (and yourself): what’s the difference between virtual infrastructure mgmt and cloud mgmt? You’ll be amazed by dance activity
- From where I stand, the opportunity for outsourcers to build managed private clouds remains massive. But they have to hire & retain talents.
- Dear cloud management vendor, your internal IT is your best ally to develop features you need to win enterprise prospects. Listen to them.
- Why do commercial cloud infrastructure solutions based on open source projects (e.g., OpenStack) change their product name every few months?
- The *very few* orgs that calculated the ROI for the cloud orchestration effort *know* how expensive it is. Others underestimate it.
- On average, a complex brownfield app will take 6 weeks min. to be converted in a catalog object with correlated automation workflow
- Starting onboarding from brownfield, complex, legacy apps is a recipe for disaster (as the many FG2000 I talk to regularly confirm)
- Building a cloud mgmt platform through best of breed approach is great in theory. In practice I have a line of clients that tried and failed
- Double check case studies. I keep hearing clients replacing their cloud mgmt platforms for technical, organizational, or political reasons.
- Listen. It’s the sound of the cloud management platform market shrinking. Very few valid CMPs left to be bought. I can see the next ones.
- I’ll never stop to be amazed by how badly cloud management startups know their competition and what large enterprise orgs actually want.
- Calls with clients about how they replaced a cloud management platform with another are always fascinating. So many failed expectations.
- Clients building private clouds continue to expect the automation of a full LoB app stack provisioning without anticipating complexity.
- Ironically, it seems like the more crowded a market segment gets the least vendors try to differentiate.
- Yet another client planning to build a private cloud but actually wanting simple virtual lab automation. I’m sounding like a broken record.
- Once again: CMP multi-tenancy support is not even close as robust as vendors suggest. My post on the subject: goo.gl/LFubiv
- Yet another org considering a private cloud on top of VMware ESX and Power VM. This is the multi-hypervisor demand vendors should focus on.
- The fact that PayPal -not a vendor- adapted Netflix Asgard to support OpenStack tells how inadequate current CMPs are to address mkt demand.
- Too many dashboards, not enough execution plans. And not enough automated execution plans.
- The assumption that provided appropriate insights humans will execute a remediation plan (or the best possible remediation plan) is wrong.
- Who has the most to lose if OpenStack successfully penetrates the enterprise market? The one that has the most adopted virtual resource mgr.
- Yet another org looking for a virtual lab automation tool. CMP vendors: are you waiting for me to set up an online petition before you act?
*Before you come to any conclusion by reading the above Twitter activity, keep in mind that tweets force brevity, remove context, and don’t reflect in full the opinion and analysis developed in my lengthy research documents. Please refer to my Gartner for Technical Professionals research
for in-depth coverage of the private cloud market and the cloud management platform landscape.
Category: Uncategorized Tags: cloud management platforms, Gartner for Technical Professionals (GTP)
by Alessandro Perilli | December 6, 2013 | 10 Comments
Despite all hype, the private cloud computing market is still in its infancy. The enterprise customers deploying what we call at Gartner “cloud management platforms” (CMPs) are in the order of the thousands. Not insignificant, especially given the size of the accounts that buy CMPs, but far away from mainstream adoption.
Evaluating the few dozen alternatives (you can read a list of them in my research document Market Profile: Cloud Management Platforms, 2013), IT organizations naturally try to understand which vendor is preferred by industry peers, or more in general which CMP is the most deployed. Answering the question is all but simple, and it’s easy to be misled.
The most sophisticated CMPs usually are a bundle of multiple management tools retrofitted to address the cloud management use case, glued together by some unification code or point to point integration.
When a vendor cannot count on an existing application portfolio to repurpose, it has to proceed with a bunch of acquisitions, but the end result is the same: a collection of different tools that must work together in a way they were never meant to.
In fact, a way to measure how mature a CMP is consists of evaluating how well its management modules integrate with each other.
In many cases, a large enterprise already owns and uses one or more management tools that coincidentally are also offered as part of a CMP. Hence, the vendor upsells the CMP for that installation base. The customer may well buy the CMP license but does not necessarily deploy any additional component.
In other situations, given how many modules a CMP may include, and how complex is to deploy and operate all of them, customers actually use just a couple of them, out of four, six, twelve included in the SKU, hoping to roll out the others with a phased approach (that may take years).
The result is a series of claims where vendors report great customer wins, but where in reality customers deployed a couple of CMP modules long before they were included in a CMP SKU, and maybe those modules are not even the ones that should be considered key enablement for cloud management.
Then there are those situations where customers decide to implement a CMP but their expectations are completely failed in just six-to-twelve months. Many things can go wrong: the deployment time promised by the vendor goes beyond the deadlines, the CMP features are insufficient to the address customer’s needs, the integration with the existing enterprise management tools requires a lot of unexpected professional services activity, and much more.
In all those situations, the IT organization has to go back to the drawing board, select a different CMP, and go through the painful process of replacing the unsatisfying product.
That’s why, when we evaluate CMP market penetration at Gartner, we spent a great amount of time reviewing customer references, asking people what pieces of the CMP they actual deploy, how they are using them, or if they changed CMP for some reason. Sometimes the interview reveals that what the vendor sold as a CMP implementation actually is not, or it’s not even close to what it should be in terms of components deployed and how they are used. In other situations, we incidentally discover that a CMP has been abandoned in favor of a different one.
Bottom line: don’t believe claims about private cloud market share. Every implementation must be carefully reviewed and re-verified after a few months. And this exercise paints a picture that can be very different from the one CMP vendors describe.
Category: Uncategorized Tags: cloud management platforms, Gartner for Technical Professionals (GTP)
by Alessandro Perilli | November 19, 2013 | 72 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 | 12 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 | 3 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 | 1 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