Shortly after Compiuta was founded, we started bouncing around a few ideas regarding IoT platforms. We had analyzed, used and built quite a few of those and started asking ourselves what could be done in that space.

After a couple of weeks spent looking into it, we started to have a clearer picture in mind. This post shares our research, thoughts and consideration that sparked our interest in building Connhex.

The “make or buy” dilemma

Say you’re interested in an IoT platform. You’ll face a typical business choice between two alternatives: make or buy.

Buy: off-the-shelf solutions

The world is filled with IoT platforms. We counted 27 - then stopped researching, since we had reached the “too many” threshold.

Vendors typically offer one in two kinds of IoT platforms. For the sake of brevity, let’s name those all-in-one packages and composable services.

All-in-one packages

All-in-one packages, like the name suggests, offer everything. What follows is a brief list of the most common features:

• data collection: brokers (entities that allow the cloud to receive messages from devices on the field), message queues;
• data storage: databases;
• user management: authentication, user roles management;
• user interface: usually charts and widgets, easily configurable through drag and drop;
• data export in different formats;
• alarms and notifications: think of something like getting an email when a certain data point reaches a threshold.

Composable services

Composable services are specialized in offering one of the aforementioned points - and they do it very well. They are usually provided by a big vendor (think of Google, Amazon or Microsoft scale) in a hosted fashion: the provider is responsible for hosting, maintaining and scaling the service. Your job just becomes gluing together different services from the same provider, and you’ll automatically get a scalable platform. A notable exception is the user interface: composable services are “lower level” with respect to an all-in-one solution, and you’ll need to build one yourself.

The business model behind off-the-shelf solutions

All-in-one packages that are hosted in the cloud usually charge a monthly fee, offering different tiers based on the number of devices and traffic that each one of those produces. If they are hosted on-premise, a flat license is charged - but it is not that uncommon to have an additional per-device license.

Understanding how much using composable services costs is a nightmare. They charge by device and traffic generated, plus a flat fee for some managed services (looking at you, Kubernetes). The first problem is their pricing is really fine-grained, so relatively small differences in traffic can make a significant difference in your monthly bill. The second one is they offer heavy discounts based on a multitude of factors: it’s all good, until those discounts are lifted and you get to pay double the amount you used to.

Some of the pros of buying an IoT platform are:

• reduced time to market, especially if using all-in-one packages. It is typically just necessary to configure devices and create a ui through drag and drop;
• maintenance is not a problem for hosted solutions: the provider will manage the platform for you at no additional cost;
• practically unlimited scalability, especially if using composable services. Having “too many” connected devices won’t be a problem at Google’s scale.

There are also cons:

• vendor lock-in is real. No matter what the provider says, once you make a choice there’s no easy going back. Even if data portability is theoretically insured, migrating it translates into a pain in the neck. Using composable services from one provider means marrying it, since there’s no way of just “switching” services other than redoing the integration from scratch;
• their pricing can be obscure and they are not cost effective as soon as the number of connected devices starts growing;
• data ownership is a question mark for hosted all-in-one solutions: you are potentially giving a third party access to all of your data;
• all-in-one packages tend to be customizable, but still general purpose. They are hammers, and treat every application like a nail: this might not be the ideal solution for your needs.

Make: building a custom platform

The alternative is to build the platform yourself or have a consulting firm building it for you.

Building in-house

Building in-house has the advantage of having total control over what gets built and how it does. But it also has the disadvantage of being time consuming: internal resources need to be subtracted from other projects, assuming you already have an in-house cloud team. If not, you need to assemble a team knowledgeable on IoT technologies: there are different nuances to data collection and storage, and not knowing those may prove really costly.

Last but not least, the monitoring and maintenance of the platform is still on you.

Outsourcing

Outsourcing is a double-edged sword: the outcome will be entirely dependent on you choosing a partner properly. While it has the advantage of reducing time-to-market, you’re practically locked-in to that supplier, so it better be good. Otherwise, you’ll find yourself in this not-so-uncommon situation:

• the platform starts to get developed and, at first, everything seems to be going well;
• as the months go by, problems start to arise and the parties involved start to argue on what was included in the contract and what not;
• you somehow end up with a platform and a proposal for a “Support and maintenance” contract: this is where the supplier is going to have high profit margins;
• you try to find another supplier for maintaining and further developing the platform. This is quite tricky, since the vast majority of candidates will simply tell you that everything needs to be thrown away and recreated from scratch;
• your return on investment is low.

Incidentally, this is true for any outsourced piece of software, not only IoT platforms.

A custom platform is usually created either by piecing together managed services or by assembling open-source software projects. The first way of doing things has the same features of buying composable services, while packaging a robust system yourself means you need to know what you’re doing.

And do yourself a favour: don’t save pennies on stress tests and monitoring - it’s gonna bite you in the long run.

A short recap

Try to summarize some of the previous considerations and you’ll come up with a map similar to this one:

So, it all boils down to your needs:

• if you need an IoT platform just for a PoC or to satisfy generic needs - like having a cloud dashboard with your data - go with the “Buy” strategy without any question. The best solution will be to compare all-in-one packages and finding what suits you best;
• if you have millions of connected devices, and a big enough budget to allocate to assemble a great internal team, build the platform yourself. The winning strategy here will probably be a mix of open-source infrastructure and managed critical services (databases are usually a good candidate).

The missing piece

It looks like every case is covered, right? Not quite so.

If you are a small-to-medium sized business and don’t have an in-house IoT software team, but need a platform to support your products, you’re only left with investing a considerable amount of money upfront to outsource the development.

If you are a software house specialized in developing apps, and have no desire to dive deep into IoT protocols, you’re only left with either outsourcing or trying to piece together blocks of software outside your domain of expertise on your own.

If you have sensitive data that can’t be transferred to the cloud, you can’t easily buy a platform engineered from the ground up to be installed on your own servers: most of them are just a clone of their cloud counterpart.

And last but not least, if you need to gather information not just to show them on a good looking cockpit but to solve an actual business need by processing those data points, you have no choice but building everything or using a “retrofitted” all-in-one solution with the user interface removed.

This is where Connhex comes into play. It has been designed, engineered and validated to be a perfect fit for these use cases.

Do those represent just a small segment of the IoT market? Of course. But this is our way of delivering great products: focus on a narrow vertical and do one thing really well, then offer that product to the right audience without worrying about pleasing everybody.

Want to learn more about Connhex?

For the time being, you can take a look at Connhex’s website or contact us at connhex@compiuta.com.

We will shortly publish two additional chapters in the story of Connhex: make sure to subscribe to our newsletter below!