Integration

Six Months of Middleware You Do Not Have to Write

The Stall Happens in the Same Place Every Time

Sensors report by week three. The device platform, whether that is a low-power network server, a cellular IoT service or a broker on an edge box, is holding the data and answering queries. Everything up to that point went roughly to plan.

Then somebody has to get it into the cloud platform the rest of the business runs on, and this is where two quarters disappear. A team writes a service that subscribes to the device platform, reshapes the messages, authenticates to the cloud and publishes. It works. It also becomes a piece of production infrastructure nobody scoped: it needs monitoring, a deployment pipeline, someone on call for it, and an owner who understands both ends. Six months later the person who wrote it has moved teams and it is the least documented component in the system.

The native integrations exist to delete that service. Data flows from the device platform into Azure IoT Hub or AWS IoT Core using the cloud platform's own device protocol and its own management primitives, which means your cloud engineers work with device twins, routing rules and serverless functions rather than learning the packet formats of a radio protocol.

The expensive part of an IoT project is not hardware, it is engineering time. Every hour your cloud team spends learning a radio protocol is an hour not spent on the thing the data was collected for.

What the Bridge Actually Does

The mechanism is less exotic than the marketing implies, which is good news. Both cloud platforms speak MQTT with mutual TLS, and so does every device platform worth using. The bridge translates between two MQTT dialects and handles the credentials.

What makes it worth doing properly is that a real bridge carries traffic in both directions and keeps state in step. Messages travel up. Commands travel down, and on the way they have to be adapted to the reality of the device: a queued application message for a sleepy battery sensor that will not wake for twenty minutes, an immediate publish for a mains-powered one. A device joining the network for the first time has to create its identity in the cloud rather than arriving as an unrecognised sender. And status changes, battery level, signal quality, last seen, firmware version, need to land in whatever the cloud platform uses to represent device state.

That last part is where most hand-written bridges stop, and it is the part that makes the rest of the cloud tooling work. A fleet whose state is not reflected in the platform's device registry cannot be queried, grouped or managed with the platform's own tools, which was the reason for choosing the platform.

On Azure

Each device becomes a device identity in IoT Hub, and its twin holds both reported state and desired configuration. That symmetry is the useful bit: change a reporting interval in the twin and the device platform delivers it to the physical device at the next opportunity, without anyone writing a command path.

The Device Provisioning Service handles onboarding at fleet scale. A device added to the device platform provisions itself into IoT Hub with the right enrolment group, initial twin properties and routing assignment, which removes the portal clicking that does not survive contact with two thousand units.

Message routing then sends different data to different places based on twin metadata that the integration populates: device type, site, tenant. One hub serves a heterogeneous fleet with each device type's data flowing to its own pipeline, which is much cleaner than a single consumer with a switch statement in it.

Functions triggered by hub events do the processing without any compute to manage. A function decodes the payload, applies calibration offsets, checks thresholds and writes to storage, and it runs on each message rather than on a schedule.

On AWS

Devices map to Things with shadows reflecting their state, and the shadow's reported and desired documents play the same role as an Azure twin. Shadow deltas drive configuration changes back down through the device platform.

Fleet provisioning templates automate Thing creation: when a device appears, a provisioning hook creates the Thing, attaches the right policy, adds it to a Thing Group and initialises the shadow, with no console interaction.

Rules then connect directly to Lambda, DynamoDB, S3, SQS, SNS, Kinesis, Timestream and IoT Analytics with nothing in between. The path from sensor to storage is two hops: device platform to IoT Core, IoT Core to destination.

Thing Groups organise the fleet by site, type, customer or rollout phase, and Jobs push firmware, configuration or diagnostics to a group. Fleet indexing answers the operational questions across thousands of devices at once: everything with a battery below twenty percent, everything silent for a day, everything still on an old firmware build.

Payloads Are Where the Work Is

Battery devices send compact binary, because every byte costs airtime and energy. That is the right decision on the device and the wrong shape for anything downstream, so something has to decode it.

A codec per device type, with unit conversions included, is the whole of that job. A sensor transmits eleven bytes; your cloud receives an object with named fields and proper units. It is not difficult work, it is just work that has to be done once per device model and done correctly, because a scaling factor wrong by ten is a bug that produces plausible numbers for months.

Two things are worth insisting on. Keep the codecs in version control alongside everything else, not pasted into a console, because a decoder edited in a web form is a decoder nobody can review or roll back. And keep the raw payload in storage alongside the decoded values, because the first time a codec turns out to be wrong you will want to re-decode history rather than lose it.

Where the Native Route Is the Wrong One

This approach is not universally correct and it is worth naming the cases where I advise against it.

If the organisation has no existing cloud footprint, adopting one to receive sensor data is a large decision made for a small reason. A self-hosted pipeline is cheaper to run, has no per-message pricing, and keeps the data in one jurisdiction without an adequacy argument. Where the requirement is dashboards and alerts rather than integration with fifty other cloud services, the self-hosted data layer is the shorter path.

If data residency is a hard requirement rather than a preference, check the region availability of every service in the chain, not just the hub. It is common for the ingest to be available in-region and one of the analytics services not to be, which is discovered late and awkwardly.

And the per-message pricing needs a sanity check at your volume. It is genuinely cheap per message and a fleet sending a few million messages a month is a rounding error, but a dashboard polling an API thousands of times an hour is not, and cloud bills on IoT projects are usually surprising because of the query side rather than the ingest side.

Where I do recommend it without hesitation is when the business already runs on one of these platforms. Then the sensor data joining the same governance, the same identity model, the same backup regime and the same on-call rota is worth more than any efficiency you would gain by running something separate.

What I Provide

I build the bridge and the codecs, which is the specialised part, and then get out of the way. That means native integration between your device platform and IoT Hub or IoT Core, provisioning automation so a new device creates its own identity and twin, a decoder per device model in version control, and routing into whichever serverless or storage pipeline the data belongs in.

Everything arrives as code you own: the codecs, the infrastructure templates, and documentation of what talks to what. If your own team is building it, a review of the design is often better value than handing the work over: most of the rework that makes these projects overrun originates in the provisioning and payload layers, and both are cheap to get right on a whiteboard.

I am not replacing your cloud team. Once the data is in the hub, they build on it with the tools they already know, which was the entire point.