Cloud Architecture Guide

Building a smart connected product means making decisions about how data flows from your devices to your applications, and sometimes back again! Blues provides an integrated device-to-cloud system that handles the hard parts like wireless connectivity, secure data routing, device management, and fleet operations, so you can focus on delivering business value.

Blues Notehub is the cloud component of that system. This guide will help you understand how to architect your cloud infrastructure around Notehub as you're developing your prototype. You'll learn how to organize your devices at scale, route data to your application cloud, and control costs as you grow.

note

Key Takeaways

• Notehub securely routes data, manages devices and fleets, handles OTA firmware updates, and works uniformly across all wireless technologies (while you focus on building your product and delivering business value)
• Organize Notehub projects by product line and device fleets by deployment stage, customer, or geography
• Blues gives you tools to control costs with bundled data, event credits, and architecture choices that keep expenses predictable as you scale

In This Guide

This guide covers the key architectural decisions for building your cloud infrastructure around Blues Notehub:

• Notehub: The Cloud Side of the Blues Device-to-Cloud System: What Notehub handles and what you build.
• Project and Fleet Organization Strategy: How to structure projects, fleets, and device groupings for scale.
• Data Routing Architecture: Route types, event schema design, and filtering and transforming data.
• Your Application Cloud: Choosing a cloud platform, dashboards, and application logic.
• Data Lifecycle Management: Event retention, archival strategies, and data retention policies.
• Cost Modeling: Notehub event credits, application cloud costs, and cellular data optimization.
• Cloud Architecture Checklist: A planning and build checklist to verify before deploying devices.

Notehub: The Cloud Side of the Blues Device-to-Cloud System

Notehub is the cloud component of the Blues device-to-cloud system. Together with Notecard (the device side), it forms an integrated platform that handles connectivity, security, data routing, and device management so you don't have to build and maintain your own product backend.

What Notehub Handles

Notehub provides five core capabilities out of the box.

1. Secure, reliable, dynamic data routing delivers your device data to one or more cloud endpoints through pre-built integrations for popular platforms, plus general HTTP/HTTPS and MQTT support for any custom destination.
2. Device configuration lets you configure devices manually, in bulk, or through APIs—including environment variables that let you change device behavior remotely without firmware updates.
3. Reliable OTA firmware updates through Notecard Outboard Firmware Update let you update firmware on a device, sub-fleet, or fleet basis without building your own OTA infrastructure.
4. Device and fleet inspection gives you visibility into any connected device, sub-fleet, or fleet including health, connectivity status, data usage, and session history.
5. Works uniformly across wireless technologies like cellular, satellite, LoRa, and WiFi. Your cloud architecture doesn't change when you change how your devices connect.

What You Build

With Notehub handling connectivity and device management, your engineering effort focuses on your hardware, your firmware, and the application logic that delivers business value to your customers. That means building the systems that turn device data into outcomes: the alerting that prevents downtime, the analytics that optimize energy usage, the dashboards that give your customers visibility into their operations, and the workflows that reduce truck rolls.

The point here is Blues lets you and your engineering team focus on what creates value for your customers, rather than on the infrastructure that connects devices to the cloud.

Project and Fleet Organization Strategy

As you plan your cloud architecture, one of the first decisions is how to organize your devices in Notehub. This matters more than it might seem at first as your project and fleet structure affects access control, firmware distribution, cost tracking, and ultimately your ability to deliver consistent business value as you scale.

ProductUID Planning

Every Notecard connects to Notehub using a ProductUID, a unique identifier for a Notehub project that is assigned to one or more devices. ProductUIDs follow a reverse domain notation format like com.your-company.product-name:identifier. You define ProductUIDs in Notehub and assign them in your firmware or during a provisioning process, and they determine which project receives your device's data.

Most companies use one project per product line. For example, if you manufacture both indoor air quality monitors and outdoor weather stations, those are likely separate Notehub projects with separate ProductUIDs. This separation gives you independent fleet management, access controls, and billing visibility for each product.

