Operations | Monitoring | ITSM | DevOps | Cloud

We've all heard from an engineering leader about the exact moment they realized their architecture had gotten too complex. It usually happens when they look at a service map and realize it looks like a box of tangled Christmas lights. This cognitive overload is exactly what Steve Evans, the former SVP of engineering at Chegg, reflected on in a recent post on LinkedIn. He argued that microservices were a trillion dollar mistake because we often over-build for future problems that never actually arrive.

At Cortex, our mission is to help engineering organizations deliver reliable, secure, efficient software, faster. With Cortex, teams can standardize against best practices and create a culture of continuous improvement to achieve this. Today, we’re excited to announce a formalized partnership with Semgrep, a leader in modern static analysis and code security.

OpenTelemetry instrumentation is the foundation of modern microservices observability, but getting it right in production requires more than just enabling auto-instrumentation. This guide covers production-tested OpenTelemetry best practices that help engineering teams achieve reliable distributed tracing, control observability costs, and extract maximum value from their telemetry data.

We know that AI has been transformational for engineering and it will continue to be, so stop me if this sounds familiar. Imagine an engineering lead opening a pull request for a critical security patch and finding five hundred lines of AI-generated code. While the solution is (mostly) usable, it follows a pattern no one on the team recognizes. This shift away from manually writing every line of logic has introduced a unique level of complexity for teams.

Most engineering leaders have a very known and very annoying "normal error." It's the log entry or deployment glitch that has been around so long that it is simply accepted as part of the status quo. Jeff Schnitter, a Solution Architect at Cortex, describes this as a form of organizational Stockholm syndrome. This mindset is unsustainable for several reasons.

I remember the first time I used an AI coding assistant. I watched the cursor dance across my screen and generate a hundred lines of code in seconds. It felt like I had finally found a cheat code for software engineering. That initial rush of productivity is a dopamine hit that's intoxicating and makes you think you can do anything with just a simple prompt or two.

If you’ve ever tried to debug a request that touched five services, a queue, and a database you don’t own, you already know why monitoring distributed systems is hard. Logs live in different places, requests disappear halfway through a flow, and when something breaks in production, you’re reconstructing what happened from fragments. Microservices make this worse by design. A single request fans out across small, independently deployed services, often communicating asynchronously.

Anyone who has ever attempted to learn the guitar knows the lure of buying high-end gear. Surely, an expensive guitar and a best-in-class amplifier will hide the fact that you only know a few chords and maybe the lead line to that one song you keep hearing on the radio. What most players find out, however, is that spending thousands of dollars on gear doesn't change the fact that you're not that good yet.

As a baseline, engineering leaders need their teams to adopt AI tools to speed up velocity and ship faster. Most organizations have already rolled out AI coding assistants or are evaluating them, but there's a really big difference between buying a tool and successfully scaling it across an engineering organization. If you layer AI on top of a chaotic codebase or a disorganized service catalog, you accelerate the creation of legacy code.

Modern software systems are more distributed, complex, and business-critical than they've ever been. A single misconfigured service can take down an entire platform. Teams are aiming for production readiness, which is the state where your services are secure, reliable, observable, and owned. Production Readiness Reviews (PRRs) are one of the key mechanisms to get there.