A reasonable take to unpack and nuance uptime so that it leaves the realm of engineering and becomes a business decision as it should be.
Also good for engineering organizations to remember that: 1. You’re not Google. 2. Most of the practices in the SRE book are not applicable to you.
https://world.hey.com/itzy/uptime-guarantees-a-pragmatic-perspective-736d7ea4
The post makes it look simple but pulling off a database migration project like this is very difficult to get right and incredibly costly in terms of time and attention that it requires.
https://www.figma.com/blog/how-figma-scaled-to-multiple-databases/?ref=architecturenotes.co
A handy overview of how to hire for developer tooling and how to improve the developer experience at companies from a perspective that recognizes these are socio-technical issues but also needs to get stuff done.
What you’re looking for, I think, is someone who can take “developer experience” and push that forward holistically by whatever way is necessary. The hardest things they will have to do is gain the trust of the entire engineering organization, buy-in for their approach, and deliver perceived value and improvements.
This role is truly a Sociotechnical Engineer, in every sense of the term; they will expose the weaknesses of your company in ways you are not prepared for, and they will challenge the status quo in ways that are painful. Embrace it. Be prepared to grow as much, if not more, than they do.
I prefer to use contributing factors over the concept of a “root cause” and if people believe an incident has a single cause, usually that also means that they’re not very serious about reliability engineering.
We’re seeing a bunch of these posts come around serverless around the time that we too are reconsidering our investment in this area. Lambda has a lot of operational benefits but at larger scales the developer experience just does not keep up.
A long post that builds up to async Rust from the ground up and explains how the various bits and pieces work. Really quite the tour de force with a simple conclusion: use Tokio.
With our re-evaluation of Lambda as a platform and after talking to some people, I’d say that Rust is the most (maybe the only) viable language on Lambda mostly because it’s negligible cold start times, high performance and the amazing developer experience of aws-lambda-rust-runtime.
https://loige.co/why-you-should-consider-rust-for-your-lambdas/
It’s interesting to see how the dynamics of Indian society influence the tech industry globally and it’s very useful to learn more about it.
The examples are hugely exaggerated for effect but the explanation of why so many people in software engineering keep themselves busy with solving imaginary problems is worth it.
https://cerebralab.com/Imaginary_Problems_Are_the_Root_of_Bad_Software
Every time I mention slack time as one of the most important things for healthy engineering teams people look at me as if they’re seeing water burning.
That doesn’t make it any less true though. Here’s a brief note by Martin Fowler on the topic: https://martinfowler.com/bliki/Slack.html