The Risks of Using SaaS – The Easy Way Isn’t Always the Best Way

In recent years there has been a movement towards software being provided “as a service” whether supplied free to induce users to buy/use other services/products or via a subscription model. The software provider usually gains through having a long term revenue stream. Companies gain easy access to ready-made and managed solutions to their problems. It all sounds perfect. However, there are risks in using Software as a Service (SaaS) that need to be understood and managed.

Creating an app or platform that integrates a 3rd party SaaS API ties you to that platform. If the platform is discontinued you have the complex task of re-writing to use the new API and migrating existing data. If there’s no similar alternative, you are faced with implementing the SaaS provided service for yourself.

Most SaaS providers are VC funded which means they tend to initially give away their APIs for free or at low cost to attract customers. Once shareholders start to want to see revenue, monthly fees increase. We are already seeing this with many beacon platform providers. Once Angel or VC funding runs out, platforms can disappear. A high profile example in the beacon ecosystem at the moment is Onyx.

The risks aren’t constrained to using VC funded companies’ services. Google has recently removed services related to the Physical Web.  They are about to deprecate Google Cloud Messaging (GCM) that’s used in thousands if not millions of apps.

So what can you do? The first thing is do your due diligence. Is the company providing the SaaS you are considering likely to be around for the lifetime of your project? Is the company (like Google) renowned for deprecating services? Do you really need all the SaaS functionality or could you make do with a simpler developed or open source solution? Might you be able to use the SaaS for a proof of concept or minimum viable product (MVP) and plan to move to a developed solution?

Read about Generic Beacons

Consider our Software Development Services

New EddystoneCMS

Some people want to use an Eddystone beacon to send out a message but they don’t have the technical ability or inclination to configure a URL shortener and set up a secure web page to serve the web address. We have also seen some customers having problems with public URL shorteners such as tiny.cc because when they are overloaded they take too long to respond, the Google Physical Web Proxy gives up and consequently the beacon doesn’t get detected.

Today, we announce EddystoneCMS, a new FREE site that creates a fast, short eddys.cc URL and a editable, secure (SSL) web page the title of which is used for the smartphone message making it easier, less expensive and more reliable than doing all this manually. The CMS creates a short URL that you put into the Eddystone beacon using the manufacturer app.

What’s more, EddystoneCMS also provides analytics and geographic information showing how many people have clicked on your beacon web address.

Signup

Who Controls Your Beacons?

One of our most popular FAQs is

“Which Beacons Don’t Require Registration/Login/Subscription to a Platform to Configure Them?”

Conversations with our customers are showing that people are starting to become wary of beacons that require online logins because:

  • They can’t be administered ‘in the field’ where there might be no connectivity
  • They can’t be easily used with other people’s platforms
  • They tie you into platform availability that you can’t control
  • They tie you into future changes of platform subscription model you can’t control

None of our beacons require you to register, login or subscribe to a proprietary platform to administer them. All can use stand-alone apps for configuration.

Beacons, IoT and Platforms

Our article on Beacon Proximity and Sensing for the Internet of Things (IoT) explains how beacons can become part of the Internet of Things. Most implementations need to use a server or cloud IoT platform. However, in working with clients we are seeing many problems with most of today’s commercial IoT platforms:

Cost – Many aren’t financially scalable in that costs escalate once the number of sensors and/or sensor reporting frequency is increased. Future costs are also unknown and unpredictable which is unacceptable for many organisations.

Continued Existence – It’s still early days for IoT and it’s not known if today’s platforms will be around for as long as the project.

Security – Some projects, particularly those with sensitive data, can’t be run on or through shared public servers, services or platforms.

Control – For some organisations, aspects such availability and reliability need to be controlled in-house.

Functionality – IoT is a nebulous concept covering many specialist areas and industries. It’s difficult for a given IoT platform to cater for all needs. It’s usually necessary to compromise on your required functionality. Many IoT platforms have limited alerts, analytics and dashboards because they have cater for the lowest common denominator and not provide industry specific features. Most cover this deficiency with the boast of an API that you can call from your extended systems. However, most organisations want just one system that will do the job.

A solution to these kinds of problem is the use of open source IoT platforms. The current and future costs are known, there’s full control and you are free to extend in any way you wish.

Newer platforms such as ThingsBoard offer data collection, processing, visualisation, and device management. In the case of ThingsBoard it offers a secure, scalable solution that uses a Cassandra database that’s well suited for storage and querying of time-series data while providing high availability and fault-tolerance. Having created our own ThingsBoard instance for customer trials, we have found it to be customisable via widgets, the rule engine and the plugin system.

Thingboard Dashboard Showing Sensor Beacons

Real Time Locating System (RTLS)
we implemented using ThingsBoard

If you need more help, consider our development services.

Google’s Proximity Beacon API

Most beacon platforms are fairly limited in that they are designed around retail marketing scenarios. If you are creating a non-retail marketing solution you might want to look into Google’s little publicised Proximity Beacon API. It allows you to register beacons and have arbitrary data, called attachments, associated with them. What’s more, it supports the registration of iBeacon as well as Eddystone beacons and you can use it free of charge.

The usual usecase is setup via Google’s console followed by update from apps detecting beacons. Android and iOS example are available.

It’s not always apps that are used to detect beacons. For example, you might have a single board computer such as the Raspberry Pi or Bluetooth-WiFi gateway detecting beacons and a web front end managing and monitoring the beacons. Google also provides example scripts that show how other entities can be used to register, list and filter beacons. Alternatively, other entities might even call these scripts.

The storing of arbitrary data allows the proximity Beacon API to be used for scenarios beyond retail marketing such as sensing with sensor beacons and real time locating (RTLS).

Which Beacons to Buy?

There’s a recent thought provoking post at Hotel Online, by Dr. Michael Arner is the Chief Technology Officer of RoamingAround, on How Do You Choose Which Beacons to Have Faith In? The article questions the merits of being tied in to a particular supplier’s hardware or software features.

The article gives the opinions:

“If you’re a beacon merchant, I suppose it’s great to have clients that are willing to shackle themselves to your super-special hardware, but if you’re the consumer, it’s usually best to avoid doing so when you can.”

“In reality, iOS and Android devices can both speak to both protocols and there are very few reasons why you shouldn’t be choosing a solution that’s beacon agnostic.”

On security:

“There exist beacons which maintain proprietary end-to-end encryption, and these should be purchased, in the very rare case they’re needed

On Customer service:

“multiply-source your vendors and then you’ll discover that the decisive factor ends up being not the device stats but the customer service”

Summarising the advice in the article, look beyond what’s being offered or promoted by vendors. They will always be promoting their unique selling points but those might not actually be the decisive factors for your project.