Why is it taking so long for cloud dev environments to catch on?(warp.dev)
warp.dev
Why is it taking so long for cloud dev environments to catch on?
https://www.warp.dev/blog/why-is-it-taking-so-long-for-cloud-dev-environments-to-catch-on
8 comments
I could imagine the switch being very difficult at an existing company, but if a startup implemented cloud dev environments from day one, it would be baked into their DNA. When I worked as a contractor, the biggest when starting a new client was getting the dev environment set up. Cloning the repo, installing packages, pulling docker images, modifying host files, etc. If all that already existed in the cloud and I just needed credentials to log in and I could start contributing in minutes instead of hours or days (even weeks if you have to ship a laptop), that would open up possibilities for bringing on devs for shorter engagements. You could have a dev spin up a cloud environment for a single ticket, giving them access to a single feature branch or even a single file or module...write the code and tests without having to invest time in environment setup
Great read.
Anedotally I've tried Gitpod, Cloud9 and Codespaces. Latency issues were the major thing that turned me off from every platform.
Also from a business pov, I've found most thin clients relatively expensive. so in the end of the day you don't save much on the endpoint side, but pay extra on cloud environments. That point is local market dependent though.
Finally, VS Code dev containers greatly improved our onboarding experience already, making cloud dev ends less appetizing.
Anedotally I've tried Gitpod, Cloud9 and Codespaces. Latency issues were the major thing that turned me off from every platform.
Also from a business pov, I've found most thin clients relatively expensive. so in the end of the day you don't save much on the endpoint side, but pay extra on cloud environments. That point is local market dependent though.
Finally, VS Code dev containers greatly improved our onboarding experience already, making cloud dev ends less appetizing.
The single user pain point (at least in a company) is that your dev environment may not closely match production in terms of architecture / OS / installed packages. In my case, this is especially true as I am developing on an M1 Mac while most of the other Eng are still on the Intel Macs. Dev documents are littered with `brew install` commands and `npm` global installs which creates headaches in replicating state.
I think VS Code has really started to change the game in this space and paves the way for more cloud focused tool like Warp. The first step in moving to the cloud is convincing developers that their machine isn't "special". VS code jumps this hurdle by allowing development to pretty seamlessly occur inside of a Docker image on your machine while your "special" dev environment extras are maintained through text config and installed VS Code extensions.
Once there is the convincing use case of "my dev environment does not need to be my machine" and that experience is seamless, the next evolution is to the cloud - either running local VS code against remote docker instances or browser-based VS code against the same remote docker instances.
In my personal case, the hurdle to get to VS Code the blocker with not a lot to be immediately gained by completing it. But I believe that once I do complete it, I can leverage that knowledge to make Dev-Ops onboarding of new developers much better. Additionally, Getting eventually to a browser-based IDE with a remote-hosted Docker, I can shift away my dependence on a specific (and very expensive) machine.
I think VS Code has really started to change the game in this space and paves the way for more cloud focused tool like Warp. The first step in moving to the cloud is convincing developers that their machine isn't "special". VS code jumps this hurdle by allowing development to pretty seamlessly occur inside of a Docker image on your machine while your "special" dev environment extras are maintained through text config and installed VS Code extensions.
Once there is the convincing use case of "my dev environment does not need to be my machine" and that experience is seamless, the next evolution is to the cloud - either running local VS code against remote docker instances or browser-based VS code against the same remote docker instances.
In my personal case, the hurdle to get to VS Code the blocker with not a lot to be immediately gained by completing it. But I believe that once I do complete it, I can leverage that knowledge to make Dev-Ops onboarding of new developers much better. Additionally, Getting eventually to a browser-based IDE with a remote-hosted Docker, I can shift away my dependence on a specific (and very expensive) machine.
That's an interesting point regarding the costs of the client vs. the cloud, and also that you can get a more hermetic experience with local VMS. Agreed on the latency concern.
Thanks for the feedback!
Thanks for the feedback!
Biggest (and somewhat hidden) win of cloud dev:
""" Cloud hosting makes it necessary to have a (mostly) hermetic dev environment, which is a good thing """
""" Cloud hosting makes it necessary to have a (mostly) hermetic dev environment, which is a good thing """
And a top-down company mandate could be the stronger pull since the individual preferences of the `MxNxL` devtools would be irrelevant compared with some more significant concerns like Dev-Security / Immutable & Standardized dev envs.