EPISODE 1664

[EPISODE]

[0:00:00] ANNOUNCER: Snowflake is one of the most prominent platforms for interacting with data and building data-intensive applications. Dan Myers works in developer relations at Snowflake, and he joins the show to talk about the future of application development, and building native data apps on the platform.

This episode of software engineering daily is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[INTERVIEW]

[0:00:37] SF: Dan, welcome to the show.

[0:00:40] DM: I'm glad to be here and thanks for inviting me.

[0:00:42] SF: Yes. Thanks so much for being here. So, you were Snowflake's first-ever developer advocate hire, I believe. Now, you lead a team of advocates there. How did you end up at Snowflake and what piqued your interest in the data space?

[0:00:53] DM: Yes. Great question. Snowflake lives in this area where applications and data really meet. What really excited me about Snowflake is, Snowflake today is becoming the platform for data-intensive applications. Being part of that and helping to define that journey really excited me. You see this historically in the features that Snowflake has been releasing from day one. The bread and butter of Snowflake has been being a data warehouse in the cloud. But with new features, like Snowpark Container Services, Snowflake Native Applications, you see more and more, where the compute is being brought closer to where the data resides. There's a lot of reasons for that. But Snowflake in particular, is well-situated for that move. So, that's really what sparked my interest, is Snowflake becoming the platform for developers to build data-intensive applications.

[0:02:06] SF: Yes. That's really what interests me in having this conversation today, is sort of this marriage between data and applications. If you look at the history of Snowflake, Snowflake does a ton of things. It's like way more than we could possibly cover. But a while back, I talked to Bob Muglia, the former CEO of Snowflake, and he went into a lot of detail about how Snowflake took this cloud-first approach to revolutionizing the way that we store query processed data, the separation between compute and storage, something that couldn't even exist in a non-cloud era back in the on-prem world. That foundation led to, I think, the growth and adoption of Snowflake. But Snowflake has made recently, in the last few years, is like very strategic investments in becoming more of like a place for data-intensive applications to live. Why do you think that investment makes sense? Why invest in things like Snowpark Containerization Service and Native Apps and some of the other things that we'll probably get into the details on?

[0:03:05] DM: Yes. I mean, the biggest reason to invest that area, is because that's ultimately where a lot of data users will continue to consume their data. So, when you think about how is the value of data derived? Well, it's derived by the analysis and taking actionable outcomes from your data, right? 

So, Snowflake is the place where data is hosted and it's been where you can also analyze and you can kind of create all sorts of analytical outcomes from your data. But apps, is really where now you can start to build upon that foundation. You see with Native Apps and Snowpark Container Services in particular, now, you are creating this, not just a visualization, but whole organizational processes around your data. I like to tell people all the time that, where I think application development is going, is a data-first development approach, where your data is really what you are ideating around, and is ultimately the foundational piece of different apps talking to each other, is the data that's being passed. So, how do you build applications that are tested, well tested in that area, and are resilient to data changes, or moving between different applications? That's, in my opinion, really, a big reason why you invest in this area is, that's where a lot of growth is, and that's where a lot of consumption is.

[0:04:42] SF: By making Snowflake more of a place where people are building applications, does that change the type of user that historically has used Snowflake? Perhaps in the past, the typical user was more a data engineer, an analyst, maybe a data scientist, are primarily working in SQL as an analyst. Maybe Python as a data scientist or something like that. Then, suddenly you're building actual data applications that maybe other people in your company are going to use. Does that shift the type of person, the type of builder that is actually using Snowflake?

[0:05:13] DM: Absolutely. Absolutely. I think you hit the nail on the head there, where, by building applications that really revolve around your data, the user of that application can be very different from a data analyst or data engineer, right? It can truly be a business user, or somebody that doesn't know how that application is implemented. They're not the ones building the app. But they're the ones using the application to do something else with the data.

So, it absolutely shifts who the users are, or I should say, it doesn't just shift, it expands the users that use Snowflake. One of the things that, I'm sure, that we'll probably continue to talk about a little bit more is kind of the paradigm shift in terms of how a new Snowflake native app is architected differently than a traditional SaaS application. By the fact that it's hosted inside of Snowflake, and because of that, it ensures that the data doesn't leave that snowflake account.

