7 ms·

Launch Your App: Why We Don’t Use Docker (We Don’t Need It)

87 points by wheresvic4 5y ago

jayd16 5y ago
I feel like this is one of those articles meant to convince the author most of all.
void_mint 5y ago
> Building is as easy as: > go build > Testing is as easy as > go test > Deploying the app is as easy as: > scp app user@host: > ssh user@host “nohup ./app” I suppose we'll see in 1-3 years whether the decision to skip any/all build and deploy tools in favor of staking a business on someone scp'ing to prod servers was a good idea. I have a very strong assumption, but who knows.
- SteveNuts 5y ago
  In the "our business teeters on the edge of solvency every month" stage of a company lifecycle, does it really matter that much? Plus the article never mentions "we'll never need to add more ci/cd", they're simply saying they don't need it right now.
  - simonjgreen 5y ago
    Just to re-enforce this, this article is all about context. It's making it very clear that in this organisations context this method of deployment and production is absolutely fine. And that's the key thing, you can keep things this simple for as long as your risk assessment says so. The key for me is making sure you are taking the time to reassess those early life decisions so when the time comes you can course-adjust
- simonjgreen 5y ago
  I'm pretty sure we've already answered that question over the last 20-30 years, and it turns out that in most cases: yes, it's absolutely fine.
- wizzwizz4 5y ago
  Yeah, we should use deploy tools instead. $ cat deploy.sh #!/bin/sh scp app user@host; ssh user@host "nohup ./app" At some point you have to use something to get it to the production server. Why not scp?
  - viraptor 5y ago
    Because push instead of pull deployment means reboots and now servers have to be handled manually. Because this way doesn't leave explicit audit/deployment logs.
  - void_mint 5y ago
    The reason to use build and deployment tools has nothing to do with _how_ the tools actually work. Deployment issues are mostly issues of consistency and access. Who runs the build/deploy, from where, with what arguments, when? Using a CI/CD pipeline isn't just wrapping an scp call in a bash script, they provide tools for managing the when, the where, the why. Do you think using only scp will prevent you from deploying the wrong artifact? Or deploying to all-but-one production node? Or scping but forgetting to run the nohup? Honestly setting up a github action to do this takes very little time, doesn't depend on containers, doesn't really add complexity to your stack. CircleCI exists and is equally easy. To suggest that your above-posted script is just as good is, to me, mostly just NIH + developer bikeshedding. YAGNI is great for being honest about the needs of an org and ignoring tools or frameworks that aren't appropriate, but there really are tools that exist that add consistency in ways that don't really increase complexity all that much.
