In this episode, I’m joined by Imran Nino Eškić and Boštjan Kirm from HyperBUNKER, two leaders whose perspective has been shaped by more than 50,000 real-world data loss and ransomware cases. This is not a conversation about theoretical security models or another incremental backup feature. It’s a discussion about what actually survives when production systems, identity layers, and cloud replicas have all been compromised.

For years, infrastructure has been designed around availability, scale, and performance. Recovery was treated as a process that would work when needed. But as attackers have grown more patient and methodical, they now target recovery paths first, quietly mapping environments and neutralising backup systems long before an incident becomes visible to the business. That shift forces a new architectural question for infrastructure leaders. Where is the layer that remains reachable when everything connected has been taken down?

We explore why so many environments that claim to be air-gapped or immutable still rely on credentials, control planes, and automation, and how those dependencies create hidden single points of failure. Imran and Boštjan explain how HyperBUNKER introduces a physically isolated survivability layer into modern infrastructure, using a hardware-enforced, one-way ingestion process and a double air-gap design that removes the network from the vault entirely. No IP address, no inbound ports, and no authentication surface to attack.

This leads to a wider conversation about infrastructure governance, cyber insurance, and regulatory pressure. Insurers are increasingly focused on whether a final, untouchable copy of critical data exists, because the largest financial losses now come from failed recovery rather than the initial breach. That reality is pushing offline recovery out of the basement and into board-level architecture discussions.

We also tackle the practical challenge every organisation faces. If only a small percentage of data can be placed in a fully isolated vault, how do you decide what keeps the business alive? That decision, as we discuss, cannot sit with IT alone. It requires operational and executive alignment around what the company must have to restart after a catastrophic event.

This episode reframes resilience as an infrastructure design principle rather than a security feature. It asks where a survivability layer should sit alongside cloud platforms, backup software, and existing controls, and why the future of Infrastructure as a Service may depend as much on guaranteed recovery as it does on uptime.

If your architecture assumes that recovery will always be there when you need it, this conversation may change how you think about your entire stack.

What happens when the infrastructure your business depends on becomes too complex, too expensive, or too slow to recover when something goes wrong?

In this episode of Infrastructure as a Service, I sit down with Tvrtko Fritz to talk about how EuroNAS has evolved from “NAS for the masses” into a platform helping organizations simplify storage, virtualization, backup, and scale-out infrastructure. What stood out to me in this conversation was how much of that journey was shaped by real customer pain, from complex deployments to the growing pressure of managing modern environments without a team of specialists.

We also get into one of the biggest infrastructure talking points right now, the VMware shift. Tvrtko shares why many customers are not moving because they want to, but because they feel they have to, and how EuroNAS is helping reduce that friction with migration support, VM import tools, and a more predictable licensing model. It is a practical look at what organizations are really facing when they need a plan B but cannot afford disruption.

Another part of the conversation I found especially interesting was how recovery speed is becoming just as important as backup itself. Tvrtko explains how instant backup and recovery can change the experience from hours of downtime to seconds, whether that means restoring a full virtual machine or pulling back a single file. We also talk about simplifying Ceph deployments, reducing setup times from days to minutes, and why infrastructure teams increasingly need solutions that let them focus on applications and outcomes rather than wrestling with storage architecture.

If you are rethinking your virtualization strategy, looking for more predictable infrastructure costs, or trying to understand how to make enterprise storage less painful to manage, this episode is packed with useful insights. After listening, do you think the future of infrastructure belongs to platforms that hide complexity rather than expose it, and what would make you confident enough to make a switch? Share your thoughts.

What does “infrastructure” mean when your data stays exactly where it is, yet suddenly behaves like a graph?

I met Weimo Liu, CEO and co-founder of PuppyGraph, during an IT Press Tour presentation, and I wanted to bring his story to Infrastructure As A Conversation because this is a data infrastructure conversation at its core. Weimo’s pitch is simple to say and harder to pull off: keep a single copy of data in your lake or warehouse, skip the ETL pipelines, and still run graph queries with subsecond performance.

Weimo’s background explains why this is more than a clever demo. He worked at TigerGraph, then on Google’s F1 team, and PuppyGraph sits right between those worlds. In our conversation, he walks me through how they treat graph queries as a set of node and edge operations that can be optimized, parallelized, and evaluated in a vectorized way, which is how they keep performance predictable when workloads get real.

We also get into the practical details infrastructure teams care about. PuppyGraph is a read-only engine, which changes the trade-offs around concurrency, governance, and operational risk. Instead of copying data into a separate graph store and building a second set of controls, you can query relationships where the data already lives, then write results back into the lake for other engines to consume. The upside is simpler architecture and less duplication. The compromise is that you are not getting transactional graph updates, and Weimo is clear about why that is acceptable for the OLAP-style workloads his customers run.

From there, the use cases start to make sense fast. Cybersecurity teams with logs sitting in object storage, fraud detection scenarios where latency matters, and internal AI chatbots that struggle with too many tables and brittle SQL generation. Weimo has a sharp analogy for that last part, text-to-graph queries behave more like a train on rails, which can help AI stay inside defined relationships and reduce messy answers.

If you are building modern data platforms and you are tired of pipelines multiplying, this episode is a thought-provoking look at what happens when graph analytics becomes a query layer rather than a destination system. And it all started with a dog-themed name and a surprisingly cheap domain.