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.

Wrong.

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 ).

This I believe

Random thoughts on the business of software development.

If you disagree or have something to add,  comment below.

Executives

1. If you cannot stop interrupting developers for every customer request, you must get out of product development business.
2. Product Manager owns the product decisions, if this is not true in your company, fire them and hire a project manager.
3. Executive team is not representation of end users – you must resist the urge to think you are smarter than your users.
4. Process or methodology is less important than your team. If your team members need to drop kids at school in the morning, its ok to have your scrum call in the afternoon.  Just because some “expert” says stand-up meeting every morning does not mean you make it a hard rule.

Prod Mgmt & UX

5. Assume you are an idiot when it comes to design – do extensive user testing. Observe users and do not lead them into your way of thinking.
6. Every metric is a vanity metric, unless proven otherwise – A vanity metric is useless by definition.
7. Getting exact product pricing  for enterprise products is not as critical as you think.  Get the pricing model right, that is the harder part.
8. Role of product manager is not about keeping all stakeholders happy – often, your stakeholders are the worst enemy your product has.  Manage stakeholders, but focus on end users and economic buyers. Don’t be a suck-up yes man.

Engineering

9. Engineer’s job is not just writing code – you are also paid to think – ask  how a product feature will be used and why
10.  Today’s resume building skill will be a worthless  in few months – what is  important is you write your best code each day. If writing great code does not inspire you, move into marketing, you can be a rockstar there.

PAAS is not dead, but its not thriving yet

We at c-cloud social media department conducted a 3 question survey on the state of PAAS. Below are the results and my short summary.

Total Responses: 57 ( exclusively via twitter )

1. Do you currently use PAAS?

Image

2. Is PAAS Dead?

Image

So, a simple majority thought PAAS is not dead. Even if we account for vendor responses, we can say there is no overwhelming sentiment that PAAS is dead. It is an argument of the “experts” more than anything else at this time.

3. What is your opinion about future of PAAS?

Here responses were interesting.

First the sample PAAS positive responses:

It is the future of software development as one can run on premises or cloud – private, public, or hybrid.

the only way most enterprises will consume cloud this decade

SaaS for Developers

It has one

Good

Useful if it means I have a common platform that my devs can write to while ops decides where the app actually runs – my infrastructure or AWS.

Its better than SaaS

Promising

Force (salesforce 1) alone already has a lot of apps created and used by companies. Hard to see it dying

High

Bright

Early but promising

Not sure why the haters are trying to derail it. There is a future

Here are the  sample PAAS negative responses:

About 5 years off from major adoption.

who needs paas when you can have saas

Effective IT Self Service that connects to CM tools largely replicates the PaaS capabilities, but without adding any additional complexity

consolidation with IaaS which then leads to reusable policy based docker like building blocks

Dead

Too inflexible for diverse worlds

Unlikely to be a meaningful distinction going forward

it is dead

Kill it

Its FUKING DED

No future.

Squashed between SaaS and IaaS.

No one will use the term—it will be standard offering(s) from IaaS providers.

predict huge adoption among corporations full of idiots

In Summary

PAAS still has a decent shot of becoming relevant, but enough doubt exists among people. This is not unique and most (eventually) successful technologies do undergo a period of doubt and I suspect PAAS is in that phase now. Vendors can move it forward by better documenting the early wins and publicly sharing customer stories as called out by this blogger.

We hope you find this survey from c-cloud social media department helpful.  Write your opinions below.

F the platform

Say “Platform” again! Say! “Platform”! again! I dare you! I double-dare you, mofo! Say “platform” one more goddamn time!

“A platform must have APIs first and foremost”

“A platform must be open”

“A platform must be delivered as a service”

“A platform is not a platform unless it has a beautiful login page”

“A platform should be integrated well with a developers IDE”

“A platform is what builds companies – product companies rarely thrive”

“Platform is the computer”

“A Platform is the glue between unknown and the known”

“A Platform must be portable and must include support for containers”

“A platform starts with community “

“A platform must support BigData”

“A platform is the building block of IoT”

“A platform must follow mobile first methodology”

“Platform is the way to build a cloud company”

Ah, F it guys. Seriously.

You are confusing the matters. There is no such thing as “the” platform that’s going to deliver nirvana for the companies that pursue them.  The world does not need one platform from every software company in the world. In your misguided greed to dominate the world through your “platform” you are building shitty products that do not even solve the basic problems that you customers buy your products for. I  see a future where your company ceases to exist if you go down this route.

