11 ms·

I don't disagree that deploying Go or Rust apps (I think the author is wrong to include JVM in that bunch) is much nicer compared to ones where you rely on shar

I don't disagree that deploying Go or Rust apps (I think the author is wrong to include JVM in that bunch) is much nicer compared to ones where you rely on shared libraries system-wide, and may even remove the need for Docker. However, I think the author trivializes the amount of work required to make different types of Python/PHP/NodeJS/whatever apps all work in a consistent way through configuration management, saying "I can just write a bash script or makefile." or "just download roles from Ansible Galaxy". This is so painfully ignorant and irresponsible that I fail to take the article seriously as a whole. Even if it's just a Jenkins job doing a docker pull && docker run I've still seen massive improvements in the maintainability of configuration management code because there are so many fewer edge cases you have to take care of. No K8s required for that. The author, writing about languages like PHP and Python (and I assume NodeJS becuase it also works in a similar way, but he doesn't explicitly mention it for some reason): > They arose from an old paradigm, which is not suited to a world of microservices and distributed computing in the cloud. So just because they can't build a single static binary, they're not suitable for microservices and distributed computing. Got it... > If the switch away from Ruby/Python/Perl to a newer language and eco-system allows you to achieve massive scale with less technologies and less moving parts, then you absolutely have a professional obligation to do so. Wow it's that easy?! Be right back, re-writing all our code in Go over a weekend hackathon. This article made me angry.

