Skip to main content

Apps Factory on Databricks​: Provision, Standardize, Observe and Govern 100+ Apps​

Summary

  • Hiflylabs introduces the Apps Factory methodology for governing more than 100 Databricks Apps at enterprise scale in high-stakes industries such as finance and healthcare, where ungoverned app proliferation leads to hidden costs and security risks.
  • The framework covers provisioning and ownership with Databricks Asset Bundles, access control with AI Gateway, reference architecture templates, coding agent guardrails, and lifecycle management with CI/CD and Lakebase branching.
  • Real-world anti-patterns are illustrated including apps running without a known owner, access control gaps introduced by agents needing full context, and Lakebase scaling at over 8,000 queries per second with horizontal scaling.

Apps Factory on Databricks​: Provision, Standardize, Observe and Govern 100+ Apps​

Watch: Apps Factory on Databricks​: Provision, Standardize, Observe and Govern 100+ Apps​
Databricks Apps makes it easy to publish the first app. We address the compounding challenges organizations face when scaling to 10, 50, or 100+ Databricks Apps: inconsistent architecture, unclear access control, missing standards, ungoverned AI components and runaway costs. We will walk through a comprehensive methodology, including solutions and principles to provision, govern and observe dozens of applications at enterprise scale. The session includes reference architecture, frameworks, templates, a production readiness checklist, CI/CD setup, security & access control, unified logging and cost tracking. Attendees receive a comprehensive technical governance and adaptation playbook to effectively manage and scale app ecosystems.
Talk By: Domonkos Pal, Director of Digital Product Development, Hiflylabs ;

Chapters

FAQs

What is Apps Factory and what problem does it solve on Databricks?

Apps Factory is a governance and production methodology from Hiflylabs for organizations managing dozens to hundreds of Databricks Apps. It addresses compounding challenges that emerge at scale, including unclear app ownership, inconsistent architecture, ungoverned AI components, missing access control standards, and runaway infrastructure costs.

How does Apps Factory handle access control for Databricks Apps?

Access control is addressed through a combination of on-behalf-of (OBO) tokens, service principals, and AI Gateway, each suited to different trust boundaries and use cases. The methodology specifically calls out the risk of agents requiring broad context access, which can inadvertently create data firewall leaks between parties that should not share information.

What reference architecture templates does the Apps Factory framework provide?

The framework provides templates for three levels of Databricks Apps complexity—from prototype to flagship—covering Streamlit, AppKit, and APX (FastAPI and React) patterns. These templates encode best practices for authentication, logging, cost tracking, and CI/CD so development teams start from a production-ready foundation.

How does Lakebase support the Apps Factory lifecycle management pillar?

Lakebase is used as the transactional backend for production apps and supports branching for CI/CD workflows, allowing teams to validate schema changes before deploying to production. The video notes that Lakebase can scale to more than 8,000 queries per second with horizontal scaling, supporting flagship-tier applications in high-volume enterprise environments.

Full transcript

