Today, we’re thrilled to announce our latest product development. Meet Starlarky!
What is Starlarky?
Starlarky, for those of you who think it rings a bell, is VGS’ in-house version of Bazel’s hermetically-sealed language, Starlark, created by Google. Developers can use the language to run user-submitted code without exposing underlying services and applications to potential attacks and/or vulnerabilities. Better yet, the language is deterministic, meaning it will always come to a halt. Starlark (and Starlarky) have Python-like syntax and support the same structure of additional libraries. If you’re interested in the main differences between Starlark and Python, here is a quick breakdown.
Now on to Starlarky. Starlarky consists of several components built on top of Starlark in order to provide VGS-specific functionality. Most notably, Starlarky contains Larky, a maven module that contains VGS additions to the Starlark language. Larky is exposed to customers as a secure serverless function within VGS execution environments to enable our customers to enhance and transform their data. It’s worth noting, Larky maintains backwards compatibility with select Python libraries, allowing customers to develop functionality using a Python runtime and easily translate to Larky to run within their VGS environment. This gives our customers unparalleled tooling support for local development, while providing a uniquely secure runtime environment once deployed. Here’s an example:
Why Should Customers Care About Starlarky?
The Starlarky language allows VGS customers to not only secure data, but also enhance and transform their sensitive data, without ever being exposed to it. A common misconception around VGS is that a customer may need to hold their data in order to run analyses or to transform it. While customers can indeed perform analyses on VGS aliases, Starlarky makes it easier than ever for developers to run models and transform their data without ever being exposed to it or removing it from their secure VGS vaults.
Let’s take a practical example. Imagine you’re an eCommerce merchant wanting to gain more insight into and optimize the card portfolios that are prominent amongst your customer base. You can now scan for BINs (first 6 digits of a card number that identify the issuing bank + card type) within your card-on-file base to:
- determine a BIN’s frequency
- find average ticket size for each BIN
- route payments to specific processors based on BINs for lower routing fees
- and more all without ever being exposed to cardholder data.
Good News: If You’re a VGS Customer, Starlarky is Available to You Today!
We’re already encouraged by the creativity of our earliest adopters and can’t wait to see how our customers use Starlarky to their advantage in the future. If you’re interested in learning more and want to take it for a spin, check out our API docs, integration guides, and support forum!
