Rigidly defined development environments breed fragile systems. They are enticing, for often rapid onboarding of new developers. However, not having the churn of letting new people onboard their setup to the system loses on an anti fragile mechanism.<p>This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction.<p>Which is not to say that a cloud environment should not be used. Just don't homogenize the setup.
I agree and it's why I personally invest so much time with things like Nix.<p>Nix offers a solution to being able to do a "cloud development environment", but on your local computer. It <i>also</i> allows you to easily setup the cloud development environment if you need one. While Docker works for setting up a new instance in a cloud provider, on a mac is a major pain so I don't really see it as a proper solution to the things Nix does for me.<p>But I can't help shake the feeling that Nix and Docker are just the best we have for now. I think the real solution to this involves far more changes before it's not just a pile of hacks. Eventually things will get bad enough that something will appear and it'll be adopted.<p>I don't think a VM per developer is the final version of this idea.
Ideally we'd have reliable local developer experiences. An unreliable cloud-based developer experience is certainly worse than an unreliable local developer experience, and IME cloud-based developer experiences tend to be unreliable and extremely tiresome to debug when they break.
No. No. No. No.<p>Solve local development first and then maybe cloud dev. Reasons, just off the top of my head:<p>- always-on internet connection is not always viable<p>- intermittent and bad connections are a thing<p>- which <i>local</i> environment do you support for accessing your cloud? An ever changing combination of "latest only" browsers, apps, and select IDE integrations?<p>- how stable is your cloud environment? which features and versions of which tools will get deprecated tomorrow?
At (former employer) were did a good a pretty good job at solving this. We were deployed to AWS, using EKS, SQS, Aurora, S3 and a small amount of lambda. When a new developer got onboarded, they were given their own slice of the dev environment: ingress, EKS namespace, S3 buckets, database and SQS queues. But it was still running within the same VPC and k8s cluster, with the same IAM (all those roles and policies that matched production and we're an important piece of testing). There was little additional infrastructure complexity, and no extra cost since the partitioning of usage-priced services and EKS namespaces is free. Developers also had access to shared infrastructure and the latest changes made by their colleagues. But everyone also had their own local microk8s + minio + mysql, so as long as they were happy to deploy the latest full testing release of everybody else's stuff, they could use that. When using their local cluster, they still had access to some cloud stuff like SQS and S3 (but not Aurora, they had to reply on a k8s deployed mysql).<p>We saw the cloud environment as an essential tool to provide the developers with, but not a tool that it was essential for developers to use. In fact, we had a preference for keeping dev working, so initial work on large changes should be done locally and deployed to dev once they're working. Dev was there to protect the testing environment and make sure that developers had a "real" cloud environment.<p>In other words, you don't have to deploy to dev, but if you break the testing environment because you didn't deploy to dev, there would be raised eyebrows.
> Every few days, my development environment got borked. Often it was a quick fix. Sometimes not. But always time taken from one of the most productive programmers (Alex, not me.)<p>No, Alex has made this bed, and now he's lying in it.<p>There comes a point where you have to spend some of that 'productivity' on things that keep you from being preempted in the middle of something else. Things like a stable development environment, self-cleaning scripts, etc. It's not necessary to make things bulletproof. It <i>is</i> necessary to make things self-service.
I pretty much run every project now through a docker compose file and use vscode remote containers with a devcontainer.json file.<p>This has been immense not only for my own development (nothing on my local machine, everything can be destroyed and rebuilt in a few minutes) but also for onboarding people onto projects. No mucking about with IDE settings, they are free to use whatever of course but having the basics all there makes for a great system all around.
TL;DR Use cloud based development environments to avoid machine (developer) specific, non reproducible problems, and increase productivity (speculatively)<p>Probably ok for certain needs, but not something I would use. My productivity comes from a localised and personalised setup. Issues with the local or remote environments IMHO, indicate a problems that<p>1) others may also encounter.<p>2) should at least, if possible be understood/ documented.<p>3) represent opportunities for greater understanding of the environments in question (assuming you have time to dig).
I've found myself constantly using my /tmp directory on my machine for this reason. I really like that it's ephemeral and it forces our projects to be turnkey.
“You have to delete this file & re-run that script. No problem.”
That's a problem actually, And doesn't matter where you run your program - locally or on remote host. Looks like there are issues with programming approach and stability.
Eh more like they shift managing the state to cloud providers.<p>Someone has to bootstrap a DC of machines before you can run that containerized business logic.<p>All the old barnacles are there it’s just hidden behind the wizards curtain.