6 ms·

Cloud development environments tame complexity by reducing state

57 points by KentBeck 4y ago

drunkenmagician 4y ago
TL;DR Use cloud based development environments to avoid machine (developer) specific, non reproducible problems, and increase productivity (speculatively) 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 1) others may also encounter. 2) should at least, if possible be understood/ documented. 3) represent opportunities for greater understanding of the environments in question (assuming you have time to dig).
- buscoquadnary 4y ago
  Isn't that what the promise of Docker was, you can distribute the docker image and everyone is running and building the same thing?
  - drunkenmagician 4y ago
    I would have thought so too ... ¯\_(ツ)_/¯
  - quickthrower2 4y ago
    Yeah but what is the debugging experience like? Does that work? I think it adds a layer of complication. Also images can take a while to build. Although most would be cached hopefully with just copying your code changing. Maybe a snappy startup can fix?
    - KronisLV 4y ago
      > Yeah but what is the debugging experience like? Does that work? Sort of. In certain stacks, you essentially set up remote debugging like you would for an app running in a remote environment (which is your local container with an exposed port) and your IDE just works. It's relatively carefree when it works as expected, but a bit of a pain to set up sometimes. Admittedly, something like CPU flame graphs or tools like VisualVM that let you easily select from locally running Java processes to instrument might be harder to work with. But even then, you can have issues with file system permissions and any bind mounts that you might need (e.g. files in a PHP container, where you want to keep developing and testing your app after page reloads, without rebuilding the entire container). I wrote a bit more about it here: https://blog.kronis.dev/everything%20is%20broken/containers-are-broken https://blog.kronis.dev/everything%20is%20broken/containers-... I'm still a proponent of using containers for making applications more consistently managed (configuration, resource limits, port bindings, storage), self-contained (dependencies, running different/multiple versions in parallel) and easier to launch (e.g. Docker Compose file or a fancier variation of YAML instead of Ansible + systemd services), but they definitely can be a leaky abstraction if you don't have *nix as your development machine OS.
- deleted 4y ago
  [deleted]
0xCMP 4y ago
I agree and it's why I personally invest so much time with things like Nix. Nix offers a solution to being able to do a "cloud development environment", but on your local computer. It also 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. 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. I don't think a VM per developer is the final version of this idea.
- gryBrd1987 4y ago
  Nah the final version is chips with a massive data model and algorithmic magic embedded in silicon magic to bootstrap an environment that samples the data model to answer user questions. A ways off, but some colleagues in the hardware world are working out the requirements on paper. Maybe right as I type this, not really tracking their calendar. There will be some wiggle room for general programming, patches, hands on customization by the user. Software is a decades long bubble to help us discover optimal machine state models we can etch into chips. So long as we can avoid social collapse or species extinction between now than then anyway :)
gryBrd1987 4y ago
Eh more like they shift managing the state to cloud providers. Someone has to bootstrap a DC of machines before you can run that containerized business logic. All the old barnacles are there it’s just hidden behind the wizards curtain.
taeric 4y ago
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. This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction. Which is not to say that a cloud environment should not be used. Just don't homogenize the setup.
- nordsieck 4y ago
  > 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. > This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction. > Which is not to say that a cloud environment should not be used. Just don't homogenize the setup. IMO, there is a good middle ground. I agree with you on stuff like editor/ide and base OS. But I think there can be great advantages to having everyone do development in docker/VM such that the environment matches prod.
  - taeric 4y ago
    I think letting people do this is awesome. I think standardizing on it would be a huge mistake. In particular, I think local deployment is important. And having freedom in all local deploys leads to finding the small details that matter. Especially since you probably do not own the full prod tech stack, you are behooved by having proof that you can change it. And, by all means, make the best attempt you can. I am arguing that somewhat purposely breaking it in a regular basis with each new developer makes you more resilient if you have to do a change in prod someday. And you will, someday.
    - pbalau 4y ago
      > I think letting people do this is awesome. I think standardizing on it would be a huge mistake. There is a hidden issue with not standardizing. Most people either don't care about local vs container (matching prod) development OR are terrible not equipped to make an informed choice. Thus, as a devops, I have to support both methods. This is a huge drain on my resources, especially since devopsing is just part of what I need to do. The root cause of this is the myth that all software engineers will understand source control, will understand databases, will understand how systems interact with each other and on top of it, will understand the business so they can actually do the work required. This is how you end up with "it works on my machine". This is how you end up with "but it works in repl, therefore your prod environment is broken". Standardizing doesn't mean this is the only way of doing things. It means, this is the standard way of doing things and if you get stuck, you get support. It means this is the way we consider to be most efficient of doing this stuff. You are still free to do things your way if you chose to, but if you get stuck, it's on you to get unstuck.