I really attribute it to a similar model as almost like a mobile phone application install. So, you have your App Store on your phone, you have an app store on Snowflake, just like you install apps on your phone, you can install applications that run entirely inside of your own Snowflake account. The difference is that those installable Snowflake applications, Snowflake Native Apps, are using data that is inside of your Snowflake account only by default. So, that's a big win for highly regulated environments, or really anybody that wants to maintain true ownership of their data. That's a really important aspect of Snowflake Native Apps in particular.

[0:06:51] SF: Yes. So, with the concept of the native app, if you didn't have something like that, where you're able to essentially build these types of applications, run them directly within my computer environment on Snowflake against data that I own. How were people sort of solving that problem historically? What was that process to build something that basically address the issue for a company, but didn't pre the existence of something like the native app framework?

[0:07:17] DM: Yes, it's great a question. Historically, what it's been is, essentially, you're connecting to the platform like Snowflake. So, you build a traditional SaaS application hosted on AWS, GCP, Azure, and you're literally connecting to your customer's data, through a reader account, or essentially, that your customer will give you credentials of some kind, that are locked down to maybe read-only, or access to specific parts of your data. And it's taking data out doing, something with that data, and then potentially putting that data back right into Snowflake, for example.

There's a lot of problems with that model. One, being that sure you might have contract saying that, "Hey, these are the only things that I'm going to do with your data when I take it out." But if you host the application inside of Snowflake, you have a programmatic guarantee that data isn't leaving. It's a different kind of world there. But another difference is just performance, right? So, there's a lot of ingress and egress cost associated with taking data out or putting it back in, just that network latency and things like that, that really add up over time. So, with Native Apps, you run that inside of a hosted environment inside of Snowflake and Snowpark Container Services then takes that really to the next level, where anything that runs in a container can run inside Snowflake now. That's really where I see a lot of the future of data-intensive applications being built, is in a model like this, where it's installed and runs where the customer's data already resides.

[0:08:54] SF: Okay. So, I definitely want to get in the details of how like some of the stuff technically works. But maybe before we get there, I think, it would help set context, what is it like an example of like a data-intensive application that would make sense to exist as a native app?

[0:09:08] DM: Yes. One would be, for example, maybe it's an application log analysis, where it's doing some type of real-time or fast-acting analysis of logs, as they're being generated to surface important anomalies that should be addressed by your dev team. Something like that. If it's always being ingested into something like Snowflake and your app is hosted outside of Snowflake, you're essentially querying and taking data out of Snowflake. There's a lot of - there can be latency there. There can be egress costs and stuff like that. If that entire application is hosted inside Snowflake. That's a lot more performance and things like that for a use case like that.

So, it's something where the app is reading data that scale and doing something with that data. Another really good example that I see a lot is like this sentiment analysis using LLMs. So, maybe you have a huge, huge repository, or a collection of user reviews for your product, and you want to get a better understanding of, "Hey, is the general sentiment positive or negative across all of these?" So, you individually rank the sentiment across every single comment that LLM can run entirely inside of Snowflake, Snowpark Container Services, and you can write a query that determines the sentiment of every comment inside Snowflake, that can run entirely inside of the Snowflake-hosted environment.

[0:10:34] SF: Yeah, I talked to a business not too long ago, where one of their big problems was, they were like sitting essentially on a mountain of data that is basically just stored, encrypted in like cold storage, and they have no way to sort of activate it. They know that there's like good value in it, but they have no way of essentially activating that value and giving people access to it. Because one is, there's regulated data in there, so that data governance and sort of access control becomes a problem. Then, also, there's a lot of essentially unstructured data that they don't know how to, like turn into something that a product team could actually consume. So, some of the things that we're considering is like, how can we bring that data to an LLM, to pull out some of those insights, and so forth.

It sounds like, that's kind of a great scenario for building something on top of Snowflake with this other, the containerization service, or even building their own native application, because essentially, they can keep all the data within their own environment in Snowflake. They can control access to it. Then, also, they can sort of pair this with some of the things that are existing in Snowflake now to support LLMs, actually pull out, dry some of these insights, give the right amount of information to their product team to deliver more ROI to the business actually, activate or drive insights from some of this data that you're sitting on.

[0:11:51] DM: Exactly right. 

[0:11:52] SF: In terms of the native app, like architecture, can you kind of break that down? What are the components of actually making the native app service like something that's real?

