Snowflake Native Apps — 3 Less Obvious Use Cases
Snowflake announced public preview of the Snowflake Native App Framework at Snowflake Summit 2023. The framework allows for providers to package both data and code — UDFs, Stored Procedures, etc — into a shareable package and list it on the Snowflake Marketplace where consumers can easily search, browse, and purchase these applications and easily install them in their own Snowflake account. This allows consumers to quickly find useful data and code that speeds up development, data acquisition, and data engineering tasks, as well as provides full application experiences via Streamlit integrated into Snowflake.
We have already seen a number of partners, as well as customers, who have built applications and listed them on the Snowflake Marketplace for use by other organizations — both free and for cost.
While this inter-organization use case is what we primarily focused on when building the Snowflake Native Apps Framework, there are a few interesting other use cases that are enabled. As is often the case with technology, there arise different use cases that leverage this new feature set that are not quite what the builder had in mind. These are perhaps less interesting, but do solve real customer challenges and are worthwhile, nonetheless.
In this post, I will share three less obvious use cases for building a Snowflake Native App:
- Augmenting a Connected app with in-database objects
- Enhancing shared data in Reader Accounts
- Sharing common/library code within an organization across multiple Snowflake accounts
Augmenting a Connected App
Connected Applications store data on customers’ own Snowflake account, rather than on the SaaS provider’s Snowflake account. They are called Connected Applications because the user-interface and processing layer run in the provider’s cloud service provider’s account, but they make a connection into the consumer’s Snowflake account to access the consumer data.
In contrast, in a Managed application, the SaaS provider manages the full stack in their own accounts, including storing their customers’ data in the provider’s Snowflake account. One luxury that the Managed application has is that the whole stack is owned by the provider, so there is no worry about putting intellectual property in any of the layers, since all of the systems are owned and managed by the provider.
For example, if there is some functionality that would be useful to leverage inside the database, such as a trained machine learning risk model or a custom propensity-to-by scoring function, in the Managed application that function can be encapsulated and pushed into the database. Then the processing layer can leverage that in-database function via SQL (or other Snowflake APIs).
However, in a Connected application, the provider cannot push that function to the Snowflake database without exposing the IP of that function, since the Snowflake database is owned by the consumer. This could have a negative impact on application performance as that functionality would need to reside in the processing layer instead.
However, with the Snowflake Native App Framework, the provider can encapsulate the custom functionality, in addition to any necessary reference data, into a native app. That native app can then be installed in the consumer’s Snowflake account. Now that the functionality is present in the consumer’s Snowflake account — securely, so the provider’s IP is not exposed — the provider’s processing layer can leverage this functionality via SQL (or other Snowflake APIs).
Moreover, since we are centrally managing the life-cycle of the data and function objects, we can push out new versions or patches to all the consumer accounts in order to keep the database objects up-to-date with the rest of the application.
Enhancing Reader Accounts
Snowflake has a feature called Reader Accounts, which enable providers to share data with consumers who are not already Snowflake customers, without requiring the consumers to become Snowflake customers. If a consumer is a Snowflake customer, data can be shared using secure data sharing, or even a Snowflake Native App.
In the case of a Reader Account, we may want to not just enable a consumer to access the data, say via JDBC or ODBC to integrate with a BI tool, but also build a data exploration experience for these users.
A common use case for Reader Accounts is to provide a separate account for each of our tenants (perhaps for an upcharge) that provides data access to the data only of that specific tenant. We can build this leveraging Snowflake’s Row Access Policies, among other approaches. The tenant would then be given access to this read-only Reader Account to analyze their data using the toolset of their choice.
In this scenario, we could use a Native App in the Reader Account to provide some additional functionality or user experience. For example, we could create a Streamlit app in our Native App that shows some basic information about the tenant’s data. This could be a way to onboard new analysts and explain the details of the data and provide context to get them started faster. Essentially, any useful capability that goes along with the data could be shared to the Reader Account.
Again, since the Native App is being centrally managed and installed in each Reader Account, we can quite easily push new versions and patches to all Reader Accounts from the central provider Snowflake account.
One thing to note is that there are constraints in a Reader Account that restrict users from modifying data — it’s a read-only account. As such, the Native App would need to also not modify data. In many cases, that restriction may be acceptable, but some use cases might have trouble.
Sharing Common Code within an Organization
Some organizations have multiple Snowflake accounts internally. There are a variety of reasons from regulatory to organizational. Regardless of the reason, it is often the case that the organization has some common code — stored procedures, UDFs, etc — and perhaps also some common data that is useful in each of their Snowflake accounts.
For example, there could be a process for how new users are created and what additional Snowflake objects (e.g., their own database, their own warehouse, their own role, etc) and permissions (e.g., being added to certain roles) are created when onboarding those users. It is important to make sure that there is consistency across the various Snowflake accounts in the organization.
Alternatively, there could be some critical business logic that is important to roll out to all Snowflake accounts, in order to have consistent logic in those environments. This could include data in addition to code.
And the variety of use cases goes on…
In all of these cases, we want to make sure the code and data in each Snowflake account is kept in sync. If there is a bug, we want the patch to go to all Snowflake accounts. If there is a new feature or a new version of the logic or data, we want that to roll out to all accounts, as well.
Snowflake Native Apps can be shared publicly, but they can also be listed privately. In this case, the Native App would be only shared internally to the organization (aside: this actually simplifies the development and deployment steps for these internal Native Apps). In this way, a new version of the data or code can be easily rolled out across the organization. The accounts can be kept up-to-date with the latest bug-fixes, as well.
While this does not sound like the primary reason we built the Native App Framework, it certainly helps address a major administrative pain point that we see customers deal with today.
Conclusion
The Snowflake Native App framework is a powerful tool designed to empower Snowflake customers to safely import provider data and functionality into their own environments. This greatly improved time-to-market and simplifies the full life cycle of data applications. Additionally, it provides a unique opportunity for providers to monetize their intellectual property in a safe way.
However, this new tool has a number of other, less obvious, use cases that were not the primary reason we built it. Nonetheless, the tool exists and helps with some interesting and important use cases. The three scenarios listed here are clearly not an exhaustive list. Snowflake customers have a habit of being extremely clever in the use of the toolsets we build, and there’s no reason not to be creative with this new and powerful tool, too.