nraynaud 4y ago
That would be true if the AWS console didn't have a search box and a bookmark system.
jackconsidine 4y ago
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.
deleted 4y ago
[deleted]
kjgkjhfkjf 4y ago
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.
hinkley 4y ago
> 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.) No, Alex has made this bed, and now he's lying in it. 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 is necessary to make things self-service.
lukewiwa 4y ago
I pretty much run every project now through a docker compose file and use vscode remote containers with a devcontainer.json file. 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.
dmitriid 4y ago
No. No. No. No. Solve local development first and then maybe cloud dev. Reasons, just off the top of my head: - always-on internet connection is not always viable - intermittent and bad connections are a thing - which local environment do you support for accessing your cloud? An ever changing combination of "latest only" browsers, apps, and select IDE integrations? - how stable is your cloud environment? which features and versions of which tools will get deprecated tomorrow?
- quickthrower2 4y ago
  Plus latency. And cost. And slowness of a browser vs native console.
- robertlagrant 4y ago
  > Solve local development first and then maybe cloud dev I think this is it. Progressive enhancement beats graceful degradation.
- KronisLV 4y ago
  I've also seen "hybrid" setups in certain stacks, where the applications run locally but the database instance is shared amongst multiple developers for the same app version/branch. In my experience, that can be a way to deal with some resource requirement and licensing constraints, but can also be pretty horrible due to either bandwidth requirements or latency that adds up for many smaller queries that follow one another (e.g. when your app needs to shuffle around lots of data to load a page). Therefore, I'm tempted to agree that you should be able to relatively easily run as much as possible locally: especially a database with automated schema migrations and either data import or seeding (generating believable test data). Then again, one can see why something like that would be problematic in situations where you can have dozens of microservices, running all of which locally isn't entirely viable, yet re-architecting everything isn't either. It'd still be nice to be able to launch and test everything you need for a given scenario locally, even while using certain dependencies from a cloud dev environment.
  - dmitriid 4y ago
glintik 4y ago
“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.
tuatoru 4y ago
Writing on Medium tames readership by requiring accounts of readers. The essay is probably interesting, but I'll never know.
- 0xCMP 4y ago
  Using Brave I am somehow able to read it without being blocked. I assume it's blocking cookies/tracking, but that's an option.
- earth2mars 4y ago
  google "github bypass paywall"
- fhoffa 4y ago
  No account is required to read this, did you try? I opened it with an incognito window, no problem. I opened it with a logged in window, no problem. Some authors try to monetize their posts. Not this one. I'd love to know if your experience was somehow different.
- cercatrova 4y ago
  I use this extension (works on Chrome and Firefox, maybe Safari too) to bypass paywalls, works great. https://gitlab.com/magnolia1234/bypass-paywalls-chrome-clean https://gitlab.com/magnolia1234/bypass-paywalls-chrome-clean
- coder4life 4y ago
  Between deleting cookies and disabling JavaScript, you can have unfettered access to most news sites (and medium)
raffraffraff 4y ago
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). 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. 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.

57 points by KentBeck 4y ago

TL;DR Use cloud based development environments to avoid machine (developer) specific, non reproducible problems, and increase productivity (speculatively) 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 1) others may also encounter. 2) should at least, if possible be understood/ documented. 3) represent opportunities for greater understanding of the environments in question (assuming you have time to dig).

buscoquadnary 4y ago
Isn't that what the promise of Docker was, you can distribute the docker image and everyone is running and building the same thing?
- drunkenmagician 4y ago
  I would have thought so too ... ¯\_(ツ)_/¯
- quickthrower2 4y ago
  Yeah but what is the debugging experience like? Does that work? I think it adds a layer of complication. Also images can take a while to build. Although most would be cached hopefully with just copying your code changing. Maybe a snappy startup can fix?
  - KronisLV 4y ago
    > Yeah but what is the debugging experience like? Does that work? Sort of. In certain stacks, you essentially set up remote debugging like you would for an app running in a remote environment (which is your local container with an exposed port) and your IDE just works. It's relatively carefree when it works as expected, but a bit of a pain to set up sometimes. Admittedly, something like CPU flame graphs or tools like VisualVM that let you easily select from locally running Java processes to instrument might be harder to work with. But even then, you can have issues with file system permissions and any bind mounts that you might need (e.g. files in a PHP container, where you want to keep developing and testing your app after page reloads, without rebuilding the entire container). I wrote a bit more about it here: https://blog.kronis.dev/everything%20is%20broken/containers-are-broken https://blog.kronis.dev/everything%20is%20broken/containers-... I'm still a proponent of using containers for making applications more consistently managed (configuration, resource limits, port bindings, storage), self-contained (dependencies, running different/multiple versions in parallel) and easier to launch (e.g. Docker Compose file or a fancier variation of YAML instead of Ansible + systemd services), but they definitely can be a leaky abstraction if you don't have *nix as your development machine OS.
deleted 4y ago
[deleted]

0xCMP 4y ago

I agree and it's why I personally invest so much time with things like Nix. Nix offers a solution to being able to do a "cloud development environment", but on your local computer. It also 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. 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. I don't think a VM per developer is the final version of this idea.

gryBrd1987 4y ago
Nah the final version is chips with a massive data model and algorithmic magic embedded in silicon magic to bootstrap an environment that samples the data model to answer user questions. A ways off, but some colleagues in the hardware world are working out the requirements on paper. Maybe right as I type this, not really tracking their calendar. There will be some wiggle room for general programming, patches, hands on customization by the user. Software is a decades long bubble to help us discover optimal machine state models we can etch into chips. So long as we can avoid social collapse or species extinction between now than then anyway :)

