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.