<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Databricks apps versus ServiceNow apps in Get Started Discussions</title>
    <link>https://community.databricks.com/t5/get-started-discussions/databricks-apps-versus-servicenow-apps/m-p/160150#M11867</link>
    <description>&lt;P&gt;&lt;STRONG&gt;TLDR:&lt;/STRONG&gt;&amp;nbsp;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.&lt;/P&gt;
&lt;H3&gt;For your examples&lt;/H3&gt;
&lt;UL&gt;
&lt;LI&gt;&lt;STRONG&gt;Cloud PC management console:&lt;/STRONG&gt; good fit, assuming it is mainly a custom UI over APIs/data rather than deep ServiceNow-native workflow logic.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;Laptop asset intake form:&lt;/STRONG&gt; strong fit; “data entry forms” is an explicit Apps use case.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;Hardware refresh scheduling UI:&lt;/STRONG&gt; medium fit; the front end is a fit, but you should validate the scheduling/notification back-end separately.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;M&amp;amp;A transfer wizard:&lt;/STRONG&gt; good fit if it is mostly guided forms plus API orchestration.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;Software catalog / app store UI:&lt;/STRONG&gt; medium fit; good for the catalog/search interface, but evaluate fulfillment and entitlement workflows carefully.&lt;/LI&gt;
&lt;/UL&gt;
&lt;H3&gt;Cost savings&lt;/H3&gt;
&lt;P&gt;&lt;STRONG&gt;Possible.&lt;/STRONG&gt; 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.&lt;/P&gt;
&lt;P&gt;The strongest savings case is when you can retire separate hosting/infra work and reduce operational overhead.&amp;nbsp;&lt;/P&gt;
&lt;H3&gt;Performance&lt;/H3&gt;
&lt;P&gt;&lt;STRONG&gt;More controllable, likely to be faster.&lt;/STRONG&gt; 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.&lt;/P&gt;</description>
    <pubDate>Mon, 22 Jun 2026 17:43:56 GMT</pubDate>
    <dc:creator>Lu_Wang_ENB_DBX</dc:creator>
    <dc:date>2026-06-22T17:43:56Z</dc:date>
    <item>
      <title>Databricks apps versus ServiceNow apps</title>
      <link>https://community.databricks.com/t5/get-started-discussions/databricks-apps-versus-servicenow-apps/m-p/159815#M11861</link>
      <description>&lt;P&gt;I'm a ServiceNow developer evaluating Databricks as an alternative platform for app development. My pain points with ServiceNow include:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Limited-to-zero support for developing apps in popular modern frameworks like React, Flask, and so on.&lt;/LI&gt;&lt;LI&gt;Buggy implementation of development on popular IDEs, such as VS Code.&lt;/LI&gt;&lt;LI&gt;Awkward (at best) support for concurrent development using Git branching and merging.&lt;/LI&gt;&lt;LI&gt;Zero integration with common CI/CD tools like Jenkins to facilitate automated testing and deployment.&lt;/LI&gt;&lt;LI&gt;Awful implementation of automated UI testing&lt;/LI&gt;&lt;LI&gt;Seat-based pricing instead of pricing based on usage&lt;/LI&gt;&lt;LI&gt;Unpredictable performance without any ability to control horizontal scaling&lt;/LI&gt;&lt;LI&gt;Awful CSS framework that produces unpredictable results and code duplication&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;What appeals to me about Databricks Apps:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Vendor agnostic (we can host on GCP, AWS or Azure)&lt;/LI&gt;&lt;LI&gt;Flexible web development frameworks&lt;/LI&gt;&lt;LI&gt;Supports different IDEs&lt;/LI&gt;&lt;LI&gt;Supports Git&lt;/LI&gt;&lt;LI&gt;MCP integration&lt;/LI&gt;&lt;LI&gt;Horizontal scaling&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Here are some of my apps currently running on ServiceNow:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Management console for IT services to deploy, query, and de-provision Cloud PCs&lt;/LI&gt;&lt;LI&gt;Input form where IT services scan physical laptop assets into the ServiceNow management database&lt;/LI&gt;&lt;LI&gt;Scheduling interface for end users to make appointments for refreshing outdated hardware assets&lt;/LI&gt;&lt;LI&gt;Migration wizard that walks users through the process of transferring into or out of the company as part of an acquisition or divestiture&lt;/LI&gt;&lt;LI&gt;App store interface to facilitate end users browsing and installing from a catalog of approved software applications&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;My questions:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Is Databricks Apps a good fit for these use-cases?&lt;/LI&gt;&lt;LI&gt;Will migrating ServiceNow hosted apps onto the Databricks platform provide any cost savings?&lt;/LI&gt;&lt;LI&gt;Will Databricks apps be more performant than ServiceNow?&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Thu, 18 Jun 2026 18:07:12 GMT</pubDate>
      <guid>https://community.databricks.com/t5/get-started-discussions/databricks-apps-versus-servicenow-apps/m-p/159815#M11861</guid>
      <dc:creator>Dietric</dc:creator>
      <dc:date>2026-06-18T18:07:12Z</dc:date>
    </item>
    <item>
      <title>Re: Databricks apps versus ServiceNow apps</title>
      <link>https://community.databricks.com/t5/get-started-discussions/databricks-apps-versus-servicenow-apps/m-p/160150#M11867</link>
      <description>&lt;P&gt;&lt;STRONG&gt;TLDR:&lt;/STRONG&gt;&amp;nbsp;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.&lt;/P&gt;
&lt;H3&gt;For your examples&lt;/H3&gt;
&lt;UL&gt;
&lt;LI&gt;&lt;STRONG&gt;Cloud PC management console:&lt;/STRONG&gt; good fit, assuming it is mainly a custom UI over APIs/data rather than deep ServiceNow-native workflow logic.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;Laptop asset intake form:&lt;/STRONG&gt; strong fit; “data entry forms” is an explicit Apps use case.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;Hardware refresh scheduling UI:&lt;/STRONG&gt; medium fit; the front end is a fit, but you should validate the scheduling/notification back-end separately.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;M&amp;amp;A transfer wizard:&lt;/STRONG&gt; good fit if it is mostly guided forms plus API orchestration.&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;Software catalog / app store UI:&lt;/STRONG&gt; medium fit; good for the catalog/search interface, but evaluate fulfillment and entitlement workflows carefully.&lt;/LI&gt;
&lt;/UL&gt;
&lt;H3&gt;Cost savings&lt;/H3&gt;
&lt;P&gt;&lt;STRONG&gt;Possible.&lt;/STRONG&gt; 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.&lt;/P&gt;
&lt;P&gt;The strongest savings case is when you can retire separate hosting/infra work and reduce operational overhead.&amp;nbsp;&lt;/P&gt;
&lt;H3&gt;Performance&lt;/H3&gt;
&lt;P&gt;&lt;STRONG&gt;More controllable, likely to be faster.&lt;/STRONG&gt; 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.&lt;/P&gt;</description>
      <pubDate>Mon, 22 Jun 2026 17:43:56 GMT</pubDate>
      <guid>https://community.databricks.com/t5/get-started-discussions/databricks-apps-versus-servicenow-apps/m-p/160150#M11867</guid>
      <dc:creator>Lu_Wang_ENB_DBX</dc:creator>
      <dc:date>2026-06-22T17:43:56Z</dc:date>
    </item>
  </channel>
</rss>

