I’ve started to blog my way through an architectural stack of a Big Data analytic framework:
I’ll start at the top layer (mobile) in this post. The creation of mobile apps will be my focus. In a previous post I posited that the building of mobile analytic-savvy applications is the new holy grail of generating revenue in enterprise companies. By “analytic-savvy” I am referring to apps that participate in the analytic and data life cycle depicted below.
Let’s discuss the mobile layer in the context of the bottom three layers that exist below it. For each architectural relationship that I describe, I will also comment on a real-world tool or product offering that highlights a sample way to implement the architecture. Starting from the bottom up:
The Scale-Out Cloud Storage Layer
Mobile devices will be heavy contributors to the data that needs to be analyzed. How can a large number of mobile devices securely contribute content down into the storage layer in a way that facilitates subsequent analytic access? There are two things to think about: (1) security from an AAA standpoint, and (2) a secure, enterprise-class way to place the data for subsequent analysis.
Within the toolset of the EMC and RSA portfolio, there are a couple of products that are great examples of how to do this:
- RSA SecurID can authenticate the device into the enterprise architecture. In addition:
- RSA Aveksa can help facilitate the management of roles and credentials across thousands of mobile devices.
- RSA SilverTail has the ability to monitor behavioral analysis on data as it is being contributed. SilverTail looks for abnormal patterns that might indicate fraudulent contribution of data into the enterprise.
- EMC Syncplicity has already integrated with a cloud-scale storage system (Isilon) as a secure way of moving content into an enterprise repository.
The Cloud Management and Orchestration Level
The mobile device, once it has the secure capability of moving data into a cloud storage layer, also needs some Big Data primitives exported up through the Cloud Management and Orchestration level. In other words, it’s not enough to push raw data down into a cloud store. There needs to be an orchestration paradigm that makes it easy to turn the cloud store into an analytic repository (e.g. a Hadoop access point).
Our great example of how to do this would be to use VMware’s Big Data extensions. This API allows a system administrator to open up access to the scale-out cloud storage layer as an HDFS/Hadoop API. For more detail on how this works, I recommend researching the approach adopted by the Hadoop Starter Kit (the HSK) released by EMC’s Open Innovation Lab team.
Now the mobile device has been provided with two mechanisms: a secure way to store data, and a secure analytic API to process the data.
The Platform as a Service Level
The final piece to discuss in this post is the PaaS layer. This layer is critical to the mobile device for a couple of reasons:
- The PaaS layer is cloud-neutral. Mobile applications written on top of this layer must be able to access data no matter what cloud management and orchestration layer is deployed underneath.
- The PaaS layer is cloud-portable. Mobile applications may wish to analyze data located on other clouds outside of the enterprise. The PaaS layer must allow for the movement of the mobile app without a re-write.
One of the best deployment options for this level is the open-source toolkit known as Cloud Foundry.
These bottom three layers are really focused on the underlying IT infrastructure and the topmost PaaS layer that provides portability and cloud neutrality for a mobile device.
In my next post I will focus on the top three levels, with a particular emphasis on the need for speed in mobile application software development.