On one of the teams QnA sessions they admitted as much about the UI tooling. I think that the guidance for a "real" app would be to use the command line tools.

On one of the teams QnA sessions they admitted as much about the UI tooling. I think that the guidance for a "real" app would be to use the command line tools. It's a fair critique though. It's not obvious how you would build a proper SF app that takes advantage of the platform. Hopefully that will change as it is open sourced. I built something on an early build of SF that was pretty simple and it was hard to get up to speed. It was more of a batch oriented thing that ran off of queue inputs, so I didn't have to deal with getting load balancing inbound traffic working or other stuff. Looking at SF recently it looks like they have made a lot of interesting changes like DNS service resolution. Something like Azure AD managed service instances would make bootstrapping secret management a lot easier. I would really like to see the ability to write PowerShell that plugged into the SDK and could take advantage of everything. The comparison to K8s is more like the "guest exe" project wrapper they had. If you aren't interested in the API's for plugging into their storage or other platform features you can just wrap an executable and specify some parameters about how to host it in configuration. This is one case where the VS tooling didn't do SF any favors. People think it's the only way to use the thing.