That said, there are cases where consolidating makes sense—for example, if multiple product lines share significant cloud infrastructure and you want unified billing visibility across a portfolio. Evaluate the trade-off between operational simplicity and the isolation that separate projects provide.

For development, staging, and production environments, we strongly recommend separate projects (e.g., product-dev, product-staging, product-prod). Separate projects give you complete isolation of routes, settings, access controls, and billing, ensuring that development activity never affects your production monitoring or data pipelines. This is especially important once your deployment grows beyond a handful of devices, where the cost of a misconfiguration reaching production devices can be significant.

A single project with fleet-based environment separation can work for very early prototyping with a small number of devices, but plan to migrate to separate projects before you enter a pilot phase.

Fleet Organization Patterns

Fleets are logical groups of devices within a Notehub project. Every project starts with a default fleet that acts as a landing zone for newly connected devices. From there, you organize devices into fleets based on your operational needs.

Organizing by deployment stage is common during product development: create fleets like "Alpha", "Beta", and "Production" to manage devices at different maturity levels. This lets you push firmware updates to small groups before broader rollouts.

Organizing by customer or site works well for B2B products where you want to segment data and configurations: "Customer-Acme", "Customer-BigCorp", or "Site-Chicago", "Site-Seattle". Fleet-level environment variables let you customize device behavior per customer without firmware changes.

Organizing by device status helps with operational management: "Operational", "Requires Attention", "In Repair", "Decommissioned". As devices move through their lifecycle, moving them between fleets keeps your operational dashboard clean. (See the Smart Fleets section below for more information on automating fleet assignments!)

Organizing by geography supports regional differences in configuration or compliance: "North America", "EMEA", "APAC". Different regions might have different features, sync frequencies, cellular carriers, or data routing requirements.

The key is choosing a fleet management structure that aligns with how you're planning to operate at scale.

Smart Fleets for Automatic Organization

Smart Fleets automate device organization based on the data devices send. Instead of manually assigning devices to fleets, you define rules using JSONata expressions that evaluate each incoming event.

For example, you might automatically move devices to a "High Temperature" fleet when their sensor readings exceed a threshold, or group devices by geographic region based on their locations. Smart Fleets evaluate rules against every incoming event, so devices can move between fleets dynamically as conditions change.

This can be incredibly powerful for operational monitoring. A rule like "move to 'Requires Attention' fleet if battery voltage drops below 3.2V" ensures devices needing maintenance surface automatically, without manual monitoring.

Watchdog Events for Device Health

Watchdog events notify you when a device has been inactive for a specified period. Configure a watchdog interval on any fleet, and Notehub will automatically publish events to the _watchdog.qo Notefile when devices go silent.

This is essential for protecting the business value your connected product delivers. Devices may stop communicating for many reasons like power failures, connectivity issues, firmware crashes, or physical damage. Without watchdog alerts, you might not discover a problem until a customer complains, an SLA is missed, or data gaps undermine the downtime prevention, safety monitoring, or loss prevention capabilities your customers depend on.

Watchdog events can be routed by Notehub like any other event, so you can send them to Slack for team notifications, trigger automated support tickets, or feed them into your monitoring dashboard.

Data Routing Architecture

Routes are how data flows from Notehub to your cloud application. Each project can have multiple routes, and a single event can be sent to multiple cloud destinations simultaneously.

Route Types and When to Use Each

Notehub can route data to any cloud destination. Pre-built integrations make it easy to connect to popular platforms, while general HTTP/HTTPS and MQTT routes support any custom endpoint. Here are some of the available route types:

For most products, start routing data to the cloud you're already invested in and utilize an S3 Archive route for data backup. You can always add specialized routes as your architecture evolves.

Designing Your Event Schema

The structure of your JSON-based Notecard events (a.k.a. Notes) affects how easily you can route, process, and analyze data in your application cloud. Design your JSON event schema with future needs in mind.

