Snowflake is serverless

Written by Thomas Milner, Data Superhero.

In addition to data engineering, I also have a strong interest in serverless computing. I have been working with Snowflake Data Cloud for the last 18 months and it struck me recently that the platform has a lot in common with how AWS serverless services like DynamoDB, S3 and Lambda work.

What is serverless?

I was also inspired to write this article after reading Jeremy Daly’s Not so serverless Neptune blog post. The post references an older definition of serverless from AWS’s initial pitch. While I was looking at these 4 benefits, it struck me again that Snowflake meets a lot or all of these requirements.

One of Jeremy Daly’s main points is that AWS’s definition of serverless has been reduced overtime. And from AWS’s latest serverless landing page, we can see this reduction in their most recent definition:

1. Move from idea to market, faster
2. Lower your costs
3. Adapt at scale
4. Build better applications, easier

Serverless technologies feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility and optimize costs. These technologies also eliminate infrastructure management tasks like capacity provisioning and patching, so you can focus on writing code that serves your customers..

The no server management has been swapped for eliminate infrastructure management tasks like capacity provisioning and patching. And more importantly, the No idle capacity has been changed to lower your costs and a pay-for-use billing model. This is possibly because it’s absence makes it easier to sell other products like Aurora, Neptune and OpenSearch as serverless. None of these scale back to zero and just turning them on will cost customers money.

AWS isn’t the only provider of serverless services and other commentators and cloud service providers have written articles about what it means to them.

Michael Walmsley writes a very good article on the subject, linking to Momento’s blog on it. Momento lists their 5 checks as a litmus test:

1. Nothing to provision, nothing to manage.
2. Usage-based pricing with no minimums.
3. Ready with a single API call.
4. No planned downtime
5. No instances.

Momento makes a big point of serverless needing to be instant and being able to start instantly with a single API call. They are selling a cache product which being instant would be a big advantage but I don’t think it’s needed in every case. In my experience with batch data processing, you may be willing to trade this instant experience for a lower cost.

Cloudfare lists the benefits of serverless in this article as:

1. lower costs
2. simplified scalability
3. simplified backend code
4. quicker turnaround

There is a lot of cross-over here with AWS’s 4 advantages. Both are touting lower costs as an advantage of serverless. On a pure cost of compute, serverless can appear more expensive but in my experience this cost is generally offset by lower total cost of ownership. Other definitions will trade off the higher cost of the service versus the lower operational cost.

Azure defines serverless as the following in their introduction to serverless page.

1. No infrastructure management
2. Dynamic scalability
3. Faster time to market
4. More efficient use of resources

GCP doesn’t try to define serverless on their serverless landing page.

Unfortunately, I couldn’t find a single agreed definition of Serverless and maybe that is not possible. As Ben Kehoe outlines in his The Serverless Spectrum article,

serverless is not an all-or-nothing proposition. It’s a spectrum — and more than that, it has multiple dimensions along which the degree of serverlessness can vary.

As the following table shows, the different vendors all place themselves on different positions along the spectrum. Interestingly, neither AWS, Azure or Cloudflare mentions No idle capacity as a characteristic of serverless. Only Momento does.

For the purposes of this article and assessing Snowflake as serverless, I’m going to look at the platform for each of the following dimensions and see how far along the spectrum it goes.

1. Faster time to market
2. Focus on business value
3. No idle capacity
4. No server management

Snowflake is Serverless

Faster time to market

Having the ability to roll out an application to production without needing to worry if the underlying infrastructure can support it is a massive advantage in going to marker. For example, our team in Tenable rolled out 12 new instances of a data platform powered by Snowflake across multiple global locations in 2 weeks. Due to platform’s elastic scaling, we didn’t need to spend any time on capacity planning beforehand. There was no need to purchase or reserve compute instances and associated storage. We could happily go into production knowing that we could dial up or down compute when we needed it and our storage would scale.

