4 ms·

If software development was a real engineering discipline docker wouldn't exist. The idea that you need isolated environments to run/develop programs that need

If software development was a real engineering discipline docker wouldn't exist. The idea that you need isolated environments to run/develop programs that need different versions of libraries is regressive. Way back in the 80s and 90s Microsoft had backwards compatiblity down. Now in the 2010s and 2020s every couple months we can expect a breaking change in the webdev, linux, python ecosystem. Try running a 3 year old python app outside a container. This foot gunning is dumb. But it sure does make work for software developers. Who go on HN and crow about how much value they create while messing around in docker or whatever.

rualca 5y ago
> The idea that you need isolated environments to run/develop programs that need different versions of libraries is regressive. Containerization's value proposition isn't really the isolation part. That's nice and all, but it's not their main selling point. The main selling point of containers is the fact that they solve the problems of packaging, deploying applications, and configuration, and they do so in a perfectly auditable and observable way.
- morpheos137 5y ago
  Again if backwards compatibility were respected then packaging and deployment wouldn't be so complicated.
  - AlexMoffat 5y ago
    If wishes were horses beggars would ride.
  - doctor_eval 5y ago
    C’mon, compatibility with the host OS is just one of many deployment issues that need to be solved. Deployment covers a ton of problems including resource allocation, traffic routing, discoverability, health checks, secrets management and heaps more. Containerisation just provides a unit of management. I work in Go which has great backwards compatibility, builds static binaries, and since //go:embed you can release a single binary containing literally all resources needed to run an application. We don’t technically need to use docker to deploy our services but we still need an orchestration platform. Ironically given the discussion, we’ve chosen nomad over K8s, but nevertheless we needed something, and “backwards compatibility” didn’t really even register.
