At the scale twitter exists right now it is anything but simple. Had it been built from scratch it could have run fine with its current staff.
But the current staff needs to maintain code from a MUCH larger staff. That's hard. Especially with microservices where every team did "their own thing" and some teams just vanished completely. You have "dark areas" where no one knows how stuff works and what's going on.
Normally when you downsize at this scale you do this in an orderly way. Every person hands off their work and responsibility. Spends a couple of weeks writing docs and instructions and then leaves. This was done quickly and violently. I'm sure there's many repercussions we don't see simply because the systems are simply running. Once the team looks at some containers and decides to pull the plug to "see what happens" we'll find out...
> Had it been built from scratch it could have run fine with its current staff.
So you are essentially saying Twitter has an over-complicated architecture with regards to its real technical needs, so Musk was right to axe the microservice zealots. Good we can agree on that.
The next step is to acknowledge that code and data-centers continue to work long after their original designers have left the company, that's what computers are, tools for automation. Keeping the lights on and services in a roughly functional state is an activity that requires much less people of relatively lower qualification, even if they couldn't have engineered it themselves.
Yes, there is a long term risk of code rot and entropy if Musk does not plan for a gradual transition to a better engineered architecture with competent maintainers. But we are not there yet, far from it.
Meanwhile, schadenfreude people have rooted for a twittocaplipse from day one, nay, predicted it as inevitable. There is absolutely no sign it's going to happen, and Twitter turned out sufficiently simple after all on the technical side.
But the current staff needs to maintain code from a MUCH larger staff. That's hard. Especially with microservices where every team did "their own thing" and some teams just vanished completely. You have "dark areas" where no one knows how stuff works and what's going on.
Normally when you downsize at this scale you do this in an orderly way. Every person hands off their work and responsibility. Spends a couple of weeks writing docs and instructions and then leaves. This was done quickly and violently. I'm sure there's many repercussions we don't see simply because the systems are simply running. Once the team looks at some containers and decides to pull the plug to "see what happens" we'll find out...