0.022_iot-platform

Why the IoT Platform You Choose Matters Less Than You Think

Share:

Facebook Twitter Link

Clients often ask us if we’ve heard of the latest internet of things (IoT) platform, if we have experience developing for a new platform that’s caught their eye, or whether we recommend one platform over another. Their excitement is relatable: IoT is a quickly emerging field, and new solutions are constantly hitting the market as more companies, both established ones and startups, look to get their share of the action.

What Is an IoT Platform?

google-cloud-platform

One result of the rush in the IoT market is that the term, IoT Platform, has taken on a somewhat nebulous quality. It turns out people mean a lot of different things when they talk about IoT platforms, and so our first job is always figuring out exactly what our clients are looking for. 

Do they want something for device management that tracks devices and gives a log? Or is it something even more particular, like a server for managing certificates for public key infrastructure (PKI) or one that can push out over the air firmware updates?

Once we’re on the same page, we often find plenty of options at our disposal. The truth is that most of these IoT technologies do the same or similar things, and there’s no need to reinvent the wheel. Especially with larger cloud providers like Amazon Web Services (AWS) and Google Cloud Platform (GPC), we find similar IoT Core services alongside everything else we may need, such as databases, machine learning (ML) solutions, and more.

Essentially, we don’t believe it worth devoting a lot of time researching every different IoT platform because they’re nowhere near being the bottleneck in any system we build, both in terms of IoT application performance and development speed. Instead, we focus on building strategically mature IoT devices from a platform-agnostic perspective.  

Platform-Agnostic System Design

platform-agnostic-1

Depending on what IoT platform we choose, we’ll begin writing code to target it. While a certain amount of tight coupling is inevitable, we also employ development practices that work to decouple our IoT applications from the platform as much as possible. That way, if for whatever reason our client decides to switch cloud providers sometime down the line, we can minimize the pain of that migration.

One way that we do so is by writing code libraries that abstract away the proprietary elements of any given platform to create reusable programs that only need minor adjustments to switch from one cloud to another. For instance, since almost every IoT solution involves inter-device communication and sending collected data to the cloud, we use an MQTT publish/subscribe, aka pub/sub, library to quickly enable this feature while retaining a healthy degree of flexibility.

Another technology that helps us achieve this goal is Infrastructure as Code (IaC), which lets us automatically provision, deploy, and scale cloud architecture. Again, while a certain amount of this code will depend on the target platform, we can use tools like Terraform to make our IaC configuration files as universal as possible. 

There are two main takeaways here:

  • First, we do everything that we can to minimize cloud lock-in.
  • Second, we can mostly build the same thing no matter where we build it.

Sign up for our newsletter

Join 10,000+ subscribers to get the latest IoT development news delivered to your inbox.

Trade-Offs When Choosing IoT Platformsiot-platform-tradeoffs

All technical choices entail trade-offs, and IoT platforms are no different. In this case, the question that we need to ask is “what features do I want and how much time and money am I willing to devote to them?” Especially on the larger platforms like AWS and GCP, we can find most things that we need, ready to go out of the box.

However, some of these services require greater degrees of vendor lock-in. For instance, AWS IoT device shadows are a useful feature because they store a small bit of data about each IoT device’s state in the cloud so that other applications can access it, even if that device goes offline. While this is almost always helpful, employing it makes a project more tightly coupled with Amazon’s ecosystem.

We could build this feature from scratch, but it’s going to take a lot more developer hours than accessing what’s already there. In fact, all of these decisions exist on a spectrum. 

On the far side of the DIY route, it’s possible to provision your own servers in a private data center, use as much open source technology as possible, and write everything else from scratch. On the other end, we can leverage everything that a third-party platform offers and tie ourselves more closely with that platform.

Conclusion: Don't Sweat It

When it comes to picking an IoT platform, our job is to understand what our client wants and how to get there. Instead of spending a lot of time at the beginning of a project researching different platforms and assessing their trade-offs, we’ll make an initial assessment of our client’s priorities and start moving forward.

At the end of the day, all roads lead to Rome. No matter what platform we do end up choosing, the impact on the end result is small. What makes a project successful is how we can implement a functional product and how good of an idea it is, not the chosen platform.

Are you looking for a team that can help you deliver results on your IoT initiative? Contact the Very team today.