- Jiejeing 5y ago
  Down the road, pulling the binary in a container for deployment is trivial, so I don’t see a downside here. Of course nobody will advocate that scping a binary on each production server for deployment is viable in the long run, but that should not be your primary concern when going through the early phases of a product. Not focusing on docker from the start forces you to have a clean build and runtime software chain, and reduces the amount of magic required (ironically, going to containers was supposed to be the opposite, but many server-side packages are now docker-only because the build and/or runtime requirements are so messed up, e.g. discourse).
  - jayd16 5y ago
    I just don't get it. Docker is just not that hard to set up. It takes a day or two and you get a lot of flexibility you can use down the line. Sure you could convert later, but now you have to move your whole workflow over during a time you're in dire need of the new features instead of casually from the start. Now instead of your artifact history being consistent, its truncated at the point you switched over. I guess I don't understand whats so complicated about docker?
    - dijit 5y ago
      Bridge networking, probably. Overlay filesystem performance across distros? Attaching a debugger to a process? Idk. Just some ideas off the top of my head. I don’t think it’s unimaginable to consider how docker is an increase in complexity and understanding.
      - akvadrako 5y ago
        > Bridge networking, probably. You can just use --net=host if you don't like it. > Overlay filesystem performance across distros? I've used docker on several distros and never noticed an issue with this. > Attaching a debugger to a process? This is also not an issue if you don't use bridge networking.
      - trinovantes 5y ago
        Getting VSCode debugger to hook into a process running in a docker container running inside WSL was insanely frustrating. In the end, I stopped using Docker during development and only use it for deploying to staging/production.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- grogenaut 5y ago
  Twitch made it to acquisition with amazon with basically this system for both a rails app and about 20 other go apps. I'd know, I helped transition us to ecs later. For go apps, docker isn't really doing much over golang binaries. The bigger transition was more just moving us away from any unneeded dependence on system level apps. This happened at the same time we were dockerizing. I think the ECS abstraction is better than the simple daemon scripts we were using and scp for deploys, but we made it work up to around 30k servers before we hit scale limits. We could have pretty easily taken it even further forward but ecs is simpler and better integrated with the rest of AWS and our build tools. It only matters for a few special teams. The real issue with SCP at some point was the parallelism of deploys: opening 30k ssh connections single threaded or with bash starts bogging down at some point, and we were at the point of writing a massively parallel version when we switched to ECS for much of this (also around the time ECS became stable).
  - void_mint 5y ago
    I posted below, but to me this post isn't really about Docker at all, as are my issues with it. You don't need to use Docker to see the need for sane build and deploy tooling. Who is running this scp? Where do they get the build? Do they have to know which hosts to scp to? Questions/problems like this are not solved at all, which generally need to be solved one way or another to scale any production system.
    - grogenaut 5y ago
      This was years ago. it was bare metal. The answer was that it got the exe from the build machine which it was running from. It knew where to deploy as we were on bare metal and used consul to list the hosts.
- dehrmann 5y ago
  I'd almost argue that the main benefit to not using docker at a scale where scp works is you won't be tempted to use kubernetes.
A-Train 5y ago
At my startup we do the same but with Rust. All the reasons stand. Insanely fast, self contained (web service / embedded UI with static js/html). Could not be happier with the architecture. I wrote it about it here if anyone interested https://logicai.io/blog/recommendation-systems-in-rust/ https://logicai.io/blog/recommendation-systems-in-rust/.
yberreby 5y ago
If you can make your app fit in a single binary and you do not _need_ Docker's features, then yes, I don't see why you'd bother using it. Docker shouldn't be your immediate go-to. It's just another tool that can help with some problems. Things do become more complicated when your app is a single logical unit that depends on a number of resources / services. Maybe you want an nginx reverse proxy in front of it, a database engine behind it; maybe Go isn't the only language you're going to use. Maybe you want the ability to effortlessly run the exact same setup as your production environment somewhere else without having to run a bunch of Ansible playbooks on the target host, and without worrying about the Linux distribution on it. Docker and docker-compose can help with these use-cases and get you up and running quickly. I'm not saying Docker is ever a _necessity_. But it can be a great convenience. In the end, use the simplest solution that fits your requirements, and make sure you can extend it later on if those requirements change.
ok123456 5y ago
A lot of modern tooling has come from people using microservices instead of making libraries. If you actually just write libraries it turns out you don't need to solve distributed systems problems, orchestration and configuration management as part of your normal development cycle.
ex_amazon_sde 5y ago
> we did get a little more complicated and create a SystemD script to launch it at startup If only there was a tool to: - bundle, distribute and deploy applications - ...and configuration files - ...and systemd unit files - ...even directories containing a Python virtualenv - keep track of what is installed and in what version - roll forward or roll back I would call it Advanced Packaging Tool.
- joecot 5y ago
  This is the normal progression. A new technology comes along, and folks are so happy to use it everywhere that they teach new people to use it, without any understanding of why it's useful or what it was made to fix. And they have little to no understanding of the ecosystem that preceded it. I watched it happen with virtualization. Everyone was so hyped about virtualization that everything was run in VMs. Later there was a counterrevolution of folks going "hey, we discovered that running things on bare metal servers is a thing you can do, and it's way faster and cheaper", a push that has mostly died out now that virtualization has hit near bare metal performance anyway and cloud hosting is the norm. But that counterrevolution happened because everyone embraced VMs and cloud services without dwelling on its actual use case, or in what cases it was an improvement over bare metal hosting. I watched similar happen with both the NoSQL and Serverless revolutions, and now we're watching it with containers. So yes, this would be better setup as a deb package, or deployed as part of a cloudinit startup script or similar. But if you came in when everyone was just shoving docker down each other's throats, you don't know what stages there were before that, and which one is the most appropriate one for your use.
