3 ms·
There are two questions here: Should gov/company/actual human use x, y or z from the US and HOW can they avoid it? I personally don't see a lot of strong answer
by jmward01 2y ago
There are two questions here: Should gov/company/actual human use x, y or z from the US and HOW can they avoid it? I personally don't see a lot of strong answers to the 'how' question right now. At a basic level I think this is because we don't have a clear, coherent 'cloud OS' that makes it easy to build alternative offerings.
I run proxmox and try to host some things locally but the server offerings aren't quite there yet. What would be amazing would be for me to be able to truly host my own cloud so that I could share a doc with someone and the editor was hosted by my servers and safely sandboxed. It would be extraordinary if I could get my phone to offload storage to my personal cloud in place of iCloud and this was as easy as pointing to my personal cloud instead if being, at best, still a patchwork.
Things like portainer, podman, proxmox, etc are putting different pieces together but they are missing the crucial ingredients of exposing themselves to the internet safely and easily and being the foundation that my personal OS can actually easily run on. This split between device OS and cloud OS is something that hasn't yet really happened and it is holding us back from creating a viable alternative ecosystem to commercial offerings. I think the things missing from current offerings like proxmox are:
1) The cloud OS of the future needs to expose VPNs and control domains as first class citizens so that my devices can join it securely and natively. These resources are the hard-drives and network cards of a cloud OS but they are treated like apps in current offerings.
2) It needs to integrate with auth in ways that allow me to 'share' a doc from my personal cloud just as easily as google does and allow others to connect in secure, controlled ways. There isn't a point to opening up to the internet if you can't allow others to connect safely.
3) It needs to integrate with other clouds and provide native ways to migrate data and services between your personal cloud and other clouds.
4) It needs to seamlessly expand from user level cloud to enterprise and beyond. This is the 'Developers developers developers' moment. If I can develop in my local cloud things that I can deploy to a real enterprise could then I will build a lot of things even if they don't go to the enterprise.
I think building the route to 'how' is the important question here. You can't just legislate 'use the alternative' if the alternative doesn't exist. So what is the route here? How do we get to a point where it is actually possible to choose a different cloud? I think there are a couple ways here but a core component is likely a split in linux to start a cloud native install path. Basically, when you install on a machine it always installs as a container running on a hypervisor/cloud OS so the machine joins/starts a cloud OS install first and then the user OS installs are virtualized on top from the start. Basically, bare-metal should belong exclusively to the cloud OS. I think this likely would create the initial split needed to focus efforts on developing the cloud OS separate from the user OS and possibly start us down a path where the ecosystem exists to enable people to hop off of US cloud providers. As a side benefit though it would make migrating to new hardware way easier since I could likely just migrate my virtualized environment after joining it to the cloud OS the old machine is hosted on.