 Okay, we're back. This is Dave Vellante of Wikibon.org, and this is theCUBE, SiliconANGLE's continuous production. We're here live at MongoDB Days in New York City at the Marriott Marquee. We're talking about Mongo, its innovations, the developer community. We've got a number of practitioners on. Rackspace is here. Rackspace made a big announcement today with Mongo, hiding Mongo as a service. The first enterprise-grade Mongo. We're going to unpack that and talk to the folks at Rackspace about that. Kenny Gorman is here, as well as Chris Lalonde. These guys are both co-founders of a company called Object Rocket, which was acquired by Rackspace. Gentlemen, welcome to theCUBE. Thank you. So let's start with Object Rocket. We love the entrepreneur stories. So take us back to the early days of Object Rocket. What was that all about? You guys are co-founders, and tell us a little bit about that startup and how you grew and how you made the exit. Yeah, super exciting. I mean, Kenny and I have known each other for better than a decade, so we've always hung out and stuff. And at the beginning of it, we really recognized the need for a premium day-to-day service in the cloud. And so we were talking one day and we decided that we were going to go do it. That was really the starting Object Rocket. We started it early in 2012, and about a year later, we got acquired by Rackspace. It was quite the year. That's awesome. Yeah, so what was that like? How'd you get funded? How many people did you have when you sold to Rackspace? What was that all about? So we went through a round of funding, the Friends and Family Round. We were able to tap into our network of folks that we worked with previously. And they really saw that the project that we were working on was super compelling. And we thought we could bring to the table a new level of experience for MongoDB users. And so we worked with them to get a round of funding. It was just three of us for the longest time, some contractors and some help. And we just got it done. We cranked it, we were rackin' stackin', writein' code, doin' it all, so. A lot of late nights. Talk about databases of service. We're talkin' to Oracle the other day and they were tellin' us how they're doin' databases of service. What's the difference between, the databases of service that a startup does versus a sort of a traditional software company? Sure, I can answer. So I think a lot of folks out there are looking to kind of forget about infrastructure. They want to develop compelling applications. They want to have a quick time to market. And they don't really want to worry about all the intricacies of a database and cash partitioning and networking, all the stuff that comes along with running a database. And so, Object Rocket, it's a true database as a service, right? So what we're trying to do is provide an interface that's a higher order than maybe most other database hosters. And so that's why we built Object Rocket. All right, now you guys made an announcement today. Just hit the wire. Rackspace and TenGen team up to deliver the first cloud platform engineered for MongoDB solutions. Now there are other clouds that are running MongoDB. So specifically what did you guys announce and what's different about it? Well today we're announcing a partnership with TenGen. They're the MongoDB company. I think the combination of TenGen's expertise with Mongo and our ability to deploy, develop and scale Mongo is super powerful for customers. It lets people go from literally a small one gig instance up to terabytes of data all without seamlessly, without having to do anything. It's sort of a fire and forget and you can just scale. So talk about, I mean you can't talk cloud without talking about Amazon. They're kind of the gorilla in the same time they're the disruptor. So how do you guys differentiate? I mean when you were a startup, were you using Amazon? Were you using Rackspace? We weren't. I mean the key differentiator about Object Rocket and one of the things that made, one of the things that we really started fundamentally was that you can't take a regular cloud infrastructure and really scale a database on it. You wouldn't take a front end web server at eBay, put Oracle on it and expect that to run eBay's database. That just wouldn't scale for you, that wouldn't work. And so it's a similar principle. We have built our platform from the ground up. So we've gone and got our own data centers when we started. We racked computers. We specifically purposely built those computers. We've tweaked the operating system. We've tweaked the network interfaces. We've built all that stuff up to make a system that's going to scale with you from literally a very small instance to scale all the way up seamlessly up to terabytes, petabytes really, of storage. Now why, you said Chris, it wouldn't scale. Why wouldn't it? Is it just because the cost? I mean it would cost you a billion dollars to make it work? Is that the issue? It would. There's a bunch of challenges around scale that people don't normally understand. You not only have, think about it this way. Think about eBay. So let's step back to eBay for example. eBay had years before they got to a million customers. They had years before they got to a million customers and they still had scale problems early days. And they had scale problems, they had a lot of money and so they could go buy engineers and they could go buy a lot of hardware and they could go buy all that expertise. Now compare that to Instagram. How many weeks was it before Instagram had a million customers? So the scale problem has become super time compressed today and developers really need to focus on developing and getting their product built and not having to worry about that scale problem. And really the only way to do that is to sort of outsource your scale problem to a service and that's the real differentiator for us. We're trying to not only deal with the hardware, growing all that hardware stuff but also being the DBA for those folks so they don't have to worry about it. That's really the answer. So how do you guys, how do you differentiate from Amazon? So Amazon today is a general compute platform. Let's just call it that. You can run anything you want on it and it's easy to provision and it's fine. On our system we're tailor-built, as Chris was talking, tailor-built for MongoDB. So we've paid attention to all the little details that make MongoDB so great. So we're not a virtualized environment. We use a bare metal style approach. We scale easily. So the context of Mongo is inside our system. So folks need to scale, they can click a button and add new shards a MongoDB term for scaling new horizontally, new shards horizontally. So we provide those APIs and those hooks to scale MongoDB beyond what someone can do on a bare platform like something like Amazon. So you use bare metal, presumably because you just don't want a virtualization. So you don't want an abstraction layer in there. Correct. Slowing you down, right? That's right. So I love when I get practitioners on because you help me squint through sort of some of the vendor marketing. Because when you talk to the virtualization vendors that say, oh no, we can run our apps. There's no degradation of performance. You say, how can that be? There is, there is. And I think what they're saying is we can run, generation N minus two, compare that with what we can do today and there's no degradation in performance. But apples to apples. That's right. An abstraction layer is going to be problematic from a performance standpoint. That's why you choose to go bare metal. Is that correct premise? That is correct. And we've tried to focus on every bit of it, right? So our disk is all SSD. So we're all solid state. So the disk subsystem is state-of-the-art. Our systems are state-of-the-art, right? So we try to make everything state-of-the-art and give Mongo the best chance to have the best platform, right? And so memory partition was part of that, CPU partition was part of that, there middle speed was part of that, sharding was part of that, SSDs are part of that, et cetera. And so that also provides, talk about the security elements and advantages. When you go to non-virtualized, non-multi-tenant. Yeah, I can talk to that. So our system is, security has been a key tenant of ours. So in our system, when you provision instances, they're closed off by default. Users can go in and open an ACL to whatever, front-end application service that they want to run. So that's kind of one thing. The second thing is we're SSL-enabled. So we terminate SSL on our side. Customers can use SSL clients to us and be fully secure. And lastly, all our transmissions to our slaves, to replicas, to any other component within our system is all over SSL. And that's just to make sure that security is really a top notch, a first-level citizen in our design, in our architecture. So you mentioned, you use SS, I mean we follow the stuff, the scale out, the whole SSD, looking at all kinds of innovations going on there and the impact from an application development standpoint. I wonder if you could talk a little bit more about that. Just in terms of how, well, let me ask you this way. How does quality of service play in there? Now that you've got this capability of a persistent medium that's not spinning, can you begin to provision not only capacity, but performance as well and pin an application to that? Sure, absolutely. I mean the, you know, the sort of two technologies, SSDs and the new cards coming out with folks like from Fusion IO or LSI really are changing the game, right? Spinning disks are 1950s technology. Let's be clear about it. And we haven't done anything with those since the 1950s. It's basically the same thing made faster and stronger. So SSDs are really the future and those flashcards are the future, next generation things to go. It's a fantastic technology. You can do exactly what you're saying. You can start doing things like carving out specific IOPS per customer and give them whatever they need. You know, you can do it dynamically, right? You can be flexible with your IO sub-system, which is really the key component of this architecture is the IO sub-system has to be super performant. And if you can dynamically allocate that stuff, it gives you the best combination, right? You can like scale your IO sub-system, not just the box anymore, right? So you're saying I can through an API call, make a request for both capacity, 50 gigabytes capacity and a thousand IOPS, and then change that on the fly. That's the idea, yeah, that's the idea. So we have our other co-founder, Eric Beebe, and his staff have become quite experts in SSDs. So these guys are boy geniuses and they are working on sort of this next generation of flash storage. Today we have sort of a current generation. They're bringing in the next generation. So we're super excited about sort of the next level that we'll be able to take this game to. Yeah, so how about this notion of being able to actually change the way in which you write applications? So things like putting the whole database into the flash system or even doing things like atomic rights, I mean is that something that you guys are playing around with and how does that affect your performance? So we're always concerned about data preservation, data quality and availability. And so that's a key component with flash storage is things like write amplification, trim support, and making sure that we're really using the best of great components in these SSDs to make sure that we provide super available, super fast service. So that's part of what we provide. Customers don't even need to worry about it, right? They just go on our service. So you're architecting that. That's correct. Or however you do it. That's what we believe databases as a service is, right? All those things are under the covers. We take care of them. You don't need to worry about them. So really simplifying the developer's life. They can focus on writing algorithms or whatever it is they want to do. Yeah, it looks like, you know, part of the foundation of the company was I was trying to write an application and I just got super, super frustrated with having to configure everything all the time. And I was like, why doesn't somebody just give me a host name and a port that I can send my data to and get my data back out of. That's available all the time and that will just scale with it. Like, there just wasn't that solution in the marketplace. Let's start a company. That's right. That's awesome. So how many guys were you when you sold to Rackspace? Three. So we were three then, the three founders, and now we're seven. The team of seven are really great expert guys and we're continuing to grow. So we're hiring and we're moving on. Who are you hiring? What type of people are you looking for? It's really, it's actually generalists. The reason is that generalists have this idea of being able to work in all these different areas because that's what we're doing, right? We're not just developing code. We're not just managing servers. We're not just dealing with hardware infrastructure. People have to really understand how all those components fit together to make a really great platform for folks. So you guys live in DevOps. Yeah, that's right. Okay, so you're looking for people who can. Python folks, Mongo folks, systems engineering folks, any of the languages that Mongo supports, the driver Ruby, Node guys, whatever, developers and developers and DevOps guys that come help and build this out. Why Mongo? I mean, you had a lot of choices out there. Why did you guys settle on? I can talk about it. So MongoDB is an interesting beast. My background's in Oracle, we're at eBay and PayPal and even Postgres to some extent. But when Mongo came around, it was such an interesting paradigm shift to go from a relational to a document-oriented storage. It was so easy to develop applications on Mongo and so many of the popular use cases around today's collaborative and social applications around tagging and photos and rich media. All that works really easily in Mongo. And so like I was saying earlier, folks can develop applications and just not worry about the API they're using. They can easily serialize their data to an API. They can retrieve and write that data in a very easy format. It matches a lot of today's OO programming models. It's just really a natural fit. So how about scale? People often sometimes throw out a knockoff on Mongo. Oh, it's scalability issues. I wonder if you guys could talk to that a little bit. They're probably doing it wrong. Would you say that again? They're doing it wrong. Yeah, yeah. Well, add some color to that. You know, I think MongoDB's a fantastic API to develop against. I think as you start to run it at scale, there's some challenges. And I think those challenges are around, a lot of the things that we're working to solve, frankly, getting disk to memory ratios right, getting the proper speed of disk, understanding the profile of their queries, understanding the tuning of their queries, running things like componentry, like balancers and things in the background and giving the right IO to those things. Those are all things that we have to take into consideration to scale Mongo. Yeah, go ahead. I'd add in is that I think that Mongo sometimes gets a bad rap because people have put it in the wrong platform. They did what I was talking about earlier. You don't take a web server and put a database on top of it and say, that's going to scale for them. That just isn't how, like, that doesn't work at scale. If you've worked in a place that's had to deal with a lot of scale very quickly, you understand that a database has a very specific requirements in terms of CPU, IO, bandwidth, all of those things. And if you just think you're going to go and take any old instance off the cloud and throw a database, any database software, forget about Mongo, and that just isn't going to work. And that's, again, that's the key component of why we started the company. We built it from scratch to do that. So it'd be a great database platform. Yeah, you guys come from that traditional RDBMS world. So you see the changes going on. I mean, when Google had to index the web, it wasn't going to stuff a bunch of stuff in the God box. It wouldn't work, right? So when you look at the shift in the marketplace, I mean, what percent of the data sources out there actually need ACID and actually, you know, need to face commits and things like that? No, you're exactly right. You know, we've, as a, you know, humanity is just adding more and more data. And the fact of the matter is, is that it doesn't always need to be ACID compliant. There are very specific cases. And what's great, you know, what, the real advantage that developers today have is that they actually have now a suite of tools, right? It's not just Mongo, it's Memcache, it's a whole bunch of other, most people's solutions. That's a key point. That's a real good point. And that whole suite of tools allows them to develop different things for different, you know, processes. Like, again, if you're at some major place, you're not just using one single data source, right? You're using a set of these tools. You apply them to the right place. You have to be able to scale those things, but it is really that. And that's why this is, like, right now, is a super exciting time in databases in general. It's just awesome. Now, help me with this. I'm going to come back to that, too, because it is a super time for databases. So, help me unpack some of the dissonance here, because on the one hand, we're just talking about, you don't need necessarily ACID compliance and all this other traditional database stuff. On the other hand, you hear a lot of people, you know, certainly in the Hadoop world, and you heard Max this morning talking about, essentially, making NoSQL more enterprise-like, you know, hear things like backup and so forth. So, is that just a matter of maturity? You don't need to go all the way, or actually, is there an opportunity to go further? What do you see happening there? Are the old data warehouses a dinosaur? I don't know. I think there's more options in the toolbox, right? There's more tools in the toolbox. And I think the challenge for developers and DevOps guys today is to figure out what the right tool is for the task at hand, if you're in a big org, you might have a specific project within that org. If you're a small startup, you might have a particular workload you're targeting, whether it be social or gaming or something. So, I think it's really important for folks to go out there, understand the tools in front of them, whether it's a column store, a document store, a relational database, you know, Informatica or data warehousing and big data Hadoop-style stuff, they all have different places in the data ecosystem. And to figure out what they do best and why to use them and how to use them, I think that's the new challenge, not whether or not how you use Oracle, how you use any one of these tools. Yeah, and from a rack spaces standpoint, they want to provide as many of those tools in the toolbox as possible. And then let the peers and let the community do its thing to help people figure out what the right strategic fit is. Right, absolutely. I mean, the real idea here is to let the developer develop and really focus on, again, building their product, using the right tool to build their product. And we provide all of that backend scale and performance growth for them. And simplicity. Yeah, absolutely. That's exactly it. That's really the driver to Mongo, it seems to me, is to just simplify everybody's lives and then, as you say, maybe it gets a bad rap and scale, but as it matures, it addresses that over time and it says the challenge is right, you got to move faster than the market can move it. Here's what it's doing so. You mentioned now is a great time to be a database. 10 years ago, database was really boring, you know? The company's getting bought up, IBM and Oracle sort of and Microsoft dominate. And now this whole wave of no sequel comes along. I mean, it's not just Mongo, it's many, many others. It's super dynamic and, you know, what's great about the competitors in the field is that it's pushing, you're pushing the boundaries, you always have to push it forward. And that's why it is really a super exciting time. You're seeing all kinds of new technologies come out, people doing really different things that are really exciting and changing how developers develop and what we can have is applications really. All right, gentlemen, we're getting the hook here. This is a great discussion. I really enjoyed it. Thanks for coming on theCUBE. Really pleasure meeting you. Appreciate it, thanks. All right, keep it right there. We're right back with our next guest. We're live in New York City at the MongoDB days. This is theCUBE.