Docker, Kubernetes, Terraform, and AWS crash course series

Cloud vendors are not all lock-ins. Kubernetes is an open API. If you've got your project working in Amazon, you can migrate it to GKE, Digital Ocean or just bare metal.

Yes, cloud vendors love to lock you in, but right now it's possible to use clouds in a vendor-neutral way. Managed postgres is just a postgres. Managed Kubernetes is just a Kubernetes. S3 have plenty of alternative implementations.

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 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.

I just don't want to do that, no thanks. I've spent so much time learning about how an OS can solve these problems and these lessons have paid dividends many times over my career. Instead, I will continue to invest in the core foundation. I'm not interested in re-learning these abstractions reading [1]-[5] tutorials plus many more and studying an unrefined, new layer of complicated abstractions built on top of the OS--the OS is difficult enough. I'll only _use_ k8s when it's managed and supported by a team of 10+ engineers, which is what it requires. Plus, it's not just k8s; you have concourse, spinnaker, artifactory, some sort of cluster templating, kops? to template your k8s deployments across DCs and environments, (I don't know what the community uses, we built our own in-house tool). It's all so gross.

My rejection of these systems has lead me to invest in FreeBSD. There was a learning curve and I'm certainly not as fluent in this system as I am with Linux but I'm in a place where I'm in control of the OS and have at my disposal solid, refined tools to help me masterfully construct the infrastructure to solve my problems. And, every time I solve a problem in this space my foundational understanding grows and these lessons will pay dividends into the future, or so I hope.

I'm utilizing FreeBSD because docker / k8s and I'll add systemd to the list, are missing and thus the community solves problems in a different way that better aligns with my values. FreeBSD isn't easier, I've been stumped on problems countless numbers of times but when I find a solution, it scales. What I mean by that is I have a better understanding of a system that can solve a larger class of problems than if I was in the docker / k8s ecosystem.

YMMV.

Companies hiring the people probably also have a need if they are hiring and looking to grow and scale out. I made a "you don't need X / Y / Z" point because I strongly believe most people don't need these tools and really need a better understanding of Linux basics. You can also learn these tools on your own if they're mentioned in job descriptions of jobs you're applying for, but that doesn't mean you have to use them when you're the decision maker, or for a personal project.

There is nothing stupid about this fear at all. Having to fight a $20k mistake is highly stressful. Not being able to prevent it via policy is a design decision by the provider.