|Cognizant Mobility Expert |
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:
- “Do we have availability monitoring?”
- “How do you get the Node service working again if it falls over?”
- “Do we have High Availability (HA) and Disaster Recovery (DR)?”
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 (http://it20.info/2011/04/tcp-clouds-udp-clouds-design-for-fail-and-aws/).
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.
- TCP is a reliable connection oriented protocol with segment sequencing and acknowledgments
- UDP is an unreliable connectionless protocol with no sequencing or acknowledgments
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.
- A TCP Cloud has the application in the consumer space and the HA / DR policies and Cloud Compute in the provider space.
- A UDP Cloud has the application and the HA/DR policies in the consumer space and only the Cloud Compute in the provider space.
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 (http://readwrite.com/2010/12/20/chaos-monkey-how-netflix-uses). 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 (http://thinkacloud.wordpress.com/2014/01/27/is-openstack-and-vmware-like-cattle-and-pets/).
vSphere servers are likened to pets:
· They are given names (such as pussinboots.cern.ch)
· Uniquely hand raised and cared for
· Nursed back to health when sick
OpenStack servers are likened to cattle:
· They get random identification numbers (vm0042.cern.ch)
· They are almost identical to each other
· They are cared for as a group
· They and basically just replaced when ill
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.
There are also plenty of ways to monitor availability of the Cloud instance. You could subscribe to a twitter feed of your particular Cloud (http://status.aws.amazon.com/). There are quite a few services that offer a ping service to check availability (https://www.statuscake.com/paid-website-monitoring/). If you are using Appcelerator Cloud Services then there is a great tool called Relic available on their Market Place (https://marketplace.appcelerator.com/apps/1140?restoreSearch=true#!features/Availability_Monitoring).
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.
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.