WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=uKUA1a0Kdfc

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/uKUA1a0Kdfc.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:12.480 --> 00:00:14.160
Hey everybody, how's it going?

s2
00:00:14.160 --> 00:00:16.640
Hope you're having a good last day of AI Engineer.

s3
00:00:16.640 --> 00:00:22.000
Uh what I'm going to talk about today is how to move fast and not break things.

s4
00:00:22.000 --> 00:00:24.560
So the the phrase move fast and break things.

s5
00:00:24.560 --> 00:00:32.160
You've probably heard this before and what this uh refers to is it's a phrase from early Facebook engineering culture days, right?

s6
00:00:32.160 --> 00:00:43.440
And the idea was we want to be able to move fast and ship fast and not be constrained by, you know, databases going down or breaking certain features because the priority is there's so much value in shipping fast.

s7
00:00:43.440 --> 00:00:49.760
And this was 20 years ago, right, before we had AI agents writing code for us and shipping things and deploying things on our behalf.

s8
00:00:49.760 --> 00:00:54.239
So, if anything, the idea of doing this is more true than ever.

s9
00:00:54.239 --> 00:00:56.960
But in my opinion, we can actually achieve both, right?

s10
00:00:56.960 --> 00:01:06.080
I want to be able to ship fast, build great features, get things out to my customers, but also not break the databases, the infrastructure, the application servers that are powering

s11
00:01:06.080 --> 00:01:07.439
what I'm doing.

s12
00:01:07.439 --> 00:01:11.600
And we've probably all seen something that looks approximately like this.

s13
00:01:11.600 --> 00:01:13.760
And I'm not calling out any particular company.

s14
00:01:13.760 --> 00:01:26.320
There's a number of companies right that due to the kind of insane scale that we've seen over the past even 6 months year two years right where we've had like daily active users double triple 10x 100x

s15
00:01:26.320 --> 00:01:39.360
a lot of that powered by like the demand of AI agents um where the infrastructure struggles to keep up and some of this is simply because it's a very hard problem right this is not meant to call anybody in particular out it's hard to scale things to

s16
00:01:39.360 --> 00:01:49.840
tens of millions or hundreds of millions of users but what we'd like to have is great products that scale well for lots of users and have our status pages look a little bit more like this one, right?

s17
00:01:49.840 --> 00:02:00.000
Three or four nines of availability uh maybe five of availability where our databases are healthy, our applications are healthy and ultimately our users are happy, right?

s18
00:02:00.000 --> 00:02:05.360
So this is kind of the idea behind what I want to talk about which is a little different than probably most of the talks you've been at.

s19
00:02:05.360 --> 00:02:12.000
A lot of the talks are probably talking about inference or specifically how to do things with agents or different kinds of automations.

s20
00:02:12.000 --> 00:02:26.560
This is more of an infrastructure talk, but how you can do that and ship fast both with the demand of AI agents as well as the you being able to use AI agents to make all of these processes more optimized and smoother.

s21
00:02:26.560 --> 00:02:29.360
So, there's three parts to this that I want to talk about.

s22
00:02:29.360 --> 00:02:36.319
The first one is how do you even build systems regardless of the number of users you have that aren't going down all the time?

s23
00:02:36.319 --> 00:02:45.680
and then tying that into well okay if you're going to build the next hit application that's going to scale to millions of people using it how do we scale that using these same principles

s24
00:02:45.680 --> 00:02:57.440
and then finally how can we take these two things and let AI agents do them for us or at least in part work with them in doing this so I should probably introduce myself a little bit too

s25
00:02:57.440 --> 00:03:07.040
why I'm talking about this is I'm Ben and I'm from planet scale and we do databases this is our whole thing and we work with a lot of these AI companies that are scaling extremely fast.

s26
00:03:07.040 --> 00:03:11.599
We work with companies like cursor for example and power databases for them.

s27
00:03:11.599 --> 00:03:15.360
And so this is something that we as a company take very seriously.

s28
00:03:15.360 --> 00:03:27.280
How do we scale and support companies that have millions of users uh on their platforms and some of what I'm talking about comes from a article that we published last year about kind of our philosophy of how we operate databases.

s29
00:03:27.280 --> 00:03:30.159
I would encourage you to go Google that and read that.