primitivesuave 5y ago
The main reason I push for Docker containers is that it's a universally-understood encapsulation of an app or service amongst technical and non-technical people alike. "I'll have John write a Docker service that handles the integration" is an easy goal for both management and John to understand. Behind the scenes, we can use some fancy deployment or just run it on a single machine like the author describes. I would definitely not be okay with an engineer in my organization telling me their plan is to ignore CI/CD, especially in the present age where GitHub Actions is trivially easy to set up, and rather set up some custom procedure over SSH. Technical choices aside, it fails the "hit by a bus" test - if you disappear for some reason, or even just your laptop gets stolen, does the company grind to a halt?
- Toutouxc 5y ago
  > if you disappear for some reason, or even just your laptop gets stolen, does the company grind to a halt As in, no one in the whole company knows how to scp a binary?
  - saurik 5y ago
    To be fair, scp was officially deprecated: it is effectively "legacy knowledge" now, and so soon it will be difficult to find anyone who can use it effectively. https://lwn.net/Articles/835962/ https://lwn.net/Articles/835962/ In contrast, we all know that knowledge of the Docker container format is both universal and likely to "stand the test of time". That anyone would believe that merely downloading a binary and then running it directly could ever be easier than first downloading and installing Docker so that you can then run docker on yet another file clearly has never worked as a systems administrator.
    - minusf 5y ago
      if the app in question can be installed by dropping some files on some servers, how could another full layer of abstraction be easier? an encapsulation is by definition adding complexity.
    - deleted 5y ago
imiric 5y ago
> But we have software we need to ship in order to get users in order to drive subscriptions. Anything that doesn’t directly serve that goal is a complication. I think you're only seeing Docker as a packaging format and missing the distribution aspect. There's a lot of value in telling users "My app is accessible with a single `docker run` command", that doesn't involve them downloading a standalone binary manually, placing it in their PATH, etc., and also works across platforms and operating systems. Or worse, having to setup the Go toolchain and compile it themselves, no matter how easy it is for a developer (and ignoring what can go wrong with Go modules). Of course, then you open yourself up to all sorts of support questions related to Docker, but I still think it's a missed opportunity to not use it to make your software as widely and most easily accessible as possible.
- matsemann 5y ago
  Good point for services being installed. Especially when I'm just testing something I don't want to see a full page on how to get it up and running, or even care about the underlying tech. Just give me a docker oneliner. Doesn't have to be the standard way of distributing the app, but at least make a simple image for local testing / development. Tested RabbitMQ this weekend, and the getting started was soo easy.
- nicoburns 5y ago
  > and also works across platforms and operating systems As a mac user, I'm not sure I agree with this. Docker does technically work cross platform of course. But it's slow everywhere except for linux. I'd much rather have binary (or even better a `brew install`) than a docker image.
  - j0ba 5y ago
    Lol no. Docker is only slow on Mac. It works great on all other platforms.
    - carlmr 5y ago
      It was slow on Windows to run Linux images the last time I tried. I think they now use WSL2 making it faster, but I haven't used it since.
watermelon0 5y ago
> No, the reason we went with go was because golang’s packaging is so much better than node. Or java. Or C#. We get a single binary. Same can be achieved with node/java/C#. There are 3rd party tools to achieve this for many languages, but at least dotnet has this option built-in: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single-file-executables https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotne...
- fiddlerwoaroof 5y ago
  Yeah, fat jars in Java has been a thing for years and, IMO, docker for Java is unnecessary overhead: if you need _containers_, use something like Google’s jib to turn your fat jar into an OCI container.
