Why Private Cloud, Seriously?

Sometimes, I just can't keep my big mouth shut.

A while back I got called out on Twitter.



I was trying to make a point about the business case for cloud and Michael Ward over at Pearson correctly pointed out that I hadn't really made a case for Private Cloud.  It was a fair point.  I actually wrote this response way back then but didn't get around to publishing this until now.  Sorry about that!

So, here it goes.

Premise:  "Cloud" as a thing is as much about business model as it is about technology.  Thus, the difference between "Private Cloud" and "Public Cloud" is primarily the difference between in-sourcing and out-sourcing.

Discussion:  If you read this blog or have read my book, you will know that I am a big fan of the NIST definition of cloud.   Under this definition, there are a few mandatory elements like self service and rapid elasticity but no references to technology.  Thus, you can see that this is fundamentally a business model change that has been enabled by things like the internet and virtualization but that this is not fundamentally about any one technical implementation.

Why is this distinction important?  I believe that this distinction is vital because it implies that the only way you can truly judge one cloud platform vs. another is based on business criteria.  In some ways, the cloud signals the end of the highly technical infrastructure wars that we have been fighting for many years.  Like other utilities, the implementation details become irrelevant.  Don't believe me?  Go ask AWS for details of how EC2 works.  They won't tell you, even under NDA.  You don't need to know that. 

Since we spend most of our time discussing implementation  details, it means that we in the industry are spending most of our time focusing on things that our actual customers don't care about.



What started the whole "friendly twitter discussion" was a comment about how dumb it was to make your own cloud.  "If you ask you to take me from point A to B would you take out your phone for an Uber or would you start ordering vehicle parts?"

My response was "If you ask me 10,000 times an hour, I might look into building my own cars."

The point here is that there is definitely a volume issue that the analogy was missing.  This leads to my first point:

POINT ONE:  Private Clouds Make Sense at High Scale.

The reality is that when you use public cloud you are making a decision to outsource part of your operations to a 3rd party.  Sometimes, this is a brilliant idea.  In many cases, the public cloud vendor is operating with a huge scale and is able to buy equipment at a much lower price than you can buy it at.  Of course, they are also making a profit.  So, there is a balance between their profit and your operational scale.  At some point, these two curves cross and you can operate your own data center for less than they can sell their data center to you.

When do those curves cross?  It depends.  How much does it cost you to deliver a single VM in your private cloud?  If you don't know the answer to this question, you may want to seriously consider buying public cloud because it's an indication that your operations are not mature enough to really compete with public cloud on price.  If you are not actively managing the ROI for your data center, you probably aren't operating at the high efficiency that public clouds operate at.


POINT TWO:  Private Clouds are Good for Your PETS.

I am sure we have all heard the pets vs. cattle argument.  I won't repeat it here.  Suffice it to say that if you have workloads that you really care about and that can never go down, Private Cloud has some attraction for you.

Yes, you can argue that having pets in your data center is a bad idea.  You may even be right.  That's not the point.  The point is that every major enterprise IT shop I have ever talked to has at least one app that's more like a pet than like cattle.  If you run an IT shop, you know what I'm talking about.

Should you re-platform that application so that it's more like cattle?  I don't know.  It depends.  Who wrote that app?  Is that person still alive?  Did you buy it from a 3rd party?  Do you even have the code?  Lord only knows.  Perhaps it's simply cheaper to keep that app running than try to mess with it.

As your infrastructure vendor, I don't get to make that choice.  I will urge you to take a look and figure out what apps can be or should be re-platformed.  But I don't get to force you to do it.


POINT THREE:  Regulatory and other issues drive this.

There are many, many organizations that have significant governmental regulatory pressures that drive IT decisions.  This may be something simple like PCI or something heinously complex like FedRAMP but there are tons of issues here that drive placement decisions.

If you have spent the last 20 years getting your core infrastructure to be compliant to some unwieldy regulatory structure, you aren't going to walk away from that quickly (or ever).

Because a Private Cloud is precisely tailored to your exact operating environment, it will always be more precisely tailored to your exact requirements.  Again, an argument can be made that this customization is bad but that is also not a decision that we vendors get to make.  Only customers get to make the trade-off between customization and cost.


POINT FOUR:  The car analogy is broken.  

