Respectfully, neither of these docs strike me as really sufficient to debug live running systems in the critical path for paying users. The first seems to be related to the inner development loop and local the second is again how to attach gdb to debug something in a controlled environment
Crash reporting, telemetry, useful queuing/saturation measures or a Rosetta Stone of “we look at X today in system and app level telemetry, in the <unikernel system> world we look at Y (or don’t need X for reason Z) would be more in the spirit of parity
Systems are often somewhat “hands off” in more change control sensitive environments too, these guides presume full access, line of sight connectivity and a expert operator which are three unsafe assumptions in larger production systems IMO
I was able to setup SigNoz on the order of five minutes to view traces in my Dagger builds locally just by exporting the right env vars — it was nice to not have to run and orchestrate three+ tools together
I don't recall either CORBA or SOAP ever seeing enough penetration to look "eternal" as mainstream tech goes (obviously, and especially with SOAP, there's still plenty of enterprise use). Unlike XML and JSON.
I hear you, but I am not aware of anyone that tried XMLHttpRequest.send('<s:Envelope xmlns:s...') or its '<methodCall>' friend from the browser. I think that's why they cited "of the web" and not "of RPC frameworks"
Eternal or not, right now JSON is used everywhere which means the performance gains of a more optimized Stalin would be significant. Just because we don’t know if JSON is around in 10 years doesn’t mean we should settle for burning extra compute on it.
MongoDB Atlas is a multi-cloud developer data platform that simplifies how developers work with data.
We’re hiring a Site Reliability Engineer to join our Developer Infrastructure team. Our team supports the broader SRE organization by:
- Building and maintaining container images, OS packages, and infrastructure tooling
- Creating self-service Terraform workflows
- Handling cloud resource provisioning across AWS, GCP, and Azure
This is a full-time, remote role for candidates based in the four continental US timezones. Prior familiarity with Bazel, Go, Terraform, Argo workflows and GitHub Actions would be helpful.
MongoDB | Site Reliability Engineer | Full-time | Remote (US-based)
MongoDB Atlas is a multi-cloud developer data platform that simplifies how developers work with data.
We’re hiring a Site Reliability Engineer to join our Developer Infrastructure team. Our team supports the broader SRE organization by:
- Building and maintaining container images, OS packages, and infrastructure tooling
- Managing internal Terraform workflows
- Handling cloud resource provisioning across AWS, GCP, and Azure
This is a full-time, remote role for candidates based in the US. Prior familiarity with bazel, Go, Terraform, Argo and GitHub Actions would be helpful.
If you’re interested, apply at https://www.mongodb.com/careers/jobs/6168913 (ignore JD and mention your interest in the "SRE DevInfra" team in your cover letter/note and the talent partner will route it to the team)
Kaiser in Oakland is without exaggeration the best medical care I’ve ever experienced. Aligning incentives between the care provider and the insurer, vertically integrating care and putting it all on a walkable campus (even with a pharmacy!!) was such an efficient and pleasant process.
I was never healthier. The other Kaisers in Oregon aren’t geographically collocated so there’s less of an effect and they’re far away from me so I don’t use them anymore, sadly
I visited their clinics for my daughter several times when she was a toddler for ear aches and other ailments— I found the experience refreshing: instant online booking, no BS registration and online communication with staff was seamless. Very sad to see them go so abruptly.
Up until this morning when I was told they were gone, I had no idea they were YC or otherwise VC funded. Just came here to pour one out for a genuinely helpful and pleasant medical company.
We had basically the same experience with Kaiser Permanente in the SF Bay Area.
Currently, there’s a doctor shortage problem (supposedly, they can’t hire, or there aren’t enough positions, depending on who you ask), which has caused issues with the quality of care (according to the doctors that went on strike over this, and personal experience).
It’s unclear what the root cause or solution is.
Anyway, you can get the experience you described, and it’s great until you hit an understaffed corner case health problem.
Modulo things like compliance where all changes must be traced back to an auditable review, abandoning the assumption that Pull Requests are necessary to keep the default branch working is an experiment everyone should try.
Having worked on projects where pairing replaced PRs it's virtually unheard of in many shops to trust individuals to this level. But it works just fine in many circumstances because for larger changes you eventually end up using PRs as something more than a rubber stamp.
I have heard the same as well.
These days, I am thinking about how AI code gen can be affecting this. When AI is writing code, you can't assume yourself to be the pair programmer, because your speed is not even close to the AI's. You are basically reviewing the code that AI has written.
So should people be thinking about pair-reviewing AI code so that they get the benefits of pair programming along with the speed of AI?
Crash reporting, telemetry, useful queuing/saturation measures or a Rosetta Stone of “we look at X today in system and app level telemetry, in the <unikernel system> world we look at Y (or don’t need X for reason Z) would be more in the spirit of parity
Systems are often somewhat “hands off” in more change control sensitive environments too, these guides presume full access, line of sight connectivity and a expert operator which are three unsafe assumptions in larger production systems IMO
reply