Let a thousand public clouds bloom

As the world is admiring how well Google Cloud has caught up and how they are offering an immense competition to AWS, I cannot but lament the golden opportunity that was wasted by OpenStack community.

As you know, I am a public cloud proponent.  But, I am not a fan of centralized power between just two players in the industry – it is bad for customers and innovation. Unfortunately, we are headed down that path for foreseeable future. We have Amazon, Google and mostly also-rans lagging far behind. (Expect next IAAS MQ to have these two guys in upper quadrant and rest in the lower middle).

Where has OpenStack gone wrong? It tried to be an Uber solution. It failed to make choices. It let time pass and hoped inaction will somehow fix things. It lacked decisiveness. It spent more time arguing and preventing good people from furthering their case than making progress. It refused to listen to good outside people.  I get it is an open source project. I get that there are too many cooks in the kitchen. For all the millions spent by companies working on it, if they stepped back and considered the market dynamics, they perhaps could have made different choices. All I see is every player mapping how OpenStack be a supplement to their existing business. Their resources, processes and values are optimized for status quo.

There are many hosting companies. These guys were the innovators in the 90s. They dropped out of schools to start these hosting companies (and I am not just talking about RAX, there are many others that fit this profile). They moved to virtualization when VMware innovated in the space. They were rewarded well for that choice.

After virtualization, Amazon came around with AWS. It was new innovation. Amazon is a closed and greedy company – they would not share neither their technology nor let these hosting companies play in the ecosystem well. VMware fell into classic Innovator’s dilemma and is digging a deeper hole that it cannot get out of. VMware is not the solution these hosting companies need.

This was an opening OpenStack had. When AWS gained ground, it gained ground with developers.  AWS smartly went beyond developers and started appealing to production workloads. It was either you do AWS or you refuse to go public cloud. In many companies, VP of App development often wins against VP of Operations in arguments. So, whether they liked it or not, VP of Ops had allowed use of AWS. Amazon is winning this war. Google will take its share as well.

What could OpenStack do? Instead of scratching the itch of its backers to make enterprise sales, they should have focused on the hosting companies. They should have made OpenStack the default choice for the operators. They should have made it stupidly simple to co-exist and interoperate with AWS. They should have embraced AWS for dev usage with open arms. Instead, they viewed AWS as an enemy before they were the enemy. They could have removed the friction of moving to public cloud. Moving production workloads to AWS is still a disruptive process for many companies. Migrating to public cloud without changing out your vendors and giving up owned infrastructure is less friction than outright moving to AWS/GCE ( contracts, getting used to support model, relationships are just few examples of friction ).

I believe OpenStack still has a small choice to become an attractive choice for operators. But, first they need to stop talking about private cloud for end customers. Private cloud is a fool’s errand, they are not only fooling themselves, they are screwing their customers too, because 100% of private cloud deployments will fail.  They have same problems of owned infrastructure that IT wastes millions of dollars on.

OpenStack needs to be laser focused on cloud operators and let many public clouds come to market that can play nicely with each other and embrace AWS and GCE as part of the ecosystem. You may say, but some operators already use OpenStack – the question is whether its possible or not, its whether they are focused on it or not.

Oh, and for not a minute, do not think OpenStack can move into ill-defined PAAS space or a container is going to be their savior. Case in point, we are currently witnessing the slow painful death of Solum.

You know, I keep thinking perhaps, it’s not OpenStack, but CloudStack that may enable this, but I am not too familiar with them. Perhaps, should take a closer look.

Industry needs robust set of competitors – a two vendor market is not a good future for IAAS. We need more.

Let a thousand public clouds bloom.


Do not do Private Cloud

As you know, I am not a fan of private cloud. To me private cloud is nothing but virtualization with some smoke and mirrors on top of it. It is the early 2000s technology and trying to build your own private cloud is both ill-advised and expensive. Not only that, building a private cloud may also be a career limiting move for CIOs as more and more CFOs and CEOs are becoming aware of advantages of public cloud and are demanding IT budget reductions. Below are some of the reasons why you should go 100% public cloud.

  •          Elasticity to match the seasonality of your business

–      Scale up and down as your business needs change for ex: based on seasonality, a special marketing campaign or Reddit talks about your app. Do not make capacity planning a huge deal – deal with it as part of your day to day operations.

  •         (Practically) Infinite capacity

–      It is unlikely that you would ever hit the limits of public cloud capacity; you can assume to have access to unlimited infrastructure resource – do not let IT capacity be a limiting factor for your business growth.

  •         Rate of innovation