So, my one piece of advice: Platform is not for majority of you, unless you already have many happy customers and developers coding against your APIs, don’t be fricking kidding yourself  that you are building a platform.

Do one thing well, do it really well first, then think about evolution of your product into a platform. If an expert says you must first think about platform, follow them after work to see what they drink at the bar – I bet they are drinking Coors Light and thinking its effing great  – do you want to listen to people like that? Seriously?

Enterprise IT has issues – acknowledge them

As you guys know, I am a big proponent of Cloud, Devops and all that good stuff. I would not look  kindly upon a vendor who tries FUD on any of those.  I am also not a big fan of Private Cloud, as it takes us backwards in technology adoption. I am not yet sold on PAAS because none of the vendors have demonstrated a clear value proposition so far. 

Having said that, I had realized over last few months that enterprises have problems and we need to acknowledge them. It is the task of vendors, pundits, gurus and shamans to work with enterprises to get them to the next stage of computing. A good understanding of the problems enterprise IT guys face is a good start. I will attempt to articulate few of those here, and look for your help in expanding them.

1. Strategic role of Enterprise IT – even today, in several large mainstream organizations, IT is a cost center and is seen as delivering a service that supports main mission of the enterprise, nothing more. Only a portion of the organizations have realized that IT is a competitive advantage. Do not make the assumption that each of the enterprise you speak to treats IT as a strategic investment. One test you can use is to see if CIO sits in the core exec team of that company. If CIO works for the CFO or someone else, you know that IT is not seen as a strategic area of the company. 

2. Company culture trumps IT culture – In many organizations, age old ways of doing business and treating employees as mere resources is still a norm. IT has to fit into this culture unfortunately – not many CIOs are empowered or capable of driving change to the culture of the larger organization they belong to. If the company has a culture of not tolerating any mistakes, then IT will be afraid of taking chances on new methods of doing things. One test you can do is ask the IT manager about what happens if the systems are down for few hours. You can learn a lot by that question about that companies culture. 

3. There is a reason some of the IT folks work in large companies – these reasons range from job security to having a predictable 8-5 job and location constraints. These folks are often risk averse. In my career, I had met many such folks. They thrive on a predictable, organized command and control structure. Any new way of doing things threaten these guys and will resist it vigorously. One test you can do is ask how long they have been with the company and how is their attrition rate – low attrition is likely higher “cling to job” mindset. Also, location of the company is a good indicator. 

Now, we can argue that companies that have these problems will not survive, but lets leave that to the management consultants to argue. 

So, if you are a software vendor that wants to sell to these IT guys, what can you do?

1. Do not attack their way of doing things as old, outdated  ( leave that to twitter  )
2. Find early victories you can give to these guys – for ex: instead of embracing Cloud all at once, how about encourage them to start with Cloud storage for files or use EC2 for only Dev/Test activities as stage 1?.
3. Do not say their previous investments are boneheaded. Especially if a CIO has spent few millions on a large enterprise software within last 2-3 years, don’t be going around arguing they made a huge mistake. They will defend their decisions. Do not fight it. Figure out how you can compliment what they have and show them a non disruptive transition plan.

However, do not do the following because you are not helping your customers or industry. 

1. Sell them a better on-prem software branded as private cloud – you really aren’t helping them.
2. Sell them training classes on new technologies or new methodologies that make the IT guys feel good for a day, but  can’t use them yet.
3. Tell them Cloud is insecure or will cause them problems meeting compliance – at best its inaccurate, worse, you are lying 

Thats all folks – back to tweeting. 

Cloudastramus 2014 Predictions

Much awaited predictions by highly-respected Cloudstramus for 2014. These have been arrived by analyzing the current position of stars, reading lot of press releases, tweets, blogs and listening to bullshit artists.

1. PAAS will get absorbed by IAAS vendors

PAAS is not shaping up to be an independent market segment and this will lead to non adoption, and increasingly PAAS vendors will look to IAAS as an anchor to get customer adoption.  At the same time, IAAS vendors need to show innovation and they will embrace PAAS to show that. We will see more M&A activity.

2. IAAS as an on-prem option will get a reality check and complexity and frustrations of this option will make IT avoid on-prem IAAS like plague.