twic 5y ago
I've used pretty much this approach at a couple of places, mostly working with Java. A production server is a vanilla Red Hat machine with an aftermarket JDK at a known path. The deployment artifact is a zip file containing jar files (and anything else) and a shell script called run.sh. Deployment is copying, unzipping, and overwriting a symlink. A cron job or a systemd etc service starts it. CI is a cron job which pulls, runs build.sh, and copies build/distribution to an NFS server. It works.
- madhadron 5y ago
  You can also build a fat jar, which is basically a zip file containing everything but that the JVM knows how to load. All the static assets can go in there, too. It saves you the build.sh.
  - regularfry 5y ago
    I thought recent JDKs had the tools to build executable jars with the JVM built in. Can't find a reference now, though.
    - kondu 5y ago
      Perhaps you're talking about jpackage - https://openjdk.java.net/jeps/392 https://openjdk.java.net/jeps/392
      - regularfry 5y ago
        That sounds close, but I thought you got a plain executable out rather than an installer.
  - twic 5y ago
    The build.sh is how CI builds the project from source. I suppose you meant that it saves the run.sh - but it doesn't, because you still have to give the path to the JDK, and any JVM command line arguments you want. Honestly, i've never really got the point of fat jars. Fat jars come with all sorts of annoyances (what do you do with the manifests from each jar?). Unpacking a zip is not hard.
FpUser 5y ago
Similar to what I do, only I use C++ instead of Go and CMake / make instead of Go Build. Vertical scalability is stellar and exceeds any realistic expectation my own business or those of my clients.
kristiandupont 5y ago
I am all for keeping complexities at a minimum and it's great that it's working for them. However, Docker is so simple to work with and so valuable in what it delivers that a headline like this reads to me a bit like "We don't need git". Sure, you might not need it. But it would probably be nice.
dkarras 5y ago
From the comments, it looks like they aren't even using a database and storing data client side ("to be stateless" they say). I don't know what kind of application they are serving but that has a whole can of complications. They are trying to make money yet I assume they don't have accounts etc. That's a bit overkill. So, no database, a single web service, yeah you might not need docker or alike. Depending on their use case they might need high availability so a backup server with a failover would be nice of course, ideally kicking in automatically and doing the necessary notifications.
great_reversal 5y ago
This was posted previously a couple weeks/months ago.
mxmasster 5y ago
More people need to do this. Focus on growing your business not optimizing your pipeline.
minusf 5y ago
> This might end up getting a lot of hate. no hate from me. it's perfectly fine to run one's stuff without docker.
easton 5y ago
I don't know, learning Docker probably took me a while, but now that I know how to do it I can spit out a Dockerfile in like five minutes (especially because most of the time its "FROM language COPY app RUN ./build.sh COMMAND ./app" unless you want to get fancy with multi container builds), and a docker-compose for single-server or workstation usage (which is all my hobbies amount to) in 15. The longest time I've spent writing a Dockerfile (because I was trying to build a gigantic Rails app where their build instructions were wrong) was probably a couple hours. I can understand not wanting to take the time to learn it because growing a business, but if you know how to write a bash script you'll probably pick it up in like a few hours, once. It's not like we're talking about k8s or something, which I can understand not wanting to immerse yourself in for weeks only to wonder why you didn't just pay for Heroku and hire an ops guy in a year to get off of it.
kissgyorgy 5y ago
X rant about technology Z because they don't understand it. Of course Docker is not simpler, because you can do so much more with it than copying a single stateless binary to a single machine...
NilsIRL 5y ago
Previous discussion: https://news.ycombinator.com/item?id=26472452 https://news.ycombinator.com/item?id=26472452
codegeek 5y ago
Interesting. I wrote an Internal Go Application (not very mission critical) and i literally deployed the binary using supervisor and nginx as a proxy in front. A quick scp command as needed for changes down the line.
jchook 5y ago
This works for their particular use case because their server doesn't even have a database. It doesn't address runtime configuration like remote hosts, passwords, etc. It doesn't even address the difference between provisioning and deploying a host.

