<story><title>We Don’t Use Docker</title><url>https://launchyourapp.meezeeworkouts.com/2021/03/why-we-dont-use-docker-we-dont-need-it.html?m=1</url></story><parent_chain><item><author>victorronin</author><text>It&amp;#x27;s super simple and it works for you - yeay! great!
If it will continue to work for you - double yeay!&lt;p&gt;However, as soon as I read, I saw a lot of red flags:&lt;p&gt;- Do you really want to copy from a development computer to your production?  No staging at all? (&amp;quot;go test&amp;quot; doesn&amp;#x27;t mean that you have 0 bugs)&lt;p&gt;- Are you really sure that everything works exactly the same on different versions of GoLang? (Hey, a new guy in your company just installed unreleased Go 1.17, build on his notebook and pushed to production)?&lt;p&gt;- That VM with systemd died at 1am. No customers for you until 7am (when you wake up)&lt;p&gt;BTW. I am not saying that you should do Docker or CICD. The thing which I am saying that when you cut out from your process too much, you are increasing risks. (As an example, you didn&amp;#x27;t remove unit tests part. Based on &amp;quot;Anything that doesn’t directly serve that goal is a complication&amp;quot; you probably should have. However, you decided that it would be way too much risk)</text></item></parent_chain><comment><author>chrisandchris</author><text>Exactly my reasons: I don‘t use Docker because it‘s great that i can (could?) scale the universe.&lt;p&gt;In my case, I simply use Docker because it is so easy to set up n HTTP services listening on port 80&amp;#x2F;442 on the same server and then put a reverse proxy (traefik) with Let‘s Encrypt in front of it. I don‘t need to worry about port conflicts. I don‘t need to worry about running Nginx and Apache on the same host. I don‘t need to worry about multiple versions of Go&amp;#x2F;PHP&amp;#x2F;Dotnet&amp;#x2F;[insert lang here].&lt;p&gt;Still, I can‘t scale (single machine) but I don‘t need to. I don‘t have a failover, because I don‘t need one. But I have so much simpler management of the dozen services I run on the host. And that‘s worth it IMHO.&lt;p&gt;I think it‘s always about the right tool for the job. And I think if the OP does work with an automated script and scp, there‘s nothing wrong with that. Because that also adds reproducability to the pipeline and that‘s just such an important point. As long as nobody ssh‘s into prod and modifies some file by hand.</text></comment>
<story><title>We Don’t Use Docker</title><url>https://launchyourapp.meezeeworkouts.com/2021/03/why-we-dont-use-docker-we-dont-need-it.html?m=1</url></story><parent_chain><item><author>victorronin</author><text>It&amp;#x27;s super simple and it works for you - yeay! great!
If it will continue to work for you - double yeay!&lt;p&gt;However, as soon as I read, I saw a lot of red flags:&lt;p&gt;- Do you really want to copy from a development computer to your production?  No staging at all? (&amp;quot;go test&amp;quot; doesn&amp;#x27;t mean that you have 0 bugs)&lt;p&gt;- Are you really sure that everything works exactly the same on different versions of GoLang? (Hey, a new guy in your company just installed unreleased Go 1.17, build on his notebook and pushed to production)?&lt;p&gt;- That VM with systemd died at 1am. No customers for you until 7am (when you wake up)&lt;p&gt;BTW. I am not saying that you should do Docker or CICD. The thing which I am saying that when you cut out from your process too much, you are increasing risks. (As an example, you didn&amp;#x27;t remove unit tests part. Based on &amp;quot;Anything that doesn’t directly serve that goal is a complication&amp;quot; you probably should have. However, you decided that it would be way too much risk)</text></item></parent_chain><comment><author>code_sloth</author><text>&amp;gt; Do you really want to copy from a development computer to your production? ...&lt;p&gt;&amp;gt; Are you really sure that everything works exactly the same on different versions of GoLang? ...&lt;p&gt;He mentions he does have a build server which runs a 10 line shell script to download code and build the binary.&lt;p&gt;Builds happen on that server, and I assume it handles deploying the compiled binary (and systemd script?) to the target as well.&lt;p&gt;The build server would also have a &amp;quot;blessed&amp;quot; golang version. New guy code that uses new not-yet-blessed features would not compile.&lt;p&gt;&amp;gt; That VM with systemd died at 1am...&lt;p&gt;Your docker host died. All your containers die along with it. Docker alone cannot solve this category of issues anyway.</text></comment>