Databricks apps versus ServiceNow apps

[Dietric]

I'm a ServiceNow developer evaluating Databricks as an alternative platform for app development. My pain points with ServiceNow include:

• Limited-to-zero support for developing apps in popular modern frameworks like React, Flask, and so on.
• Buggy implementation of development on popular IDEs, such as VS Code.
• Awkward (at best) support for concurrent development using Git branching and merging.
• Zero integration with common CI/CD tools like Jenkins to facilitate automated testing and deployment.
• Awful implementation of automated UI testing
• Seat-based pricing instead of pricing based on usage
• Unpredictable performance without any ability to control horizontal scaling
• Awful CSS framework that produces unpredictable results and code duplication

I have been working on the ServiceNow platform for about 10 years now, and ServiceNow has consistently prioritized features that give me less control, less choice, and less flexibility.

What appeals to me about Databricks Apps:

• Vendor agnostic (we can host on GCP, AWS or Azure)
• Flexible web development frameworks
• Supports different IDEs
• Supports Git
• MCP integration
• Horizontal scaling

Databricks appears to give me a lot of choice while still abstracting enough of the underlying infrastructure management so that my team can develop and deploy apps efficiently.

Here are some of my apps currently running on ServiceNow:

• Management console for IT services to deploy, query, and de-provision Cloud PCs
• Input form where IT services scan physical laptop assets into the ServiceNow management database
• Scheduling interface for end users to make appointments for refreshing outdated hardware assets
• Migration wizard that walks users through the process of transferring into or out of the company as part of an acquisition or divestiture
• App store interface to facilitate end users browsing and installing from a catalog of approved software applications

My questions:

• Is Databricks Apps a good fit for these use-cases?
• Will migrating ServiceNow hosted apps onto the Databricks platform provide any cost savings?
• Will Databricks apps be more performant than ServiceNow?

In short: while I immediately see the benefits to developers of hosting on Databricks, I'm not yet sure how to make the business case for switching off ServiceNow onto Databricks.

[Lu_Wang_ENB_DBX]

TLDR: Databricks Apps is not a 1:1 ServiceNow replacement. Its intended uses are internal web apps tied to data/AI, especially data entry forms and custom operational interfaces; it supports Python or Node.js, React, local IDE-based development, Git-backed deploys, and CI/CD with Declarative Automation Bundles and GitHub Actions.

For your examples

• Cloud PC management console: good fit, assuming it is mainly a custom UI over APIs/data rather than deep ServiceNow-native workflow logic.
• Laptop asset intake form: strong fit; “data entry forms” is an explicit Apps use case.
• Hardware refresh scheduling UI: medium fit; the front end is a fit, but you should validate the scheduling/notification back-end separately.
• M&A transfer wizard: good fit if it is mostly guided forms plus API orchestration.
• Software catalog / app store UI: medium fit; good for the catalog/search interface, but evaluate fulfillment and entitlement workflows carefully.

Cost savings

Possible. Databricks Apps is usage-based: apps are billed per running hour based on provisioned capacity; Medium is 0.5 DBU/hour and Large is 1 DBU/hour, and stopped apps do not incur cost.

The strongest savings case is when you can retire separate hosting/infra work and reduce operational overhead. 

Performance

More controllable, likely to be faster. You can explicitly size apps at Medium (up to 2 vCPUs / 6 GB) or Large (up to 4 vCPUs / 12 GB), and horizontal scaling now supports multiple instances behind one URL for higher availability and concurrency, with zero-downtime deployments; compute cost scales linearly with instance count.