4 ms·

Oh boy... Guys and gals, learn the basics. You don't need Docker, just a version control system (e.g. git). You don't need overpriced cloud offerings in the

Oh boy... Guys and gals, learn the basics. You don't need Docker, just a version control system (e.g. git). You don't need overpriced cloud offerings in the first place. First of all, pick the right language. For me, that's Go, because it has lots of performance for little resource usage. Docker is written in Go. Why would I put a Go proxy in front of my Go program to have nothing but what's essentially a zip file with some startup script and then have to fight the Go proxy, Docker, and its configuration. Learn about systemd. It's the defacto standard init system for most popular Linix distros nowadays. Terraform? Ansible if you must. If you're managing more than 1 host maybe you do, but it's likely you don't. Or pick something like NixOS if you just have to define your machine state. AWS (and GCP, etc)? A, one, dedicated server where you can host all the projects your heart desires for a fixed price with low costs for bandwidth/traffic. Kubernetes, you do not need it. Go can handle about 500 million visitors a month on 12 year old hardware per 1 server. You will almost certainly not reach these numbers. So you don't need much to live a stress free and cheap but efficient life. What this article tries to teach you is how to become a tool for public cloud providers. Running k8s requires at least 9 servers. Managed k8s, like those cloud providers offer are expensive, because even if you think it isn't so, the devil is in the details. I see that guy posting of how easy it is. BS. Nothing is easier than a single host with a front proxy like nginx, which btw k8s also uses, they call it ingres proxy, a simple nginx config, some letsencrypt, your Go backend and the database on the same server. It doesn't get easier. What this article tries to teach you is stuff you will only ever need if you expect over 5k concurrency (note that's not 5000 users). When do those situations occur? Eurovision Song Contest. Very popular chat app (but even there you'd not use http). You don't need all this. And you also don't need microservices. Monoliths are fine. When are microservices useful? When you need to scale particular components of your big program. Is it worth the trouble? Hell no. Especially because now you have to deal with a problem so huge with very little benefit to going the event driven microservice route, because that's the only route that matters regarding microservices. And that's the only, ONLY time k8s makes sense. That's also where you can afford to pay those ridiculous prices for cloud traffic and managed k8s. Those are multilateral enterprise levels of business size, ok? Forget all that crap. In these comments you'll find people trying to BS you to get hyped for their product, promising "there will be only one". It's all BS. Just learn the basics. It's not hard. Disclaimer: truly failsafe setups should run on 3 servers (hn runs on 2 and has regular downtime). So if you have a money maker of course do that. But until then even a single server setup with regular backups will do just fine.

cloudyporpoise 4y ago
God damn, I love this comment. We manage 8 Linux servers total for an application that is lightly used by our customers but heavily used by our internal workers that constantly reach out to internet services and check for things. Everything we've done has been in Go and bash, and our deployments are easy and take seconds. I'm tired of seeing so many posts for Docker, Kubernetes, terraform, and even so many of Amazon's service offerings. Guess what? All these tools are abstractions, and it's insane to me that so many would rather learn to work with these abstractions, as opposed to learning some Linux basics, which would allow them to solve the same problem with much less overhead. We have two webservers, four workers, and two database servers. All of our code is written in Go so our dependencies are limited, and this has been my reason for not needing Docker. However, we use Docker locally to spin up our local dev environment, so developers don't need to have MySQL installed on their machines. The primary benefit I see with Docker is dependency management, and when your dependencies are minimal, it's not worth the overhead. All of our servers are built from bash scripts that are executed on the server on the first run. This bash script creates folder structures and user accounts and sets permissions. If a server needs to be destroyed for whatever reason, it can be rebuilt as new from these scripts in < 10 minutes. Code deployments are done using SCP and rsync and systemctl to stop and start services remotely. If we were using an interpreted language where dependencies are a bit trickier to manage in prod, certainly we'd use Docker then. Still, for the time being, this Go \ bash ecosystem works for us, is easy to manage, and limits dependencies overall. Debian & Go all the way, baby. The longer I work in this industry, the more I realize a bigger hindrance to accomplishing goals is actually overthinking and over-engineering. I see startups with no customers using kubernetes and terraform. People building noahs ark when they've never experienced rain. The pain points in your process will become obvious. Let the process tell you it's time for these more advanced tools. If you can manage production code and deploy updates easily without them, then don't waste your time. If you don't know any other way, then maybe it's worth spending the time to learn Linux a little bit better.
- chrismarlow9 4y ago
  I agree with you entirely, nearly all of the companies I've encountered that are trying to get kubernetes working have: 1. Made poor language choices that require them to over complicate their architecture to scale things up. Places where a single golang binary would work and instead you have queues and callbacks and 5 container images because at each road block they just added some new "thing" to make it work. 2. do not even have the base infrastructure automated for any of this to run on, so instead they throw kubernetes on top of it and cross their fingers that the underlying hosts will just magically stay up. And every email about degraded hardware from AWS nearly gives you a heart attack. I guess overall I'm sad that instead of trying to make smaller and tighter machine images that boot quickly in order to automate availability, we (the industry) added another layer (containers) to just complicate things more.

cloudyporpoise 4y ago

God damn, I love this comment. We manage 8 Linux servers total for an application that is lightly used by our customers but heavily used by our internal workers that constantly reach out to internet services and check for things. Everything we've done has been in Go and bash, and our deployments are easy and take seconds. I'm tired of seeing so many posts for Docker, Kubernetes, terraform, and even so many of Amazon's service offerings. Guess what? All these tools are abstractions, and it's insane to me that so many would rather learn to work with these abstractions, as opposed to learning some Linux basics, which would allow them to solve the same problem with much less overhead. We have two webservers, four workers, and two database servers. All of our code is written in Go so our dependencies are limited, and this has been my reason for not needing Docker. However, we use Docker locally to spin up our local dev environment, so developers don't need to have MySQL installed on their machines. The primary benefit I see with Docker is dependency management, and when your dependencies are minimal, it's not worth the overhead. All of our servers are built from bash scripts that are executed on the server on the first run. This bash script creates folder structures and user accounts and sets permissions. If a server needs to be destroyed for whatever reason, it can be rebuilt as new from these scripts in < 10 minutes. Code deployments are done using SCP and rsync and systemctl to stop and start services remotely. If we were using an interpreted language where dependencies are a bit trickier to manage in prod, certainly we'd use Docker then. Still, for the time being, this Go \ bash ecosystem works for us, is easy to manage, and limits dependencies overall. Debian & Go all the way, baby. The longer I work in this industry, the more I realize a bigger hindrance to accomplishing goals is actually overthinking and over-engineering. I see startups with no customers using kubernetes and terraform. People building noahs ark when they've never experienced rain. The pain points in your process will become obvious. Let the process tell you it's time for these more advanced tools. If you can manage production code and deploy updates easily without them, then don't waste your time. If you don't know any other way, then maybe it's worth spending the time to learn Linux a little bit better.

chrismarlow9 4y ago
I agree with you entirely, nearly all of the companies I've encountered that are trying to get kubernetes working have: 1. Made poor language choices that require them to over complicate their architecture to scale things up. Places where a single golang binary would work and instead you have queues and callbacks and 5 container images because at each road block they just added some new "thing" to make it work. 2. do not even have the base infrastructure automated for any of this to run on, so instead they throw kubernetes on top of it and cross their fingers that the underlying hosts will just magically stay up. And every email about degraded hardware from AWS nearly gives you a heart attack. I guess overall I'm sad that instead of trying to make smaller and tighter machine images that boot quickly in order to automate availability, we (the industry) added another layer (containers) to just complicate things more.