Mobile Cloud Service Models
I slept and I dreamed that life is all joy. I woke and I saw that life is all service. I served and I saw that service is joy.
Kahlil Gibran
Abstract
Internet cloud services are usually categorized into IaaS, PaaS, and SaaS. However, it does not apply to mobile cloud service models, where mobiles may be a service provider, service consumer and/or service broker at the same time. It is more suitable to classify mobile cloud services using a user-centric approach, where mobile devices holders regard his/her mobiles as service consumer which may consume computing and storage resources, retrieve data, and compose services from the cloud, etc.; mobile devices can serve as cloud service providers providing sensing data to other cloud users; furthermore, mobile devices can serve as service brokers that can cache service content or act as networking relay, etc. Finally, a scalable IoT service model is highly desired to compose IoT services/functions to build a flexible, reusable, and scalable new service approach, in which microservices come into the picture as a promising candidate for the next generation mobile cloud computing service framework.
Keywords
Service provider; Service consumer; Service broker; Microservices; IaaS; PaaS; SaaS; IoT
Cloud services are usually classified as IaaS, PaaS, and SaaS according to service level the cloud provides. IaaS provides the lower level infrastructure services where the users would like to manipulate the resources directly with the guest operating system. PaaS and SaaS provide the higher-level service, for which users do not work on operating system directly, but instead, on the software platforms or the service products. From a naïve service perspective, where the service operation involves three actors: service provider, service consumer and service broker, the previous cloud service classification focuses on the service provider side. To extend the cloud service model into mobile cloud service model, we will, from the involved service actors' perspective, look into the mobile cloud service models. The addition of mobile devices to the cloud service model introduces additional reaction patterns in the service operation, including service offloading, migration, and composition. After studying the basics of mobile cloud service models, we will discuss some state-of-the-art mobile cloud service models.
This chapter is organized as follows. We review the cloud service models including IaaS, PaaS and Saas in Section 3.1. We will discuss the state-of-the-art on mobile cloud service models in Section 3.2; and then we will focus on the mobile cloud service models in Section 3.3. Finally, we will present Internet of Things and the applied microservice patterns in Section 3.4.
3.1 Review Cloud Service Models
Though service-oriented architecture advocates “everything as a service” (with the acronyms EaaS or XaaS, or simply aaS), cloud-computing providers offer their “services” according to different models, which happen to form a stack: infrastructure-, platform-, and software-as-a-service. IaaS is like a vehicle, where it needs to be maintained and supplied with fuel, but a driver can go pretty much everywhere he/she wants to; PaaS is like a taxi, where a rider chooses where he wants to go, but keeping the car running is up to the driver; finally, SaaS is like a public transport, which is cheap and takes care of everything; however, it may not get as close to where the rider wants to go. The three cloud service models are listed in Fig. 3.1.
3.1.1 Infrastructure as a Service
In the most basic cloud-service model, and according to the Internet Engineering Task Force (IETF), providers of IaaS offer computers – physical or (more often) virtual machines – and other resources. IaaS refers to online services that abstract the user from the details of infrastructure like physical computing resources, location, data partitioning, scaling, security, backup, etc. A hypervisor, such as Xen, Oracle VirtualBox, Oracle VM, KVM, VMware ESX/ESXi, or Hyper-V runs the virtual machines as guests. Pools of hypervisors within the cloud operational system can support large numbers of virtual machines and have the ability to scale services up and down according to customers' varying requirements. IaaS clouds often offer additional resources such as a virtual-machine disk-image library, raw block storage, file or object storage, firewalls, load balancers, IP addresses, VLANs, and software bundles. IaaS-cloud providers supply these resources on-demand from their large pools of equipment installed in data centers. For wide-area connectivity, customers can use either the Internet or carrier clouds (dedicated virtual private networks).
To deploy their applications, cloud users install operating-system images and their application software on the cloud infrastructure. In this model, the cloud user patches and maintains the operating systems and the application software. Cloud providers typically bill IaaS services on a utility computing basis: cost reflects the amount of resources allocated and consumed.
IaaS examples
• Amazon Web Services EC2 and S3. Amazon EC2 forms a central part of Amazon's cloud-computing platform, Amazon Web Services (AWS), by allowing users to rent virtual computers on which to run their own computer applications. EC2 encourages scalable deployment of applications by providing a web service through which a user can boot an Amazon Machine Image to configure a virtual machine, which Amazon calls an “instance”, containing any software desired. A user can create, launch, and terminate server-instances as needed, paying by the hour for active servers – hence the term “elastic.” EC2 provides users with control over the geographical location of instances that allows for latency optimization and high levels of redundancy.
Amazon S3 (Simple Storage Service) is an online file storage web service offered by Amazon Web Services. Amazon S3 provides storage through web services interfaces (REST, SOAP, and BitTorrent). S3 stores arbitrary objects (computer files) up to 5 terabytes in size, each accompanied by up to 2 kilobytes of metadata. Objects are organized into buckets (each owned by an Amazon Web Services account), and identified within each bucket by a unique, user-assigned key. Amazon Machine Images (AMIs) which are used in the Elastic Compute Cloud (EC2) can be exported to S3 as bundles. Buckets and objects can be created, listed, and retrieved using either an REST-style HTTP interface or a SOAP interface. Additionally, objects can be downloaded using the HTTP GET interface and the BitTorrent protocol. Requests are authorized using an access control list associated with each bucket and object.
• OpenStack Nova, Swift, and Neutron. Nova is an OpenStack project designed to provide power massively scalable, on-demand, self-service access to compute resources. Swift is a highly available, distributed, eventually consistent object/blob store. Organizations can use Swift to store lots of data efficiently, safely, and cheaply. Neutron is an OpenStack project to provide “network connectivity as a service” between interface devices (e.g., virtual Network Interface Cards – vNICs) managed by other OpenStack services (e.g., Nova). It implements the Neutron API.
3.1.2 Platform as a Service
PaaS vendors offer a development environment to application developers. The provider typically develops toolkit and standards for development and channels for distribution and payment. In the PaaS models, cloud providers deliver a computing platform, typically including operating system, programming-language execution environment, database, and web server. Application developers can develop and run their software solutions on a cloud platform without the cost and complexity of buying and managing the underlying hardware and software layers. With some PaaS offers like Microsoft Azure and Google App Engine, the underlying computer and storage resources scale automatically to match application demand so that the cloud user does not have to allocate resources manually. The latter has also been proposed by an architecture aiming to facilitate real-time in cloud environments. Even more specific application types can be provided via PaaS, such as media encoding as provided by services like bitmovin or media.io.
Some integration and data management providers have also embraced specialized applications of PaaS as delivery models for data solutions. Examples include iPaaS and dPaaS. Integration Platform as a Service (iPaaS) enables customers to develop, execute, and govern integration flows. Under the iPaaS integration model, customers drive the development and deployment of integrations without installing or managing any hardware or middleware. Data Platform as a Service (dPaaS) delivers integration and data-management products as a fully managed service. Under the dPaaS model, the PaaS provider, not the customer, manages the development and execution of data solutions by building tailored data applications for the customer. dPaaS users retain transparency and control over data through data-visualization tools.
PaaS consumers do not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but have control over the deployed applications and possibly configuration settings for the application-hosting environment.
PaaS examples
• Microsoft Azure. Microsoft lists over 50 Azure services including the following PaaS:
1. App services, PaaS environment letting developers easily publish and manage web sites.
2. Websites, high density hosting of websites allows developers to build sites using ASP.NET, PHP, Node.js, or Python and can be deployed using FTP, Git, Mercurial, or Team Foundation Server. This feature was announced in preview form in June 2012 at the Meet Microsoft Azure event. This comprises one aspect of the PaaS offerings for the Microsoft Azure Platform. It was renamed Web Apps in April 2015.
3. WebJobs, applications which can be deployed to a Web apps to implement background processing that can be invoked on a schedule, on demand or can run continuously. Blob, Table, and Queue services can be used to communicate between Web Apps and Web Jobs and to provide state.
• Google App Engine. Google App Engine (often referred to as GAE or simply App Engine) is a PaaS cloud computing platform for developing and hosting web applications in Google-managed data centers. Applications are sandboxed and run across multiple servers. App Engine offers automatic scaling for web applications – as the number of requests increases for an application, App Engine automatically allocates more resources for the web application to handle the additional demand.
Currently, the supported programming languages are Python, Java (and, by extension, other JVM languages such as Groovy, JRuby, Scala, Clojure), Go, and PHP. Node.js is also available in the managed VM environment, and Google App Engine has been written to be language independent.
Python web frameworks that run on Google App Engine include Django, CherryPy, Pyramid, Flask, web2py, and webapp2, as well as a custom Google-written webapp framework and several others designed specifically for the platform that emerged since the release. Any Python framework that supports the WSGI using the CGI adapter can be used to create an application and the framework can be uploaded with the developed application. Third-party libraries written in pure Python may also be uploaded.
Google App Engine supports many Java standards and frameworks. Central to this is the servlet 2.5 technology using the open-source Jetty Web Server, along with accompanying technologies such as JSP. JavaServer Faces operates with some workarounds.
Though the datastore used may be unfamiliar to programmers, it is easily accessed and supported with JPA, JDO, and by the simple low-level API. There are several alternative libraries and frameworks you can use to model and map the data to the datastore such as Objectify, Slim3, and Jello framework. Jello framework is a full-stack Java framework optimized for Google App Engine that includes comprehensive Data Authorization model and a powerful RESTful engine.
The Spring Framework works with GAE; however, the Spring Security module (if used) requires workarounds. Apache Struts 1 is supported, and Struts 2 runs with workarounds.
The Django web framework and applications running on it can be used on App Engine with modification. Django-nonrel aims to allow Django to work with nonrelational databases and the project includes support for App Engine.
• Heroku. Heroku is a cloud PaaS supporting several programming languages. Heroku was acquired by Salesforce.com in 2010. Heroku, one of the first cloud platforms, has been in development since June 2007, when it supported only the Ruby programming language, but has since added support for Java, Node.js, Scala, Clojure, Python, PHP, and Go.
• OpenShift. OpenShift is a Kubernetes and Docker powered cloud PaaS developed by Red Hat.
Online is Red Hat's public cloud application development and hosting platform. Online is currently powered by version 2 of the Origin project source code, which is also available under the Apache License version 2.0. Online supports a variety of languages, frameworks, and databases out of the box. In addition to the built-in languages and services, developers can add other language, database, or middleware components that they need via the OpenShift Cartridge API.
Origin is the upstream community project that powers OpenShift Online, OpenShift Dedicated, and OpenShift Enterprise. Built around a core of Docker container packaging and Kubernetes container cluster management, Origin is also augmented by application lifecycle management functionality and DevOps tooling. Origin provides a complete open source application container platform. All source code for the Origin project is available under the Apache License (version 2.0) on GitHub.
3.1.3 Software as a Service
In the SaaS model, users gain access to application software and databases. Cloud providers manage the infrastructure and platforms that run the applications. SaaS is sometimes referred to as “on-demand software” and is usually priced on a pay-per-use basis or using a subscription fee.
In the SaaS model, cloud providers install and operate application software in the cloud and cloud users access the software from cloud clients. Cloud users do not manage the cloud infrastructure and platform where the application runs. This eliminates the need to install and run the application on the cloud user's own computers, which simplifies maintenance and support. Cloud applications differ from other applications in their scalability – which can be achieved by cloning tasks onto multiple virtual machines at run-time to meet changing work demand. Load balancers distribute the work over the set of virtual machines. This process is transparent to the cloud user, who sees only a single access-point. To accommodate a large number of cloud users, cloud applications can be multitenant, meaning that any machine may serve more than one cloud-user organization.
The pricing model for SaaS applications is typically a monthly or yearly flat fee per user, so prices become scalable and adjustable if users are added or removed at any point.
Proponents claim that SaaS gives a business the potential to reduce IT operational costs by outsourcing hardware and software maintenance and support to the cloud provider. This enables the business to reallocate IT operations costs away from hardware/software spending and from personnel expenses, towards meeting other goals. In addition, with applications hosted centrally, updates can be released without the need for users to install new software. One drawback of SaaS comes with storing the users' data on the cloud provider's server. As a result, there could be unauthorized access to the data. For this reason, users are increasingly adopting intelligent third-party key-management systems to help secure their data.
SaaS examples
• Google for Work. Google for Work is a service from Google that provides customizable enterprise versions of several Google products using a domain name provided by the customer. It features several Web applications with similar functionality to traditional office suites, including Gmail, Hangouts, Google Calendar, Drive, Docs, Sheets, Slides, Groups, News, Play, Sites, and Vault. It was the vision of Rajen Sheth, a Google employee who later developed Chromebooks.
Gmail, a free webmail service provided by Google, was launched as an invitation-only beta program on April 1, 2004, and became available to the public on February 7, 2007. The service was upgraded from beta status on July 7, 2009, at which time it had 146 million users monthly. The service was the first online e-mail service with one gigabyte of storage. It was also the first to keep e-mails from the same conversation together in one thread, similar to an Internet forum. The service offers over 15 GB of free storage, shared with other Google Apps, with additional storage ranging from 20 GB to 16 TB available for $0.25 per 1 GB per year.
• iCloud. iCloud is a cloud storage and cloud computing service from Apple Inc. launched on October 12, 2011. As of February 2016, the service had 782 million users.
The service provides its users with means to store data such as documents, photos, and music on remote servers for download to iOS, Macintosh or Windows devices, to share and send data to other users, and to manage their Apple devices if lost or stolen.
The service also provides the means to wirelessly back up iOS devices directly to iCloud, instead of being reliant on manual backups to a host Mac or Windows computer using iTunes. Service users are also able to share photos, music, and games instantly by linking accounts via AirDrop wireless.
3.2 Current Mobile Cloud Service Models
Current Internet clouds have been broadly classified in three-type service models: Infrastructure-as-a-service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). They are classified according to the layers of virtualization. However, due to the involvement of both Cyber-Physical Systems (CPS) and Cyber Virtual Systems (CVS), the MCC's service models are more appropriate to be classified according to the roles of computational entities within its service framework, where the classification of MCC service models can use the roles and relations between mobile entities and their invoked cloud-based resource provisioning. Based on this view, existing MCC services can be classified into three major models: Mobile-as-a-Service-Consumer (MaaSC), Mobile-as-a-Service-Provider (MaaSP), and Mobile-as-a-Service-Broker (MaaSB). These MCC service models are illustrated in Fig. 3.2, in which arrows indicate service processing flows from service providers to service recipients.
MaaSC originated from the traditional client–server model by introducing virtualization, fine-grained access control, and other cloud-based technologies at the initial stage. Mobile devices can outsource their computation and storage functions onto the cloud in order to achieve better performance and more application capabilities. In this architecture, the service is one-way from the cloud to mobile devices, and mobile devices are service consumers. Most existing MCC services fall into this category.
MaaSP is different from MaaSC in that the role of a mobile device is shifted from a service consumer to a service provider. For example, with on-board sensors, i.e., GPS module, camera, gyroscope, etc., mobile devices are able to sense data from the devices and their neighboring environment, and further provide sensing services to other mobile devices through the cloud. In Fig. 3.2, consumers receive services provided by both the cloud and mobile devices. The types of services provided by mobile devices are diverse based on their sensing and processing capabilities.
MaaSB can be considered an extension of MaaSP, where MaaSB provides networking and data forwarding services for other mobile devices or sensing nodes. MaaSB is desired under some circumstances because mobile devices usually have limited sensing capability compared to sensors that are dedicated to specially designed functionalities and sensing locations. For example, mobile phones can be used to collect users' physical activities from Nike Fuelband [215]. MaaSB extends the cloud edges to mobile devices and wireless sensors. Thus, a mobile device can be configured as a gateway or a proxy, providing networking services through various communication approaches such as 3/4G, Bluetooth, WiFi, etc. Moreover, the proxy mobile device can also provide security and privacy protections to their interfaced sensors.
We summarize existing MCC services and applications in Table 3.1. We discuss four major MCC service types and corresponding representatives. Each service or application can be categorized into one or multiple service models. MaaSC is the most common MCC service model because most of existing mobile devices are still restricted by their computation and energy capacities. For example, CloneCloud [80] provides the computation task offloading service for mobile devices. In this case, the mobile device is the service consumer since it only gets benefit from the service provided by cloud rather than providing services for other users.
Table 3.1
Summary of MCC Services and Applications
| MCC Services and Applications | Service Models | |||
| MCC Service Types | Representative Approaches | MaaSC | MaaSP | MaaSB |
| Mobile Cloud Computation | CloneCloud [80] | ✓ | ||
| MAUI [89] | ✓ | |||
| ThinkAir [168] | ✓ | |||
| Mobile Cloud Storage | Dropbox, Box, iCloud, GoogleDrive, and Skydrive [87] | ✓ | ||
| WhereStore [257] | ✓ | |||
| STACEE [213] | ✓ | ✓ | ||
| Security and Privacy | CloudAV [218] | ✓ | ||
| Secure Web Referral Services for Mobile Cloud Computing [176] | ✓ | |||
| Zscaler [300] | ✓ | |||
| Google Wallet [119] | ✓ | |||
| Context Awareness | An Integrated Cloud-based Framework for Mobile Phone Sensing [105] | ✓ | ✓ | |
3.2.1 Mobile Cloud Computation
Computation task offloading is a demanding feature for mobile devices relying on Internet clouds to perform resources-intensive computation tasks. Partitioning computation tasks and allocating them between mobile devices and clouds can be very inefficient during the application runtime considering various performance metrics such as energy consumption, CPU power, network delay, etc. Efficiently and intelligently offloading the computation tasks onto the cloud is one of the main research issues of MCC. CloneCloud [80] and MAUI [89] are two pioneers in this area. They both can automatically offload computing tasks to the cloud.
CloneCloud serves as an application partitioner as well as an execution runtime environment that allows unmodified mobile applications to seamlessly offload parts of the executions from mobile devices onto a cloud server. The offloading decision is made by optimizing execution time and energy usage for mobile devices. Contrary to CloneCloud, MAUI allows modification of offloading applications at the coding level to maximize the energy saving of mobile devices. Thinkair [168] demands dedicated VMs in clouds as part of a complete smart phone system, and removes the restrictions on applications/inputs/environmental conditions by using an online method-level offloading.
3.2.2 Mobile Cloud Storage
Storage capacity is another constraint of mobile devices. There are many existing storage services for mobile devices, e.g., Dropbox, Box, iCloud, Google Drive, and Skydrive [60][87]. Besides manually uploading the files or data onto the cloud, one desired feature of mobile cloud storage services is the automatic synchronization between mobile devices and the cloud. Multimedia data generated by mobile devices demands a stable and high available storage solution. This is the reason that many smart phone operating systems natively implant the multimedia data synchronization feature, e.g., iCloud for iOS, Skydrive for Windows Phone, Google Drive for Android, etc. Moreover, mobile users' behavior data such as location traces, browsing history, personal contacts, and preference settings need to be kept in a reliable and protected storage space. Most existing commercial cloud storage solutions are built on a centralized data center, which is appropriate for Internet clouds.
Storage mobility has been gradually becoming a recent research focus. WhereStore [257] is a location-based data storage solution for smart phones. It uses filtered replication (a filter expressing the set of data items that are likely to be accessed in the near future) along with each device's location history to distribute data items between smart phones and the cloud. STACEE [213] proposes a peer-to-peer cloud storage where mobile phones, tablets, set-top boxes, modems and networked storage devices can all contribute as storage within these storage clouds. It provides a peer-to-peer (P2P) cloud storage solution and addresses the storage issue for mobile users as a QoS-aware scheduling problem.
3.2.3 Security and Privacy
Security related services aim to provide data security protection through the cloud. Security of mobile devices can be enhanced with the help of cloud security mechanisms including cloud-based secure proxy, remote anti-virus, remote attestation, etc.
CloudAV [218] advocates such a cloud-based security model for malware detection for end hosts by providing antivirus as an in-cloud security service. Secure web referral services [176] enable the antivirus and antiphishing services through the cloud. The referral services depend on a secure search engine to validate URLs accessed by a mobile device to prevent mobile users from accessing phishing websites.
Zscaler [300] is one of the most well-known commercial cloud-based security companies that provide policy-based, secure internet access for mobile devices. It provides a comprehensive cloud-based security solution including three main components: ZEN (proxy), CA (central authority), and Nanologs server (log server). Various cloud-based security services are built based on these components. For example, the ByteScan service enables each ZEN to scan every byte of the web request, content, responses and all related data to block malicious actions and data such as viruses, cross site scripting (XSS), botnets, etc. The PageRisk service relies on the ZEN to compute a PageRisk index for every page that is loaded and enables the administrator to control content served to their users based on an acceptable risk evaluation. The NanoLog service enables administrators to access any transaction log in realtime.
An increasing number of security features can be enabled in the cloud, in which a reliable and secure connection between a mobile device and the cloud is the main challenge for this type of solutions. Google Wallet [119] is developed on a cloud-mobile dual trust root model, where the cloud is in charge of the application level security such as credit card transactions and user credential management, and the Google Wallet mobile device is protected by strong trust computing elements on the board to prevent malicious attacks on the mobile devices.
3.2.4 MCC Context Awareness
Nowadays, a smart mobile device usually serves as an information gateway for mobile users involving various personalized activities such as checking e-mails, making appointments, surfing the web, locating interested spots, analyzing personal behavior data based on data mining and machine learning, etc. For example, in [105], each mobile device has a dedicated Mobile Cloud Engine (MCE) including three modules: decision module, publish subscribe module, and context awareness module. The decision module regulates the transactions among the different parts of the MCE. The publish subscribe module is responsible for establishing the data flow between the mobile application and the MCE. Finally, the context awareness module provides context information to the application. The state-of-the-art solutions lack a unified approach suitable to support diverse applications while reducing the energy consumption and providing intelligent assistance to mobile users.
3.3 Mobile Cloud Service Models and Examples
The Internet cloud service model is categorized by the service content in a layered structure. From the service composition perspective, we can see the cloud usually works as service provider, while users consume the service through web service interfaces. When we extend the Internet cloud to the mobile cloud, we introduce mobile devices into the picture, which can be service provider, service consumer and service broker as well.
3.3.1 Mobile as a Service Consumer
Mobile as a Service Consumer (MaaSC) originated from the traditional client–server model by introducing virtualization, fine-grained access control, and other cloud-based technologies at the initial stage. Mobile devices can outsource their computation and storage functions onto the cloud in order to achieve better performance and more application capabilities. In this architecture, the service is one-way from the cloud to mobile devices and mobile devices are service consumers. Most existing MCC services fall into this category. One typical example of MaaSC is surrogate as a service, which is introduced next.
Mobile devices consume VM resources
The resources in the mobile devices are usually limited due to the device size and weight. Not only are the computation power and storage space bounded, but the battery limits the active lifetime. To offload some tasks from mobile devices to the clouds is one of the promising approaches to reduce the computation and storage requirement on the mobile devices as well as to increase the device battery duration. The cloud which can host the offloaded tasks are providing surrogate as a service.
The mobile device to offload the task usually completes in three steps. First, the mobile device discovers the surrogate service and migrates the task code to the cloud. This piece of code should be compatible with cloud surrogate running environment. The application may contain the cloud version of code which is migrated, or the cloud accepts the mobile code and knows how to run it. Second, the cloud hosts a surrogate container to run the code and provides the interfaces for the mobile device to call. The application on the mobile device call the interface to pass in the input and fetch the task result. This remote function call may happen many times during the application lifetime. Last, when the application on the mobile device decides not to call the offloaded code any more, it tells the cloud surrogate to terminate the hosting and release the resources to finalize the cloud billing for this session.
Surrogate as a service is not good in various situations. Since the communication between mobile device and cloud costs some resource and energy, and causes delay, the tradeoff should be considered seriously to get the offloading benefits. The cost of offloading includes the network delay, energy consumption for the networking, development effort to make code compatible, and the boxing and unboxing data during the remote function call. The impacted aspects include not only the application performance in terms of running time or delay, but also the battery lifetime and development effort. Thus, the offloading decision plays a key role to guarantee the offloading benefits. For the different situations, the offloading decision may be different. Various offloading decision models are discussed in Chapter 5.
Mobile devices consume cloud data
Many systems collect huge amounts of data from the users and store them in the clouds or datacenters. For example, Twitter.com puts all the data in its datacenters; Uber.com collects the cars' and drivers' information and stores it in its clouds. The operations on these huge datasets cannot be done in the mobile devices. If a user would like to search a topic or search the nearby available cab cars, the users' requests are sent to the clouds to calculate on the dataset. In other words, the computation happens where the data is. If the mobile applications would like to compute based on the data that are only available in the clouds or moving the raw data to the mobile devices to compute is too expensive, mobile applications have to consume the data in the clouds, which can be named “data as a service.”
A system implementing “Data as a Service” usually evolves from large data store systems. One typical example is Hadoop project. The Hadoop project provides a data store named HDFS (Hadoop Distributed File System) which can host very large amount of data on disks in clouds. Besides data hosting, Hadoop provides the Map-Reduce operations on the data to compute the user queries. Let's discuss an example of a user searching for a topic on tweets implemented using Hadoop. The users' tweets are collected and stored in the HDFS in the clouds, and the tweets are processed to build Inverted Index. Both the tweets content and the indexes are stored in the HDFS. When a user wants to search a key word, the request goes to the cloud and follows the indexes to fetch the query results.
Mobile devices composite cloud services
The cloud provides containers for the mobile application to run the offloaded code. However, if we put common codes or services are available in the clouds already, the mobile applications will not have to transfer the computation code. Moreover, the mobile applications may compose the available services in the cloud to form the specific services they would like. The mobile applications may consume the complex service composed from simple common cloud services in a flexible way.
In summary, MaaSC examples include mobile devices consuming VM resources, cloud data, and composing cloud services. They can be differentiated by the services the cloud provides to mobiles:
1. A mobile consumes VM resources and the cloud provides containers or surrogates;
2. A mobile consumes cloud data and the cloud provides containers and data;
3. A mobile composes cloud services and the cloud provides containers and codes or services.
3.3.2 Mobile as a Service Provider
Mobile as a Service Provider (MaaSP) is different from MaaSC in that the role of a mobile device is shifted from a service consumer to a service provider. For example, with on-board sensors, i.e., GPS module, camera, gyroscope, etc., mobile devices are able to sense data from the devices and their neighboring environment, and further provide sensing services to other mobile devices through the cloud. Consumers receive services provided by both the cloud and mobile devices. The types of services provided by mobile devices are diverse based on their sensing and processing capabilities.
Mobile provides location
Location as a service is one of emerging MaaSP service model. As one of the most typical services in MCC, it highly relies on Location-Based Services (LBS), which make use of the geographical position of a mobile device, have the advantages of both user mobility and cloud resources in MCC. These services gain user's current position by utilizing GPS, and provide various location-related services. However, experiments show that GPS only allows continuously working for 9 hours on smartphones, which indicates that saving energy costs in mobile location sensing is a significant issue [268].
The locating technologies used today mainly include GPS, WiFi, and GSM. Each of these technologies can vary widely in energy consumption and localization accuracy. Experiments have shown that GPS is able to run continuously for 9 hours only, while WiFi and GSM can be sustained for 40 and 60 hours, respectively. At the same time, the corresponding localization accuracies are about 10, 40, and 400 m. Most LBAs prefer GPS for their accuracy although it is perceived as extremely power-hungry. What is worse, phones currently only offer a black box interface to the GPS for the request of location estimates, and the lack of sensor control makes energy consumption even more inefficient. Additionally, many LBAs require continuous localization over reasonably long time scales. Therefore, energy-efficient location sensing methods must be adopted to obtain accurate position information while expending minimal energy.
Dynamic tracking.
The basic idea of dynamic tracking is attempting to minimize the frequency of position updates by only sampling positions (generally with GPS) when the estimated uncertainty in position exceeds the accuracy threshold [268].
This process obtains a GPS position and then uses a certain method to determine the user state (i.e., whether the device is moving or not). If the device is not moving, the logic waits for movement. When it is moving, the speed of the device is determined. Then a scheduling plan of sensors and radio is calculated with some principles included to minimize power consumption. When the estimated uncertainty in position exceeds the accuracy threshold, the process restarts and samples the next GPS position. In this process, the methods of movement detection, velocity estimation, and scheduling principles can be very different.
Trajectory simplification.
Trajectory simplification has been proposed as a means to reduce data size and communication costs caused by sending motion information. It is used for applications which need trajectory information instead of a single position [268].
The basic idea of trajectory simplification is to use a smaller subset of obtained positions, one which is minimal in size while still reflecting the overall motion information. In EnTracked [165], trajectory simplification is viewed as a special case of line simplification (which has been thoroughly discussed in the computational geometry community).
Mobile provides sensor data
Sensor as a service is another emerging MaaSP service model. Present mobile devices such as smart phones carry various sensors such as fingerprint sensor, accelerometer, gyroscope, barometer, proximity sensor, ambient light sensor, and hall sensor. These sensors profile the device environment or the user environment for smart phone. The device environment profile is very important for context-based or user-based applications. Besides, the device environment is also very important for cloud applications. In this model, the mobile devices or smart phones work as service providers, which expose their sensing function to the cloud.
The cloud can build a virtual mirror world by the device environment profile. A virtual mirror world enables a new cloud mobile application scheme, which is a mirror-synchronization scheme. The mirror-synchronization scheme works in three steps as its name indicates. First, the mobile device senses the environment and sends the environment profile to the cloud. The cloud builds the virtual world by the profile. Second, the cloud application aggregates lots of small mirror virtual worlds into one big world, based on which many applications can run. Third, in return for the mobile device sensing profile data, the cloud provides the application for the mobile devices. Due to the aggregation of small mirror virtual worlds in the cloud, the mobile devices actually use the data from other mobile devices and the cloud computation power. Both the mobile device and cloud benefit in the mirror-synchronization scheme.
Mobile Health
There is substantial enthusiasm for the concept of mobile health (mHealth), a broad term typically used to describe the use of mobile telecommunication technologies for the delivery of health care and in support of wellness. In 2011, US Secretary of Health and Human Services Kathleen Sebelius referred to mHealth as “the biggest technology breakthrough of our time” and maintained that its use would “address our greatest national challenge.” This level of exuberance for mHealth is driven by the convergence of three powerful forces. The first is the unsustainability of current health care spending and the recognition of the need for disruptive solutions. The second is the rapid and ongoing growth in wireless connectivity – there now are more than 3.2 billion unique mobile users worldwide – and this brings about a remarkable capability for the bidirectional instantaneous transfer of information. The third is the need for more precise and individualized medicine; a refinement in phenotypes that mandates novel, personal data streams well beyond the occasional vital sign or laboratory data available through intermittent clinic visits [256].
More and more mobile applications are developed to help us monitor our health. A typical mobile health application monitors our body activities through phone sensors, for example, location and speed to estimate the calories burned during exercises, and send the data to the cloud servers for analysis. The mobile provides the monitoring as a service, which helps the doctors diagnose.
3.3.3 Mobile as a Service Broker
Mobile as a Service Broker (MaaSB) can be considered as an extension of MaaSP. MaaSB provides additional networking and data forwarding services for other mobile devices. For example, MaaSB is useful when mobile devices have limited sensing capability compared to sensors that are dedicated for specially designed functionalities and sensing locations. A mobile phone can be used to collect users' physical activities from wearable devices such as Nike Fuelband, in which mobile devices and wireless sensors can be added to the cloud edge through the MaaSB service model. In this way, a mobile device can be configured as a proxy through various communication approaches and the proxy device can also provide security and privacy protections to MaaSB consumers.
Mobile web caching
A mobile ad hoc network enables a mobile device to fetch web information through another mobile device. Since some mobile devices may have better connection to the base station or WiFi hot-spot and have already downloaded the web pages that the other mobile devices are interested, the other mobile devices may directly access the cached web information from this relay node. The mobile devices may communicate through direct communication channel rather than through the far connection to the remote Internet cloud. One copy of cached web pages may benefit all the other mobile devices.
Vehicular cloud
The vehicles on the road may form local small vehicular cloud, which consists of a group of cars, buses, and trucks. The buses and big trucks may carry the network endpoint devices to enable them as network access point such as WiFi hot-spot. The other cars may access the WiFi endpoint on the buses for the Internet information. Since the buses and big trucks can carry lots of devices and they usually keep regular routines, the network coverage and network signal should be predictable and stable, so that the cars nearby can have good connection to them.
A platoon of vehicles may collaborate to provide information for each other. For example, the vehicles at the head of the platoon may provide the road condition information to the vehicles at the end of the platoon. Some vehicle may be elected as relay node for the communication in the platoon, which is also a form of mobile as a service broker.
Relay as a Service
Sometimes the service consumer and service provider are separated due to the communication limitation. The mobile devices can help to broker service binding through communication relay. Ad hoc mobile wireless networks are examples for “relay as a service.” Ad hoc networks are deployed in situations where no base station is available and a network has to be built impromptu. Since there is no wired backbone, each host is a router and a packet forwarder. Each node may be mobile, and topology changes frequently and unpredictably. Routing protocol development has received much attention because of mobility management. And efficient bandwidth and power usage are critical in ad hoc networks [178].
3.3.4 Summary of Mobile Cloud Services
The mobile devices, such as smart phones, are more and more popular. These devices are becoming powerful and carrying more sensors, so they become good candidates to collect environment data as well as to be a computation platform. The mobile clouds eventually serve users. As the bridge between users and resources or clouds, the mobile devices can be service providers for clouds to collect data, or be service consumers to delegate the tasks to the cloud, or connect the other service providers and consumers. The flexible role of the mobile devices leads to the various roles in the mobile cloud service model.
3.4 IoT and Microservices
The Internet of Things (IoT) has connected an incredible diversity of devices in novel ways, which has enabled exciting new services and opportunities. As figure in page 1 shows, we are at the age when IoT are booming. Prior success with traditional approaches in no way guarantees that we shall be as successful in using the same techniques to build the future IoT system we desire. Instead of focusing on the things as the atomic elements in systems, we argue it can be beneficial to follow the service-oriented approach and conceive IoT systems as being built out of services. Any IoT node can be abstracted as a smart object providing certain services over the network, and the focus of developers can be raised to the level of data and services rather than on the devices and end-to-end communication.
3.4.1 From Things to Distributed Microservices
The way in which cloud computing and web service applications are engineered – the techniques and technologies used – have changed substantially since the invention of the Web less than three decades ago, and recently one approach known as “microservice architecture” [261] has gained some notable adherents, including Netflix, Linkedin, and Amazon [262].
A microservice is a minimal functional software module which is independently developed and deployed. A microservice architecture is a composition of microservices that are deployed and connected through composition mechanisms. Desirable characteristics of microservice-based systems include: decomposition of larger services into small, focused, self-contained services, loose coupling, and clear execution context boundaries. Due to these characteristics, microservices can often be deployed inside portable lightweight execution environments called containers. Even the services of cloud infrastructure itself can be developed and deployed in this way [156]. Much of the excitement from switching to a microservices approach comes from their promise for improvements to system and process qualities: improved alignment of system structures to teams and business, easier integration of software components using heterogeneous technologies, easier system evolution, simplified continuous delivery, and improved resilience, and scalability [100][214].
3.4.2 Microservices Patterns for IoT
We wish to work towards a vision future in which we are able to efficiently develop IoT systems that are extremely interoperable, flexible, and secure. The structure of the vision consists of a high-level, abstract model of general microservices-based IoT systems, together with patterns of solutions that one might expect to see employed in the design and deployment of any given IoT system following the vision.
Fig. 3.3 shows a visualization of the overall abstract model of IoT systems using microservices patterns. We focus on the two major patterns, microservices and API gateway, in the vision of microservices-focused IoT solutions in the following subsections.
Microservices
We take “microservices”-based IoT systems to be composed of one or more individual self-contained and independent deployable software components, i.e., microservices interacting with each other by messages abstracted as method calls (e.g., web service call, or message RPC), or through publishing/subscribing events.
From the service consumer's point of view, a microservice is nothing but a collection of APIs. To make it easier to discuss the organization of these APIs, we propose an abstract model of the internal structure of a microservice, which can be mapped onto various protocols such as MQTT [254], CoAP [242], AMQP [253], or REST API. In our model, a microservice contains one or more virtual objects, which we take to be akin to objects in object oriented programming (OOP) languages. A virtual object can have two types of service APIs: methods, or event channels. Methods resemble the methods in OOP languages or services in REST APIs: they provide a remote procedure call (RPC). Event channels implements a publisher–subscriber model such that anyone that subscribes to the event channel will be notified when an event is published by an event producer.
Sensors and devices with sensing capability are examples of what might typically be an event producer. The events they publish might usually be intermittent, and their traffic is normally a push style. Actuators and services in the cloud are examples of event consumers and method providers (callee). They are typically continuously online, and their traffic style is typically that of request-response. It may be that one event or method call might generate a cascade of additional events or method calls. A method that does not return anything can be used as an event consumer as long as the method and the event channel is compatible in data format as well as semantics. Virtual objects, event channels and methods can be dynamically created by a microservice.
API Gateway
An API gateway is an interface that relays calls or requests between two or more microservices. API gateways can aggregate the APIs for multiple microservices into one client interface, and can also distribute or route the calls or requests from one entry point to multiple target microservices. Rather than allowing direct communication among microservices, an API gateway can be placed in-between them, which can have the effect of adjusting interconnectivity through the aggregation and distribution function of the gateway. Microservice connection is then established through registration; when a microservice registers itself to an API gateway, it creates one or more endpoints with unique identity, which can be further bound to an event channel or method through static configuration or dynamic negotiation with the API gateway. Besides the microservices, any user or machine client can also be required to present its identity as a name of identifier to interact with the API gateway to access its associated microservices. The identity management and authentication service might leverage existing systems that managing accounts, such as single-sign-on (SSO) or OAuth [127].
From the API gateway's point of view, each endpoint is uniquely identifiable, where the identity may be represented as a unique name or just an identifier. Such endpoint name or identifier only exist in the model, and the API gateway implementation needs to map it into actual protocol, such as an URL in REST API or CoAP, a queue or exchange in AMQP, or a topic in MQTT. In a cloud-supported body weight management IoT system as described in the example above, the weight management plan virtual object can be mapped to REST resource URL on the cloud server, which runs the weight management and recommendation microservices, and the method as well as parameter format on this virtual object can be mapped to the HTTP methods. In typical uses of this approach, the method name is encoded in the JSON payload to AUGMENT the limited types of HTTP methods. Such mappings impose additional constraints on our model, such as requiring that consecutive method calls in a session must be “nonsticky.”