Designing a Connected Application
When building a new application, picking the right deployment model is a key first step. A new model rising in popularity is the Connected Application. A connected application is an application that connects directly to the customer’s data platform to store and process data. This is in direct contrast to how most B2B SaaS “managed applications” operate today. While a typical SaaS app manages their own datastore for their customer’s data, and exposes APIs to update or retrieve that data, a connected application allows the customer to bring their own data platform to the SaaS app.
A connected application offers many benefits to both the SaaS provider and customer — this includes, but isn’t limited to, the following:
- Stronger Data Security — data stays in the customer’s data platform
- Single Source of Truth — no data silos
- Lower Cost — no data duplication and customer controls compute speed and scale
- Faster Customer Onboarding — customer data integration with an app is painless
- Extensible Results — app data is available alongside customer data for custom analytics
A connected app can potentially connect to multiple data platforms, but the Snowflake Data Cloud is the leading data platform for developing a connected application. To read more about the benefits of using the Data Cloud for Connected Apps, this ebook is a must-read.
Snowflake Deployment for Connected Apps
When implementing a connected app on the Snowflake Data Cloud, your application will be connecting to the customer’s account directly. At a bare minimum, this means you’ll need to have templated scripts to install a dedicated user, role, and warehouse for your application to hand to the customer to install. Depending on the app and use-cases, you will likely want to establish additional dedicated objects as well. See Implementing a Connected Application for an example of what this might look like.
Because the application will be connecting directly to the customer’s Snowflake account, this means that the primary Snowflake tenancy model for connected apps is an “Account Per Tenant” (APT) model*. Each customer will bring their Snowflake account to you in mostly one of two ways: direct account access, or dedicated account access.
Option 1 — Direct Account Access
In this model, the customer creates objects directly inside their main account using your install scripts. In the diagram above, the connected app has created a dedicated database, two dedicated warehouses, and a dedicated Snowpipe for streaming ingest (the dedicated user and role are assumed in the diagram).
Thus far, the Direct Account approach has been a common model for marketing technology providers when deploying a connected application. It’s easy to set up and manage, and the application can use the customer’s data from its source. Any data that the application produces also lives next to the source data, typically in a different Snowflake database. If necessary, you can optionally grant ownership of the application DB to the application’s role for schema changes.
Option 2 — Dedicated Account Access
With this model, the app still connects to a customer’s account, but it’s a separate Snowflake account in the customer’s organization that is dedicated to the application. This model has been popular with cybersecurity providers, mainly because it adds another layer of protection to the customer’s data — the app only gets the data shared to the account. This setup can also allow the app to read from the original account, and perform writes to the dedicated app account. Finally, the app would have more freedom to perform administrative actions on the account: re-sizing warehouses, creating new objects, and even creating new users.
If the app needs admin-level permissions, a dedicated account is the best option to go with. Otherwise, using direct account access with a dedicated database, user, role, and warehouse will suffice.
Front-End Application Tenancy for Connected Applications
While the app is connecting to the customer’s Snowflake account for the customer’s data, the front-end of the application (i.e. the user interface) will likely not be running on Snowflake — at least until Unistore is available**. Typically, the front-end application, or sometimes referred to as the “control plane”, will leverage a transactional database like Postgres or MySQL. It will manage application users, settings, and the authentication to the customer’s Snowflake account.
Multi-Tenant Front-End for Connected Applications
In many SaaS managed applications, a multi-tenant approach is used because the app is the same from customer to customer, with only different configuration settings and users. Connected apps can use this same model as well. The biggest difference here is that Snowflake is still deployed in a single-tenant manner, so customer data is never mixed inside the same datastore.
In this model, the app is easy to deploy and maintain, but your customers are trusting you with the Snowflake credentials to their account where other credentials are stored as well. Also, because the customer has the final say in scalability for operations in their Snowflake account, they’re trusting that your app will be able to keep up — this can be difficult for multi-tenant deployments.
If your customers include enterprise and/or security-conscious organizations, then you should be ready to deploy a single-tenant version of your connected app.
Single-Tenant Front-End for Connected Applications
For connected apps, a single-tenant model offers a few added benefits, namely better security, scalability, and availability. In this deployment, you’ll likely want to dedicate infrastructure in a dedicated VPC for each client that needs it.
While this model has its advantages, sometimes it’s still not secure enough to those who need total control over data security. A way to modify it would be to put portions, or all, of the application in the customer’s Cloud Service Provider. This type of setup could vary — it may be a single external stage (e.g. AWS S3) that’s owned by the customer and dedicated to the app, or it could be the entire application itself is hosted by the customer.
Like the other models mentioned above, there are trade-offs. While it might be more secure, the customer has more overhead to manage the application infrastructure. This type of single-tenant app brings in other considerations as well, particularly customer support and maintenance of the app.
While a provider might lose some control of their application as more sits on the customer’s side, the provider actually gains much more. When designed correctly, the connected app model typically fares better when reviewed by security and compliance teams. Because the customer’s Snowflake account is kept as the main datastore, the provider has fewer considerations when it comes to regulatory compliance laws like GDPR, CCPA, and HIPAA.
Hybrid Deployment and Tenancy
The last model is using a hybrid deployment and/or tenancy. “Hybrid” in this sense is a very broad term — they can include, but are not limited to:
- Separate single-tenant and multi-tenant components in one deployment
- Connected app deployment on a managed Snowflake Account
- A single product that supports both managed app and connected app deployments
For customers on Snowflake, using a connected app will likely be more beneficial; however, for customers not on Snowflake, or customers who lack the technical resources to run their own account, you might want to offer a managed application version of your product to limit code variance.
A hybrid model can be very enticing when much of the data processing for each customer is very similar or the exact same, especially when that processing happens in the provider’s Snowflake account or outside of Snowflake entirely. A popular method for existing Powered by Snowflake partners is to start with a fully-managed application, and then move/migrate customers to the connected app model when ready.
Your Connected App — Powered by Snowflake
For an in-depth detailed guide to data applications (managed, connected, or native), see Deployment and Tenancy Models for Data Applications by Kevin McGinley. You can also check out the Powered by Snowflake webinar series for further information. Lastly, when you decide to build your app, Snowflake suggests using Native Connector Best Practices (requires SPN login), especially when querying and loading data.
If you’re building a connected app, or are thinking about building a connected app, Snowflake is the best place to start. The Powered by Snowflake program is helping our customers and partners build data applications on top of Snowflake — apply online or reach out to your Snowflake Account Executive to get started.
Thanks to Anthony Alteirac, Kevin McGinley, Frank Pacione, Craig Schleicher, and Omer Singer for their contributions to this post.
- *The Account Per Tenant (APT) tenancy model is separate from the Object Per Tenant (OPT) and Multi-Tenant Table (MTT) models. A combination of the three are possible on hybrid deployments, but APT is the only model available for a pure Connected App. Please see the video mentioned in the summary above or this guide for more details.
- **If you’re going to be using Unistore for the front-end app, then you might want to look into building a Snowflake Native Application instead.
