Talk Recap: Kubernetes Saved My Grandma: High-Reliability IoT for Elderly Care at BaselOne 2026
On October 15, Linus Basig and I spoke at BaselOne 2026. At the speaker dinner I met really interesting speakers. The food was great too: instead of classic catering, we got coupons for the wide variety of food stands in the Markthalle.
The Talk in Short
CARU builds a home emergency system that lets elderly people keep living independently at home. When someone falls and calls for help, the call has to go through, day and night. Today the platform runs on AWS managed services, and it works well.
So why talk about leaving? Data protection law (GDPR, the revised Swiss nDPA), Switzerland’s digital strategy putting sovereignty at the top of the list, and sanctions that suddenly cut organizations off from their IT providers all raise the same question: what would a truly sovereign architecture look like for a system like this? As we said on stage: we are software architects planning for the future, not legal experts.
The talk is a thought experiment, not a migration report. Nothing has been moved yet. We went through the platform area by area (compute, event subsystem, fleet management, storage, monitoring and observability) and looked for open, foundation-governed replacements for each managed service. Some answers are clear, others are still open, and we said so on stage.
Key Takeaways
- Open source alone is not enough: look at who governs it. Elasticsearch, HashiCorp Vault, Terraform, Redis and MinIO all changed their license or their distribution in the last few years. Projects under a neutral foundation (CNCF, Linux Foundation, Apache, Eclipse) are much harder to close.
- Bet on open standards, APIs and protocols, not on products. If the interface is an open or widely adopted standard (OCI and Kubernetes, the S3 API, MQTT, OpenTelemetry, OpenID Connect), the product behind it becomes a deployment choice, and switching gets fast. APIs sit on different levels (application-level APIs, specifications, message formats, protocols) and range from vendor specific (Lambda) through de facto standards (S3 API, Kafka) and open specifications (OpenTelemetry, AsyncAPI, CloudEvents) to formalized standards (OpenID Connect, MQTT, HTTP). The more standardized the API, and the higher its level (application-level APIs at the top), the easier it is to swap the product behind it. How to design good APIs around your domain is the topic of the book Crafting Great APIs with Domain-Driven Design, which I wrote with Annegret Junker.
- Migrate in three steps: back up everything off-cloud as your safety net, get the abstractions right and move slowly, and prepare the escape with classical disaster recovery planning and rehearsals.
- Look at the system from two sides. The platform view (the technical areas below) is where you solve it once, with standards, for all capabilities. That was the focus of the talk. The capability view (emergency call, daily check-in, CO2, care partner portal, hydration reminder) is where you prioritize. What must work first, or only, after a switch? What can you drop before changing anything? Where do you start? Methods like the business model canvas and Wardley mapping help here. More on this in my talk Crafting Great APIs with Domain-Driven Design at Spring I/O 2026.
- Every area has its own answer:
- Compute: Kubernetes. Start on a managed Kubernetes such as EKS, still on AWS, move the first Lambda functions into pods, then scale.
- Event subsystem: still open. We defined criteria for an MQTT broker (an OSI open-source license, free for commercial use, real active/active clustering, retained messages that stay correct across the cluster, a small footprint, and a vendor-neutral foundation as tiebreaker) and a test suite to compare the candidates. The target: no data loss (RPO 0) when a single node dies. Three approaches are on the table: one broker for everything, Kafka with a protocol adapter, or keep it simple.
- Fleet management: none of the open candidates we looked at (Eclipse Ditto, Eclipse hawkBit, KubeEdge, ThingsBoard, Mender and others) covers device shadows, jobs, fleet indexing and groups with low operational overhead. For now the answer is DIY: CARU knows fleet management well, and most of the pieces are not that complicated.
- Storage: abstraction. A document store with simple CRUD, Kubernetes persistent volumes and the basic S3 API. The API stays, the product is a deployment choice.
- Monitoring and observability: OpenTelemetry, with the tools we already know that support it.
- Don’t forget the hard stuff. Key management (PKI), networking, DNS and cellular connections, operations and backups, certifications such as the BSI C5, DevOps know-how and new vendor relations. This is where the cost of freedom lies.
- Five steps to sovereignty, and repeat. First decide: do you need to be sovereign, how sovereign are you today (the BSI C3A criteria are a good start), and is the gap worth closing? Some of the gap is cheap to close (clear components, APIs, open standards), some is harder (training, DevOps, 24/7 operations). Then act: close the gap where needed, backups first, then open standards and well-sliced components. Go fully sovereign only if required, and don’t forget the people. Finally, validate regularly: restore your backups and run a disconnect test. Then start again from step 1: goals, constraints and the world around you change, and so does the answer.
Follow-up Articles
Linus Basig and I are writing deep dives on the topics from the talk, for example which MQTT broker to choose and why. Get them by email.
We will give the talk again at KCD Suisse Romande 2026 in Geneva in December and at OOP 2027 in Munich in February.
Links and Resources
- Slides (PDF)
- BaselOne 2026 program
- Linus Basig on LinkedIn
- CARU
- Book: Crafting Great APIs with Domain-Driven Design
Related Talks:
