VMworld 2015: Cloud Native Apps - a complex (interesting), but fascinating story.

First things first - what the heck is a “Cloud Native App”, great a new buzzword… and we yet another buzzword (YAB ;-) like we need a punch in the face :-)

It is a real idea, but an idea that lacks a discrete authoritative definition, but you know it when you see it.

Let me throw out some of my thoughts on this through my travels, customers dialogs, and insights from other customers.

Hang on to your hats if you don’t Iive in this world (common for the “traditional VMware admin” - frankly for most people).  

Whenever an idea hits the “zeitgeist” (like “Cloud Native Apps” have), you find a TON of info that is high level.  You find a lot of pithy (technically silly) analyst/press comments.   For example, the “VMware vs. Containers” thing for example is a case where people want eyeballs, but are unwilling (unable?) to really understand.

If you want to understand - you need to be curious.   If you are curious - read on!

So… WTH is a Cloud Native App (Cloud Native App)?

Recently, Subbu Allamaraju from Ebay did a great post sharing the last 3 years of his experience here.

Here’s a key quote that I think captures a couple central ideas that are “Cloud Native App” thinking.

"I would describe a cloud native abstraction as one with two fundamental characteristics:

Durable: The abstraction may be built using ephemeral parts, but the abstraction itself is durable in the sense that it survives failure of its parts.

Declarative: The user of the abstraction declares the desired state, and the service providing that abstraction attempts to maintain the abstraction in that desired state."

 For people with a developer’s or comp-sci background that want a more technical definition (personally, I think this is very authoritative), The Twelve Factor App  is a nearly perfect characterization that defines a real Cloud Native App.

Notice that those definitions say nothing about the “HOW” of the infrastructure layer should work - only that the app has no infrastructure dependencies.   What is an infrastructure dependency?   A simplistic way to say it would be “anything that the app cares about”.  Does the app get unhappy if the IOps drop by 50%?   Does the app freak out if a VM blows up?  Do you think about backup?   These are all examples of infrastructure dependency.    

And remember - I’m not talking about “hardware” here.  I’m talking about the way that the infrastructure (in totality) manifests itself: ultimately, the top IaaS layer.

Let me give you a real example.  

