[HN Gopher] Launch HN: Deviceplane (YC W20) - Update and Manage ...
___________________________________________________________________
Launch HN: Deviceplane (YC W20) - Update and Manage Devices Running
Linux
Hey Hacker News! We're Josh, Sean, and Cyrus from Deviceplane
(https://deviceplane.com/). Deviceplane is an open source device
management tool for embedded systems, IoT, and edge computing. More
specifically, we manage any device running Linux. These can be
found in many different categories of hardware such as single-board
computers (Raspberry Pis, Jetson Nanos), IoT devices/gateways, and
servers running at the edge. The use cases for Linux devices span
many different verticals/industries: robotics, consumer appliances,
drones, autonomous vehicles, medical devices, and much more. Your
first thought might be that a tool for managing robots and a tool
for managing medical devices are quite different, but after talking
to a variety of companies, we've found that the pain points across
these industries are actually quite similar! Deviceplane solves
the biggest infrastructure problems for these use cases:
- Orchestrating and deployment of remote updates - Network
connectivity and SSH access - Host and application monitoring
- Device organization: naming, labeling, searching, and filtering
of devices - Access and security controls Deviceplane
is designed to support a variety of hardware, from small embedded
devices to large x86 servers. Today's tooling ecosystem suffers
from being segmented by hardware size. For smaller devices, the
Yocto project is popular. While it's good for building custom Linux
installations, it has downsides for delivering applications. It's
hard to understand, can take hours to compile, and solves only a
portion of the problems present in device management. For larger
devices, many companies seem to build and maintain their own
internal tooling. We've seen everything from systems built around
configuration management to scripts polling for new Debian packages
in S3. These systems are usually brittle, fall short of a complete
feature set, and drain precious engineering resources with their
maintenance. We think Deviceplane is a great replacement for all
of these. Not only is it suitable for all of these hardware sizes,
it also presents a way to standardize the tooling across them. One
of our goals with Deviceplane is to make device management more
accessible to developers. To do this, we build on technologies and
concepts popularized in cloud deployments: -
Applications are packaged as containers and defined in a format
resembling Docker Compose - Updates can be rolled out and
tested gradually by using "canary" deployments - An intuitive
and scriptable CLI that will feel familiar to Docker and Kubernetes
users Deviceplane integrates with your device by running a
lightweight static binary via your system supervisor. We can be
used with nearly any Linux distro, which means you can continue
using Ubuntu, Raspbian, a Yocto build, or whatever else fits your
needs. Deviceplane is completely open source. The code for
everything from the agent to the backend and UI can be found on
GitHub (https://github.com/deviceplane/deviceplane). We put a lot
of effort into making our open source version as easy as possible
to run. You can even run the backend of Deviceplane with a single
Docker command: docker run -d --restart=unless-stopped -p
8080:8080 deviceplane/deviceplane For more information on hosting
Deviceplane yourself, check out our docs
(https://deviceplane.com/docs/self-hosted/). If you'd rather jump
right into managing devices, we have a hosted version available at
https://cloud.deviceplane.com/. Lastly, we'd love to hear more
about your experiences managing devices! What have your biggest
pain points been, and what infrastructure do you wish existed to
solve those? Either comment here, or shoot us an email anytime at
founders@deviceplane.com.
Author : joshwget
Score : 115 points
Date : 2020-01-28 17:16 UTC (5 hours ago)
| kairuiz wrote:
| We've been running DevicePlane in prod for a few months now
| (after switching over from remote.it) Originally it was just
| device plane being having a much faster SSH and for convenience,
| but the new features they've begun to add started streamlining a
| lot of our dev work and actually helped us with more best
| practices. We've now containerized our applications and can
| schedule releases, stream metrics and crash data to datadog, all
| of which makes us feel more confident in our IoT.
|
| The only feature I miss is being able to execute bulk scripts
| across devices, and would love to have an internal dashboard
| rather than using datadog since the cost of data collection is
| beginning to scale out of hand.
| cyrusroshan wrote:
| Hey Kai, I remember you mentioning that bulk scripting the
| first time we talked. I actually wrote up the docs on how to do
| that just recently (the last section is probably what you're
| looking for): https://deviceplane.com/docs/operating/command-
| scripting/
|
| Glad to hear you're enjoying using Deviceplane!
| simlevesque wrote:
| Could you compare your product to AWS GreenGrass ? If I use
| GreenGrass, should I use Deviceplane too ?
| detaro wrote:
| Somewhat interesting and will keep an eye on it, but the "current
| ecosystem" paragraph seems to both miss some options and confuse
| some things. E.g. yocto isn't an update solution, but is
| presented as contrast to some options for bigger systems, and no
| of the more advanced competitors for updates, both software and
| services, aren't mentioned at all - but those are what you need
| to convince me you're better as. (And yes, the space certainly
| can use some more options trying new things!)
| joshwget wrote:
| True, Yocto is not technically an update solution! We explained
| it as such to try and keep our post a little shorter, but
| perhaps we oversimplified a bit too much there. What we
| probably meant to say is "the Yocto ecosystem".
|
| 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!
| bibabaloo wrote:
| It'd be great to hear a comparison of when you'd want to use
| DevicePlane vs something like mender.io or updatehub.io. I'm
| a great fan of the A/B dual image update strategy because
| it's simple and atomic. Would I still want to use something
| like that with DevicePlane?
|
| I'd personally be very concerned with using DevicePlane as
| it's presented as I have no way of updating the device's
| kernel version that I first deploy with.
| calvinfo wrote:
| I don't know a ton about the embedded/IOT world, but it's an area
| that has been coming up more on my radar recently. This project
| seems like a super interesting solution to the problems of
| deployment, updates, and monitoring.
|
| Could you talk a bit more about the focus on linux? How much of
| the ecosystem is running a full OS vs a small embedded program?
| joshwget wrote:
| The short answer, agreeing with @crtlaltdel, is that Linux is
| getting really popular for embedded/IoT use cases. A lot of
| "embedded" devices are starting to look more and more like real
| servers. The latest model of Raspberry Pis go up to 4gb of RAM!
|
| 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.
| crtlaltdel wrote:
| linux has become quite common in iot, which has really expanded
| what a lot of people consider an "embedded system". we built a
| platform on a custom BSP for OpenWRT for industrial
| applications where an rtos or plc wasn't needed.
| thebeardisred wrote:
| To some extent, it's a matter of ease.
|
| For embedded systems, you'd have to include the command and
| control elements in, which then gets into concerns about the
| amount of memory (both RAM and flash consumed).
|
| For example, the ESP* devices historically have had challenges
| because you don't have enough flash storage to hold a proper
| SSL anchor chain. Suffice it to say there is a LOT of nuance
| when working in the embedded world which vanishes if you (even
| if just for the purposes of minimal viable product) focus on a
| full OS.
| deforciant wrote:
| That's great! I was thinking of writing something like this for a
| few months as Balena seems really over complicated. Glad to see
| Go :) will definitely try it out for my projects!
| joshwget wrote:
| Thanks! Looking forward to hearing your feedback.
|
| Let us know if there's any feature you were planning to build
| for your upcoming project that Deviceplane doesn't currently
| have.
| jackhalford wrote:
| I tried to enroll a server into deviceplane but there is a hard
| requirement on systemd.
|
| Are there any plans in the future to support more linux
| distributions?
| joshwget wrote:
| Our agent will support nearly any Linux distro, even though our
| installation script only supports systemd at the moment.
|
| 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/mast
| er/insta....
|
| Let me know if you end up getting this to work. Would love to
| upstream to our install script!
| aryik wrote:
| This looks really cool. Kudos for going fully open source and
| congrats on launching!
| veeralpatel979 wrote:
| Congrats on launching, and thank you for open sourcing! I've
| added your codebase to my list of open source React/Go
| applications to check out.
|
| 1. Do you worry that open sourcing will make it difficult for you
| to monetize?
|
| 2. Can you describe your tech stack more?
|
| 3. How long has your team been working on this?
| f2prateek wrote:
| Congrats on the launch!
| tacLog wrote:
| Hey I was trying to reach out to sales@deviceplane.com and keep
| getting: 550 5.1.1 Requested action not taken: mailbox
| unavailable Is there a better way to reach out?
| joshwget wrote:
| Sorry about that! Must have gotten lost in the .io -> .com
| transition.
|
| We'll dig into this fix, but until then you email us at
| founders@deviceplane.com.
| tacLog wrote:
| No worries, sent to that address. Some public questions
| though.
|
| We are looking at launching a product on the nvidia jetson
| and you mentioned that running a third party OS is an uphill
| battle? Can you go into the pros and cons of BalenaOS vs the
| default for many of these single board computers?
|
| One of the big issues we have had is that on BalenaOS you are
| forced to use NetworkManger which caused us weeks of work to
| code around it's many short comings.
| ejcx wrote:
| I'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!
| MaximumMadness wrote:
| 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!
| ivanstegic wrote:
| What about Balena? How are you different or the same?
| joshwget wrote:
| Great question!
|
| 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.
| pompouspurist wrote:
| "For smaller devices, the Yocto project is popular. While it's
| good for building custom Linux installations, it has downsides
| for delivering applications. It's hard to understand, can take
| hours to compile, and solves only a portion of the problems
| present in device management."
|
| This hits home. I work at a company that builds sensor systems.
| We started using Yocto before my time in the company but we lived
| the above sentence for the last couple years before migrating to
| Ubuntu. We also happen to be scoping out a configuration
| management tool for this year. I will definitely be checking out
| Deviceplane in the coming days.
| bibabaloo wrote:
| Can you elaborate on this? How do you make use of Ubuntu in
| this way and why was it hard to use Yocto? For the usual
| embedded Linux workflows I'm used to, it seems like building on
| top of Ubuntu would necessitate re-implementing Yocto features.
| ocdtrekkie wrote:
| This sounds really neat, and exciting that it has a self-hosting
| option as well! Raspberry Pis seem to generally be pets instead
| of cattle, and combined with the ease at which they seem to torch
| their file systems, a good management solution for them sounds
| really appealing.
|
| Do you foresee a business model applying to self-hosters? If your
| business is going to focus on the service, do you have a plan to
| avoid AWS/Azure/GCP eating your lunch running your self-hosted
| code?
| joshwget wrote:
| > Raspberry Pis seem to generally be pets instead of cattle
|
| 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!
___________________________________________________________________
(page generated 2020-01-28 23:00 UTC)