Why you should choose Connhex as a software developer
Being software developers, we enjoy building complex systems from scratch. If we get asked whether our team can build an IoT solution, we all have the same first thought:
Of course, we can! How hard can it be?
Our plan is roughly searching all of GitHub for the best open source projects we can assemble to our liking, creating a scalable architecture and starting to bang out lines of code. This is wonderful - it's one of the reasons why our job is great.
However, it's also easier said than done, as we discovered at our own expense.
We created this page to discuss when you should choose Connhex over building a complete IoT platform yourself, and why it is preferable than the alternatives available.
Why you should use Connhex instead of building it yourself
Building a cloud solution to collect data from remote devices is easy. Building a scalable IoT infrastructure, that must be the backbone of your connectivity solution for the next decade? Anything but that.
IoT crushes databases
All IoT use cases involve monitoring. Once your company decides to create a monitoring system, it will try to collect as many metrics as possible: this translates into a lot of pressure on your infrastructure's databases.
"We'll just scale and add as many replicas as needed", you might think: unfortunately, you'll soon run into budget constraints. The typical IoT business model consists of a free plan, plus additional services sold on top of it: however, all devices send all data - and the paid tier needs to cover costs for both.
You can optimize data retention, but you won't walk away from needing to extract every bit of efficiency from your database cluster. This is not to say you can't do it yourself, of course: just be aware of the fact that this is harder than it seems1 and plan accordingly.
The takeaway? Creating an effective storage layer is a lot of work: don't assume you can get away with just choosing a proper database technology and scaling it 2.
It's not just about building
The main difference between creating an IoT infrastructure and running it in production is this:
Building an IoT infrastructure is fun. Running one in production is stressful.
You'll be spending at least twice the time it takes to build it in follow-up activities: stress testing, validating, documenting for compliance and monitoring setup.
And this is just the first step: we spend the majority of our time ensuring everything runs smoothly.
Dealing with data involves regulations
An often overlooked aspect in dealing with data is compliance with different regulations.
It can't be reduced to a checkbox users tick: your company might need to defend architectural choices, even in non-regulated markets. By choosing Connhex, you get a leg up in compliance.
Your time is valuable
As much as we would like to do everything ourselves, we must keep an eye on opportunity costs.
Your time is probably better spent by applying your domain knowledge to solve your users' problems than monitoring disk usage, patching dependencies and being on call to guarantee a SLA to your customers.
Beware the requirements you're given
You can do everything right, yet still fail to deliver a performant infrastructure.
Requirements always evolve over time, devices manufactured over the years have their own quirks. No matter how well your architecture has been designed, the risk of finding yourself frantically adding if
statements all over the place is still there.
One of Connhex's biggest selling points is being currently deployed to serve a wide range of use cases: it will support both your current and future requirements.
Software projects take longer than expected
We have been developing Connhex for 3 years, with it being our main focus - and yes, we had access to all of GitHub too 😉 With the benefit of hindsight, our estimates were so off they were almost laughable.
By building on top of Connhex's APIs, you'll be drastically cutting down time to market for your company.
Why you should choose Connhex over the alternatives
We've seen why you should prefer Connhex to building an IoT infrastructure yourself. Now let's move on to comparing Connhex with the available alternatives, either composable services (e.g. AWS) or IoT platforms (e.g. Thingsboard).
State of the art
This point is more of a consideration than a comparison: we can't comment on the implementation of all IoT platforms, especially closed source ones - for obvious reasons.
Connhex is a state-of-the-art IoT platform, with services orchestrated through Kubernetes. It features a powerful ABAC policy service and a DSL for mapping between message formats. It provides incremental backup and rollback strategies, plus data management and cleanup utilities.
Head over to the docs to understand Connhex in detail, or get in touch anytime!
Flexibility and composability
We keep saying that Connhex is a complete IoT suite, not an IoT platform: it doesn't include the notion of plant
, for example.
You'll retain the maximum flexibility for building application logic on top of its services: for example, you can use Connhex Resources as an ORM dedicated to your use case. See the difference? Connhex gives you resources
instead of plants
, installations
or equipment
.
All services have been designed with a strong focus on composability. Connhex Rules Engine is not responsible for sending emails once a rule is triggered: that's delegated to Connhex Notifications, acting as a central bus for delivering notifications. Guess who's responsible for delivering exports produced by Connhex Exporter?
Connhex Edge features the same degree of composability: firmware functionality is split into services, communicating with each other through a pub/sub mechanism. This promotes code reuse and decoupling of tasks - making testing and debugging much easier.
Everything runs on your clusters
If you're using a SaaS solution, you're entirely reliant on the provider. This might be a non-issue, but it's worth mentioning: if you're selling a service to your customers, what happens if the provider shuts it down3?
With Connhex, everything is always running on your clusters - either cloud or on-premise. Many IoT vendors propose an on-premise version4 of their IoT platform, but Connhex is way better in this respect - simply because it has been architected especially for this purpose.
We have developed lots of internal tooling to support distributed Connhex instances: from deployment and versioning to updating and monitoring systems.
When you might consider building it yourself
We're nerds and hate being sold to. We couldn't say with a straight face that Connhex is a solution to all problems and want to be transparent about it: let's explore when it might make sense to build an IoT infrastructure from scratch, or buy an existing IoT platform 5.
You should probably go with an existing SaaS solution if you're just starting out, developing a PoC or only need to connect a few devices. If selling services on top of connected devices isn't a priority for your company, you should probably suggest subscribing to an IoT platform too. Budgets will typically be too small for doing great work.
Deciding whether you should build an IoT infrastructure yourself or not is trickier. If you choose Connhex, you still need to implement the business logic layer, plus all user facing apps: you might go the extra mile and implement everything yourself. This can make sense if your team is big enough, or if you have great in-house expertise. It's also challenging, so you'll be learning a lot. It's also a reasonable way to go if you're planning to offer a general-purpose IoT platform: if you want to compete with Thingsboard, just copying their work won't be sustainable - you'll be always lagging behind.
Why developers should choose Connhex
Think of Connhex as a set of APIs that handle the difficult IoT stuff for you - with the advantage keeping data entirely under your control.
As a software developer, you should choose Connhex if you:
- need to build domain-specific apps to support connected devices
- work in a dynamic environment, with always-evolving requirements
- have little experience running TB-scale databases in production
- value data ownership and want to preserve the flexibility of switching providers at any time
- don't have time to go through the testing, validation and compliance phases
- don't want to monitor and maintain general-purpose components of an IoT infrastructure
Ready to start connecting your devices? Go here to explore Connhex configurations. Still unsure? You can always reach out for any additional information: we'll be glad to hear from you!6
- Especially because if your stress testing doesn't replicate the production environment properly, you might find out architectural bottlenecks too late.↩
- If you're going to build it yourself, try to optimize both storage and retrieval: see here and here to see how we did it.↩
- Don't assume you're entirely safe by choosing big providers either - just ask Google IoT Core users.↩
- Read copy-pasted.↩
- We've already provided some general considerations for two case studies: read here and here.↩
- We know you won't do that - we wouldn't either. Here's the quick-start 😉↩