Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.

Platform Engineering

Here is a brief write-up on how platform engineering goes with edge: <https://avassa.io/articles/edge-computing-platform-engineering/> Feel free to comment or DM with any thoughts or feedback!

got to drop the og of edge computing in here :joy: <https://medium.com/chick-fil-atech/enterprise-restaurant-compute-f5e2fd63d20f>

Brian Chambers from the Chick-fil-a team was one of the delegates at Edge Field Day #1 last week. Videos from presentations and round table discussions available here. <https://www.youtube.com/techfieldday>

My son works at a local CFA and he showed me those and I was a bit shocked(but in a cool way).  No question about CFA being the best tech company in their industry!

:smile: , ya their original blog post was what got me interested into edge stuff, specially using cheap ( kind of ) hardware like nucs and rpis, which then led me into k3s and the rest is history :joy:

Weaveworks is doing some work in this space <https://github.com/weaveworks-liquidmetal> - as well as <https://github.com/smartxworks/virtink> using microvms on baremetal

If your looking for OSes for edge devices for hosting kubernetes - <https://kairos.io/> - and <https://www.talos.dev/>

Confessions of a Platform Engineer, Edge Computing Rollout Edition.pdf

Hi! If you're looking for something to read this Tuesday, I wanted to share this write-up. It's about what the first 10-12 months of an edge computing rollout could entail, from the viewpoint of a platform engineer.

I'm curious to know: For those of you who have been involved in a project like this, do the stages, challenges, and considerations mentioned in the write-up align with your own experiences?

This article generated a lot of interest - seems that CI/CD data should be entering the software catalog <https://thenewstack.io/simplify-ci-cd-with-a-general-purpose-software-catalog/>

Exellent read <@U03UBGT4UQJ>! Any thoughts on how this would apply to edge environments where there is e.g. hundreds of locations to deploy into?

A centralized software catalog that acts as the source of truth is crucial for managing software deployments across a large number of edge environments. This is even more important when you have a significant number of locations to deploy into. Without a centralized source of truth, managing and accessing information across numerous locations can be error-prone. Therefore, having a single place to manage and access software components simplifies the deployment process. Additionally, a REST API would enhance accessibility and make it easier to integrate with other tools, streamlining the CI/CD process.

Yes, agreed. AND; I would add that there is need for not only putting together a coherent definition of software, but also a means of describing what software require from the surrounding execution context. My experience is that edge environments can be very constrained and heterogenous (i.e. different CPU architectures) and there may also be requirements on e.g. GPU accessibility for certain types of applications. So it should be possible to declare runtime requirements as part of the definition of the software. Thoughts?

1. ~What does the software require from the surrounding execution context. My experience is that edge environments can be very constrained and heterogenous (i.e. different CPU architectures) and there may also be requirements on e.g. GPU accessibility for certain types of applications. So it should be possible to declare runtime requirements as part of the definition of the software. Thoughts?~