87 points by wheresvic4 5y ago

I feel like this is one of those articles meant to convince the author most of all.

> Building is as easy as: > go build > Testing is as easy as > go test > Deploying the app is as easy as: > scp app user@host: > ssh user@host “nohup ./app” I suppose we'll see in 1-3 years whether the decision to skip any/all build and deploy tools in favor of staking a business on someone scp'ing to prod servers was a good idea. I have a very strong assumption, but who knows.

SteveNuts 5y ago
In the "our business teeters on the edge of solvency every month" stage of a company lifecycle, does it really matter that much? Plus the article never mentions "we'll never need to add more ci/cd", they're simply saying they don't need it right now.
- simonjgreen 5y ago
  Just to re-enforce this, this article is all about context. It's making it very clear that in this organisations context this method of deployment and production is absolutely fine. And that's the key thing, you can keep things this simple for as long as your risk assessment says so. The key for me is making sure you are taking the time to reassess those early life decisions so when the time comes you can course-adjust
simonjgreen 5y ago
I'm pretty sure we've already answered that question over the last 20-30 years, and it turns out that in most cases: yes, it's absolutely fine.
wizzwizz4 5y ago
Yeah, we should use deploy tools instead. $ cat deploy.sh #!/bin/sh scp app user@host; ssh user@host "nohup ./app" At some point you have to use something to get it to the production server. Why not scp?
- viraptor 5y ago
  Because push instead of pull deployment means reboots and now servers have to be handled manually. Because this way doesn't leave explicit audit/deployment logs.
- void_mint 5y ago
  The reason to use build and deployment tools has nothing to do with _how_ the tools actually work. Deployment issues are mostly issues of consistency and access. Who runs the build/deploy, from where, with what arguments, when? Using a CI/CD pipeline isn't just wrapping an scp call in a bash script, they provide tools for managing the when, the where, the why. Do you think using only scp will prevent you from deploying the wrong artifact? Or deploying to all-but-one production node? Or scping but forgetting to run the nohup? Honestly setting up a github action to do this takes very little time, doesn't depend on containers, doesn't really add complexity to your stack. CircleCI exists and is equally easy. To suggest that your above-posted script is just as good is, to me, mostly just NIH + developer bikeshedding. YAGNI is great for being honest about the needs of an org and ignoring tools or frameworks that aren't appropriate, but there really are tools that exist that add consistency in ways that don't really increase complexity all that much.
Jiejeing 5y ago
Down the road, pulling the binary in a container for deployment is trivial, so I don’t see a downside here. Of course nobody will advocate that scping a binary on each production server for deployment is viable in the long run, but that should not be your primary concern when going through the early phases of a product. Not focusing on docker from the start forces you to have a clean build and runtime software chain, and reduces the amount of magic required (ironically, going to containers was supposed to be the opposite, but many server-side packages are now docker-only because the build and/or runtime requirements are so messed up, e.g. discourse).
- jayd16 5y ago
  I just don't get it. Docker is just not that hard to set up. It takes a day or two and you get a lot of flexibility you can use down the line. Sure you could convert later, but now you have to move your whole workflow over during a time you're in dire need of the new features instead of casually from the start. Now instead of your artifact history being consistent, its truncated at the point you switched over. I guess I don't understand whats so complicated about docker?
  - dijit 5y ago
    Bridge networking, probably. Overlay filesystem performance across distros? Attaching a debugger to a process? Idk. Just some ideas off the top of my head. I don’t think it’s unimaginable to consider how docker is an increase in complexity and understanding.
    - akvadrako 5y ago
      > Bridge networking, probably. You can just use --net=host if you don't like it. > Overlay filesystem performance across distros? I've used docker on several distros and never noticed an issue with this. > Attaching a debugger to a process? This is also not an issue if you don't use bridge networking.
    - trinovantes 5y ago
      Getting VSCode debugger to hook into a process running in a docker container running inside WSL was insanely frustrating. In the end, I stopped using Docker during development and only use it for deploying to staging/production.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
