Wednesday, January 30, 2019

It's not them, it's you

This blog is re-posted with permission.  It originally appeared here:  https://cloud.vmware.com/community/2018/01/23/ask-alex-part-1/
It is part of a multi-part series on public cloud strategy for enterprises. 
In part one, he’ll answer the question: “My internal developers want to move to public cloud. What is it about public cloud that’s so great that they want to leave the on-premises environment?”
There is a joke going around the internet about cloud: “There is no cloud, just someone else’s ops team.”
It’s funny because it’s true. While the current rise of cloud has everyone agog about the possibilities and amaze-balls stuff that the cloud can do, the reality is that there is no magic there. Everything that folks like us or Amazon are doing are things you could in theory, do on-premises.
However, in practice cloud is totally different. Why is that?
  • Cloud is about scale. There are some things that are difficult or impossible to do unless you have massive scale.
  • Cloud is about on-demand. Because of #1 above, you can usually just show up and ask for things.
  • Cloud is about a customer-centric business model. This is less obvious and often forgotten. Cloud assumes a customer-centric business model.
On the other hand, most enterprise IT organizations have different priorities and missions. Normally, IT is tasked with things like ROI, security, stability, etc.. These goals are often in direct conflict with what a developer is trying to do.
In reality, developers are not really running towards cloud. What they’re seeking is getting the freedom to do their thing the way they want to do it.
To say it another way, it’s not them. It’s you.
Cloud flight may be a problem for your organization or it may be just fine. It really depends on what your overall cloud strategy is and how you plan to support those applications AFTER they get developed. The issue for IT is not massive movement to cloud. The absolutely terrifying thing is when YOU DON’T KNOW WHY you’re doing it.
As we discussed in our blog post about IT portfolio management, it is very common for applications to move from “High Potential” where cost is less of an object to “Key Operational” where cost is the #1 consideration over time. Thus, the long term impact of this trend is that you may be “stuck” with applications that were developed for a specific cloud platform that is no longer appropriate for the economics of that platform.
The reality is that there is no one answer that is correct for every organization and every application.
What you need to do is to think about your long term goals and then align your IT policies and procedures to optimize for those goals.
For example, if you have internal development teams that are working on applications that are core to your business, you will want to have a multi-year strategy about how you will manage those applications throughout their life-cycle. This strategy will then inform the platform and tooling decisions you make.
In the end, you cannot force tooling and platforms to your application development teams. Because of public cloud, they can simply take their business elsewhere.
This means that you need to be a true service provider to your internal customers and to focus on what they really need from you.
Like any business you will have to identify your target market and decide what business you are in. Not all customers are worth the cost of acquisition and you may choose not to service all internal customers all the time. That’s OK. One huge mistake that IT makes is to assume they are the only game in town and try to be all things to all people. That way leads to madness. You may not be able to serve everyone. Again, that’s OK.
The other aspect of this plan is to think about what your internal customers really NEED as opposed to what they say they WANT. The difference between expressed customer wants and actually (usually unexpressed) NEEDS is the difference between mediocre businesses and hugely successful ones. There is a great book about this subject by Mahan Khalsa called “Let’s Get Real or Let’s Not Play.” I highly recommend this book to any/all IT leadership seeking to transform their IT organizations into customer-centric service organizations.
To summarize, why are developers moving to public cloud and away from on-premises?
  1. You are not meeting their needs.
  2. They have business needs that you cannot meet.
  3. They have a real business need that means public cloud is the correct place for them to be.

If you are in case 2 or 3, you are probably fine. However, if you are in case 1, I would seriously look at this and figure out what is really going on.

Monday, March 27, 2017

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?