Earlier quoted context omitted.
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…
That sounds like a bit of an extreme reaction to what seems to be a "this technology is yucky and I don't like it" problem.
Docker, Kubernetes, Terraform, and AWS crash course series
61–70 of 84 posts
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#62Earlier quoted context omitted.
not sure if IaC will help, I'm just started reading about it. Indeed the cloud vendors are all lock-ins, something needs to be designed to mitigate the switching cost among cloud providers. Each one has its own SDK and own complicated infrastructures, so far it seems impossible to switch once you started with any one of them.
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.
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#63I can’t think of a worse way to manage Kubernetes than Terraform. After years of running into issues, I think it’s really only suitable for small clusters. ClusterAPI has been the way my company has been doing things lately and I can honestly tell you it’s been transformative. https://github.com/kubernetes-sigs/cluster-api There’s nothing more amazing that updating a kubelet version in a git repo and watching Cluster…
How does ClusterAPI compare to Helm charts (or just managing Kubernetes YAML manually or through Kustomize?) Why do you need clusterctl / clusterawsadm? Can't you just kubectl apply once you have your .kube/config set up for your AWS k8s cluster (or Azure or GCP or whatever)?
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#64Earlier quoted context omitted.
That sounds like a bit of an extreme reaction to what seems to be a "this technology is yucky and I don't like it" problem.
No, you're way off. Maybe my reaction is extreme, but my problem isn't. What's yucky is that you're trying to convince people that reading five tutorials on k8s will make them productive. No, the problem, and I'll repeat it since you conveniently skipped over it, k8s requires 10+ engineers to maintain and manage, full time. _I_ don't have 10 engineers and thus it's the wrong tool for me and I've decided to not invest…
I'm not running a very big operation, I only have two nodes which host a few custom webapps and a few dozen WP sites. Running in a single region removes the extra charge for HA GKE, letting me run pretty lean and just pay for the VM, storage and bandwidth. I hardly ever have to spend any time on managing the cluster, it keeps chugging along while I get things done and makes it easy for me to manage app lifecycles. YMMV.
I keep it simple, I tried helm but didn't like it because it added too much complexity. I pull in cert-manager and nginx-ingress to every cluster I run but nothing else. I build my images locally and push to the registry directly, no CI/CD. I focus on the core competencies of k8s and try to stay lean and conservative with adding new tools or components.
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#65Earlier quoted context omitted.
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.
what are the strongest competitors to S3? S3 is so dominant I rarely looked into anything else for cloud storage.
I guess it wouldn't work for all the intricacies, but for commonly used stuff it works.
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#66Why use k8s and AWS instead of ECS?
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#67I can’t think of a worse way to manage Kubernetes than Terraform. After years of running into issues, I think it’s really only suitable for small clusters. ClusterAPI has been the way my company has been doing things lately and I can honestly tell you it’s been transformative. https://github.com/kubernetes-sigs/cluster-api There’s nothing more amazing that updating a kubelet version in a git repo and watching Cluster…
How does ClusterAPI compare to Helm charts (or just managing Kubernetes YAML manually or through Kustomize?) Why do you need clusterctl / clusterawsadm? Can't you just kubectl apply once you have your .kube/config set up for your AWS k8s cluster (or Azure or GCP or whatever)?
We use ClusterAPI + a centralized ArgoCD to push our clusters that’s other teams can use but with all the required add-ons that the business says we need like security tooling and policy management.
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#68Re: Docker, Kubernetes, Terraform, and AWS crash course series
#69Kubernetes must probably be one of the most tutorialized pieces of SW out there. You want a "crash course" on the platform of your choice? You got it. You want it for the price of your choice? You got it. The docs are great [1] and offer even interactive parts [2]. There are a ton of good materials on youtube. There are Coursera and EdX courses, e.g. [3] from Google and [4] from Red Hat. There are a ton of Udemy cour…
Re: Docker, Kubernetes, Terraform, and AWS crash course series
#70Oh 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 wi…
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'…
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.