93 karma · joined December 3, 2015
I can certainly see how pulling a base image could require that kind of download size, but subsequent updates should only need to pull the layers that have changed.
2. If I had to summarize in one word, Golang. Our backend, agent, and CLI are all written in Go.
Frontend is React + a custom component library we maintain.
On the infrastructure side it's quite simple: RDS, containers running on ECS, and an ALB load balancer. We built Deviceplane to be simple to host and since we just run the open source version it means our own infrastructure is simple.
3. We've been working on this since around August!
Another common reason for large images is the Nvidia ecosystem. Most of the images that Nvidia publish can get close to 1GB. However, these should only need to be pulled to devices once until you need to upgrade the base image.
> 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.
We mention Yocto and internal tooling rather than other competitors because they're what we hear most often. We would have loved to include more discussion about why were better than other solutions, but it would have made our post a little unwieldy.
I have a comparison between us and Balena here: https://news.ycombinator.com/item?id=22173350.
What other tools did you have in mind? It'd be great to discuss this more!
We'll dig into this fix, but until then you email us at founders@deviceplane.com.
Let us know if there's any feature you were planning to build for your upcoming project that Deviceplane doesn't currently have.
We've really wanted to add OpenRC support to our installation script for a while but haven't gotten to it yet.
If you know your init system well, you could always write your own service file. Here's the unit file for systemd as a reference: https://github.com/deviceplane/deviceplane/blob/master/insta....
Let me know if you end up getting this to work. Would love to upstream to our install script!
We're in the same space as Balena and tackling some of the same problems, but with a different approach. Here are some of the big ways we defer from Balena (though these points really just scratch the surface).
Balena ties you into their ecosystem a bit too much. They require you to use BalenaOS which means they only support a fixed number of devices. In contrast, Deviceplane can be used with any Linux distro, meaning that as long as your device runs some form of Linux than it can be used with Deviceplane.
What's more, we've found that in most cases people really need the choice of what underlying Linux distro to use. For example, if you're using Jetson Nano devices and don't use the distro provided by Nvidia then you'll be fighting quite an uphill battle. Their distro includes a custom version of Docker (nvidia-docker) that adds support for using CUDA inside of containers.
Deviceplane also doesn't tie you to any specific container builder. We make it easy to integrate with popular CI systems so you can inherit all of their best features: build secrets, fully scriptable pipelines, etc...
Balena also lacks some of the core infrastructure that Deviceplane provides, such as our monitoring and bulk provisioning support.
Lastly, we're 100% open source and easy to host unlike Open Balena. Open Balena doesn't include user management or a UI. If you read through its installation guide you'll quickly get a sense that its architecture is needlessly complex and difficult to self-host. In contrast, Deviceplane was engineered to be self-hosted from day one and can be run in a single Docker command.
This is a great comment, and maybe a point we should have directly made in the launch post. Devices are certainly more like pets. If you push an update that breaks a device, you'll have an angry customer calling you rather than just being able to spin up a new EC2 instance!
We certainly predict self-hosting being a core part of our business model. This isn't as a response to AWS/Azure/GCP though.
We get this question a lot, but we don't actually fear AWS/Azure/GCP much. Plenty of SaaS companies have products similar to something offered by major clouds (Datadog, Cloudflare, etc...). We think the big clouds are good at their core competencies (EC2, RDS, etc...) but struggle to address the right problems with a great UX in their fringe products.
AWS/Azure/GCP just don't come up much in our customer conversations. We think our real competitor is internal tooling!
Linux has been standard in the cloud for a long time and as a result the tooling is pretty mature now. Projects like Kubernetes are great for managing servers in the cloud and have become quite standard. We noticed the same level of tooling for running Linux on devices just wasn't there yet, and so we decided to try and fix that!
That being said, there are certainly use cases where Linux isn't the best choice. If you have realtime requirements or you need low power usage then using an RTOS is a better option.
We considered using Alpine as the base image for our system containers for a time. They're still built using Buildroot currently, though we're playing around with another project that we might use instead.
- LinuxKit seems designed to be a piece that can be used to build a Linux distro but isn't a full distro out of the box like RancherOS
- As far as I know LinuxKit is still based on Alpine whereas RancherOS is custom and doesn't have much of a host filesystem
- LinuxKit is based on containerd and RancherOS is still based on Docker (though this is likely to change soon)
We're definitely interested in collaborating with LinuxKit since we do have similar goals. It's probably a good idea for us to write a more detailed blog post comparing the two since we've been getting this question pretty often lately.