grogenaut 5y ago
Twitch made it to acquisition with amazon with basically this system for both a rails app and about 20 other go apps. I'd know, I helped transition us to ecs later. For go apps, docker isn't really doing much over golang binaries. The bigger transition was more just moving us away from any unneeded dependence on system level apps. This happened at the same time we were dockerizing. I think the ECS abstraction is better than the simple daemon scripts we were using and scp for deploys, but we made it work up to around 30k servers before we hit scale limits. We could have pretty easily taken it even further forward but ecs is simpler and better integrated with the rest of AWS and our build tools. It only matters for a few special teams. The real issue with SCP at some point was the parallelism of deploys: opening 30k ssh connections single threaded or with bash starts bogging down at some point, and we were at the point of writing a massively parallel version when we switched to ECS for much of this (also around the time ECS became stable).
- void_mint 5y ago
  I posted below, but to me this post isn't really about Docker at all, as are my issues with it. You don't need to use Docker to see the need for sane build and deploy tooling. Who is running this scp? Where do they get the build? Do they have to know which hosts to scp to? Questions/problems like this are not solved at all, which generally need to be solved one way or another to scale any production system.
  - grogenaut 5y ago
    This was years ago. it was bare metal. The answer was that it got the exe from the build machine which it was running from. It knew where to deploy as we were on bare metal and used consul to list the hosts.
dehrmann 5y ago
I'd almost argue that the main benefit to not using docker at a scale where scp works is you won't be tempted to use kubernetes.

A-Train 5y ago

At my startup we do the same but with Rust. All the reasons stand. Insanely fast, self contained (web service / embedded UI with static js/html). Could not be happier with the architecture. I wrote it about it here if anyone interested https://logicai.io/blog/recommendation-systems-in-rust/ https://logicai.io/blog/recommendation-systems-in-rust/.

yberreby 5y ago

If you can make your app fit in a single binary and you do not _need_ Docker's features, then yes, I don't see why you'd bother using it. Docker shouldn't be your immediate go-to. It's just another tool that can help with some problems. Things do become more complicated when your app is a single logical unit that depends on a number of resources / services. Maybe you want an nginx reverse proxy in front of it, a database engine behind it; maybe Go isn't the only language you're going to use. Maybe you want the ability to effortlessly run the exact same setup as your production environment somewhere else without having to run a bunch of Ansible playbooks on the target host, and without worrying about the Linux distribution on it. Docker and docker-compose can help with these use-cases and get you up and running quickly. I'm not saying Docker is ever a _necessity_. But it can be a great convenience. In the end, use the simplest solution that fits your requirements, and make sure you can extend it later on if those requirements change.

ok123456 5y ago

A lot of modern tooling has come from people using microservices instead of making libraries. If you actually just write libraries it turns out you don't need to solve distributed systems problems, orchestration and configuration management as part of your normal development cycle.

ex_amazon_sde 5y ago

> we did get a little more complicated and create a SystemD script to launch it at startup If only there was a tool to: - bundle, distribute and deploy applications - ...and configuration files - ...and systemd unit files - ...even directories containing a Python virtualenv - keep track of what is installed and in what version - roll forward or roll back I would call it Advanced Packaging Tool.

joecot 5y ago
This is the normal progression. A new technology comes along, and folks are so happy to use it everywhere that they teach new people to use it, without any understanding of why it's useful or what it was made to fix. And they have little to no understanding of the ecosystem that preceded it. I watched it happen with virtualization. Everyone was so hyped about virtualization that everything was run in VMs. Later there was a counterrevolution of folks going "hey, we discovered that running things on bare metal servers is a thing you can do, and it's way faster and cheaper", a push that has mostly died out now that virtualization has hit near bare metal performance anyway and cloud hosting is the norm. But that counterrevolution happened because everyone embraced VMs and cloud services without dwelling on its actual use case, or in what cases it was an improvement over bare metal hosting. I watched similar happen with both the NoSQL and Serverless revolutions, and now we're watching it with containers. So yes, this would be better setup as a deb package, or deployed as part of a cloudinit startup script or similar. But if you came in when everyone was just shoving docker down each other's throats, you don't know what stages there were before that, and which one is the most appropriate one for your use.

