The idea of the book is to pull away a lot of the hype of big cloud providers, show practical steps how we run things over at Talk Python (podcast, courses, e-commerce, and more).I hope some of you find this refreshing!
You can read the first 1/3 online for free. The rest is available DRM free.
Seems interesting, read the online summary. I am curious to read about your part on Chapter 14 (I am part of Litestar maintainer). Thank you for the book anyway !
"Have you heard the phrase "You're not Google, you're not Facebook, and you're not Netflix"? The TL;DR; is those tech giants that have 1M+ concurrent users. They have a hard requirement for no downtime."
Actually, one of the more interesting parts of the Google SRE book was that they don't try to aim for 0 downtime. They consider the background error rate of any network request and optimising much beyond this is counter productive.
Even for individual services they make a point of not trying to make them perfectly available, as this means downstream services are less likely to build in adequate provision for failure.
Unrelated to the content: why on earth is super-light grey a good "bold" colour for a white background? I'm having to highlight each of the bolded parts of the text just to understand it :/
edit: console command for anyone else struggling to read this `document.documentElement.style.setProperty('--bulma-strong-color', '#000');`
Didn't yet go through the content, but having a AI generated image that you didn't even bother to at least touch-up a bit to fix the text does not give me a lot of confidence about the effort that went into this.
You can and probably should go thinner than this, with uv we effectively have a workflow comparable to deploying static binaries in other language stacks. You don't need the complexity of docker for this book's goal.
This go thin with uv is good advice for smaller projects. But as you grow with more aspects, it gets more problematic.
I ran code that way for years. But now we have 23 different services: web apps, APIs, and database servers, my code and other self-hosted services.
I would NOT run 23 projects/servers (3 versions of postgres) this way. Like so much, it depends. FWIW, the book goes into depth about these trade-offs.
I don't know, but the "Read Online" button leads me to "https[://]talkpython.fm/books/python-in-production/#read-online", and that URL then tries to redirect to "https[://]talkpython.fm/books/python-in-production#read-online". (Notice how the last slash of the path is missing).
This forced my browser to reload the page, and it beats the entire purpose of anchoring and fragment-based navs.
The book needs to remove the AI images. They are actively hurting the eyes with the wrong and weird perspective.
It is pretty light reading, name dropping a lot of software without going into details.
As always with Python: These books do not tell you the downsides, and the future of Python is uncertain because the governance has been taken over by a bunch of mediocre weirdos. Python core has always suffered from the problem that occasionally smart people implement something and then leave, but the majority of core devs are pretty dumb and they can now vote in their own after van Rossum left.
I'm glad to see people recognizing that computers are quite fast and that they don't need massive cloud-scale solutions for simple problems. That being said, Python really shines as glue code and in small scripts where performance doesn't matter. You'll see considerable performance (and likely maintainability) gains by moving off of Python to almost any other language.
21 comments
[ 3.3 ms ] story [ 57.3 ms ] threadYou can read the first 1/3 online for free. The rest is available DRM free.
Actually, one of the more interesting parts of the Google SRE book was that they don't try to aim for 0 downtime. They consider the background error rate of any network request and optimising much beyond this is counter productive.
Even for individual services they make a point of not trying to make them perfectly available, as this means downstream services are less likely to build in adequate provision for failure.
edit: console command for anyone else struggling to read this `document.documentElement.style.setProperty('--bulma-strong-color', '#000');`
A 8 CPU / 16 GB Ram server at Hetzner is $30 or so per month. It's $200+ at AWS / Azure.
Bandwidth is 4TB included from free at Hetzner, it's $92.16 / TB or $368.64 additional at AWS / Azure.
That is where the 6x comes from. It's described in detail with that math in the book BTW.
Was hoping the book would cover data persistence.
I ran code that way for years. But now we have 23 different services: web apps, APIs, and database servers, my code and other self-hosted services.
I would NOT run 23 projects/servers (3 versions of postgres) this way. Like so much, it depends. FWIW, the book goes into depth about these trade-offs.
This forced my browser to reload the page, and it beats the entire purpose of anchoring and fragment-based navs.
It is pretty light reading, name dropping a lot of software without going into details.
As always with Python: These books do not tell you the downsides, and the future of Python is uncertain because the governance has been taken over by a bunch of mediocre weirdos. Python core has always suffered from the problem that occasionally smart people implement something and then leave, but the majority of core devs are pretty dumb and they can now vote in their own after van Rossum left.