alexandros

I think keeping all the data in one place has been one of the smartest things we did. If we'd been crazy enough to give each microservice its own persistence, we'd be neck deep in chaos by now. It only happened for one service due to reasons that we should have ignored at the time, and it keeps biting us in the rear to this day. Thankfully we're getting closer to reversing that mistake, oh happy day.

We started resin.io with a microservices architecture from day one, and we are still happy with the result. It was very painful to get it up and running, but once that was over, we were good to go. The boundaries we defined early on are still solid, and the result works well. One critical detail however, is that all our persistent state lives in one place, minus specific well-understood exceptions. Arguably, starting with microservices helped us define strong boundaries we weren't tempted to blur over time.

All this said, I do sometimes wish we had started with a monolith, if only because we paid the microservices tax in deployment and infrastructure maintenance way too early, long before we had the scale to warrant it. I feel starting with a monolith would have probably meant more progress in less time, though with a risk of not being able to refactor smoothly when the time came.

Overall a hard call to make, since I'm happy with the result, but wonder about the pain it took to get here, and at the same time counterfactual universes are hard to instantiate...

TL;DR -- because developers love it. I clicked the article hoping there was some strategic background, some connection to the Oracle lawsuit, etc. Nop, the answer to "why" is "because of its merits". Also in this article, some backstory about the name "Kotlin".

At resin.io we keep looking for a solid arm host, as we are currently emulating a ton of arm builds on x86. I guess our use case is somewhat unique, but we still haven't found something that works for us.

Hey there -- resin.io founder here. Resin is indeed starting with our hosted service, but we have committed to, and are making decent progress towards, building a completely open source platform.

If you need pure OTA, mender is a great solution. Resin is about containers first and foremost, with full-blown host updates being a lot more rare, since the host is a lot simpler.

Different things work for different projects, hope yours goes well!

Incredible work jayniz -- I guess everyone and their mother is suggesting improvements, are you preparing a new version with the rpi zero W and non-cut lego blocks?

Disclaimer: resin.io founder, we're so happy you chose resin for this awesome project ;)

mind linking the paper?

Do we know if that is because Runners and Musicians tend to be generally better educated and raised, both those things being markers of middle- and upper- class membership?

The point of Amazon Go is instant gratification. The point of this is not carrying stuff to your house. Cool troll, but they should be careful of the false sense of superiority. Perhaps they could hire some Nokia and BlackBerry execs to explain the concept to them.

> Wish there was a less insidious company trying to get into all my devices.

Sounds like a call for a shameless plug! We have recently released resinOS[1] as a stand-alone OS after a few years of development and production deployments on resin.io[2] connected devices.

[1]: https://resinos.io [2]: https://resin.io

And what when the robot goes to $4/hr? Eat less expensive food? Have fewer children? What when the robot goes to $0.02/hr?

If someone told me that a certain truth is not useful, I would be inclined to disbelieve them. The basis of your argument seems to be "I can't think of any uses" but that can hardly be considered "the problem with articles like this". I can think of quite a few applications, but in many cases I have experienced, whenever relevant truths have been ignored, delusions have thrived.

Resin.io | REMOTE | Linux engineers, Security engineers, Backend engineers, UI/Front-end engineers, Workflow engineers

Resin.io allows IoT developers to push Linux Containers to embedded devices. See our demo of updating a drone in-flight at DockerCon [1]. We're very emphatic about our remote culture [2].

The resin.io team is composed of people passionate about quality code, well-thought out architecture, and great user experience. Etcher.io, a tool we recently released, is a good example of all those things. Most of our code is node.js though we're transitioning some parts of the stack to Go.

Some details on the individual roles:

Linux engineers - We're building a minimal OS for embedded devices[3]. Knowledge of Yocto Linux very helpful.

Security engineers - Passionate about building an end-to-end secure code delivery pipeline, from the cloud to the device, all the way down to the bootloader and CPU?

Backend engineers - Resin's backend is composed of ~10 node.js microservices, each with unique challenges.

UI/Front-end engineers - We're passionate about UX, and have a lot of cool features to build. Most of our UI is in AngularJS but knowledge of other frameworks a plus. Workflow engineers - Looking for full-stack developers passionate about optimising the way a remote team works.

If this all sounds interesting, drop us a line at join@resin.io

[1]: https://youtu.be/75vm6rRb6K0?t=1569 [2]: https://resin.io/blog/how-we-run-a-remote-team/ [3]: https://github.com/resin-os/

Transactional updates are pretty much standard for embedded devices that care about updates. Android Brillo, ChromeOS, Android, Snappy, and many many others employ similar strategies.

ResinOS does indeed have a smaller footprint, a broader set of supported architectures (Snappy only supports ARMv7 and above), and uses Docker instead of LXD+snaps.

If you run a privileged container, you can add any sort of audio and video manager in the container. We have users running X11 and Electron inside their containers, for instance.

Preloaded containers is something we have built out for resin.io, and will be extending to resinOS standalone as well. The current release is just the development version. Production version with preloading should follow.

We use node.js for the development toolkit, not for the OS components. There will always be programming language disagreements, but we find we are productive in node.js and it works for us. Coffeescript is admittedly getting a bit long in the tooth and we should switch to ES6 or TypeScript, but I personaly see that as a minor change, though a good one.

