4 ms·
There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of t
by keyle 4y ago
There is no going back. The industry has seen a 5X raise in money and people.
It's only natural that a job that used to take 2 now takes 10 people because of those facts.
And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.
- papito 4y agoWe will be going back. After the last binge, torching through piles of cash to do resume-driven development, companies are now looking to be lean. You can't really survive if you are doing microservices and trying to actually build something with a team cut by 75%. I am already seeing this newly discovered love of simple, fast monoliths and the developer ergonomics they offer. What is old is new again - we are at the beginning of this cycle. The older generation learned that "complexity kills", the new generation is beginning to get it as well.
- Aeolun 4y agoIf you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
- anonzzzies 4y agoThe first thing I hear from the tech lead/CTO or whatever when I walk into a company is 'we are going to use microservices', then a lot of kubernetes, sqs, lambda etc. And THEN they talk about what the project is. I only didn't manage to keep away from a monolith for a fraction of the money and time; it was a huge fail; 20m$ burnt on engineers and aws and the endresult was a painful burning pile of nuclear waste. They had money to burn so they are still alive, but I should've walked out after the CTO pushed microservices past his team (his team + my team) who said it was nonsense in this case (it's in all cases, but whatever, I cannot prove that so).
- orange8 4y agoWhat do you mean zero prestige in that? Do you know the difference in salary, importance and status in managing a team of 50 vs one of only two?
- moosedev 4y agoI think you misread GP. That was the point they were making.
- klabb3 4y agoNot just managers, but the senior engineers too. You can aggregate all the inter-service communication and say that you’re managing 1000 QPS service mesh rather than a meager backend with 10 QPS.
- Marazan 4y agoRecently turned off a service that ran at 40,000 QPS
- marginalia_nu 4y agoNot to mention the resume padding technology. You can no longer claim to have expertise in OpenShift, Redis, Kafka and RabbitMQ and machine learning from having implemented a todo app :-(
- deleted 4y ago[deleted]
- missingcolours 4y agoIn the past and in other industries you'd choose the former because you'd get hit hard if your manager realized what you were doing. But in the easy-money FAANG world your manager is usually playing the same game, so they actually prefer that you go with the latter.
- kqr 4y agoI agree. These decisions are not made economically, they are made politically. And the big complicated thing is far more prestigious. Then let's say half of our profession has less than five years of experience (though I would guess it's closer to two years) -- they see what the elders do and copy that, like any good apprentice would. Suddenly, it's all they know. Wild conjecture, of course. I would like to see it studied!
- rqtwteye 4y agoEven for a tech lead the former is definitely very bad for your resume. You pretty much kill your own career.
- byyyy 4y agoBecause we can't definitively prove which one is better. There is no formal theory around system design so you get people complaining about how monoliths are error prone and way too complex and you get people complaining about microservices with the exact same argument. The result is that with a period of about a decade the industry just oscillates between the two methodologies in an endless flat circle. Monoliths will come in vogue again in the 2020s.
- marginalia_nu 4y agoYeah. I think what it boils down to is inexperienced developers and shortsighted product managers are capable of bad design choices in any paradigm. And handing them a new paradigm that's en vogue will all but guarantee they'll mess it up. Perhaps the real crux is that large teams don't build good software. Especially not from the ground up.
- ozim 4y agoFun part is there is no “better” in generic terms. Another fun part is that people on the internet complain but without merit. I cannot judge some project because I usually don’t know the project. So might as well be that monolith or not team was having high attrition or there might be many other things that would affect project.
- byyyy 4y ago>Fun part is there is no “better” in generic terms. No. It goes further then this. We actually don't even know if one is better or not. There is no formal theory that allows us to prove these designs. For example we have formal theory behind algorithm complexity that quantifies runtime cost but no such theory exists for engineering design patterns. We aren't even sure what to quantify. But just because a formal theory doesn't yet exist doesn't mean one can be developed in the future. Until then these system designs will be like history... Always repeating itself.
- deleted 4y ago[deleted]
- EasternGuy 4y agoOn a vaguely related note but still shows how the World works. Back in 1992, my Eastern European computer science teacher told us a story. He used to work as a programmer, doing "ERP" software for communist companies (state-owned, of course). The software would run on machines featuring Z80 CPU with CP/M operating system. Anyhow after the change of regime they got 386 PCs and rewrote the software to run on them. The performance gain was staggering but ... users (directors of said companies) complained. The software would cost a lot but seemengly would not "work hard" for it. On the old machines it would take a lot of time to process anything, it was obvious the software was "working hard". On the PCs the same operation which would take minutes or hours would complete instantly. Obviously the job was too easy and thus much overpriced. Faced with this serious problem impacting sales, the programmers thought about it and eventually found a solution. They added... SLEEP instructions. All over the code in key points, sleep(seconds), calibrated so the response time was about the same as on ye olde CP/Me machines. Customer reaction: completely satisfied. ... I think we can draw some conclusions on the universality of human stupidity and incentives to act that way.
- jowdones 4y agoThis shows what they failed to consider in those optimistic views of the 1930s like John Maynard Keynes who predicted that his grandkids would work just 15 hours a week. Slaves don't trade productivity for their lives, they trade time. No matter how many trillions of times more productive human activities will become, slaves's time will still belong to the masters and very little of their life will belong to them.
- disgruntledphd2 4y ago[flagged]
- jowdones 4y agoSo using the "wage slave" rethoric is punished now by the Thought Police. Happy happy thoughts and be greatful for the opportunity to trade our lives for a measly pay working for the man.
- granshaw 4y agoAll the laid off tech workers disagree