LWN: Comments on "Bose and Kubernetes"

Bose and Kubernetes

nix — Tue, 19 Feb 2019 11:50:36 +0000

Being really pedantic, a cloud-based irrigation controller would presumably float in the cloud layer and produce irrigation by triggering rainfall. So yes, you're quite right! (I'm not sure where it gets the water from when the cloud isn't in place. Really long hoses that stretch all the way down to ground level? This modern technology, it's marvellous.)

Bose and Kubernetes

rahvin — Tue, 19 Feb 2019 00:00:29 +0000

But don't Irrigation controllers make rain?

Bose and Kubernetes

nix — Sun, 13 Jan 2019 13:09:34 +0000

I specifically bought the Rain Machine irrigation controller because it was cloud based, but continues to function without the cloud in place

This is such apt naming. An irrigation controller that only works when it's cloudy would be less than useful :P

Bose and Kubernetes

Wol — Thu, 10 Jan 2019 15:17:39 +0000

> where the core functionality of the device stops simply because some remote service is no longer available.

I don't know as I'm that unusual, but in my house the internet seems to fall over as a matter of course many evenings. Oh - I live in a major European capital - London ...

And I think the problem is the infrastructure outwith my house, so there's nothing I can do about it other than pay megabucks for an unwanted internet upgrade - I probably only use a fraction of what I'm paying for now ...

Cheers,
Wol

Bose and Kubernetes

robbe — Tue, 08 Jan 2019 14:58:03 +0000

It’s hard to understand their choices and issues unless you already know what their product/service offers.

Does their speaker get audio from a the Bose service, or is it just a rendezvous point to route commands (from Amazon or elsewhere) to the speaker? I assume the latter … the mind boggles at the technical effort burnt because the Internet lost end-to-end in the nineties.

Bose and Kubernetes

Cyberax — Fri, 04 Jan 2019 12:38:02 +0000

ZeroMQ by itself doesn’t do connection balancing or anything smart. It’s more like an advanced socket rather than a messaging system.

Bose and Kubernetes

zoobab — Fri, 04 Jan 2019 11:59:36 +0000

Did they evaluate ZeroMQ?

The malamute broker can handle lots of connections, unfortunately there is no MQTT support at the moment.

Bose and Kubernetes

excors — Thu, 03 Jan 2019 18:42:05 +0000