I don't think resinOS affects that either way, but I will check and come back to you in a few hrs as the team in Europe wakes up.

We used to release anually in the data centre too. If the benefits of incremental and iterative deployment don't move you, consider all the iot security issues recently. And if that doesnt do it either, consider NASA's Mars rovers, Tesla, nest, and the multitude other embedded products that use updating to great effect. You may disagree, but gibberish is a bit harsh don't you think?

anything that would benefit from a consistent build pipeline, fast deployments, isolated failures, etc etc.

resinOS is designed for embedded devices, already supports many of them running several architectures (all the way down to ARMv5). While I have heard that rancherOS can run somewhat on a raspberry pi, that's a long way from being able to properly function in an embedded environment (read-only rootFS, reliable networking and DNS stack, support for atomic host updates, etc). There's nothing we'd like more than to have someone make the OS for us, but at this point we're pretty sure we'll have to do it ourselves. The variance in the embedded world is simply too large for a cloud OS to handle it without major rearchitecting.

Thank you Ελευθέριε! Onwards and upwards :)

You mean that you tried the image and it worked on the X15? That's fantastic! We hadn't tried the board before.

What does support of the other processors entail? Is it a kernel modification? Are you sure the dsp on the Beagle doesn't work? Say hi on the gitter channel ( https://gitter.im/resin-os/chat ) and the resinOS team will be there tomorrow morning (european time) to talk more.

Our model is not a commandment for everyone. There will always be cases where containers don't make sense. However, every new level of abstraction meets this instinctive reaction at first. People didn't want VMs in the data centre messing with their bare metal either, I'll bet.

The point of containers is to make updateability easy. To bring embedded software closer in line with what's going on in the cloud. To enable the kinds of workflows we have had in every other part of the development world for decades. It may or may not be right for your project. So long as you understand the intention and make informed choices about the tradeoffs, there will always be cases that fall in the one or the other side of the fence. I don't perceive this as being a dick, you're stating a reasonable case for a model that does indeed work for a lot of cases.

We will continue working to reduce overhead, hopefully power requirements and cost will go down, and somewhere along the curve, we may even meet your needs at some point. Whatever the case, we're pretty sure we'll never cover everything so if we gave the impression that resinOS will end all embedded OSes, then it was the wrong impression to give. :)

Haven't really tried to go that route. There are some fundamental limitations to Kubernetes and Docker Swarm due to their dependence on etcd, which behaves very badly when the devices are not on the same LAN. Depending on your use case you may want to have a look at resin.io as a management/orchestration service of sorts (pardon the plug), though our focus is purely on embedded/IoT scenarios, so it may or may not apply to your use case.

Yes! We've actually created extremely small base images with Yocto for our own agent at resin.io, and it's a really cool approach, though it is very complex to set up and handle, and has approximately none of the elegance of a Dockerfile. Also, resinOS images are available as containers for some very specific use cases, so that's another instance where we've done something like that. Perhaps we should write up more about the approach.

We're generally very active in the Yocto community, the resin.io team already maintains the raspberrypi, CHIP, and Samsung Artik BSPs. Not sure what their interaction has been with the vitrualisation layer and don't want to misrepresent them, but I do know Andrei and the rest of the team are generally good citizens and work hard to feed patches upstream as much as possible.

There are a lot of companies looking at the intersection of containers and embedded. Some call it "Fog Computing" others "Edge Computing", others still "Industrial Internet" and so forth. We have a number of use cases on the resin.io website of people using this technology in production today, but some of the larger ones we're not allowed to talk about :(. ResinOS does include a full Docker engine however. It's just that a lot more is needed to do containers right on embedded Linux devices.

Very good question. We find that we have to add functionality for the embedded world in quite a few cases, and part of the resinOS roadmap is to package that up for the OS. But the base Docker, other than its recently growing size, is a very strong foundation, and one that keeps improving. We're particularly excited about the new security features and in general our approach is that we can move a lot faster by filling the gap between Docker and embedded devices, rather than starting from scratch and building Yet Another Container Engine.

Yes. We build many container base images for all architectures. have a browse and pick what works for you -- https://hub.docker.com/r/resin/ and also http://docs.resin.io/runtime/resin-base-images/

The hypriot guys are doing great work, and we share a common mission in spreading containers to embedded development. ResinOS is built with production deployments as a first goal, and so has a read-only rootFS, supports atomic host OS updates, is ported (and portable) to a lot of device types (via Yocto) and in general has many more "embedded" characteristics than Debian, on which hypriotOS is based. I do however want to reiterate that we know the Hypriot guys decently well and appreciate the work they're doing to make Docker accessible to embedded hackers.

The version of Docker on the OS right now is 1.10 so the ram footprint of the OS is fairly small. The team is all asleep (being in Berlin and whatnot), but I'd estimate about 50mb is a decent approximation. We're working on getting a newer Docker but its RAM footprint is one of our concerns, though we do have ways forward.

The number of containers is kinda a red herring for a couple reasons. For one, you can make a trivial container and launch as many containers as you like, it really depends on what's in them. For another, embedded devices don't usually need hundreds of containers, they run payloads that are either single-container, or look a lot more like a docker-compose file with a few microservices.