ghshephard 5y ago
It's important to distinguish between the different flavors of containerization - Docker, and container orchestration - K8S. Docker is intriguing as a nice lightweight way of separating your processes - and is (mostly?) interesting to developers. K8S changed the entire trajectory of application management at scale. We have about 4300 containers in production where I work (at this moment - it can change from hour to hour), and I don't believe "isolated environments that need different versions of libraries" was ever a driver, or even strong incentive for using containers. Rather - the ability to rapidly add resources, resize resources, re-allocate storage performance dynamically, and use whichever cloud provider made sense (we've worked with AWS, Google Cloud, and now Azure) - and be able to migrate your environments between them in a period of a week - was what made containerization attractive. Being able to type: kubectl scale deploy worker-background --replicas=300 And have 300 worker pods come online in < 60 seconds really changes the power of an individual. Being able to have that done all dynamically (up and down) without any human intervention - that's a game changer in some of the ETL heavy workloads. If you've ever worked at a large company - think of the effort required to get 300 new 6 CPU/32 GB VMs allocated to a project you are working on. Now consider a company where pretty much all of the engineering / ops employees can do that from the bash prompt. I'm just looking forward to the day where we can scale the performance of our storage from 500 IOPS/sec to 8K IOPS/sec dynamically as required (still requires a manual step with Azure - albeit a pretty straightforward one in their portal).
- jiggawatts 5y ago
  This is a little bit hilarious to me, because I've been through this exact same "reinventing the wheel" cycle about 3 times now. The cycle goes like this: "A mainframe takes too long to buy, it's too expensive!" "Here, have an LPAR, you can spin one up in seconds!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get an LPAR!" "Getting an LPAR approved takes too much paperwork!" "Here, have an Intel server instead! It's not a 'proper' machine, but you can have it in a week!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get a new server provisioned properly!" "Getting a server provisioning approved takes too much paperwork!" "Here, have a VMware virtual server instead! It's not a 'proper' machine, but you can have it in a day!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get a new VM provisioned properly!" "Getting the VM provisioning approved takes too much paperwork!" "Here, have a Cloud server instead! It's not a 'proper' machine, but you can have it in minutes!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get a new cloud IaaS VM provisioned properly!" "Getting cloud IaaS VM provisioning approved takes too much paperwork!" "Here, have a Kubernetes Namespace instead! It's not a 'proper' machine, but you can have it in minutes!" <-- you are here.
ghaff 5y ago
If there were no need for isolated environments in Windows, VMware wouldn’t exist.
deleted 5y ago
[deleted]
pjlegato 5y ago
Broken dependencies in 90s-era Microsoft systems was so common that it has its own Wikipedia article: https://en.wikipedia.org/wiki/DLL_Hell https://en.wikipedia.org/wiki/DLL_Hell
goodpoint 5y ago
Spot on, and this is seriously harming Linux distributions and ultimately making FOSS unusable for non-developers.

rualca 5y ago

> The idea that you need isolated environments to run/develop programs that need different versions of libraries is regressive. Containerization's value proposition isn't really the isolation part. That's nice and all, but it's not their main selling point. The main selling point of containers is the fact that they solve the problems of packaging, deploying applications, and configuration, and they do so in a perfectly auditable and observable way.

morpheos137 5y ago
Again if backwards compatibility were respected then packaging and deployment wouldn't be so complicated.
- AlexMoffat 5y ago
  If wishes were horses beggars would ride.
- doctor_eval 5y ago
  C’mon, compatibility with the host OS is just one of many deployment issues that need to be solved. Deployment covers a ton of problems including resource allocation, traffic routing, discoverability, health checks, secrets management and heaps more. Containerisation just provides a unit of management. I work in Go which has great backwards compatibility, builds static binaries, and since //go:embed you can release a single binary containing literally all resources needed to run an application. We don’t technically need to use docker to deploy our services but we still need an orchestration platform. Ironically given the discussion, we’ve chosen nomad over K8s, but nevertheless we needed something, and “backwards compatibility” didn’t really even register.

ghshephard 5y ago

It's important to distinguish between the different flavors of containerization - Docker, and container orchestration - K8S. Docker is intriguing as a nice lightweight way of separating your processes - and is (mostly?) interesting to developers. K8S changed the entire trajectory of application management at scale. We have about 4300 containers in production where I work (at this moment - it can change from hour to hour), and I don't believe "isolated environments that need different versions of libraries" was ever a driver, or even strong incentive for using containers. Rather - the ability to rapidly add resources, resize resources, re-allocate storage performance dynamically, and use whichever cloud provider made sense (we've worked with AWS, Google Cloud, and now Azure) - and be able to migrate your environments between them in a period of a week - was what made containerization attractive. Being able to type: kubectl scale deploy worker-background --replicas=300 And have 300 worker pods come online in < 60 seconds really changes the power of an individual. Being able to have that done all dynamically (up and down) without any human intervention - that's a game changer in some of the ETL heavy workloads. If you've ever worked at a large company - think of the effort required to get 300 new 6 CPU/32 GB VMs allocated to a project you are working on. Now consider a company where pretty much all of the engineering / ops employees can do that from the bash prompt. I'm just looking forward to the day where we can scale the performance of our storage from 500 IOPS/sec to 8K IOPS/sec dynamically as required (still requires a manual step with Azure - albeit a pretty straightforward one in their portal).

jiggawatts 5y ago
This is a little bit hilarious to me, because I've been through this exact same "reinventing the wheel" cycle about 3 times now. The cycle goes like this: "A mainframe takes too long to buy, it's too expensive!" "Here, have an LPAR, you can spin one up in seconds!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get an LPAR!" "Getting an LPAR approved takes too much paperwork!" "Here, have an Intel server instead! It's not a 'proper' machine, but you can have it in a week!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get a new server provisioned properly!" "Getting a server provisioning approved takes too much paperwork!" "Here, have a VMware virtual server instead! It's not a 'proper' machine, but you can have it in a day!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get a new VM provisioned properly!" "Getting the VM provisioning approved takes too much paperwork!" "Here, have a Cloud server instead! It's not a 'proper' machine, but you can have it in minutes!" "Wooaa there! You can't just do whatever you want, fill in this paperwork to get a new cloud IaaS VM provisioned properly!" "Getting cloud IaaS VM provisioning approved takes too much paperwork!" "Here, have a Kubernetes Namespace instead! It's not a 'proper' machine, but you can have it in minutes!" <-- you are here.

ghaff 5y ago

If there were no need for isolated environments in Windows, VMware wouldn’t exist.

deleted 5y ago

[deleted]

pjlegato 5y ago

Broken dependencies in 90s-era Microsoft systems was so common that it has its own Wikipedia article: https://en.wikipedia.org/wiki/DLL_Hell https://en.wikipedia.org/wiki/DLL_Hell

goodpoint 5y ago

Spot on, and this is seriously harming Linux distributions and ultimately making FOSS unusable for non-developers.