Docker containers and Kubernetes orchestration form the infrastructure backbone of every FSS Technology IoT cloud platform. While IoT devices generate data at the edge, the cloud backend that receives, processes, stores, and visualises that data must be scalable, reliable, and maintainable. Containerising backend services with Docker and orchestrating them with Kubernetes gives FSS clients platforms that scale horizontally to absorb traffic spikes, recover automatically from failures, deploy updates without downtime, and run identically in development, staging, and production environments. Since 2017, FSS has containerised every new backend service it builds — from MQTT brokers and telemetry ingest pipelines to REST APIs and React dashboards.
Docker: Consistent Environments from Laptop to Cloud
Containerisation of IoT Backend Services
A typical FSS IoT platform backend consists of multiple cooperating services: an MQTT broker (Eclipse Mosquitto or HiveMQ), a telemetry ingestion service (Node.js or Python), a REST API, a time-series database (InfluxDB or TimescaleDB), a relational database (PostgreSQL), a caching layer (Redis), and a dashboard frontend served by Nginx. Each service runs in its own Docker container, isolated from others with its own filesystem, network namespace, and process space. Docker Compose orchestrates multi-container development environments where a single docker-compose up command starts the entire platform stack on a developer’s laptop, identical in configuration to the production environment. This “works on my machine” problem — historically a major source of IoT backend defects — is eliminated when every developer and deployment environment runs the same container images.
Docker Images for Firmware Build Pipelines
FSS uses Docker not only for runtime services but also for firmware build environments. STM32 and ESP32 firmware requires specific compiler toolchain versions (arm-none-eabi-gcc, xtensa-esp32-elf-gcc) that are tedious to install and version-manage on developer workstations. FSS maintains Docker images with pinned firmware toolchain versions, enabling any developer to build firmware with a single Docker command without local toolchain installation. CI/CD pipelines use the same Docker images, guaranteeing that CI builds use exactly the toolchain version defined for the project — eliminating the “worked in CI but not locally” class of build defects.
Multi-Stage Builds for Production Images
FSS Node.js and Python service Docker images use multi-stage builds: a builder stage installs development dependencies and compiles TypeScript to JavaScript or runs Python packaging, and a production stage copies only the compiled output and production dependencies into a minimal base image. The resulting production images contain no build tools, source code, or development dependencies — reducing image size by 60-80% compared to naive builds and reducing the attack surface of production containers by excluding unnecessary software.
Kubernetes: Orchestrating IoT Platforms at Scale
Azure Kubernetes Service for FSS IoT Platforms
FSS deploys IoT platform backends on Azure Kubernetes Service (AKS), Microsoft’s managed Kubernetes offering. AKS abstracts the complexity of Kubernetes control plane management — etcd, API server, controller manager — while giving FSS full control over workload deployment, scaling policies, networking configuration, and secret management. An AKS cluster running an FSS IoT platform typically runs 3-10 node pools: a system node pool for Kubernetes infrastructure, application node pools for API and telemetry services, and a data node pool for stateful database workloads with premium SSD storage. Node pool autoscaling adjusts cluster capacity automatically based on CPU and memory utilisation, absorbing ingestion traffic spikes from large device fleets without over-provisioning.
Kubernetes Deployments and Rolling Updates
Kubernetes Deployment resources manage FSS backend service lifecycle: desired replica count, container image version, resource requests and limits, liveness and readiness probes. Rolling update strategy deploys new container image versions by gradually replacing old pods with new ones, maintaining service availability throughout the update process. Readiness probes prevent traffic routing to pods that have not yet completed startup — preventing the “503 flash” that occurs when a new container receives requests before its database connection pool is initialised. FSS defines Kubernetes resource requests and limits for all containers, preventing noisy neighbour problems where one misbehaving service monopolises node CPU or memory and degrades others.
Horizontal Pod Autoscaling for Telemetry Ingestion
IoT device fleets generate uneven telemetry loads: device activations after power outages cause ingestion spikes, scheduled reporting intervals create burst patterns, and industrial IoT devices may send high-frequency data during production hours and minimal data at night. Kubernetes Horizontal Pod Autoscaler (HPA) scales telemetry ingestion service replicas based on CPU utilisation or custom MQTT queue depth metrics, expanding capacity during load spikes and contracting during quiet periods to minimise cloud spend. FSS configures HPA with appropriate scale-up and scale-down cooldown periods, preventing thrashing where the autoscaler rapidly adds and removes pods in response to brief traffic fluctuations.
Kubernetes Secrets and ConfigMaps for IoT Platform Configuration
IoT platforms require extensive configuration: MQTT broker credentials, Azure IoT Hub connection strings, database passwords, API keys for third-party services, and per-environment settings. Kubernetes Secrets store sensitive credentials encrypted at rest in etcd, injected into containers as environment variables or mounted volumes at runtime — never embedded in container images or source code. ConfigMaps store non-sensitive configuration, enabling per-environment settings to be applied without rebuilding container images. FSS uses Azure Key Vault with the Secrets Store CSI Driver to synchronise secrets from Azure Key Vault into Kubernetes Secrets, ensuring a single authoritative secret store with full audit logging of all secret access.
Limitations and Considerations
Operational Complexity
Kubernetes introduces operational complexity — cluster management, networking, storage, RBAC, monitoring — that is not justified for small IoT platforms with modest scale requirements. FSS evaluates whether Kubernetes overhead is warranted for each project: small IoT platforms (under 1,000 devices) may run on Azure Container Apps or Docker Compose on a single VM, avoiding Kubernetes complexity while preserving containerisation benefits. Kubernetes becomes the right choice when platforms must scale beyond single-VM capacity, require zero-downtime deployments, or need sophisticated workload isolation between multiple client tenants.
Learning Curve for Client Teams
Clients who take over platform operation from FSS after initial delivery must invest in Kubernetes training for their operations teams. FSS mitigates this through comprehensive infrastructure documentation, GitOps configuration management (all Kubernetes manifests in version-controlled repositories), and optional FSS managed operations engagement where FSS continues to operate the platform post-delivery.
Docker and Kubernetes Use Cases at FSS
Multi-Tenant IoT Platform
AKS-hosted multi-tenant platform serving 15 industrial clients from isolated Kubernetes namespaces. Per-tenant MQTT broker instances, shared telemetry processing pipeline, tenant-isolated PostgreSQL schemas. HPA scales ingestion pods from 3 to 20 replicas during peak load.
Firmware Build System
Dockerised STM32 and ESP32 build environments in GitHub Actions CI. 4 hardware variants built in parallel Docker containers; signed firmware binaries published to Azure Blob Storage for OTA distribution.
Zero-Downtime Platform Updates
Kubernetes rolling update deploying new telemetry API version to production AKS cluster during active device operation. Readiness probes validate new pod health before traffic shifting; zero dropped MQTT messages during 8-minute deployment.
Development Environment Parity
Docker Compose stack replicating full production environment locally: Mosquitto MQTT broker, Node.js API, PostgreSQL + TimescaleDB, Redis, React dashboard. New developer onboarding time reduced from 2 days to 30 minutes.
Marine IoT Platform Scaling
Superyacht IoT platform on AKS: burst ingestion during fleet gatherings (50+ vessels simultaneously connected) handled by HPA scaling ingestion tier from 2 to 8 pods. Azure Cosmos DB absorbs write spikes without backend changes.
GitOps with Flux
All Kubernetes manifests managed in Git repository; Flux CD operator applies changes automatically on merge to main branch. Infrastructure changes are code-reviewed, audited, and reversible — the same engineering discipline applied to application code.
FSS Infrastructure Engineering
FSS Technology’s infrastructure engineers have designed and operated Docker and Kubernetes environments for IoT platforms since 2017. Our team holds Azure certifications, contributes to internal Helm chart libraries for common IoT platform components, and has accumulated hard-won operational knowledge from running production IoT platforms through traffic spikes, hardware failures, and major software updates. We bring this experience to every new platform project, ensuring that clients receive infrastructure that is not only functional on day one but maintainable and scalable for the years ahead. Contact FSS to discuss cloud infrastructure for your IoT platform.