primitivesuave 5y ago

The main reason I push for Docker containers is that it's a universally-understood encapsulation of an app or service amongst technical and non-technical people alike. "I'll have John write a Docker service that handles the integration" is an easy goal for both management and John to understand. Behind the scenes, we can use some fancy deployment or just run it on a single machine like the author describes. I would definitely not be okay with an engineer in my organization telling me their plan is to ignore CI/CD, especially in the present age where GitHub Actions is trivially easy to set up, and rather set up some custom procedure over SSH. Technical choices aside, it fails the "hit by a bus" test - if you disappear for some reason, or even just your laptop gets stolen, does the company grind to a halt?

Toutouxc 5y ago
> if you disappear for some reason, or even just your laptop gets stolen, does the company grind to a halt As in, no one in the whole company knows how to scp a binary?
- saurik 5y ago
  To be fair, scp was officially deprecated: it is effectively "legacy knowledge" now, and so soon it will be difficult to find anyone who can use it effectively. https://lwn.net/Articles/835962/ https://lwn.net/Articles/835962/ In contrast, we all know that knowledge of the Docker container format is both universal and likely to "stand the test of time". That anyone would believe that merely downloading a binary and then running it directly could ever be easier than first downloading and installing Docker so that you can then run docker on yet another file clearly has never worked as a systems administrator.
  - minusf 5y ago
    if the app in question can be installed by dropping some files on some servers, how could another full layer of abstraction be easier? an encapsulation is by definition adding complexity.
  - deleted 5y ago

imiric 5y ago

> But we have software we need to ship in order to get users in order to drive subscriptions. Anything that doesn’t directly serve that goal is a complication. I think you're only seeing Docker as a packaging format and missing the distribution aspect. There's a lot of value in telling users "My app is accessible with a single `docker run` command", that doesn't involve them downloading a standalone binary manually, placing it in their PATH, etc., and also works across platforms and operating systems. Or worse, having to setup the Go toolchain and compile it themselves, no matter how easy it is for a developer (and ignoring what can go wrong with Go modules). Of course, then you open yourself up to all sorts of support questions related to Docker, but I still think it's a missed opportunity to not use it to make your software as widely and most easily accessible as possible.

matsemann 5y ago
Good point for services being installed. Especially when I'm just testing something I don't want to see a full page on how to get it up and running, or even care about the underlying tech. Just give me a docker oneliner. Doesn't have to be the standard way of distributing the app, but at least make a simple image for local testing / development. Tested RabbitMQ this weekend, and the getting started was soo easy.
nicoburns 5y ago
> and also works across platforms and operating systems As a mac user, I'm not sure I agree with this. Docker does technically work cross platform of course. But it's slow everywhere except for linux. I'd much rather have binary (or even better a `brew install`) than a docker image.
- j0ba 5y ago
  Lol no. Docker is only slow on Mac. It works great on all other platforms.
  - carlmr 5y ago
    It was slow on Windows to run Linux images the last time I tried. I think they now use WSL2 making it faster, but I haven't used it since.

watermelon0 5y ago

> No, the reason we went with go was because golang’s packaging is so much better than node. Or java. Or C#. We get a single binary. Same can be achieved with node/java/C#. There are 3rd party tools to achieve this for many languages, but at least dotnet has this option built-in: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single-file-executables https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotne...

fiddlerwoaroof 5y ago
Yeah, fat jars in Java has been a thing for years and, IMO, docker for Java is unnecessary overhead: if you need _containers_, use something like Google’s jib to turn your fat jar into an OCI container.

twic 5y ago

