raghava

Most down-detectors are down due to their dependency on CF.

Cloudflare Mumbai, Bengaluru, Chennai, Hyderabad edge-nodes also unable to serve content.

x.com down.

Few quick-commerce apps are acting up at times.

Interesting set of points; the intent to move beyond sterile dashboards and engage in deeper, more meaningful conversations about system health is very welcome, especially in a time when most leaders don't bother to read about Goodhart's law on metrics.

But still, I spot a few points of concern.

- While experienced engineers develop valuable intuition, this can also be a source of significant bias. An engineer's "feeling" might be influenced by their personal comfort with a particular technology, their resistance to change, or their own role in creating the system in question (the "IKEA effect"). Over-relying on intuition can lead to subjective decision-making that isn't backed by evidence.

- What is "simple" for a senior engineer with years of context might be overwhelmingly complex for a new team member. Furthermore, some business domains are inherently complex, and attempting to impose a simplistic model can lead to a system that fails to capture the necessary nuance and ultimately creates more problems.

- Informal discussions can be dominated by the loudest voices, the most senior people in the room, or those with the most social capital. Junior engineers or those with dissenting opinions may not feel comfortable speaking up, leading to a skewed and incomplete picture of the system's health. A more formal "safe space" approach might help here, to increase psychological safety perception of participants, for a better discussion.

- For large, legacy systems that have been in production for years, questions like "Can we explain the system's responsibility in plain English, within 5 minutes?" or "Do simple modifications you expect in hours, take many days?" can be demoralizing rather than constructive. They might highlight known, intractable problems without offering a clear path forward, leading to shame, anxiety and frustration.

Disaster stemming from the deadly combo of Dunning Kruger effect + network effect + recommendation algorithms floating similar BS up top.

Most who post absolute BS on such "professional" forums as a way to gain a larger "network" easily attract similar ones with relatable mediocrity index. The network effect kicks in and mediocrity gets amplified.

Everyone thus gets forced to either to act insanely ridiculous or just GTFO to retain whatever little sanity they have left in them.

Most corporate jobs are just mediocrity-maxxing absolutely BS jobs. It is only natural that the most popular corporate SM amplifies and promotes BS and mediocrity at scale.

just came across this. am not the author/dev behind this. sounds like a very cool project.

I don't think that is the case even now.

Don't know much about LatAm now but can comment on conditions in Asia.

In fact, internationalization and local language input (especially for Indic content) is much more neater and simpler in Linux as I have seen. And in India/Indonesia/Philippines especially, most SMEs/startups/mid-or-small-banks simply use English itself and get the job done. Except for some PR related stuff, all content and data that they manage is almost always in English only.

> I wonder how the 8K to 6K reduction happened.

As said, most of their workloads were on cheap VPSs before. Moved some to 'scale-to-zero' solutions, reduced the bloat in VMs, fixed some buggy IaC, also moved some stuff to the serverless scene. That got a decent ~20% reduction.

Points to be noted.

1. It took the end of ZIRP era for people to realize the undue complexity of many fancy tools/frameworks. The shitshow would have continued unabated as long as cheap money was in circulation.

2. Most seasoned engineers know for the fact that any abstractions around the basic blocks like compute, storage, memory and network come with their own leaky parts. And that knowledge and wisdom helps them make the suitable trade-offs. Those who don't grok them, shoot themselves in the foot.

Anecdote on this. A small sized startup doing B2B SaaS was initially running all their workloads on cheap VPSs incurring a monthly bill of around $8K. The team of 4 engineers that managed the infrastructure cost about $10K per month. Total cost:$8K. They made a move to 'cloud native' scene to minimize costs. While the infra costs did come down to about $6K per month, the team needed new bunch of experts who added about another $5K to the team cost, making the total monthly cost $21K ($6K + $10K + $5K). That plus a dent to the developer velocity and the release velocity, along with long windows of uncertainty with regards to debugging complex stuff and challenges. The original team quit after incurring extreme fatigue and just the team cost has now gone up to about $18K per month. All in all, net loss plus undue burden.

Engineers must be tuned towards understanding the total cost of ownership over a longer period of time in relation to the real dollar value achieved. Unfortunately, that's not a quality quite commonly seen among tech-savvy engineers.

Being tech-savvy is good. Being value-savvy is way better.

> there is a great opportunity to help businesses manage their software supply chain

Yes, very much. There are so many layers, components, and their intricate relations that goes totally ignored today at least in most places. Because, doing so is insane amounts of work. Only BigCos can afford to have dedicated teams for 's/w supply chain management', considering the cost-parity-with-returns. However, the solution on this end that works for BigCo doesn't necessarily work for SMEs & startups. That gap isn't small, if am right.

> Another product that is often requested is a visual DAG debugger. When a pipeline break, you want to know why, and staring at your CI logs is definitely not the best experience for that. With a web UI, there's a lot we can do there.

Yes. This definitely helps. But more than a viz DAG element, people look for an early-warning of a failure. Most common build-failure reasons (other than failed tests) -> expired creds used somewhere in the pipeline, provisioning failed/time-out, problem at some other dependent module totally outside org's control (some OSS/dep). People seem to be bothered equally about how to squash'em rather than just where to squash. Locating the part where pipeline broke is just half the part. Actionable insights as to how that pipeline can be healed is the hard part. And considering the diversity of the ecosystem, that's gonna be a wild ride.

BTW, are you folks hiring? "DevOps OS for enterprises" seems very very enthralling, esp for an old toolmaker.