We have developed a best-practice architecture that has proven effective for many customers in meeting the requirements of modern IoT platforms. The development of IoT platforms often presents similar challenges, like the efficient processing and delivery of data generated by a wide range of devices. It must be received, processed and made available to surrounding systems. Our best-practice architecture addresses this challenge. It is suitable for projects of any scale and complexity in terms of user and device numbers, and has proven its worth in a wide range of demanding use cases.
Contents- The advantage of the cloud: scalability and efficiency
- Reach your goals faster with managed services and best-practice architecture
- Flexibility through modular components
- Focus on the ingest pipeline
- Architecture of the ingest pipeline
- Architectural components
- Implementation scenarios
- Conclusion
The advantage of the cloud: scalability and efficiency
The underlying architecture is independent of specific deployment scenarios and can be used with major cloud service providers (CSPs) offering a wide range of managed services, as well as with smaller CSPs and in on-premises environments. However, using the cloud offers significant advantages; services such as Azure Event Hub, for example, simplify the installation, configuration and operational processes considerably.
The associated higher costs and loss of flexibility are justified in many cases, particularly when the benefits of PaaS and SaaS services are taken into account: simplified scaling, faster deployment and easier maintenance. A potential vendor lock-in is deliberately accepted if it aligns with the customer’s cloud strategy.
Reach your goals faster with managed services and best-practice architecture
Our best-practice architecture enables a quick start, as the time-consuming process of designing a system architecture can be significantly shortened, or even eliminated altogether. PaaS and SaaS managed services act as ready-made building blocks for the architecture; they can be easily set up, thereby further accelerating progress in building an IoT platform. This means that the focus of the project can be shifted much earlier to the implementation of the components that deliver the greatest added value.
Flexibility through modular building blocks
Each abstract component of our architecture can be populated with different concrete implementations. In theory, these can be combined in any way, but certain implementation scenarios are encountered more frequently. Examples:
- Hyperscalers with a 100% focus on CSP SaaS
- Medium-sized CSP with managed K8S and open-source building blocks
- On-premises with 100% open source
These implementation scenarios can be quickly identified based on the requirements at hand and translated into suitable implementation strategies.
Focus on the ingest pipeline
In this article, we have focused on the ingest pipeline for IoT metrics and telemetry data. However, other mechanisms (commands / request–response, device management, on-boarding, provisioning, etc.) are also covered in our best-practice architecture and will be discussed in future articles.
Our experience shows that a well-thought-out architecture not only improves the efficiency and scalability of IoT solutions, but also lays the foundation for innovative developments.
Architecture of the ingest pipeline
The IoT platform’s ingest pipeline is a generic IoT data processing chain designed to receive, process, enrich and store data from a wide range of devices. Depending on the use case to be implemented, the platform stores this data in (time-series) databases, deposits it in a data lake or an archiving area, and/or forwards it to surrounding systems in near real time. In our experience, some of the sub-components of the ingest pipeline contain use-case-specific logic. However, many sub-components can be modelled in a completely generic manner. The figure below shows the best-practice architecture and the generic and use-case-specific sub-components of the platform it contains.