1. Keep Notes self-contained. Each Note should include enough context to be useful on its own. Your application supplies the content for the JSON event and Notehub supplements with additional metadata.
2. Version your schema. Add a version field now (e.g., "version": 1.0) so your cloud systems can handle format changes gracefully in the future. When you add/change/delete fields, increment the version.
3. Use consistent field names. Try to standardize names across different Notes. For example, use temperature not sometimes temp and sometimes temperature_celsius!
4. Consider your cloud application storage. If you're routing Notecard data to a time-series database, structure Notes with that in mind. If you're routing to a data warehouse, consider how Notes will map to pre-existing table schemas.

Filtering and Transforming Data

Not every Note will go to every route you set up. Notehub lets you filter routes by Notefile (e.g. only route _temp.qo events) and by fleet (e.g. only route events from the "Production" fleet). This reduces noise in your application systems and can help you control costs.

You can further optimize your events in Notehub with JSONata transforms that let you reshape event data before routing. You might extract specific fields, rename keys to match your backend's expectations, or compute derived values. Transforms are most often applied at the route level but can also be applied project-wide for consistency.

Using placeholder variable substitution in routes lets you insert dynamic values into route configuration fields like URLs, headers, and/or payloads. For example, you can use [.device] to programmatically include the Notecard's unique DeviceUID, [.body.temp] to include a specific field value, or [$env_var_name] to include environment variables. This enables scenarios like routing data from different devices to different endpoints without creating separate routes.

Your Application Cloud

Notehub doesn't replace your cloud infrastructure, rather it securely routes data between your devices and the cloud platform where your application logic runs. Your choice of application cloud depends on your existing technology stack, team expertise, and the business value you're building toward.

Choosing a Cloud Platform

AWS, Azure, and Google Cloud all have IoT-specific services that integrate well with Notehub. If your team is already invested in one of these platforms, the path of least resistance is usually to stay within that ecosystem. Each has native Notehub route support.

Custom HTTP/MQTT backends (i.e. HTTP/MQTT-based servers or serverless functions) give you complete control but may require more development effort. Use the General HTTP/HTTPS or MQTT routes to send data to any endpoint you build or to any third-party that supports an HTTP or MQTT endpoint.

Third-party IoT platforms like Datacake, Initial State, Ubidots, and Qubitro offer pre-built dashboards and analytics if you want to avoid building your own. Notehub has direct integrations with several of these as well.

The right choice depends on your constraints. Building from scratch gives maximum flexibility but takes longer. Third-party platforms get you to market faster but may limit customization.

Dashboard and Visualization Options

Dashboards are one important component of delivering value. They give your customers and internal teams visibility into device data and the business outcomes your connected product enables.

Blues provides a variety of routing tutorials that walk engineers through syncing data with cloud applications and developing data visualizations.

If you're routing data to your own database, Grafana is a popular open-source option that connects to most databases and supports sophisticated visualizations. Many teams run Grafana alongside their time-series database.

Cloud-native tools like AWS QuickSight, Microsoft Power BI on Azure, or Google Looker Studio integrate well with their respective ecosystems and offer managed infrastructure.

Third-party IoT platforms like Datacake or Ubidots often include dashboards as part of their offerings, which can be the fastest path to visualizations if you're using one of Notehub's integrated partners.

Building custom dashboards from scratch with web frameworks like React or Vue gives you complete control over the user experience (but does require frontend development resources!).

Building Application Logic That Delivers Value

The primary objective of your application cloud is running the logic that turns device data into business outcomes. This is where the real value of your connected product lives. It's the code that generates downtime prevention alerts, makes truck roll decisions, optimizes energy usage, monitors for safety conditions, or detects loss patterns.

When planning your application logic, consider what processing needs to happen in real time (e.g. safety alerts) versus what can be batched (e.g., daily energy reports). Think about whether your customers need to interact with the data directly, or whether the value is delivered through automated actions. And plan for how your application logic will evolve as you learn from pilot deployments and customer feedback.

Data Lifecycle Management

As your deployment grows, data management becomes increasingly important. Plan for how data flows through your system and how long you retain it.

Event Retention in Notehub

Notehub retains events for 30 days on the Essentials plan. Enterprise plans offer extended retention periods, see Blues Pricing for details. During the retention window, you can view events in Notehub and query them via the Notehub API.

After 30 days, events are no longer available in Notehub. This means you need alternative storage if you require data retention beyond this window, which most production applications do.