gryBrd1987 4y ago

Eh more like they shift managing the state to cloud providers. Someone has to bootstrap a DC of machines before you can run that containerized business logic. All the old barnacles are there it’s just hidden behind the wizards curtain.

taeric 4y ago

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. This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction. Which is not to say that a cloud environment should not be used. Just don't homogenize the setup.

nordsieck 4y ago
> 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. > This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction. > Which is not to say that a cloud environment should not be used. Just don't homogenize the setup. IMO, there is a good middle ground. I agree with you on stuff like editor/ide and base OS. But I think there can be great advantages to having everyone do development in docker/VM such that the environment matches prod.
- taeric 4y ago
  I think letting people do this is awesome. I think standardizing on it would be a huge mistake. In particular, I think local deployment is important. And having freedom in all local deploys leads to finding the small details that matter. Especially since you probably do not own the full prod tech stack, you are behooved by having proof that you can change it. And, by all means, make the best attempt you can. I am arguing that somewhat purposely breaking it in a regular basis with each new developer makes you more resilient if you have to do a change in prod someday. And you will, someday.
  - pbalau 4y ago
    > I think letting people do this is awesome. I think standardizing on it would be a huge mistake. There is a hidden issue with not standardizing. Most people either don't care about local vs container (matching prod) development OR are terrible not equipped to make an informed choice. Thus, as a devops, I have to support both methods. This is a huge drain on my resources, especially since devopsing is just part of what I need to do. The root cause of this is the myth that all software engineers will understand source control, will understand databases, will understand how systems interact with each other and on top of it, will understand the business so they can actually do the work required. This is how you end up with "it works on my machine". This is how you end up with "but it works in repl, therefore your prod environment is broken". Standardizing doesn't mean this is the only way of doing things. It means, this is the standard way of doing things and if you get stuck, you get support. It means this is the way we consider to be most efficient of doing this stuff. You are still free to do things your way if you chose to, but if you get stuck, it's on you to get unstuck.

nraynaud 4y ago

That would be true if the AWS console didn't have a search box and a bookmark system.

jackconsidine 4y ago

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.

deleted 4y ago

[deleted]

kjgkjhfkjf 4y ago

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.

hinkley 4y ago

> 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.) No, Alex has made this bed, and now he's lying in it. 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 is necessary to make things self-service.

lukewiwa 4y ago

I pretty much run every project now through a docker compose file and use vscode remote containers with a devcontainer.json file. 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.

dmitriid 4y ago

No. No. No. No. Solve local development first and then maybe cloud dev. Reasons, just off the top of my head: - always-on internet connection is not always viable - intermittent and bad connections are a thing - which local environment do you support for accessing your cloud? An ever changing combination of "latest only" browsers, apps, and select IDE integrations? - how stable is your cloud environment? which features and versions of which tools will get deprecated tomorrow?

quickthrower2 4y ago
Plus latency. And cost. And slowness of a browser vs native console.
robertlagrant 4y ago
> Solve local development first and then maybe cloud dev I think this is it. Progressive enhancement beats graceful degradation.
KronisLV 4y ago
I've also seen "hybrid" setups in certain stacks, where the applications run locally but the database instance is shared amongst multiple developers for the same app version/branch. In my experience, that can be a way to deal with some resource requirement and licensing constraints, but can also be pretty horrible due to either bandwidth requirements or latency that adds up for many smaller queries that follow one another (e.g. when your app needs to shuffle around lots of data to load a page). Therefore, I'm tempted to agree that you should be able to relatively easily run as much as possible locally: especially a database with automated schema migrations and either data import or seeding (generating believable test data). Then again, one can see why something like that would be problematic in situations where you can have dozens of microservices, running all of which locally isn't entirely viable, yet re-architecting everything isn't either. It'd still be nice to be able to launch and test everything you need for a given scenario locally, even while using certain dependencies from a cloud dev environment.
- dmitriid 4y ago

glintik 4y ago

“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.

tuatoru 4y ago

Writing on Medium tames readership by requiring accounts of readers. The essay is probably interesting, but I'll never know.

0xCMP 4y ago
Using Brave I am somehow able to read it without being blocked. I assume it's blocking cookies/tracking, but that's an option.
earth2mars 4y ago
google "github bypass paywall"
fhoffa 4y ago
No account is required to read this, did you try? I opened it with an incognito window, no problem. I opened it with a logged in window, no problem. Some authors try to monetize their posts. Not this one. I'd love to know if your experience was somehow different.
cercatrova 4y ago
I use this extension (works on Chrome and Firefox, maybe Safari too) to bypass paywalls, works great. https://gitlab.com/magnolia1234/bypass-paywalls-chrome-clean https://gitlab.com/magnolia1234/bypass-paywalls-chrome-clean
coder4life 4y ago
Between deleting cookies and disabling JavaScript, you can have unfettered access to most news sites (and medium)

raffraffraff 4y ago

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). 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. 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.