Operations | Monitoring | ITSM | DevOps | Cloud

You're in a planning meeting when someone asks a simple question. How long does it actually take your team to ship a feature? You've got spreadsheets, Git logs, and Jira exports scattered across three tabs, and you still can't give a confident answer. It's a question you should be able to answer instantly, but the data lives in too many places to stitch together on the fly.

Pragya Jazwal, Platform Engineering Lead at Paxos, compared standing up an internal developer portal to buying a gym membership during her talk at IDPCON 2025. Purchasing the software is one thing, but convincing a team of busy engineers to change their daily habits is a much bigger monster to tame. Pragya says the platform team at Paxos learned this lesson the hard way.

Throughout 2025, we watched AI transform from a novelty into a non-negotiable requirement for engineering teams. Leaders moved quickly to roll out coding assistants, driven by the promise of unprecedented velocity. But as we settle into this new reality, it’s becoming clear that there is a massive difference between buying a tool and successfully scaling it. You can't just drop AI into a complex organization and expect it to work without a solid foundation.

In the late 2000s, the big question in database design was SQL or NoSQL. While relational databases had long held their ground, document and key-value stores were emerging as serious alternatives. Many predicted a zero-sum, winner-take-all outcome. But when we look at how organizations are using database technologies today, no single tool or category has dominated the landscape.

These days, engineering leaders find themselves caught between a rock and a hard place. On paper, AI adoption looks like an unqualified success. Developers are shipping more code faster than ever, pull request volumes are up, and teams report feeling more productive. Their leaders rush to LinkedIn to share their plans to scale adoption because their teams are just so much more efficient. But then, the incidents and bug reports start piling up.

There's a moment every engineering leader hits when implementing AI where they realize that no one really knows what they're doing. Not your competitors. Not the consultants. Not even the executives pressuring you to show results yesterday. Everyone is figuring this out in real time, and beneath the confident vendor pitches and LinkedIn thought leadership, the truth is messier than anyone wants to admit.

This blog is based on Haylee Millar's talk at the Symfony 2024 conference. Haley is a Product Engineer at Upsun. We utilized AI tools for transcription and to enhance the structure and clarity of the content. When faced with an aging system that needs new features, many development teams find themselves at a crossroads. Do you patch the old system and risk technical debt, or do you take the leap into microservices architecture?

You've set up the Cortex MCP and connected it to your AI assistant and IDE. You ask about service ownership, check a Scorecard or two, and it works. You're impressed by how much faster this is than clicking through the web UI. Now you're wondering what else you can do with it. I'm willing to bet we've hit a nerve with that "hypothetical" scenario. The Cortex MCP works exactly as designed, but it's deceptively difficult to know which questions to ask and when to ask them.

For decades, engineering leaders have struggled to measure the productivity of their developers. Metrics such as number of PRs merged, lines of code changed, hours worked, and tickets closed were always flawed. They incentivized the wrong behaviors and ignored code quality and best practices. Ultimately, they were the perfect formula to make Goodhart's Law a reality. Measures became targets, which meant they ceased being good measures.

Development teams depend on microservices to build, deploy, and scale features independently. Microservices have become the backbone of modern, scalable applications. Scaleway’s managed Kubernetes service (Kubernetes Kapsule) offers a powerful, cost-effective platform for running containerized workloads in the cloud. It’s a great fit for startups and solo engineers who want to focus on shipping features, not managing infrastructure.