danenania 8y ago
Yeah... I'm a big fan of both Go and Clojure, but they both easily lend themselves to over-engineering. When you have to consider time to market, rapid iteration, and other such annoyances, languages that optimize for developer productivity definitely have their place, and Docker is a huge win for working with interpreted languages.
- regularfry 8y ago
  Having been around that particular block in Ruby, and seen similar things happen in other languages, I'd say that the primary problem with them isn't that the interpreters or basic tech makes it difficult. It's that the community rallies round ways of doing things that don't focus on the "uberbinary" story, and the knowledge of how to do that sort of thing is not well distributed. For instance, it's not particularly hard to wrap everything from the app down to the ruby interpreter in a single directory that you can then drop into a .deb, but because deployment stories in the Ruby community, from at least Capistrano onwards, focused on getting the app code onto the server and then working from there, with all the problems that entails, the folk knowledge of how to do it just never spread that far. You had commonplace craziness like using RVM to install Ruby on the production servers because it was convenient, and once that mindset was embedded, the community as a whole (and I'm tarring with a very broad brush here, but it's not inaccurate) ignored simpler solutions that worked better, and didn't need tooling with as many points of failure. Bundler is another case in point: you just don't need it in production. Or at least, I never found it necessary past the build pipeline, and I think a lot of folk never found out whether they did or not. The point is, a lot of the apparent deployment difficulty in interpreted languages is entirely incidental and self-inflicted. Now, there is a real argument that Docker removes the need to learn all the ecosystem-specific folk knowledge you need to get to a point where you can do painless, sensible deployments in a new environment, but I think it's just moving the problem around.
  - forknore 8y ago
    Thank you for your comment, I'm very interested in deployments of Ruby applications that come as close as possible to a single binary. Do you have any pointers to the mentioned folk knowledge that you can share?
    - regularfry 8y ago
      There are a couple of different approaches you can take. The "traditional" way to do it would be something like exerb, which is a packager for building standalone Windows executables (although I'm not sure whether it works for recent rubies), and you literally end up with a single file. Similar ideas crop up every now and again. But that's not the only way to do it; it's in keeping with the "uberbinary" idea to have a single tarred up directory and a known entry-point, such that once that's copied to the server you don't need anything else, no post-install build steps to get running. I built something to do everything-but-the-interpreter a while ago: https://github.com/regularfry/au.git https://github.com/regularfry/au.git. The tricks that let these things work almost always boil down to knowing about the existence of a very few environment variables, and when in the build process you need them set to which values. `au` relies on $GEM_HOME, $GEM_PATH, and $PATH, and knowing what to do with $DESTDIR and `ruby-install` ought to get you a ruby interpreter as well (although `ruby-install` is just a shortcut to `make` in the MRI source). Where you'd look to learn that stuff now, I don't know.
endymi0n 8y ago
The point is: Even if you're using single, static binaries (like we do in 90% of cases with Go), the big benefit of Docker is that you don't just get a binary, you get a service interface. I can't stress this point enough. If you don't know what's up with a failing service, any SRE can go into the Dockerfile definition (actually, we're rarely dealing with Dockerfiles anymore, these days it's more the Kubernetes definition), look at which ports are exposed, what the environment variables are, what the service is talking to, etc. You can harden security between those services much tighter than between binaries, by dropping capabilities, seccomp, network policies, read-only file-systems. Also, all the other advice about the drawbacks is pretty dated: While I've run into my share of super annoying Docker problems myself in the early days (and yes, especially on Ubuntu, goodbye Device Mapper...), I've yet to encounter a single, Docker related bug on Google managed GKE on Container-Optimized OS since we've switched all of our services there a year ago. I didn't regret our choice in a very long time.
- aeorgnoieang 8y ago
  Does Docker itself make defining service interfaces easier than configuration management? I'd imagine that, e.g. a well-written Ansible module for an application could do all the things you mention.
  - lykr0n 8y ago
    Docker allows you to say "Application X" talks to "Application Y" and it will do the rest with minimal configuration. The same could be accomplished with Consul or Salt/Ansible/Puppet that knows about the services.
    - moosingin3space 8y ago
      Really? In my experience, that's been tooling on top of Docker that makes that sort of declarative networking easy.
      - lykr0n 8y ago
sjellis 8y ago
> However, I think the author trivializes the amount of work required to make different types of Python/PHP/NodeJS/whatever apps all work in a consistent way through configuration management, saying "I can just write a bash script or makefile." or "just download roles from Ansible Galaxy". This is so painfully ignorant and irresponsible that I fail to take the article seriously as a whole. He also trivializes the massive cost and difficulty of switching stacks. Even if a company can afford to upend their development processes to use a different language for new development, most of IT is legacy technology, and dynamic languages have been popular for long enough that legacy Python, Ruby and PHP applications are part of IT estates, just like legacy C++ and Java applications.
- the_new_guy_29 8y ago
  He also comlpletely negates the need of rewriting all of those "scripts" in case of a change in host provider.. None of modern companies is using own hosted servers because its simply too costly. Everyone is using cloud providers - now try to switch from one cloud provider to the other - all of those "scripts" would have to be rewritten top to bottom. I cant take this article seriously, its just some person refusing to adapt because "in my days we did it differently"
  - philliphaydon 8y ago
    If you’re using a cloud provider, using docker isn’t going to magically save you when switching providers cos chances are you’re using services of the cloud provider. Your code has to be rewritten. And in regards to scripts or docker. No you wouldn’t need to rewrite everything.
    - the_new_guy_29 8y ago
      Thats why you wrap them in api or rather your architect should. You can and abolutely should abstract yourself from cloud provider. Difference with Docker is that in case of such a move (already did that in my career) the amount of boilerplate you have to review and adjust is magnitudes lower than what he (OP) proposed in his article.
coldtea 8y ago
>However, I think the author trivializes the amount of work required to make different types of Python/PHP/NodeJS/whatever apps all work in a consistent way through configuration management, saying "I can just write a bash script or makefile." or "just download roles from Ansible Galaxy". This is so painfully ignorant and irresponsible that I fail to take the article seriously as a whole. Well, we did it that way for 2 decades without Docker, and the world hasn't collapsed, so?
- blowski 8y ago
  Should we do things in 2018 how we did them in 1998 just because it sort of worked in 1998? I say this as somebody who’s usually quite conservative in operations.
  - coldtea 8y ago
    >Should we do things in 2018 how we did them in 1998 just because it sort of worked in 1998? Well, if it ain't broken, don't fix it.
    - the_new_guy_29 8y ago
      Broken - no, tedious and resources consuming - hell yes
    - crehn 8y ago
      There’s a very fine line between painfully cumbersome and broken.
    - rsyntax 8y ago
      Just curious, do you still have/use a Nokia cell phone?
      - ForHackernews 8y ago
        Funnily enough, I had to send my smartphone in for repair recently, and I popped my SIM card back in my old Nokia phone that I'd kept in a drawer -- it works great. It's a 10+ year old device and the battery has lasted all week.
trumpeta 8y ago
I feel like the article doesn't spell out exactly what is wrong with Docker, only that its a Gamble and Dangerous, why? I understood the point that it may be an overkill for static binary deployments, but how is that dangerous?
- sametmax 8y ago
  The hype. Docker is an unifying interface. It's great at what it does: make a standard facade for app deployment, setup and service management. But it also comes at a cost. And as usual in the IT industry, the people using the tech sell it like a silver bullet, and avoid to tell you that: - docker is complex as a product and a concept - knowing how to run docker != knowing how to use docker properly. Remember the nosql debacle where people though they could not formalize their schema because the DB didn't enforce it ? Geeks love the circle of life. - docker is rarely alone, it will come up with an ecosystem that will creep in your stack. Like you never really do reactjs alone but soon find out you have 1000 plugins for a complex build system and you architecture depends on a flux implementation - most things just don't need docker. Dockers solves a technical and organizational scaling problem. If you don't have the problem, you don't need docker. Just like you probably don't need a blockchain for your new client reward policy. - docker is a LOT of new things to learn. Not only how to use it, but also how to do all the sysadmin things you used to do right, again, but with docker. Network management used to be a fun one. Not running as root again. Persisting data. - you will need something to install docker and the infra anyway. So you will not drop Ansible/Chef/Whatever. They will work together. - people use docker as an excuse to not do their job properly. No packaging, little doc, etc. "Just use the docker image". This one leads to bad times. - Not everyone uses docker. You don't live in a bubble. - Docker images are big huge binary you download from internet and run on your server. It's very painful to audit. And so easy to ignore. - The paradox of choice. So many things in the docker world. And it changes so fast. It's really hard to know what to use, and to keep up. I've seen many projects wasting time and resources just because of the docker setup. It's like those people setting up a distributed architecture for a job that takes 10 seconds to run as a bash script. Bottom line, if you think you need docker, don't use it. People needing it don't think they need it. They know they need it. And it's useful for them because they use it right.
sametmax 8y ago
Plus you can build a single static binary in Python using nuitka (http://nuitka.net/ http://nuitka.net/). Ok it's static against the python dependencies but dynamic against libc for the linux build, but I've never had to deploy to a server without libc. And if you know all your servers have the same Python version and your code is pure Python, you can even forget that and do a .pex (https://github.com/pantsbuild/pex https://github.com/pantsbuild/pex), which a the Python equivalent of Java .war : a zip that embeds all the program and dependencies. It's light, fast, and problem free basically.
- paulfurtado 8y ago
  Note that typically the problem isn't that a server lacks libc, but that it has too old of a version. For example, my company runs on CentOS 6, which comes with glibc 2.12. Software built against newer glibc versions will not link against it at run time, and this is frequently a problem. The easiest solution to this is to build on the oldest linux distro you plan to target
  - otabdeveloper1 8y ago
    > The easiest solution to this is to build on the oldest linux distro you plan to target No way. Just package your libraries with your executable: /my_path/ld-linux-x86-64.so.2 --library-path /my_path /my_path/my_binary
    - sametmax 8y ago
      Apparently nuitka's author considers it a bad idea and removed this feature: http://bugs.nuitka.net/issue136 http://bugs.nuitka.net/issue136
  - viraptor 8y ago
    And the funny part is that currently the easiest way to build against an older/different version of the OS without being forced into the "prod env = dev env" situation is... to use docker or any other container solution.
davedx 8y ago
> make different types of Python/PHP/NodeJS/whatever apps all work in a consistent way through configuration management Do you typically deploy all of these technologies into one VM in production? I don't think I understand the scenario being suggested here. (I'm experienced with Ansible but not Docker or Kubernetes)
- raziel2p 8y ago
  Whether it's one VM or multiple, you still have to write the configuration management code (Puppet modules, Ansible roles...) to do so, and some of them will need tweaking for specific applications (e.g. in Python, installing libxml or libmysqlclient for pip dependencies, in PHP installing the various dynamically loaded extensions), which is where the rabbithole of complexity begins.
randomsearch 8y ago
> If the switch away from Ruby/Python/Perl to a newer language and eco-system allows you to achieve massive scale with less technologies and less moving parts, then you absolutely have a professional obligation to do so. To add: this is wrong from another perspective. There are more goals than "massive scale" in software development. Your main costs are wages, so anything that allows programmers to be much more productive (or cheap!) is good for your business. Therefore, settling on something like Python makes sense if you can leverage its ecosystem and the wide availability of the relevant skillsets. I won't be switching to Go until its ecosystem and popularity can compete with older languages.
brightball 8y ago
I agree with you for the most part, but one thing I'd throw out is that Ansible is making this conversation more interesting thanks to Ansible Container. Just from an ops perspective, if I can use Ansible to provision infrastructure, configure bare metal, configure VMs and build containers (Docker/LXC/LXD)...all of a sudden life gets easier - especially for keeping the containers themselves up to date.
- raziel2p 8y ago
  Configuration management software is good to have for managing servers because 1) they are mutable, 2) you're not always building from scratch, and 3) you may have to support many different environments (different distros, distro versions, exact same distro with different packages installed...). Containers get rid of all these problems: Your images are immutable, you can always build from scratch, and you have full control of what goes in the image. Because of this, a plain shell script or something like Dockerfile is much simpler and easier to reason about. I really don't see the point in Ansible Container.
  - brightball 8y ago
    Containers break the problem into subsets. All Ansible does is run shell scripts.