Archival Strategies

The simplest approach is routing all events to cloud object storage like Amazon S3 or Azure Blob Storage. Notehub's S3 Archive route handles this automatically, organizing events into date-partitioned folders. This gives you a permanent record of all device data at low storage cost on AWS.

For more sophisticated needs, consider a data lake architecture where raw events land in object storage, then get processed and loaded into a data warehouse or analytics platform. This separates raw data retention from queryable, processed data.

Your remote data retention policies should balance compliance requirements, analytical needs, and storage costs. Some industries require years of data retention; others may only need months. Design your archival strategy around your specific requirements.

Cost Modeling

Understanding costs helps you make informed architecture decisions and avoid surprises as you scale.

Understanding Notehub Event Credits

Notehub uses an event credit system. One event credit is consumed each time a billable event is received by Notehub from a device. Events requested via the Notehub API and outbound routed events don't consume additional credits, only device-originated events count.

Every Notehub billing account on the Essentials plan is topped-up to 5,000 event credits per month automatically. This is enough for most prototyping and pilot deployments. Production deployments typically require purchasing additional credits, with volume pricing available.

To estimate monthly Notehub event credit usage, calculate: devices x events per device per day x 30 days. A device sending hourly sensor readings (24 events/day) consumes about 720 credits/month. Note that Notehub-created events (e.g. platform events) are not billable.

Estimating Application Cloud Costs

Beyond Notehub, consider costs for your application infrastructure in whatever cloud platform or provider you are using (e.g. AWS, Azure, Datacake, or Ubidots, and so on). Costs you may need to factor in include:

1. Data ingestion charges (API Gateway calls, function invocations) are typically based on request volume.
2. Data storage costs depend on how much data you retain and in what format.
3. Compute costs for processing and dashboards depend on your architecture.
4. Per device costs are common amongst IoT-specific platforms.

note

It's difficult to provide a general model that works across all cost categories and all cloud providers. Every cloud provider offers some type of calculator service to estimate your monthly costs.

Optimizing for Cellular Data

The vast majority of Blues-equipped smart connected devices communicate at some point over cellular networks. So, assuming you are deploying with at least some cellular-based Notecards, use of the bundled 500MB of data is something to be aware of.

Note templates optimize transmission of Notes by sending field definitions once, then only sending changed values. This is especially effective for periodic sensor readings where many fields stay constant.

Voltage-variable sync intervals balance power levels with syncing cadence. Does your application really need minute-by-minute updates, or would hourly suffice? Longer intervals mean fewer events and less power drawn.

Taking advantage of the ample flash storage available on Notecard allows for storing multiple Notes when real-time syncing isn't required. Instead of sending temperature every minute, accumulate readings and send hourly with 60 data points instead.

Consult the Blues guide on Data Usage Estimates to learn more.

Cloud Architecture Checklist

Before deploying devices, be sure to verify you've at least touched on, if not fully addressed, these architectural decisions.

Planning Phase

• ProductUID naming convention defined with clear structure for future products
• Fleet organization strategy documented based on your operational model
• Note JSON schema designed with versioning and cloud platform integrations in mind
• Application cloud platform selected with Notehub routes configured
• Data retention requirements defined with archival strategy in place
• Notehub and cloud platform cost projections calculated based on expected device volume and event frequency

Build Phase

• Notehub project(s) created with appropriate team access configured
• Routes configured and tested with test events flowing to all cloud endpoints successfully
• Cloud dashboard integrations verified with end-to-end data visibility
• Monitoring and alerting set up for route failures, disappearing devices, and unexpected data
• Cost projections validated against actual usage during pilot

Resources and Next Steps

With your cloud architecture planned, you're ready to continue building your connected product. The following resources provide deeper guidance on specific topics.

Blues Resources

• Notehub Walkthrough
• Routing Data with Notehub
• Smart Fleets
• Fleet Administrator's Guide
• Blues Pricing

Getting Help

If you have additional questions about cloud architecture for your Blues-based product:

• Post questions on the Blues Community Forum
• Contact Blues sales for enterprise-level support