,

Cloud Native Applications

,

I’ve always believed that cloud computing is really two things.  One, it is a technology architecture. Two, it is a business operating paradigm that we often call on-demand.  Your application must satisfy the on-demand business model requirements satisfy the technical architecture requirements to be a cloud native application.  There are not very many cloud native applications running in the world today.  This is changing quickly. 

A Cloud Native Application is architected and designed to run on what is commonly referred to as a cloud IaaS or PaaS.  The words I used there are very important.  It is architected and designed to run in the cloud from the beginning.  Therefore, it has a number of important traits as part of it’s DNA. The traits that a Cloud Native Application must have are:

 

  • Highly Available with no single point of failure at a tolerable granularity

  • Horizontally Scalable by just adding more appropriate resources

  • Scalable Concurrency

  • Highly parallelizable (as needed of course)

  • Scalable Throughput

  • Mission Critical

  • Automation

  • API

 

These traits must be built in from the beginning.  Otherwise, it’s likely that whatever you are doing is just temporary solution.  So, what is the actual solution?

I think that Cloud Native Applications are essentially distributed computing applications.  The design patterns for distributed applications are well documented, if not perhaps well known, and have been for quite some time now; the early 70’s at least.  In 1977, “The Laws for Communicating Parallel Processes,” was published.  This work was related to research done by Baker and Hewitt going back to the early 70’s or perhaps further? Ths and related work just keeps going back. Just take a few minutes to read the Actor Model Wikipedia entry and do related research.  My history is a little rough here but I’m catching up now.  It’s really fascinating.  I got a nice history lesson from Dale Schumacher over the weekend from his presentation, “Actor Thinking” that I saw on InfoQ. 

So, at the end of the day, I’m becoming quite convinced that the models that we need to deal with the issues we face when trying to embody the above traits that I listed into our internet applications already exist.  The models have existed for quite some time.  However, it’s only in the last 6-10 years that the technology has spread and the information itself about the technology (using the technology ironically) has spread far enough to start to make a dent and start to get these ideas well rooted and growing.

I’ll be spending a good bit of time in the near future thinking and testing with Actor models when working with developers to architect cloud native applications.  I’m interested in hearing more from other folks that are doing the same. 

Reference Materials and Related Items

While researching this and various distributed application programming paradigms I ran across this article called, “Why has the actor model not succeeded?”

http://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol2/pjm2/

Of course, after I wrote this article I wanted to check and see who else might be thinking this way.  So, I searched, dug, and read a bit.  I found that I’m not the only one who had this general series of thoughts.  But, that my way of thinking about it was a bit different. 

Here are a few links I found:

NCA’s - http://cloud.dzone.com/news/what-native-cloud-application

NCA’s again - http://www.theserverside.com/news/thread.tss?thread_id=52871

The thing is, that those two articles combined call out the following three traits of NCA’s:

  1. “They are massively parallel”

  2. They are “Developed using a cross-cloud paradigm”

  3. “Massively Parallel computations”

  4. “Massively Parallel data”

  5. “Auto-Scalability On the Cloud”

Well, I don’t much care if it becomes a CNA or an NCA.  But, do care about the traits. 

Regarding Riak-Core and Recent Hacks

Work being done on the Erlang based Riak-Core and Riak-KV systems lately is rather fascinating as well.  Take a look at this extension to Riak-Core recently released.

https://github.com/jtuple/riak_zab

It seems to me that that riak_zab (and the original zab work) address particular concerns that were mentioned in an article called, “Why has the Actor Model not Succeeded.”  In particular, this quote, “manipulation of a stack-like structure using asynchronous message passing could be problematic if the messages do not arrive in the correct order.”