I've used pretty much this approach at a couple of places, mostly working with Java. A production server is a vanilla Red Hat machine with an aftermarket JDK at a known path. The deployment artifact is a zip file containing jar files (and anything else) and a shell script called run.sh. Deployment is copying, unzipping, and overwriting a symlink. A cron job or a systemd etc service starts it. CI is a cron job which pulls, runs build.sh, and copies build/distribution to an NFS server. It works.

madhadron 5y ago
You can also build a fat jar, which is basically a zip file containing everything but that the JVM knows how to load. All the static assets can go in there, too. It saves you the build.sh.
- regularfry 5y ago
  I thought recent JDKs had the tools to build executable jars with the JVM built in. Can't find a reference now, though.
  - kondu 5y ago
    Perhaps you're talking about jpackage - https://openjdk.java.net/jeps/392 https://openjdk.java.net/jeps/392
    - regularfry 5y ago
      That sounds close, but I thought you got a plain executable out rather than an installer.
- twic 5y ago
  The build.sh is how CI builds the project from source. I suppose you meant that it saves the run.sh - but it doesn't, because you still have to give the path to the JDK, and any JVM command line arguments you want. Honestly, i've never really got the point of fat jars. Fat jars come with all sorts of annoyances (what do you do with the manifests from each jar?). Unpacking a zip is not hard.

FpUser 5y ago

Similar to what I do, only I use C++ instead of Go and CMake / make instead of Go Build. Vertical scalability is stellar and exceeds any realistic expectation my own business or those of my clients.

kristiandupont 5y ago

I am all for keeping complexities at a minimum and it's great that it's working for them. However, Docker is so simple to work with and so valuable in what it delivers that a headline like this reads to me a bit like "We don't need git". Sure, you might not need it. But it would probably be nice.

dkarras 5y ago

From the comments, it looks like they aren't even using a database and storing data client side ("to be stateless" they say). I don't know what kind of application they are serving but that has a whole can of complications. They are trying to make money yet I assume they don't have accounts etc. That's a bit overkill. So, no database, a single web service, yeah you might not need docker or alike. Depending on their use case they might need high availability so a backup server with a failover would be nice of course, ideally kicking in automatically and doing the necessary notifications.

great_reversal 5y ago

This was posted previously a couple weeks/months ago.

mxmasster 5y ago

More people need to do this. Focus on growing your business not optimizing your pipeline.

minusf 5y ago

> This might end up getting a lot of hate. no hate from me. it's perfectly fine to run one's stuff without docker.

easton 5y ago

I don't know, learning Docker probably took me a while, but now that I know how to do it I can spit out a Dockerfile in like five minutes (especially because most of the time its "FROM language COPY app RUN ./build.sh COMMAND ./app" unless you want to get fancy with multi container builds), and a docker-compose for single-server or workstation usage (which is all my hobbies amount to) in 15. The longest time I've spent writing a Dockerfile (because I was trying to build a gigantic Rails app where their build instructions were wrong) was probably a couple hours. I can understand not wanting to take the time to learn it because growing a business, but if you know how to write a bash script you'll probably pick it up in like a few hours, once. It's not like we're talking about k8s or something, which I can understand not wanting to immerse yourself in for weeks only to wonder why you didn't just pay for Heroku and hire an ops guy in a year to get off of it.

kissgyorgy 5y ago

X rant about technology Z because they don't understand it. Of course Docker is not simpler, because you can do so much more with it than copying a single stateless binary to a single machine...

NilsIRL 5y ago

Previous discussion: https://news.ycombinator.com/item?id=26472452 https://news.ycombinator.com/item?id=26472452

codegeek 5y ago

Interesting. I wrote an Internal Go Application (not very mission critical) and i literally deployed the binary using supervisor and nginx as a proxy in front. A quick scp command as needed for changes down the line.

jchook 5y ago

This works for their particular use case because their server doesn't even have a database. It doesn't address runtime configuration like remote hosts, passwords, etc. It doesn't even address the difference between provisioning and deploying a host.