Ah I had misread. I had assumed you were referring just to the Mesh devices. Yes that is a very real risk indeed with cloud service provisioned devices. Electric Imp would be another candidate having this risk.
However, I believe with Particle you still have a work around with all their devices as I believe (but I could be mistaken) that they have documented alternatives for all hardware, should you need to reflash the device. So you can at least put in your own cloud service on their hardware at any stage. Not many cloud providers do that with their devices. In terms of ease of use, Particle still tops it, my opinion. Azure Sphere has too much IT methodology written into it, which isn't always suited for embedded environments IMHO.
Actually, what I said is strictly true "the risk of the cloud provider simply pulling the plug, leaving you with a(n almost) useless piece of hardware is very real". You might argue whether that risk materialised or not in the case of the Particle Mesh (i.e. whether the devices became useless, almost useless or still useful as a Circuit Python device) but the risk is very real. That is why Microsoft decided to guarantee that the Azure Sphere platform would remain supported for a specified number of years.
From a product management perspective, the problem with subscription service is that I don't know how to model the long term total cost of ownership. At best I might get a 3 or 5-year contract with a service provider. When the contract is up, or when we re-enter the negotiation stage, I cannot be certain of what the new cost will be. And I mean this in both directions. What if my volume is so high the current vendor cannot handle it? Or what if it was so low that I overpaid? How do we figure out the path forward?
And then, how do I calculate (or model) my switching costs?
"Yeah, keeping it in-house seems like a good idea."
You're right, this is beyond the local area so that made it much easier to decide. I'm thinking to offer it as a service, to permanently install in different sites, and then use the data to make improvements (initially manually with no electronic control, just sensors). Today very ancient logger designs (with no connectivity) are used for some measurements or troubleshooting, or to visit and take measurements at different times of the day, so it would be nice to reduce that. There are some existing offerings, I just think it's an area where there's some opportunity regardless. Your comments regarding security and value aspects of the cloud approach sound right to me too.
Shabaz, your HVAC monitoring solution would make a great case study.
In my view there are two actually elements to this. Firstly, there is the monitoring of course, which involves collecting data and the second is control, which involves intervention to say change operating mode or even change firmware.
If any of these requirements don't need to be outside the locality (i.e.local area network) then the cost of supplying hardware and software is so low these days and pretty reliable that I cannot see the requirement for pushing this application out to a cloud. However, as soon as you require any element of that application to be able to communicate with the outside world (even if it's dispatching an email) then I would argue that a cloud service, based on today's technology, is the more secure (and arguably the better value) option assuming no lock in and other contractual constraints. Technically, I know there are other options around such as secure tunnelling etc. but would argue that not suited in all cases.
So, the question, I think is being asked is whether you then buy an all-inclusive service for this purpose or build yourself on a platform of your choice. This is of course is not really a generic question as will depend on technical skill of individuals involved and the balance between development time and cost to get to the end result.
I agree with the comments from Nico and some others. Just to add some background on my thoughts around cloud versus local, it came from building and tested my first cloud service (it wasn't IoT). It was initially prototyped on a PC. Today a Pi would be suitable for that too. My service was for a retail store, and we considered all the options, running it on a server on a site, or at my home : ) or using a provider. In the end, the decision was unanimous (despite initial reservations from the customer - this was approx 8 years ago when many were wary of cloud for security reasons).
The cloud cost (just using IaaS at that time, which isn't always efficient) was ballpark $15 a month (actually it was free for a year), which the customer had no issue paying, I built it into the service cost. It eliminated me needing to open up ports and dealing with security issues and upgrades, and I didn't need to deal with any equipment failure. For any second customer (although I only had 1 customer!) there would be half the cost (almost - unless more resources are needed) if it is multi-tenanted.
For a home app initially using a cloud option can be perceived to make no sense, but if one day you want to turn it into a business connecting more devices, to me it seems it's better to to take the hit and experiment with a platform from a provider that will be there in ten years time (as opposed to using a smaller hobby provider), even if the learning curve is higher initially.
Not strictly true, as I believe in Particle's case they have provided options for alternative use. This is the benefit of open sourcing almost everything.
I forgot to add, those of us who have Particle Mesh devices will know that the risk of the cloud provider simply pulling the plug, leaving you with a(n almost) useless piece of hardware is very real.
To be fair, I should add that these services do make a lot of sense for startups needing to get off the ground quickly. These services also provide the crazy kind of scalability that could be hard to pull off with a small team.
I tend to roll my own because a) I already have web hosting for other reasons, so this piggy backs onto it for free, and b) I've been building things like this for many many years so a php script is super easy to throw together.
For those new to this, and without the web space available - I would still recommend learning to build it yourself, and maybe setting up a local server to host it. This can be easy on a Raspberry Pi, or you can install something on your regular computer.
Top Comments