Databricks Apps, The Last Mile Runs Inside the Workspace

Pull-quote: “Every data platform eventually grows a shadow IT ring of Streamlit dashboards on random VMs. Databricks Apps exist so that ring can come home.”

Why this matters

The hardest question in enterprise data delivery is not the pipeline. It is the surface: where do the people who act on the data actually work? For a decade the answer was “a BI tool plus a ring of small web apps on infrastructure nobody remembers approving.” Databricks Apps move that ring inside the workspace: same SSO, same Unity Catalog permissions, same audit surface, deployed with the same asset bundles as the rest of the estate.

When an app is the right answer

And when it is not: broad external audiences, heavy custom frontends, or anything whose lifecycle outgrows a workspace. Those remain conventional applications; forcing them into Apps trades one shadow ring for another.

The thin-client pattern

The architecture mistake to avoid is putting the product inside the app. The app should be the doorway, not the house:

   Databricks workspace                        Platform / services
   ────────────────────                        ───────────────────
   App (Streamlit/Dash)  ──── MCP/REST ──────► Engine, rendering,
     │ SSO passthrough                          domain logic
     │ UC-scoped reads                             │
     ▼                                             ▼
   Unity Catalog tables                        Sealed outputs,
   Genie spaces                                audit records

Keep the in-workspace component thin: UI, identity passthrough, and governed reads. Keep the engine behind a contract (MCP or REST) that any client can call, so the same capability serves the app, the agents, and the CLI without three implementations. A thin app is also what a security review wants: no weights, no secrets, no proprietary logic living in a workspace it does not need to.

This is exactly how we ship AlchemyLake’s Databricks integration: an Apache-2.0 asset bundle containing a thin Streamlit app, an MCP registration, and one optional SQL UDF. One databricks bundle deploy, and the workspace gains a governed creative studio whose engine never enters the workspace at all.

Deployment discipline

• Asset bundles, always. The app deploys like the jobs and pipelines around it: versioned, reviewed, promoted through environments.
• Pin releases. The bundle references a tag, not a branch. Rollback is a redeploy of the previous tag.
• Let the platform own identity. No service accounts smuggled into app code; SSO passthrough and UC permissions are the entire authorization story.

Closing

The last mile of a data platform is a product decision, not an afterthought. Databricks Apps make the governed choice the convenient one: the application beside the data, behind the same door, deploying through the same pipeline. Keep the app thin, keep the engine behind a contract, and the shadow IT ring finally comes home.