I'd say the opposite instead: we need Kubernetes distributions, just like Linux needs distributions. Nobody wants to build their kernel from scratch and to hand pick various user space programs.
Same for Kubernetes: Distributions which pack everything you need in an opinionated way, so that it's easy to use. Now it's kinda build-your-own-kubernetes at every platform: kubeadm, EKS etc all require you to install various add-on components before you have a fully suitable cluster.
I think the Operator pattern will grow to become exactly what you describe. We're still at the early stage of that, but I can see that a group of operators could become a "distribution", in your example.
ECS+Fargate does give you zero maintenance, both in theory and in practise. As someone, who runs k8s at home and manages two clusters at work, I still do recommend our teams to use ECS+Fargate+ALB if they satisfy their requirements for stateless apps and they all love it because it is literaly zero maintenance, unlike you just described what k8s requires.
Sure there are a lot of great feature with k8s which ECS cannot do, but when ECS does satisfy the requirements, it will require less maintenance, no matter what kind of k8s you compare it against to.
Kubernetes needs regular updates, just as everything else (unless you carefully freeze your environment and somehow manage the vulnerability risks) and that requires manual work.
ECS+Fargate however does not. If you are a small team managing the entire stack, you need to factor this into accounts. For example EKS forces you to upgrade the cluster to keep in the main kubernetes release cycle, albeit you can delay it somewhat.
I personally run k8s at home and another two at work and I recommend our teams to use ECS+Fargate+ALB if it is enough for them.
> Kubernetes needs regular updates, just as everything else (unless you carefully freeze your environment and somehow manage the vulnerability risks) and that requires manual work
Just use a managed K8s solution that deals with this? AKS, EKS and GKE all do this for you.
There's still Helm oddities, "annotations", CRDs, mutating web hooks, operators, etc. to comprehend before you have any idea of what the system is doing. All it takes is a random annotation to throw all your assumptions away.
It's a complicated mess compared to something like a Nomad jobspec. That's one of the reasons we decided on Nomad while I was at Cloudflare.
I agree with @metaltyphoon on this. Even for small teams, a managed version of Kubernetes takes away most of the pain. I've used both ECS+Fargate and Kubernetes, but these days, I prefer Kubernetes mainly because the ecosystem is way bigger, both vendor and open source. Most of the problems we run into are always one search or open source project away.
Are you assuming the workloads have to use K8s APIs? Where is this coming from? If that’s not the case can you actually explain with a concrete example?
Man, you don't need to use service mesh just because you use k8s. Istio is a very advanced component that 99% of users don't need.
So if you are going to compare with a managed solution, compare with something equivalent. Take a bare managed cluster and add a single Deployment to it, it will be no more complex than ECS, while giving you much better developer ergonomics.
If it is pulling a filesystem from tape into memory and booting from that, it could be pretty quick. Reading sequentially from tape, if you are already at the right location which is easy if that location is the start of the tape, isn't particularly slow at all – non-sequential access is where tape storage becomes very slow due to massive latency in the physical mechanisms.
Does anybody else often visualie memories as they would watch them via a movie camera? I do. I can see myself walking in places with a cinematic camera movements and angles. Haven't heard much others having the same.
How could you possibly know how you really looked like walking in those said places? You haven’t seen yourself walking there. Also, you haven’t seen all of the possible angles that this cinematic camera would capture and replay.
This is an interesting concept about memories, part of them is just made up by our brains.
Edit: So the next time you have an argument about a thing that happened or how it happened, ask yourself, do you really remember or is your brain filling the gaps?
Oh I absolutely agree that our minds are extending our memories and fabricating rest and it's next to impossible to difference what was real.
But getting back to my cinematic memories: I remember the places I've visited (and imagine places which I haven't) and then my mind constructs the cinematics. Fascinating!
I'm a long time Amethyst user, but going to try AeroSpace out!
Based on the documentation the toml syntax is stretched quite a bit to implement some logic and callbacks. Have you considered some scripting language to make it easier to do, or is the need for this kind of advanced use so little that it's not really a problem?
When I started the project, I kept it simple, so I started with the static config
The complexity of the config has grown since then, with the bigest (and, actually, the only) problem being on-window-detected callback as you mentioned.
I've been thinking about using a scripting language like Lua, but I haven't made my mind yet whether it's worth it
What's wrong with that? Computing history has a lot of machines with various co-processors which are used to offload various things from main CPU. Just as an example: Amiga and C64 had both co-processors for rendering text faster.
Same for Kubernetes: Distributions which pack everything you need in an opinionated way, so that it's easy to use. Now it's kinda build-your-own-kubernetes at every platform: kubeadm, EKS etc all require you to install various add-on components before you have a fully suitable cluster.