Technical Deep Dive: Architecting Production-Ready Data & AI Apps

Summary

• This video provides a technical deep dive into architecting production-ready applications on Databricks Apps, covering framework choices between Python (Streamlit, Gradio) and full-stack JavaScript/TypeScript, authentication via Service Principals and On-Behalf-Of tokens, and CI/CD deployment with Databricks Asset Bundles.
• Lakebase integrates into Databricks Apps for OLTP state management with database branching support, while MCP servers and AI agents can be embedded directly into applications to enable intelligent, interactive workflows.
• Enterprise observability is implemented using OpenTelemetry for distributed tracing and app telemetry, and the roadmap includes serverless pricing improvements, mobile support, and a Genie App Builder for low-code application creation.

Technical Deep Dive: Architecting Production-Ready Data & AI Apps

Organizations are moving beyond simple dashboards to interactive, secure Data & AI applications built directly where their data lives. this video provides a technical deep dive into Databricks Apps, exploring how to transform complex AI logic into production-ready business tools. We will cover the essential architectural choices for developers, including a comparison of Pythonic frameworks like Streamlit and Gradio versus full-stack JS/TS implementations. The discussion will focus on the end-to-end development lifecycle, teaching you how to master authentication via Service Principals and On-Behalf-Of (OBO) tokens, and how to implement robust production workflows using Databricks Asset Bundles (DABs). Additionally, we will share best practices for optimizing performance and scalability—such as using async operations—and ensuring enterprise-grade observability through diagnostic logging and audit trails
Talk By: Ivan Trusov, Lead Specialist Solutions Architect, Databricks ; Naïm Achahboun, Forward Deployed Engineer, Databricks ;

Chapters

• 00:00 Introduction
• 02:04 Why Databricks Apps: architecture overview and agenda
• 05:21 Security posture and app surfaces on Databricks
• 13:53 Framework choices: Python, JS/TS, and compiled back-ends
• 15:35 Authentication with Service Principals and OAuth
• 18:55 Lakebase for OLTP state and database branching in apps
• 21:29 Building APIs and back-end services with Databricks Apps
• 32:37 Integrating agents and MCP servers in apps
• 46:25 Automated testing strategies with dual-LLM patterns
• 52:32 CI/CD and deployment with Databricks Asset Bundles
• 59:58 Observability with OpenTelemetry and app telemetry
• 1:06:49 Roadmap: serverless pricing, mobile, and Genie App Builder

FAQs

What framework options are available for building Databricks Apps?

Developers can choose between Python-based frameworks like Streamlit and Gradio for rapid prototyping, or full-stack JavaScript/TypeScript implementations for more complex production applications. Compiled backend services are also supported, giving teams flexibility to use the languages and frameworks they are most comfortable with.

How is authentication handled in Databricks Apps for secure data access?

Databricks Apps support authentication through Service Principals using OAuth flows. On-Behalf-Of tokens allow applications to act on behalf of end users when accessing Databricks resources, ensuring that data access is properly attributed and governed through Unity Catalog's fine-grained permission model rather than running everything under a single service account.

How does Lakebase fit into Databricks Apps for stateful workloads?

Lakebase — Databricks' managed PostgreSQL OLTP service — can be used as a state store within Databricks Apps for low-latency transactional data such as user preferences, application sessions, or workflow state. It also supports database branching, which enables safe development and testing of schema changes without affecting the production database.

How are Databricks Apps deployed and monitored at scale?

Databricks Asset Bundles provide the recommended CI/CD pattern for Databricks Apps, enabling automated deployment across environments with version control. OpenTelemetry integration provides distributed tracing and app-level telemetry for full observability, and dual-LLM testing patterns are also discussed for automated quality assurance of AI-powered application features.

Full transcript

