Provisioning for the Agentic Era: How Databricks Built a Self-Serve Infrastructure Vending Machine

Summary

Databricks' Field Engineering Vending Machine (FEVM) delivers just-in-time, isolated workspaces on demand to over 7,000 field engineering and go-to-market staff without requiring tickets or shared admin access.
Built as a Databricks App using Terraform and MCP, FEVM supports both human engineers and AI agents as first-class consumers of provisioned environments, reflecting the shift to agentic workflows.
Automated lifecycle management handles environment cleanup after use, improving cost visibility and governance across thousands of concurrent users and agent runs.

Provisioning for the Agentic Era: How Databricks Built a Self-Serve Infrastructure Vending Machine

As Databricks' go-to-market organization grew past 7,000 people — and AI agents became first-class consumers of platform resources alongside human engineers — our field team ran into a familiar problem: shared demo environments couldn't keep up. Too many users needed admin-level access, platform limits became real constraints, and it was hard to see who was using what, whether that "who" was a person or an agent. In this video, we'll share how we addressed that by building the Field Engineering Vending Machine (FEVM), a Databricks App that gives every engineer — and every agent — just-in-time, isolated, and governed environments on demand. Instead of filing tickets or juggling shared workspaces, engineers describe what they're trying to do — build a demo, run a hackathon, reproduce an issue, spin up an agentic workflow — and FEVM delivers a fit-for-purpose environment in minutes, then cleans it up automatically when it's no longer needed. We'll show how this "vending machine" model has improved speed, control, and cost visibility for thousands of users and countless agent runs, and why building it as a Databricks App has become a blueprint for how we dogfood the platform internally — for the agentic era and beyond.
Talk By: Greg Wood, Lead SSA, Databricks ; Joel Thomas, Director, Databricks ;

Chapters

FAQs

What is the Field Engineering Vending Machine (FEVM)?

FEVM is a Databricks App built by the Databricks field engineering team that provides just-in-time, isolated, and governed workspace environments on demand. Engineers and AI agents describe their need—building a demo, running a hackathon, reproducing an issue—and FEVM provisions a fit-for-purpose environment in minutes, then automatically cleans it up when no longer needed.

Why did Databricks build a self-serve provisioning tool for its field team?

As Databricks' go-to-market organization grew past 7,000 people, shared demo environments could no longer keep up with demand. Too many users needed admin-level access and platform limits became real constraints, making it difficult to track who—whether a person or an AI agent—was using what.

What technologies power the FEVM architecture?

FEVM is built on Terraform for infrastructure provisioning, Databricks Apps for the user-facing interface, and MCP (Model Context Protocol) as the AI agent provisioning interface. This stack enables both human engineers and AI agents to request and receive environments through a unified, governed workflow.

How does FEVM support AI agents as infrastructure consumers?

FEVM treats AI agents as first-class consumers alongside human engineers, allowing agents to request and receive isolated environments through the MCP interface. This design reflects the broader shift toward agentic workflows and enables Databricks to dogfood its own platform for the agentic era.

Full transcript