A good example would be the loading of historical data. Without elastic compute and storage, a team could be planning and executing a backfill of older data for months. I’ve been in situations where we have had to do it and it definitely adds time (weeks to months) to how quickly you can go to market. With Snowflake, you can dial the compute all the way up and load all the data quicker. And in practise it doesn’t cost anyhow. As you increase instance sizes, the cost per second does increase but the amount of time that you need the compute reduces to compensate. For normal workloads, you just dial the compute back down. The storage is already there and doesn’t need to provisioned separately.

Focus on business value

By reducing operational load, a team developing on Snowflake can use the time saved to focus on delivering business value. Spending 2 days out of 5 on infrastructure should still leave 3 for delivering customer value but it rarely works that way. By allowing developers to focus full-time on delivering business value, they will be able to concentrate on a single domain and not get distracted by operational concerns.

The Team Topologies book talks a lot about reducing cognitive load on a team. I believe that choosing serverless is a great way to reduce cognitive load for developers. It also allows them to reduce context switching between infrastructure and development.

By using Snowflake my team has reduced it’s total operational load and increased its capacity to deliver business value to our customers. New hires can be effective immediately by focusing on writing business logic and not having to worry about how the infrastructure needed to run it.

No server management

Compute power (CPU and memory) are provisioned in Snowflake through virtual warehouses. When you have a task or query to run, you must chose a warehouse from a range of sizes, X-small to 6X-Large.

My team and I have been running 15 instances of a production customer-facing application across 11 Snowflake global accounts for over 8 months now. Except for one minor outage, we have never had to worry about compute being unavailable or being in a situation where the service did not recover itself without failure.

Snowflake also provides the capability to run tasks with serverless compute. By utilising this feature, a developer does not need to create a separate warehouse before creating a task. They can just hand that responsibility over to Snowflake and the platform decides how much compute the task will need. The other big benefit of serverless compute is the 1 second minimum pricing. Virtual warehouses have a 1 minute minimum. In my experience serverless tasks work well where you have predictable workloads. If you are running something with a reasonable amount of elasticity, the way Snowflake determines the amount of compute power to run the task can lead to expensive surprises. Virtual warehouses do provide a greater level of cost predictability.

As stated, I believe there is no server management with Snowflake and it meets this dimension fully as a serverless service.

No idle capacity, scale to zero

With Snowflake, you don’t pay for idle capacity. Once the compute has been turned off, you don’t pay beyond a one minute minimum pricing. Michael Walmsley put it best.

If there is no traffic, there is no cost is the fundamental core of what Serverless truly means to us and is how we think of the term “Serverless”.

However, there may be cases where you need to leave your compute turned on even when it isn’t used. Cold starts are an issue when turning on Snowflake compute. It isn’t instant and Snowflake warn that it might take some time in their documentation.

Initial creation of a virtual warehouse might take some time to provision the compute resources, unless the warehouse is created initially in a SUSPENDED state.

If you need to support a workload where you need an instant response, you may need to pre-provision a virtual warehouse to get around this. For example, if you have a customer facing application where you want sub-second response times, you will need to leave your virtual warehouse turned on for an extended period just in case. For this reason, this is one dimension where Snowflake isn’t as far along the serverless spectrum as others.

Summary

In summary, I will say that I believe Snowflake can be considered a serverless platform. The one dimension I see it falling down on is the No idle capacity. If you have a use case where you always need an instant response time, this may require you to run virtual warehouses provisioned even when they are not being used. It is similar in this regard to AWS Lambda’s provisioned concurrency feature.

And Snowflake is not just for analytical use cases anymore. They are pushing hard into the application development market. With new features like Snowpark and Streamlit powered by Snowflake provided compute, it is very close to providing a full ecosystem of services to build full-stack applications. Their Unistore tables will allow Snowflake to support OLTP workloads. I can see a point in the future where software providers can built an entire customer-facing application entirely within the Snowflake platform.

I see great potential here but one of the areas Snowflake will need to address is the start up time of their virtual warehouses. Expecting application users to wait some time to provision the compute resources will limit the scope of what applications built on Snowflake can achieve.