–      For most part, AWS and IAAS can innovate faster than your team ever can. IAAS is their core business, not yours. You do not want to enter a horse race in building infrastructure; you will put your app developers and company at a huge disadvantage compared to your competition. Your innovation should be in your core business and applications and leverage the scale of larger IAAS vendors. This is one reason you should move off of colo data centers and move to IAAS as soon as possible.

  •         World class SREs

–      The best Site Reliability Engineers now work for Google and Amazon. These are the experts in building scalable, highly available infrastructure – your current budget may not even come close to being assemble an excellent team of SREs if you maintain your own infrastructure. It is a fool’s errand, do not pursue it.

  •         Falling prices

–      Granted, IAAS prices are still bit more expensive than what you pay to hardware upgrades on what you already own, but IAAS vendors are dropping prices faster than Wal-Mart is dropping prices on Candy. Signing up with either Google or AWS would ensure that you will get the best price possible. Google does have slight advantage here because you don’t have to pre-commit to a reserved Instance as in the case of AWS. Unless there is a strong reason to go AWS, I would recommend Google here. If you build your own private cloud, not only you are spending CAPEX, which is a sunk cost and also you risk your infrastructure being outdated when compared to your competition.

  •         Space reduction

–      Data Centers are not cheap and renting space there is both expensive and painful. By going public cloud, you reduce this pain, and you may never have to set your foot into an ugly data center again.

  •         OPEX instead of CAPEX

–      Lower CAPEX means more CFO love. Yes, you can’t take advantage of depreciation on capital equipment for tax write off, but reducing CAPEX requirements will bring your IT in-line with rest of the industry and you will look good in the eyes of your CFO and CEO.

  •         No need for Data Center engineers

–      If you own and run your own data centers, you have to hire data center engineers to manage physical stuff and power. This used to be cute in the mid-90s and it stopped being so lately. You also have to buy insurance on your data center and concerns because data centers tend to get hot and often not the safest places to work in with wires dangling around. Would it not be better to cut off this expense? Now, you can mitigate some by going with Co-lo, but why go half way when you can fully get rid of all risk by going public cloud.

  •         Faster provisioning of resources – time to market

–      Your app development team wants servers and storage as fast as possible and instead of hiring an army of IT provisioning engineers, you would be better off enabling self-service cloud resource provisioning for your app development team. They would think you are cool and you also reduce the load on your team, so they can focus on value added tasks. Yes, you can give them a lab manager, but you will be having a different mess on your hand. Just say no to managing more infrastructure software.

  •         Security & Compliance

–      The balance has shifted – it can be argued that public cloud is more secure and you can demonstrate infrastructure compliance easily on public cloud than your owned infrastructure. The public cloud vendors have the best staff, tools, processes and resources to ensure that the infrastructure you rely on is both secure and compliant with whatever standard you need to meet. For ex: PCI, FedRamp and other compliance mandates are already supported by AWS.

So, when it comes time to refresh your technology infrastructure, trash it, and leverage public cloud – you would thank me later.

Disagree? Comment below or tweet away.



Is there a way to succeed with OpenStack?

Several experts and non-experts such as me have criticized lack of focus and leadership in OpenStack efforts. It often felt like they were playing the wrong game, chasing wrong enemies and were running around in circles. To add to this, several folks have highlighted problems with the technology itself. Technical problems can and will be fixed, but headed down wrong road because you had a bad strategy will sting quite a bit.

Is OpenStack done? Not really, I do see a path forward for (large) companies to succeed and make money with OpenStack. I will outline my thinking here.

First few observations:

  1. The game for the future is Elastic Cloud – provide (perceptively) infinite compute, storage resources as a start for your customers and do not let them experience limits of infrastructure that traditional approaches surface.
  2. Private Cloud is a flawed thinking that will run its course soon.
  3. This requires willingness to offer low cost offerings and compete on price for commodity infrastructure resources.
  4. Realize that it’s actually not a zero sum game. You don’t only win if rest of the market loses – it’s still an early enough market that you should learn to co-exist.
  5. Accept what AWS has done is disruption to your traditional model – they are not competing on technology, they are competing on disrupting traditional enterprise software business model
  6. Responding to disruptive innovation is taking a harder look at your Resources Processes and Values (refer to Clay Christensen’s RPV theory).
  7. The market is ready to move beyond integrated offerings and may be getting hungry for open architectures when it comes to IAAS.

If you were to accept my observations, here is what I would recommend as a course of action ( using OpenStack as technology underpinning ).

  1. Create a separate BU with a GM to focus exclusively on public cloud that will be competitive with AWS and in the process will cannibalize your own private cloud offerings.  Give this BU very limited budget. Why should you have a separate BU? Refer to RPV theory again. Take it from me – I have failed in my career to do it within existing structure and most recently a half-ass BU structure.

