Congrats on the launch, y’all. I’ve worked closely with Cyrus in the past and just met the team a few months ago. I’m very much looking forward to where this is going.
Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
31–40 of 68 posts
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#32Congrats on the launch! This is perfectly timed since I’m currently evaluating device management solutions for Hiome’s IoT device fleet (https://hiome.com)
Currently, we use Mender (mender.io) but are considering switching.
Pros for Mender:
* great pricing for consumer products at around $0.50/device/mo
* lets us keep using Raspbian on our Raspberry Pi fleet
The cons however are that we are stuck with Raspberry Pi 3B+. We want to switch a more production-friendly board (either the compute module or something else entirely), but that means switching to yocto, which as you mentioned, is its own world of problems. Mender’s UI is also very buggy.
BalenaOS is acceptable and does support the boards we’re currently considering, but we’re limited to the devices they choose to support in the future.
I love that Deviceplane claims to work with any linux distribution. However, as far as I can tell, you only support application updates, not OS-level updates. Will it ever be possible to update the OS in your model? A major reason I want to use a device management system is to make sure we can fix potential OS-level security issues.
Another concern is pricing. $5/device/mo is probably fine for enterprise, but that can be 100% of revenue for many consumer devices. Since you’re open source, we could always self-host, but I’m curious if you have any plans to for more B2C-friendly pricing.
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#33My biggest pain point with Balena in my previous job was that it used Docker; it's unfortunate that most of the solutions in this space (including Deviceplane) seem to do so. It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update.
I'd be really interested in seeing a system based around Git and something like buildpacks instead. IoT definitely feels like the right space for pushing small diffs for deployments.
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#34My biggest pain point with Balena in my previous job was that it used Docker; it's unfortunate that most of the solutions in this space (including Deviceplane) seem to do so. It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update. I'd be really interested in seeing a system based around Git and something like buildpacks instead. I…
> It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update.
That seems like a really big image? Alpine-based images in my experience tend to be under 100MB.
But I would be fascinated to use p2p for distributing image layers; it feels like that shouldn't be too hard?
EDIT: it's been done, apparently:) https://blog.bonner.is/docker-registry-for-ipfs/
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#35Congrats on the launch, y’all. I’ve worked closely with Cyrus in the past and just met the team a few months ago. I’m very much looking forward to where this is going.
Thanks Izu, I hope we can share some great updates in the next few months!
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#36Congrats on the launch! This is perfectly timed since I’m currently evaluating device management solutions for Hiome’s IoT device fleet ( https://hiome.com ) Currently, we use Mender (mender.io) but are considering switching. Pros for Mender: * great pricing for consumer products at around $0.50/device/mo * lets us keep using Raspbian on our Raspberry Pi fleet The cons however are that we are stuck with Raspberry Pi…
Thanks!
> However, as far as I can tell, you only support application updates, not OS-level updates.
For now this is true. People using Deviceplane today upgrade their underlying OS via the mechanism provided by their distro. On Debian-based systems this means running something like `apt-get dist-upgrade`. Deviceplane provides the tools to rollout this upgrade across your devices, but we're not hands-on past that.
We do have plans to support OS-level updates, but for now we're specializing in just updating applications and letting the underlying distro handle updating itself.
> Another concern is pricing. $5/device/mo is probably fine for enterprise, but that can be 100% of revenue for many consumer devices. Since you’re open source, we could always self-host, but I’m curious if you have any plans to for more B2C-friendly pricing.
Our pricing isn't actually $5/device/mo! This would be quite expensive. Our team plans starts at $250 per month, but pricing doesn't scale linearly past that. We're still exploring different pricing schemes for Deviceplane, but we do know that having the same per-device rate for B2B and B2C will likely not work.
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#37My biggest pain point with Balena in my previous job was that it used Docker; it's unfortunate that most of the solutions in this space (including Deviceplane) seem to do so. It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update. I'd be really interested in seeing a system based around Git and something like buildpacks instead. I…
Docker images are designed for minimal artifact transport while avoiding the need for assembly from source at the edge. If anyone is pushing around 1GB images for iterative deployments they might be able to do better with a few tweaks to their image structure and delivery pipeline.
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#38My biggest pain point with Balena in my previous job was that it used Docker; it's unfortunate that most of the solutions in this space (including Deviceplane) seem to do so. It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update. I'd be really interested in seeing a system based around Git and something like buildpacks instead. I…
> It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update. That seems like a really big image? Alpine-based images in my experience tend to be under 100MB. But I would be fascinated to use p2p for distributing image layers; it feels like that shouldn't be too hard? EDIT: it's been done, apparently:) https://blog.bonner.is/docker-re…
IPFS and decentralization don't really address artifact size issues.
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#39I've worked with both Josh and Cyrus at DevicePlane and can say I'm really looking forward to what these folks deliver. Really great engineering talent all around working on a solution to a non-obvious but hard problem that exists. I can't wait to get the time to sit down and play with it!
I'd echo this. I've worked with Cyrus previously and he's one of the most effective engineers I've ever partnered with. Great team behind this!
Thanks, Evan, Max, you guys rock! Sometimes I forget how many people I know that read HN.
Re: Launch HN: Deviceplane (YC W20) – Update and Manage Devices Running Linux
#40Earlier quoted context omitted.
> It's not really ideal in a number of installations to be pulling down 1GB Docker images simultaneously from 20 devices when you push an update. That seems like a really big image? Alpine-based images in my experience tend to be under 100MB. But I would be fascinated to use p2p for distributing image layers; it feels like that shouldn't be too hard? EDIT: it's been done, apparently:) https://blog.bonner.is/docker-re…
IPFS and decentralization don't really address artifact size issues.
It certainly improves the practical outcome; replicating layers between nodes in a rack/datacenter is way faster than pulling it down 20x from one external upstream.