Cloud computing as defined by the National Institute of Standards and Technology (NIST) is: “A model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”.
In Machine-to-Machine (M2M) applications, the ability to remotely monitor, collect, store, and visualize data is paramount. Clients today have the choice to build out their own back end server system and associated software elements, or look to a cloud-based system where much of the solution has been provided. Which solution is best depends on many factors including: core competency, complexity, capital investment, time to market and more.
Advantages of Cloud-Based Systems
The cloud offers a way for companies to pursue opportunities quickly and cost effectively. Before cloud services, software developers had to develop or buy, configure, and maintain their own servers and software applications. These activities can be outside the core competency of an OEM and distract from the core work of a company. The cloud provides the ability to deploy a cloud-based solution quickly and easily with little to no capital expenditure accelerating time to market.
Low start-up costs; there is no capital investment required. There is no need to purchase hardware servers, software, and licenses and no need to build a secure location or computer room and manage the system.
Cloud computing is described as a “pay as you go model,” meaning the system is always right-sized. You pay for what you use. Thisis a critical point when first starting out, or for a proof a concept. In a cloud solution, deploying a small number of devices for a proof of concept or demonstration does not require a capital expenditure of hardware and software. Also with a cloud solution, you can eliminate extensive software projects to write the data broker and other associated software elements when it is necessary to move data from the device to the servers and enterprise application
Cloud Computing Delivery Models
-
Infrastructure-As-A-Service (IaaS), Users utilize “fundamental computing resources” such as processing power, storage, networking components, or middleware. The consumer can control the operating system, storage, and deployed applications. IaaS customers are often companies with extensive IT expertise who desire access to computing power but don’t want to be responsible for installing or maintaining the hardware.
-
Platform-As-A-Service (PaaS) PaaS is a cloud-based platform companies can use to develop their custom application or write software that integrates with existing applications. The user controls the applications running within the environment (and possibly has some control over the hosting environment), but does not control
the operating system, hardware or network infrastructure that they are running on. PaaS is currently the smallest segment of the cloud computing market and is often used by established companies looking to outsource a piece of their infrastructure.
-
Software–As-A-Service (SaaS) The largest and most mature part of the delivery model within the cloud is an application, or suite of applications, that resides in the cloud instead of on a user’s hard drive or device. Google Maps, Salesforce.Com, and Shutterfly are examples of commonly used SaaS applications.
Cloud offerings share a few similarities across the previously outlined categories.
-
Customers rent them instead of buying them, shifting IT from a capital expense to an operating expense.
-
Vendors are responsible for everything “beneath the hood” – all the maintenance, administration, capacity planning, trouble- shooting, and backups.
-
It’s usually fast and easy to get more from the cloud – more storage from an IaaS vendor, the ability to handle more PaaS projects, or more seats for users of a SaaS application.
Selection Criteria for Cloud Platforms
There are many cloud solutions in the market today and deciding which solution is right will depend on your application needs and business goals. Here are a few selection criteria that will help you make the right choice.
Device API or Agent Code Size
Most, if not all, cloud solutions require a piece of software to be placed on the remote device. This Application Programming Interface (API) code snippet tells the device how to connect and interface with the cloud-based system. Seeking a cloud solution with the smallest footprint API that performs the desired functionality should be a goal. In a microcontroller, memory is the main driver to the overall cost of the microcontroller solution. Having to change your microcontroller to larger memory footprint to accommodate a bloated software API will drive the cost of your solution higher. Depending on the solution and vendor 40 lines of “C” code can accomplish the goal of sending data to a device platform.
Protocols Supported
XML is one protocol for moving data off a device to a cloud-based system. In general this is a suitable solution, however when trying to minimize the packet overhead and latency, XML is probably not
the most prudent choice. SNP, MQtt, GPRS, REST, UDP and other Transport Control Protocols (TCP) should be considered to provide better performance. If you are using a cellular link you will pay for every kilobyte of data, so choosing the right protocol will impact the total cost of ownership.
System Latency
Latency is another specification that needs to be keenly understood in the cloud-based solution. Applications vary, so what is real-time to one may be slow or fast to another. Test and measure the response time it takes for events to occur until it makes its way though the system and a response is generated to ensure it meets your application needs. Sub millisecond response is achievable today in cloud-based systems. Delays in the “seconds” range may be red flags around system performance.
Hardware Platform
Given the wealth of microcontroller and microprocessor options in the market today, working with a cloud vendor who can support your processor architecture is paramount. Having to change your processor architecture to accommodate a cloud choice will limit flexibility and make increase design time.
Long-Term Storage
The primary goal of collecting data from remote devices is to apply business intelligence and analytics to the data. In order to provide a long-term analysis on business process efficiency (for example five years), the field data needs to be stored and accessible. If your cloud solution does not offer long-term storage, you will need to provide a storage solution yourself or move the data to another cloud-based server solution (at additional expense, latency, and risk). Look for a vendor with a long-term storage option to simplify your solution.
Cost Models for Cloud Solutions
When discussing cost models simple is better. Within the industry there are as many pricing models as solutions, so you must be careful to understand exactly what you have to pay for.
Number of nodes/devices
The simplest method is being charged per month based on the number of nodes one wishes to communicate with. In this model, one is charged price times node quantity. Look for solutions where tiered pricing and discounts are possible based on deployment of more nodes. This is a service-related business and quantity matters in the pricing.
Data Usage
Some vendors require the amount of data sent/received to stay below a preset threshold. Look for a vendor who doesn’t charge extra for different tiers of data stored. Typically, telemetry data from an embedded system should be included at no extra cost to the user. Of course, if you are streaming 24 high definition cameras at 30 frames a second and need to store all the data for years, you can expect to pay more for this type of application.
API Calls
API calls occur when the application queries the system for information. Some vendors will limit the number of API calls per month (and charge extra per month based on the actual number). Look for unlimited API calls at no charge.
Transaction Costs
Some vendors may tack an additional charge per transaction, and require a minimum amount per month. Beware of these seemingly small charges that add up quickly and drive the cost of service up. Seek vendors with no transaction costs.
Service Level Agreement from Cloud Providers
A solid cloud vendor will provide you a Service Level Agreement (SLA) outlining the system uptime, mean time between failure, and offer credits should the system go down, etc. If there is no SLA, this is a red flag, and you should seek service elsewhere. Each application is unique and having access to the data 24/7 without interruption is paramount.
Every outage by a prominent cloud vendor receives a great deal of attention, but overall cloud reliability records with established providers are admirable and would be the envy of most on- premise operations. For example, Google’s Gmail service was available for 99.978% of 2010.
Arrow Machine-to-Machine Solutions
Arrow M2M Solutions’ wireless expertise, vast selection of products from world-class suppliers, unmatched M2M engineering support, comprehensive services, and renowned supply chain management capabilities support you from concept to production, at each step of your design cycle, maximizing efficiencies and streamlining your journey to market.