[0:12:02] DM: Yes, so there's a couple of ways to do it. Namely, what most people will be familiar with are Native Apps that can be installed via the Snowflake marketplace. In order to get your app listed on the marketplace, you create an app package. What is an app package? What is an app package? It's basically a, think of it almost like a .msi file, for example, on Windows, right? It's the installer. It kind of packages together, whatever necessary data that might be included in your app, some UDFs, user-defined functions. These are some various functions that your app will execute. You can even expose some of those functions to users of your app.

But ultimately, it's packaged together on Snowflake and listed on the marketplace. So, when you look at what's all included in that app package, there's going to be - if you really want to get into the weeds, there's going to be a manifest file that really defines all the metadata that's associated with your app. So, that could include what version it is, what necessary artifacts it's going to be looking for, and need access to? So, for example, if your application is expecting a table of user comments, for example. You're writing that native app that does sentiment analysis on comments.

One of those artifacts might be a table asking for, "Hey, it needs a table with these set of columns and column types. And this is going to be the collection of user comments and I'm doing sentiment analysis on." It will actually prompt the user when you run that native app, where should I reference this table from, right? Do you grant read access to that table by this native application?

So, that's part of it. You also can write your native application and a variety of languages through UDFs. What is a UDF? It's a user-defined function in Snowflake and we support a few different languages directly as a UDF. Python being one of the most popular, and so you can write these Python functions that run in a secure environment. We actually utilize Anaconda for package management. So, there's a huge number of different packages out of the box that you can leverage in your Python UDFs, for example, and then expose those, all of that in your native app.

But really, the goal for a native app is to have a packaged element of functionality. You can push that to the marketplace for others to install. Let's say you're in a large organization that, "Hey, I'm really building this native app for other users in my organization. This isn't meant to be published on a marketplace and sold." That's also possible. You can create a native application and actually, you can install it and then share that application with other users inside your own Snowflake organization. So, there's a lot of different ways that you can leverage Native Apps today. The real kind of theme here is you're packaging together some functionality, in kind of a Snowflake object, that you can then share with other people.

[0:15:13] SF: If I'm building a native app on Python, and I'm using the Anaconda package manager, what if I need a package that exists outside of Anaconda? Is there a way to do that?

[0:15:22] DM: Absolutely. So, the easiest way to do that is leveraging our Snowflake CLI. This is a tool that you can actually go and download off of Snowflake Labs. If you do a Google search for Snowflake Labs, GitHub, that's our GitHub organization for open-source projects at Snowflake. From there, you'll actually see one of our projects called Snow CLI. This has probably the easiest way through just a couple commands, as long as it's a pure Python function, for example, or pure Python package, you can essentially pickle that and put that into your Snowflake environment and run that inside Snowflake. So, really cool way to get really any package that isn't by default in the Snowflake Anaconda environment, packaged together with your native app.

[0:16:08] SF: One of the things I've noticed with some of the things with the native app is that even if I'm coming from, I don't know, a background as a traditional application developer, maybe I'm really, really familiar. I'm a great Python developer, whatever it is, the language I'm going to be working in. There's still some element where I probably have to touch SQL for permissioning in some of these initial setup and configuration. Have you noticed or seen any issue with essentially like a struggle of application developers, kind of getting up to speed, or accepting the fact that they might have to do a little bit of SQL configuration in order to actually build an application?

[0:16:41] DM: That's a great question. I think that some of this comes from Snowflake has grown up as a data warehouse in the cloud, right? So, I think, to your point, there can be some terminology learning curve in Snowflake for a traditional app developer, where ultimately, for an app developer, inside Snowflake, when you use compute of any kind, you're spinning up, then you assign what's called a warehouse. That's where a data warehousing comes from.

So, a warehouse is, in essence, just a form of compute that your app is running on. You kind of see this pop up in different areas where a traditional app developer, "Hey, I think of compute as an EC2 instance from AWS." But for Snowflake, it's just, it's called a warehouse. A database is another way where for traditional app developer, they have a very particular thing in mind of what a database is. For Snowflake, when you create an app package, essentially, it's creating a database that has all these different snowflake objects inside of it. So, you'll see, I think, some terminology that essentially can be mentally thought of as very close to the same thing. But to your point, some app developers might not be familiar with that terminology, for sure.

[0:17:56] SF: Yes. So, there's some new mental bottleneck stuff that they might have to essentially equip themselves with in order to familiarize themselves with how to like build and deploy a native application on Snowflake. You mentioned the warehousing. So, warehouse, basically maps to like compute, and you have these different sizes that are available from extra small all the way to like, I don't know, 5x large or something. As an app developer, can I actually specify the size of the warehouse is like, optimal, or the minimum size warehouse that you've run my application on in case I need additional compute resources?

