 But my name's Mike Miller. I'm one of the three founders of Cloud Ants. I'll tell you a little bit about the company. But myself, I'm a particle physicist by training. I was a professor until January at University of Washington. And Cloud Antt came out of particle physics at MIT, where we were working on collider physics, Brookhaven National Lab, Fermi Lab, and most recently, Large Hadron Collider, dealing with big data, a lot of people scattered around the globe, and counting data centers in the hundreds and trying to deal with these problems. So I actually like to spend most of my time writing or talking or kind of pontificating about big data, data science, trends in general. And I try to stay away from vendor pitches. Today's talk is going to be a vendor pitch. So I'm going to warn you right there. But I'd like to make it interactive. If you have questions, shout it out. We can take this kind of how we want to go. But I want to tell you about Cloud Antt, the data layer. And have you walk out of here with a crisp idea of who we are and what we do. So let's start with the quiz. Before you walked into this room, I just want to get some ideas. Is there anybody here who did not know what MongoDB or TenGen was? One, maybe? All right. They have a billboard on the 101. It's tough to miss these days, right? How many have heard about Hadoop Cloud Air? Let's go ahead and raise hands. I see one that doesn't have a hand. Very well-known brands. How many of you had ever heard of Cloud Antt before this talk? All right. We've got one, which is great. Let's talk later. The purpose of this talk is to introduce you to something that we've been building and running in production for two years. Why have we been doing it? One of the interesting things is that we actually were part of the original NoSQL movement. We set up and sponsored the first NoSQL conference in 2009 to see if the technology we were building, fresh out of Y Combinator, had application. If there was a market, if there was a need. And what happened, we ran this conference in Georgia, in Atlanta, Georgia. And I don't know if anybody was actually there, but hundreds of people came out, from LinkedIn, from Facebook, from Twitter, and all the things that were just kind of nascent glimmers in the eye of NoSQL. Mongo was there talking about, or Dwight was there talking about this database part of TenGen, their cloud stack at that time. Reoc was brand new when we were close to trying to launch a beta service at that time. So it was a really foundational place that even brought together researchers. It was very exciting. So we've been around the space since the very beginning in its current marketing form, but the interesting thing is we're starting to become very relevant. You haven't heard about us, but for the last couple of months we have twice the monthly uniques as these two combined, or these two combined on our website. So who the heck are we and what do we do? That's the idea. I'm gonna tell you, you're gonna leave here. The one thing I want you to take away is I think 2012 is your data as a service. It's your focus. What's driving that? It's all of this stuff. In 2009, we talked about coming trends, mobile phones, tablets, televisions. We talked about scale. We talked about the way people would write applications and where they would run. These were ideas. These were specs that we argued over at that point. 2012, these are real. These are in production and they're new and big markets. Do we really wanna focus on no sequel, new sequel, the technology? Or do you wanna get down to doing what it is that you do, what you believe in, what you're passionate about, leverage these new technologies and live in this really rapidly changing world and get down to what matters? And I think the message that we're seeing from the market as it involves and why people are using cloud and coming to it just to random inbound channels is that to win in the space and take advantage of this, focus on the application. If you're a game developer or a studio in IndieShop, you're trying to deal with the fact that you don't get a $30 million budget up front in three years to put a game on a console and ship it to Atari and be done. It's a totally different world. You've gotta live in the world of client server. You don't know that. You've gotta live in the world of mobile and social and you don't know that. You could either try to become an expert and deal with it that way and operate everything yourself or you can try to offload the part to a service that does it well. We're comfortable doing this with infrastructure now in the cloud. And I think that what we're seeing is maybe not a complete platform play but that data as a service for your application is something that makes a lot of sense. So I'm gonna tell you about that, how we provide that and some of our customer stories. Okay, but please, please stop and ask questions. And if you don't have the guts to raise your hand and derail me with a question, then do it on Twitter. Yeah, a few and I'm gonna talk about that in detail. The simplest is scale but really I mean, when I was at LHC I ran what was called data operations. We had a five to $10 billion project. It cost probably millions of dollars a minute when it was running and it never turns off, right? Dealing with 10 gigabytes a second of data for eternity and shipping that for the lifetime of the project and shipping around the globe is a tremendous operation. It means that you had to build systems or you had to run systems. You need a team of people and you have to understand how to keep that running. Just, I don't call it data management because you'll always have to understand what your data is, how you model it and how you interact with it. But do you really wanna run the service, right? We heard it this morning from Swami when he was talking about Dynamo. DynamoDB is the fastest growing Amazon web service ever. Why? It's like the simplest, right? And they've boiled it down to the bare roots. Dynamo itself as an internal service was great. Huge excitement internally and externally but it didn't have the uptick because they made people run it, right? Do you wanna run it yourself? And that's really the question. Sync, scale, distribute, these are all things that I'm gonna talk about but I think at its core it's about operations, okay? Focus on your core competency. There's a big market, go be a player in it. Good, more? Okay. I'm gonna present the company in essentially a slide just so you have a feel for the background. We started clouding out of MIT because that's what you do when you're at MIT. Myself, my two co-founders, Alan Hoffman and Adam Kokoloski until December or November we were seven people, all technical, we remain highly technical but we're growing rapidly now. We passed an internal threshold that told us the market is taking off, we basically made enough money, we passed a goal, we said, okay, we'll grow and now we've added quite a bit of the HP Vertica team at the upper levels, we're about 25 people now and growing to 40 or 50 by the end of the year. We're founded by Y Combinator and Venture Funded but we've built largely with customers in production and been very revenue focused from the early days. We are building what we call an application data network which is really this data layer idea that in the 90s if you had a website and it went big you could give money to Akamai and they made it fast and they got your content, your static assets to the edge, to the people that were gonna consume it and they scaled it out for you. We wanna do that for your data that's transactional, that's dynamic, that application state. We don't use databases anymore for dollars and cents and business ledgers, we use them to store the state of our applications to drive the end user experience and so we are doing that for dynamic content. We actually built out on about 25 data centers on the globe, I'll show that to you. We've done this by bringing our IP from World of Physics and hiding it behind the Apache CouchDB API where wire compatible with Apache CouchDB with some augmentations. Now I'm gonna go into why we chose that instead of another API through this talk. But really the idea is focus on your applications. We've got actually about 10,000 users in the multi-tenant service now, a large number of those paying in and a large and surprising number of enterprise applications building out on cloud right now. And I'll talk a little bit more about customer stories at the end. So real quickly, product one. And how many of you are actually developers or write code or are not scared when you look at code? Awesome, I'm gonna spend a little more time in the middle and ask me questions. I can go into more detail. But here's the deal. Imagine Amazon web services without the stuff around infrastructure and without the things about backend storage and batch warehousing. If you're here looking for analytics like backend batch analytics or ad hoc queries that can run in a warehouse with week long latencies and jobs like Hadoop, this is not the talk for you. We are focused squarely on applications driving the end user experience from the bottom up. I'm not even gonna talk about databases here. I'm gonna talk about application state, frame it all in the context of the application. We provide a hyperscalable document store. So it's JSON or HTTP. That's the CouchDB API. Means you don't need to install any client libraries to talk to it from your phone, from your browser, from your television, hopefully from your washing machine someday. So we think that's very empowering. One of the key reasons, right here, moving rest back up the stack is gonna simplify a lot of the challenges you have, I think, in adopting new technologies into the stack. So it provides asset key value storage and I'll tell you actually duplicate your data and triplicates the store on multiple data centers to be safe. But you also have secondary indices for flexible query. So right there we already diverged from DynamoDB. You can do a tremendous amount of stuff with the primary index by properly building your key structure and that's still there. You can do that. You can slice into the primary index and do range queries there. But you don't have to, okay? There's a flexible framework to build secondary indices that can be queried in order log and time over the rest API as well, okay? Very powerful. There are certain types of analytics that you'll need to be able to do at the application layer to really live in this space of big data applications, okay, big applications. Examples are aggregating leaderboards in a game, right? In real time or crawling a social graph in Twitter in real time to quantify the moments of depth and breadth to figure out which of these pieces of content was most influential. Whatever it is, the business value that you're trying to provide, we try to bring as much of that framework and ability to do parallel processing out of the warehouse and into the application layer, okay? Into the application data layer. So a lot of the same ideas, we do this via a MapReduce framework that runs incrementally on new modified or deleted data so that you can do this and have semi-real-time results for talking milliseconds to seconds depending on the complexity running in that data layer, okay? That's more than I'm gonna be able to talk about but I'm gonna show you some simpler things too. Applications always have search, right? I'm gonna say always because it's a rare application I find that wouldn't profit from having full text indexing and search and having that extend to numerical range queries and having geospatial capabilities as well, right? In the mobile world in particular, things are running in vastly different places. So we've taken Lucene and we're gonna be making a big PR buzz about this in September. We have a lot of experts in information theory that have built multiple systems for the web and for the enterprise. We've layered Lucene incrementally so that it will automatically index your data as it comes in so you can choose the analyzers, the stop words, whatever you want. You don't need to stand up your own search service. You don't need to build an elastic search cluster and run that yourself. You get that here and it has actually a decent fraction of geospatial capabilities now and that's growing. Currently you can search near things. You can start to put together some trajectories, et cetera. And it's all exposed via the standard Lucene query index. And actually we store application objects as well. So it's not built like Amazon's S3 service to store large objects that are going to be infrequently accessed. It's built to store the things that your application needs. So we're talking thumbnails, images, audio, video if you're building an image sharing site, right? So things that are smaller than gigabytes typically but can be accessed in millisecond scales instead of seconds to get it down. Things that your application's gonna load into the browser every single time, right? So that's really what it's built for. But I think the best part is this all runs as a service and I'm gonna talk about that in a lot of detail which is probably the most important thing we offer to application developers. But we take that application state, we take your data and we synchronize it around the globe, okay? So we try to get it, building a backend database that's fast is fun. I've done that a few different times. But getting a microsecond or like nanosecond transactions is worthless if you're dealing with it over your phone and you're 200 milliseconds away from some global write master that exists. So blow away the global write master, right? Provide developers a single endpoint URL that is going to DNS resolve based on where you are. Whether you're talking to the data layer directly from your phone or whether it's from an application middle tier it's going to resolve to something nearby, okay? And the goal here, right? The end play is to try to have cloud clusters at the base of cell towers. Like that's what I would love to see and I'm gonna talk about our distribution as we go towards that. So that's real quick, the product line. So I just wanna pause there and see if there are other questions before we go on. I'll show you some examples of API usage. Anything here? Full set of CouchDB API. We have augmented the API. So if you wanna learn about the API you can actually pick up a CouchDB book and read it. We have some for developer stuff now and I'll show you how we're rolling that out to help people learn. But really this is focused not at trying to infiltrate the existing Java middle tier layer. It's understanding like new applications how they're being built frameworks like Backbone.js, Meteor.js, Angular, Ember, right? All of our, the majority of our examples are being cast in that kind of browser context if you will. Yeah. Can you say right or? We have a lot of our clusters are larger than most Hadoop clusters. Larger than many Hadoop clusters. Hundreds of terabytes. I'll tell you, we have a decent chunk of a petabyte of transactional data like not counting binary attachments under management now. So it's a surprisingly big service that none of you have heard of. So I'm trying to tell you about it. And I'm gonna go into a specific customer examples to show you some use cases and then actually I don't have slides on it but at the end I can take questions about what's it not good for because I didn't fill my talk with anti-patterns but I think that's often the best way to tell you what is useful. So here's an example. One of the things we love about the CouchDB API is you don't need anything installed on the client, right? If you wanna use a connection layer, you can. If you just wanna use jQuery, that's fine, right? That ships with your application into the browser state. You can also use one of a plethora of libraries that exists since it's an open source API for Python, for Ruby, for Java, for C, for C sharp. They're out there. We don't maintain those, right? We focus primarily on keeping the API clean and the backend service humming. So here's an example of connecting to a database using a jQuery extension, creating a document which is JSONified and tossed down into the database. Very simple, straightforward stuff. And if you're a Mongo user that should look very familiar except that it's running in JavaScript and I can write this in various other languages. And there's a rich part of the API which I'm not gonna talk about but there's support for bulk operations. You can actually get some surprising upload throughput if you need to. And every commit, whenever I say save doc, right here, whenever I push something into the database with a put to arrest URL, it's flushed to disk, okay? We make sure that at least two out of the three copies are flushed to disk with a full f-sync. And the model, we actually, one of the reasons we love CouchDB is we've taken portions of it. We use the storage engine and we contribute back to that project. We're actually the dominant open source contributor CouchDB now. But the CouchDB storage model is a pendulum and copy on write. That means you're never overwriting data in place. So it doesn't lose your data. And in the case of a total RAID meltdown or something on one of the machines, we store your data in triplicate, right? At least two data centers. So this is a flush and f-sync and you don't have to worry about it. Yes? Oh, sorry, that was a stretch. Creating a secondary index. There are a lot of different ways. There, sorry, there are two different ways to do this. There is the existing CouchDB framework where you write a map function, which gives you one document at a time in a server-side JavaScript context, okay? You can use JavaScript frameworks like underscore or low-dash or whatever you want, if you include those in as kind of extra libraries you wanna ship with your code. But this gets run data parallel on just the documents of years that happen to be on that machine. And so if you're on a cluster that say 10 machines, you have the horsepower of 10 times however many cores you have to do some work there. The idea is that you're served one document at a time and you produce some little stub that gets tossed into an index. And currently we support the CouchDB Btree index as a secondary index format, which you can build using the MapReduce framework. That's a little gnarly. How many of you write MapReduce? Okay, CouchDB was described, or Mongo was described as CouchDB without the crazy, right? For a good reason, because it's kind of crazy and I'm starting to learn why it's so crazy. It's way out there in terms of its vision, all right? But it's built from the context of somebody that's gonna be writing a JavaScript application. And it makes a lot more sense when you look at it that way. One of the things that we're working on is rolling in declarative query languages, okay? So that it looks more SQL-like. But already you can use the simple format to pick off the portions of the document that you want and toss them into a secondary index. If this is a Lucene-based index and so you're analyzing it with some Lucene analyzer, you can pass in the analyzer of your choice, stop words, things like that, all the Lucene stuff that you wanna add here. So you write a little snippet of code and push that into the system and all of your documents get run through that. Again, this happens incrementally. So if you're used to using solar or Sphinx, incremental updating of a full text indexer has been a challenge, traditionally. Elastic search is making that easier, solar is getting faster. But this is a framework to do this truly incrementally. So you can actually query an index like this immediately after making a document right and provide semantics that say, don't answer my query until all of the documents that have been written up to this point in time have been indexed. In the system, I'm barely gonna mention it, but it's multi-version concurrency control. It's very unique in that sense. So it can deal with high levels of concurrency. It's what it's built for. So to come in and query that syntax is very simple. You have a base URL, mic.cloudrun.com. I have a database name that gets tacked onto that. And then I string together a Lucene query. I'm gonna look for some value of grass in this field. And I can do numerical queries like this. So you can string together your Boolean logic. You can string together numerical or Geo stuff in that sense. And then you just make an Ajax call there in the browser and you get the results back. And the cool thing about this, I wanna be really clear, jQuery is actually pretty amazing. I never thought that I would respect JavaScript as much as I do. I wrote C and back in the day, even a little bit of assembly. It's all about speed and efficiency. It does some things very well. And this data layer and kind of a couch to be framework in general was really designed for the idea that when the application is gonna be running, not necessarily in a middle tier layer that's right on top of the database, but potentially in a browser and talking directly to that data layer, you've gotta minimize round trips. You just gotta minimize round trips. So it's built for concurrency. You throw all your queries at it concurrently at one time, and then you can just do whatever it's dollar.ajax.when or something like that, which will string together your queries and make it easy for you to trigger downstream processing when they've all come back. So if you have compound operations that depend on multiple queries, throw those in parallel, wait for it to come back and then do your work. And jQuery actually makes that extremely easy, which is why I think it's a powerful thing right now. So this is a standard Lucene query syntax. And so there's really, I think very little new to learn here. And the interesting thing is like even, even I think my mother could probably figure this out because she knows how to type Google queries and reweight certain terms and things like that. So we, instead of trying to invent new query language, right, like document query language or something that some of our competitors work on, we're trying to go with something very standard. Okay, and this is how you deal with it in JavaScript. This is an example. If you wanna try it out, you can try it out right now actually. One of the ways, about a third of our customers package applications directly as HTML, CSS, and JavaScript, push that application as a document with attachments into the data layer and serve that directly to the browser, okay? This two tier framework is something that you're gonna hear a lot about if you go to developer conferences. And it's really one of the radical kind of new way things, but it's very powerful because it lets you build an application very, very quickly. I wasn't even a JavaScript developer and I built this one, which is live here, okay? You can open this in the inspector, right? In your WebKit inspector and see everything about the application. But really all you do is this is an example if you wanna play with our new search service. I loaded up about a million documents which represent public data. It's lobbyist disclosure data. If you lobby on behalf of somebody, you have to telegovernment that once a quarter. And so you can see who lobbied, who they actually talked to on Capitol Hill, who they were representing and how much money they spent and where this took place. And it's really interesting. So this is built to drive applications. Here's an example of an application you can look at. Runs in your browser and you can type a compound query. Like I wanna see things around specific issue of health. They were filed in California in the year 2009 and half a million or more, right? And if you actually run that, it sends a single query to the backend, gets the results back into the client and you can laugh at my JavaScript code if you actually open this up in the inspector and just presents it to you in a table that you can click through to see the information. And it's interesting, right? Safeway and Oracle actually dominate the health-related filings in California in the year 2009. They spend a lot of money. Oracle spent the most if you dig into it. So it makes it very easy to go in and do that. Yeah, I didn't talk about that. So we encourage people to use SSL. So you can use basic author SSL. When you create accounts in the cloudrun.com domain, that gives you the ability to create an arbitrary number of databases within your domain. So mike.cloudrun.com is my domain and I can create DB1 through DB100 million. And we actually have customers that create hundreds of millions of databases for large applications, okay? Within a single user context, every database has a set of four permissions which are reader, writer, admin, and a middle one called creator which maps on a specific portion of the CouchV API. And those permissions can, you can assign those to anybody else in the cloudrun.com domain. So if you have another user, you can share information at the database level. And database, all queries exist within the context of a single database, okay? You can choose to share information between those databases a few different ways by moving it from my bucket to your bucket, right? If I want to. But really it's going through these kind of four permission levels. So this one has only read privileges. So you're going to get back a 409 unauthorized, is that right? If I give you permission, I mean by defaults only I, only user ML Miller has permissions to write to mike.cloudrun, MLMiller.cloudrun.com. In this example, that doesn't have to be the case. I want to be clear, two thirds of our users, standard three tier architecture, right? One third of our users and a growing population are talking directly to the data layer from the television, right? And doing pretty novel things. And for them, that distribution around the globe becomes increasingly important for low latency experience. I will say that that two tier architecture, the biggest challenge is great for data consumption and for specific types of data creation. It's not great for all applications because there are questions about, you know, off off and how that gets mapped into the HTML5 spec that I think are kind of unsolved by the community. So I'm not going to walk out of here wanting, I don't want you to walk out of here thinking this is the way to solve all problems. But it's actually quite applicable to a large number. And I think in the big data space, there's like this perfect storm of the ability to store a lot of data, process it, but the challenge is like, how do you disseminate it, right? The values and the application and putting it in the context of the end consumer. And I think these two tier apps are great for data consumption, I really do. And so if you go to examples.cloudrun.com, or I'll show you a link later, all of our developer framework, instead of writing API docs, kind of the old static way and putting our information in books, we're building live applications that you can interact with in the browser, right? So we embed these examples as live things that are in the browser to play with. It's very developer centric. Okay, so I'm probably going a little slow, so I'm going to gloss over some of this. But let's look under the hood a little bit. We are built out on over, I think over 25 data centers around the globe now. It's on a mix of providers. There's still a dash of Amazon for our Heroku pass through, okay, we're partnered with a lot of people like Heroku. But we're primarily on software, Joints, Rackspace, Windows Azure is the latest one that we've launched on. We're the first Linux app running on Azure. And our goal, right? Currently we're in about 20. These are representing clusters, and I'll tell you what that means. But the goal is to get as close to the end consumer as possible. Whether the end consumer is a rail stack that happens to be living in Brazil, or the end consumer is a television that wants to talk to the service, we want to get to the edge, okay? That's our game. Within one of these, what I'll call a cluster, that's a set of machines that can be scaled horizontally, arbitrarily. Minimum is three, because we store three copies of your data, okay? One on each machine. Put where the document comes in, it gets stored to three machines. It's very dynamo inspired for the primary document stuff. But the key thing that we do is we take a cluster and we put two thirds of these copies in say Dallas and one third in San Jose, okay? This communication is all distributed or lang. It's all available to the developer through the semantics of Quorum. You can enforce full consistency or relaxed consistency depending on a transaction by transaction basis. It's available as a multi-tenant service. If you sign up at cloud.com, you can choose one cluster. Or the big thing is private cloud clusters where we basically pop this off for specific providers and SLAs. Between these clusters, say between East Coast and Europe, we use a version of CouchDB HDP replication. This communication all happens on a private network. This communication happens over HDP behind SSL, okay? And this is the stuff that asynchronously transfers data as a user is working in Brazil, say transfers the data back to the US. So if I get on a plane and I go there, I have my data in the US as well and I have a low latency experience. That can go cluster to cluster, right? On big, fat pipes from my provider. Or it can go over this wireless to a disconnected device like your laptop. You can, as a developer, use a filter to get last night's data into a local CouchDB server. Plane, vanilla, Apache, CouchDB on your laptop. Windows, Mac, whatever you want. And take it on the train with you or take it on a plane. And it can go to an edge database cluster which are the ones that we're trying to get to the edge. So currently we're on 25 data centers with the Microsoft edition that gives us access to 85 more, right? We have a pathway to get to the edge. We count, if you look at the data that we're allowed to talk about in public, that's under management. It's on the order of 100 terabytes. There's a lot more than that in some installs that we can't talk about. We count databases in the hundreds of millions, okay? The idea here is it's a collection that you can use to encapsulate user data if you want to. And so for a lot of sharing, they're kind of like you want a private high cloud. This is a framework to do it. And we count IOs in the, I don't know, trillions or pet IOs at some point. So it's actually big. It's been in production for two years. A lot of that was beta as we were building, but now we're really focusing on getting it out and making it easy for developers to use it. So I'm gonna close up with a bit of marketing propaganda here and flash through this and just tell you a little bit. One of our first customers was able to scale 20x and building a social media aggregator and sell it back. They have one FTE on the back and it deals with data modeling and building their application. I think they have maybe 50 terabytes at times in their cluster and we actively help them archive and flush out old data. The last week that it draw something was not owned by Zynga. We launched draw something in production at CloudInf. This is a quote from Jason Perlman, CEO one of our Y Combinator brethren. The big thing here, draw something. Yeah, they had scaling issues and CouchBase makes a big deal of this, but they actually came to us. And they were having trouble running the system that they were on before. It's not necessarily a knock on the system they were on, but running a new distributed system that say 20 servers or 30 servers on a cloud architecture is tremendously challenging. Things are gonna go wrong in that cloud architecture every day. And these guys were great at writing games but not great at running that service. And so we got them into production. Unfortunately, they got bought right after that so we're renegotiating, right? A great mobile story from a local company, Gain Fitness, synchronizing data down and for an offline experience on their phone using the CouchDB replicate endpoint. Don't need to install anything on the phone, just standard JavaScript or HTTP. And Monsanto is actually using this to store their genome sequencing data and do genome alignment in the browser. NoSQL is great for data integration. Last piece of marketing pitch, I have a few of these if you're interested, but Hothead Games is a classic example of company that has done well by giving it to us, right? They had an app that launched and actually went, this is an indie game shop, 30 people, one and a half FTEs doing data process. They're doing the back end work. They launched an app and within two days it went to number one in the app store. What do they do there? MySQL dies. They try to switch over to Mongo or CouchDB dies. You just can't keep up with it and it's not their core competency. So they came to us and they said, these ratings were totally bipolar based on the experience that somebody had because they're very latency sensitive and they have people and they're trying to send them to open card packs, buy those card packs with real money and open it and they had to have a consistent low latency experience, right? I'm saying consistent in the sense that you have to get the amount of money right in their account. So it's a nice example. So they came to us and said, it looks like you've had a win with some other game companies. Can you scale this for us? And we did, we got them up and within I think a day we had them up and they are making hundreds of millions of database transactions a day. I think the total number of interactions with the database is about a billion. If I take the peak and we got them onto what started as a small cloud and cluster, six servers in one place is now growing actually to I think about 85, okay? So we're able to grow with them in a matter of weeks and do well over 10 X scaling. And the cool thing is they started with this big win soccer and it's a pattern that they can apply. It's like a nugget of a game that you can apply or kernel to other domains. And so then they launched big win hockey. This one took off I think faster than a day to get into the top 10. And then big win baseball was launched somewhere in the early morning, West Coast time we were watching this. I think by the time Joel took a shower it had gone like to number 200. He had breakfast. It was like in the top hundred by the time he got to work that morning like 9 a.m. It was like number seven, okay? So this is meteoric growth, right? And it's a nice story and I think this is a place where data as a service has allowed them to do what they want to do, right? And this cluster, you know, the question from the gentleman just left is how big do they get? You know, the typical one is probably six nodes to a dozen, right? That's the mean, but there are plenty, you know, that we're talking about hundreds and moving beyond that. So they can get very big, very fast. And so I think this was a big piece of their success and the stats have been great. Now they have, you know, there's another season coming up. You can maybe guess what's gonna launch and when. So, you know, we're provisioning for that. So I just want to stop with one last question and ask who knows what this is? Nobody knows what this is. All right, what is it? Close, it's the same package. This is a personal DNA sequencer. It's available for sale, all right? Things that used to take a billion dollars in a major international initiative to sequence your genome will now be able to be bought for a border of $3,000. This year, I'm on order, but it hasn't been sent to me. These are harder to get than Raspberry Pi's. This is amazing, right? And just last week, George Church from Harvard stored five petabytes of data in one gram of DNA. He took his book, he transformed it into base four and put it into a DNA strain, right? I mean, this is an example that's out of context, but everything I talked about in the beginning that we used to look at is futuristic, right? Two-tier app stack, HTML5, right? Reaching out to the GPU from the browser, are you kidding me? Nobody's gonna do that, right? This is happening. It's happening now. And I think that, you know, this is the era of data as a service because there is amazing opportunity out there to be had and it's not about replacing existing things. It's about becoming agile and productive and winning in this new space. So if you're interested, we've been doing this for a while and we're just launching up the marketing machine now. We've brought in a lot of experts from Vertica most recently to fill out the team and we're, of course, hiring. But if you wanna take it for a spin, I'm particularly proud of the four developers section. We're eager for feedback, showing you how to use it, giving you live demo examples and actual example applications that run in the browser that you can just clone, download it to your machine and play with it on the plane on your way home or on your Caltrain ride back north. So give it a spin and plan for success. Thanks.