Stelo recently released Stelo Data Replicator V6.1. Similar to past versions, V6.1 offers robust, real-time data replication but with additional features to further support the evolution of data management strategy. Over our 30-year history, we’ve developed best practices for moving information that still guide us today.
In part two of a three-part blog series, we’ll break down more new features in V6.1. For a breakdown of Stelo’s high-performance support for non-SQL destinations in V6.1, read part one.
Here, we’ll cover PowerShell scripting, support for Linux, and container-based deployment.
In summary, Stelo added the following features between V5 and V6.1:
- PowerShell scripting extends the capabilities of Stelo Data Replicator by providing more granular programmatic control of replication tasks for those looking to manage the replication process using workflow tools.
- Support for Linux and container-based deployment allow Stelo to be delivered as an appliance in under fifteen minutes and encourages the use of open-standard architectures for scaling server applications.
Each of these features is designed to facilitate a responsive data pipeline architecture. So, how do they keep your options open?
Schema changes can be managed and directed with PowerShell scripting.
The value of PowerShell scripting starts with understanding why a business might be looking to manage replication using workflow tools in the first place. Application developers account for the replication of data in the software production lifecycle, so when they make a change, it’s reflected in the pipeline and any subsequent destinations.
A simple example is scaling from tracking zip codes in a five-digit format to a nine-digit format. Instead of storing five characters of data, the task is to store nine. (Ten if you count a space character.) This change could be handled a couple of different ways; the database that’s storing the information could be inflated to store more data or the applications that are acquiring the data could be made aware that there’s more data to make available. The structure of that information is referred to as data schema. That schema is a meta-term for describing the data and any changes (e.g., character count changes).
It's best practice to have pipelines deliver changes in schema to downstream consumers of information. This should be approached in a coordinated manner such that schema changes are communicated before data starts arriving in a new format.
Stelo Data Replicator does detect schema changes, and it will dynamically deliver them downstream as needed. Some organizations prefer to take it a step further and engineer when those changes occur by programmatically telling the pipeline that those changes are coming. That said, it can be more convenient for those organizations to use workflow tools that are managing their existing software development processes rather than Stelo’s graphical user interface (GUI). Even so, they need a programmatic interface for the Stelo appliance to communicate changes.
PowerShell scripting is a way of communicating to V6.1. Now, organizations can drive change data process, capture, and delivery programmatically instead of having to use Stelo’s GUI. This extension is helpful for a variety of business cases. Large, complex organizations leverage PowerShell scripting as they migrate systems and develop new business practices while maintaining day-to-day operations. Smaller companies use the extension for customized reports. As a business, Stelo relies on PowerShell scripting in our development practices. Every time we make a change to our software, we’re able to run thousands of automatic tests.
Deployment is faster and increasingly scalable with container-based deployment.
In V5, it took one to two hours to deploy Stelo Data Replicator. With containers, deployment takes less than fifteen minutes. That speed is a standalone benefit, but this deployment strategy also lays the groundwork for a future where containers are a much more accepted technology. Some organizations are opting for Linux servers, which readily support containers. A basic server structure with the right container is a Stelo Data Replicator appliance. Down the road, this deployment method presents an opportunity for customers to run Stelo Data Replicator at a lower cost.
Access on-prem servers (without being on-prem) with support for Linux.
The cost of running open-source Linux servers is significantly lower than other conventional options. However, beyond the savings potential, Linux is well-suited for scaling.
The shift to container-based deployment was accompanied by a change in Stelo’s GUI that allows organizations to decouple from the environment where their software is running. While Stelo Data Replicator’s GUI still runs on Windows, with Stelo Apply, individuals can communicate with an Amazon Web Services (AWS) server without having to log in at the same physical location. In other words, organizations can readily communicate across a network. This GUI change also enabled role-based authentication control (RBAC), another feature added in V6.1.
At Stelo, we believe that scalable technologies are central to solving immediate business challenges and maintaining flexibility over time. V6.1 integrates features with staying power to support data management from here on out.
Contact us to request a V6.1 demo. For more information on V6.1 features, check out Part 1 of our Unboxing Stelo V6.1 series.