The architectural decisions you make for the cloud-end of your IoT product will affect its success and profitability for years to come. So what should you consider beforehand?

1. Buy an all-in-one, or integrate components?

Do you want to buy an "all-in-one" solution such as Electric Imp or ARM's Pelion? These implement the device stack as well as the cloud stack. This may be a great solution if you're a traditional product company without deep technology capabilities getting into IoT for the first time, especially as a relatively low-investment way of dipping a toe in the water, though longer term you may want to think hard about the risks of handing over so much control to a third party. The advantage of going with the "components" route is that you can mix and match to find pieces that really fit your needs - and swap them out piecemeal in the future as the market evolves. 

2. Open source or buy as-a-service?

Assuming you do want to build your service from components, do you want to use open source components or buy in the components as-a-service? Maybe a mixture of the two?

Using open source is attractive in terms of control, but implies that you'll be taking on responsibility for the deployment and maintenance forever - it's towards the "build" end of the "build or buy" spectrum.

Using as-a-service components requires you to relinquish some control, but in return allows you to focus more on your USP and core business. Some open source components are also available as-a-service which could be the best of both worlds. 

3. Vendor selection

Assuming you decide to buy in components and integrate them yourself, you'll need to choose vendors for at least the major components:

• Hardware stack
• Communications network
• Cloud platform
• Cloud applications

4. The layers of cloud IoT 

Here is a helpful framework for understanding the levels of the as-a-service IoT hierarchy.

Infrastructure-as-a-service (IaaS):

The equivalent of renting PCs in the cloud - you don't have to worry about buying or maintaining the hardware, but you still have to acquire and maintain all the software on it. When the server crashes or the disk fills up it becomes your problem, so you'll need a 24/7 operations staff. You might install IoT components such as an open source MQTT broker on your cloud machines. This option can often look really cheap... until you factor in the people needed to build and run it. 

Platform-as-a-service (PaaS): 

This is a solution to that problem. If you want an MQTT broker as the core of your IoT service, you can just buy it as a service - no need to install or upgrade it, no operations to do, no disks to worry about, infinitely elastic, extremely elastic, and all security issues etc dealt with by experts. And the price is pretty reasonable too, because cloud providers offer even small customers basically the same "at scale" usage-based pricing as their large customers. 

As well as buying in your core platform as a PaaS, you can also buy added-value components on top, for example databases. These are still quite technical components, but again you're freed from the worry of having to install or maintain them, and elasticity comes for free.

Software-as-a-service (SaaS): 

Since Salesforce pretty much created this term almost 20 years ago, SaaS is all about human-facing applications and is the only layer many people are aware of. The layers below it in the pyramid do not result in anything that a normal human could use to do a job in the real world, but at the SaaS layer we finally discover finished applications that anyone can use, with carefully designed user interfaces optimised for specific tasks. 

You'll probably want to implement your own custom user-facing application for your specific product, and might even sell it to your customers as a SaaS. 

In order to run your product, you'll need another set of applications/tools too - for example, for customer support management or for operational analytics. These can also be bought as a SaaS.