Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fixed spelling of OpenFaaS

...

  • From the Iothon already, it became clear that Image processing is needed. All of the interesting applications used some kind of image processing. In retrospect, image processing is also pretty much the only use case for having compute power at the ultra far edge.
  • One of the biggest challenges both for setting up the hackathons and for the participants was cross compilation. A Raspberry Pi is so low powered that compiling on it is not really fun. Containers make cross compilation even more difficult: while finding a cross compiler for glibc based distros is easy, the popular Alpine Linux uses musl which requires its own compiler (or compiler settings). If we talk about distroless base images, the build system gets even more complicated. On Raspberry Pis, most distros are 32-bit (Suse SUSE Linux supports 64 bits on Raspberry 3B's and soon on 4B models) while Docker images exist for ARM64. ARMv7 processors may or may not have an FPU, and this it sometimes has to be told to the compiler (see https://gist.github.com/TapioT/9ac8e546904447e66a96a91b6f3b1d79).
  • We naturally migrated to a microservice architecture. It is simply easiest for everyone to write their piece of code in whatever language they want, use whatever base distro they like, and then package the result as a container and push it to Docker Hub. The result can then be installed with docker run.
  • As a nice surprise, the ETSI MEC specification turned out to be mostly useful. Students in the Metropolia project created an OpenAPI specification for taking pictures and generated the stub code. They were then able to add the real functionality and then they had a working app. The ETSI MEC will likely become more useful once we have more hardware to support.
  • Serverless architectures seem to be the way to go, supporting the goal of easy and secure development. The development is easy, since OpenFAAS OpenFaaS hides the routine parts of development. It is secure since it reduces the attack surface that an application has.

...

  • Write the architecture document. We have the pieces already – k3s, Service Registry, developer user interfaces, OpenFAAS OpenFaaS serverless, MEC APIs, integration with kubernetes services – but we need to write those up.
  • Automatic builds. Since everything in µMEC is built on k3s (kubernetes), we should not worry about OS installation and instead use VMs or containers. One strategy is this:
    • Build all needed containers whenever the code changes
    • Integrate the whole stack: install k3s →install OpenFAAS OpenFaaS and its dependencies → install components → run tests
  • Once this works, the installation document is easy to write
  • Support the specific use cases like Neutral Host
  • Trusted computing. We need to make the platform secure
  • Integrate OpenFAAS OpenFaaS and OpenFAAS OpenFaaS Cloud to make application management easy and secure

...