rudi_mk

Damn. I started building exactly the same thing a couple weeks ago.

https://github.com/equationscp/equationscp

> Most people support Tesla, Elon and Trump.

A sweeping generalisation, perhaps? Maybe it's something you _want_ to see rather than what's _actually_ there to see.

> I like how this explains the ancient miracles

...which ancient miracles are you possibly alluding to here?

Like the UI a lot. Although def depressing to see how inaccessible the world is on my Indian passport. Def makes me want to work towards a good exit and get one of those nice passports by investing in a country.

OrbStack has been an absolute lifesaver. Rancher Desktop was great for running a quick K3s cluster locally, but OrbStack's VMs are just great. For someone who likes to run separate envs on Linux, Orb's VMs are great. Pretty performant on my older M1 MBP too.

Bit of a similar boat. I wish I had extensive and intelligent advice for you, but I'd definitely like to say this: _do right by yourself_. The actions of a few inglorious men in power affects everyone, and ends up tarring everyone with the same brush. IMO your duty isn't to a country or a flag - but to yourself. If emigration allows you to unlock/access opportunities that are otherwise (potentially) blocked due to geopolitical considerations, then it's only right to move.

I run 200+ production clusters across EKS, GCP and MSA. In a nutshell - running your own clusters and being responsible for every aspect - autoscaling, storage, upgrades - it's not fun. Using managed Kubernetes allows you to run a cluster knowing all those bells and whistles are already taken care of. Hard to go wrong with the following setup:

1. A cluster VPC with public and private subnets.

2. A managed control plane on EKS.

3. You can opt between self-managed and managed nodegroups. To be fair, self-managed nodegroups give you more control, but you'll need to be careful about updating them yourself.

4. Use AWS controllers - the AWS Ingress Controller, the EBS CSI Driver - stuff like this will ensure your cluster can provision and manage load balancers, storage and so on.

5. For starters use cluster-autoscaler to dynamically manage compute capacity on your nodegroups. As your platform builds up and scales, you can look at Karpenter as a viable alternative.

Please feel free to DM me should you need any tips with this. Email - me[at]rudimk.com.

Hello! Author of that little blog post there. Happy to be hit up with thoughts/feedback when you give it a shot!

As someone who basically focuses on infra engineering, I sometimes want to throw together quick UIs for automating stuff. Always been terrified of React/Vue. This is practically a godsend - can't wait to build some tools for myself.

I’m sorry you found my earlier response vacuous. The point I was trying to make is that K8s is the best shot we have, and I wanted to underline the possible bias I may have. I’m sure someone must have found what I said worth their time, just as someone won’t.

Keeping the complexity aside - which is always a decent motivator for new platforms - I feel a significant amount of technical and financial investment has been made in Kubernetes over the last few years. So when a community like the CNCF comes together and says okay, where do we go from here, I don’t think anybody says let’s ditch all we’ve done so far for a new platform that may never happen. Their focus ends up trying to either extend what we have already - which, let’s be fair, does actually work - or they look for ways to make using Kubernetes slightly easier.

Not a big fan of tools like kops or even eksctl - sure they’re good for creating cookie cutter clusters, but I prefer using Terraform for cluster orchestration. Apart from that, k9s is a terrific tool for managing clusters instead of kubectl. Apart from that - a Grafana installation locally on my Mac with preloaded dashboards, and all I need to do is port forward to Prometheus, in order to view monitoring data easily.

Disclaimer - been working on K8s in different capacities since 2017, so there’s definitely a lot of bias.

My take - Kubernetes isn’t perfect. It’s got a lot of moving parts, a lot of complexity. My work involves managing SRE for almost a hundred clusters daily, where clusters are running across different clouds with different levels of customisation. I’ll say this - K8s is to cloud native infrastructure engineering what ODBC was for databases 20 years ago. A consistent base standard for running workloads across public, private and hybrid clouds, without worrying _too much_ about how those apps will actually utilise the underlying infrastructure. I’ve worked on Docker Swarm, Rancher 1.0, Mesos, Nomad - nothing comes close.

Sure things may evolve and maybe in a decade we _may_ see a new standard, perhaps a new platform. But I don’t really see that happening. K8s is here to stay, and it’s now at a point where it’s stable and mature from a reliability standpoint; it just needs people like us to worry and fret about making it more accessible.

Now I'm psyched to try this out.

Lovely idea! We use Slack for CX - per-customer channels. I think one of our concerns with this approach is the fact that it doesn't feel scalable, especially when it comes to locating knowledge/experience around similar support queries/cases. I was wondering about your thoughts on that front?

I have a bunch.

Usually when I’m architecting infrastructure(I’m an infrastructure architect/SRE), I like listening to this: [https://open.spotify.com/playlist/4ELbFgXjDLVd3pB6DYcEXF?si=...

When I’m working on live production infrastructure, I dunno why but metal seems more like what keeps me going: [https://open.spotify.com/playlist/4Goz8XUN3ZHlx7t8CuNdbt?si=...

Save yourself a lot of trauma and get out of this mess. Been in a similar situation, spent five years trying to fix things, gave up. Could have saved myself some of the therapy I now need.

Try MIT. It's dead simple, very open and works for the scenarios you've listed.

Details - https://choosealicense.com/licenses/mit/