What really started this whole thing off was the idea that Uber is way better than building your own car.

That analogy is broken.

Nobody builds their own private cloud from scratch any more.  If you buy vRealise Automation from VMware or an OpenStack distro from Mirantis you are actually buying most of a car.  You're not buying a bunch of parts and assembling it from scratch.

So, the question is really:  Do I buy a car or do I rent one by the hour from Uber?

Answer:  It depends.

I take Uber all the time.  When I'm away from home, it makes way more sense to take an Uber than it does to buy a new car in that city only to sell it again the next day.

On the other hand, I also own a car.  I like having my own car.  I enjoy customizing it.  It's cheaper to operate than taking an Uber everywhere.

For Private Cloud, I argue it's the same thing.  I operate a private cloud when that makes sense.  I also use Public Cloud when that makes sense.  This is not an either or choice.

If you look at what's happening in enterprise IT closely, you will find that less than 10% of all enterprise IT organizations have more than 50% of their IT on public cloud today.  While we should fully expect this to rise significantly, we should not expect that private infrastructure will go away.  Over time, each will find their niche.  Just like Uber has found a niche that buying a car cannot fill.

Summary:  Horses for courses

When you watch large IT organizations make a decision and then you say "that's wrong" you should step back and consider.  It's easy to say something from a technical perspective or an architectural perspective because things like technical features don't change much from organization to organization.  However, business requirements can be radically different from place to place.  Unless you really understand the business requirements driving an IT decision, you should be slow to judge.

In the end, cloud is a business model.  Thus, any cloud adoption is a business decision, not a technical one.

So, Michael (if you read this far), did I convince you that Private Cloud is a thing?

Why we fail. Again. Sigh..

Sometimes being correct is an awesome thing.

That is not the case here.

A few years back, I wrote a book about enterprise private cloud called "Why we Fail."  The title was intentionally stark to try to gain attention to the book and the subject.  In that book, I made the argument that IT organizations that tried to use traditional business practices and governance were doomed to failure when deploying private cloud.

Sadly, this has turned out to be all too true.

As Thomas Bittman correctly points out, most of the issues facing enterprise public cloud are simply people and process issues.   Not technology issues.

While Gartner proposes a model they refer to as "Bi-Modal IT" to solve this problem, I would propose an alternate approach.  The key issue I have with Gartner is that they propose that Cloud is so new and fundamental to IT that you simply have to reboot and create a new greeenfield organization that is totally different than the old world.  I don't think that's true.

The issue isn't cloud.

The issue is broken IT organizations.  They're broken and thus they can't do what they need to do.  Pretending that "legacy" applications are working fine and can be simply hidden in the "Type 1" silo is just hiding your head in the sand.

The reality is that most IT organizations suffer from a severe lack of strategic vision.

As regular readers know, I am a huge fan of the Cranfield School of Business models for IT business management.  These models are not new.  In fact, they pre-date cloud by a couple of years at least.  However, if you look at them closely, you will see that they are very applicable to the conundrum that businesses find themselves in today.

One of the key messages in the Cranfield model is that technology products are like a stock portfolio.  Thus, the best way to reduce your risk is to diversify.  In addition, the way you manage different types of investments should also be different.  Just as you would not day trade on your house, you probably want to have different IT governance policies around your payroll system than you do for your CI/CD integration with Slack.

If you look closely at the reasons why shadow IT happens, you will usually find disconnects between business goals and IT governance policy.  Say for example that you are a developer working for a bank.  Normally, things like banking information need to be very strictly controlled.  For this reason, most banks have very formal IT governance policies.  As a developer of a new system that allows the marketing department to interact with customers via Twitter, you don't really have to worry about those things.  So, you ask for a VM or a full sandbox that has full Internet access.  Do you get it?  That depends on the governance policy.  If you don't get it, what happens next?  My guess is that you open up some EC2 instances on AWS and expense them.  You've got to get your job done, right?

This seemingly trivial example happens every day in enterprise IT organizations.  Some handle this very well.  Some poorly.  

Why Enterprise Architecture Will Vanish From This Earth

Although your world wonders me,
With your majestic and superior cackling hen
Your people I do not understand,
So to you I shall put an end
And you'll
Never hear
Surf music again

"Third Stone From the Sun"  -- Jimi Hendrix