[0:18:29] DM: It's a great question. So, when you install a native application, the user of that native app can really fine tune for their own cost reasons like what warehouse they want to run your native app on. But you can absolutely recommend certain sizes for your native app and you can put that in either in the documentation or different aspects of that.

But yes, the other aspect here is some types of compute. So, you mentioned we have our standard warehouses from extra small to double XL and more. But we also have, for example, Snowpark-optimized warehouses. Essentially, those are high-memory warehouses. Then we also have GPUs. So, you can specify, "Hey, I want - I'm running an LLM that needs GPUs for inference to run faster, instead of a general-purpose warehouse. There are definitely a lot of different ways that you can specify what type of warehouse and what size of warehouse you need and go from there.

[0:19:29] SF: How are updates managed? Essentially, a version of my application is living inside one of my customers, Snowflake Environments, and I go and make some important changes. Do those updates happen automatically? Do they have a choice in the matter? Or essentially, can you explain how that process works?

[0:19:46] DM: Yes, absolutely. So, with Native Apps, as a native app provider, so some of the terminology here. We have a native app provider, which is the developer of the native app, a native app consumer, that person installing the native app. So, as a provider of your native app, you have versioning and this is all defined inside that manifest file that I mentioned earlier. You can have different versions and you can have those updates. The whole point here is that you need to be able to have a structured approach to not break the installs of your customers. So, we provide mechanisms on the marketplace for that. But over time, you can have a large number of deployed versions, across many customers. That's the idea here, is that we provide you the tools to define those versions, and give you the ability to make those updates.

[0:20:41] SF: Then, what does the tooling look like today to build native applications? What am I building these applications in. We mentioned programming languages like Python, but like, is there specific tools that I need to use in order to like build a native app, test it, and actually deploy it to the marketplace?

[0:20:57] DM: Yes. So, we have a variety of tools. Snow CLI is really the, I would say, the best tool today is going to be Snow CLI. There's a lot of engineering effort that's gone into making Snow CLI, an amazing developer experience, particularly for Native Apps. Everything from you know helping to manage your staged files, to helping you package, and create that app package, to even installing and doing things like that. So, I would say the best tool that any of the listeners here should go check out is Snow CLI, and use that when developing your native app.

[0:21:35] SF: You mentioned stage files there. The idea of a stage was something that as I started to learn more about Snowflake, was something that I had to kind of build that new mental model for, because I didn't really - I hadn't encountered that terminology before. Can you explain what a stage is?

[0:21:51] DM: Yes. That's another great example of that terminology difference between a traditional app developer and somebody who's developing apps or a user like a data engineer on Snowflake. So, a stage is essentially a place for you to store files and blobs. In essence, a stage is a literal mapping tool like an S3 bucket, for example, or GCP Cloud Storage, or Azure Blob Storage. So, for Snowflake's purposes, you define your stage like any other Snowflake object, and you can create directories on there. You upload your various files and that's actually directly what is used when packaging your native app together. So, you would literally upload Python files, if you're creating UDFs. You would upload your install script, for example. All of that is referenced in the manifest YAML file. So, there's a specific directory structure, or at least a single entry point for a file that is needed for a native app. And then your manifest file will reference other files within that stage and go from there. So, it's a great question that the stage is literally a place to store your files and data.

[0:23:00] SF: Then, in terms of like the advantages as an organization or an application developer, like building Native Apps, we mentioned some of the advantages for someone consuming Native Apps from a security perspective, or even from a compute perspective. But what are some of the advantages to the organization actually building the applications? Why essentially do this and use the app framework in the marketplace?

[0:23:24] DM: So, the reason to use the app framework in the marketplace, it comes down to the fact that your data isn't leaving Snowflake. There's a huge win there regulation wise, if you're in a highly regulated environment. Also, if you are a company that's building apps. Say, you already have a traditional SaaS application that's operating on some customer data. Why would you move to a native app architectural model?

Well, one is that, when your app runs, it becomes a single-tenant application. In essence, a lot of folks I see they have a multi-tenant SaaS model, traditional SaaS. So, they have all these different customers using shared resources in their traditional SaaS application. When you migrate to a, or you move to a native app model, that inherently becomes single tenant because it's running just inside that customer's account. It also means that you as that SaaS provider, you're no longer fronting the cost of that compute and storage that you're having to do on behalf of your customer. Because now, it's your customer, that's defining, "Hey, I'm going to run it on this warehouse. This is the stage I'm doing all these things on." So, it becomes part of their Snowflake build. The difference there is who's paying for the compute and storage costs of running the application? Then, also, who ultimately maintains programmatic control of that data and that compute that that's processing the data?

