The environment problem does not really allow for the American dream of 1:1 ownership.

I have little sympathy for a generation raised on such notions who see it all as theft. No such legal contract exists.

It makes me wonder how the next generations would feel about a stable environment being taken.

But we won’t be around and have our social orders so ...

History doesn't repeat, but it certainly rhymes

The funny thing is that I remember doing exactly this with PHP in the early 2000’s on a small team. We didn’t even have version control on the project and just did all of the development in vim, relying on its lock files to ensure we didn’t edit the same files at the same time. Deployed changes with rsync.

That project ran in an enterprise environment, customer facing for 10 years with almost no maintenance.

You can still do a bad install inside the cloud IDE and screw up your development environment. I’ve done this on Cloud 9.

But it’s usually easier to trash a cloud IDE and create a fresh instance than it is to unknot a bad Python configuration on a local machine. (Although you can always use Docker or Vagrant)

But you don't need things to be web-based for this, do you?

I have worked in places which say, "no code on laptops! You get a remote machine, all code must live here"

Same security advantages, but you get way more customize-ability -- choose a terminal app, font, fullscreen or many windows, and so on.

...more painful workflows

> What's there to be afraid of, so long as your workflows aren't made significantly more painful?

It's more painful.

Does GCP not let you set up a VPN? All instances can have an interface on the VPN so that you log into the VPN and can hit your instance without it being external.

For the company: infrastructure management. You don't have a local PC (other than mainly a low cost thing acting as a fairly dumb terminal) that may have parts fail and will otherwise need upgrades every now and then, with local work that may need to be encrypted and backed up, ... You are working in "the cloud", your environment is running on a common set of VMs/containers, a fault in a node just means a new one spins up (or you get shunted onto the still running ones), hardware redundancy is handled at that level reducing single points of failer, local machines don't need to be monitored for data/apps/other they should not have, resource management (does anyone run their dev PC at full tilt 24/7? no? so CPU/IO/other resources can be shared), ...

For the individual: similar concerns of hardware failures losing work go away a bit (there are still ways to lose everything, but less of them), easy moving between environments (desktop, laptop, phone), ...

Though it depends how much is pushed to the "cloud". You may still need some meat on the local resource bones if not pushing any CPU crunching into the sky too.

Essentially we are reinventing the thin client from the 90s/00s, which in turn reinvented many mainframe concepts, not that either ever completely went away, with an eye on much the same benefits.

From a security perspective, you remove the possibility of exfiltration of client data, especially PII or other sensitive data. Many orgs that have to work with PII already have strict controls around them, but that usually means that the company installs crapware on dev machines.

It could cut IT costs down dramatically. Depending on what you're working on you might need a pretty beefy machine, but nobody really wants to deal with the actual hassle of managing a fleet of high powered machines. If you can use commodity hardware + nice monitors and run the machines remotely then the machine itself can be scaled up and down arbitrarily.

This feels like another solution a lot like Stadia. There have been countless other attempts at the same idea, but the problem is always the same. Latency and user interaction between the local and remote hosts always end up being overwhelming constraints.

The most important one for us is credential management: say you do most of your work using a CI/CD pipeline but you need the AWS CLI to run reports, troubleshoot, etc. If that means you have credentials floating around in ~/.aws/credentials, there's a risk that an attacker could exfiltrate those. If you use a short-term credential system to load them via SSO, you have more infrastructure to maintain. If you setup a bastion host, you need to keep that secured because it's a really high-value target and might allow an attacker to get higher access credentials than the person they compromised if there are any mistakes on setup (common in what I've seen - internal infrastructure is often neglected compared to production servers)

None of that is something which can't be solved, of course, but this is a nice way to avoid having to deal with O&M yourself, which is the point to a lot of cloud services.