One note on cannibalizing: Don’t worry about upsetting existing holy cows in your organization – they will be disrupted – only question is whether it’s your own BU or competitors – if your BU does it, these holy cows have a chance of retaining their jobs and retire with dignity.

This BU shall:

  1. Go with a pricing structure that is on-par with AWS and GCE. Sell this offering independently; create a separate, small and dedicated sales team. They should be commissioned on selling this offering only, nothing else.  (A major chunk should come from on line sales though).
  2. Make interoperability possible from your public cloud to AWS, GCE and Azure. Highlight that your offering is open, while rest are closed. See #7 above.
  3. Create the best interoperability possible with OpenStack deployments in a data center environment, but encourage those customers to get on a plan to move to the public cloud.
  4. Refuse to accept constraints such as artificial certifications, release processes that old timers at your mother ship may want to impose on you.

I do not believe you are at a disadvantage because you are starting late – this may be right time to offer a modular open option for customers growing weary of integrated IAAS offerings.

The One Problem

We have lot of smart people in the software industry.  We have great ideas and we innovate at a rate faster than many others. We know how to solve a complex problem and if only our prospective customers can see the brilliance of what we are offering, they can save so much money, effort and compete effectively.


And this is the problem afflicting many in our industry. We don’t know jack about what problems our target customers are trying to solve. We have untested theories and we build products based on these theories. We don’t talk about these products till they are ready to be launched because we are afraid our competitors will steal our stellar ideas.

We think what we are doing is special and cutting edge that prospects will not appreciate rough mockups and we should show them fully baked products. We have theories on how incompetent the IT guys are at our target market. We think our main problem is that these guys are not smart, so we should try to sell to their bosses. We have this idea of a CIO sitting idly at his desk waiting for us to pitch our brilliant ideas and he would join us in the cheerful dance at the end of the pitch. We think the sales people we hired do not get this simple fact and are stuck in selling to middle management and that’s why this wonderful product is not selling as much as expected it would.

When going gets tough, we raise yet another round of funding, so we can invest more into engineering, hire some famous engineers, infuse design thinking, hire heavy hitting sales people, get the buzz going, sign few more partners and throw parties at industry events.

So much waste, so much wasted energy, so many hopes being dashed. Could all this be avoided? Yes, there is one stupidly simple trick to avoiding this waste. Without much ado, I present to you a proven solution in few steps:

1. Talk to your target market customers

2. Show them rough mockups and ask what they think about them

3. Ask them if this problem is worth solving for them

4. Ask them what its worth to them

5. Ask if they would be willing to spend time testing your product when you have an alpha

6. Hang out with them, become friends with them, ask them for advice

And most importantly,

7. STFU and listen – listen, listen, listen – if you speak more than 30% in a conversation, you are boring the other person.  If you forget everything I said and just remember to STFU and listen, you have a fair shot at building a product that market wants.

None of this is new guys, but as the saying goes, common sense is not so common. This post would have met its goal if I can inspire at least one product manager to pick up the phone and call a customer next week.

PAAS Revisited…

Probably my last post on PAAS, as I think it’s time to move on talking about PAAS – there are more interesting cloud happenings that are exciting. But, to bring closure to a twitter discussion, I wanted to get this post done.

I have written previously about Platform as a Service. Had hoped that things have changed, but there are no signs that they have.  Also have done a quick and dirty survey and discovered PAAS is not exactly thriving, but is not dead either.  PAAS vendors for most part have not done a good job of articulating the value prop – ignoring that many of us don’t even understand what value these vendors bring to the table, I will outline few of the points that make me uncomfortable about PAAS.

1. Lack of industry accepted definition of what PAAS is.

Each vendor defines what PAAS is differently. If you peel back the original messaging, the root messaging seems to be “Trust us. We know what we are doing. Lock yourselves to our platform and you will do well”.  This is what I call a Papal message. In fact, some of the PAAS evangelists are somewhat similar to religious evangelists in their passion and in asking followers to suspend their disbelief. I see tweets like “The blind man in Chicago was cured of blindness by Brother X” – ok, may be not that, but something like my prospect was so impressed he jumped out the window thinking PAAS lets him fly.


If we look past the antics of vendor posturing, it does reveal a structural weakness in the market. There is no interest or motivation to sit at a table and discuss what a PAAS is and if it would make sense to have a reference implementation. As much as we all hate J2EE, we have to admit that they guys at least tried to do a reference implementation and several had published J2EE patterns that served as guidance for developers. This does not exist for PAAS.


Some would argue that .NET did not follow a reference implementation – well that strategy works if you have a segment of the market that believes in your ecosystem – this would indeed work well for Microsoft and Salesforce and not for others.


