Welcome!

@CloudExpo Authors: Zakia Bouachraoui, Elizabeth White, Liz McMillan, Pat Romanski, Roger Strukhoff

Related Topics: @CloudExpo, Java IoT, Mobile IoT, Microservices Expo, Linux Containers, Agile Computing

@CloudExpo: Article

MBaaS, Cloud Computing and Architectures for Enterprise Mobility

What your mother never told you

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:

  • "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)?"

This led to me take a deep look at the architecture of building Cloud native applications on top of Amazon Web Services (AWS). MBaaS does abstract a lot of the underlying details away from you, but at the end of the day if the underlying Cloud provider is Amazon EC2 (which is a very common option) then maybe it is worth understanding exactly how AWS works. Abstraction is a great concept for simplification but it is always better if you start off with a core understanding before you start such a process. Furthermore, it used to be the case that most server side development was performed by specialists in server side development but the popularity of Node has meant that client-side JavaScript developers are now faced with developing server side applications that run on the Cloud for the first time.

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.

  • 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. 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:

  • 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.

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.

More Stories By Kevin Benedict

Kevin Benedict serves as the Senior Vice President, Solutions Strategy, at Regalix, a Silicon Valley based company, focused on bringing the best strategies, digital technologies, processes and people together to deliver improved customer experiences, journeys and success through the combination of intelligent solutions, analytics, automation and services. He is a popular writer, speaker and futurist, and in the past 8 years he has taught workshops for large enterprises and government agencies in 18 different countries. He has over 32 years of experience working with strategic enterprise IT solutions and business processes, and he is also a veteran executive working with both solution and services companies. He has written dozens of technology and strategy reports, over a thousand articles, interviewed hundreds of technology experts, and produced videos on the future of digital technologies and their impact on industries.

CloudEXPO Stories
The precious oil is extracted from the seeds of prickly pear cactus plant. After taking out the seeds from the fruits, they are adequately dried and then cold pressed to obtain the oil. Indeed, the prickly seed oil is quite expensive. Well, that is understandable when you consider the fact that the seeds are really tiny and each seed contain only about 5% of oil in it at most, plus the seeds are usually handpicked from the fruits. This means it will take tons of these seeds to produce just one bottle of the oil for commercial purpose. But from its medical properties to its culinary importance, skin lightening, moisturizing, and protection abilities, down to its extraordinary hair care properties, prickly seed oil has got lots of excellent rewards for anyone who pays the price.
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected path for IoT innovators to scale globally, and the smartest path to cross-device synergy in an instrumented, connected world.
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
ScaleMP is presenting at CloudEXPO 2019, held June 24-26 in Santa Clara, and we’d love to see you there. At the conference, we’ll demonstrate how ScaleMP is solving one of the most vexing challenges for cloud — memory cost and limit of scale — and how our innovative vSMP MemoryONE solution provides affordable larger server memory for the private and public cloud. Please visit us at Booth No. 519 to connect with our experts and learn more about vSMP MemoryONE and how it is already serving some of the world’s largest data centers. Click here to schedule a meeting with our experts and executives.
Darktrace is the world's leading AI company for cyber security. Created by mathematicians from the University of Cambridge, Darktrace's Enterprise Immune System is the first non-consumer application of machine learning to work at scale, across all network types, from physical, virtualized, and cloud, through to IoT and industrial control systems. Installed as a self-configuring cyber defense platform, Darktrace continuously learns what is ‘normal' for all devices and users, updating its understanding as the environment changes.