s30
00:03:30.159 --> 00:03:33.920
Um but a couple of these principles let's go over some of these.

s31
00:03:33.920 --> 00:03:38.080
So the the first and one of the most important is isolation.

s32
00:03:38.080 --> 00:03:38.319
Right?

s33
00:03:38.319 --> 00:03:48.239
When you are running infrastructure, one of the things you want to make sure you do is have a setup where if something fails, it doesn't take down the whole system, but every component is very isolated.

s34
00:03:48.239 --> 00:03:50.799
So what I'm showing here is data plane.

s35
00:03:50.799 --> 00:03:52.640
That basically means where are your databases?

s36
00:03:52.640 --> 00:03:58.560
Where does your most critical data live that you need to be using for your users to log in and interact with your application?

s37
00:03:58.560 --> 00:04:00.239
But there's lots of other components, right?

s38
00:04:00.239 --> 00:04:09.200
There's your control planes, there's your observability pipelines, there might be your analytics frameworks, there's your apps, there's your MCPs, and there's all these different components that can potentially fail.

s39
00:04:09.200 --> 00:04:19.519
And in fact, assuming you're using a good database platform, the database is hopefully low likely to fail, but these other things you're shipping and deploying to more frequently, so are more likely to fail.

s40
00:04:19.519 --> 00:04:28.800
So we want to make sure that we've designed things where if I deploy a bad ship to the control plane and take it down, nothing else is impacted and can still

s41
00:04:28.800 --> 00:04:30.800
access the database, right?

s42
00:04:30.800 --> 00:04:32.960
And anything in my data plane.

s43
00:04:32.960 --> 00:04:36.880
So this is one of these kind of core principles that we take very seriously.

s44
00:04:36.880 --> 00:04:39.600
And another thing is redundancy.

s45
00:04:39.600 --> 00:04:45.680
And if any of you have worked with databases before in the past, you've probably seen a diagram that looks something like this.

s46
00:04:45.680 --> 00:04:50.320
And similar things apply to your app infrastructure and your other infrastructure.

s47
00:04:50.320 --> 00:04:57.120
Although in the case of application servers, usually redundancy is a little bit easier to solve because it's a stateless workload, right?

s48
00:04:57.120 --> 00:05:06.240
There's lots of sort of autoscaling cloudflare workers and versell functions and AWS Lambda that can scale and have redundancy very easily because it's not storing state.

s49
00:05:06.240 --> 00:05:09.120
But in the database world, you have to store state reliably.

s50
00:05:09.120 --> 00:05:10.960
You can't lose a single bite of data.

s51
00:05:10.960 --> 00:05:12.320
And so how do you do this?

s52
00:05:12.320 --> 00:05:20.720
Um, a very common approach which costs more money and is more complex but it's the way that you scale reliably is by having a primary node.

s53
00:05:20.720 --> 00:05:22.560
So this is where most of your traffic goes to.

s54
00:05:22.560 --> 00:05:33.199
But you always have replica servers or follower servers standing by in different data centers or different availability zones ready to take over because the fact is servers do fail sometimes.

s55
00:05:33.199 --> 00:05:41.759
Uh, and on a small scale when you've got an app that has a hundred users and you have one database server, you might only experience a failure once every couple of years.

s56
00:05:41.759 --> 00:05:48.960
But at a large scale when you have thousands of servers a once or twice a year failure becomes a weekly or monthly failure.

s57
00:05:48.960 --> 00:05:53.360
And so you need to have systems in place to deal with this very well.

s58
00:05:53.360 --> 00:05:54.000
Okay.

s59
00:05:54.000 --> 00:06:03.199
So we've talked about uh what the principles of of scaling reliably are or of um having reliable systems are.

s60
00:06:03.199 --> 00:06:07.440
But then the question is what I've just told you here we could write a whole book on.

s61
00:06:07.440 --> 00:06:07.600
Right?

s62
00:06:07.600 --> 00:06:11.360
So there's lots more that you know there's people who spend their entire careers focused on this.

s63
00:06:11.360 --> 00:06:19.199
So, we're going a little bit quickly through it, but these principles apply no matter what point of this user growth chart you're at, right?

s64
00:06:19.199 --> 00:06:28.960
You could be at 100 users and in this case, uh, it's still good to have redundancies, to have isolation, to have failure even for that smaller set of users.

