111–120 of 310 posts
99% of all developers had enough todo with their work, they don't have time to write shiny articles about the used technology.
This should make it clear that many great articles on many great technologies are written by a few, most of which are at an academic level and have less to do with the practice of 99%. But everybody thinks that using this tools that way is normal, it isn't.
Earlier quoted context omitted.
The point the article raises is whether those "non-FAANG engineers" should be using serverless at all. Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?
mod_php is a serverless compute platform. The better question, will anyone’s requirements ever scale to a point where it makes sense for them to NOT be deployed as a serverless service? FTPing source code to a shared hosting provider is about as simple a deployment story as it gets; people bring all kinds of incredible complexity and thousands of hours of work on themselves messing with daemons, init scripts, systemd…
In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…
They shaped the world to their liking and now it looks like a match. duh.
The developer bubble. 99% of all developers had enough todo with their work, they don't have time to write shiny articles about the used technology. This should make it clear that many great articles on many great technologies are written by a few, most of which are at an academic level and have less to do with the practice of 99%. But everybody thinks that using this tools that way is normal, it isn't.
I was too passionate about coding to butcher it in this way so I left the professional sector and focused on open source (thankfully I have enough side income to do this). It's mental torture to come to work every day, working in an industry which is supposedly all about logic and problem solving and be constrained by what is essentially religious dogma when applied in context.
10 years ago, it was such fun to be in the software industry as a developer. The company directors would trust you to choose any stack/framework you wanted or even build your own lightweight in-house framework (or no framework at all). It's no longer the case.
Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves the performance problem with dozens, sometimes hundreds of replicas for one particular microservice. Many developers don't even understand the impact the JVM has when running on a single core (yeap... you get Stop the World GC - aka Serial GC - by default).
And then, the dev team decides to move to a new language because of performance and cost issues. And that by itself just brings many other problems.
All they had to do was keep the same amount of CPU and memory, but less VMs and replicas, with more vertical resources. Depending on the workloads and the system, it is even possible to reduce the cost.
All this is caused by the push in the industry for companies to go Cloud Native.
Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves t…
In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…
Take the POS example. You're helping real people be more efficent, and you've litterally got better things to do than be a software purist ( no offense, have same problem ). People are relying on you.
Meanwhile, serving the hospitality environment where multiple devices might be ran around a restaurant, and end up down a beer garden, all the whilst being expected to have every order on every device, because a table may call a wandering staffer, whilst having spotty AF network connectivity, processing trillion of transactions a year.
Suddenly you have a real life use case where your DS&A knowledge is useful, a real reason to be efficent on the wire, the device, and the server, and improvements in architecture can remove bad states, bugs, and improve the lives and fortunes of real people.
If being a 1% dev means profiling people and serving them ads, or writing pure code that nobody uses, then I'm quite happy in the 99%.
Disclaimer: I'm a CTO of one of those POS startups. :)
I am not sure what the point of the article really is. I mean it’s not wrong, we all live in that real world (my job is literally migrating off stuff) and recognize everything the author says. It’s just that I don’t see those myths being myths in the first place. In fact, thinking that the 1% is any different is perhaps the biggest myth in the article. Sure they have distributed crap to handle and uptime commitments…
Having new joiner stating on 2nd day that the whole system has to be moved to microservices on graphql with blue/green continuous deployment to solve all past and future problems is a real problem, it does exist.
Some people seem to fall into this trap described in the article of reading some blog post on some approach and fixating on it in religion-like mindset. It makes it hard to unwind ideas they throw into business people's minds because they all sound superficially great. You have to break it down to first principles and go through it, explain why things make sense for 10k+ engineering teams but don't for our dozen people team.
They will call current architecture legacy from the start and that sticks with business people. The reality is often the other way around - big players would love to be able to run systems using those simple, straightforward arrangements: single version for all services, ability to have few minute downtime to upgrade system offline, single monorepo, single database – but they simply can't because they have thousands of people working on it, running at massive scales across the globe.
When you say those things people get very defensive and it's hard to keep dialog on. Because those new things could actually work very well, but ie. not as replacement for everything but to create some satellite services, maybe for things that crystalized over years, unlikely to change and can be extracted as dedicated service, maybe graphql makes sense for admin section where the f/e team wants to experiment more etc.
I'd say:
- be rational
- analyze from first principles
- use N-order thinking
- be open minded - for new tech and ~legacy~ current tech
- judge on simplicity as one of main criteria
- stop calling tech you're currently running without already available alternative "legacy" - it's your "current" tech
- monoliths are not "legacy", they are desired if possible, split if they'd simply not work or you organically grew into maturity level where it start to make sense
- same with single database
- same with single versioning
- same with single monorepo
- use your own business reality as base for evaluation, not somebody else's reality