cancel
Showing results forย 
Search instead forย 
Did you mean:ย 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

How I explain classic vs serverless compute, and the limitation list I check before migrating a job

techinlayers
New Contributor II

Sharing the two-column version I use when someone asks which compute to pick.

Classic: the control plane requests VMs from your cloud provider and the cluster runs in your own account and network. You own instance types, autoscaling and networking, and you pay the cloud provider for the machines plus Databricks for the DBUs.

Serverless: resources run in the serverless compute plane, managed by Databricks, and nothing is provisioned in your cloud account. Tables stay in your own storage.

Before moving an existing job I check it against the documented serverless limitations: R is not supported; compute-scoped libraries and init scripts are not supported; only Spark Connect APIs are available, so RDD APIs are out; Trigger.AvailableNow() is supported but Trigger.Continuous and Trigger.ProcessingTime are not; and there is a 7-day maximum runtime after which a run is terminated and not retried.

Animated diagram of both paths, 2:36: https://youtu.be/s8452E2Y6WM
The series in order: https://www.youtube.com/watch?v=B5iHmoYgnqY&list=PLDB5WDkDOYF4

Interested in how others decide the boundary in a mixed estate - per workload, per team, or per environment?

You press run on a notebook. Databricks can serve that one request in two completely different ways. This video draws both lanes: classic compute, where a cluster of virtual machines is created inside your own cloud account, and serverless compute, where capacity comes in seconds from a pool ...
0 REPLIES 0