s65
00:06:28.960 --> 00:06:32.880
And you want to apply those same principles when you are all the way up here.

s66
00:06:32.880 --> 00:06:37.520
I don't know if you can see that line very well, but at millions of daily active users.

s67
00:06:37.520 --> 00:06:43.680
But there is a point where you actually have to incorporate different technologies to scale efficiently and effectively.

s68
00:06:43.680 --> 00:06:47.440
So, uh, let's talk about how we scale those systems for a few minutes.

s69
00:06:47.440 --> 00:06:52.000
And probably the part you're most excited about is the AI agents part, which we'll get to at the end.

s70
00:06:52.000 --> 00:06:58.160
Um, so one of the key things, and this is what we do a lot of at Planet Scale, is sharding.

s71
00:06:58.160 --> 00:07:02.400
Um, I just realized my mouse is on the screen, so let me get that off the screen here.

s72
00:07:02.400 --> 00:07:04.319
See if that will go away eventually.

s73
00:07:04.319 --> 00:07:05.840
Um, so database sharding.

s74
00:07:05.840 --> 00:07:07.440
What is this?

s75
00:07:07.440 --> 00:07:17.280
What you do is instead of relying on that single node, which works fine when you have 10 gigabytes of data, it doesn't work so well when you have 10 terabytes of data

s76
00:07:17.280 --> 00:07:20.319
or 100 terabytes of data or a pabyte of data.

s77
00:07:20.319 --> 00:07:21.680
So what do you have to start doing?

s78
00:07:21.680 --> 00:07:26.720
Well, what you need to do is spread your data and your queries out across many servers.

s79
00:07:26.720 --> 00:07:29.360
And so that's what all of these shards down here below are.

s80
00:07:29.360 --> 00:07:40.479
And typically you put some kind of proxy and we'll talk more about what VTGate means later in between that intelligently handles distributing all of the user requests or the query requests across all of these servers.

s81
00:07:40.479 --> 00:07:44.479
Uh and this is exactly what we do a lot of for some large customers at planet scale.

s82
00:07:44.479 --> 00:07:49.599
We do sharding through vitess for my SQL and niki for postgress.

s83
00:07:49.599 --> 00:07:52.479
Um and so this is a very fundamental way of doing sharding.

s84
00:07:52.479 --> 00:07:55.039
But the other thing is you don't just use sharding by itself.

s85
00:07:55.039 --> 00:08:02.240
If we look at this and we see for example shard A, within that box, you actually would want a redundant system.

s86
00:08:02.240 --> 00:08:04.400
So you'd have a primary and several replicas in there.

s87
00:08:04.400 --> 00:08:11.759
So if one of those servers fails, that single shard can do self-healing and get back online very quickly if there's a problem.

s88
00:08:11.759 --> 00:08:18.240
So this is one of the ways that we see and is probably the most common and performant way to scale databases.

s89
00:08:18.240 --> 00:08:29.680
But really the same principle of hey let's take queries and data and spread them out across many servers, many nodes, many drives uh applies to lots of other areas of the stack that you're building.

s90
00:08:29.680 --> 00:08:30.479
Back pressure.

s91
00:08:30.479 --> 00:08:36.719
So this is another one that is sort of a mix of being a part of scalability but also a part of reliability.

s92
00:08:36.719 --> 00:08:47.920
And what we mean here is there's a lot of systems like MySQL and Postgress and SQLite, these very popular databases that people run that don't do a good job at handling being overloaded.

s93
00:08:47.920 --> 00:09:02.720
The moment that they have too many queries or using too much CPU or they run out of RAM for the cache in many cases, if not taken a lot of care for, they'll just crash and now your server is down and now all of your users are impacted and they can't use your service that the database is

s94
00:09:02.720 --> 00:09:03.680
powering.

s95
00:09:03.680 --> 00:09:12.160
What back pressure is is it's designing a system to be able to push back and say when I detect that I'm above a certain threshold of resources I can actually say

s96
00:09:12.160 --> 00:09:27.360
I want to push back and start failing requests denying query uh denying connections right so that I can keep the existing users or some of the traffic healthy while gracefully degrading some of the other traffic and then the rest of your stack has to be built to support that.

s97
00:09:27.360 --> 00:09:34.880
So, this is a principle that applies in lots of areas of the stack, but in the database, it's arguably the most important.

