Ahead of his 2026 Nordic APIs Summit talk on scaling data ingestion without turning to Kubernetes, we check in with Bauer Media Group UK’s Faith Sodipe to talk about infrastructure complexity.

In the tech space, perhaps more than in any other, we are always looking for the next big thing. Whenever a new platform, standard, or architectural pattern emerges, you don’t usually need to look far to find someone calling it “the future of” this or “the next evolution” of that.

It’s easy to get swept up in hype cycles and adopt an approach that sounds impressive, only to realize later that it wasn’t the best choice for the project at hand. In some cases, that’s because the technology in question is flawed or immature. But it’s not true in every case.

During a capacity-planning exercise at a previous company, Faith Sodipe and his team found themselves drifting towards deploying Kubernetes. It’s a respected solution that’s been around for more than a decade, but when he considered using it in this instance, he realized it would have been overkill.

Most of us have been in his shoes, looking seriously at a certain solution, especially one that’s new and shiny — even though some part of us knows we’re, as the kids say, doing too much. In advance of his Nordic APIs Summit 2026 talk, Faith joined us to talk about how to avoid falling into that trap.

“What Problem Are We Actually Trying to Solve?”

That’s the question that Sodipe kept coming back to after a series of internal engineering meetings during the project in question. The answer, he realized, “wasn’t that we need orchestration. It was that we need better monitoring, efficient database query patterns, a modernized and controlled deployment strategy, and better code optimization.”

“Kubernetes would have added a control plane,” he told us, “along with networking complexity and a learning curve, but it wouldn’t have fixed our actual bottleneck. So we chose to invest in the data layer instead of setting up complex infrastructure.” This all clicked when he realized they were considering using Kubernetes for the buzz, not because they actually needed it.

It’s a classic case of infrastructure as theater, when the technical solution far exceeds the requirements of a project. And Sodipe freely admits that he, like many of us, has felt the pull of infrastructure complexity as a status symbol: “There is something about saying to another engineer that ‘we run Kubernetes in production’ or ‘we have a service mesh.’ It signals that your system is running at an enterprise scale, even if you are not even remotely close to it.”

And Sodipe highlights that keeping up with the Joneses has real consequences that go beyond the financial implications of maintaining overengineered solutions: “It drives teams to adopt tools before they have the problems those tools solve. And that shifts focus away from what actually matters: clean code, good API design, and deep understanding of your domain.”

Boring as a Feature

His team’s initial fixation on Kubernetes led them to overlook the root cause of the problem they were facing: that their bottleneck was a data-layer problem, not an orchestration problem. As such, moving to Kubernetes would have added complexity without fixing the root cause.

“Our ingestion engine processes close to a million events daily, with variable payload sizes and bursty traffic patterns. The core requirement was predictable latency at high throughput and the real constraint was never CPU or memory allocation; it was I/O and data serialization.”

When Sodipe explains how his team “leaned heavily on three pillars of observability” for the project, he uses the same word multiple times to describe the tools they used: boring.

• Logs: Structured JSON logging aggregated into Loki, a log aggregation system
• Metrics: Prometheus-style metrics exposed from API layer, visualized in Grafana
• Traces: Key paths instrumented with OpenTelemetry, but only for critical flows

.Be sure to attend Nordic APIs Summit 2026 for Sodipe’s upcoming talk for more on implementation, as well as questions and answers.

None of this, he explains, actually required complex infrastructure. “A containerized service, a good load balancer, and a thoughtful monitoring stack got us 99.9% uptime. Orchestration doesn’t necessarily give you observability — it just gives you more things to observe.”

Infrastructure Theater vs. Engineering Judgment

There are, Sodipe suggests, some dead giveaways when it comes to identifying when deployment of a solution is real infrastructure and when it’s theatrical: “One thing that’s particularly common,” he says, “is that when you ask them what their goals were, they end up describing what they built, and how they built it, rather than what they fixed.”

Real infrastructure work is invisible because it just works, while theater is loud, proud, and constantly requires attention. And that manifests in things like time spent managing infrastructure vs. spending time building meaningful features. “If your platform team outnumbers your product engineers,” Sodipe jokes, “then something is definitely off.”

The realities of the scale at which teams are working are also a key factor here. In other words, is a team adopting a tool before they actually have the problem that said tool solves? “If someone mentions running a service mesh but only has three services talking to each other,” Sodipe remarks, “then that screams overengineering to me.”

Hallmarks of infrastructure theater, like those outlined above, are often easier to identify in other people’s projects than they are your own. As such, thinking critically about every project you encounter — even if it feels like you’re picking apart another developer’s work — can be valuable in developing an eye for whether or not “a solution” is a solution at all in your own projects.

When Simplicity Becomes a Selling Point

There is, of course, an elephant in the room here: the concern is genuine that a “boring” stack may be viewed as outdated or a failure to innovate by potential customers, partners, and employees. In his experience, however, Sodipe has found the opposite to be true:

“On the customer side, it has actually been a positive differentiator for us. When we tell prospects we run a simple, proven stack, they actually feel more confident, not less. They see stability in our approach, rather than the risk that comes with untested technologies.”

On the hiring side, he admits, it’s been more mixed. He describes candidates, especially more junior ones, asking why the company isn’t using Kubernetes or some other setup, and whether the stack is outdated. “There’s definitely an initial hesitation,” he says.

“But the engineers who think critically often appreciate it,” he continues. “They ask follow-up questions like: What was the trade-off analysis? How do you handle failover? What’s your deployment cadence? In this situation, those are the people we want.”

Make no mistake, Sodipe is no Luddite: during our conversation he calls Kubernetes “an incredible piece of engineering for solving real problems at real scale” — hundreds of engineers, millions of daily requests, he suggests — “but it is a solution, not an identity. Why would you pay a complexity tax for features you have no intention of actually using?”

As we wrap up, Sodipe returns to the question at the beginning of this piece — “What problem are we trying to solve?” — and follows it up with another: “Is this the simplest tool for that job?” If the answer to that question is no, it might be time to consider getting a little more boring.