Comment by bjterry | Hacker News Reader

Comment by bjterry | Hacker News Reader

99% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%".

Whether this distinction is relevant to you depends on where you sit. If you are a startup selling developer tools, by all means think about the 99% developers, but also know that a lot of them are in environments that don't spend a lot on tools and are averse to exploring new technologies. If you are a developer in one of these environments, well, the standard advice on Hacker News is already "You're not Google."

I feel like some of this is a bit fatalistic. The 99% can follow a DevOps playbook if they realize its value, and it's cheaper to have DevOps than to not have DevOps, in the anything-more-than-short timeframe. The 99% can certainly have test coverage standards for new code. Somehow, we moved from a world where the 99% didn't use source control, and now they do! Some technologies and practices are so impactful, you should aspire to them no matter what you're environment is (e.g. code review, CI/CD).

The 99% concept also hides a lot of important details, as it's defined by exclusion. The choices you need to make for an early stage startup, a mature WordPress shop for small businesses, and a legacy mainframe team in a F50 are as different from each other as they are from FAANG.

For the last few days I've been rewriting one of the company's legacy WordPress plugins to work better with modern WooCommerce.

That's right: PHP, baby. Ugly, hacky, sticky, oozing PHP.

Oh woe is me, etc etc, but you know what? It makes the customers money, which makes the company money, which makes me money. I've gotten used to eating and living indoors, so this is a good thing.

It's not serverless, there is no GraphQL, it's not within a mile of the nearest Rust compiler and it could not be implemented in golang even in my wildest fever dreams, with or without generics. There isn't even any machine learning!

We need to keep in mind the trillions of lines of legacy code out there that is still being maintained, refactored and rewritten, every day, that is not a new product or a groundbreaking new paradigm. It's just the internet, and the hacky PHP and smooth perl5 that keeps it running.

So yeah, 99% might be an exaggeration, but if I was making a new IDE (or whatever) today, I'd sure as hell target WordPress before I started making up my own buzzwords. I can't say for sure if that's because of my perspective or because of some objective data, but I do know that it would be a product with a hell of a lot more customers.

PHP is the OG serverless

And doesn't have the stupid name.

What you seem to be implying is that there isn’t a profitable market for dev tools for the “rest” of developers (whatever the % might be). 2 observations:

* it’s possible the market isn’t lucrative enough for a VC funded SV company; perhaps other models in other locations might make it more cost effective to serve that market

* putting the profit motive aside: I think there is a lot to learn from understanding how the 99% of developers work and how they may be enabled by tooling to make them more productive. The solutions to the problems faced by that group may actually help build better technologies.

… I'm in a small company, and we "use" serverless. I've never once asked myself "Should I move to serverless?" It's just whether, for some application, it's the right tool.

We run a few Github bots & a function that updates a Route 53 record on serverless. (Security didn't want to give permission to R53; "too much, too broad"; a lambda that exposed only the necessary action to the service that required it was the compromise). But it's all extremely low-frequency stuff with no or little state, where the costs of a VM would far exceed the costs of "serverless". It was the right tool, for those jobs. (& it's usually niche stuff… I'm trying to think if I've ever worked somewhere with something core on Lambda or the like…)

But also got tons of VMs. Lots of VMs. Probably too many VMs.

You have to have a VM to run a _single_ service? You have no multi-application VMs?

> You have to have a VM to run a _single_ service?

This is extremely common, in my experience. (Like it's a default tendency of nature.)

So, the VMs example was my previous employer. An yep, not really any multi-app VMs. There were some that did do a couple of things, but it wasn't great: it meant the deployment and dependencies of anything sharing a VM were all interdependent … and often under specified. Painful.

It's why Kubernetes exists, really. (Which is funny how much hate it & Docker seem to get on HN.) In my current employ, we do use k8s, and while much runs on it, and it's nice, we still haves some single-service VMs. I'd like to move them all into k8s if at all possible, but it is not always possible. Or it's not always that time gets dedicated to it.

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?

So by No-FAANG engineer, you mean someone who isnt a robot ad hawker sell out?

Serverless allows anyone to be scale for minimal up-front cost and only pay for the usage they really need.

So glad that FAANG attract all this rare talent so us no-FAANG engineers can make a buck.

> So by No-FAANG engineer, you mean someone who isnt a robot ad hawker sell out?

Come now, is there any reason to throw those insults?

Many.

> Will their requirements ever scale to a point where it actually makes sense

And even that. Let’s treat scaling issues latter. Create something that can be scaled horizontally dumbly, like a monolith you can run on n servers so you can scale without loosing money and then scaling can become your problem.

And that’s probably never if you are b2b like a majority of companies, since your usage depends and can be predicted from your sales team performance.

It's a chicken and egg problem.

How would you gain professional experience in something that is out of your current scope?

For example, if a frontend web developer wants to pivot to backend using serverless.

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 units, VM images, containers, schedulers, etc.

I guess you could pretend mod_php serverless until it needs to be load balanced and then it turns out the code actually relies on writing to the filesystem...

I've used graphql at a small company because it solved a specific problem we had, which was how to deduplicate all our kludgy page-specific views and let front end devs write new ones easily. I've also written runbooks and playbooks and used lambda functions to grab webhook payloads.

The given examples are really weird to me because they're some of the few things from gigantic companies that actually work properly.

As one that usually works in the 99% developer space, when we adopt stuff like GraphQL or serverless, is mostly because we are forced into it by new products, or they were the sales pitch to get new consulting gigs.

Reply on news.ycombinator.com