[00:08] I'm pleased to welcome everybody today. Uh we are going to go on a deep dive into our datab bricks apps. An astonishing part of the datab bricks platform that I have started working with since the moment of the private
[00:20] preview and you know since then it never ceased to amaze me with what we can do there. Um, one thing, uh, both me and Naim, we're going to do some forwardlooking statements. Please take
[00:32] that. Yes, guys. What's happening? >> You cannot hear me. >> One, two, three, four, five. Should I be louder? >> All right, I can be really loud. This is
[00:45] not a problem. Can you hear me now? Well, and loud. Beautiful. All right, guys. So, one thing before we start is the forwardlooking statement. an important thing for all of you. You know, we're going to also talk a little
[00:58] bit about the road map. It is something anticipated. So, please take it uh in that form. Uh good. So, let me then introduce you to your hosts of today and
[01:11] uh I'm going to introduce you first of all to my brilliant colleague Naim. He is a forward deployed engineer at data bricks. Naim would you mind a couple of words? >> Hey everyone, nice to meet all of you. Uh thanks for joining our presentation
[01:23] on apps today. Uh looking forward to sharing more. Uh thanks Ian. Turn back over to you. >> Thank you. Uh and my name is Ivan Joseph. I'm a lead specialist solutions architect in the data bricks team. I was actually leading the uh ops 2025 deep
[01:38] dive as well as this one today. So you know that would be quite interesting to see right. Um, one thing we want from you guys, please after you have watched
[01:50] our today's presentation, if you like it or you have criticism, uh, please drop a drop a feedback for us, fill out the survey, let us know what can be better. This allows us to provide the most relevant content for you. All right,
[02:04] good. So then today we're talking about architecting production ready data and AI applications. And when we're talking about the architecture, it is what it is
[02:18] a cohesive view on a certain object in physical building it would be like an actual building an office building or something like this. But when it comes to it, you know, general data and AI
[02:32] developments, cohesive architecture plays also a very important role. Why so? because the traces of the architecture of good and bad technical decisions they leave through the systems
[02:45] that are staying with us. So our agenda of today is to make it as cohesive as possible and you know cover as much as possible on the topic of
[02:57] datab bricks apps specifically. Now important thing apps touch multiple different data brick surfaces when you work with them and this is expected. We will not be able to deep dive on each of them but I urge you to take a look at
[03:10] other sessions especially the agents one where some of the topics are opened up in a little bit you know more detail for you practically we're going to start with you know just baseline introduction then we're going to go into the
[03:22] frameworks and tooling and from there we will go into the integrations then as soon as we integrated everything into our app we want to make it a beautiful agent then we're going to talk a little bit about how to develop the
[03:35] apps, you know, how to test what is happening inside them. Then we deploy them and then finally, you know, we're going to take a look at what is coming from the data bricks platform in the upcoming uh in upcoming year or so.
[03:49] Good. So, let's start from the introduction piece. Um on a very very high level, uh let's talk about the what are data and AI applications. And what is very important is that practically we
[04:03] know applications nowadays as interactive humanoriented interfaces that are capable of performing certain actions and these actions we usually call business logic. Now what is very
[04:15] important about this is that when we're talking about data and AI applications specifically these applications are usually based on either supplied or they let the data get into the system.
[04:28] Another scenario is when we plug in wire in some LLM and AI capabilities into the application and as you can see most of the modern applications are already data in the applications right good but there
[04:42] is a problem right if there was no problem we won't be standing here right the problem is that if you take a look at like you know the existing ways of building data and AI applications outside of the data bricks platform you will see that there are three main
[04:55] problems from the business perspective First things first, it is complex. You need to understand a lot of concepts including physical layer up to the network layer up to CI/CD and deployment just to run an application should be
[05:08] simpler. Second thing, the complexity increases the time to deliver. You need more people, more connectivities and so on and so on and so forth. And then the third thing is especially valid in the age of you know AI and LM generated code
[05:21] is the security posture of the applications that have been built. So at data bricks we're looking at this and we're also looking at this thing. So take a look this is from 2025. If you
[05:33] want to be a full stack developer you need to do 37 steps. Just think about the number. First you need to understand you know how to write front end HTML CSS JavaScript you know things like that. After that it's not we are not there
[05:47] yet. You also need a proper back end connectivity to the database permission control and so on and so forth. Then we only come to the topic where we actually deploy the product of our work. You know when you think about CI/CD the
[06:00] underlying technical infrastructure and all of this raises just one reaction. All right. But you can tell me Ivan this slide is from 2025. I've seen it. Now we
[06:13] are in 2026 which means we can just use AI right? We can like you know we can forget about all of these complexities and just use AI to some extent. The problem is that even if you vibe code
[06:25] everything, you still have a whole lot of things you need to figure out because I mean you can hand over them to an agent but they are really easy to get done wrong and if you don't control it you know you will run into a lot of problems you will run into scaling
[06:38] problems you know potential security and authentication blocks uh you also need to understand that like you know there is a database that usually powers the application application state how do you observe what has been deployed let's
[06:50] assume it is working after a VIP coding session but how do I check what exactly is happening there right then I also need to understand how can I validate who was using the application and as well as I need to think about you know
[07:02] long-term infrastructure packages and containers so the good thing is that with data bricks we're looking at this under the following angle on one side we want to provide you with a platform that can be customized to your requirements
[07:16] on another side for citizen developers the platform can be simple enough and because we are already in the data ecosystem and data bricks provides best-in-class data ecosystem. We can connect the business blocks of
[07:29] applications into the data and make this process almost flawless and you know really nice and easily integrable with one to another. Now um I wanted to start
[07:41] off with you know something interesting here. So let me take a look just at the real time solar array visualization. There we go. I hope you can see my screen right now. So what is happening here as you can see in 3D this is
[07:55] written in data bricks apps in under I don't know in under 10,000 tokens. This is real time data that is collected by this deep space climate observatory and it shows the solar array so solar winds
[08:09] uh that are flowing towards the planet earth. Don't worry nothing bad will happen. This is a standard process right and we can see the trajectories of them and practically under the hood of this we have what it's data bricks up that
[08:22] shows you this 3D visualization in a nice way the data is coming in real time from uh from a stream uh it's official open openly available API and you know
[08:34] then we can quickly visualize this from a delta table so just wanted to show you how much of the potential and capabilities app bring to you if you take a look at them from the perspective
[08:46] of the domain that is interesting for you. Right? So back to the topic this is all cool but the question is how do I build an application? How do I do this effectively? How can I how can I
[08:58] make it? And let's talk a little bit about the actual frameworks and tooling that we're going to use to make things work. Um well it's again 2026. So my favorite approach is this one. I
[09:11] really love this slide to be honest. So you you know you warm up and then you go into your favorite chat interface, build an awesome app, make no mistakes. The problem here is not for the formulation per se. It is that we didn't give the
[09:24] agent enough context to do it effectively. But they don't know what means awesome and they don't know what means a mistake like you know. So we see this trend in the following way.
[09:37] The world has changed and it changed in the in the following direction. On one side we have a lot of new people who are citizen developers. They may not have any experience with writing code on one side but it's not a bad thing. They are
[09:51] using agent as a tool to deliver a certain result. They are not verifying the logic of the code. They are verifying that the application is running and working. On another side we have seasoned engineers. For them agent is only an assistant. It's not a
[10:04] decision maker. Right? I am making my decision by looking at the code, validating the codebase and checking that. And seasoned engineers are usually quite opinionated about the codebase. So here is the question. What is your
[10:16] favorite programming language guys in the recent days? Python. Anybody? There we go. Opinionation. How about JavaScript or TypeScript for that matter? All right. We also have some opinionation here. And Rust, of course.
[10:29] >> Okay, I'm alone in the room. That's not a problem at all. >> Okay, that's cool. Good. So the thing is that if you are a you know a citizen developer you don't know much about all these building things but you want to
[10:42] understand and you know you want to build you want to deliver to be able to make apps work and then in this case the today announced Genie app builder is the interface for you. It is coming soon and you know if you have interest already
[10:55] express your interest to your account executives. So we know about that practically it is a prompt convenient fast way to develop an application but importantly this development goes in context of your organization because
[11:08] Genie is powering the whole process. But you may ask me Ivan this generated code does it like follow any framework? Is it like readable or you just generating you know plain text HTMLs? Well, of course,
[11:21] we are not. Under the hood of this, if you are an engineer, you will see AppKit. So, AppKit, I urge you all to check out the uh the GitHub page. Appetit is what it is an opinionated
[11:33] framework of written in React and NodeJS. And what is very important is that it comes with a readytouse plug-in ecosystem. So you can you know work with queries with lake base with DBCSQL with
[11:47] agents without writing this glue code to make the services work together. I mean it's not that much of a glue code in the end but we made this flawless and we tested this at scale and most importantly of course this comes with
[11:59] necessary cloud skills and any other agent skills for that matter. So not only cloud so you will be able to develop it effectively and you know read the codebase in a clean way. All right,
[12:11] good. So, uh, however, even if you guys do not prefer anything of this and you know you have your own approach to this, still not a problem. Uh, any framework that you are using can be used with data
[12:24] bricks, right? So, any client, any uh any set of skills and so on and so forth. And we provide these skills. You can install them literally with one CLI command and use it with any agent of
[12:36] your choice. Not you know just the uh not just genie app builder you know if you are opinionated about your stack of white coding you also can do this. It wouldn't be a problem. Um a very
[12:48] frequent scenario that we see is this approach. So people say all right I know Python very well. I'm not very good at front end. So I'm just going to vip code the front end because that's something I visually validate. you know, I can see that the button is where it needs to be.
[13:01] And the back end I'm going to write in Python because I know Python like the most widely distributed language nowadays. So this approach works very well on apps. What you do is that you take your front end, write it, compile
[13:14] it into set of static files and serve it alongside with your application. The standard tool of choice is fast API. And of course, this works with all of the API protocols you can think of like curl, graphql, uh for agents, MCP and
[13:28] A2A, but we're going to talk about that a little bit later. All right, one more thing. Uh if we we see this question quite frequently recently like all right, I have an .NET application, can I
[13:40] run it on data bricks apps? I have a Go application, can I run it on data bricks apps? My team prefers Java. Can we run Java? The answer is actually yes. Here's the thing. Apps by default come with a runtime for interpretable languages. So
[13:53] JavaScript, Python. But any language that can be compiled can be compiled into an executable executable can be executed on data bricks apps. This is that simple, right? Uh so here is an example. If uh in Axum for example, you
[14:07] can write a server and then you know just build it and run as an executable as a binary on datab bricks apps. This will work flawlessly. All right. So that's all good and you
[14:19] know that's all technical capabilities but if we deep dive one step the first and the baseline question is how can I authenticate the actual users? How can I make sure that I'm providing access securely and uh here's the thing that a
[14:32] lot of people sometimes get wrong. So I wanted to clarify that really well. First things first every time when you create an application there is a default service principle. Service principle does not mean it's a workspace administrator or anything like this.
[14:45] service principle is just a technical entity, right? It doesn't have admin privileges or anything like this. It cannot it cannot go over your user privileges and so on and so forth. And it is usually used to perform actions
[14:58] that are outside of user context like let's say listing jobs or listing clusters and so on and so forth. At the moment when you need to um you know when you need to do something as the user of
[15:10] your application for example read a table or start a job or something like this you will use the user identity to do this. So how the user identity works real quick and by the way user identity
[15:23] and the source principal identity can coexist inside the same app. One does not exclude the other. They can be like inside the same application simultaneously. So user authentication works really simple in fact every time when we
[15:35] receive a request it goes for the datab bricks control plane. Now control plane validates that this user is exactly the identity that is coming with and then we can generate a token and pass this token
[15:47] into your application in the form of a header and now you can use this header to perform actions on behalf of the given user. Right? So this is a very important kind of piece in terms of how these things are organized and
[15:59] implemented. And of course, AppKit and Genia Builder know about this. So, you know, they also can efficiently use uh the uh use the user authentication. All right. Um if you're using the databicks
[16:13] SDK, here's a quick example in Python. I will not go over this, but practically it is, you know, you get the token, you initialize the workspace client, and using this workspace client, you can do whatever is need, whatever needs to be
[16:25] done. All right. So, let's assume that we're good on the tooling. We have full understanding that we can write applications in all languages. We also have a UI capability to build an applications easily. But app itself
[16:38] without any connectivity is just a shiny, you know, static landing page. How do I connect data and AI services? I need an expert on this. Naim, could you tell us a little bit? >> Thanks. Thanks, Ivan. Um, so in this
[16:50] section, guys, I want to talk about how you can connect data bricks apps to the different services within data bricks. uh eventually we'll zoom in to a particular service which is lakebase um but I want to make sure that I make
[17:03] the point that apps are very very well are tightly integrated with all other services within the data bricks platform right often if you are building apps on an external platform right let's say another hosting option this will lie
[17:16] upon you right you have to use either the API or SDK you have to do a lot of boilerplate coding whereas if you're using data bricks apps this call comes baked in um Most of the time if you are more of a UI person right you can
[17:28] register these resources directly in the UI or you can provision them using terraform or data bricks asset bundles because of the time I want to focus on one particular resource that we see a lot which is lakebase um particularly
[17:41] how we how you can yeah use that with apps effectively how you can scale it effectively that's going to be the core focus of this segment
[17:53] now before starting into and diving into how you connect lakebase to an app I want to talk about when should you use lakebased with your application and I think primarily you know as we've seen the announcements uh during the keynote with Raiden there's a lot of engine
[18:05] possibilities nowadays on data bricks um when do you pick lakebase now in essence what you can remember is whenever you're doing any type of transactional processing which means you're modifying
[18:17] single rows right either reading them or updating them that's where lakebase is a a good contender um Now you usually you would also use lickbase if you're striving for very very low latencies meaning every time a user refreshes the
[18:31] page you want to fetch their username or you want to fetch um let's say their their actual name and display that right if you were to use data brick SQL you would incur a latency penalty of at least let's say half a second whereas
[18:43] lakebase that's not the case I think the the nicest thing that lakebase offers versus any other traditional OLTP database system uh is branching right And for those that haven't heard of
[18:55] branching, it's essentially the concept where in Lakebase we can take an existing database and we can create a direct let's say clone of it that we can fully alter, right? So we can do changes to its schema to the tables. Uh we can
[19:08] remove all the rows without affecting the actual database. And this is a nice characteristic to have especially when you're developing right in a team. Instead of having to provision test databases for every single team member, you can create these, let's say,
[19:21] branches that are virtual very quickly for each PR and when you're done and you've merged it, you just destroy it. Um,
[19:33] I think uh on the how, right? So suppose you've identified Lakebase is the right fit for our workload. Um, there's there's a very easy way in the UI, right? If you want to use the UI, you can see all of the lakebased instances that are provisioned within your workspace and you can attach it to the app. uh automatically the app service
[19:46] principle that Ivan just discussed will be granted a role on the lakebase instance so they can interact with it. Um now I do mention I call out on the slide that even if your service principle is allowed to use the database
[19:59] that does not mean it's allowed to use all of the schemas and tables within it. So you have to execute the proper let's say grants right within Postgress it's just it's regular Postgress in that sense so that the service principle can reach all of the tables that you want it
[20:12] to reach. Now, of course, if you don't want to use the UI, you can also do a full deploy using asset bundles or Terraform. Both are possible.
[20:26] Now, a lot of times, and uh let's say beyond actual visual apps, there's also a large category of of nonvisual or let's say apps that are consumed by third parties or by other systems. And I want to emphasize that that is actually also a possibility on data bricks. So,
[20:38] when we when we talk about apps, we're also implicitly talking about any type of API, right? that is HTTP based where maybe you want to serve JSON or you want to serve XML. It really doesn't matter. A very simple example here on the left
[20:50] where we just using a very simple fast API uh scaffold for an items object. Now the the nice thing again when you're building APIs on data bricks apps you benefit from the same authentication
[21:02] that Ivan just discussed which means you can use the service principle or you can use the O token that is inherited or given by the actual user calling the API. And this allows for again uh let's
[21:14] say rich guard rails uh when you for example want to make sure that a certain customer calling your API can only see the records in uni catalog that belong to that customer.
[21:29] Great. Now before everyone starts building all sorts of APIs on apps uh I think I also want to discuss the other options you have um before before you actually look at building the API on apps. Right? There's many different use
[21:41] cases where you could look into an API and there's many flavors let's say that data bricks offers nowadays. Um the first flavor is you you have data that you have synced from your lakehouse into your lakebase instance and you want to
[21:53] provide this data to let's say thirdparty stakeholders or other folks within your business. If you have no business logic beyond simply serving data from lakebase you do not need to build an API in apps rightbase has
[22:06] something called the data API. It's it's a postgress compatible API interface which means you can have queries made to Postgress over HTTP. Um so if if that's your use case, use a data API. Second
[22:20] point that I will want to understand or talk about is when you're actually serving machine learning features, right? So you have computed a a bunch of features that are relevant to a model. Maybe the model is hosted on data bricks. If it is, forget this part. You
[22:33] do not need it. It's natively built in. But if you're hosting your model elsewhere, um you don't need the app to sit in between, let's say, the feature store and the model calling it. We have something called a feature serving endpoint which can serve these features
[22:46] to any model downstream. Now second or third category is mainly when when you actually running a machine learning model right you could technically put it into an app it's not recommended right agents definitely right agents apps is
[23:00] the right place to be but for any type of classical machine learning model maybe even maybe it's GPU accelerated even you would rely on a classic model serving endpoint for that deployment
[23:15] great now suppose we we decided apps is the right place to be and now we have an influx of users users using our application. How are we going to make sure that our app remains well and alive and that it can handle all of the load we throw at it? Um so nowadays data bricks provides essentially two options
[23:28] to provide scalability. Um the first one is vertical scaling and vertical scaling simply means we have a certain instance and we give it more cores and more RAM. Um, now the most important thing is when
[23:41] you look at or try choose to vertically scale your application is that your app is actually utilizing the cores that you're giving it. Right? If your app is single threaded, meaning it's actually only relying on a single core, even if I
[23:55] double it or triple the amount of cores, my app is not going to become more performant. Now the other scaling form which is currently in beta at the moment so you can talk to your account executive you want if you want access is is horizontal scaling where essentially
[24:08] we simply replicate the app into different instances and we load balance all of it traffic and the nice thing about this on apps is we we have a concept which is session aware uh sounds
[24:20] fancy essentially it means that whenever a user makes a request we tie that user to a specific instance and we try and make all requests of that user hit the instance. Now what that translates to
[24:32] practically is that you can store user data in memory in the instance and you can rely on it that it will often reach that inmemory state again. It's not a hard guarantee though when you have a lot of users coming in you might have to
[24:44] shuffle. Great. So looking beyond uh just let's say scaling up the compute there's other ways to think about scaling a data bricks app and this is mostly on some I
[24:56] would say high level tips you can use to judge whether your code is optimized um I think mostly for for most applications or let's say IO bound applications which means we're doing a lot of networking calls and we're calling to databases or
[25:09] other services um you should prefer writing asynchronous code that simply means that whenever we have a worker right that's actually maybe let's say it's making a call to a database it's not going to wait for the database to
[25:21] respond but rather the moment the call is made that worker is going to start working on other stuff so that's a nice characteristic we would like our app to have um second point is is choose your framework wisely right there's many
[25:33] frameworks right I would say too many to even list all of them um but each framework has different performance characteristics some make it very easy to write performant code some make it more difficult so when you're starting your project and you have freedom of
[25:46] choice Right? Look at maybe do a napkin calculation. You know, how many how many users do I expect? What's the load profile going to be? And and let that weigh into the decision you make uh to pick your framework. Now, the third one, which is actually the most important
[25:58] one, um is you can have the data bricks app do a lot of things, right? You can have it maybe even try and fetch things from a document or you can have it call lots of APIs that are maybe not necessary to be called within the
[26:11] request response cycle. Um but the third point basically says try and delegate actions that should not be in the app which means there's a lot of other compute types within data bricks right let's say job compute or model serving
[26:23] endpoints try and push as much work as you can to those other compute types so that the app itself is free to let's say serve user requests um if you do that well then actually I think even a small
[26:36] app instance can handle a lot of load Great. So what we see a lot is that most apps actually also come with a lakebase instance. So even if we have scaled our
[26:49] app perfectly uh we need to make sure that our database itself is also scaled up properly. Um but let me start by saying that even a single node lakebase instance is very capable. Uh and so the
[27:01] scale that we're talking here is when you have let's say a really significant amount of users let's say order of magnitude tens of thousands of of users using your app. Um I've split the section into two um portions. The first
[27:15] one will talk about read traffic and the other one we'll talk about right traffic. Um there's a yeah peculiarity that we have to deal with. Um, now the easiest way to scale Lakebase traffic is to make use of something called read
[27:28] replicas, right? Essentially what that uh entails is LakeBase has a primary instance that writes a whole bunch of logs containing all of its updates and those logs are then sent over to all of the read replicas that you can
[27:40] provision. Um, nice thing about Lakebase, we're not actually copying the data. It's still one source, right, in object storage that is served to all of the read replicas. Um, and this is very scalable. you can add I think even
[27:52] upwards of 12 if you reach out to your account team probably more and then you can handle I would say a lot of read traffic the second point is with regards to those replicas right suppose we have decided to start using read replicas
[28:06] it's important to rightsize them and what I mean by that is linkbase has autoscaling functionality right where we can specify a minimum capacity unit and a maximum and then it will autoscale in between um it's important to pick that
[28:19] minimum Well, um, and usually this this kind of is inferred from the data set size. If you look at how Lakebase works, right? Lakebase tries to aggressively cage all of the data that it that it
[28:32] can. It's it's something called the working set. Now, if you provision the minimum CU to be something that is smaller than your working set, you are forcing the instance to constantly go back to object storage to fetch the
[28:45] relevant information. That usually harms your performance, right? It adds latency. So the easiest way is to do basically napkin calculation. How much data do I have in my link base instance and use that to guide the decision on
[28:57] the minimum capacity unit that you actually need. Um now the third one is actually when you're trying to do very large full table scans or aggregate queries where lake base is not a good
[29:09] fit. Um, and I would say this is somewhere where this when you're in this category of workloads, you can look at doing offloading, which basically means we take the data we have in Lakebase and we sync it back to the lakehouse and we
[29:21] rely on data brick SQL. Uh, with the announcements of Raiden this week, you can also look at actually using RAM potentially in the future uh, to handle these workloads where you're you essentially doing big aggregate
[29:33] operations that are not a good fit for lakebase. Great. Now with regards to write traffic um because lakebase is in the end a postgress database um there's no support
[29:46] for multi-writer nodes meaning in every database cluster let's call it that there can only be a single node that is responsible for the rights to avoid having conflicts. Um so the advice
[29:58] becomes relatively simple. If you want to scale your rights, you need to scale that node vertically. Meaning you need to grant more capacity units to it to make sure it can handle all of the right traffic. Um the second point is for
[30:12] really large deployments. You will not find yourself in this category easily. Um so meaning think of like cross region workloads where we have people from different regions all wanting to use the same app. uh it can sometimes be in the
[30:26] best interest of those users to shard the workload completely. And what I mean by that is if you um if you have let's say let's say we have um 2,000 concurrent users from each region we
[30:38] have some in Australia, some in uh the US. Uh it might be a good idea to split that workload into two separate databases. One is let's say the Australian database and one is the US database. Um, now what this unlocks
[30:51] essentially is when you shard on the logical key, you essentially gain two writers, meaning each of the separate database clusters can be used by those user groups and in the end you can aggregate the data for your analysis back into the lakehouse. Um, so you you
[31:05] can still do analysis across the entire data set. Um, now the easiest or the the quick win when you're scaling rights is to always make sure to add at least one read replica in because any read traffic
[31:17] that you might still be servicing will then be surfaced from the read replica and that just frees up the primary node to focus solely on read on writes.
[31:32] Amazing. So suppose you've now set up your data bricks app. It's connected to all of the services. How do you go to the next level? Right? How do you take the step from going to an app to an actual agent? Ivan is going to talk more about that. >> Great. Thank you so much, Naim. Yeah, of course, an agentic application cannot
[31:45] exist without a lake base and you know an infrastructure to host the agent itself. So I think name bridge it very well towards you know the topic of the agentic applications. Let's talk about that for a second from a theoretical perspective. Um first of all what is uh
[32:00] like you know we've talked about what is an application but what is an agent then in this perspective it's actually quite simple. So application is a unit of business logic has some input and output
[32:12] connected to data brick services and maybe connected to external services and from this perspective agents are nothing more than just a subclass of an application but they have the implementation specifics. So let's talk
[32:24] about that. Um, agentic applications, they usually contain certain business logic, but they are either powered by an LLM or powering the LLM with the context, which practically splits them
[32:37] into agents and MCPS. Take a look how this good works, right? So powered by LLM means an agent goes into uh provides data for an LLM is an MCP context. So uh they are specific because the logic may
[32:51] not be nondeterministic. You can easily test a crude application that updates the task status. Can you do the same with an agent? No, because the logic is nondeterministic. Second thing, agents require their own specific protocols like REST APIs for cruds. We also have
[33:05] MCP and A2A for agents. And what is mostly important, agent applications usually go and check and use multiple tools. They go and check into Slack and then into Gy and maybe into GitHub and
[33:19] maybe into something else and so on and so forth. Which means they also need a framework that is capable of orchestrating everything, calling the tools, retrieval memory on one side and they also need a proper infrastructure
[33:32] that help us to trace what is happening, collect the logs, collect the metrics and clearly understand what is happening within our agent. So let's talk about that part first and then we'll also talk
[33:44] about the MCPs. How do we build agents and data bricks ups? This is super simple. In fact, one is the user provider. So users and service principles coming from your identity provider and you grant them with access
[33:57] permissions to the application instance and they just go into the application instance. Nah, not exactly. I would prefer to route them through AI gateway. Why? Because AI gateway applies you allows you to apply guard rails at scale
[34:12] on all of the agents that you are working with not just one but many of them. It also provides you a registry of agents and you know you are for you can also enforce some certain limits and so on and so forth. Next step okay we have
[34:25] registered an agent and here we have it. We have an agent but the agent as I've just described is a system that you know in whichever framework you're writing it you still need several logical blocks. I split them into four context, memory,
[34:39] traces and uh general telemetry. So it means that we need to run an agent in a place that provides all of this. What a coincidence. Data bricks platform is exactly the place where you will run your agent. So how does that look like?
[34:53] First of all, let's talk about the connectivity to internal and external services. So MCP servers can be running on datab bricks can be outside of data bricks. Those who are running on data bricks are exactly like you know apps
[35:06] and naim we're going to talk about them and those who are external to datab bricks you want to access them securely and in a unified way across all of the users in this moment you will exactly use unity catalog connections because it
[35:19] allows you to uh provide uh certain MCP as a service with proper permission and o management next thing of course we don't like the agents that forget what we have wrote to them last day like you
[35:31] know so you're looking for a memory. Where do you persist the memory? There should be some fast scalable database, right? I know one. It's called plague base. Very good. Now, we also need to
[35:44] strictly control what is happening with the agent. And this is quite serious. No joke. Because you know when your agent said something wrong, you want to have full trace of this conversation. What was the input? What was the output? Why did we provide this output? Were
[35:57] guardrails applied? What was the decision taken at this moment in time? MLflow tracing is the place where you will run that well. You will handle the full capture and you will be able to review the agent behavior and this
[36:09] allows you to also have the loop of the feedback. Now finally agentic applications themselves when a lot of tools are called and so on and so forth you need to understand this chains of logic and the best way to understand
[36:21] these chains of logic when they are running in production is to properly collect ter telemetry and logs and this is exactly what apps provide you and I will be talking about the telemetry and login slightly later but for now let's
[36:33] talk a little bit about the box at the top the MCP servers right because they power the agents they provide the context so how would that work na back to you. >> Thanks, Ivan. Um, so maybe quick show of
[36:46] hands. Who has has built their own MCP server before? >> Few. Okay. Who has used an MCP server before? Okay. Yeah, that's a lot. Awesome. So, I think um I want to very quickly introduce it for the folks that
[36:59] haven't. Um, but think of MCP as a protocol that's specifically developed to help agents use and discover APIs, right? Whereas in the past we used to have APIs with with let's say specific
[37:13] endpoints, we used to have very very like explicit documentation containing lots of examples and the schema. The MCP essentially tries to combine these two things. Um now if you look at the uh things that it provides out of the box
[37:26] most of the basics are essentially the MCP server has a collection of tools. Think of these as actions that the agent can take using the server. uh whereas resources the other attribute are let's
[37:38] say things or information that the agent can fetch back from the MCP server. Now I think the the key thing to understand is why why do we need MCP servers when we can hook up all of these APIs and tools to the agent directly. um
[37:52] usually has to do with the fact that the agents still have a limited context window and when you give it access to let's say all of the downstream dependencies that you're abstracting away behind the MCP um you're forcing
[38:05] the agent to use a lot of its context to do let's say a lot of steps to get to the final result whereas if I had a properly designed MCP server let's say for ordering a pizza somewhere I can abstract all of the steps away let's say
[38:17] from finding a pizza joint to placing the order to waiting for the delivery into one action that's called order pizza. Um that's a basic example. I think the the nice thing about MCPs is that data bricks has uh first class
[38:30] support. So you can build MCP servers that are fully custom and host them on data bricks apps. Uh you can use any of the MCP libraries. In this example I show one using fast MCP. Uh note that
[38:42] the syntax here is highly simplified and likely to be correct. Now with regards to um the features that are supported again similar to APIs and apps MCPS also support OBO and the service principle
[38:55] off basically anything hosted on data bricks apps will support both types and the key thing when you create one is that you add MCP dash in front of the name and it's essentially used for
[39:07] discoverability within the platform. So it appears in all sorts of lists where you want to see and look at the MCP. Um to make this more visual, I've prepared a demo. Um and essentially what I'm going to show you is how we have a very
[39:20] very simple World Cup MCP server that I'm going to attach to Genie Code. Um for that I will move into my workspace and I'm currently on the application tab. I'm going to close this Genie tab
[39:33] aloing it already. Um, but I've got an app prepared here or an MCP server that uh essentially has loaded some fictional World Cup data uh and Genie Code. It's excellent at coding, but it knows very
[39:45] little about football. So, we're going to give it this MCP server. So, it's able to help me with my football match ideas. Um, now the way you would do that is you can click on the Genie Code icon up top. I'm going to create a new
[39:58] session. Uh, you can click on the three dots here and move to settings. Now then you can move all the way down and I should find it. Oh, it's up there. Uh so you see already here I've added my MCP
[40:11] server in but suppose it was not there. I can click on add server and then you see a whole list of options that you can add to Genie code. Uh in particular all of those that are um let's say data
[40:23] bricks apps specific or any MCP that you're hosting on data bricks apps will appear in this list. Um I won't add it again because it's already there. Uh now the nice thing is uh I can basically now start talking to Genie code and I'm
[40:36] going to ask it whether you know Morocco is going to win the World Cup. I'm very interested. Um is win and I'm typing with one finger so bear
[40:49] with me. Yes. Um now what you're going to see is that Genie is probably going to realize that it needs to use the the Roka MCP server. There we go. So, it has realized that I have a function in my MCP that it can use and
[41:02] I'm going to allow it to use it. And what's happening now is a genie code under the hood is it's calling my MCP server and it's going to fetch a whole bunch of historical um group data. This is all fictional by the way at the moment, but imagine it was attached to
[41:14] an actual football API. Then I can now from you know my own data bricks workspace while doing work stay up to date on whether Marco is going to win. Now I think it mentioned that it it had one win one draw. I don't know probably
[41:26] we're still at one draw at the moment. Um but this is the basic example I wanted to show. So I hope that in in your own applications that you're building or organizations if you have ideas for let's say complex actions that you want to embed or you want to expose
[41:39] to other users um using an MCP and exposing it either through Genieode or another coding assistant is a very yeah good way to do so. Amazing. Now when you start building
[41:53] these MCP servers there are let's say there are lots of tips you can give but there there's three things I want to uh highlight for today um and the first thing is that you want this server preferably you want it to be predictable
[42:06] and you want it to be super specific um mainly because LMS even the frontier ones tend to have a tendency to make mistakes right they will just hallucinate they will imagine things into the schema they'll give wrong types
[42:19] and you need to be basically quite strict in if something needs to be an integer you should fail on anything else even if it looks like an integer um so that the model can let's say adapt from
[42:31] it let's say you give a descriptive error back and then the model can fix itself and call the MCP correctly um the second point is that you should try and take into account any uh let's say um item potency that's a it's a fancy word
[42:44] it basically um means when you deal with a lot of retries suppose the model is stuck in some loop and it like calls the tool like 10 times instead of then ordering a pizza 10 times, you likely want to capture that. So you you cage
[42:58] some identifier for a few minutes and you make sure that you dduplicate. So you only do the action once. Um this is I would say more common best practice from software engineering, but it it applies to these LLMs because they can
[43:10] make mistakes, right? If the session was interrupted and then it starts again, it might call the tool again. Um now the third one has to do with any output that you generate from the MCP. Try and keep that as lean as possible. Right? Going
[43:23] back again at the fixed context window length. Um the more concise you can be uh the more context you can preserve. And you'll find that let's say the reason why we don't reuse APIs MCPS directly is because sometimes they just
[43:36] return a huge amount of of data whereas only let's say a small portion of the actual rows are relevant to the response. Um, so try and take that into account when building good MCP.
[43:50] When you when you're done building this MCP or when you're still in the process, you also want to make sure you can test it effectively. And that's why I'll continue in this section to discuss testing on data bricks apps not only on MCPS
[44:03] now just interested um to highlight that like I think with the the advent of now agentic coding uh the software development life cycle has changed a bit
[44:16] I don't think that the life cycle itself like that the stages have have changed or shuffled uh but the time spent in each stage has definitely shuffled and changed um I I would say that nowadays you will find that with with the AI
[44:29] coding assistant your implementation phase can be very very fast but the review and let's say testing phase become ever more critical whereas in the past if you wrote most of the code yourself right you were intimately familiar with it you would probably know
[44:41] the weak areas so basically the areas where you should write a lot of tests and now you're basically uh yeah you're you're blind on those weaknesses and so you have to have a very expansive test suite to catch anything that might be wrong. Um now I think um the main points
[44:57] that this part of the presentation focus on is how you can do that testing effectively right what's the a good mix but be sure to also spend time on the other stages that we're not going into because it's like it isn't in the end a
[45:09] sort of a flywheel right the the better you are at let's say a planning stage or an analysis stage um the easier also your testing plan is going to be right if I have a very good PRD then I know for example what my critical user
[45:21] journeys are in my application and I know where I should have a lot of tests so that I don't, let's say, fail the user on a critical journey. Great. So, when talking about testing, there's lots of ways. There's lots of
[45:34] methodologies. Uh, I like this triangle myself. Um, quickly starting at the bottom, a unit test is testing um just one specific piece of functionality, preferably as simple as possible whether
[45:47] that is correct. it is not touching anything else, any other function calls, any other services or dependencies. It's it's super isolated. Um, and it basically guarantees that this little piece of logic we have is correct. Um,
[46:00] second, when we go up the stack into integration testing, that's when we are testing already more services together. Um, so we're not focusing on a single unit, but we're focusing on several units and how they interact. uh and let's say the holy grail end to end
[46:13] testing is where we're we're essentially simulating a user of our application that is clicking through the UI and that is generating all sorts of maybe API calls in the back um yeah to basically simulate how our application would be
[46:25] used in production um I think from the perspective of today right in the past generating tests would take a lot of time it would be very very timeconuming and intensive and so you would need a
[46:37] lot of effort to do it nowadays you don't necessarily need to do that but I think you should still think critically about the tests you actually need right you can easily spin up an agent and have it like write 1 million tests for a function that adds to numbers um I think
[46:51] it's it's useless spend of your test testing compute um but what I would recommend is that you strive for a healthy mix uh in these buckets right so I'm not that big of a fan of code
[47:03] coverage I think code coverage can hide some issues right it's it's possible to have 100% coverage and still have poor tests written where they simply traverse the lines and they're not really testing.
[47:15] Um, but I do want to emphasize the final point which is make sure to leverage the new tech that we have and that's also the demo I want to show uh in how you can have agents build these tests for you and essentially give you more reli
[47:27] give you an insight into the reliability of your software in AI assisted way. Great. So this is the the demo part. Um, it is a a very simple app uh I've built.
[47:40] >> Zoom in a little bit. >> Oh, yeah. That's a good Thank you, Ivan. Let me go and I suck at zooming in on the Mac, but if you could help me. Yes, >> that's the teamwork. >> Oh, yes. Amazing. There we go. Thank you. Um, so essentially in this example,
[47:53] we're going to have an an agent battle. I've always wanted to do this at the presentation. Uh, but I'm going to have two agents. Uh, let's say one is a defender and one is an attacker. Um, and think of this as like an an adversarial
[48:05] pattern where one is going to try and generate a good test suite and the other one is going to act as like a critique of that test suite. Um, now what I'm doing here is I'm using two different models from different families and I
[48:18] would recommend that if you try and do something similar. The idea is I have this simple function. It calculates a mean on the left. We're going to be writing tests for that. Now in this example, the the mean function is incorrect, right? It's dividing by the
[48:31] length minus one. So we preferably don't get a fully green test suite or we have some degenerate case during the demo. I'll do three rounds, not four. Um, and I will give it a higher max. Let's do
[48:43] 20. Um, so we're gonna we're going to start the fight. Uh, essentially what's going to happen now is yeah, I'm going to scroll. Uh, but the defender model is like generating a test suite live for
[48:56] uh, this function. And now we had the red team, the attacker give feedback and essentially find a case where the test suite was weak. And so the defender again regenerated the test suite. And this essentially continues in like a
[49:09] cycle. The agents are battling each other and eventually there's a there's a winner. Yeah, round three is still in progress. Um now this is obviously an example, right? I would not recommend that you do this in an app, but you you
[49:21] incorporate it into uh maybe CI/CD, right? Into PR review. um it is a very effective way um to get a better test suite, right? If you just have a single LM generate the test suite, often it's
[49:33] okay. Um but it might have some issues whereas if you have this like cycle go back and forth like ping pong and you have a good objective uh it tends to give you yeah pretty good tests. Um now
[49:46] to be honest I haven't checked whether these tests are are solid but the the conceptually the principle stands is that having an adversarial pattern to generate things and using different model families uh is the way I would recommend uh writing tests for an
[49:58] application or any piece of software. I think that's going to be uh it from the demo side and we can now discuss to once you've tested your application
[50:10] right you have confidence that it's ready for your users how do you actually bring it to your users and that's where Evan is going to help us out >> got it thank you so much Na thank you so much for preparing a well- tested application that I can easily deploy right that would be the logic this is
[50:23] how teams should work right isn't it all right so uh let's talk quickly about this first of all let's talk about the basics like I know that People may get already tired of the slide, but I still love it because it shows the standard
[50:36] process of the um of the like you know deployment. The problem is that sometimes I'm coming into like into a situation I'm like all right guys but you're not following this. So I'm going to repeat this slide very quickly. Take
[50:49] the source build it validate that it works push it to the staging separate workspace separate app instance then it goes to production. Not the other way around. no just production that I'm going to fix it live and later. Don't do
[51:02] this. You're going to bring problems to yourself later. So, uh the
[51:15] integration, it's time to deploy. uh they are logically not the same because CI happens when you have new versions of your application and you are not yet sure if you want to release them as a pack or you're like testing it or just
[51:27] validating those are your uh feature branches in most cases and uh the easy thing to automate all of these things together is to use the declarative automation bundles is still yeah it's
[51:40] declarative automation bundles uh where you practically do it in the following way you describe in the YAML file What is your deployment pattern? Because apps rarely go alone. They usually have
[51:52] connected services to them and you may create these services if you own the whole application such as a database or you may refer to the existing services because they already exist and they were provided to you, right? However, the
[52:06] convenient thing is that whatever is described in the YAML file can be easily deployed with the data bricks bundles. And the good thing is you can have multiple targets. So you can deploy it to your staging workspace in your CI and
[52:19] you can deploy to your production in your CD pipeline. All right. And uh let's talk a little bit about this difference between the CI and CD. Of course, your application code base should live in Git. There is no other
[52:32] way of doing this, right? It should be there. Uh you need to use the data bricks asset bundles to define the application resources and the setup and then you use the CLI to trigger the action. So as bundles in the YAML file
[52:45] is the description language CLI is the way to trigger and then this um lays down nicely onto these differences between like you know CI and CD because your CI/CD provider like GitHub actions
[52:59] bit pipelines and so on and so forth. You practically have two of them. One is on push. You change something. You're pushing the codebase and you validating this with like your peers maybe second I
[53:11] review and so on and so forth and then you run the integration test after you have deployed the up to the staging workspace and when everything is all right you merge this into main. It leaves until you're ready for the next
[53:23] release. you're probably going to like botch several features in one release and at that moment in time you trigger the own release pipeline and at this moment in time you build the package deploy the new application version and
[53:35] put it into the data bricks production workspace. Here is a very interesting uh synergy because previously you know you may have seen some intermittent uh problems when you know an application is being deployed and the startup was not
[53:48] correct. We now with horizontal scaling don't let you do this. So we have the like this pattern sometimes called blue green deployment. You have a running version and until the new version has started we're going to keep the running
[54:00] version for you. So you know for the horizontal scaling this capability is also there. So you know you have a good user experience. All right in terms of the CI/CD tooling if we talk about
[54:12] Python specifically I really recommend you to forget about resistance of requirements.txt. it is just supported but you should use UV in like almost all of the scenarios. Second thing, you know, with the recent
[54:25] uh problems with like you know public registries, it's really recommended to have a self-hosted pipey or an npm registry and you know where you can host them on data bricks apps like seriously we have customers who are hosting their
[54:37] npm and pipey on data bricks apps think about this you have all of the access control in place very convenient so and of course in terms of the code base if you have a common library that is applied like you know in data pro
[54:49] processes and data pipelines and then your application logic and you know that part of this is reusable don't bake it into the app you know separate it make it a good refactoring you know slightly slide them from one another in terms of
[55:02] CI/CD as I've said CLI is the tool that executes certain steps and DABs are the way to describe your uh are the way to describe your deployment pattern and um
[55:16] one more thing uh sometimes people miss this if you are inside a corporate network where you know you cannot just publicly access your workspace and you will need to use the self-hosted runners. That's more for like you know platform administrators recommendation.
[55:31] All right, there is one more thing which is very convenient uh and uh it is for situations when you have a simpler application. Let's say you do not manage your dependencies. They are just provided to you. In this scenario, you
[55:43] can really deploy the application from the uh from the git repo directly. You don't need to build if you don't have any build step, right? uh the only thing you want to do is like okay this is the final and the current version of the
[55:55] application. I want you to pick it up from the main branch run it and here we go. This is also an approach and uh uh what you can do is that you also can enforce the git only deployment. So you
[56:07] can say the only way the code base gets into the application and we have a running application is to enforce it. So you know nobody can just do some local deployment and then you're thinking where is this code base come from? uh that there is this is an option that you
[56:20] can enable. All right. Uh let's talk now a little bit about the demo piece. So you know what I do love is uh demos during the large presentation that have
[56:32] some risk in it. Uh this is something that I do and this is the second year I'm doing this uh in the previous year as you know. I wanted to prepare a beautiful demo for you and I've launched it but here is a problem. The year is
[56:45] outdated. I'm very ashamed of this. Please sorry me. The good thing is that I can use CI/CD pipeline to quickly release a new version, you know, in in life. So, uh nothing bad is going to happen and I will be just all fine. So,
[56:59] I'm going to launch the deployment and while this is happening, I'm going to explain to you what the deployment is doing. So, let's uh take a look at this practically and in a very simple case. This is uh this is GitHub actions, but
[57:11] you r you really like you can use whatever you want, right? It can be uh any system that is acceptable within your environment. So what is happening is that first you just need to configure the environments and it is recommended to make the deployments through uh your
[57:26] uh through service principle. Second thing you know let's cach the NodeJS dependencies because we need them for tests and then finally we will do what we will install the dependencies. We
[57:38] will install the datab bricks CLI and we can run this command and as I've said so in this scenario I don't even need dabs because I don't have any dependencies. So I'm just using data bricks apps deploy but in in any like you know large
[57:51] scale real deployment most probably you're going to have uh you're going to have to have the like data bricks bundles deploy that like when you have multiple dependencies and so on and so forth. So what is happening now? What is
[58:04] happening run uh right now is that you know the application is ongoing through a deployment and I have updated the year successfully. So I can only hopefully think that in a couple of seconds we
[58:16] will get a new year. Beautiful. Right here we go. I've told you this is going to work. I love this risk. Um of course and by the way the application UI itself is built with our new appkit and uh we have prepared a beautiful documentation
[58:29] about how to use it. So you know guys check this out uh uh datab bricks uh upkit you can find it in Google and you will get straight to this page. All right. Uh, now let's talk a little bit
[58:41] about the next piece which is okay. My application is deployed and this is super convenient. Wait a second. Should I? Yeah, let me switch back. There we go. This was a demo instance. Now back
[58:54] to the presentation part. So our application is deployed and even the year is correct. Uh, next time I'll write a test using for that. Right. Uh the question is how can I monitor what's
[59:07] happening inside the app like how many requests per second are the users happy what is the latency and so on and so forth can I do this well of course you can uh first of all the most basic the
[59:19] most standard the most simplistic way to work with your application is to just go and check the logs it's really super simple you just get the application URL/logs and there you are you know um it's done this has some problems however
[59:32] this is real time logs and they are erased when the compute is stopped. So you know maybe sometimes quite inconvenient. Uh the second thing is that uh um you know kind of you
[59:44] sometimes want more analytical view not just search for the string but like group the logs maybe identify some have something that is happening maybe find some patterns and so on and so forth. So looking for more also one more thing is
[59:58] that sometimes you would like to understand who and from where was connecting to your application at this moment in time especially if you're using the datab bricks AI security framework you're going to use the audit
[60:10] logs because they're going to provide you information about who from where which IP which user agent was connecting to your application and this is super convenient because it's integrated into the access uh into the systems tables so
[60:23] you know you can just go uh build yourself a dashboard and you know have full control of the application visitors. All right, but as I've said sometimes we want more than just you know audit that somebody has logged. We
[60:36] want traces or like chains of events that were happening inside the application and the good thing is that from any application and with any framework you can have open telemetry.
[60:49] Um quick question who who does know what open telemetry is? All right, perfect. Then I'm just introducing to you something that is like know in our public preview and you may have asked yourself can data bricks do this? Yes,
[61:01] we can. Open telemetry is practically what it is a standardized protocol of collecting logs uh metrics and traces from your application. Uh logs are just
[61:14] textual blocks. Metrics are numbers that you can collect around the application surface like latency, how long is the database handling the request and so on and so forth. Traces are structured
[61:26] chains of events and you can like kind of add more and more traces along the line. So you can understand like user spent here this amount of time there there another amount of time and so on and so forth. So uh let me quickly show
[61:40] you how you can collect uh the hotel metrics from a fast API application. It's really um quite amusingly simple thing to do. So uh first of all we need to configure
[61:53] our application properly. So you know we can uh host the telemetry somewhere. Quite simple and quite easy. You take your application telemetry setting. You need to enable it in your workspace to
[62:06] the status enabled. And as soon as you have it there you will see this block in your app telemetry view. There you need to define three tables or you can just put it into a single schema if you don't want to customize the names. So it's
[62:19] going to be logs, metrics and traces. Exactly the objects that I was talking about. So you know the thing that you need to do can you do this through datab bricks asset bundles or through terraform? Yes, of course you can. Oh
[62:31] sorry declarative declarative automation models whatever. Yeah, so you can do this uh of course in the same YAML file. You can just take your application and describe there what is happening and you know it's going to work as expected. LLM
[62:44] agents are also knowledgeable about this and this creates a very interesting loop. You can automatically collect the logs metrics and traces into Unity catalog and tell your agent hey
[62:56] something is going wrong with my app. Uh the latency of the database is too large or I see from the logs that something wrong is happening. Can you feed this? Can you check what is happening? Think about how many options this opens up to you. You know from this moment in time
[63:09] even on a deployed application instance you can always check the full context of what is happening and you know let your agent work through it. So you don't need like to manually explain to the agent where is the problem. They can look it
[63:22] up themselves. This is a way of providing context to some extent. Um and of course sometimes you know I do not trust the agent. I trust my own eyes and I would like to validate what is happening there. And in this scenario,
[63:34] I'm going to build myself a dashboard. And because the data is systematically stored and actually with a very low latency, sometimes even less than 5 seconds from the event happening, I can
[63:46] validate and see what is happening within my application. So here for example, I'm collecting the HTTP request latency and what can I see is that most of the requests are handled within roughly 3 seconds, which is a good case
[64:00] for my application. But I also see that the difference between the P50 and P90 is very large. This means that my application is not working uniformly and maybe there is something I need to fix inside the application, you know, so all
[64:13] users get the same level of of user experience, right? So that all all routes are are routing fast enough. Um, of course, I can also calculate things like uh requests per second per each of
[64:26] the routes I'm working with. uh and uh this is also very helpful because uh usually application exposes the business logic and forms of the routes and you can see what do the users use the most.
[64:38] Do they say create more tasks or they pre prefer some other interfaces? Do they chat with the data or do they prefer to look at the dashboards? Such things you can only have if you fully
[64:50] trace you know the logical blocks of your application and that's exactly what we can do here right. Uh and of course of course the lock viewing sometimes just want to take a look at the logs. I mean all logs here are green because I
[65:03] was validating that application works but usually you know the first things first something is not working you get a message and what you can do is that you go here filter by severity into error and boom there you have your full
[65:16] analytical introspection into what is happening inside your application. It's also quite simple from this perspective. All right. So that would be my uh sorry let me switch back. Here we go. All
[65:31] right. So that would be the story about the hotel metrics from the fast API application. And if you ask me Ivan can we do the
[65:43] same thing for any other language would it be Java, JavaScript and so on and so forth. Of course yes. And if you ask me can appkit collect the metrics for us. Yes, there is a readyto-use plug-in. So even if you v code your application, you
[65:56] can still ask the you can still ask the agent like hey add metrics here and there and you will see them in your uh in your datab bricks uh unity catalog and that would allow you to work with the data. All right so we have talked
[66:10] about pretty much the whole cycle now right let's think about this. We started from what is an application. Then we showed you how you can deploy one, how you can develop one, how you can test it, and how we can observe what is
[66:23] happening. This seems quite cohesive to me to be honest. I think this is exactly what a deep dive should do. But now I want to know something about the future. Where are we heading to? And I need somebody who knows all of the secrets of
[66:35] the future. And then that's the road map. So this goes to name. Name. Can you tell us something? >> Thanks Ivan. Yes. for sure. Um, so the the future is looking bright luckily.
[66:49] Uh, I've taken three points from the road map that I really want to emphasize. Uh, if you've watched the keynote, then you already probably know what's coming. Uh, but I think the main point I wanted to emphasize is that we are launching app spaces soon. Um, and
[67:02] the main concept there is that it will provide a new governance boundary uh to allow more scalable adoption of apps. Right? So we've received lots of feedback from customers that you know we are we love apps. They're a great product, but we find it hard to roll it
[67:16] out in a safe way to let's say users that are non-technical, right? Someone might create a hund of them and leave them all running and maybe only use two or three. Um, now app spaces will make that pattern uh possible because all of
[67:28] those will be let's say serverless microVMs. So even if there are 100 and only three are used, you essentially not incur any cost for the idle ones. That's one of the primary uh reasons that it's being introduced. Um, but for those
[67:42] users that don't know how to build an app, we're also introducing another tool which is the Genie app builder. Uh, I think you might have seen already announced this morning already, but the key thing there is, um, we have lots of great partners already that provide a
[67:56] like VIP coding experience. If you have one of those, keep using them. They're great. If you do not, uh, but you have business users or citizen developers that you want to empower to build apps, that's why we're building, uh, the Genie app builder. It will be very easy. you
[68:09] can just uh essentially use prompts to build the application and deploy instantly into a space. Yeah, I've I've gotten the luxury of testing it myself last week. It was very interesting. Um the final point I wanted to mention is
[68:21] scale to zero. Uh this is tied to let's say all of these things all of these three points you can actually see as one big development essentially. Um and this is this is this is more to to help users with apps that do not have consistent
[68:34] usage every single day. Right? So if you have an app that's used once a month, maybe even once a year during yearly review, you can still keep that app in existence and it will only let's say spin up when you once you open it. Um yeah, there's lots of other things and
[68:47] hopefully we will be able to share more. So keep keep let's say data works on LinkedIn or any of the other socials to stay up to date on the apps road map. Now with regards to what we discussed, I'm going to ask Ivan to help us with a
[68:59] concise and good summary. >> Thank you so much. All right. So, as I've said now, we also know something about the future, but it was long 90 minutes. Thank you so much for making it here, guys. It's really good job. Now,
[69:25] energized to do something. So um first of all where can you use apps right now and where can you not right practically a year ago uh there was only one extra line on the one fit slide which is like
[69:39] hosting static content but now we also can do this with app spaces because you know it gets uh economically effective. So what you can do with apps nowadays is practically the whole richness of everything that comes towards the model
[69:52] uh towards the modern application building standard create uh create create read update applications agents chat bots uh business logic API services
[70:04] uh complex custom visualizations like the one I've started our presentation with and so on and so forth. You really can do practically everything except two small things. One is mobile applications. I mean it's not a simple
[70:17] thing and we haven't yet had much of the request towards that but you know if you have any use case for a mobile app uh please let us know. We would be really interested you know kind of to to size how would that could look like and work
[70:30] on our platform. And second thing, this one we know very well externally facing public applications that do not depend on your uh identity provisioning system like just any public user can walk in
[70:43] and start working on your application. That's something that we have uh I wouldn't say any specific dates. It's a forward-looking statement but that's something we definitely you know have in
[70:55] in our lists and that's something that we are actively thinking about. If you have a scenario where you would like to, you know, to go externally facing with your application, please let us know. All right, good. So from the business
[71:09] perspective, let's recap this, right? Agents, uh, sorry, apps are a product surface of data bricks. Data bricks is a large platform. It's capable of many things and apps is a very peculiar, very
[71:21] nicely user oriented product surface of it. Nowadays, year ago, this wasn't like fully 100% true, but nowadays it is scalable for any kind of the workload both with various both with vertical and
[71:34] the horizontal scaling. I personally know uh scenarios where there are literally thousands of real-time users on the data bricks apps inside the organization and it works flawlessly.
[71:46] Second thing, the apps are well governed and controllable and this is already something you know something that brings us very positive things. Next thing is if you're building an application, you have built-in observability and
[71:58] security. And of course, we come with some batteries included. So, you know, the upcoming Genie app builder will be capable of, you know, just providing simple textual interface into building the apps. But if you are a developer
[72:11] yourself, I really, you know, recommend you to take a look at AppKit and the skills that we provide because they really kind of improve your uh your aentic development story from the business perspective. uh if you're
[72:24] considering all right so it's great to you know to be able to build apps but uh what exactly are are my like my business use cases usually the business people know the use cases for the applications they usually thinking like ah it's going
[72:36] to be so hard to build and I urge you to try because actually on apps like I've seen a lot of times when business persona coming in swiping it out like oh wow that's actually going to work that is what there is no reason why it is not
[72:48] going to work right so it's going to work uh and therefore apps becoming a business driver. They're easy to build. They're easy to operate and you can really easily scale them out. So that's the second thing. And uh the most
[73:00] important part, right? Apps are an action surface, right? They allow you to extract business value from your data. That's something that I want you to keep in mind. Do not just build uh I mean of course if it's needed, you can build it
[73:14] uh like say reaggregational dashboard in apps. You can do this. No problem. You can do this. But since you have already building an application, you can bring a business. You can you can bring some
[73:26] business action into it. You can have a button that you know um the let's say don't just show me all of the orders. Uh add me a button where I can let's say recall a certain order or you know uh uh
[73:39] connect a manager who was working with it or something like this. So business actions inside the apps, right? And the same thing with agents because agents are all about doing an action. All right. So if there is one slide I want you to
[73:51] keep in mind after this whole presentation is this one. Datab bricks apps are a production ready data and AI application platform including agents as well. We think about three main
[74:05] personas. Citizen developers will get simplicity. The platform administrators will be able to control what they are doing because they have app spaces and in general like you know platform level
[74:18] guard rails around it and engineers can build applications in any language they prefer in any shape they prefer and in any in any form they prefer and all of this together means that the capability
[74:31] to build an application is absolutely endless. There is just one small thing is left. It's time to build. So I really wish you to build more and more of that. And if you want some extra resources on how to build them, here are some
[74:44] documentations uh some documentation links. You don't know how to do this at all, reach out to our databicks account team. Uh the links will be also under the YouTube video afterwards. So don't worry. Explore some
[74:56] samples on the application cookbook web page apps cookbook as well as in our public official documentation. Uh and with that one more thing please
[75:08] help us please uh let us know what was your opinion about our presentation please uh complete this survey afterwards and with that uh me and Naim we really want to thank you and it's
[75:20] time to build so let's build something thanks a

Learn more about the Databricks Data and AI platform.