[0:24:58] SF: I guess from a go-to-market standpoint too, it's also a new channel that you can potentially monetize from similar to like, the growth of iOS applications. A big part of that motivation for people to move to developing applications is you can actually make money there. Essentially, we're able to access a new type of user that they wouldn't have been able to access themselves, because Apple had this great, essentially, tool to access tons and tons of consumers.

[0:25:24] CM: Absolutely. That's really where the Snowflake marketplace shines. So, we have already a huge number of different data sets. But bringing apps now to the Snowflake marketplace, as a native app provider opens up, like you said, a whole new channel of revenue, and this is another really interesting aspect of how Native Apps operate, which is you as the provider, you control how your native app monetizes itself.

So, if you wanted to, you could have it as just a one-time install fee. Once it's installed, wipe your hands, you're done. Or you could have it as a monthly subscription. Every single month, it's a fixed price of X dollars to always have and run this native app. Or you could have it based off of the number of invocations, how many times they invoke your app to run a certain thing, right? Maybe you expose a certain function that's doing sentiment analysis, and you want to charge for the number of times they run that particular function. You can charge based off that. You can even charge based off of, for example, the number of returned rows. Let's say, you run this function, and it returns a million rows. You can would have some type of pricing defined for the amount of data returned. Or you can have some custom, combination of everything. The point is, we have an entire API and framework around how to monetize your native app to really map how you're charging to the consumption of that app.

[0:26:57] SF: Yes. In continuing on this sort of analogy to the iOS App Store, like some of the value as an application developer for the flick of mobile devices, you're sort of like offloading, compute to essentially someone's device. You can - I don't have to worry, essentially, about like the scale of my own infrastructure. I'm basically using the infrastructure device and it's the same thing here where I'm offloading compute. I don't really have to worry about like spinning up a bunch of servers, and so forth. I can really concentrate on app development and making something invaluable in that capacity. Then, the users of those apps essentially are going to be in charge of paying for the compute in that entire environment.

[0:27:36] DM: That's exactly right and I don't think that can be overstated. I mean, a lot of app developers that I talked to, if they've been in the space of web app development for a while, there's a very ingrained SaaS, kind of traditional SaaS architecture that everybody really knows and has grown accustomed to. With Snowflake Native Apps, you get the benefit of, especially when you bring in Snowpark Container Services where you can Node, Express, React inside of Snowflake. The point is it changes the dynamic of how these web applications are built and how they make money. Because the app store for Snowflake, the marketplace really makes a big difference.

[0:28:25] SF: Yes. I want to talk about Snowpark Container Services. You talked about the idea of running an express React web application within the container service. Can I basically run anything that I can run on Docker, or something like that, within Snowpark Container Services?

[0:28:41] DM: That's exactly it. So, you want to run a WordPress site inside of Snowflake, you can do that. You want to just take anything that runs inside of a Docker, you can throw it up into Snowflake, and be good to go. Why would you do that? Why would you want to do that? Again, it goes back to when you combine Snowpark Container Services with the concept of a native application, now you're migrating this application architecture from potentially traditional SaaS where it's multi-tenant. You have a lot of different users, and they each own different parts of the data stack that you have in your SaaS application to a native app, that's just this one instance of your app is being run for a single customer. 

So, you can use the same exact software stack that you have been using. Now, just run that entirely inside of Snowflake. You have all of the benefits of the marketplace, and the big benefit of the user of your app gets the programmatic guarantee that their data doesn't leave their environment. Because they brought your app to their environment, instead of the other way around.

[0:29:48] SF: Yes. Is anyone actually running like a web application directly off of Snowpark Container Service?

[0:29:54] DM: So, at our last summit, we actually demoed a huge number of different partners and customers of ours, running their entire stack natively inside. One of the coolest ones that I saw were actually was Hex. So, if you're not familiar with Hex, Hex is an app for - you can think of it like a Jupyter Notebook almost. But basically, it does a whole lot more. Traditionally, you have to connect your Snowflake account to Hex, and then it's able to kind of execute and you're able to create Python functions inside Hex that run inside Snowflake and use Snowpark, all of the above. To now, where Hex is entirely hosted inside of Snowflake.

