Found this post super interesting. I've personally run into similar, and built a really lightweight k8s operator and claude skill that lets the citizen devs deploy to an eng/IT managed internal k8s cluster. Keeps things safe (non-public), and can update it as they get more advanced.
Isn't it all Steven Wilson playing the mellotron on Opeth records? Damnation is one of those albums where if you hear a song from it, the whole thing is getting played.
I do this for a living (help companies migrate to k8s).
The advice I give everyone is: Stay off k8s until you care about binpacking. That is, making sure you're fully utilizing the instances you pay for. When the cost of your architecture is taking up some brain cycles, start digging in.
If that's low down on your priority list, it's not worth the investment. If you're reasonable considered "a startup", invest your time/money elsewhere. PMF and getting to default alive is far more important.
How do you suggest companies which don't need binpacking run their workloads, and is it really that much simpler than using k8s?
If you need automated deployments, centralized logging, autoscaling, etc which many teams do, then you're going to be dealing with a bunch of complexity anyway.
Honestly, package a container and run it Serverless. AWS Fargate, GCP Cloud Run, and similar are better fits.
There will come a time when cost of paying the overhead for a devops person (and eventually) team is worth it. At that point, k8s can be a great fit.
In my experience, that tends to be when you're at scale enough to care about costs a lot. Total spend and/or reducing COGS make it worth while. But when you look at it from the time an engineer costs, it's easier to see.
Are you gonna save 200k/year (minimum) in costs moving to k8s? Then do it. If you don't have line of sight to that, pay AWS/GCP to manage that for you, and focus on your business.
Also note, there's stages even with running k8s. Don't go all in running it all.
Start with a container, run it serverless.
When k8s becomes a better fit (to reduce costs, or with other small exceptions), use EKS or GKE. Don't run your own control plane.
If you really have a need for a lot of custom stuff, then start to run your own control plane. But by this team, you probably have a team managing all this. If that cost (remembering how expensive engineers are) is shocking, you should be running a different solution.
Generally not. The guidelines say you should submit the actual title, unless the title is clickbait, uninformative, otherwise misleading, or longer than the character limit.
It's market cap weighted, so they make up more than 1% of the index. Just based on the numbers shown (+2%, -5%, and +37%) they must represent about 17% of the S&P 500.
OP said bulking or cutting. Bulking is easier from an energy standpoint (compared to cutting), but it's not trivial. Your body is still tired. Your capacity for problem solving is still limited. And eating (and buying, and prepping) the amount of food needed for bulking is time consuming.
And cutting is even worse. You feel drained. And you sleep more when cutting then you did when bulking.
Both are hard enough that it makes me wonder if you've done either for a decent period of time. If you had, it'd be pretty easy to see OP's point without a flippant answer that ignores what they're saying.
So, zero excuse, as long you have the money to pay someone to do all the thinking/planning for you. And as long as you have the money (and live in the right locations) to have someone do all the actual work of cooking for you.
None of those things cost that much compared to alternatives. Food delivery is a huge industry. A consultation with a nutritionist isn’t a big deal, might even be covered under your insurance.
