CNA in the Enterprise?

Following up from my post about joining the Cloud Native team at VMware, I'd like to transition to the challenge that we've decided to take on:  Moving Cloud Native into the Enterprise.

Like IaaS and other cloud technologies, the idea of enterprises running cloud native applications is all the rage right now.  Every CIO and every IT architect I talk to has some plan or research project going on around Docker, Kubernetes, Mesos or some other aspect of the cloud native stack.  This is awesome for a product manager like me because it means everyone is interested in what I'm working on.  It's very easy to draw a crowd by showing off vSphere Integrated Containers or one of the other cloud native projects we're working on.

Unfortunately, the current state of the market is not very mature.  In fact, it very much reminds me of the awesome Dan Ariely quote about big data: 

"Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it..."

You could basically insert "Docker" or "Cloud Native" in the quote above for Big Data and you wouldn't be far wrong.  Similar to big data, there are some folks out there doing amazing work.  However, for most mere mortals, this is a completely theoretical discussion at this time.  Pretty much like every locker room conversation you had in middle school.

The reality is that making Cloud Native work in the enterprise is going to be VERY VERY hard.  There are some very significant barriers to entry here:

1. There are millions of lines of code running key business functions that will need to be completely replaced.  You cannot simply port existing code to cloud native, you need to re-write the application and re-architect it to get the benefits.
2. Your existing development process will have to be abandoned.  The traditional dev/test/stage/prod cycle you are using now will not cut the mustard.  One of the key values you get from Cloud Native is speed and agility.  That won't happen without changing out your processes.
3. Cloud native assumes a robust PaaS layer.  If you look closely, there is a massive "hand wave" in most architectures when it comes to persistence.  Nobody runs databases in containers.  This is because platforms like AWS already have a great PaaS layer.  Why build your own object store when you have S3?  Do you have a full PaaS stack inside your firewall?
4. Your current security and it governance policies will have to be re-written.  It is extremely unlikely that your current policy and governance structure was designed for the type of rapid iteration and agility implied by cloud native.  Do you have an Architectural Review Board?  Forget about that.  Centralized governance model?  Nope.
5. Deploying within your firewall assumes you already have a robust PaaS and IaaS platform.  Do you?  Our research shows fewer than 10% of enterprise IT shops have a fully deployed IaaS platform.
6. Deploying outside your firewall (AWS, GCE, Azure, etc.) assumes that you have policies and procedures for managing things like data protection, security, etc. in a public cloud context.  Do you?

Given the issues above, is it even practical to deploy or build cloud native applications in my enterprise?  Most definitely yes.  The reality is that cloud native solves so many problems with traditional application development that it's worth all the hassle of changing out your existing infrastructure, processes and policies.  However, you should begin this journey with open eyes.  Like every other technical project you've ever done, this one will have issues, complications and unforeseen consequences.

Assuming that you're not going to re-write your existing line of business apps for fun, my assumption is that your first cloud native application will be a net new application.  It's going to be much easier if you apply this toolkit to a new development effort than if you attempt to retrofit an existing application.  Therefore, you have the opportunity to create a new team with a new set of dev tools and processes.  Thus, you are really talking about of a net new team writing a new application.  Setting aside the policy and procedure issues from above (not because they're trivial, but because I can't generalize them) your biggest problem comes down to PaaS.

It turns out that running cloud native assumes you already have a cloud and all of the fun things that this implies.  If you already have a robust IaaS and PaaS environment running, you're good to go.

Unfortunately, we know that for most customers this is simply not true.  We know that you don't have this infrastructure running because we've spend the last year talking to literally hundreds of enterprise customers about this very topic.

The next thing that usually happens is that engineering teams go off and get an account on AWS, GCE, Azure or another cloud provider service.  This is awesome because it allows them to begin writing code almost immediately.  All the services that we've already talked about exist up there and they work great.  They code away like mad and everyone is happy.  Right?

Well, not really.  If you are a software company and product velocity is the only thing that matters, this may be a very acceptable state of affairs.  However, if other things matter to you like data sovereignty, multi-sourcing, ROI, etc. then you might not be OK with being locked into a single hoster.  This means that you don't want to consume PaaS services that are limited to a single cloud.

Thus, we get back to creating your own PaaS layer.

I believe that this will be the single greatest stumbling block for enterprises who seek to adopt cloud native.

This is one reason why our team is working on tools and services to make this simpler.  We need a way to deploy "just enough PaaS" quickly and easily inside the firewall and outside the firewall.  We need a consistent services layer that will run on any cloud.  We need a single management interface for all of those instances running across any cloud.

Hmmm.

Sounds like a good idea for a product, right?

Stay tuned.......