This past weekend I seated myself close to the television through much of The Rolex24 at Daytona. Much like other races that span 24 hours, for as long as I can recall it was considered an endurance race, much the same as the 24 Hours of Le Mans, and yet with the improved reliability of the participating vehicles, Daytona is now very much a 24 hour sprint race. Mixing prototypes with vehicles you could drive off the showroom floor sort of, these long races make for entertaining viewing.
While we have a connection with one of the racers
involved, the Indy Car phenom Colton Herta, the grandson of our good friends, the
Kennys, who just happened to add yet another Rolex to his collection of Rolex
Daytona watches after winning the Le Mans Prototype 2 (LMP2) class and placed fifth
overall (car pictured above), all the same I was surprised at how quickly those
24 hours passed. I remember conversations with my father after listening to Le
Mans the time disk brakes first appeared (on a Jaguar) and contemplating how
difficult it would be to stay awake for the duration and yet, here it is just a
few days later and realization that today’s technology advancements have meant
cars could run flat out the whole time.
Of course, advances in technology don’t just apply to
motor vehicles.
The world may be talking non-stop about the rate of
acceptance of electric vehicles even as Elon Musk is on his way to becoming the
world’s first trillionaire, but let’s not forget what is happening with the
technology powering much of this very same world’s infrastructure. 24 hours may prove tiring for athletes but
for the rest of us going about our daily routines, we live 24 hours seven days
a week. Perhaps not all at once but as occasions dictate, there is always the
potential that, at the top of any given hour, you may find us hard at work, a
circumstance perhaps driven by the global pandemic but all the same, a
circumstance that demands the presence of technology infrastructure being
available whenever the need strikes us.
For the NonStop community this is the bread and butter
of our existence. The very substance that fuels our enthusiasm for the products
with which we work 24 hours a day! I was reminded of this only a short time ago
when I was asked by my friend about the reason I continue to promote NonStop
and my response was rather simple. Approaching its fifth decade meeting the
mission critical requirements of the biggest enterprises on the planet, nothing
better has come along. Mainframes remain general purpose in the roles they
fulfil while a variety of servers support apps and databases at bargain
basement prices. But NonStop brings a level of availability to a comprehensive
mix of hardware and supporting software stack unlike anything else on offer
today.
Reliability as I reminded my friend isn’t simply
throwing redundancy at the problem.
Building out a server farm with the cheapest possible
components and then letting multiple copies of the software mask outages isn’t
a winning strategy when it comes to mission critical applications. There is a
reason why the biggest enterprises are proving reticent to move everything to
the cloud. The cloud experience holds considerable attraction but it’s the
experience that is important, not the cloud. Expressed as simply as I can, the
cloud is just a service bureau and can even be viewed as a time sharing service
offering revisited.
Our business mindset is always driving the need to find
a cheaper solution, a solution that demands few human resources, a solution too
that is not just portable but can be supported by a variety of suppliers in
hybrid combinations that presumably give their advocates better leverage over
pricing when upgrades are called for. But in this open world of disconnected
APIs, have you noticed how proprietary solutions are returning? AWS is no Azure as Azure is no iCloud: if you
want to span multiple clouds you need to architect the application with its
required infrastructure ahead of time and even as you do, you need to be
conscious that the world of data, apps and APIs is constantly in a state of
flux.
Should you even consider having your backup of your AWS
apps on Azure just in case disaster strikes and your AWS cloud goes offline?
Should you standardize on just a common subset of APIs?
Where NonStop comes to the fore is that as a software
offering running on virtual machines with the traditional levels of
availability on hand, the time is coming when you can leverage that 24 hours of
availability on even the most fragile of deployments. All day, every day. It’s
not a cliché or a generalization that the more we connect the more we demand
and there is no greater demand than having whatever is at the end of the line
being always there for us. For the enterprise that adage of the next site is
only a click away doesn’t apply as that click won’t take you to your app if it
doesn’t reside on that resource.
Back to the questions I was responding to: It became
an easy transition to cover the topic of incremental change, of taking baby
steps.
The jump to a fault tolerant infrastructure spanning
today’s hybrid world isn’t something any of us would contemplate doing over a
weekend. The NonStop world is one that moves at a judicious pace testing and
testing with every baby step that is taken. Given this and how experience has
been gained through the years about splitting processing across systems located
remotely and where business continuity has led to greater business integration,
perhaps the first step is to provide the mandatory two network paths between a
traditional NonStop server and NonStop running on a virtual machine in a
collocated x86 server farm.
Following success with this first step it would be easy
to see the next step being connecting to servers hosted off site in a
colocation (colo) facility where a level of oversight is retained. Only then
with an understanding of all operational aspects of NonStop configured in this
manner could the move to a partial cloud service offering be considered, with a
level of caution in measure with that experience already gained. There are many
cool aspects to moving some functions to the cloud, among them the opportunity
to tap into analytics and AI/ML that otherwise would be out of reach to a
NonStop application but now just a few electron paths away from our NonStop
configuration in the cloud.
There will always be a demand to run application 24
hours a day. That’s a testament to how we live just as it is background
commentary on how quickly 24 hours passes us by!
The challenges other vendors face in attempting to
provide such infrastructure are daunting and throwing hardware at the problem
isn’t the answer for the most critical of our mission critical applications. At
a time when it was a challenge to simply run any application for 24 hours uninterrupted,
to where today for the NonStop community it is indelibly part of what we do,
should be encouragement enough to take NonStop into the new world of the cloud
experience.
In any of the 24 hour car race there is no time set
aside to do maintenance or to add new capabilities. Any such move which out of
necessity may happen more often than not means you lose the race. Yes, while
racing you can pull in for fuel, change tires and perhaps a driver change but
you are never out of the race. You keep on going. That car’s engine keeps
turning over without ever coming to a stop. And from where we sit we can see
Colton continuing to perform at a level whereby he adds even more to his
collection of trophies. And watches.
Comments