[00:07] Good afternoon everyone. I hope you are enjoying the summit. It's so good to connect and reconnect again this year. And um
[00:21] Before we start, um just a small piece of housekeeping. Uh it's a bit long, so to sum it up, just please don't believe anything I say and with that said, we are good to go. Um The more apps you have, the higher the
[00:34] chance that you are leaking money. My presentation today is about stopping that leakage with Apps Factory. I'm Domonkos Pal, hi everyone, from High Fly Labs, 13 years of building
[00:48] enterprise data apps in industries like finance and health care. And over the past year, many clients reached out to us that they don't just have one use case for apps,
[01:01] but potentially several hundreds to cover. And so my goal with Apps Factory was to create an environment tailored for mass production of apps in these high-stake industries
[01:14] um like finance and health care, where there's no room for mistakes. Because in my experience, these issues are almost never visible on the surface. They come
[01:26] they come at you sneaky. So, let me tell you five made-up stories. I've masked all the details, so if it sounds familiar, that's a complete
[01:38] uh coincidence. Um Yeah, some of them might sound a little bit um oversimplified, but um I really wish I could tell you we've never seen issues like that.
[01:51] Like the first one, we had a customer who was looking for the owner of an application. And then um
[02:03] he received what is probably the most expensive answer in the industry. The guy who built it is already left has already left. Now, on one hand that's a pretty
[02:15] impressive app. Like if it runs years without supervision, but on the other hand come on. Like it sounds obvious but it's real because of Databricks UI by default the app is created under your
[02:27] own personal account. We'll get come back to this but um let's look at the next one.
[02:42] Here's a pretty common situation um at a health insurance company. They provide health insurance for patients and also malpractice coverage to doctors.
[02:55] Which means that there are um uh cases where in the very same incident they insure both parties. From a data perspective
[03:07] like there should be a wall between the claim claims adjusters. Um and that part is easy with Databricks governance. Uh but what happens if
[03:19] you start introducing apps, agents, and they say that hey, I need a full contact to be helpful. And imagine that firewall is leaking through the app. That's an instant
[03:31] disaster. That's broken broken trust. Um and we also have clients with a fleet of application and it's not rare that say due to a like critical security patch a
[03:45] sweeping update has to go out. Easy like one dependency uh one PR template um can be done by lunch.
[04:04] Without standards, it turns out every app is wired differently. So, now we get to choose. Do we accept the risk or we or we accept the outage? The word cup is on right now, and this
[04:17] story from last week, actually. Someone I knew Someone I know had to push a last-minute promo into an application. Um kickoff is in 10 minutes.
[04:30] Turns out the only person who can deploy is on holiday. Oh, I forgot. Okay. You can see the story. Uh
[04:43] It seems obvious again, but the most lost revenue I have ever seen came from releases slipping something on something exactly like this, or even worse.
[04:57] Here's a street I've seen many, many times. Uh we get a surprise $80,000 cloud bill. And why didn't any single artist, let's say at 2,000? Okay, no drama, we can
[05:10] learn from it. Let's check the logs. It's not in the logs. Turns out there's no proper tagging, or the app logs and the agent logs are not
[05:24] wired together. So, the only thing we can observe is the bill. Um And what's common in all five stories? Two things, basically.
[05:37] Sometimes they are incredibly easy to forget about, and you only notice when the damage is done. And most of them are about avoidable. >>
[05:49] >> And in fact, after a while while it sometimes takes more effort to maintain these practice these bad practices than to prepare for them in advance.
[06:06] I have endless stories like this. But let's focus on apps. This time last year I had to the chance to stand somewhere here and show how efficiently we can deliver an end-to-end agentic application on Databricks apps.
[06:18] And since then, we have seen that unfold at every level. It starts with prototypes, a workflow, a dashboard, a human inter- human in the loop interface for app-
[06:31] for agents. >>
[06:52] And you set up a, for example, a genie and a knowledge assistant, maybe a supervisor agent on top of that, like in this example, and you can build end-to-end working demos like completely from scratch. And not too long ago, this
[07:04] would have taken like what, weeks, months, probably even more. Um the next level, you take a concrete use case and deploy it
[07:18] as an MVP to users. And say some- something like a chatbot chat based app or a workflow automation or both. In the past few past few months,
[07:30] we have seen several of these built in days or um one or two weeks with everything included and deployed to production.
[07:44] Level three. And um finally, there are the truly complex flagship enterprise applications like this one from healthcare. At this level, you go completely custom
[07:57] tailored with um custom serving endpoints or an agent declare spending multiple applications, custom vector search and data pipelines all under Unity Catalog's file, model,
[08:10] and data governance. And the interesting part that isn't >>
[08:22] It's that you never have to leave the Databricks environment to implement a complex health health care uh application. Everything is there integrated. >>
[08:34] hours, days, weeks. What's the consequence of building or shipping this fast? When the marginal cost of building an application drops this far, your
[08:46] organization will build hundreds of them. Um not hundreds of uh flagships uh of course, but a lot of prototypes. And you want probably the to make the way
[08:59] uh for these prototypes to production. And um because the full world is full of automated manual Excel-based processes. And that now can be covered much easier,
[09:13] much faster. And yeah, it's no judgment. We also have some of those supporting spreadsheets, but I guess your organization is no probably no exception either. And um
[09:26] so, why Databricks? What makes it different for apps? In my opinion, it breaks down into five pillars. First, and probably the most important,
[09:38] the built-in capabilities. You don't struggle with old security, infra, observability, scaling. It's handled. And I would include the DevEx as well. Templates, workflows, agentic toolkits, everything around them.
[09:51] >>
[10:03] it. The second, just as important, Lake Base. Um a managed low-latency Postgres for your app and agent state with auto-scaling and branching.
[10:16] But, um most importantly, you probably keep keep seeing back and forth with the UCN Lake Base. And that's something uh the industry has been trying to solve
[10:29] for decades. And it finally works. And on top of that, we heard that Lake Tap is arriving. So, the old wall between the transaction transactional and analytical data is
[10:43] uh gone. And that alone unlocks a whole set of new use cases. Third, normally, every app is a new data silo.
[10:56] Here instead, we build on the data that we already have. Um on an established platform, established governance layer. Avoiding hundreds of data silos was a
[11:08] major point when we created the concept of Apps Factory. Number four, the agentic layer can uh be deeply embedded to the apps. And
[11:23] that agentic layer is fully equipped with every tool and capability required. And finally, Genie 1 um a com- comprehensive, constantly
[11:37] growing, and constantly renamed ecosystem for building business users, democratizing business, and data. And um yeah.
[11:49] This again sounded like little marketing, but uh business usage is really in the spotlight like um compare the keynotes from today to one like 5 years before. It's completely
[12:03] business focused. Um so, what happens when your engineering team gets this beautiful, easy-to-use uh Swiss Army knife?
[12:15] They start pouring out application, and to be clear, this is good. This it should be supported, encouraged. But it comes with one big problem, or
[12:27] actually eight multiplied by the number of engineers. Probably uh there will be personal accounts, maybe missing governance, no tracing, no tags,
[12:39] code hand push push to production, uncontrolled spend, security depths, and more. And you have two options. You can lock the resources down at the workspace
[12:52] level, which is okay, absolutely fine. We also do it. But um there's a risk. By overusing it, you can push uh even further from production, and you
[13:04] can easily end up with shadow IT. Or option two, hand your engineers tools um that make efficient to to build
[13:16] correctly from from scratch from day one with provisioned, templated, tags, telemetry, CI/CD, token security scans by default Uh sorry, token limit
[13:29] security scans by default. And um Now, you may say that, "Okay, but governance sounds slow. You promised me speed." And that's fair. Uh it does take
[13:44] an investment for a single app and for a little while, you may be faster without all of this. Um but it pays back very quickly. To illustrate this, like do trains move faster with a messy layout with
[13:57] uncoordinated tracks or in in a highly automated, well-engineered rail system? And our measurements um say the same, like you can set it up
[14:09] in about 4 weeks and after for development runs with roughly 30% less engineering effort. And this is not just what we measured,
[14:21] but actually uh this is also grounded in Google DORA's metrics. But ROI uh is just a secondary thing or secondary bonus. We do it to be insured
[14:34] again against everything mentioned in those five stories. >>
[14:47] apps at apps factory in practice. In a fleet of apps, the expensive part is in the coding, especially with the agentic engineering. It The expensive part is every single
[14:59] decision uh that um about the proper layering and wiring. And with a blueprint, you can make those decisions once. So, let's walk through the apps
[15:11] factory pillar by pillar. The first aspect is provisioning and ownership. >>
[15:23] important. The big advantage of apps is actually the one-click setup. But the downside of one-click is everything that it doesn't set up, like tags, budgets,
[15:35] proper ownerships, and so on. The go-to solution is using dabs, isn't it? Like hands down, we can move on. Next slide.
[15:47] Until one of our clients said that it's not enough for them. So, what if with one-click we provisioned the entire workspace and separate individual use cases at a
[16:00] workspace level with an infrastructure as a code description that contains the entire workspace, the services, the accesses, the catalogs and volumes, the policies,
[16:12] tags, and even the logging and the checkpoints at the end. And with that, you would don't just save time, but you simply never end up with unknown, untagged, untraceable apps.
[16:25] >>
[16:38] the beginning again beginning. Well, it's it is mostly covered is probably not the answer you want to hear about security. So, let's get a few approaches straight.
[16:52] One, but first OBO, on behalf of, the app acts as the user and can only reach what the user could reach anyway. Clean, no problem.
[17:08] Second one, service principal. Now, we are authorizing a service account to reach content. We are doing this to give our apps and agents the entire context. And this is where it gets interesting.
[17:21] So, as a result, the service can access the data that the user cannot. And um if you don't follow uh least privilege principle, you probably that's a
[17:33] straight road to privilege escalation, which is game over. Uh and now I'm going to contradict myself a
[17:45] little. Earlier, I was phrasing the built-in governance, but it's not always automatic. Like in this example, we have the Unity catalog, the lake bay, and the lake base, and the data syncs through
[17:59] uh sync tables. But only the data is synced, not the policy. So, we have to recreate your those row-level security policies on the lake bay side with manual step. It's not that hard, but still needs some manual
[18:12] effort. I know a solution for this is coming, but still now you have to do it. And uh so, the readable metadata doesn't necessarily mean uh enforced policy.
[18:26] That's maybe the takeaway here. And beyond that, and this is not revolutionary, but the application layer has to be treated like any other application. Controlled by by patterns
[18:40] with full uh audit trail. The AI specific AI specific policies should be there in AI gateway and beyond like the approved model list, the tools to use
[18:52] for the policies. Um rate limits or uh prompt injection mitigation. And the good news, there are a lot of checklists for that and auto tool
[19:05] automations like checking the goes go statically or the packages used or um simulating dynamic attacks and that can give you a daily scan report for
[19:18] free. Um the pillar's free templates, my favorite topic. This is really the heart of Apps Factory. So, one thing to declare up front, not
[19:32] everything is a nail and not everything is a hammer. I don't want to talk about like one-size-fits-all templates. Uh the first thing we need to define is the
[19:44] reference architecture we follow. So, let me show you one example. Um and maybe that Mm.
[19:56] >>
[20:09] um please accept for now that we will start with the user action. So, the entry point of business consumption is Genie. That's where people reach your apps, your dashboards,
[20:21] your Genie spaces, but an app can integrate and orchestrate all of it. It's a classic full-stack app, front end, back end, but you don't have to deal with the built-in stuff and the application layers uh should stay thin
[20:35] and delegate the heavy lifting to the layers underneath. Um As a first step, let's say we uh talk to built-in AI tools and ship valuable products in hours.
[20:48] Uh but we don't want to stop there. We build out our custom agents, the transactional data store in lake base, refine and scale the product. The next step is orchestrating the agents.
[21:01] And uh for the full end-to-end build out, we also ship the medallion architecture, the sync loop between the operational and analytical data. And the entire setup deploys with
[21:14] um deploys with dab. templates. Databricks offers many awesome built-in starters, but what I want to show here
[21:26] are the reference on implementations, boilerplate, not lightweight starters. Four levels depending on the complexity of the product or how much control you actually need. Level one,
[21:39] um when the interface or the future scalability isn't the point you just want to give create a fast example. Um like in the first keyword, that's just a personal Streamlit-based scaffold
[21:51] on GitHub with uh specific agent skills uh baked in so you can deliver an interface for your agents with like a single prompt.
[22:04] Um Level two, App Kit, a Node uh based full stack template from the Databricks product team. And it's actually fantastic. It ships built-in plugins for
[22:16] built-in plugins for most Databricks services like Genie, Lakehouse model serving, and more more. Uh the um engineers from the product team are here at the summit, so use the opportunity
[22:29] and go talk to them. What they are building is is yeah really awesome, and they know a lot more features are coming. Um Thanks to the plugin um ecosystem, it
[22:42] doesn't require a deep Node.js expertise, and it's backed by the very very strong engineering toolkit.
[22:54] Level three, there's another one from Databricks but from field engineering, APX. A really good Python plus React scaffold. It gives you more flexibility but requires more effort to use.
[23:08] And the classic fully custom built. You can create your own boilerplate too, like the sample implementation I pushed to another repo. Um
[23:21] It's It's a completely ordinary app with minimal Databricks specific details. So, it's the most flexible across the cloud providers, but the downside is that with
[23:33] this approach that this requires far the most effort. Um that's That said, it's worth mentioning that they It's It's built in Python, but Node.js SDK is coming or
[23:45] actually here. So, you can build the same kind of custom full-stack template on a completely Node.js stack as well. So, my advice is build your own typical
[23:57] So, build your own um version of this, select the one that fits your project size or the how typically the teams work or how the
[24:11] tech stack um looks like at your organization. Uh because this isn't about making every app identical, it's about making them recognizable. So, when an engineering is
[24:24] switching a project, the structure can feel familiar. And now it's time to play the good old Node versus Python match. So, please
[24:36] Python believers to the left, Node believers to the right. Or we can call that game actually off because they work beautifully together. Node is great for the front end and API
[24:49] layer. So, it has the greatest end-to-end uh dev ex coverage. It's so good in in orchestration, streaming, handling a lot of concurrent sessions, JSON schemas. And on the
[25:04] Python has um some of these capabilities as well, but it's stronger on the AI and data layer like agent definitions, embedding, parsing, OCR, vector ops, rag,
[25:18] ML and everything in ML basically. So, you can either choose Node or Python or Node plus Python. And oh, favorite topic, performance.
[25:32] Uh I can spend the entire day here about this, but I try to be quick. So, the do's and so just some ideas. Like if you have a scaling issue with a
[25:44] couple hundred simultaneous users, there's a chance you are not delegating something properly. But I'm going to show you a few numbers that are absolutely not representative.
[25:57] Um like it's so hard to compare Streamlit with a full stack app as it it has its own custom web socket rendering. So, I tried to measure it in the honest way by
[26:09] real browser sessions. There's a tool called for uh called K6 for that. Uh so, it um uh collects the rendering performance,
[26:22] which is not an API benchmark. And on the medium instance, we see which was the minimum Streamlit was able to like do 10 simultaneous users perfectly and in 50 in an acceptable day uh way.
[26:36] While the Node and Python stacks were able to go far beyond that number. And two important
[26:50] context about this. These were like real complex applications, not just basic starters. And the second one is that this is done actually on my machine where the rendering is a bottleneck. So, please
[27:02] don't go away with that Streamlit can only like do 10 simultaneous users, but rather with the impression of the performance difference between a Streamlit based or an a a classic full
[27:17] stack build. Okay, so uh between Node and Python at this level, there's no measurable difference. So, I went further to measure uh
[27:29] apps and like how apps scale on Lake base uh using Lake base. So, I used a complex query query that involves some Lake base part and some
[27:42] other custom uh tasks. And it went from for the smallest instance, the medium one, it was
[27:54] uh it was perfect for like a 100 QPS. And um QPS means queries per second, so it's probably enough for a couple hundred
[28:07] users. And then I went beyond and I tried the horizontal scaling in a private preview. And um that's an interesting part because I was
[28:19] able to go above with five large and uh instances with the same stack. Um I was able to go beyond like 8,000 QPS. But um
[28:32] it can handle way more, so um when it when I measured on my laptop, obviously that's a bottleneck here. You should measure it from um
[28:44] a cluster. We did it as well, so we went for cluster, spin up many instances and try to measure it. And we can say that uh
[28:57] it's is just a minimum number. It can go way beyond than a thousand QPS. So, that means several hundred or several thousand uh
[29:10] uh simultaneous users can be served with with horizontal scaling. And even more features are coming for the uh horizontal scaling, so you would probably able to do even more. But,
[29:23] that's available today, so you can do it right now. Um Now, about the agent care engineering setup, and this is a again a good
[29:36] example of the whole apps factory concept. Like, when you start using coding agents, you have two options. Like, build a Databricks apps and tell the agent to make no mistakes. That's option
[29:50] one. Or option two, put guardrails context around, and uh the agent can be kept perfectly on track. Databricks offers several setups for that, like the AI Dev Kit, the agent
[30:04] skills. And if you are using these setups in code code, it can actually run against the endpoint um you serve in your own Databricks workspace. Trace with that MLflow, so
[30:17] every interaction is traced and guarded inside your Databricks environment. >>
[30:30] happily pay as you go. But, to get serious, in many cases, this is actually important because not the token cost uh that matters the most, but the proper AI security and governance. Without
[30:44] that, you usually cannot even get started. And we With that, you can build low-code agentic apps. You can build scalable full-stack apps or even
[30:58] dynamic gen AI features or generative UI features in your application.
[31:10] Tailoring to internal operations also matter here. With Apps Factory, your schemas, your specs, your repos, your internal skills, and the fixes that um the fixes that you use use for typical
[31:24] issues. And plus your own safeguards like automated tests, static analysis, performance measurement, you can wire them into your agentic setup. And
[31:36] yeah, basically anything you can wire in anything that continuously validates the agent's performance. Pillar four, lifecycle and release management.
[31:49] We touched on provisioning already, but now let's to take a look at the whole life of an app that after it's created. Um as a father of two and a third on the way, I can say that getting started is
[32:02] not the hard part of parenting. So, like many things in the world, apps are the exact same. For example, in both cases, it is true that it is much easier to establish the
[32:14] best practices and the expectations in the beginning than to try than trying to correct them later. Um step one is about setting those
[32:26] expectations. By having a production readiness checklist for um uh releasing and operating apps. Uh I have one uh
[32:38] on the uh on the image, but uh enterprises usually also usually have one. And I honestly couldn't count how many times I've filled out these in my
[32:52] life. Um but there's uh great news. Actually, like usually like 80% of these checklists can be filled with uh um a check of that Databricks provides
[33:06] it. We don't have to care about. But as we saw with security, the re- remaining 20% uh is on us. There's nothing ground-breaking about um
[33:19] what CI/CD covers. Uh just to recall quickly, uh we make sure the developers are not deploying from their own machines. Uh that there's a um version that can be deployed
[33:32] in an isolated environment with continuous monitoring. In line with this, I don't think it's worth discussing uh the branching model either. It's the best best used by the um mature
[33:44] organization is standardized on. However, with lake base and Databricks uh workspaces, there are several dimensions that um um deserve attention
[33:58] when designing your pipeline. Uh say your promotion pass is dev, staging, prod. And in dev, the eternal pain is to getting started um or get identical say
[34:12] seed data very quickly to um to a test run, to a feature, to bug fix, or whatsoever. With lake base branching, you with and with that copy on write Postgres clones,
[34:26] you can provision provision these in blinks uh in a blink. And a And you actually create an application and the link ba- link base combo
[34:39] per feature, per user, or completely custom a completely custom environment for debugging something. And you spun it up on push and
[34:53] turn it down on merge or periodically. And after this, I usually recommend that we no longer branch, but instead deploy to an isolated staging uh and production
[35:06] environment. Testing follows the same logic. Uh apply the proven of approaches from your SDLC like uh unit, integration, and performance testing. But again, there
[35:19] are a few Databricks workspace uh specific things worth highlighting like you can run your Python unit tests in Databricks workspaces. And but probably even more expe- exciting, you can run
[35:33] Playwright uh tests in in Databricks as well. Deployed with Devs, for example, with a job. And so can you can run a an end-to-end test in a unified
[35:46] environment, which works nicely as a monitoring service as well. And if you haven't had enough GitHub links, uh there's another one uh for an Playwright example as well.
[35:59] Uh Yeah, so since I said monitoring, the pillar five, the last pillar, is observability and cost tracking. Um let's unpack that quickly. If you don't
[36:11] want to or if you want to observe more than just the bill, if you don't want to be alerted by the user complaints. And um there's a set of questions
[36:23] uh we need to uh answer we need to be able to answer at any given moment like who used it, what happened, what failed, what was the latency, what did it cost.
[36:36] And to answer this, you collect many data points like service health, performance, usage, cost allocation right down to uh, agent quality equals. And
[36:48] the good news again that most of them is already collected by MLflow and Databricks automatically. Um, and of course next to collection you want alerting as well.
[37:01] But to actually get the answers it's not enough to tag every service service and collect parameters separately. You have to wire them together in one shared correlation context. And
[37:14] by the help of that correlation context, you can go from we have the logs to we have the answers. And for cost tracking and observability, there are several built-in Databricks
[37:26] interfaces. Some landed just recently, but let let me give you two ideas or concept if you um, if you if you want to set it up for yourself.
[37:39] The first option is to create your own app like a fleet of a fleet view of the apps, insights, alerts, security scans or even a single like scanning job that just quickly sends
[37:52] uh, checks if there is a package used with a security risk or if all the apps are having the um, it's health their health
[38:04] check properly. And um, the second one is even simpler. You just set up an EIBI dashboards in minutes uh, on the correlation context that you
[38:16] created um, plus a Genie companion Genie space where you can ask the questions like which app has the highest AI spend this week or
[38:29] where's the slowest endpoint or whatever. And of course, these two will work the best combined, like the app for incident triage and the genie for ad hoc questions.
[38:42] And that's the end of the uh Yeah. Mhm. Okay, the So, the question is how can we merge the uh Rap or use the Rap in in Databricks? Um
[38:55] Actually, I'm rather focusing on full stack and um and production deliveries, so I'm not really familiar with the app kit approach, but yeah. Yeah, let's talk about it after we I I quickly finish and
[39:08] then we can somewhere here like talk about this, okay? Uh so, that's the end of the apps factory tour. Uh thanks for uh sticking with some 50 sounds later, but like let's just quickly end with three
[39:21] takeaways. Um layer one, the Databricks apps is the foundation for productivity. Um the layer two is the Layer two is the apps factory that uh
[39:34] puts the uh acceleration in control. And three, um engine tick engineering puts the whole thing into the AI gear, but with app sec apps factory, it stays grounded,
[39:46] governed, and controlled. And if you want to set up your own apps factory, it takes like three easy steps. Uh a a quick review analyzing the current maturity gaps risk, then it
[39:58] continues with uh a customized build um of the demonstrated template setups and processes, and finally an enablement that we make sure that the adoption of
[40:10] apps factory actually sticks and can be sustained. Um Leave the slide on a minute. Uh We will be here with this funky green
[40:24] shirt I have with me so we are happy to show you in details. Um and yeah one last task, please fill the surveys.
[40:36] Uh Thank you so much everyone. Uh I wish you to make the most out of this summit. My contact details are up there and I would be delighted to keep in touch. Thank you. >>

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.