spyspy

Probably just regular ol' overtime abuse.

If you care about your health at all, do NOT buy a jar of trader joe's cookie butter, or their cookie butter ice cream...

How is the stone wall that's been holding up my house for over 100 years a liability? You know it's still there even when it's covered with drywall right?

Homes need more whimsey. I recently discovered one of my interior doorways is actually a stone archway that someone had squared off, drywalled and installed a cheap hollow door for no apparent reason. Working with a stonemason to re-point/parge it and bring it back to glory. Will I ever see a return on this investment? Probably not but fuck it it'll make my house just that much cooler.

The good ol' Fastly approach. Have your stock pump after you go down because no one had any idea how many websites depended on you.

The way I've set these things up, nothing talks directly to the identity service. The ID service is a backend behind your gateway like any other service and any UI would have to have the request proxied through the gateway to reach it. Now, you can carve out certain rules (if you control the gateway) where requests headed to /users/* don't require the same authN steps other requests do because it's already headed to the ID server. Internal UIs may or may not work the same, that's really up to you - they won't likely be super high scale. Often the support teams won't even be querying the real DB, but instead a view or copy so they can't affect real user data. A share code for users A->B would just be a request from the UI to the ID server via the gateway, authenticated as User A, and responding with the code for B if possible. Or, I've do it where you could have special logic in the gateway to query 2 servers and combine the responses. No need for services to make requests sideways. Hope that makes sense.

Don't give them ideas.

The trick is to have your gateway handle authn, and then proxy authz data upstream so those services can decide how to handle it without needing to make a second call to the identity service.

The trick I've used is the N1 (gateway) service handles all AuthN and proxies that information to the upstream services to allow them to handle AuthZ. N+ services only accept requests signed by N1 - the original authentication info is removed.

Treating N4 as a service is fair. I think the article was leaning more toward that idea of N4 being a database, which is a legit bad idea with microservices (if fact defeating the point entirely). My takeaway is that if you're going to have a service that many other services depend on, you can do it but you need to be highly away of that brittleness. Your N4 service needs to be bulletproof. Netflix ran into this exact issue with their distributed cache.

`SELECT * FROM mytable ORDER BY timestamp ASC`

I'm still convinced the vast majority of kafka implementations could be replaced with `SELECT * FROM mytable ORDER BY timestamp ASC`

If you haven't been following space updates closely, the US is _already_ in a race with China, especially in regards to the Artemis (moon) missions. That being said it's mostly being used as an excuse to keep SLS alive and prop up the legacy space contractors... It's hard to lose a contest you won 60 years prior...

This reminds me of the journalist working for months on uncovering Trump's dirty business just for Trump himself to admit the entire thing in a tweet.

If you do use terraform, for the love of god do NOT use Terraform Cloud. Up there with Github in the list of least reliable cloud vendors. I always have a "break glass" method of deploying from my work machine for that very reason.