This is probably out of left field, but what is the benefit of having a naming scheme for nodes without any delimiters? Reading at a glance and not knowing the region name convention of a given provider (i.e. Hetzner), I'm at a loss to quickly decipher the "<region><zone><environment><role><number>" to "euc1pmgr1". I feel like I'm missing something because having delimiters would make all sorts of automated parsing much easier.
Thanks for getting back to me! Now that you've written it out, it's plainly obvious, but for me the readability and flexibility of delimiters beats the speed of typing and scanning. Many a times I've been grateful that I added delimiters because then I was no longer be hamstrung by any potential changes to the length of any particular segment within the name.
I've done this but on EC2. What would you like to know? Installing K3s on a single node is trivial and at that point you have a fully functional K8s cluster and API.
I have an infrastructure layer that I apply to all clusters that includes things like cert-manager, an ingress controller and associated secrets. This is all cluster-independent stuff. Then some cluster-dependent stuff like storage controllers etc. I use flux to keep this stuff under version control and automatically reconciled.
From there you just deploy your app with standard manifests or however you want to do it (helm, kubectl, flux, whatever).
It all works wonderfully. The one downside is all the various controllers do eat up a fair amount of CPU cycles and memory. But it's not too bad.
I've also had a good experience using the 'perf'[^1] tools for when I don't want to install 'hyperfine'. Shameless plug for a small blog post about it as I don't think it is that well known: https://usrme.xyz/tils/perf-is-more-robust-for-repeated-timi....
1. naiive prompt - gives dogshit answer: "how can I implement authorization for each microservice request if I am using AWS EKS and Linkerd as service mesh?"
- the answer to the first naiive prompt was mere 148 words. Similar to what you find in first results of gogel search.
2. meta-prompt - just start with "Write LLM prompt to ask AI about...". My meta prompt was "Write LLM prompt to ask AI about how can I implement authorization for each microservice request if I am using AWS EKS and Linkerd as service mesh"
- it gives the following prompt: "I'm using AWS EKS for container orchestration and Linkerd as my service mesh. How can I implement robust authorization for each microservice request in this architecture? Please provide an overview of recommended approaches, considering factors like scalability, security best practices, and integration with AWS services. Include any specific tools or patterns that work well in this ecosystem."
- the answer for the second prompt is much better at 428 words and I didn't have to think much. It took me 27 words of meta-prompt to get the 57 word real-prompt and the final answer is much better
Thank you so much for taking the time to give a concrete example! It really elucidated the process for me and I'll definitely do some A/B testing of my own to try it out.
Does anyone know how far along the eBPF implementation for Windows actually is? In the sense that it could start feasibly replacing existing kernel drivers.
I like the spirit of the second half to demonstrate what the team is up to, but I too wondered about potentional one-upsmanship problems. I'll definitely start following this to learn more though.
