6 ms·

It is a myth that all websites (or applications) have an active development team continuously deploying updates. I would even expect that the vast majority of t

by cm2187 7y ago

It is a myth that all websites (or applications) have an active development team continuously deploying updates. I would even expect that the vast majority of the code in production in the world is old code that is not looked after. This is particularly true for small non-tech companies that outsourced the development, and for internal systems in large organisations where the developers have been re-assigned to other projects. This is why technologies that assume active development, like containers, cloud APIs, etc are in my opinion a disaster in the making.

gtirloni 7y ago
Fully agree. I think it means small non-tech companies are better off sticking to SaaS offerings instead of rolling out their own (e.g. wordpress.com vs hosting your own). It's limiting in some cases but at least it's actively developed.
OJFord 7y ago
> This is why technologies that assume active development, like containers, cloud APIs, etc are in my opinion a disaster in the making. I assume you mean because the API might change under your feet, but containers?
- cm2187 7y ago
  Because to update the components of a container you need to recreate it from source image, assuming where you took the source image from will have been updated 10y later, and assuming someone will have both the knowledge and the right version of the tools to deploy your container. And if you have a container orchestration ecosystem then we are in cloud API territory. (Change and deprecated)
russellendicott 7y ago
> This is why technologies that assume active development, like containers, cloud APIs, etc are in my opinion a disaster in the making. I can agree with this. I've already been burned a few times _by my own tools_ trying to push an update 8 months after building it the first time. A docker build as part of my CI/CD will download some new package and bork everything. I know that this can be prevented with pinning, container registries, etc. but I often don't build all of that overhead into these stupid little web services. I know this may cause immeasurable pain for someone in the future but there's only so much time in a day. If this was just some *nix box that "just worked" and never got patched it would probably work better long term.
- rodw 7y ago
  > A docker build as part of my CI/CD will download some new package and bork everything. Really? I'm not much of an ops guy but that's precisely the problem docker _fixed_ for me. We must have very different usage patterns. I used to think bare linux guy, but when I finally bit the bullet and first fully dockerized the personal stuff I was working on at the time was after the Nth time of running into library/service version problems every time I stood up a new AWS (plain-linux EC2) instance. In fairness I never really "pinned" to specific AWI, which was probably the root of my problem, but, you know, security updates and stuff seem helpful. But every time I installed on a fresh box I'd run into incompatibilities with really core, basic stuff (it seemed to me) like PostgreSQL versions and so on. I'm still not much an ops guy, but version/install/configuration stability is by far the most appealing thing about docker for me personally. I do fair bit of audio and visual processing stuff, typically developed on Mac and deployed to Linux. With some services every 6 months I would need to hunt down some wholly new instructions for installing some third-degree dependency I was using (indirectly) and an entirely different set of build problems to work out when deploying to a (linux) server. But since switching to Docker I have had little to no (surprise) compatibility problems. sox? alsa-utils? libvips? ffmpeg? I can't remember the last time I had one of those "oh no, I guess I need to spend 4 hours spelunking forum posts to figure out which precise combination of dependencies need to make this work like it did a week ago" moments. I am surprised by (a) how _few_ problems I have making sure that native-code-heavy A/V that runs in docker on my OSX laptop works without modification when I move to a headless linux server.

by cm2187 7y ago

gtirloni 7y ago

Fully agree. I think it means small non-tech companies are better off sticking to SaaS offerings instead of rolling out their own (e.g. wordpress.com vs hosting your own). It's limiting in some cases but at least it's actively developed.

OJFord 7y ago

> This is why technologies that assume active development, like containers, cloud APIs, etc are in my opinion a disaster in the making. I assume you mean because the API might change under your feet, but containers?

cm2187 7y ago
Because to update the components of a container you need to recreate it from source image, assuming where you took the source image from will have been updated 10y later, and assuming someone will have both the knowledge and the right version of the tools to deploy your container. And if you have a container orchestration ecosystem then we are in cloud API territory. (Change and deprecated)

russellendicott 7y ago

> This is why technologies that assume active development, like containers, cloud APIs, etc are in my opinion a disaster in the making. I can agree with this. I've already been burned a few times _by my own tools_ trying to push an update 8 months after building it the first time. A docker build as part of my CI/CD will download some new package and bork everything. I know that this can be prevented with pinning, container registries, etc. but I often don't build all of that overhead into these stupid little web services. I know this may cause immeasurable pain for someone in the future but there's only so much time in a day. If this was just some *nix box that "just worked" and never got patched it would probably work better long term.

rodw 7y ago
> A docker build as part of my CI/CD will download some new package and bork everything. Really? I'm not much of an ops guy but that's precisely the problem docker _fixed_ for me. We must have very different usage patterns. I used to think bare linux guy, but when I finally bit the bullet and first fully dockerized the personal stuff I was working on at the time was after the Nth time of running into library/service version problems every time I stood up a new AWS (plain-linux EC2) instance. In fairness I never really "pinned" to specific AWI, which was probably the root of my problem, but, you know, security updates and stuff seem helpful. But every time I installed on a fresh box I'd run into incompatibilities with really core, basic stuff (it seemed to me) like PostgreSQL versions and so on. I'm still not much an ops guy, but version/install/configuration stability is by far the most appealing thing about docker for me personally. I do fair bit of audio and visual processing stuff, typically developed on Mac and deployed to Linux. With some services every 6 months I would need to hunt down some wholly new instructions for installing some third-degree dependency I was using (indirectly) and an entirely different set of build problems to work out when deploying to a (linux) server. But since switching to Docker I have had little to no (surprise) compatibility problems. sox? alsa-utils? libvips? ffmpeg? I can't remember the last time I had one of those "oh no, I guess I need to spend 4 hours spelunking forum posts to figure out which precise combination of dependencies need to make this work like it did a week ago" moments. I am surprised by (a) how _few_ problems I have making sure that native-code-heavy A/V that runs in docker on my OSX laptop works without modification when I move to a headless linux server.