This might be a long shot, but we would like to br...
# platform-toolbox
j
This might be a long shot, but we would like to bring the platform concept to embedded dev and we could use some feedback from you. Embedded is a bit different in terms of required infrastructure. Cloud is not really involved, most of the development is done locally, with only a few exceptions like CI/CD. For a single project usually a lot of different tools are used, so containerization comes in handy. Our approach to managing environments like these is to put each tool into its own container. The tool images are stored in registries, and we group them together as per project needs. We call a group of these images a development environment. We created a free and open source tool called DEM to manage these environments. With DEM the users can browse from preconfigured development environments and install them in a self-service manner. Creating a new one should be intuitive with DEM's TUI. Do you think that this is the right approach? Could DEM be a building block of an IDP? I would really appreciate your insights, especially regarding DEM!
h
Is this not technically what https://containers.dev/ is?
it even comes with a reference cli - https://github.com/devcontainers/cli
j
Well, actually we plan to use the Dev Containers specification in the background. If my understanding is correct, the specification defines a way to parameterize a container to become a Dev Container, and how to run the specific image inside. They tend to put every required tool into a single image, but our approach is different. We try to dedicate an own container for each tool because then we gain some advantages (containers can run on different hosts, easier to change tools, better isolation). Our solution can be achieved in other ways like docker compose, but with DEM a Dev Env is more similar to a classical embedded IDE.
d
A bit of a sidebar from your original question but a problem I was working to solve in the hardware DevEx space was sharing access to specialised lab hardware like timing clocks, spectrometers and such but over the network. I paired up with an EE in my last org, he knocked out PCB and CAD designs while I worked to integrate APIs into common libraries our devs could use. We never completed the project but perhaps this is of interest to you.
j
It sounds interesting! How come you didn't finish it? Are you allowed to share more info?
d
I took another job and shortly after my colleague moved back to his old job at Tesla, coincidentally I believe he was replicating internal tooling they had at Tesla within the backplane he made.
j
Thanks for sharing this!