Most Read This Week
MBaaS, Cloud Computing and Architectures for Enterprise Mobility
What your mother never told you
By: Kevin Benedict
Apr. 4, 2014 08:30 AM
My friend and Cognizant colleague, the ever opinionated Peter Rogers, shares more of his insights into the world of IoT (Internet of Things), enterprise mobility, geekdom and how they really works under-the-covers. By "they" I mean technology, not geeks.
I believe the trends away from mainframes to the Cloud will have a large impact on enterprise mobility architecture. If we believe that going forward, enterprise mobility architectures will be closely tied to the Cloud, then we need to take a serious look at architectural design. I have written about MBaaS (Mobile Back End as a Service) which is a new form of Cloud offering, but today I want share my opinions on best practices.
I have been working on an MBaaS project recently, and we ran into some interesting challenges when it came to submitting the App to the Apple App Store. In the middle of the night there was some server maintenance going on which was obviously considered out of hours in the UK. The point I reminded everyone was that Apple Valley is actually GMT-7, and so what is considered out of hours in the UK is not the case where Apple does their testing.
We then got onto some interesting questions:
One of the best articles that I found underpinning architectural design for Cloud native applications on AWS was written back in 2011 (but is still referenced today) and genuinely changed my architectural philosophy on the matter.
In a nutshell, Amazon Web Services uses a UDP-cloud model because it doesn't guarantee reliability at the infrastructure level.
This is a very interesting concept so I want to take the rest of the Blog to explain it, starting with a quick reminder of TCP and UDP.
During a few large AWS outages then a number of Bloggers (such as George Reese) outlined the differences between the "design for fail" model and the "traditional" model. The traditional model, among other things, has high-availability (HA) and disaster recovery (DR) characteristics built right into the infrastructure and these features are typically application-agnostic. An alternative view of "design for fail" and "traditional" is therefore TCP-clouds and UDP-clouds.
This is obviously a vast oversimplification and AWS offers far more than just cloud computing, but the key components in this equation are the ones to focus on. AWS doesn't have high availability built into the EC2 service, instead they suggest to deploy in multiple "Availability Zones" simply to avoid concurrent failures. In other words, if you deploy your application in a given "Availability Zone," there is nothing that will "fail it over" to another "Availability Zone."
Some of AWS customers, therefore, developed tools to test the resiliency of their applications such as a Chaos Monkey tool. These are software programs that are designed to break things randomly. In a TCP-cloud it would be the cloud provider to run traditional tests to make sure the infrastructure could self-recover. In a UDP-cloud it is the developer that must run a Chaos Monkey in order to test if the application could self-recover since it's been designed for fail.
A different view on this is cattle and pets.
vSphere servers are likened to pets:
OpenStack servers are likened to cattle:
The conclusion being that "Future application architectures should use Cattle, but Pets with strong configuration management are viable and still needed". If you haven't made the connection yet, then Cattle are UDP Clouds and Pets are the TCP Clouds.
I have always classed MBaaS as somewhere between Cloud PaaS and Cloud SaaS to my colleagues but I have been quite wrong in this regard. I want to update that definition to the following:
"MBaaS is the combination of Cloud SaaS and EITHER Cloud PaaS or Cloud IaaS, which depends on both the underlying Cloud provider and the supporting service model".
That means if you have an underlying Cloud provider of AWS, and your MBaaS vendor isn't giving you additional support in HA/DR, availability monitoring or Chaos Monkey tools, then you are basically sitting on a Cloud IaaS which is acting as a UDP Cloud. That is an important thing to be aware of in terms of what you need to bring to the party, and is the potential danger of not really understanding the underlying Cloud model that you are working with.
When we finally move away from mainframes and fully embrace the Cloud then we need to look at how we architect Cloud native applications. That means considering that your Node service tier could fall over and looking at tools like Node-Forever and PM2 (http://devo.ps/blog/2013/06/26/goodbye-node-forever-hello-pm2.html). Node-Forever is a popular option to bring Node services back to life again (Keep Alive) and also supports CoffeeScript. PM2 adds the following: log aggregation; API; terminal monitoring (including CPU usage and memory consumption by cluster); native clustering; and JSON configuration.
There are also plenty of ways to monitor availability of the Cloud instance. You could subscribe to a twitter feed of your particular Cloud. There are quite a few services that offer a ping service to check availability. If you are using Appcelerator Cloud Services then there is a great tool called Relic available on their Market Place.
In terms of HA then you need to look into deploying a High Availability Proxy. HAProxy (High Availability Proxy) is an open source load balancer which can load balance any TCP service. It is particularly suited for HTTP load balancing as it supports session persistence and layer 7 processing. I am not sure how many Cloud developers actually use Chaos Monkey tools to test DR but the option is certainly there. Certainly you should be designing your applications to be stateless as much as possible and looking into NoSQL databases.
I hope this article has helped you to understand that you cannot just assume your MBaaS vendor is providing a full Cloud PaaS and all of this stuff just comes out of the box. I hope you will also consider designing your Cloud services with a general consideration of the underlying infrastructure. You should have this discussion early on in the project and work out which tools you need to be providing and which enterprise architectural principles need to be applied.
Of course there is nothing to stop you having two or three different underlying Cloud providers or just having the mission critical features running on a private local Cloud. It is an important point to remember though, Amazon EC2 and other Cloud providers can go down for 48 hours. It is very rare but it is not unheard of in the history of the Cloud.
"Design for failure and you won't ever be surprised"
I would like to thank Massimo and Douglas Lin for their exceptional Blogs that I have referenced throughout this article.
Kevin Benedict Senior Analyst, Digital Transformation Cognizant View my profile on LinkedIn Learn about mobile strategies at MobileEnterpriseStrategies.com Follow me on Twitter @krbenedict Browse the Mobile Solution Directory Join the Linkedin Group Strategic Enterprise Mobility Join the Google+ Community Mobile Enterprise Strategies
***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads