[phtrivier]

Maybe. How do I find the O'Reilly book that explains that ? And the petty details about knowing the first one is down and starting the backup ? And just enough data replication to actually have some data in the second machine ? Etc, etc...

My pet peeves with distributed and ops books is that they usually start by laying out all those problems, but then move on to either :

- explain how Big Tech has even bigger problems, before explainig how you can fix Big Tech problems with Big Tech budgets and headcound by deploying just one more layer of distributed cache or queue that vietually ensures your app is never going to work again (That's "Desifning Data Intensive Applications", in bad faith.)

- or, not really explain anything, wave their hands chanting "trade offs trade offs" and start telling kids stories about Byzantine Generals.

[lmwnshn]

More entertainment than how-to guide, and oriented more towards developers than ops, but if you haven't read "Scalability! But at what COST?" [0], I think you'll enjoy it.

[0] https://www.frankmcsherry.org/graph/scalability/cost/2015/01...

[arinlen]

> explain how Big Tech has even bigger problems, before explainig how you can fix Big Tech problems with Big Tech budgets and headcound (...)

What do you have to say about the fact that the career goals of those interested in this sort of topic is... Be counted as part of the headcount of these Big Tech companies while getting paid Big Tech budget salaries?

Because if you count yourself among those interested in the topic, that's precisely the type of stuff you're eager to learn so that you're in a better position to address those problems.

What's your answer to that? Continue writing "hello world" services with Spring Initializr because that's all you need?

[phtrivier]

> Because if you count yourself among those interested in the topic, that's precisely the type of stuff you're eager to learn so that you're in a better position to address those problems.

People will work on problems of different scales in a career ; will you agree that different scales of problems call for different techniques ?

I have no problem with FANGs documenting how to fix FANGs issues !

I'm a little bit concerned about FANGs-devs-wanabee applying the same techniques to non-FANGs issues, though, for lack of training resources about the "not trivial but a bit boring" techniques.

Your insight about the budget / salaries makes sense, though : a book about "building your first boring IT project right" is definitely not going to be a best seller anytime soon :D !

[enumjorge]

Nothing wrong with having those aspirations, but sounds like the parent commenter has non-Big-Tech-sized problems he needs to solve now.

[EddySchauHai]

What you’re describing there sounds like general Linux sysadmin to me?

[phtrivier]

Not entirely, I would argue, if you look at it from the application développer.

You have to adapt parts of your app to handle the fact that two machines might be handling the service (either at the same time, or in succession.)

This has impact on how you use memory, how you persist stuff, etc...

None of which is rocket science, probably - but even things that look "obvious" to lots of people get their O'Reilly books, so...

But you're right that a part of the "distribution" of a system is in the hands of ops more than devs.

[EddySchauHai]

I guess it's just experience to be honest. It happens rarely, you might be lucky enough to be involved with solving it, and then you focus on the important parts of the project again. I've only worked in startups so don't know about the 'Big Tech' solutions but a little knowledge of general linux sysadmin, containers, and queues has yet to block me :) Once the company is big enough to need some complexity beyond that I assume there's enough money to hire someone to come in and put everything into CNCFs 1000 layer tech stack.

Edit: Thinking on this, if I want to scale something it'd be specific to the problem I'm having so some sort of debugging process like https://netflixtechblog.com/linux-performance-analysis-in-60... to find the root cause would be generic advice. Then you can decide to scale vertically/horizontally/refactor to solve the problem and move on.