Xyna Shared Resource Management
Xyna Bulletin #30
Dear Friends, Partners, and Customers of Xyna,
Today, we would like to turn our attention to an operations-focused topic—ensuring that the technically inclined readers of this bulletin remain both curious and engaged: the new Xyna Shared Resource Management (Xyna SRM).
In a nutshell: it is a mechanism designed to ensure the consistency of system and infrastructure resources within a distributed "cloud-native" scenario. That is, an operational setup where the system load is distributed across loosely coupled nodes (containers, worker nodes) that operate independently of one another, yet still require a central mechanism to cooperatively manage capacities, vetoes, and IDs.
Before we dive in, a quick heads-up regarding the upcoming TM Forum dtw Ignite! conference in Copenhagen, taking place from June 23rd to 25th.
This year, we will be represented by an exhibition booth (Booth 323), a Catalyst project (URN C26.0.921, Kiosk i2.8), and an Industry Showcase (TMF Stage). And, of course, by a friendly and knowledgeable team on-site. More on this in the next bulletin.
Happy reading!
::
Xyna Shared Resource Management (Xyna SRM)
Starting point: „The Migration Shift“ / Moving from VMware to Kubernetes
For many years, VMware—with its vSphere platform and ESXi hypervisor—was virtually the de facto standard for virtualization. At the very least, 90% of our projects ran on a VMware setup—and did so very successfully, for from a sober operational perspective, there is really nothing to be said against virtualization using VMs.
However, the world has now decided—for reasons that are likewise entirely understandable—to embrace "cloud-native" infrastructures. This typically refers to container-based architectures (often Docker) that are managed and operated via orchestration platforms such as Kubernetes or OpenShift. This shift is driven by commercial factors (notably Broadcom and licensing models), but also by technical considerations—such as kernel sharing, scalability, resource efficiency, and faster startup times.
Why are we telling this?
Xyna-based applications frequently serve as critical OSS systems, entailing corresponding requirements regarding availability and load distribution via horizontal scalability. For the VM era, Xyna offered various "Cluster Providers" (RMI, Oracle RAC, XSOR) to facilitate the implementation of cluster architectures (High Availability, Shared Nothing, etc.).
While fundamentally highly performant, these Cluster Providers rely on the cluster layout—specifically the number of nodes and their assigned tasks—being known in advance. They constitute essentially static configurations—an approach that is both enabled and logically supported by the VM paradigm.
Challenge: Distributed Resources in Cloud-Native Environments
In a cloud-native scenario, this "VM static nature" is now lost—or rather, replaced by "container flexibility": the orchestrator (Kubernetes) aims to flexibly scale the number of containers (worker nodes) based on load or other operational factors (e.g., resource allocation):
To begin with, that is a great thing. And if the tasks to be distributed across the containers can be structured and separated, managing them via an orchestrator is, as a rule, quite feasible. However, there is also application-specific information that is unique across the entire cluster—or limited in quantity—or that requires unique numbering. For Xyna, this specifically includes vetoes, capacities, and IDs.
A quick reminder for those who, unfortunately, do not get to work with Xyna on a daily basis: Vetoes and capacities are used for concurrency control within the Xyna Scheduler. Vetoes, for instance, can be used to prevent two orders from being executed simultaneously on a single endpoint device. Capacities, on the other hand, allow you to limit the number of concurrently running orders—for example, to protect target objects with capacity constraints, or APIs, from overload situations. IDs, in turn, serve various purposes—such as uniquely identifying specific order instances (Order IDs).
And this is exactly where Xyna Shared Resource Management comes into play.
Xyna SRM - Consistency in Elastic Environments
For Xyna SRM, several new Xyna components have been developed, which essentially run on the Xyna Nodes (containers). They ensure that, for every usage of vetoes, capacities, and IDs, a query is performed against a central database.
This central database can be any SQL database—for instance, one running as a cloud service or, likewise, as a container within the Kubernetes environment. However, in contrast to the ephemeral worker nodes, the following principle applies here: this database service must be configured to ensure its availability whenever at least one Xyna Node requires it to be operational. If the node is required to be continuously available, a 2+1 HAaaS configuration, for example, is a suitable choice.
The operational mechanism of Xyna SRM can be summarized simply as follows: whenever a Xyna Node initiates an activity that utilizes IDs, vetoes, or capacities, it consults the central database. Robust algorithms ensure that no inconsistencies arise—even under conditions of high system load, the dynamic addition or removal of containers, or communication failures.
And what does all this accomplish?
And why do you even need it in the first place?
Well—anyone who has ever grappled with the challenges of parallel computing will realize that the coordinated and cooperative use of central information objects across distributed nodes is no simple feat. And that’s before we even start talking about true coherence.
Yet Xyna SRM is not merely another cluster provider; rather, it is a completely new, standalone capability designed for the distribution and synchronization of resources across loosely coupled containers.
Xyna SRM enables:
- Cloud-native setups for Xyna-based applications
- Dynamic scaling of Xyna nodes within an orchestrator
- Scenarios such as "scale-to-zero" or FaaS serverless computing
- High application availability through JIT provisioning
Pretty cool. And pretty powerful. It does, however, require—for nothing comes without a cost—that any application seeking to utilize Xyna SRM be appropriately prepared in terms of its process logic for order processing.
If you would like to discuss this further with us, we would be happy to do so. Get in touch!