To highlight the launch of the vCloud Air object store - the EMC team (thanks Matt and others!) built an app that is a real world example.  It’s pretty simple, and illustrative.  It pulls twitter pictures that match a hashtag (#VMworld), filters for NSFW content (warning, this isn’t perfect), and stores the pictures in the vCloud Air object store (which uses the EMC SDS Elastic Cloud Storage object stack).   The app architecture follows the “12 factor app” rules - and this is is a real Cloud Native App example.

First, go and check out the app here.

Next, if you want to understand how this works - it’s running in vCloud Air, where there is a Pivotal Cloud Foundry instance which makes the app scale with a single command (“cf scale”), and we’ve gone through multiple updates with zero downtime not because of things like “VM HA” or “highly resilient infrastructure” (in any form), but because of the durable and declarative way the app is constructed.  Each micro service is ephemeral, and we are using a cloud-scale geo-distributed object store (the new vCloud Air Object storage model which is powered by ECS) for underlying persistence.

You can see the app architecture in the logical diagram below:

There is a funny story behind the app name “Vasco da Gama” - from Matt Cowger (@mcowger): “The very first version I wrote had no name and was a hack. Then Kenny and Jonas took it, improved the interface and dockerized it and deployed it over a ton of world wide AWS instances and called it "Marco polo”.   I then rewrote it into the uServices architecture and called is Vasco da Gama.”   The people here are a great group of folks, all EMC SEs currently or in the past, and now part of the EMC {code} team.

So - what does this app want from infrastructure?   What does any Cloud Native App want from infrastructure?   What matters for “Cloud Native App” IaaS is a couple things:

• programmability (“infrastructure as code”)
• elasticity (which demands a very scale-out architectural model)
• economics (which steers towards commodity hardware + software architectures)
• powered by open-source software stacks - to a smaller degree for economic reasons, but to a LARGE degree for the rapid rate of innovation and collaboration that only a community approach can bring
• Bonus (but not required) is strong instrumentation and telemetry of the IaaS layer

BTW - if you do this, and do it well - customers will pay for it - it’s a new form of value.   Look at the business margin models of AWS and Azure (now that they are public) - those are very profitable.   People think this is a function of their scale.   I don’t think so.   Its a function of value.

 This is a tricky thing (strategically) for us as the Federation - because we’re REALLY good at the other kind of IaaS: very feature rich, very resilient at the VMware SDDC (SDC, SDN, SDS) layer and the hardware layer.   We have all kinds of data services to protect, recover, create active-active models, and DR with RPOs you can dial in however you want.  We have even industrialized it with the Federation Enterprise Hybrid Cloud model - that makes the whole solution turnkey.

Furthermore - exactly because these IaaS stacks support monolithic, fragile, NON resilient apps (usually sitting on a creaking Oracle RDBMS for the data fabric), they are wrapped with organizational models and processes that are built to reduce RISK at all cost - including agility.   If you can spell ITIL, you know what I mean.  Very valuable, very mature change control processes built over decades.

So - what’s a customer to do?   What’s VMware, EMC to do?

First - an important (REALLY important) observation: Brownfield and Greenfield models.

Cloud Native Apps (cattle in the “pets and cattle” - or “pets and chickens" for my Hindu friends :-) can absolutely be deployed on an existing “infrastructure resilient” IaaS stack and operational model..   Call that a “brownfield” deployment.   It will have exactly the elasticity and agility that the organization and process that supports it can deliver.   

There is then logically a “Cloud Native App” version of IaaS.    There, things like VM HA, DRS, Storage DRS, heck VMAX, XtremIO, Data Domain and the ilk have dramatically lowered value.   Why?   Because they suck?  No.   Because you value elastic, programmable IaaS - and don’t care particularly about infrastructure resilience.   You do resource management at some higher level in the stack (either PaaS does it for you, or a container/cluster scheduler like Cloud Foundry, Kubernetes or Mesos does)

Which of these is “right”?

BTW this idea was presented in the VMworld keynote on the topic this way:

Sigh.   Get ready for years of stupid debates - with people who are rabid fanatics one way or another.   This will be the next version of “NFS vs. VMFS”, or “AFA or HFA”, “Converged or Hyper-Converged" or “Public or Private Cloud”.   Hint: when you talk to someone that is fanatical - that can’t reflect, consider circumstance, or nuance, walk away.   Unless it’s Donald Trump, in which case, mess with his hair.

Clearly - a customer needs to evaluate their strategy, and EMC and VMware must support both models (on premises and off premises).   We must have the BEST IaaS stack for monolithic apps, and also Cloud Native App stacks.

Now - there are experiences and observations that I’ve been noting over the last year or so on the “Brownfield vs. Greenfield” topic.

Observations re Brownfield / Greenfield: 

• Most enterprises start with the brownfield.   There’s overwhelming weight of monolithic non Cloud Native apps that they just can’t mentally justify another stack and separate operational team.
• Many pivot to the Greenfield (again technology stack, and organizational/process)  over time.
• The reason for the pivot is not the technology delta (though there are technology differences that are material) - it’s the organizational and process considerations.   Simply put, the organizational models (very SLA oriented into silos with clear demarcation and handoff) and processes (very mature, very geared to focus on “risk = bad”) simply cannot be elastic enough, programmable enough.   This is the root of the Gartner “bi-modal IT” observation.

Second - how are these Cloud Native app stacks constructed?   Structured, and unstructured PaaS patterns both exist.   WTF am I talking about now?

 

Wikibon has what I think is a brilliant post on the topic here written by my respected and great friend, Brian Gracely.   He has a table that nails this the comparison of Structured PaaS and Unstructured PaaS (think “homebrewed PaaS”)

 

 

What are examples of each?   The clear leader in the structured PaaS market is Cloud Foundry.   Others exist of course - but there is a ton of rallying behind CF.  BTW - note that I’m not saying this because of the Pivotal connection.   The Cloud Foundry project is now governed by under the Linux Foundation, and no one “controls it” - contribution is the name of the game.

 

In the unstructured PaaS market (think “home brew”) there is no “one leader”, since there is no “one thing”.   As the table notes, there are many “will need to be built”.   The Container/Cluster manager/scheduler has a ton of players - with Kubernetes and Mesos being clear stand outs.   But this is a strange ecosystem - with Cloud Native App, and heck Docker itself having some things that can be considered container/cluster manager elements - in Cloud Native App land, trying to draw hard lines is a waste of time.

 

Furthermore - these are not in “opposition” - a structured PaaS can be thought of as a single instantiation when people have packaged up all the of the “will need to be built” and “integrate” points on the table above.   Ergo - that’s why Cloud Foundry can ride of top of Docker.

 

You can now immediately understand why everyone writing "docker vs. virtualization" or “PaaS vs. containers” articles is kinda putting out there that they don’t get it.

 

Like the earlier question - which of these is better - Structured or Unstructured?  Sigh.  Silly humans.  

Aside - this train of thought (wanting to rationalize options down to a singular choice) exists in so many brains because all humans struggle to maintain two opposing ideas in their brain at the same time - we naturally want to “harmonize” or “reconcile”.   Again - note the pattern - when someone says “this is the answer, all the time” - gather up sharp objects and back away slowly. 

That said, like the “Brownfield / Greenfield” point, I’ve made observations over the last year from hundreds of customer interactions of every flavor.

 

Observations re Structured / Unstructured PaaS:

• In general, Enterprises seem to get better results from Structured PaaS than unstructured.   This is the PaaS version of the “mix and match vs. converged/hyper-converged infrastructure” observation.  Stop building things that you should just buy.
• In general, SaaS startups and Hyper-Scale players seem to get better results from unstructured PaaS - because they get specific benefits out of their own, very specific selections around all the “integrate” and “need to be built” topics in the table above.

Now - what does this have to do with the VMware Photon Platform announcement - and what’s the Federation level strategy?

 

It’s simple at it’s core - and I’ll put it out there really transparently...

 

There are core Federation strategic principles on Cloud Native App: 

• Brownfield and greenfield models exist and are both important
• We must be open at every level, but also deliver an integrated stack with a “First and Best” model.
• Structured (PaaS) Cloud Native App patterns are best for enterprises, but we recognize that an important unstructured Cloud Native App marketplace exists 

If these are “axioms” (things that are true), they then have direct “corollaries” that flow from them (and this is an open transparent post that is the essence of our strategy):

• Pivotal focuses on three parts of Cloud Native Apps - having the best structured PaaS model (Pivotal Cloud Foundry), the best data fabric (Pivotal Hadoop as part of the Open Data Platform effort), winning over customers and developers by helping them build apps (Pivotal Labs)
• … which means Pivotal needs to continue continue to focus on winning in he structured Cloud Native App ecosystem with Cloud Foundry 
• … and Big Data
• … and keep expanding Pivotal Labs capacity directly or via franchising Cloud Foundry Dojos.
• VMware is focused on one part of Cloud Native Apps - having the best Cloud Native Apps IaaS layer…
• … which means VMware needs to focus their R&D $$ to build the best stack (Photon Platfrom) which must integrate and support a “First and Best” structured Cloud Native App using Cloud Foundry
• … while also supporting an unstructured Cloud Native App ecosystem (e.g. supporting Kubernetes, Mesos on Photon Controller/Photon)
• EMC focuses on two parts of Cloud Native Apps - having the best persistence (storage) stacks - and to “industrialize” the offer including on hyper-converged rack scale infrastructure…
• … which means EMC needs to focus their R&D $$ build the best Cloud Native App persistence/storage (ScaleIO, ECS, OneFS, DSSD)
• … which must integrate and support the Photon Platform as the “First and Best” Cloud Native App IaaS
• ... while also supporting an OpenStack based offering and ecosystem (Project Caspian)

Let me make this visual.

 

First - let’s build a framework.   This taxonomy is far from complete - and it is laid out how Cloud Native App stacks work - they are not “vertically stacked”, rather it’s a web of connected pieces (yes, yes, I know there is SOME vertical orientation :-).    I’ve also left out things that the companies do that are more oriented towards brownfield use cases (like Project Bonneville) - not because they aren’t awesome, but because I’m trying to make the greenfield picture clear.

 

There’s a whole set of functions that need to come together to build a complete Cloud Native App stack.   This visualization is FAR from complete - and I want people to feel free to add to it.  Omission is just that - something omitted - not a intentional slight :-)

 

Now - following the “axioms” / “corollaries” I noted above - let’s fill them in for Pivotal (and solid means “heavy weight code contribution in an open ecosystem”, and light hashing means “light code contribution in an open ecosystem that may have others that are the primary contributors”.    Again, this visualization is FAR from complete - and I want people to feel free to add to it.  Omission is just that - something omitted - not a intentional slight :-)   There’s far more occurring in Pivotal, VMware and EMC than I’ve put on electronic paper here.

 

 

 You can see material parts of the structured PaaS and Data Fabric are where Pivotal is ALL OVER IT.   Of course - there’s WAY more to it than what I’ve put down here (the PCF marketplace of micro services is really broad), but you get the idea.   Also.note - this can be deployed in private or public IaaS clouds - and can run on brownfield and greenfield.   In fact, the vast majority of Cloud Foundry runs on vSphere in a brownfield today.

 

Ok - same thing - with the VMware greenfield Cloud Native App IaaS efforts:

 

Here you can see what VMware has announced could be the industries best “Greenfield Cloud Native App IaaS”.  The Photon machine can add security and isolation to the container ecosystem - without a full heavyweight ESX and vCenter model.   The Photon Controller can create the bindings and configuration management for the container management ecosystem.   This means that VMware is building something that can underpin Structured PaaS (aka Cloud Foundry) and Unstructured (e.g. Kubertnetes, Mesos, etc).

 

I will keep saying it (that damn human instinct to “go binary”!) - it’s not that ESX, vCenter are bad in any way, or that brownfield is a bad approach.   vSphere provides a ton of value for traditional monolithic infrastructure-resilient apps - and CAN also support Cloud Native App apps using Project Bonneville, the Big Data Extensions and more.   I debated on the vRealize CodeStream work (because it’s best value in brownfield.

 

I also didn’t include VSAN - not because VSAN isn’t awesome (it is!) but that it’s primary focus is to NAIL being the simplest, most integrated SDS transactional stack with vSphere (post on SDS going up in coming weeks)

 

This is a new Greenfield Cloud Native App stack - something that is lean, designed for cloud scale.   Will VMware nail it?   I wouldn’t bet against them - a ton of brilliant engineers, and they created the premiere IaaS stack and SDDC that runs the world.   It’s an interesting strategic question that all companies must face - navigating the process of disrupting oneself (analogous to EMC’s self-disruption in many dimensions).

 

Ok - same thing with EMC’s Cloud Native App persistence stacks, and our efforts to “industrialize” the full stack.

 

 

… Now let’s put it together.  Remember the grounding strategic principles - each of the companies is responsible for leading in their particular area, and operating in an open ecosystem.  

 

Each stack can be used with that open ecosystem (Photon platform can support Structured and Unstructured PaaS as an example, and ECS/ScaleIO snap into Openstack/KVM beautifully)  - but our Federation principle of “open but aligned” means that with the VMware Cloud Native App IaaS Photon Platform announcement we can now create an unbelievable, completely unique Federation Structured Cloud Native App greenfield stack that is ideal for the enterprise:

 

Wowser.  There isn’t anything like this from anywhere else that I can think of (please correct me if I’m wrong).  

 

It also highlights the fallacy of thinking of the areas of innovation being in any one part of the set of companies.   There’s incredible things going on in each, and together.

Now, you're probably saying to yourself: "that’s a lot of pieces that I have to assemble myself - can you make it easier?”  Together, Pivotal, VMware, and EMC have heard this feedback from our customers and we understand the value to simplify the integration and consumption options.  

This is why Pivotal and VMware have announced a new single SKU that includes both the PCF structured platform and the Photon Platform Cloud Native Application platform to run it on.   Info on that here!

Now - one last missing ingredient.   All of the above is pure software - and could be deployed in a million and one ways, and in public, private clouds - and that choice is excellent!  

 

However, some will want to take all the risk out, and make it REALLY turnkey - including a single support, warranty, and ongoing engineering?

 

...If only we had a hyper-converged rack scale appliance using industry standard components, but with the necessary system architecture and hardware management and orchestration to scale to "infinity and beyond” :-)

 

Oh.  We do.   VxRack.   

 

 

 

BTW - when I say “we do” - I mean it.  VxRack has not gone GA yet, but is in the directed availably period.  Increasingly, we’re using a directed availability pre-GA for EMC/VCE solutions - we want to make sure we NAIL the VCE white-glove experience and outcomes that customers have come to expect with VxBlock.   VxRack will go GA very soon - and will underpin a whole series of solutions - let me elaborate on this...

 

...In the Converged/Hyper-Converged Infrastructure post here, I noted that VxRack has been designed from the start to support different “Cloud Personas” managed by the VxRack Manager.   One persona is “naked” (bring your own stack).  One persona is the VMware SDDC, fully integrated with EVO SDDC Manager.   One persona will likely be this Federation Cloud Native IaaS stack - lots to do before we can say this conclusively, but you can imagine it’s a direction we’re pursuing.

 

VCE also packages up and does the design and integration of the cloud persona layer that underpins the Federation Enterprise Hybrid Cloud - there’s nothing stopping them from doing the same for this Federation Cloud Native App greenfield stack.

 

There’s a TON of work to do - and I’m not saying this is available, but I’m sharing what we’re working on.   Before VMworld - the team got together and started, and it will kick off in full force next week - but… How. Freaking. Cool. Is. This?

Look - it’s early days here, and things are moving fast.  I would stay tuned, and I would wager that by VMworld Barcelona there will be even more (!!!)   But - at the same time, I want to pause for a second and say CONGRATULATIONS.

• At the strategic level, congratulations to VMware as a whole.   This embrace of brownfield AND greenfield is right, and is the choice that customers want to be put in front of them.   It means that a Federation level greenfield Cloud Native App stack is possible for the first time.   Customers and partners love you for vSphere and the SDDC Suite - let’s make them also love you for Photon Platform as THE BEST Cloud Native App IaaS stack.   THANK YOU!
• On a personal level, congratulations to Kit Colbert and all the people on the VMware Cloud Native App team - they’ve been working on this for years, and it’s always a great day when you can welcome your baby to the world!

As always - input welcome!   Would be very curious on people’s thoughts on brownfield / greenfield - and frankly on the whole topic.

 

 

 

 

 

Comments

[Sean Pedrosa]

Chad,

I am so glad I found this blog, everything you have described here is what I addressed in my email to you and Chris.

My conclusion is exactly as you have drawn on, VxRack makes perfect sense in this space of what I have now learned as Structured and Unstructered PaaS. Before I would just describe it as just CF or DIY PaaS :-) GE Appliances and GrubHub at DockerCon 2015 are great examples of the Unstructured PaaS side of things.

The business value customers are creating out of moving this way is phenomenal and as you correctly stated, this whole debate about this evolving, fast paced eco system on delivery mechanisms, one way vs another, are entirely missing the point. THAT's the really GREAT thing about this space, you have such immense choice to do what is BEST for your unique business requirements and with the unique employees you have.

As we know, every week a new tool is mentioned and released in the opensource community. When you have the flexibility at a MicroService/Container level to take on more risk with trialing new tools, because applications are not Infrastructure dependent, you start to really find new value adds and potential improvements on the day to day services you deliver internally or externally.

Really great post and aligns to everything I have been reading.

p.s. we need to change the language we use in this space for example when talking to people dealing in this area its not storage, its persistence etc....

[Chad Sakac]

@Sean - thanks bro - keep up your furious learning, and read my Q4 memo carefully. I'm thinking of you (and many of your kindred spirits amongst the SE family :-)

[David]

Hi Chad, thanks for it. Just wanted to follow what Matt did with Twitter and VMworld, however it seems not to live anymore? or is the link broken? http://tweets.vmworld.emccode.com/