s98
00:09:34.880 --> 00:09:36.080
Uh, let's see here.

s99
00:09:36.080 --> 00:09:36.480
The clicker.

s100
00:09:36.480 --> 00:09:37.040
There we go.

s101
00:09:37.040 --> 00:09:43.279
And then the last component of this that I want to talk about before we move into how to do this all with AI is decoupling.

s102
00:09:43.279 --> 00:09:53.920
Uh, there's a lot of people that you'll talk to and when it comes to databases will argue that you should probably have all of your services combined into one because there's some convenience to that.

s103
00:09:53.920 --> 00:10:02.640
your Postgress database, your OOLTP workloads combined with what you're doing for analytics combined with your your queuing and your job system, your caching.

s104
00:10:02.640 --> 00:10:06.560
There is convenience and some technologies try to do this where we put this all in one.

s105
00:10:06.560 --> 00:10:14.000
But that does one add a lot of complexity, but it also breaks some of the fundamental principles from earlier like failure isolation, right?

s106
00:10:14.000 --> 00:10:17.680
If one service goes down, that actually means everything is going down.

s107
00:10:17.680 --> 00:10:20.640
And then you also have to deal with contention of resources.

s108
00:10:20.640 --> 00:10:34.160
So if you suddenly have a burst of Q jobs and you need to scale up your cues, but maybe nothing else really needs to scale, it would be nice if we can independently scale the amount of compute resources that we've given to each of these parts of our backend service

s109
00:10:34.160 --> 00:10:35.760
powering your favorite application.

s110
00:10:35.760 --> 00:10:37.360
Right?

s111
00:10:37.360 --> 00:10:40.320
So this is not a complete list.

s112
00:10:40.320 --> 00:10:41.519
What did we go through so far?

s113
00:10:41.519 --> 00:10:42.959
We went through sharding.

s114
00:10:42.959 --> 00:10:44.480
We went through back pressure.

s115
00:10:44.480 --> 00:10:46.320
And now we're talking about decoupling.

s116
00:10:46.320 --> 00:10:48.959
There's many other aspects to scalability.

s117
00:10:48.959 --> 00:10:52.880
And again, you could spend your entire career becoming an expert in scalability.

s118
00:10:52.880 --> 00:11:01.839
Uh, but this is a lot of what we think about a lot at planet scale because our customers rely on us to be reliable and to scale.

s119
00:11:01.839 --> 00:11:04.720
So, finally, let's go to the last part of this.

s120
00:11:04.720 --> 00:11:09.120
We let's say we have all of these principles in place.

s121
00:11:09.120 --> 00:11:12.560
We are doing things reliably where we have fault tolerance.

s122
00:11:12.560 --> 00:11:14.880
We're doing things that are very scalable.

s123
00:11:14.880 --> 00:11:22.160
But these days in a lot of organizations and we talk to a lot of people that feel this both at the small scale and at very large organizations.

s124
00:11:22.160 --> 00:11:31.200
How can we allow agents to whether in part or in full have control over what is arguably the most important infrastructure of your company, right?

s125
00:11:31.200 --> 00:11:35.920
The databases, the cues, the things that are powering every other layer of your stack.

s126
00:11:35.920 --> 00:11:44.000
Um, and this is something that can be a little bit intimidating because it's pretty much the standard these days, right, to write code with AI.

s127
00:11:44.000 --> 00:11:47.200
In some cases, people are not even writing any lines of code anymore, right?

s128
00:11:47.200 --> 00:11:50.079
AI is actually writing all of your code, reviewing all of your code.

s129
00:11:50.079 --> 00:11:53.040
Um, and you're just sort of guiding these agents to doing that.

s130
00:11:53.040 --> 00:12:04.480
But it is quite different to say, I'm going to now also give my agents the ability to deploy changes to the database or make changes to how things are configured there or to shard my database, right?

s131
00:12:04.480 --> 00:12:09.680
because that's something if it gets wrong, it's generally not as simple as clicking a button to roll it back, right?

s132
00:12:09.680 --> 00:12:12.880
It's taking down your entire application and every user notices.

s133
00:12:12.880 --> 00:12:15.519
So, we want to do this effectively and safely.

s134
00:12:15.519 --> 00:12:22.800
So, I'm going to revisit a couple of the concepts that I previously talked about and think about how do we use agents to solve this.

