Every season of Fortnite, it feels like the Epic developers go “our menu system has a bunch of unfixable bugs, so we need to rewrite the whole thing” and then they just create a new menu system that has a new set of unfixable bugs.
Paul David
@iamtherockstar
- 59 Followers
- 68 Following
- 344 Posts
Chop wood. Carry water.
Of course, they’re probably running some awful kubernetes thing, so it’s probably just some dev’s container build.
Also, my favorite lore I have come up with is that I occasionally end up on a Fortnite instance that is running on some dev’s machine.
Fun fact: you can gaslight Copilot.
1.3.6.1.4.1.61513Your `pip` unwrapped 🎇
- you tried to install `requirements.txt` 18 times this year. Doing better than last year!
- of the packages you installed 67% started with py, 11% python, and 6% Py. You guessed wrong 85 times.
- your love for building source has no bounds, except maybe the 92 failed compiles
- you updated `requests` 18 times. Urllib is feeling lonely.
- the average time between updating `pip` was 97 days. But we warned you 338 times!
Gaëtan Perrault@iamtherockstar Oh, we absolutely had the scale to justify such a thing. But we notably made it that far without actually having such a thing.
The nature of my research on that front made it pretty clear that k8s was powerful, but had a high bar for entry. And this research was literally part of my job.
This was back in 2020-2022 range, and I concluded back then that the vast majority of applications were best served using some form of hosted platform. Like Heroku or Azure Serverless, AWS Serverless etc. There were already so many tools that could run your services for you while offering really high availability databases/queues/caches.
If I were at a start-up tomorrow, I would be leveraging those as much as possible. Even hosted k8s would be way down on my priority list. There are so many steps on that staircase before K8s.
amosMy hypothesis is that we've gotten here because we think that agile processes mean we don't do quite as much design. In some cases, that's absolutely true. Agile processes help us pivot quickly. However, agile is for the manufacture of software, not design. We still have to consider architecture, even if only to acknowledge there is nothing novel about our design. Oftentimes, it means that we skip over the one or two _absolutely_ novel things about our software, which leads to problems.
In the late 10s, I made a not insignificant amount of money by helping startups either avoid k8s entirely or moving them off of it. Maybe it was moving to managed k8s, or maybe it was moving to something more "old skool" like ec2. The deployment process becomes more clear, the development process becomes less hairy, and we don't have to have multiple teams of SREs just trying to keep our infrastructure up.
Hot take: the default "we'll just run our own Kubernetes" in startup life stems from the fact that we are afraid of architecture. In the "nobody ever got fired for using..." we've added this behemoth of complexity and overhead.