You could argue that a foundation or a task force was formed. I think we as an industry have seen enough attempts at a committee or a foundation or a task force. These are where vendors get together, drink expensive wines and sign on a dotted line – nothing good ever comes out of these. If this was driven by an end customer, I would have some hope. When we were young, we used to call it “smoke and mirrors” show.  Boy, for all failings of Sun Microsystems, I wish we had someone like that now.


2. Vendor Lock-in


Firstly, here is a fact you need to memorize.


Open Source <> Blank check


Just because your project is open source does not impress me. You have to prove value. There are more open source projects than developers out there and one could argue that not all open source projects are same.


I know this has nothing to do with my main argument, but I wanted to get it off my chest :).


Now, coming to vendor lock-in – a good PAAS is the one that does not dictate your choice of IAAS. It should work well on AWS, Azure, GCE and other IAAS options out there. Most of the PAAS vendors do have some level of support for other IAAS options, but there is an uncomfortable realization that their mother ship prefers using a particular infrastructure.


One thing most PAAS vendors are similar is in their universal hatred of AWS. I am not holding my breath that they will treat AWS as a first class infrastructure option. Time will tell, but just a vanilla support is not enough of an assurance that they will continue to put resources into AWS interop.


Also, early indications are that to get full value of PAAS, you should probably consume all the services that PAAS provides and this may mean ripping out what you have and replacing them with new services provided by the PAAS vendor.


One thing I would say is that smaller PAAS vendors actually have an advantage here as they are not tied to a larger mother ship with different agendas. They may actually build a platform that helps their customers.


3. Maturity of PAAS


It is my opinion that PAAS is for bleeding edge adopters and not for mainstream yet. I keep hearing that PAAS demos well, but may not deploy too well in production. There are definitely early adopters who have through sweat and tears managed to make it work, but for a mainstream app development shop that is racing to meet business needs, wise thing to do may be to hold off committing yourself to a particular platform. (Exceptions: If you are already a MS shop, you would be foolish not to use Azure – similarly, if you already use SFDC to build your apps, you should fully leverage SalesForce1).


These are some things that make me nervous about state of PAAS currently, but I do believe we could be at the beginning of a massive opportunity or it could just fizzle out. I am no longer in the camp of believing that PAAS will be subsumed by IAAS or PAAS does not have any value. PAAS has value, but we are probably in top of the first inning in a nine innings game. It’s time to go grab some peanuts and beer and enjoy conversation with friends. Think the SF Giants will get it done this year?


CIOs, Love your Shadow IT

It used to be that CIOs and IT used to hate and fear Shadow IT.  It wasn’t long time ago they rushed to HR to get employees fired for using unapproved tools. How fast times have changed, eh?.

Its about time that you change your views as well.
Consider the following:

1. Your IT staff may be outdated when it comes to new technology than your employees.
2. Whether you like it or not, your employees are social beings and expect to work outside the corporate network.
3. There are better solutions out there than what you had provisioned for your employees.
4. Your business side is thinking you suck at your job and is ineffective in delivering value.
You are fighting a losing battle. Instead of fighting Shadow IT, why not embrace it. Think of it this way:
1. Shadow IT is innovation
You are expanding your evaluation team to a larger pool of employees. Most innovations results because an employee outside of IT took initiative. For example, back in late 2000, employees used to use Yahoo messenger to IM each other – this was shadow IT and in someways killed your multi-million dollar Intranet projects. Company was better for it, even though your budgets took a hit.
2. Shadow IT is empowerment
Empowered employees are motivated employees. By allowing them to use the best technology available out there, you are empowering them to be productive. Case in point – employees start getting more collaborative by using something like Yammer. There is no need for IT to approve its usage. IT needs to get out of the equation here and stop being a bottleneck. Oh, you want employees to use Lotus Notes instead? Did we had this discussion about how you and your IT team are outdated?.
3. Shadow IT is productivity
Alright, lets get this out of the way. VPN is stupid, and honestly it should be taken to a backroom and shot in the head point blank.  Your employees should not use VPN to use any services you provide. “Requires VPN” is a sign of IT impotence. Get over it. Use Cloud services, and since you can’t get over the fear of fictitious security monsters in the cloud, let your employees sign up. If sales guys didn’t sign up for SFDC back in the early 2000s, you would still be implementing multi million dollar Siebel systems and would be seriously over budget.  In someways, those clueless sales guys that signed up for SFDC saved your bacon.
There are many more reasons to love Shadow IT – I just gave few points to give you gist of whats the reality there. Disagree? Comment below or tweet away. ( Oh, wait, you don’t allow tweeting because it can’t be on your corporate network ).