Looking towards the setting sun, watching the tree line reflect in the pond backing onto our Florida home as the sun set, it seemed a good time as any to reflect on the year that’s past. There may be a few weeks remaining before 2025 officially ends and we have closed the books on business for the year and yet, as we look ahead to what might emerge as a highlight in 2026, there is one aspect I have seen growing from strength to strength among the Nonstop community and it has been resilience.
I love to fly, to take a plane and head out beyond the horizon. I observe, listening to snippets of conversations among my fellow passengers. I watch the customer experience be it the initial check-in, the movements through security, the inflight refreshments and the air of expectation when the flight ends and the passengers depart. When I say I like to fly, I have flown a lot to where the miles flown with multiple airlines has reached 4 million miles; 2.5M miles with just one airline. Spending a large part of my business life in Australia, accumulating so many miles, seemed normal. My biggest take away from my observations is that a good customer experience brings me back whereas a bad customer experience sees me moving on; changing allegiances.
For the Nonstop community, front-ending mission critical applications, it has always been about the customer experience. Their very presence serving in this capacity has been driven by the Nonstop’s unequalled levels of availability that in turn, underpins a level of resilience unmatched to date. When flying, for me it’s proven that planes are resilient. Likewise, with as many years flying as I have accumulated it’s just as easy to add, I too have become resilient. I have put up with almost everything that can possibly occur when going from point A to point B. But when it comes to our applications these days there are situations that are challenging our faith in even the most basic of computer services.
The fault tolerant architecture of Nonstop, highlighted by its process-pair support, has given Nonstop a head start. The presence of replication solutions has furthered this level of tolerance taking it from just a single system to where no single location can jeopardize the continuous functioning of the application. It may look simplistic but is powerful. Almost all Nonstop customers have worked through this at some point and have their back-up sites, on the ready, capable of taking on the workload at any point. However, now there are a lot of discussions around virtualization and the opportunity to deploy virtual Nonstop (vNS) – nothing can go wrong, can it?
But first, there have been two separate articles, featuring two very qualified individuals, that have caught my attention, as I was spending time reflecting on that tree line as the sun was setting. AWS is vey much in the news given its latest outage that impacted way more customers than could have been imagined only a short time ago. From major banks, to gamers, to the corner store – all systems down. Brent Ellis, principal analyst at Forrester, said the outage exposed what he called the “nested dependency” between popular digital platforms and the array of services providing the web’s technical underpinnings. “There’s great appeal to using tech giants,” said Ellis. “But assuming they are too big to fail or inherently resilient is a mistake.”
In a column that appeared in BBC publications, “Watch out for sharks: The bizarre history of Internet outages,” by Thomas Germain, he writes, “As our infrastructure becomes ever more tangled with the Internet, this won’t be the last catastrophic online outage either. The history of computing is littered with examples of our digital fragility and crashes of the past offer a glimpse of what it will feel like on the day the Internet turns off. He then quotes Ritesh Kotak, a cybersecurity and technology analyst, saying: “There’s a price to pay for convenience we enjoy.” When it comes to Internet outages, Kotak states, for instance, “It will happen again, from a technical standpoint, the fix for CrowdStrike was relatively easy. Next time, we might not be so lucky.”
In the Nonstop community we know all too well that we cannot rely on luck. We understand the price for convenience and we know all too well of the fragility of infrastructure. Thinking what we have created without Nonstop might still be resilient may be a stretch, too far. And then we have enterprises considering vNS with the objective of deploying it in a public cloud. Suddenly, the shadows of sunset look like they are turning ugly. Suddenly reflections aren’t at all as pleasant as we would like. Yes, everything can go wrong!
Yet, here we are at the close of 2025 with tools readily at hand to address vNS on public clouds. Naturally enough, our thoughts turn to the merits of deploying a disaster “site” on another vNS deployed on another cloud service provider. Copy primary on AWS, copy backup on Azure. Replication products should keep the two in sync and switching networks with the abundant infrastructure at hand should be child’s play to seasoned Nonstop personnel, right? How about we start to give serious thought to whether we can deconstruct Nonstop itself to provide even greater resilience?
What follows here is speculation on my part where there is nothing that I can point to suggesting programs already exist. Maybe it was the setting sun but then again, maybe not. It’s always good to kick around ides, right? But the thought never leaves me that the story of Nonstop is not over and that there are further contributions to be made. The resilience of Nonstop lies not just in what it is capable of doing today but in how it has successfully embraced change and adapted to technology tectonic shifts without putting Nonstop customers at risk, ever.
For some time now I have considered any hypervisor as a single point of failure so why not architect Nonstop to run process-pairs across services’ providers? A single image for Nonstop running some CPUs on AWS and others on Azure? Could we engineer our Nonstop implementation so take-over could occur between cloud service providers? Can we look past possible latency issues – would be nice to test this out somehow without taking on major changes to the Nonstop OS? As I reflected on the year, I kept coming back to this as the almost holy grail situation for Nonstop.
This will not happen overnight. I am not that deeply plugged into Nonstop development but it has me wondering – we cannot make Nonstop less resilient, less available, as we take it to the clouds. As new releases of Nonstop favor faster Ethernet over InfiniBand and even RoCE, that presence of an industry standard Ethernet connection configured to run at the max bandwidth, surely it is something we all should be contemplating – the very first fault-tolerant cloud deployment. Perhaps, over time, testing latency becomes a non-issue.
And with that, bring on 2026 and thanks for all the fun we shared in 2025.
Be the first to comment