Complex upgrades, lack of enterprise capabilities and lack of expertise around on-prem IAAS would result in many more failed projects and word will get around that on-prem IAAS is not a viable option.

3. OpenStack Foundation will get dissolved and a new self-organized group will form that will provide stronger leadership and vision.

Despite having well intentioned and good people in the Foundation, vendors like Oracle, IBM and others will try to derail any potential progress the Foundation can make. Out of frustration, some of the passionate OpenStack folks will come out and form a new group to rescue OpenStack from the clutches of these companies.

4. GCE will mount serious marketing and product challenge to AWS – AWS will start losing some market share.

Early success stories will start emerging in mid 2014 and Google will launch massive marketing and product challenge to AWS. Due to confusion around AWS enterprise pricing and some mis hits, AWS will start losing some market share to GCE.

5. Excitement around Containers will subside and world will start viewing them as another option, not the only option.

Container fanboys will get a reality check and realize that while it is a good option, it is not the only viable option. The unbelievable claims like the computer the size of Internet will start getting challenged more broadly. Containers are here to stay, but as an important component of overall Cloud infrastructure.

PAAS is a figment of (y)our imagination

I admit failure and thats a hard thing to do given my ego.

I started exploring PAAS and said, may be I can help explain this. After some effort, I give up. I question the existence of PAAS as a product category. It just does not exist – it is a figment of (y)our imagination.

Everybody is confused about PAAS. The vendors seem to fight a lot as well. Initially I thought it was due to their competitive nature. I am starting to think its because even they are confused about what problem they are trying to solve and if their product is even relevant. I suspect the anger is a result of their fears. 

PAAS as a market segment is like putting cart before the horse. It is vendors trying to package bunch of stuff and call it a PAAS. Now, each of these offerings provide different value for customers that take time to understand them and find value in using them. It would be a mistake to lump them all together and call it a category for now. It would be a category as broad as ‘moving vehicles’ that may include bicycles, cars, earth moving equipment, trucks etc. 

Current “PAAS” products are amalgamation of developer tools and services that a vendor can get their hands on. It often include various language run-times, IDEs, monitoring and debugging tools, APIs etc. 

For a taste of difference between different PAAS solutions, I listed 3 of the ones that list services offered by them below ( in Alphabetical order ). 

Note: Would have loved to include OpenShift, but what services OpenShift provides is a mystery to me and their website is impossible to use, so going to ignore it for now. 

Apprenda

Service Broker
API based Transaction Metering
Distributed Cache
Federated Authentication with Enterprise Systems
Multi-tenant Queue
Service Catalog
End User On boarding / Provisioning
Entitlement Definitions
App Deployment Policies
Application Inventory
Application Lifecycle Management
Self Service Dev Portal
Self Service IT Portal
Centralized Logging/Auditing
Chargeback/Showback
System Center Integration
Infrastructure Tagging
Load Distribution and HA
Resource Policies
REST APis & CLI
Extensible Cloud Application Services
Custom Workflow Extensions
Multi-tenancy Enablement

CloudFoundry

Lifecycle API
Dynamic Routing
Buildpacks
Data and Webservice Brokers
Linux Container Management
Role based access
app health management
user authentication and authorization
Realtime logging API

Salesforce1

Workflow and approval engine
Point & click development
Multi-language development
Real-time data feeds
Chatter
Tools and APIs for professional developers
Mobile Services & SDK
Sharing and user access controls
Identity management
Reporting and dashboards
Salesforce Identity
Salesforce Private AppExchange

Tell me how much similarity do you find between these ?.  There are some common components, but it feels all over the map. 

So, what does this means. So, the questions you should be asking yourself are the following:

1. Do I need app services when building and deploying a cloud application?
2. Which services do I need for this application?
3. Which vendor provides these services – is it CloudFoundry, Salesforce1 or Apprenda or Microsoft Azure or someone else?

However, if you want to end in a zone of endless frustration, ask the following questions:

1. Do I need a PAAS ?
2. Which PAAS vendor is the best?
3. Which PAAS vendor has most traction?

ps: Do not throw the baby out with the bathwater – the lack of a clear market segment definition or similarities between these products, I do believe they serve a purpose and if you have a need for them, you should absolutely consider using them. They will deliver value from what I understand from early adopters. 

Hope you find this argument helpful. As always, agree / disagree with me here or on twitterz…