The top list would be all EU countries since not only they can travel almost anywhere, but they have the right to live and work in 20+ other rich countries.
How does this compare with Pulumi? AFAIK they also don't have a state file and relay on an external database to store state. Is your locking granularity better?
I don't know enough about Pulumi to make a fair comparison on locking granularity. Pulumi's model is pretty different from Terraform/OpenTofu in general and state management is only one part of that. We're focused on optimizing the Terraform execution model and making the state layer match the graph semantics it already uses.
I think that’s the article but tl;dr that’s only part of the problem and already widly adopted with mutexes in say dynamo or whatever flavor you chose. This is about not having global locks or 10 arbitary random locks per subdomain but rather figuring out the exact resources affected and locking only those.
I mean take this with a grain of salt and purely anecdotal; but everywhere I've heard of who chose pulumi over tf are no long using pulumi. I'd love to hear some opposing experiences to that though!
I was in a platform team using Pulumi (TypeScript) for a while. An issue I observed is that the team members with weaker programming skills were contributing not so great changes, and parts of the codebase diverged in style. The Output type also took some time for us to get our heads round and it felt awkward to work with, we were having to chain a lot of calls and had callback hell sometimes.
We were all experienced with Go but at the time the Go SDK was very awkward, although I think some of that has been resolved with generics now.
TF is less expressive but I think that’s actually better for 99% of cases.
I'm seeing a lot of custom operators written in Rust nowadays. Obviously biased because I do a lot of rust myself so people I'm talking to also do rust.
I think you're just used to AWS services and don't see the complexity there. I tried running some stateful services on ECS once and it took me hours to have something _not_ working. In Kubernetes it takes me literally minutes to achieve the same task (+ automatic chart updates with renovatebot).
I'm not saying there's no complexity. It exists, and there are skills to be learned, but once you have the skills, it's not that hard.
Obviously that part's not different from Kubernetes, but here's the part that is: maintenance and upgrades are either completely out of my scope or absolutely minimal. On ECS, it might involve switching to a more recently built AMI every six months or so. AWS is famously good about not making backward incompatible changes to their APIs, so for the most part, things just keep working.
And don't forget you'll need a lot of those AWS skills to run Kubernetes on AWS, too. If you're lucky, you'll get simple use cases working without them. But once PVCs aren't getting mounted, or pods are stuck waiting because you ran out of ENI slots on the box, or requests are timing out somewhere between your ALB and your pods, you're going to be digging into the layer between AWS and Kubernetes to troubleshoot those things.
I run Kubernetes at home for my home lab, and it's not zero maintenance. It takes care and feeding, troubleshooting, and resolution to keep things working over the long term. And that's for my incredibly simple use cases (single node clusters with no shared virtualized network, no virtualized storage, no centralized logs or metrics). I've been in charge of much more involved ones at work and the complexity ceiling is almost unbounded. Running a distributed, scalable container orchestration platform is a lot more involved than piggy backing on ECS (or Lambda).
A lot of people (esp people that performed extremely well in school and in corporate environment) find "failing" and "losing reputation" very stressful.
I am sure enough that I would crumble under that specific kind of pressure that I don't put myself in situations where I would experience that specific kind of pressure. Works great!
Thank God someone said this. Of course it is stressfull, there is no free lunch. If you can't take the heat just dont enter into a such top-heavy game.
Landlords and supermarkets dgaf. There is no real risk, and if they stress over it, that’s more a founder’s own psychological failing than anything else.
If you care what other people think that much, you probably don’t have sufficient quantities of the oft-cited “grit” that founders supposedly require.