mamcx 8y ago
> If the switch away from ... a newer language and eco-system allows you to achieve massive scale with less technologies and less moving parts, then you absolutely have a professional obligation to do so. Read this again. It make total sense. Eventually, some path become running against the current, and then the better path is move to something else. And what about that millons-of-lines of code? Is the same thing as "what about all the investment in money with that inneficient car that eat gasoline like is not a tomorrow, I push so much on it but the new tech is far more efficient?, and you tell me, let that in the past?" Yes. You put that millons-of-lines in the past and rebuild. If you have the correct mindset the change will pay off GREATLY... P.D: I do this for work several times in my life, With very drastic/radical changes. In fact, the MORE RADICAL the BEST. "Small" changes are not worth it. The $$$ is not there. But when you do a hard change is when the benefits get more evident...

danenania 8y ago

Yeah... I'm a big fan of both Go and Clojure, but they both easily lend themselves to over-engineering. When you have to consider time to market, rapid iteration, and other such annoyances, languages that optimize for developer productivity definitely have their place, and Docker is a huge win for working with interpreted languages.

regularfry 8y ago
Having been around that particular block in Ruby, and seen similar things happen in other languages, I'd say that the primary problem with them isn't that the interpreters or basic tech makes it difficult. It's that the community rallies round ways of doing things that don't focus on the "uberbinary" story, and the knowledge of how to do that sort of thing is not well distributed. For instance, it's not particularly hard to wrap everything from the app down to the ruby interpreter in a single directory that you can then drop into a .deb, but because deployment stories in the Ruby community, from at least Capistrano onwards, focused on getting the app code onto the server and then working from there, with all the problems that entails, the folk knowledge of how to do it just never spread that far. You had commonplace craziness like using RVM to install Ruby on the production servers because it was convenient, and once that mindset was embedded, the community as a whole (and I'm tarring with a very broad brush here, but it's not inaccurate) ignored simpler solutions that worked better, and didn't need tooling with as many points of failure. Bundler is another case in point: you just don't need it in production. Or at least, I never found it necessary past the build pipeline, and I think a lot of folk never found out whether they did or not. The point is, a lot of the apparent deployment difficulty in interpreted languages is entirely incidental and self-inflicted. Now, there is a real argument that Docker removes the need to learn all the ecosystem-specific folk knowledge you need to get to a point where you can do painless, sensible deployments in a new environment, but I think it's just moving the problem around.
- forknore 8y ago
  Thank you for your comment, I'm very interested in deployments of Ruby applications that come as close as possible to a single binary. Do you have any pointers to the mentioned folk knowledge that you can share?
  - regularfry 8y ago
    There are a couple of different approaches you can take. The "traditional" way to do it would be something like exerb, which is a packager for building standalone Windows executables (although I'm not sure whether it works for recent rubies), and you literally end up with a single file. Similar ideas crop up every now and again. But that's not the only way to do it; it's in keeping with the "uberbinary" idea to have a single tarred up directory and a known entry-point, such that once that's copied to the server you don't need anything else, no post-install build steps to get running. I built something to do everything-but-the-interpreter a while ago: https://github.com/regularfry/au.git https://github.com/regularfry/au.git. The tricks that let these things work almost always boil down to knowing about the existence of a very few environment variables, and when in the build process you need them set to which values. `au` relies on $GEM_HOME, $GEM_PATH, and $PATH, and knowing what to do with $DESTDIR and `ruby-install` ought to get you a ruby interpreter as well (although `ruby-install` is just a shortcut to `make` in the MRI source). Where you'd look to learn that stuff now, I don't know.

endymi0n 8y ago

The point is: Even if you're using single, static binaries (like we do in 90% of cases with Go), the big benefit of Docker is that you don't just get a binary, you get a service interface. I can't stress this point enough. If you don't know what's up with a failing service, any SRE can go into the Dockerfile definition (actually, we're rarely dealing with Dockerfiles anymore, these days it's more the Kubernetes definition), look at which ports are exposed, what the environment variables are, what the service is talking to, etc. You can harden security between those services much tighter than between binaries, by dropping capabilities, seccomp, network policies, read-only file-systems. Also, all the other advice about the drawbacks is pretty dated: While I've run into my share of super annoying Docker problems myself in the early days (and yes, especially on Ubuntu, goodbye Device Mapper...), I've yet to encounter a single, Docker related bug on Google managed GKE on Container-Optimized OS since we've switched all of our services there a year ago. I didn't regret our choice in a very long time.

aeorgnoieang 8y ago
Does Docker itself make defining service interfaces easier than configuration management? I'd imagine that, e.g. a well-written Ansible module for an application could do all the things you mention.
- lykr0n 8y ago
  Docker allows you to say "Application X" talks to "Application Y" and it will do the rest with minimal configuration. The same could be accomplished with Consul or Salt/Ansible/Puppet that knows about the services.
  - moosingin3space 8y ago
    Really? In my experience, that's been tooling on top of Docker that makes that sort of declarative networking easy.
    - lykr0n 8y ago

sjellis 8y ago

> However, I think the author trivializes the amount of work required to make different types of Python/PHP/NodeJS/whatever apps all work in a consistent way through configuration management, saying "I can just write a bash script or makefile." or "just download roles from Ansible Galaxy". This is so painfully ignorant and irresponsible that I fail to take the article seriously as a whole. He also trivializes the massive cost and difficulty of switching stacks. Even if a company can afford to upend their development processes to use a different language for new development, most of IT is legacy technology, and dynamic languages have been popular for long enough that legacy Python, Ruby and PHP applications are part of IT estates, just like legacy C++ and Java applications.

the_new_guy_29 8y ago
He also comlpletely negates the need of rewriting all of those "scripts" in case of a change in host provider.. None of modern companies is using own hosted servers because its simply too costly. Everyone is using cloud providers - now try to switch from one cloud provider to the other - all of those "scripts" would have to be rewritten top to bottom. I cant take this article seriously, its just some person refusing to adapt because "in my days we did it differently"
- philliphaydon 8y ago
  If you’re using a cloud provider, using docker isn’t going to magically save you when switching providers cos chances are you’re using services of the cloud provider. Your code has to be rewritten. And in regards to scripts or docker. No you wouldn’t need to rewrite everything.
  - the_new_guy_29 8y ago
    Thats why you wrap them in api or rather your architect should. You can and abolutely should abstract yourself from cloud provider. Difference with Docker is that in case of such a move (already did that in my career) the amount of boilerplate you have to review and adjust is magnitudes lower than what he (OP) proposed in his article.

coldtea 8y ago

blowski 8y ago
Should we do things in 2018 how we did them in 1998 just because it sort of worked in 1998? I say this as somebody who’s usually quite conservative in operations.
- coldtea 8y ago
  >Should we do things in 2018 how we did them in 1998 just because it sort of worked in 1998? Well, if it ain't broken, don't fix it.
  - the_new_guy_29 8y ago
    Broken - no, tedious and resources consuming - hell yes
  - crehn 8y ago
    There’s a very fine line between painfully cumbersome and broken.
  - rsyntax 8y ago
    Just curious, do you still have/use a Nokia cell phone?
    - ForHackernews 8y ago
      Funnily enough, I had to send my smartphone in for repair recently, and I popped my SIM card back in my old Nokia phone that I'd kept in a drawer -- it works great. It's a 10+ year old device and the battery has lasted all week.

trumpeta 8y ago

I feel like the article doesn't spell out exactly what is wrong with Docker, only that its a Gamble and Dangerous, why? I understood the point that it may be an overkill for static binary deployments, but how is that dangerous?

sametmax 8y ago
The hype. Docker is an unifying interface. It's great at what it does: make a standard facade for app deployment, setup and service management. But it also comes at a cost. And as usual in the IT industry, the people using the tech sell it like a silver bullet, and avoid to tell you that: - docker is complex as a product and a concept - knowing how to run docker != knowing how to use docker properly. Remember the nosql debacle where people though they could not formalize their schema because the DB didn't enforce it ? Geeks love the circle of life. - docker is rarely alone, it will come up with an ecosystem that will creep in your stack. Like you never really do reactjs alone but soon find out you have 1000 plugins for a complex build system and you architecture depends on a flux implementation - most things just don't need docker. Dockers solves a technical and organizational scaling problem. If you don't have the problem, you don't need docker. Just like you probably don't need a blockchain for your new client reward policy. - docker is a LOT of new things to learn. Not only how to use it, but also how to do all the sysadmin things you used to do right, again, but with docker. Network management used to be a fun one. Not running as root again. Persisting data. - you will need something to install docker and the infra anyway. So you will not drop Ansible/Chef/Whatever. They will work together. - people use docker as an excuse to not do their job properly. No packaging, little doc, etc. "Just use the docker image". This one leads to bad times. - Not everyone uses docker. You don't live in a bubble. - Docker images are big huge binary you download from internet and run on your server. It's very painful to audit. And so easy to ignore. - The paradox of choice. So many things in the docker world. And it changes so fast. It's really hard to know what to use, and to keep up. I've seen many projects wasting time and resources just because of the docker setup. It's like those people setting up a distributed architecture for a job that takes 10 seconds to run as a bash script. Bottom line, if you think you need docker, don't use it. People needing it don't think they need it. They know they need it. And it's useful for them because they use it right.

sametmax 8y ago

Plus you can build a single static binary in Python using nuitka (http://nuitka.net/ http://nuitka.net/). Ok it's static against the python dependencies but dynamic against libc for the linux build, but I've never had to deploy to a server without libc. And if you know all your servers have the same Python version and your code is pure Python, you can even forget that and do a .pex (https://github.com/pantsbuild/pex https://github.com/pantsbuild/pex), which a the Python equivalent of Java .war : a zip that embeds all the program and dependencies. It's light, fast, and problem free basically.

paulfurtado 8y ago
Note that typically the problem isn't that a server lacks libc, but that it has too old of a version. For example, my company runs on CentOS 6, which comes with glibc 2.12. Software built against newer glibc versions will not link against it at run time, and this is frequently a problem. The easiest solution to this is to build on the oldest linux distro you plan to target
- otabdeveloper1 8y ago
  > The easiest solution to this is to build on the oldest linux distro you plan to target No way. Just package your libraries with your executable: /my_path/ld-linux-x86-64.so.2 --library-path /my_path /my_path/my_binary
  - sametmax 8y ago
    Apparently nuitka's author considers it a bad idea and removed this feature: http://bugs.nuitka.net/issue136 http://bugs.nuitka.net/issue136
- viraptor 8y ago
  And the funny part is that currently the easiest way to build against an older/different version of the OS without being forced into the "prod env = dev env" situation is... to use docker or any other container solution.

davedx 8y ago

> make different types of Python/PHP/NodeJS/whatever apps all work in a consistent way through configuration management Do you typically deploy all of these technologies into one VM in production? I don't think I understand the scenario being suggested here. (I'm experienced with Ansible but not Docker or Kubernetes)

raziel2p 8y ago
Whether it's one VM or multiple, you still have to write the configuration management code (Puppet modules, Ansible roles...) to do so, and some of them will need tweaking for specific applications (e.g. in Python, installing libxml or libmysqlclient for pip dependencies, in PHP installing the various dynamically loaded extensions), which is where the rabbithole of complexity begins.

randomsearch 8y ago

> If the switch away from Ruby/Python/Perl to a newer language and eco-system allows you to achieve massive scale with less technologies and less moving parts, then you absolutely have a professional obligation to do so. To add: this is wrong from another perspective. There are more goals than "massive scale" in software development. Your main costs are wages, so anything that allows programmers to be much more productive (or cheap!) is good for your business. Therefore, settling on something like Python makes sense if you can leverage its ecosystem and the wide availability of the relevant skillsets. I won't be switching to Go until its ecosystem and popularity can compete with older languages.

brightball 8y ago

I agree with you for the most part, but one thing I'd throw out is that Ansible is making this conversation more interesting thanks to Ansible Container. Just from an ops perspective, if I can use Ansible to provision infrastructure, configure bare metal, configure VMs and build containers (Docker/LXC/LXD)...all of a sudden life gets easier - especially for keeping the containers themselves up to date.

raziel2p 8y ago
Configuration management software is good to have for managing servers because 1) they are mutable, 2) you're not always building from scratch, and 3) you may have to support many different environments (different distros, distro versions, exact same distro with different packages installed...). Containers get rid of all these problems: Your images are immutable, you can always build from scratch, and you have full control of what goes in the image. Because of this, a plain shell script or something like Dockerfile is much simpler and easier to reason about. I really don't see the point in Ansible Container.
- brightball 8y ago
  Containers break the problem into subsets. All Ansible does is run shell scripts.

mamcx 8y ago

> If the switch away from ... a newer language and eco-system allows you to achieve massive scale with less technologies and less moving parts, then you absolutely have a professional obligation to do so. Read this again. It make total sense. Eventually, some path become running against the current, and then the better path is move to something else. And what about that millons-of-lines of code? Is the same thing as "what about all the investment in money with that inneficient car that eat gasoline like is not a tomorrow, I push so much on it but the new tech is far more efficient?, and you tell me, let that in the past?" Yes. You put that millons-of-lines in the past and rebuild. If you have the correct mindset the change will pay off GREATLY... P.D: I do this for work several times in my life, With very drastic/radical changes. In fact, the MORE RADICAL the BEST. "Small" changes are not worth it. The $$$ is not there. But when you do a hard change is when the benefits get more evident...