The ingest pipeline extends from the connected device to the storage layer. When implementing it, it has proved helpful to take the following general principles into account:
- Event streaming: messages arriving from devices are treated as a stream of events. The following three core elements play a key role in this process
-
- Kafka: forms the centre of the architecture and acts as the data and event hub.
- Stream Processing: enables the use of stream processing and streaming analytics frameworks to carry out further calculations.
- Specific functional building blocks: Event-oriented functions or services (usually stateless) that read data from a Kafka topic, process it and write it to another Kafka topic.
- Generic data: The data within the ingest pipeline is largely generic and can therefore be processed further regardless of the specific use case.
- Data sinks: Generic components that store data in a generic format in specific data sinks.
- Hot, Cold, Warm Paths: The processing chain essentially distinguishes between three processing paths, which primarily influence processing latency:
- Hot Path: Hot data is processed in near real time and made available with very low latency.
- Warm Path: Warm data is processed quickly and made available with relatively low latencies.
- Cold Path: Cold data is processed with a delay or in batches and is usually persisted in relatively slow storage. Read latencies in particular can be high here.
The table below explains the functions of the platform’s standard components:
|
Collection Layer |
Inbound endpoint to which the devices connect. It is usually located on the public internet and therefore requires highly secure connection mechanisms, as well as protection against common attack scenarios |
|
Transformation Layer |
Receives data in a device- or use-case-specific format and transforms it into a standardised, generic format |
|
Processing Layer |
Additional processing steps may take place here, which usually generate further data. Typically, the following occur here:
|
|
Storage Layer |
The Data Storage Layer connects various data sinks:
|
|
Query layer |
Access to data persisted in the storage layer for peripheral systems |
|
Visualisation layer |
|
|
Custom applications / portal |
Use-case-specific applications utilising IoT data |
|
Analytics layer |
Specific data analytics applications for in-depth data analysis, model building or similar tasks |
|
Operations Layer |
Includes the components relevant to the successful operation and further development of the IoT platform
|
Implementation scenarios
In practice, we have seen a wide range of different implementation scenarios. When making a selection, the client’s specific circumstances often play a key role, such as whether or not they have a cloud strategy, whether on-premises solutions are already in place, or whether they possess existing expertise in specific technologies. Essentially, we have repeatedly encountered the following basic implementation strategies:
- Hyperscaler CSPs (Azure, AWS, Google Cloud Platform) with extensive use of CSP-specific services (PaaS, SaaS):
This strategy is often chosen when the cloud strategy permits its use and the aim is to minimise management and operational costs. - Hyperscaler CSPs (Azure, AWS, Google Cloud Platform) used generically with K8S:
This strategy is employed when the cloud strategy permits it and greater flexibility is required in the selection of individual platform components, as there are very specific requirements for these. - Medium-sized CSPs: StackIt, Ionos, OVHCloud:
This strategy is frequently used when the cloud strategy requires the use of German providers for reasons of data sovereignty. - Hybrid solution: CSP with third-party managed services (Influx Cloud, TimeScale Cloud, Confluent Cloud)
This strategy offers greater flexibility in the choice of components when specific requirements can only be met by third-party managed services (e.g. an MQTT broker with full support for protocol version 5), and where, for example, management and operational costs need to be minimised. - On-premises & fully self-managed (generically with K8S)
This strategy is often used when there is no cloud strategy in place or when using the cloud is not possible.
In addition to the basic implementation strategy, the precise requirements for the IoT platform play a decisive role in the selection of suitable components. Requirements may include, for example:
- Ease of instantiation
- Sensitive (device) data that must be strictly segregated on a per-use-case basis
- The need to set up and take down new use cases quickly and frequently (fail-fast approach)
- Very high usage load (data volume) and number of devices
- Simple and rapid scalability, e.g. according to the time of day due to highly variable load periods / peak times or because of expected high growth.
- Integration of many diverse devices, device types or different manufacturers. The IoT platform acts as a central, standardising platform.
- Preferred location for data storage (Europe / America / China)
- and much more
Based on the basic strategy and the specific requirements, suitable components for the platform can ultimately be selected.
Architectural components
The table below shows a selection of technologies or services categorised by component type and management type. In principle, these components can be combined in any way (within certain limits).
|
Self-Managed |
CSP Managed |
Third-party managed |
|
|
K8S |
Rancher Vanilla K8s OpenShift |
Azure AKS AWS EKS etc. |
- |
|
Kafka |
Strimzi |
Azure EventHubs AWS MSK |
Confluent Cloud Aiven Kafka |
|
Kafka integration |
Kafka Connect |
AWS MSK Connect Azure Data Explorer (ingest) Azure Event Hubs Routing |
Confluent Kafka Connect Aiven Kafka Connect |
|
Collection Layer |
EMQX HiveMQ |
Azure IoT Hub AWS IoT Core |
HiveMQ Cloud |
|
Transformation Layer Processing Layer |
Spring Cloud Stream Services Microservices in various languages (Go, Rust, Java, Python, TypeScript) |
Azure Functions Azure App Services AWS Lambda AWS BeanStalk |
- |
|
Storage layer: Cold Path |
Min.io DeltaLake |
Azure Storage Accounts AWS S3 |
- |
|
Storage layer: Warm path |
Influx Timescale |
Amazon Timestream Azure Data Explorer |
Influx Cloud Timescale Cloud |
|
Storage Layer: Hot Path (Streaming Analytics) |
Apache Spark Apache Flink Kafka Streams |
Azure Databricks AWS EMR AWS Databricks |
Ververica Platform Databricks Platform |
|
Query Layer |
Proprietary API service |
Azure Data Explorer |
InfluxQL PromQL |
|
Visualisation layer |
Grafana Tableau |
Azure Power BI Azure Synapse Azure Managed Grafana AWS Managed Grafana AWS QuickSight |
Grafana Cloud Tableau Cloud |
|
Custom applications / portals |
In-house custom applications |
- |
- |
|
Analytics Layer |
Apache Spark Apache SuperSet Trino PrestoDB Jupyter / Zeppelin |
Azure ML AWS SageMaker |
- |
|
Operations |
Prometheus Grafana ELK Stack |
Azure Monitor / Application Insights AWS CloudWatch |
Instana Observability Dynatrace |
Conclusion
Building an IoT platform offers a highly diverse range of possible solutions. The best-practice architecture for the ingest pipeline presented here can be implemented in all the deployment scenarios shown. iteratec has had positive experience with the platform building blocks presented and can combine them in a highly customised manner to meet specific requirements. Implementation on one of the major CSPs naturally offers significant performance benefits.
The fact that an increasing number of companies now also have suitable cloud strategies in place to offer high-performance solutions in the cloud is demonstrated, for example, by the Azure-based implementation of a digitalised IoT solution (see SWM Insights on LinkedIn or IoT Solutions | SWM), in which iteratec colleagues were involved.

David Lane is a Principal Solution Architect and IoT specialist at iteratec. Drawing on his expertise in smart products, smart manufacturing and IoT security, he develops innovative and secure solutions for digital transformation. He uses his technical know-how and enthusiasm for the IoT to support companies in developing digital products or optimising manufacturing processes through bespoke, high-performance and scalable IoT platforms.

Andreas Strafner has been supporting our clients for many years as an experienced project manager and technical point of contact. His focus is on innovative IoT solutions – ranging from the development of comprehensive IoT platforms, through the implementation of specific IoT use cases and their integration into business processes, to the realisation of innovative business models and products.
Do you have any questions or need assistance?
You can find further information about the possibilities of digital twins for your business on our website. Please feel free to contact us.