Here is a bold prediction:  Enterprise Architecture as we know it will cease to exist by 2020.

Why do I think this?

It’s because enterprise IT (which includes architecture) has failed utterly and is rapidly becoming obsolete.  It will either morph into a form that is almost indistinguishable from today’s IT or it will also cease to exist. 

Allow me to explain.

Enterprise IT as a function came into existence when computers were expensive and rare.  We were entrusted with safeguarding the company’s data and managing the company’s extremely expensive investments in IT.  My first job out of college was working in an IT R&D group.  Our primary responsibility was testing new hardware and software to see if it worked as advertised and then selecting corporate standards.  We literally published a catalog of things you were allowed to buy.  These days, the idea of BYO has led to more and more personal technology in corporate America and the cloud has led to "shadow IT."  All of these trends reduce the importance and the authority that corporate IT once had.

I wrote about this in my first book , and the trends and failures that I predicted there are sadly coming true.  Traditional IT organizations are facing more and more pressure to change or to simply get out of the way.  In that book, I suggested an alternate model of IT that I called the “Customer Centric IT” model.  To summarize, it looks like this:

Traditional IT	Customer Centric IT
Sets IT Standards	Supports Business Requirements
Focus on Operations Excellence	Focus on Customer Satisfaction
Engineering is key skillset	Consulting is key skillset
Sets Policy	Seeks Input
Focus on Large Projects	Focus on Smaller Projects
Organized by Technology	Organized by Customer
Technology Focus	Business Value Focus
Delivers most projects in house	Brokers external vendors as needed

Similarly, if we think about the traditional Enterprise Architecture team, they are very focused on traditional IT values like “setting standards” and “setting policy.”  If there is one thing we have learned about cloud and the new way of building applications it’s that the development team is the one team in your organization that is qualified to make decisions about the tools they use and the architectural elements they need to succeed.  This fundamental democratization of developer tools has started a revolution in IT that is only gaining ground.

Thus, the entire concept of what the architect’s role is has changed and is continuing to change.

Software Eats the World

As Mary Meeker points out in her excellent state of the internet report last year, there are major sectors of the US economy which are being or are about to be disrupted by software.  Specifically, the top three areas of consumer spending, Housing, Transportation and Food (65% of US consumer spending in total) are all facing disruption due to software based competitors.  The implication is that the pace of innovation and the business model of software is coming to many more industries than in the past.  Realistically, this means that most companies are going to need to treat software as a key piece of their value proposition in order to survive in the modern digital world.

While this trend is not new, it is continuing to accelerate as internet adoption rates in the United States approach those of radio and TV.  Smartphones, the cloud and other technologies have made software more ubiquitous than ever and more industries are starting to react to this new threat.

As the interface between business and technology, this is a huge area of concern for architects.  If you don’t have a plan for dealing with software disruption to your business, you’re probably not doing your job as an enterprise architect.  Traditional, legacy, IT policies are designed to promote cost effective, stable platforms that protect an enterprise business from technology’s foibles.  However, this policy no longer works.  If your goal is to compete with a software company, you need to operate at the speed of a software company.  Once technology becomes a revenue source, things like velocity and agility become the most important considerations; more important than ROI or stability.

When you optimize for velocity, things like standards, cost controls and other traditional IT functions cease to exist.  Individual teams can make decisions faster than enterprise wide architecture review boards.  Interoperability and standardization are only important when it comes to cross feature dependencies.  Inside the individual system, getting your features out is the most important thing.  This lessens the role of the central architecture group. 

While some claim this makes enterprise architecture irrelevant, I disagree.  What it does is shine a bright light on what the hell enterprise architecture is supposed to be for.  In reality, the enterprise architecture team has a very limited role.  Our role is to ensure that the minimum viable governance models are in place to ensure that vital regulatory, security and other policies are enforced.  In the end, the tools your developers use isn’t really important.  But if you fail your SOX audit, there will be hell to pay.  The exact amount of governance you need will vary by industry but you should always be focused on how to achieve the absolute minimum.

Thus, the question for enterprise architects is this:  How do you reduce your role to the absolute minimum?

This may seem counter-intuitive but scaling back your role to the bare minimum may be the only way to save enterprise architecture as a function in your organization.