[00:09] Hey everyone, welcome. Uh, I'm hoping this is your last session for the day. You all still have some energy left to, you know, power through one more session here. Uh, thank you for being here. Uh, my name is Joel Thomas and this is Greg Wood. Um I'm you know I lead our we're
[00:23] part of field engineering team uh at data bricks here and we one of the core functions that we do as part of our team is to build AI tooling and other internal tooling for our field
[00:36] engineering and broader go to market teams to be more efficient and this in particular you know we're going to be talking about um how we build some of the needs or capabilities that we built
[00:48] that came out of you know, not necessarily, hey, we had a little bit of foresight to do it. It's just like, hey, out of necessity because the agentic thing is going at a light
[01:00] speed and circumstantially, we just happened to build it and it kind of got a viral moment internally within data bricks. So, we're just going to be uh walking through our problem statement and other solutions that we built and
[01:13] how potentially you can also be inspired by it to build your own similar solutions as needed. and I'll let Greg to introduce himself. >> Hey, uh Greg Wood, like Joel said, uh part of FEM on Joel's team. Um you know,
[01:27] we're trying to evolve rapidly. Uh you know, over the past six months, I think six to 12 months, I think all of our roles have really, uh wildly evolved. Uh and so yeah, I don't think any of us
[01:40] could have imagined a year or two ago that we'd be here talking about this, but uh it's been really fun to do. So really excited to share this All right. So let's talk through like I
[01:52] mean like I said uh talking through the problem statement even before going in bit of context and history of the team or how we do internally at data bricks right so we you know you probably if
[02:04] you're a customer of data bricks you have solutions architect coming in and helping and their job is primarily to learn about data bricks prototype and demonstrate and showcase to customers
[02:17] and as part of that back you know Greg and I we've been here for 7 8 years here at Data Bricks. Back in the day, it was rather small. It was, you know, 50 80 people or so. We had some environments
[02:30] that was easy to manage in a different fashion. But fast forward today, combining with the field engineering as well as their, you know, counterparts with sales and other folks, that's about 7,000 people. So imagine 7,000 people
[02:46] trying to work in the same space. It just doesn't scale the way we originally had it. And that's kind of what led us to the, you know, some of the situations and other things. So if you kind of think about
[03:00] it, you know, back in the day, we had an environment where it has, you know, like I said, 70 people or 80 people, they are all coming in together and working where they have elevated access because
[03:12] they're all solutions architect. They all supposed to have in-depth knowledge of what they're trying to do. So it worked for a time and a place and it just you know had a lot of other
[03:24] challenges percolated over time again and again and it kind of went into the problem of like you know having technical debt compounding people stepping on each other like you know when they're trying to learn something
[03:37] or prototype something and demonstrate something for their customers you know a lot of other challenges that came in because literally everybody you know was an admin and then couple other challenges as well. You know, couple of,
[03:50] you know, I'll let Greg talk about that. >> Yeah. Uh, we really saw uh this thing break down um over the past even, you know, year and a half, two years. Um,
[04:03] you know, data bricks both as a company and as a technology platform just grew exponentially, right? So the the field GTM organization grew, you know, three
[04:15] times in uh in four years. And you know, if you go back to when we built a lot of this stuff when Joel and I had joined, we the whole company was maybe 500 people. So going from 500 to 12,000, uh
[04:27] you just really hit those scale problems that you can't gloss over by adding more capacity in a single environment. You have to move to a new paradigm. Uh and the other thing again like I said was
[04:39] the technology fundamentally changed uh back in you know 2020 2021 we were uh not even really thinking about the lakehouse as much as we were. Uh we were data lake Delta was pretty new was on
[04:53] the cusp of like being released. Uh nobody had thought about AI yet. Uh let alone uh the proliferation of like everybody has cloud everybody can launch everything they want and build an app.
[05:05] uh that just didn't exist. So, uh like Joel said, uh these systems started to break down. They got really expensive. They got really sort of bloated. People were stepping on each other. People were locking each other out of their
[05:17] workspace. Uh and things were insecure, which you know, over the past year, I think everybody's realized that that's not a good thing. Uh and it's getting less of a good thing the more agents get involved. Uh it wasn't good for the
[05:31] users either. So, you know, essays would uh have demos break. We had to constantly maintain the uh systems and the shared databases. Uh and that took a
[05:43] ton of time. Uh we've got our our brave system admin sitting in the front row here who has uh weathered that storm for the past few years. And you know, come talk to him after he can tell you some horror stories, I'm sure. Uh but it was
[05:56] not easy. It took a full-time person plus and you know the probably took five full-time people really to maintain that. Uh and then you know that's sort of the last piece is the admin struggling with uh angry users long
[06:09] request cues and and generally just a system that was beyond its scale.
[06:21] So now coming back to you know how we kind of evolved over time right like the if you think about it like you know we had to think through differently instead of saying that hey how can we like there are platform limits there are other
[06:33] limits within the you know from the cloud level to our work at data bricks account level data bricks workspace level there are multiple levels that we had to think through and we were trying
[06:45] to figure out Like it's not like we are just trying to solve just for the problem in front of us. How can we think for four five like if we already know the trajectory of the growth and we last year at this time when we started doing
[06:58] all these things we know AI systems and other things are coming in so we were trying to figure out how we can plan ahead like you know we know where the puck is going. So you know they as they say you got to skate towards where the
[07:10] puck is going and not where it has been. So we had to think through and that's really the origination of the you know the design or the considerations that we thought through on how we should really
[07:22] think around the problem and that's really you know if we u if you think about it we the core principle is like we cannot live in this shared environment like how can we just in time
[07:34] provision only what is needed for a given user for the given need that they have at hand and how we can make it self-s served that they can take it and whether it is a people user or an agent
[07:47] user regardless of what it is you know they are able to come in get the resource they need just in time and by the time they are done you know it's it's they don't have to worry about it it's automatically you know recycled
[08:00] repurposed and all those things in the same way you know if you've talked about like neon database you know lake base and other things that you might have heard that agents are the one coming in spinning up all those resour resources
[08:12] as needed you know and then they are just automatically clawed back. So it's the same concept we thought of that and say okay how can we take similar concepts and apply the same thing for the infra layer being able to say
[08:27] you know as a user as a regular solutions architect in the field being able to take it to customers they have a certain set of need they are part of probably part of a particular industry they need to have a certain dimensions
[08:40] or other data that is residing you know in some places and we need to be able to bring them all them package them in a way that they are able to take it and you know they are able to not just take
[08:53] it and show it but also take it and reper like design and other things on top of it and then being able to take it and share it with customers. So that's really the core principle that we thought of and kind of started working
[09:05] together. And if you go to the next slide, you know, so that's really the, you know, the crux of it that landed is what we call as the, you know, FE vending machine. And as you can see here, the ask from the end user is
[09:17] rather simple. We just say, hey, just tell it like don't there is no, you don't have to fill in 200 different things to get what you need. Just in the chat interface, just tell us what's on
[09:29] your mind. what exactly are you trying to do? And that is all that is needed. And the rest of the agentic framework that we build under the hood takes care of it to be able to decipher the intent from the intent. What is the necessary
[09:42] infrastructure and hardware that is required under the hood and then being able to you know we took the brunt of it with the agentic framework to be able to say these are the components that needs to be stitched together and managed and
[09:55] maintained and all they get at the end of the day is a URL. they click on it, they get the resource. So that's really what we, you know, just ask what you need, here is what you need, and kind of got into that framework.
[10:12] >> And so when we uh sat down to to build this, which was, you know, about a year ago, um we we started to think of what are the different sort of buckets of users that we need to uh appease with this thing. And there there were really
[10:25] three of them at the end of the day. The first was the actual essays, the people in the field who were going to use this day-to-day uh who were you know failing in the current workload uh the current uh paradigm. There were the IT and
[10:38] security folks, the you know people who owned the budget for for everything uh that they needed to be confident that we could you know meet the needs for governance. And then there were the admins, uh, us, who were going to run
[10:50] this thing and hopefully not be on call 247 to make sure it was running and make sure that we were meeting all the needs of everything. And so, uh, that's sort of the the three buckets you hear, uh, see here. You know, first is, you know,
[11:03] getting people the right infrastructure at the right time. Uh, it's easy to get people, uh, the right infrastructure all the time because you can just build it and that's what we tried to do originally and it doesn't scale. Um, and
[11:15] hopefully you don't want to give people the the wrong infrastructure at the right time because that doesn't really help anyone. And so getting people to what they need without actually necessarily having them know what they need because you know even in a
[11:27] organization as technical and uh advanced as data bricks people don't always know everything right not everyone at data bicks is a infrastructure expert a lot of people are AI experts a lot of people are data
[11:39] engineering experts but they don't necessarily know you know I need private link I need a slash22s cider I need x y and z so how do you get people what they need without uh you know killing them
[11:51] with details and having a million knobs that they can turn. Uh obviously the governance piece again getting more and more important uh and so governance really had to be a first uh design
[12:03] principle of FEVM making sure that we weren't launching things that were going to get us into trouble uh because there's no you know faster way to get your project shut down than just opening up a you know any workspace to the
[12:16] internet or something like that. So the sort of design principle number two and the third was you know consolidating things make it easy for the admins and ideally build things on data bricks first where possible but more than
[12:28] anything you know we we didn't want to sacrifice functionality and we didn't want to make things more complex than they had to be. Uh fortunately uh with the rise of lakebase and all the models on data bricks uh we really didn't have
[12:41] to do that uh while making data bricks sort of the the first class citizen in this design. Uh, one of the really important things
[12:53] and again this sort of started building this thing before agents were were really big uh or really at the start of when agents were starting to to emerge and we went pretty hard in uh from the
[13:08] beginning on let's make this thing uh fully agentic. let's design with agents sort of as a first class citizen both for the users and also for uh you know itself right how do we make agents
[13:20] embedded at every piece uh one of the really cool things I think that we've we've done with this is sort of this uh agent-based UI so there's an MCP and I'll show it in a minute uh MCP in the
[13:34] background and that's really driving all of the agentic workflows both from external callers but also within the platform itself So, uh, this sort of concept of the generative UI where things are not fixed. They're not just a
[13:47] static form that you can go through and it's, you know, gives you X, Y, and Z choices and it's sort of a your standard um decision tree. It's more of a a really reactive thing where users talk
[14:00] to the agent, they get a sort of pre-filled form from the agent, they can keep talking to the agent, the agent continues to update the form or they can update the form and it goes back to the agent. So there's this cycle of context
[14:12] uh that helps really make the user experience good, but it also helps the agent perform really well. Uh so uh you'll see that when we do the demo. Uh but it's I think one of the the bigger
[14:24] wins that we've had and one one of the biggest realizations that we've had from building FEVM is designing with this sort of agent first framework has really made things uh go a million times faster and uh I think a million times better
[14:37] than they would have otherwise. Yeah. So even even like even in the generative UI, but before going to the next slide, you know, couple of other things that I want to call out as well, right? Like the whole point is to make
[14:51] it look dumb and simple in front of the user. It is I mean at the end of the day they are just chatting with an interface filling few elements only what they probably are aware and a lot more
[15:04] complexity is abstracted away from it and that's really the secret sauce probably not very apparent in a demo or a slide here for us to show but even be like similar to what Greg was alluding
[15:16] earlier right like for us as a you know tooling team or a infra team providing a service to 7,000 people behind As there is IT teams who managing a bunch of
[15:29] infra where they are providing it as a service there is security team they are coming up with a list of policies on how it is which changes over time based on their own understanding of how the world
[15:41] of security needs to be and legal has their own thing and then the finance and budget team they have their own concerns and everybody you know historically back in the day what used to be is like everybody had a policy dock there's a
[15:54] security governance Doc and that cost governance doc and everybody has to manually understand and a lot of times they couldn't really keep up and this system what it is doing is that it is
[16:06] literally abstracting away all of those components. If they use this framework they are implicitly adhering to the security policy the cost policy and the
[16:18] legal policed away from them. So what we tell them is that we want to make you know instead of making like the easy thing to do is to like instead of
[16:31] telling them go and look at all these policies and which is a hard thing to do we make it saying that hey the easy thing to do is the right way to do it right like so we kind of got into that
[16:43] framework and that is really the reason why we kind of had a viral moment internally at data bricks to be able to say hey I don't really need to read about it in 20 pages to keep up. I can can just go click within a fraction of
[16:56] you know minute or so I'm able to get the resource that I need. So if we go to the next slide right like so kind of zooming out to do a little or I should say zooming out or an expanding scope here if you will. So this infra is just
[17:10] really just one component to it but there is a lot more as a workflow for a given team member in the field engineering team right like so if you think about it so this is one of the things that we are kind of embarking or
[17:24] evolving into or scaling into so what we're really working towards is being able to say from a use case or from a workflow from a end user end user
[17:36] as in from our perspective is a field engineering team member. They are probably having conversations with customers all day in probably with multiple customers and we kind of how we
[17:48] can capture like we talked you know from the keynotes and other things. You probably heard about context and other things where how can we capture these context well ahead of time in a temporal
[18:00] manner for a given account or for a given SAT member or any team member within the GTM or a field engineering org and being able to capture them and keep that you know in a recurring basis
[18:12] and being able to say I know about this customer these are the conversations you have been having this is the pain point they alluded to to you and say last Friday you were on a call they said okay
[18:26] perhaps maybe if you do ABC I would love to see how that works out how can our agentic system instead of just talking about it being able to be actionoriented
[18:38] to say okay I'm able to start working on it on your behalf so it's an ambient mode type of agents being able to come in and say I know the context of this customer I know the context of you as a user and recently Basically this is what
[18:51] they talked so I'm going to start first step let me provision the you know necessary infrastructure for me to experiment that building solution part of it so they actually use the MCP
[19:03] server that Greg will show later in a minute being able to spin up the necessary infrastructure first and then that is not the end all be all like that solves only step one being able to come
[19:16] back and next and say okay next I know what industry I mean I know the context of the customer. So what industry, what set of use cases that typically in that industry has been doing. So we have a
[19:28] catalog of all those things in our context catalog being able to take that and use you know dabs and other methodology within data bricks to instantiate those as add-ons using the
[19:40] same you know provisioning framework. So now we have the infrastructure or the data bricks workspace which is praying and vanilla you have the add-ons or other things which is like a base
[19:52] solutions that customers probably are interested have been talking about it not only that given that I have actual context of the actual problem they have been talking about I have another
[20:04] component you know what we call as the solutions builder being able to take that base using agent framework with genie and other things being able to adapt and personalize even further
[20:17] validate lot of problem statements that customer talked about and then being able to come back and report back to the solutions architect and say in a proactive manner reach out to them and say this is a conversation you had here
[20:30] is the actual URL where you everything has been already done on your behalf which the SA can actually go in and take and say I can modify a few things
[20:42] iterate even further because I have other information and then being able to personalize even further and take it to the customers the next week and say I have already validated all these this is
[20:54] not just a you know talk but also the actual working solution that we can even share with you and which the customers can then take it and build extend upon. So that's the full end to end agent full
[21:07] agentic framework that we are building around it to even extend even further in the coming months. >> So if you talk a little bit about uh the architecture and and the design
[21:20] principles of of FVM uh I think first to start with how did we get started on this um and I want to note this was actually we started this before cloud was really a thing. I think
[21:32] if we were building this today, uh, it would go, I don't know, like 10x as fast. But I also think that there was, uh, maybe becoming a bit of a lost art of taking your time in building things
[21:44] and actually doing it by hand, uh, to begin with at least. Uh, but the the the sort of core things that we focused on when we were designing this about a year ago was, you know, first, uh, don't wait
[21:56] for perfection. Um, we really iterated fast. You know, again, it's been a year. Uh I think we're we've released probably 150 times already. Uh so you know we have minor major releases. Um we've
[22:09] refactored our database twice. We've done a lot of uh iteration on this. And so you know I think coming into this uh at least personally I had a a sort of
[22:21] mindset of we we have to design something really good but you know doing really good especially in the agentic era where things move at the speed of light. uh you get left behind really quickly. So iteration really quickly is
[22:33] is sort of key and part of what helps you do that is designing with agents as you know first class citizens. Um again as as you sort of saw earlier as Joel talked about as you'll see in the demo
[22:45] uh agents are really baked into this thing. uh they are really uh as we see in sort of the traffic into FEVM becoming more and more of you know users
[22:57] are are still important but there's more and more agents coming into this thing they're becoming perhaps even a majority of the traffic into FEVM so they have to be uh designed for and the workflow has to be really easy and then the third one
[23:10] which I think uh we can credit Joel with is you know build from the user's perspective uh in to the product rather than starting from the technology and building out. And so we we spent a lot of time iterating on like what are the
[23:23] CUJS, what are the the user journeys that users are going to do uh in this tool or what do we want them to be uh going out and talking to the users. I guess that's a really important part is actually talking to people who are going
[23:35] to use it before you build something that you think they need and then building the the solution from there sort of backwards and and sort of making your choices based on that.
[23:50] And what we ended up with was uh this stack. So this is very high level uh and and hopefully you can see it all but you'll notice that you know most of this is actually data bricks native. Um there are a few pieces uh and we we built this
[24:03] on AWS but you could build this easily on uh Azure GCP. uh pretty much everything except for the storage uh which you know is in S3 and the the notification pieces which are you know a
[24:15] few different sort of external messaging uh tools those are all in in data bricks so you know we we built from the workspace up uh you know apps on top of that lakebased for the serving layer and
[24:28] the uh sort of delivery layer uh and MCP again built on an app and then the UI built on top of that. So you you can sort of see the components o over on the right there. Um not as important here
[24:41] but really uh I I think it's really impressive to see that almost everything top to bottom can be built on uh on data bricks natively. Now the other piece uh
[24:54] I think that sort of was a bit of a innovation here was using the the runners and the Terraform uh templates. So we basically have a a repository that has all of our Terraform templates in it. Uh from the FEVM app when you you'll
[25:07] see sort of in a minute when you deploy something it kicks off a runner. That runner grabs the appropriate template with all the parameters filled in and then goes and launches it. So um you know it's it's been a really uh
[25:20] important piece to to sort of keep that flexibility and flow.
[25:33] Okay. Okay. So this is sort of the uh the actual vending machine. This is our production instance. Uh we're on version 010.10 here. Uh and I think we actually released something since I loaded this.
[25:45] So it's probably going to go to 01011 uh in a second. So like you see uh sort of this chat interface is is really the main thing. Uh so we've got some sort of pre-baked queries here that you can fill in. If I just say uh give me a
[26:02] serverless workspace. This will kick us over to that uh sort of generative UI. So it's going to prefill the things that
[26:14] it thinks are best. Uh basically give me the the minimum that it can confidently predict and uh sort of go over to to the UI.
[26:30] if it goes. Try this again. Unfortunately, the the Wi-Fi is a little bit iffy here. There it goes. So, this is the uh that
[26:42] generative UI we were talking about. So, I can either chat over here and ask the agent to update things or if I know sort of what I want to do, I can go over to this side and it'll actually send that
[26:54] context back to the agent. So, if I continue with the chat, uh the agent won't try to sort of run over what I've already done manually. It'll know that I did that and it'll use that to to make better suggestions. So, you can see, you
[27:06] know, this is basically giving me a an AWS workspace. I can give it a name and a lifetime. You know, the lifetime is important. basically it defines how long this thing is going to live until it gets cleaned up. Users can extend that
[27:18] that workspace. Um you know we basically send out notifications seven days before it gets deleted, three days before it gets deleted and as it's getting deleted. Uh and all those notifications go over Slack, over email, uh and in
[27:30] app. So I have the add-ons like Joel was saying. So there's the solution builder which is uh you know part of that a aentic framework. I can add that add-on. And basically what happens is after I launch this, it's going to launch
[27:43] another template that goes and puts that into my workspace for me. So as a user, I really don't have to do anything. I just hit deploy and it starts that deployment for me. If I go to sort of what resources I
[27:58] have, this is sort of the user experience of, you know, what do I have? Uh what's in progress. So I'm cheating a little bit. I have an agent in the background that's launching and deleting a bunch of things. So, we can see these in flight, but these five are
[28:11] provisioning. These two are deleting. And then I have some active workspaces as well. If I click on any of these, I'll go directly to that workspace. It'll be set up for me. Again, I don't need to set up any infrastructure or
[28:23] know anything about the underlying uh tooling that goes into it. I just need to go in and actually use it. Uh if I go to sort of the the admin side uh so you can see what we're doing to to you know
[28:35] make our lives easier. Um basically we can see all the deployments. So you know we've got almost 3,800 active workspaces in this thing which is pretty cool. Uh we've had
[28:48] uh almost 14,000 total actually more than 14,000 almost 20,000 total deployments that have gone through the uh the entire pipeline of FEVM and we've
[29:01] got you know extensions. So again, if users come in and want to keep their workspace for more than 30 days or they only did it 30 days and then they realize that they need another 60 days, they can file that extension and we've
[29:13] got some tools built in to uh to make that easier for us. But really the sort of easiest way to do any of this even outside of the uh UI is to do it via an
[29:25] agent. And so we have skills and we have a completely sort of bakedin agent framework uh that will let us uh use agent let users use agents and also admins use agents to do their sort of most common workflows. So for example uh
[29:40] if I want to check on all of the things I have running right now I just dovm I say tell me about my deployments and give me my remaining quota.
[29:54] Basically, this is going to go call our MCP server and it's going to pull all of the data from FEVM so that I can see uh sort of uh both see sort of read actions but
[30:07] also do write actions. So I can have workflows that that call this agent from anywhere that is sort of MCP accessible. So you'll see I have you know four pending workflows got a bunch of uh AWS
[30:21] stable serverless work uh workspaces that are uh already launched and I've got a limit of 25. So again you know as an admin I can also say approve all these extensions give me any sort of uh stuck uh provisioning workspaces that I
[30:35] need to go on triage help me solve you know what's causing this thing to fail uh and and sort of again bake agents into everything within this Cool.
[30:47] So, if I go back to here, that's sort of what we talked through here. So, I guess uh just to wrap up a little bit, uh the lessons and takeaways of of
[30:59] building FBM over the past year, you know, what have we learned and and what are our takeaways? Um, you know, I guess I this should have been 20,000 workspaces later, but uh there are some some key things that, you know, we've
[31:11] learned and hopefully those have come out through this presentation. First is, you know, simplicity is is not easy when you're building these kinds of things. I think anybody who's, you know, built a a userfacing app or or UI or any kind of
[31:24] tool, uh, will realize that it's it's really hard to build something that's easy for users and also easy for admins and that sort of maintains a simple architecture. Uh, so, you know, again,
[31:36] this is sort of upfront. We spent a lot of time designing the database um designing the initial UI, iterating, going to users, seeing what they thought, redesigning and I think that really made the rest of the process uh
[31:49] much more smooth and also made the adoption go really quickly which is sort of point number two. You know, finding critics is uh a really useful exercise. I think some of the people that are the
[32:01] the best supporters of FBM uh today are some of the ones that were very critical of uh of the process of you know you're taking away my workspace that I've had for three years uh but we're giving you
[32:15] something better. So making those people into your sort of power users uh is going to help you capture the rest of everybody else because the most critical ones are are usually the the ones who are loudest and can be loud for you as
[32:28] well. And then the last piece, you know, agents, again, everything is agentic. I think if you if you've been to any session or just looked at the uh giant billboards around uh Moscone Center, you
[32:41] realize everything is is really agent focused. And so at UVM, designing with agents uh in the uh core of it from the start really made a huge difference.
[32:55] And so sort of a final call to action and then we can do some Q&A. sort of keep up with data bricks apps. There's been a ton of announcements. Uh they're they're iterating really quickly again and building a ton of new things on apps. Uh so, you know, make sure you
[33:08] check out all of the sessions that we've done with apps. Uh keep an eye on the product page. I think there's going to be a lot of really interesting uh previews and and GA features that are coming out soon. Uh determining the best
[33:21] stack for your app. Again, uh we're a little bit opinionated, but we think data bricks is pretty good for for most pieces of this kind of stack. Um but you know, uh I think lakebased made a huge difference, but design for for what you
[33:34] need. You may decide that uh RDS or or some other services is what's right for you. Uh build the necessary stuff first. You know, start with with what is the uh
[33:46] sort of core value prop of your solution and build out from there. build from the uh sort of users in and then you know also don't overengineer like we've had a lot of people ask us uh how can I do
[33:59] FEVM uh in my company and this the answer often is you probably don't need to like if you're not launching 10,000 workspaces uh over uh six months you may not need to build this full solution but
[34:13] the core principles and the sort of idea around it might still be useful so you know don't I I I think get fixated on oh I need to build this thing exactly but uh look at what your your company needs
[34:27] or what your users need and build that and then uh come talk to us we're happy to uh to to talk more about it I think we have another one of these sessions tomorrow uh as well >> yeah just to conclude there as well
[34:41] right like like what Greg mentioned uh pretty much every most of the like we have touched every aspect of data bricks as a product from from Unity catalog to
[34:53] you know coding to genie to lakebased data bricks apps in particular even though we solved a infra problem it still touched a lot of different components so it's like we data bricks
[35:07] has evolved to the point that like it's really up to your imagination on how you want to what you want to solve and how you can solve all these these components. So this is still kind of a first inning for us as a team. You know,
[35:21] we what we're really working towards next as part of our team is really going to how we build a true digital twin equivalent of our field engineering organization and how we can bring all those components where where we have
[35:34] agentic users and human users are coming and working together in a same agentic platform for us to truly execute at scale. And that's a vision you know we're working towards and definitely you
[35:46] know every element or every aspect of data brick stack is a core component of how we looking to build it. So thank you VI7.

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.