You look at the URL at the top of your browser, and it says, snowflake.com URL, right? But you're running Hex. So, that's a pretty big thing. So, Snowpark Container Services just went public preview not too long ago, a few weeks ago, really. We're already seeing a lot of folks starting to leverage Snowpark Container Services, both inside different applications that they have, and all sorts of stuff.

[0:31:02] SF: Then, how does deployment work? How do I go about actually like, packaging up my whatever application I want to run inside the container services, and then deploying it and running it on Snowflake inside my own Snowflake environment?

[0:31:14] DM: Yes, Great question. So, you have, ultimately, in Snowpark Container Services, you have your images. You can develop locally, and you have your Docker file, for example, and you have your spec, your YAML spec, which kind of defines a few elements around it. You would actually put that YAML spec file into Snowflake, and you can create a running hosted service. So, within Snowpark Container Services, there's actually a few ways that you can run it, and this is pretty important to know. One is you can create a managed service. So, containerized service. You can create a job and you can create functions.

So, with a service, it is long-running. You can even create a public URL. If you have just a whole like website that you want, like hosted inside Snowflake that's accessing data in a Snowflake account. That would be a service. Jobs, you can essentially create a job that's run periodically or different times and you can execute that job. And function is kind of how it sounds. You can be able to specify a function and be able to run that function inside Snowpark Container Services. It'll take in some data as an input parameter and return the results, essentially, as a SQL query.

[0:32:29] SF: You mentioned that Container Services is now public preview. Native Apps was announced probably a little - almost two years ago, but now is also public preview, I believe as well, or is it public? Is it GA? Native Apps?

[0:32:43] DM: So, Native Apps is available right now in several regions, and we are adding more regions as time goes. But yes, we announced it, public preview back at summit earlier this year. It's definitely - I would say, right now, is time to get into Native Apps and Snowpark Container Services across the board.

[0:33:02] SF: What's next for applications on Snowflake? What other types of investments, do you think? Or what are some of the problems that need to be solved? Or how do you essentially scale and grow this thing?

[0:33:14] DM: So, I think what's next for Native Apps, what's needed for scale, is one, expand to more regions. Like I said, we're right now across AWS and Azure. So, expanding to more regions, so it's more widely available. But then two is, I think, once Snowpark Container Services, like Snowpark Container Services is really fresh right now. I think as more developers get their hands on utilizing Snowflake, especially for things like LLMs, and utilizing GPUs, that I think will open up a huge number of additional use cases. Because Snowflake has the data today, and this is all about bringing the applications to the data.

So, as more and more developers get on it, that's really how we scale. Everybody knows this thing, developers, developers, developers, developers. So, that is, I think, the next step for scaling this, is just getting more developers hands-on with these tools and these platforms.

[0:34:19] SF: What's kind of like the community look like today that's building on this?

[0:34:23] DM: So, the community today is pretty amazing. We have a lot of different user groups across the globe that really are - we're able to really show, get hands-on, with some labs and things like that. A lot of these community-led events. We have, for example, online user groups, community at snowflake.com, and also places like Stack Overflow, Reddit, things like that, where we are seeing more and more interest in Native Apps and Snowpark Container Services. So, I would say for anybody listening, if you want to really get involved and get hands-on, check out the Quickstart for Native Apps. Quickstarts.snowflake.com and just search for Native Apps. Then, also, check out the one that's for Snowpark Container Services as well.

[0:35:12] SF: Yes. I will say that the - I've gone through the Quickstart. I have also done the introduction in the documentation and they're super easy to follow. It's not a huge time commitment. This is, at all interesting. You can, essentially, not know anything and have something built in an hour or less.

[0:35:28] DM: Yes. Exactly. So, we try and keep those pretty concise, so that we know people are busy. So, keep it fun and lively.

[0:35:38] SF: Awesome. Well, Dan, as we start to wrap up, is there anything else you'd like to share?

[0:35:41] DM: Just check out developers.snowflake.com as well. I'd say like, if anything here, check out developers.snowflake.com, because that'll really point you to the right quickstarts. That will point you to the right direction in terms of thought documentation as well. And be sure and listen in on our YouTube channel as well, a Snowflake Developers' YouTube channel. It's been great chatting with you, Sean. Thank you.

[0:36:02] SF: Awesome. Well, Dan, thanks so much for being here. Cheers.

[0:36:06] DM: Cheers.

[END]