It seems the Alexa platform is designed to make Alexa devices relatively simple, so they can be cheap and ubiquitous. Anyone can use the Alexa Voice Service API (https://developer.amazon.com/docs/alexa-voice-service/api...) to add Alexa functionality to anything with a microphone and speaker and internet connection; you just send audio to Amazon's cloud service, and implement a few interfaces to play the returned audio etc. Since most of the logic is in the cloud, users get a reasonably consistent experience across all devices. Adding more device-side logic - like a reliable performant secure authenticated way for them to proxy commands to other non-Alexa devices on the local wifi network - has both the cost of implementing it on many devices, and the cost of confusing users when some features work on some Alexa devices and not on others.

Sometimes device-side logic might be worth the costs, like how some Echoes have Zigbee support to communicate with nearby IoT devices - otherwise the user would have to buy a separate internet-connected Zigbee hub, and nobody likes buying hubs (they're expensive and don't appear to do anything). But if the IoT device is already connected to the internet, like a smart speaker whose primary function is to stream music from the internet, it's not that hard for the manufacturer to provide their own cloud to send commands to their device. (If they don't want to implement it all themselves, they can buy the service from Amazon (https://aws.amazon.com/iot-core/) or probably Google or Microsoft or whoever). Then users will be happy their new smart speaker is compatible with even the oldest or dumbest Alexa devices.

That also means the manufacturer can add support for Google Home or Bixby etc with no device-side changes at all - they just connect their own cloud to the Google cloud etc, and the device should work exactly the same. So it's good for reducing vendor lock-in and allowing competition between voice assistants.

Bose and Kubernetes

jerojasro — Thu, 03 Jan 2019 13:37:34 +0000

> There is no direct interface between the two devices; it all must be handled in the cloud. So it takes hundreds of miles of cable to bridge the three-foot gap between the two devices on stage.

I feel like I'm missing something, but, it seems to me all of this kubernetes-massive-cluster effort is unnecessary, and they should just devise some scheme for delegating authority for certain commands to the user's alexa over the user's bose speaker, and then having the alexa authenticate and connect to the speaker via the local network.

Yes, it requires work on both the amazon and bose devices, but still...

Bose and Kubernetes

nilsmeyer — Thu, 03 Jan 2019 10:33:42 +0000

100% agree, especially since there seems to be no benefit to the user. Imagine buying a speaker and then having to sign up for another cloud service, sharing ever more of your personal data, then having it work only if the service is available, the speaker firmware is current and you have a working internet connection. What is the value proposition for the customer here?

Bose and Kubernetes

zdzichu — Thu, 03 Jan 2019 07:22:48 +0000

What's wrong with TLS support in Mosquitto itself?

Bose and Kubernetes

zdzichu — Thu, 03 Jan 2019 07:20:35 +0000

In general, networking in Kubernetes seem like a temporary solution promoted to production. K8s started with utilizing iptables' NAT rules. This came about 15 years (!!) after Linux world noticed that iptables is not suitable for highly dynamic environments and started to work on better solutions, like nf-hipac (https://lwn.net/Articles/10951/).

Only quite recently k8s gained support for using IPVS (Linux IP Virtual Server) for networking (https://www.youtube.com/watch?v=4-pawkiazEg, Scale Kubernetes to Support 50,000 Services [I] - Haibin Xie & Quinton Hoole).

It is suprising, for Linux-native container solution to skim over Linux networkinging progress. Over the course of history, kubernetes started with obsolete solution (iptables), ignored nftables, only started to utilize a solution devised in 2002 (ipvs)… but began to flirt with eBPF :-) https://kubernetes.io/blog/2017/12/using-ebpf-in-kubernetes/

Bose and Kubernetes

jaymell — Thu, 03 Jan 2019 06:18:09 +0000

Very nice write-up of the discussion. I found it interesting that Kubernetes 'services' (generally virtual IPs routed with iptables NAT'ing) ended up being discarded relatively quickly in the process of addressing bottlenecks. I have recently been dealing with scaling issues in a Kubernetes-based environment and hadn't seriously considered the bottlenecks the additional NAT'ing might be posing.

Bose and Kubernetes

Cyberax — Thu, 03 Jan 2019 03:28:07 +0000

> They are not quite more reliable than wifi exactly because all three use "free air" as a medium
ZWave and ZigBee have a much lower bitrate than WiFi so they are seriously more reliable, and they also can use sub-GHz bands that are not as polluted as the 2.4GHz WiFi band.

> any device can claim compliance but there are *ahem* versions eg Ikea Tradfri and Philips Hue (both claim to work with each other now - there are many others)
I have tested multiple ZigBee devices and so far they appear to interoperate just fine.

With ZWave it's not so much certification as the fact that there's only ONE manufacturer of ZWave chips. And these chips are based on Ye Olde Intel 8051. On the other hand, _all_ ZWave devices are compatible (even pre-ZWave-1.0 ones).

Bose and Kubernetes

gerdesj — Thu, 03 Jan 2019 00:48:53 +0000

I agree with Cyberax: avoid "cloud" for home IoT. For me all devices should have a manual override/equiv. where possible and nothing should fail if the controller fails.

I've spent a while looking into both ZigBee and ZWave. They are not quite more reliable than wifi exactly because all three use "free air" as a medium. ZigBee is a bit more free form - any device can claim compliance but there are *ahem* versions eg Ikea Tradfri and Philips Hue (both claim to work with each other now - there are many others). ZWave requires certification but there are several revisions. So far I see ZWave as more expensive but generally more compliant with standards. Its not all happy clappy though. I also note that devices are generally better built/documented for ZWave (my opinion) and for my needs that is important.

I have decided to focus on ZWave for my gear but I do keep a ZigBee USB dongle wired up for experiments.

MQTT is an absolute belter - very clean and simple. Owntracks, Mosquitto might be keywords. You can put mosquitto behind HA Proxy (to do SSL properly)

Bose and Kubernetes

adam820 — Wed, 02 Jan 2019 22:44:01 +0000

From the looks of the device in the picture, they're using a Bose Home Speaker 500 which states in the FAQ that in addition to the Wi-Fi/Cloud stuff, it also supports standard Bluetooth and 3.5mm input jack. So it looks like, in the event that the cloud stuff folds for whatever reason, it will continue to function as a regular 'ol speaker.

I do agree that anything I would purchase that is cloud-enabled should have that as something I can opt-in to using for convenience. I wouldn't want anything where the core functionality of the device stops simply because some remote service is no longer available.

Bose and Kubernetes

Cyberax — Wed, 02 Jan 2019 21:27:05 +0000

Avoid all the cloud nonsense and go ZigBee or ZWave route.

For example, I have Halo+ smart smoke alarms. Their parent company went out of business last year, btu the alarms themselves work perfectly fine and will be supported for their rest of their usable lifetime (10 years).

As an added bonus, ZigBee and ZWave are mesh networks and are more reliable than WiFi when you add enough repeaters (mains-powered devices).

> Back on topic, I'm not familiar with the message protocol being used by Bose, does anyone know if it securely encrypted so that someone can't spy on or monitor connection traffic?
MQTT is typically transferred over SSL.

Bose and Kubernetes

rahvin — Wed, 02 Jan 2019 20:49:02 +0000

I agree, IOT devices should be cloud independent as much as possible. Obviously this is much harder with a speaker type product that is relying on external computer resources for data and processing but the product shouldn't simply die without cloud access.

I specifically bought the Rain Machine irrigation controller because it was cloud based, but continues to function without the cloud in place and it openly hackable by owners. In my mind this was the way to properly design a IOT device, in that it can and will perform it's primary duties without cloud access and owners have the ability to take control of the device in the event the company goes bankrupt or like Logitech decides to abandon the product.

Back on topic, I'm not familiar with the message protocol being used by Bose, does anyone know if it securely encrypted so that someone can't spy on or monitor connection traffic? These speakers are damn scary to me as owners are basically self bugging their homes and allowing these speakers to hand over all audio to internet connected clouds which may or may not be secure.

Bose and Kubernetes

rghetta — Wed, 02 Jan 2019 20:24:55 +0000

Technical prowess aside, to me this trend toward having every appliance connecting to a manufacturer server in order to work is maddening.