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

My Move to Cloud Native

In late July, I decided to move back to VMware.  There were many reasons for this change, but one of them was the opportunity to work in a group within VMware called "Cloud Native Applications" or CNA.  While, I've been a "cloud" guy for years; I've mostly worked on IaaS.  I was on the public IaaS team at Oracle Public Cloud but I worked primarily on the Private Cloud space at VMware and NetApp.  Thus, CNA is adjacent to what I was doing but very different in practice.  Naturally, I have been asked many times to explain exactly what CNA is and what our mission in life is.  In order to do that, I had to define exactly what we mean when we say cloud native and I thought that this would be a good topic for a blog post.

The very short answer is that when we say Cloud Native Applications, we mean a class of applications that were born in the cloud and natively use the infrastructure services of cloud.  However, that answer doesn't really give you a good picture of how fundamentally different CNA is from the rest of VMware. 

As a Product Manager who owned features within vSphere, I can tell you that vSphere is a great business for VMware and probably will be for the foreseeable future.  It is one of those rare products that was so good, it created an industry.  Like Windows or Linux, there is an entire ecosystem around vSphere and it's component technologies.  As you can imagine, there is a great deal of pressure as a member of the vSphere team not to mess that up.  When you don't take your time and things slip, people notice.  Like front page Wall Street Journal notice.  Thus, there are all kinds of systems and processes in place within vSphere to make sure that mistakes are not made and to address any issues that do come up.  This is a good thing and I think that we're doing a pretty good job keeping that product stable while introducing new features at a measured, steady pace.

However, there are other markets that are moving much more quickly.  In those cases, the type of process driven organization that produces a product like vSphere cannot keep pace.  Thus, you cannot have one team working on a very mature product like vSphere and also going after a brand new, fast moving market.  Thus, the creation of the CNA team at VMware.  Our mission is to serve the cloud native market and to introduce new products, platforms and services for this market.

Naturally, because this market is so new, there is some debate about what this means and how to go after it.  Our first challenge as a team was to identify why this market was different and how customers in this market make decisions about what technologies to use.  It has become abundantly clear to us that unlike vSphere, CNA is fundamentally a developer driven organization.  The move to cloud is largely driven by developers seeking to solve their development, deployment and operations problems by getting away from traditional architectures and infrastructures.

Thus, the fundamental truth about cloud native is that it revolves around an architectural paradigm.  The notion that we need to change the way we design, build and operate is what lies at the heart of what we mean when we say cloud native.  This paradigm shift then drives technologies to meet the new requirements of these applications.  Note the cause-effect loop here.  Different REQUIREMENTS are driving different TECHNOLOGIES, not the other way round.  This important distinction is lost on some in the industry and will ultimately lead them into bad decisions and products.  Thus, things like Docker are very interesting because of problems they solve, not as technology per se. 

So, how do we define this new architectural paradigm?  One popular way is the "12 factor app" as defined at 12factor.net.  While this site is super detailed and provides everything you'd want to know about creating your own cloud native application, it may be TOO detailed for some.  There are a couple of things we can summarize out of this and generalize for our use.

Fundamentally, Cloud Native is about four requirements or assumptions for building applications:

1. Cloud Native implies that applications are built with the assumption that infrastructure is inherently unreliable.  All availability, data replication and other availability features are moved away from infrastructure and into the application.
2. Cloud Native assumes that the infrastructure is "Software Defined" and thus fungible.  The assumption is that I can re-configure my infrastructure simply via an API call and thus control the underlying platform from within the application.  
3. Cloud Native assumes that applications need to scale to internet scale.  That is to say, Cloud Native applications should inherently "scale out" instead of "scale up" because you eventually run out of "up".
4. Cloud Native assumes that technology velocity is more important than ROI.  Yes, cost is always a factor in the real world, but there are always trade-offs.  If your goal is to be the lowest cost provider, you are unlikely to be on the leading edge.  Thus, when you optimize for speed, you may incur additional cost and that's OK.

Here is the really interesting thing:    ALL my customers say they want cloud native, but MOST of them are not willing to accept the assumptions and requirements above.

Similar to what happened a few years ago when IaaS started to penetrate the enterprise, there is a huge amount of "buzz" around cloud native and all things cloud within enterprise today.  And just like I did five years ago, I am talking to customers about why this ISN'T a good idea for them.  At least right now.

I cannot tell you how many companies I have worked with around IaaS only to see them fail utterly.  This is not to say that their cloud didn't work.  The technology works just fine, thank you very much.  The problem is that they did not change the way IT worked.  Thus, the "impedance mismatch" between what IT saw as the proper way to do things and the way their internal customers wanted to consume cloud services as an impossible barrier to overcome.

The first question you must ask yourself as an IT leader is:  "what business am I in today and what business do I want to be in tomorrow?"  I think the last item on the list above is probably the killer for most companies.  If your company views IT as a cost center which needs to be controlled, you can never adopt the same methodologies and architectures from companies like Twitter and Google there technology is a profit center.  Never.

On the other hand, if those requirements match your requirements, there are some really interesting things that can be done with the technology stack that has been developed by those companies.  There are lessons to be learned about the way to scale out huge web farms and run large businesses on entrusted platforms.  When those lessons are applied, there are some architectural patterns that stand out:

1. Containerized workloads.  This is not the only way to build cloud native applications, but it is the dominant trend and we think it’s one of the better ways.
2. Stateless workloads.  Not to say that state is never persisted anywhere, what we mean is that any individual host or VM should not hold state that can’t be recovered easily.   To say it another way, I don’t “fix” the container or the VM, I kill it and start another.
3. Language and framework agnostic.  The rise of REST and things like Zookeeper and Etcd have made it possible to integrate components that were not developed together and have no common technology platform.  Thus, it becomes "run what you brung" and language becomes a developer choice.
4. Continuous Integration.  If speed is your #1 driver, then traditional dev/test/stage/prod cycles are not going to work for you.  Naturally, that means you need to have a programmable infrastructure, but we stated that in our requirements section.
5. REST.  The reality is that everyone is moving to REST.  Things like SOAP and RPC are not fast enough and are too "leaky" to maintain the level of abstraction and the scale required for cloud native.

Thus, we see that these technologies are interesting because they make it simpler to achieve our stated objectives and meet the requirements we've stated above.  This also means that while these are currently the way we are doing things, there is no guarantee that this will not change.  Thus, there is no point in creating a "Docker" product group within VMware.  We also urge our customers to focus on requirements and let technology decisions flow from there.  Yes, we love and support Docker here at VMware's CNA group, no we don't think this is the ONLY way to go about things.  Our focus here is to help our customer develop, build and deploy cloud native applications, regardless of technology or platform.