s135
00:12:22.800 --> 00:12:29.600
So, going back to sharding, what I'm going to talk a little more specifically about is Vitess and this is an open- source project.

s136
00:12:29.600 --> 00:12:34.639
uh we operate the test databases for our customers and it works with my SQL to do sharding.

s137
00:12:34.639 --> 00:12:50.880
So what you can see here is like all of those shards down there those would be my SQL databases and the VT gate that's the proxy that is basically an intelligent proxy that takes my SQL queries parses them figures out which shard they need to go to and routes all of those requests in a very sophisticated way.

s138
00:12:50.880 --> 00:13:00.720
So the software is fairly complicated, but the interface that we present for specifying how do you want all of your queries and your data sharded is actually quite simple.

s139
00:13:00.720 --> 00:13:07.440
It's what we call a v schema and it's literally a JSON file where you say here's the column I want to shard on and here's the way I want to do sharding

s140
00:13:07.440 --> 00:13:13.839
and you can specify certain tables to go on certain shards and have lots of control over where and how things are configured.

s141
00:13:13.839 --> 00:13:21.200
And the great thing is, as we all know, AI agents are excellent at working with things like text files and JSON files.

s142
00:13:21.200 --> 00:13:25.760
So you can give your agent and say, "Hey, I'm struggling with scalability of my database.

s143
00:13:25.760 --> 00:13:26.800
Here's my schema.

s144
00:13:26.800 --> 00:13:30.079
I want you to come up and help me prototype a good v schema."

s145
00:13:30.079 --> 00:13:30.560
Right?

s146
00:13:30.560 --> 00:13:44.639
And once you've developed and designed something that it has thought through and made decisions about the most efficient ways to shard when you are on a platform like planet scale you literally will plug this in and you make a deploy and you you can we give you an interface for creating new sharded systems and scaling up your

s147
00:13:44.639 --> 00:13:55.120
database and a lot of this can happen with either the help of AI or letting AI take some control over these processes uh given our API and our command line interface that we run.

s148
00:13:55.120 --> 00:14:08.480
So this is one of those things right very complex infrastructure in reality under the hood that is scaling your systems but you provide the right interfaces for it like simple configuration files and those things become much more accessible to any company

s149
00:14:08.480 --> 00:14:10.320
trying to scale.

s150
00:14:10.320 --> 00:14:16.399
Um, another thing, so this is getting into the uh concept of back pressure that we talked about earlier, right?

s151
00:14:16.399 --> 00:14:22.160
So when a database is overloaded, and this, as you might imagine, probably happens all the time at some of these companies, right?

s152
00:14:22.160 --> 00:14:32.000
I think there was a a tweet a couple of months ago from GitHub that basically said like their traffic had like two or three or 4x from what already was an extremely high load.

s153
00:14:32.000 --> 00:14:34.560
And pretty much all of that was attributed to AI agents, right?

s154
00:14:34.560 --> 00:14:39.360
So they already had gigantic infrastructure because they're the most popular place in the world to develop.

s155
00:14:39.360 --> 00:14:47.680
and then they had multiple uh uh traffic increases especially over like the holidays right due to these uh overloaded systems.

s156
00:14:47.680 --> 00:14:49.360
So how do we deal with this?

s157
00:14:49.360 --> 00:15:00.079
One of our solutions and the way that we like to think about it is we give users a system called traffic control which allows you to essentially categorize and tag all of the traffic coming into your database

s158
00:15:00.079 --> 00:15:11.279
and then you create resource budgets to say hey this segment of my traffic cannot exceed this amount resources of CPU usage or of backend processes and again we do graceful degradation

s159
00:15:11.279 --> 00:15:12.079
when that happens.

s160
00:15:12.079 --> 00:15:20.560
So what I'm showing here is this is a graph of I have a budget set up um to say don't exceed these amount of resources and warn if I do start exceeding these resources.

s161
00:15:20.560 --> 00:15:28.639
So it's showing me uh this is the amount of queries that are exceeding your budget over time and we're we're we're sending warnings back to the client like hey I'm overloaded

s162
00:15:28.639 --> 00:15:33.519
you need to slow down and we can even make it more strict where we actually kill those queries that are executing.

s163
00:15:33.519 --> 00:15:34.480
Right?

