Email or username:

Password:

Forgot your password?
All posts Jason's posts Post Back to profile
Jason Lefkowitz

This is a good look at how Standard Ebooks runs their whole operation off a single relatively modest VPS.

There is a lot of wisdom here that is unfortunately deeply unfashionable these days. If you can serve mostly static files, it's easy to scale like crazy. If you can fit your data entirely in memory, it's easy to scale like crazy. Your database is almost always the first bottleneck you hit, so if you can do without a database, it's easy to scale like crazy.

Developers have poured out sweat over the last couple of decades to get you working in ways that make it hard to scale like crazy. But you can always just... not do that.

alexcabal.com/posts/standard-e

4 January at 2:41 | Open on octodon.social
22 comments
Tokyo Outsider (337ppm)

@jalefkowit "Developers have poured out sweat over the last couple of decades to get you working in ways that make it hard to scale like crazy."

What do you think has been the driver for that?

4 January at 3:11 | Open on mas.to
Jason Lefkowitz

@tokyo_0 It's not malicious or anything. It's just... we're all human beings, left to our own devices we will eventually overcomplicate things.

And simplicity doesn't get you asked to speak at conferences, guest on podcasts, etc. Adding complexity is a reliable career enhancer. (And by the time the bill comes due, your celebrity has moved you on to greener pastures.)

4 January at 3:13 | Open on octodon.social
SysAdmin1138

@tokyo_0 @jalefkowit In my experience, interactivity is what drives much of this. If you're there to do a job (which isn't "read 10K words of a novella") making changes and having them reflected back to you drives a lot of this complexity. Most blogs would be quite happy as static files with a small set of pages for comment-writing and admin.

4 January at 3:23 | Open on octodon.social
Cegorach

@tokyo_0 we all tend to fall into the "yeah, but I can't use the old stuff, because MY PROBLEMS ARE COMPLICATED!" hole.

so we reinvent the wheel and overcomplicate solutions

sometimes we're somewhat correct in that, but most of the times it's just in error

and then the solutions not only have to support YOUR complex stuff, but everone elses complex stuff too. The simple use-case tends to get ignored, because that's solved already.

You don't become a hero by solving how to butter bread.

4 January at 7:53 | Open on chaos.social
Tokyo Outsider (337ppm)

@drazraeltod I hear what you're saying, but what was being described in the initial posts seems like more than just reinventing what has already been written once already. Your last line seems closer to the mark: "You don't become a hero by solving how to butter bread."

4 January at 9:26 | Open on mas.to
Cegorach

@tokyo_0 nah, the initial post is just that (actually it's LESS than reinventing anything)

they buttered bread - even the same way most people do

they took the most mainstream of parts (Apache, PHP, Linux, HTML, CSS) and left out moving parts that weren't needed for their use case.

the whole static site idea is pretty similar to that (but those mostly use nginx or so AND have no need for ebook processing)

the only thing they did is going half way to least complexity. And that's totally fine.

4 January at 10:17 | Open on chaos.social
Forbearance

@jalefkowit
> But you can always just... not do that.

Words to live by

4 January at 3:30 | Open on mastodon.xyz
Mike :nixos:
Si Dawson

@jalefkowit @xurizaemon That was an AMAZING read. Thank you.

Enormously validated a series of grudges that have been growing in me the last decade or two.

4 January at 4:18 | Open on mastodon.nz
Tim Lavoie

@jalefkowit I love the part where Github is merely a mirror, not the origin.

It's important to keep control of your own processes.

4 January at 5:03 | Open on cosocial.ca
Eli the Bearded

@jalefkowit A few jobs ago the way they managed scaling was precomputing all possible answers, sticking them in a key-value (not SQL but Berkeley DB) in memory and using some basic C code to manage the security and accounting.

4 January at 7:08 | Open on fed.qaz.red
Niclas Hedhman

@jalefkowit

A friend of mine created a content management system for the Swedish Tax Authority and he ran that off a laptop ~18 years ago, a few days before tax return filing, with 12 million hits per day. And that was NOT statically generated, but DB backed and heavily cached.

Root cause is (more often than not) that people no longer asks "Why?" for each technical decision and think about it critically.

@eskatos

4 January at 7:37 | Open on angrytoday.com
bison ✅

@jalefkowit haven't read it fully yet, but scanning over it I will read it later with time and make my padawans read it too.
Some of my small website projects actually work only with a few php arrays and without databases like spielmannspiel.com/
I think we lost something in time, that something simple can serve a purpose too without over engineering it
So thanks for this post in advance :BlobhajHeart:

4 January at 7:40 | Open on mastodon.social
bison ✅

@jalefkowit finished reading it, thank you! an exceptional great and amazing blog post :BlobhajHeart:

4 January at 10:11 | Open on mastodon.social
Haelwenn /элвэн/ :triskell:
@jalefkowit Your post reminds me of exactly why I don't like the ideology of scalability™, as if you could take a thing and use it at any scale, which is a trap.

Software doesn't needs a database as long as what's needed to be parsed (so static files excluded) can fit into RAM and other kind of upper limits like storage latency.
And a database is something that itself needs maintenance and special software (in-database data typically being non-portable, eww) with added complexity to use it, so it's seriously worth it to just plainly avoid it.
@jalefkowit Your post reminds me of exactly why I don't like the ideology of scalability™, as if you could take a thing and use it at any scale, which is a trap.

Software doesn't needs a database as long as what's needed to be parsed (so static files excluded) can fit into RAM and other kind of upper limits like storage latency.
4 January at 7:58 | Open on queer.hacktivis.me
iameru

@jalefkowit in the end the article says: if you can serve your stuff (~700 ebooks) statically, do it. I agree but this website does not need dynamic content, there is no user account or payment or whatever. If you just serve files, well of course, just serve files..

4 January at 8:19 | Open on leipzig.town
Interpipes 💙

@jalefkowit even if you do have a database there’s certainly ways and means to make your compute go further if your application is amenable to result caching etc.

A customer was recently acquired by another firm who has apparently been blown away at how little our customer spends on compute with us vs the larger firm’s spend on AWS to achieve less throughput.

4 January at 9:00 | Open on thx.gg
HoldMyType- main :: [Response]

@jalefkowit til 78 pc of #webdev still happens in #php

(personal note- and I considered that as an option, what was I thinking)

4 January at 9:20 | Open on emacs.ch
Space Hobo Actual

@jalefkowit Except the answer is actually "We have a very dynamic Web site running PHP stuff, but the database is cached in RAM because we only have 630 records."

4 January at 10:12 | Open on teh.entar.net
Santiago Lema :amiga:

@jalefkowit A very refreshing read! I also got more and more convinced of that approach of using just files when possible and only using builtin features of the language.

I also went down the shady hills of changing frameworks, dependencies, APIs and cloud. I stopped.

Today I feel relief when I find something that’s 10 years old and doesn’t need a full rewrite just to check how it looks/works. This is particularly meaningful if you have long periods of “downtime” as a person.

4 January at 10:26 | Open on masto.lema.org
chris

@jalefkowit There is the sort of wisdom involved that is visible to people whose answer to the question "what framework do you use?" is "php".

4 January at 11:13 | Open on social.inzeiten.de
Go Up