SREday Barcelona had no shortage of strong technical talks, picking one to write about wasn't easy. The one that stuck with me longest was David Jacovkis' talk on what DevOps looks like when your infrastructure is, literally, in space: intermittent connectivity, long feedback loops, and systems you can't just SSH into when something breaks. It would have been an interesting talk on its own merits. What made it stick was how directly it mapped onto something I deal with every day, building on-prem cybersecurity products for environments I don't fully control either.
Hidden assumption in modern development
A lot of modern applications are built around a simple assumption: the system is reachable, observable, and controllable. In practice, that is not always true. Problems which David talked about are not abstract.
They show up pretty often when systems are hard to reach, access is restricted or completely impossible. We cannot always assume everywhere „normal cloud setup”. In enterprise on-prem deployments, especially in highly regulated environments like Banking, Financial Services, Public Sector/Governance and Healthcare, many of the same assumptions also break down.
In these cases the whole infrastructure layer fully belongs to the customer. Outbound access is highly restricted. Network traffic might sit behind proxies, even multiple ones, there are a lot of security policies or network rules you do not control. And sometimes, when you need to apply an update or something breaks - there is no easy way to log in and fix it directly.
That means during development, we need to rethink our operational model a little bit. We need to assume that configuration in the customer environment is „part of the problem”. As a DevOps you need to slightly expand your thinking from "How to deploy this application and provide updates as quickly as possible?" to "How do we deploy applications in the customer environment while maintaining maximum reliability?"
Rethinking operational assumptions
In David’s talk, not only the scale and uniqueness of his environment was especially interesting, but also how many common assumptions during development start to behave differently once access and connectivity are limited or not guaranteed at all.
We cannot assume that full access to systems and troubleshooting will be always available. In restricted and regulated environments, those capabilities usually require much more forward-thinking design.
The whole challenge is not simply how to collect logs or expose common metrics to popular observability tools, but designing systems that remain fully diagnosable, supportable and recoverable even when direct operational access is limited. That shift in mindset is pretty familiar to me working with on-prem cybersecurity applications setups.
Design for reliability, not just deployment
In restricted environments the main goal should not be making deployment work. Your systems need to be properly designed to be easy to operate once they are already running. You need to figure out clear and predictable validations steps, meaningful health check signals, stable recovery paths and just enough diagnostics to provide support for any issue without directly accessing everything underneath. These kinds of systems require thinking beyond standard DevOps practices. You need to start designing for reliability and operability from day one, not just focusing on install and update flow. That does not mean that such environments are impossible to manage, they are just more challenging. You need deliberate and mature processes to understand quickly what happens when something does not go as planned and how to act to fix it quickly.
Why this felt familiar at Holm Security
At Holm Security, we develop a feature-rich and highly configurable on-prem platform that has to run reliably across very different customer environments. Each customer environment is unique with its own network topology, security policies, processes, network traffic and access restrictions and infrastructure expectations.
All these circumstances change the standard approach and best infrastructure management and platform design practices. The systems we create must be predictable in many aspects under various conditions. Simply delivering required features on time is not enough. We must assume from the outset that the environment in which we will deploy our applications will be far from ideal from a developer's perspective. The challenge is not only building features, but making sure the platform remains observable, supportable, and operationally predictable.
Over time, that shifts the engineering focus and assumptions much closer toward resilience, diagnostics, validation, and operational clarity.
While the environments discussed in David’s talk differed significantly on the surface, many of the underlying engineering principles felt remarkably familiar.
Closing thoughts
David's talk has stayed with me since the conference because it was never really about space. It was about a bigger question: how do you design, diagnose, and recover systems you don't fully control? Once you frame it that way, the gap between "a satellite you can't reach" and "a customer's on-prem environment behind three layers of proxies" gets a lot smaller.
Thanks to the organizers and speakers for keeping the conference genuinely technical and focused on real engineering problems instead of buzzwords. I'm leaving with a few new tools to try, and a few old assumptions I'm glad got challenged.