s164
00:15:34.480 --> 00:15:45.760
And this is one of those things that like, okay, it's not ideal to have to deny requests, but it's much better than your whole application going down and being offline for all of your users.

s165
00:15:45.760 --> 00:15:58.720
Uh, and then finally, one other thing I I want to talk about, and I know I'm showing this is the planet scale UI here, but this is not even so much specifically about planet scale, but it's about the philosophy of how we do these things with agents, which is

s166
00:15:58.720 --> 00:16:03.120
most developers are used to using a gitlike flow when you're building.

s167
00:16:03.120 --> 00:16:04.959
And this applies to your agents as well, right?

s168
00:16:04.959 --> 00:16:13.440
You have a main, you create a branch, you make code changes, you do merge that in, and you deploy that dynamically to wherever your application is deployed.

s169
00:16:13.440 --> 00:16:22.560
What we have done, and this was long before agents even existed, is we wanted to take that same UX and mirror that for your database because a lot of the times when you're building new

s170
00:16:22.560 --> 00:16:26.240
application features, you're also making changes to your schema.

s171
00:16:26.240 --> 00:16:33.920
You're adding tables, you're adding columns, you're deleting things, you're you're adding indexes, you're doing all of this stuff to your database to keep it in sync with your codebase.

s172
00:16:33.920 --> 00:16:46.399
So what we give you powered by that same vitess earlier is the ability to branch your database schema, make changes to that schema in an isolated environment and then merge that back into production with what we call a deploy request.

s173
00:16:46.399 --> 00:16:47.680
All with no downtime.

s174
00:16:47.680 --> 00:16:59.360
And not only that, but actually the ability, you might see here at the bottom, the ability to, if you deploy a schema change and you see a problem, we give you the ability to oneclick revert that go back to the old state of your database

s175
00:16:59.360 --> 00:17:00.880
without data loss.

s176
00:17:00.880 --> 00:17:08.240
Uh, and so this is something that was great for humans, but we also have the APIs and the CLI to be able to let agents automate this.

s177
00:17:08.240 --> 00:17:20.000
So when they are doing things and automating code and branching and making pull requests and doing code review, there can actually be a mirror database state that is working in sync with all of those things, right?

s178
00:17:20.000 --> 00:17:22.959
And that can either be fully automated, it can be semi-automated.

s179
00:17:22.959 --> 00:17:31.360
Obviously, many of us are working in a human in the loop fashion where humans are still reviewing all of these changes that AI agents are making, which is a good thing.

s180
00:17:31.360 --> 00:17:36.720
Um, but we have the primitives in place for building these uh systems.

s181
00:17:36.720 --> 00:17:48.400
And there's a number of other things that I didn't get to to talk about this, but kind of the the ending point that I want to make is we're a company and I know a lot of companies out there like to focus on the developer experience.

s182
00:17:48.400 --> 00:18:02.320
And when I say developer experience, I don't just mean like light and dark mode switches and good keyboard shortcuts and all of this, but I mean the actual experience of, hey, if you're a developer that's responsible for your company's database or responsible for some piece of infrastructure,

s183
00:18:02.320 --> 00:18:09.440
do we give you the tools that you need to not mess up to do deploys safely to make your database faster to get better performance?

s184
00:18:09.440 --> 00:18:11.919
Uh, and we've been building these things for years.

s185
00:18:11.919 --> 00:18:19.520
And it does kind of turn out that when you really focus on that core of the developer experience, what you actually end up with is also very good primitives

s186
00:18:19.520 --> 00:18:24.720
for AI being able to work with a database safely and reliably and helping it scale.

s187
00:18:24.720 --> 00:18:34.720
Uh, and so because we expose a lot of these things through our MCP server, through command line interfaces, obviously there's plenty of debate on which of those is better when working with your AI agents,

s188
00:18:34.720 --> 00:18:43.679
but because we expose those things to both parties, it's actually a great experience for operating your database and working well with AI agents.

s189
00:18:43.679 --> 00:18:46.320
So that is all that I have to say.

s190
00:18:46.320 --> 00:18:47.280
Thank you guys for coming.

s191
00:18:47.280 --> 00:18:51.360
I'm Ben and have a great rest of the conference.

s192
00:19:02.988 --> 00:19:04.988
[music]