Unicorns, Pendulums and Private Clouds
Last week Alessandro Perilli of Gartner posted one of his controversial takes on cloud. In this particular post he, basically, pointed out that many CMP vendors aren't really selling a truly integrated cloud management platform software.
Instead, they are proposing a rebranded old piece of software augmented with new fitting-hole products. These new products have been growing inorganically inside the company or, even worse, have been made available in the portfolio through acquisitions. As a result this CMP software stack is all but integrated.
Granted that different vendors have different level of (dis)integration in their respective cloud management software stacks, Alessandro hits a valid point. As usual, hard to counter argue.
Since this problem is close to my heart (professionally speaking), I decided to take a quick stab and made a comment on Alessandro's post.
Eventually, I thought the matter is hot enough that it warranted a quick blog post (this) to clarify my thoughts. Here I'd like to expand on the two points I made in my comment on Gartner's blog and I'll close with some personal considerations on the "private cloud".
You can call this a "survival guide for CMP vendors". Not sure I am smart enough to make them actually survive... but at least I am going to tell them what they are going to die of. Figuratively of course.
The first point I made (and that I glossed over in my comment) is related to the fact that building a fully integrated CMP software stack takes a lot of time. Particularly because the list of things that this software stack is supposed to do is pretty long (ironically, Alessandro created that list of things).
The time lag between the layout of an overall strategy, the creation of the detailed specs of what the CMP should be doing and the execution to build this stack isn't something that could be done in a week.
In an industry where the standard release cycle of a complex software stack often have an annual cadence (sometimes bi-annual cadence), you can easily understand that it is a multi-year effort to deliver a fully integrated, rich and complex CMP stack that you can deploy with a next-next-next-next-done experience.
Surely many startups in this space have a much quicker release cycle than the traditional incumbents. However, even assuming they have the richness of the multi-disciplines features required (as defined by Gartner), in an industry with more vendors than (actual) customers, it may be a risk to bet on a horse that could either go belly-up at any time or that could be acquired by an incumbent. And ironically, the latter option is part of the problem Alessandro was describing in his post.
So on one hand we live in a world where executing is very difficult and it's a multi-year effort (because the problem and the "ask" is gigantic) but on the other hand we also live in a world where people's imagination marches (or run?) very fast and what was "cool" last year may be "legacy" this year. For example last week was the week of "well IaaS was interesting but it was useful to a point, the real thing is PaaS". So the industry is still in the middle of the mess described by Alessandro and people are already thinking about "what's coming next".
And this is one of the many things that make the stabilization of a fully integrated stack so difficult. You are in the middle of a journey to get to a point outlined by your strategy and something all of the sudden happens that makes you question your original strategy. That is bad because it has direct effect on your software product specs that forces you, ultimately, to go back and retro fit new stuff into your original plan (either through acquisitions or in-house inorganic growth to gain speed).
In a scenario like this integration is a unicorn because the vendor's stack is always in maintenance mode to make it evolve according to the asks. Ironically many (but admittedly not all) of these asks are coming from either leading edge customers or cloud thought leaders, leaving the rest (and majority) of the world behind.
The Infinite Pendulum Swing
Another point I made in my comment on Alessandro's post is the concept of the infinite pendulum swing. I have been in this industry enough to notice an interesting pattern.
Let me express this concept with a small BASIC program:
110 Customers want more integration because they spend too much time putting stuff together. 2 320 Customers want their vendor of choice to take their 20 products and turn them into a fully integrated software stack. 4 530 Vendor (eventually) delivers on the promise. 6 740 Customers realize they are now locked into the vendor as the stack is so tightly coupled that they have to "buy it all". They can't just cherry pick products separately (and, similarly, integrating a third party product may not be easy). 8 950 Customers ask the vendor to make the stack more modular so that can cherry pick what they need or they can choose to switch any of the products at any time. 10 1160 Vendor (eventually) delivers by (dis)integrating the stack to make it more modular and more loosely coupled. 12 1370 Customers realize that integrating these products is becoming very difficult and ask the vendor for more integration between products (oh where did I hear that?). 14 1580 (oh yeah) GOTO 10.
An infinite loop. No escape.
If that is not sad enough, how about this: the vendor doesn't even ever get to the point of a fully integrated stack or a fully modular stack. Simply because the pendulum swings so fast (related to the capability to execute) that the vendor needs to change course right in the middle of the journey to an end.
To complicate things further, it is not only the customer requiring more modularity. Sometimes the vendor is interested (rightly so) to be able to sell a single product standalone without having to prereq another 17 products to get it working. So the pendulum may be swinging also for reasons related to the business model and priorities of the vendor itself.
All in all, if you are a customer, I am sorry. You need to choose your poison at this point.
You have to either choose a "modular" strategy where you spend 2 years and 2M$ to create a "private cloud", or choose an "integrated" strategy where you go "all in" with a complete vendor stack.
The Forces at Work
If you followed my rant so far, you realize there are two orthogonal forces at work here. Both try to stretch the CMP vendor in four different and opposite directions. I tried to visualize those in the next picture:
The first (north) stretching force is represented by the notion that what you have been doing so far is old and you need to evolve.
"LMAO if you think IaaS is still interesting, PaaS is cool today" is an (admittedly extreme) representative statement of that unicorn force.
The other (south) stretching force is represented by the other people (in the real world) that deal with practical day to day business problems and, admittedly, are also a little bit behind the curve.
"How can I integrate my AS/400 into my private cloud?" is a question I heard last week. No kidding. Gee, what a #facepalm.
The last (east <-> west) stretching force is represented by the infinite pendulum swinging theory I described above. As I said this swinging can be driven by either customers or the stack vendor itself but it is definitely a disturbing force when you try to move north evolving your software stack (and doing that at a pace that doesn't let the "AS/400 customers" feel too left behind).
And now look at the CMP vendor person in the middle. Poor guy (or girl). Whatever.
For the records a lot of people designing public clouds look a lot like the person in the picture above. You (as a consumer) just don't see them, lucky you. You only see a fancy UI and API set.
Does the Private Cloud Exist?
The last sentence in my comment on Alessandro's blog generated a bit of interest as well. That was: I am also questioning whether a “private cloud” can even exist and makes any sense.
I guess this discussion boils down to what you mean by "private cloud". If you go by the NIST definition I would argue that building a private cloud is close to impossible. And frankly, by that definition, there could be only a handful (literally) of cloud providers worldwide that can deliver a true IaaS public service.
I do have my own (very personal) ideas re what's going on in the private cloud space. However I feel like I am running a bit out of gas in this blog post. This matter is complex enough that it warrants a dedicated post on its own.
Suffice to say that the combination of the challenges I have described in this blog post along with the challenges I have described in previous blog posts make owning a private cloud an interesting job (euphemism being abused here).
This is also why there is a raise of interest in consuming a cloud rather than owning it. It must also be said that, given I don't see 100% of workloads moving to a public cloud (and not even 90%) there is a huge opportunity for CMP software vendors to do a good enough job to win the (big) non-public portion of the cloud business. Since I always like to quote myself:
"the vendor that will win the on-premise battle in the next 5 years is not the one whose software is the best but the one whose software sucks the least (you’ll excuse the language)"
The full story is here.
Last but not least, on top of the technology challenges I am describing, I have to also admit that customers (in the real world) aren't making this transition to cloud easy.
I met the same customer three times in the last year and they went from "I want to build a private cloud" through "I want to sell cloud capacity externally and become a public cloud provider" all the way to "I want to consume a public cloud".
All in 12 months. Talking about changing strategies and directions. Wow.
And this does not even take into account those customers that are after what I call the Frankencloud. Which adds complexity on top of an already uber complex matter.
Jeff Sussna would argue that, while these (IT) folks are lost in the middle of all this, their developers and business units are bypassing them and going straight to public clouds. Jeff does have a valid point and, whether this will happen or not, it will depend on a number of reasons, including how quick these IT folks are going to adapt to the change and what good (enough) of a job the CMP vendors are going to do.
I'll take a wait and see approach on what's going to happen but, as my forefathers used to say, "In medio stat virtus" so I'll salomonically say that in the next 5 to 10 years it will be a 50/50 split between on-prem and off-prem infrastructures. Whether the 50% of on-prem infrastructure can be defined as "cloud" (Vs. glorified virtualization Vs. legacy orchestration Vs. whatever) is part of another long due blog post that I have had in mind for a while.
This old one should give you a hint though regarding what I think how the "private cloud" will look like (on average) in the short and medium term. For long term I don't have a crystal ball.