Salto Makes Infrastructure as Code for Salesforce

The promise of dealing with the complexity, popularity, and growth of Salesforce is driving interest in Salesforce Devops. This is because devops may be a way to better manage enterprise app production. But Salesforce is just the first of many SaaS systems which will benefit from advanced devops features such as metadata intelligence. Now, independent software vendor Salto (link) seeks to use metadata intelligence to accelerate app production by moving all SaaS configurations into a more code-centric world.

To power its platform, Tel Aviv-based Salto invented an open-source and human-readable application description language called NaCl. This declarative language seeks to create a vendor-independent way to store SaaS system configurations in code. Salto is available as a free and paid online service and via an open-source repository.

Infrastructure as Code for Salesforce

To understand how Salto is upgrading application delivery let us use devops software giant HashiCorp as a comparison. This company is the inventor of Terraform which was the original “Infrastructure as Code” service. Terraform helped to spark the initial growth of devops because it met a key delivery automation challenge, which was creating new virtual machines from hyperconverged infrastructure. The growth of Terraform, and other products, propelled HashiCorp to be a global sales leader in cloud native devops.

Before Terraform, engineers manually ran scripts or used a graphical interface to build virtual machines. By encoding these activities into text format, Terraform stored configurations as text in source code repositories. A command server like Jenkins then invoked Terraform in a script. This automatically built new virtual machines during a delivery activity. Additionally, the Terraform script was stored in a source code repository which audits changes in the script.

What HashiCorp did for automating virtual machines is what Salto wants to do for configuring SaaS business applications. Just like how the Terraform system describes, deploys, and audits virtual machines, Salto describes, deploys, and audits Salesforce, NetSuite,Workato, plus more system configurations.

Salesforce Needs a Translator

Salto says NaCl is needed because each SaaS system has a different way to express its configuration. The system has an architecture that uses connectors to synchronize metadata between the Salto cloud and each target system.

*This sample of NaCl shows a translation from hard-to-read XML*

This allows the system to deal with a key issue in Salesforce release management: XML. Without reciting a full litany of woes, allow me to say that XML is very hard for most Salesforce users to read. To fix this, Salto deals with Salesforce XML using metadata intelligence. The company automatically ingests XML and stores an org’s metadata in a graph database designed to generally describe business application systems. NaCl, which stands for “Not Another Configuration Language,” is a human-readable textual representation of that internal database. The system also lets you also ingest Workato, NetSuite, and other SaaS system configurations and express them as NaCl.

Salto Has Many Functions

Salto is a cloud native app that runs separate from Salesforce. It uses metadata intelligence to perform many functions that support Salesforce release management and devops activities. Here are some of the Salesforce devops functions in the system.

Git Integration – Salto integrates with GitHub and other git-compatible repository systems, which automatically audits NaCl changes.
Change Intelligence – The system performs impact analysis of a metadata element, showing architects where each metadata element is used in an org.
Deployment – Salto supports two-way communication between the Salto cloud and Salesforce for branch-based deployment scenarios.
Agile Integration – Salto reports changes in a Salesforce org by automatically creating a Jira work item.
Sandbox Management – Salto performs sandbox generation and can incorporate customized datasets used in Salesforce CPQ.
Environment Alignment – Salto groups multiple Salesforce orgs into workspaces which allows for comparison and joint management activities.

Salto supports examining an element for dependent relationships

Salto is a Cloud Native Tool

Using Salto requires architects to steer towards using cloud native systems in their devops processes. This is opposed to committing to the full stack offerings from the Top 5 Salesforce devops platform vendors. The separation comes into focus when one realizes a separate command server, such as Jenkins or Azure DevOps, is required to use Salto in a Salesforce devops continuous delivery process.

An Architect’s Dream?

From an industry perspective, Salto could be a devops tool for independent software vendors and system integrators who work on top of Salesforce. The dreamy part comes in when there is an application that works on Salesforce, but it needs to be ported to another platform. Or vice versa. With NaCl and Salto those kinds of migrations seem much more doable. And since the Salto repository is open source it makes it more accessible to the ISV and developer community.

For enterprise architects, Salto gives them ways to envision synchronizing metadata between related SaaS systems. This should be especially attractive concerning issues like shared lead, account and contact objects.

Salto Not Just for Multi-Cloud

Salto targets the enterprise architect who needs the multi-cloud, metadata magic of NaCl. However, there is plenty to admire for Salesforce devops shoppers. If you are looking to add metadata intelligence to your Salesforce devops pipeline without the bloat of a full platform, then Salto is worth a look.