Tesora’s own Frank Days moderates this panel disussion featuring Chris Merz (Solidfire), John Dickinson (SwiftStack), Denis Vilfort (EMC), and Patrick Silney (Nimble Storage).
—
Transcript of Session:
Frank: Welcome everyone. My name is Frank Days. I’m the lead marketing dude at Tesora. That’s a title that Doug Shelley, our head of R&D gave me earlier in the year. I will be leading the panel on OpenStack, DBaaS and storage in the cloud. Before we jump onto the panel itself I just want to do really, really brief introductions. First, to my far right, John Dickinson. John’s got the most awesome title in the world, Director of Technology at SwiftStack. I think you would probably know Jon from his other job, which is a small job of PTL for the Swift project in OpenStack. Small job, big title, hopefully he knows a little bit about storage and a little bit about OpenStack today. Next to John is Denis Vilfort. I met Denis about 15 months ago during my very short and undistinguished career at EMC. After my previous company was acquired by EMC, I spent a 7 week window there, I met some great people like Denis and then joined Tesora soon after. Haven’t looked back, I think. Next is Chris Merz. Chris joins up from SolidFire. He came out from Boulder, formerly from the Valley. Chris brings his strong DevOps background, also a lot of DBA experience. He brings that together with this storage. You’ll notice he’s got a cast on his arm he had heard someone the other day saying something disparaging about OpenStack and the brawl ensued and that’s where we ended up today. Finally Patrick Sliney joins up from Nimble Storage. Patrick has described himself as the architect of the West. It was great to meet someone who designed the entire western part of the United States. But he works in Nimble storage transaction systems, banking, all across the verticals. I’m excited to have Patrick on the panel.
Why a storage panel? I mean this is a show about databases and this is a congress talking about databases. Well, what is a database without storage, right? We can’t have our database without more sophisticated storage. All these new databases that we’re coming out with, all the new database technology and all the current technology are really driving us to look for both look for more sophisticated and higher performing storage as well as lower cost more commodity like story, just driving really the market from both directions. From that standpoint we want to have a conversation today about how are storage and Trove related and what does that mean to all of us who are interested in OpenStack Trove.
The first question I wanted to ask the community and we’re always talking about use cases right, and we’re trying to figure out in OpenStack, who’s using OpenStack, who’s using different parts of it and where we find the storage that you guys are selling that’s ending up in OpenStack. What are the top use cases? Let’s start down on John down on the far end. You’re looking away. That was like my recollection of business school, when you try to look away from the professor and as soon as you look away the professor cold calls you. What are the top use cases you’re seeing for SwiftStack?
John: I think there’s a few different ways I can answer that. The first one looking at it from the perspective of Swift in general as just a way to store a large amount of unstructured data in a way that it offloads all those hard storage problems away from the client application, so they can just focus on making an awesome application. That being said, there are tons of use cases out there that are being used today and that are coming online every day. Everything from just storing all that unstructured data, the media that we’re all using on the internet, backups and document, sharing, anything that is storage on the internet, that’s pretty much Swift is a perfect use case for that.
It’s really interesting that recently SwiftStack specifically has been focusing a lot on the back up use case and I think that is something is especially applicable to people here today in relation to Trove. One of the things we’re seeing as like the partnership between Trove and Swift and how SwiftStack fits in to this overall community and things like that is looking at it from a perspective of great, you’ve got structured data, stored in a database, provisioned by Trove. That’s awesome. We need to make sure we have backups of that. There is a project out there that is automatically, by default, enabled to support that and it scales to massive capacity, supports geographic regions, supports all of those hard problems that you don’t have to worry about anymore because it’s taking over those, and that’s OpenStack Swift. From SwiftStack’s perspective, we’re there to help you enable and to make sure that you can integrate, and monitor and manage all of that.
Frank: Thanks John. So Denis, your company I think sells storage products right?
Denis: I’m afraid so, yeah. Can’t run away from that.
Frank: I know we talked before a little bit about I know EMC has really been embracing OpenStack from across the federation. Can you share a little bit about what you guys are seeing?
Denis: Yeah, I mean, it’s a funny thing, EMC, big company as you know. The leader in storage, all that, I don’t have to say that. We were sitting around kicking the tires like five years ago around the whole OpenStack thing. I think a lot of people don’t really know what to make of it. Then in 2012, we jumped in with both feet. We’ve been very active in the OpenStack community. We’re going to all the OpenStack shows now. What we’re really seeing is that OpenStack is a preferred way to consume storage. This is the funny thing about when we’re looking at the software side, we tend to forget that software runs on something and that something tends to be governed by Moore’s law. Moore’s law, as you know, says Gordon Moore, according to that phrase, when I was a young whippersnapper years ago, if you look at Moore’s law aggregated over the last fifty years, a long time, right, we’ve lived with this. We know that it’s ten billion times more firepower for the same amount of money today.
That’s why, probably not what I would say by happenstance, that you have folks up here that are all involved with solid state because solid state is the new way of doing things. You start saying, well that’s on the technology side, why is that because when you have more and more and more compute firepower the storage has to be able to deliver the data with lower and lower latency. The way you want to consume it is through an OpenStack abstraction. Sitting there doing things by hands, that sort of sucks a bit, so what you want is, hey I want a software layer. Actually, what we have done is we’ve doubled down on this big time at EMC. Sorry for the long answer. Here’s the thing, you know we all did Viper, right, you heard about that, software defined storage and then we open sourced that sucker. You can download that and totally play with that right now. That snapped into our OpenStack Cinder interface as well.
Everything we got, XtremIO, ScaleIO, 100% software defined, right. You’ve look at XtremeIO with 100% flash with inline you look at VMAX, you’ve got a VNX, you look at all the stuff we’ve got, there’s an OpenStack driver for everything.
I wanted you to know that we love OpenStack. We jumped in with both feet. We say hey, man this makes sense to us. We’re thumbs up.
Frank: Excellent. Chris, you want to share.
Chris: Yeah, certainly. So SolidFire is an all-flash array for those who don’t know. We’ve been involved with OpenStack for quite some time. In fact until just recently, our fellow John Griffith, was the PTL for the Cinder project, which is block storage in OpenStack. We’ve invested very heavily in the ecosystem and have been committed from day one to OpenStack because basically we don’t look at storage so much as a SAN or a monolithic storage system. We look at it as a storage layer for whatever type of cloud you’re building, whether that’s a public cloud, offering that service providers would build or a private cloud offering within a large organization, where they need to be doing self-service or have internal customers. Whether you’re using a charge back system or a credit card swipe is really just a matter of presentation. It’s all the cloud.
When you’re creating a storage layer for your cloud you want something that’s going to scale the same way as your cloud scales. In terms of adoption, some of our biggest customers actually back Trove with SolidFire. That’s one of the primary use cases that we have. That we ship nodes for. There’s also many, many cases where folks are not necessarily using Trove yet, but they’re deploying, when you’re going to deploy things that take up storage in a cloud, such as OpenStack, it’s going to be one of a few things. It’s going to be VMs, VDR and databases; these are the general use cases that you might have. Databases end up being a huge, huge area where people are looking to be able to have the performance they need.
Cloud is kind of an abstracted or virtualized system. The idea is you only want to use the IOPS you need for the application and not overprovision or under provision. Always make sure that you have guaranteed, available throughput and performance because capacity is one metric you can use, but not all capacity is created equal. I mean, if you’re using a 10 K spinning disc drive, you might have all the storage you need, but you have absolutely no throughput for your primary high-performance applications. The ability to decouple capacity from performance and dial in those IOPS as high or low as you need for every for every volume in your system, completely programmatically through OpenStack and through the driver, that’s what you’re looking for. That’s something that’s going to make the ease of administration, completely changes the entire OPEX, the entire way you do operations. I’ll try to cut it there.
Patrick: I’m glad I’m the last seat on the row. You guys have pretty much covered it all. It does come down to those use cases, so some of the customers that Alan had up on his slide earlier are customers that are using OpenStack on top of Nimble storage. They chose it because of those abstraction layers. They don’t want to manage VMs. They don’t want to manage infrastructure. They don’t want to manage storage. They simply want to deliver an application to their end user. And in some cases that end user is Joe Paycheck buying toilet paper online from their website store or in some cases it’s a large web service provider providing websites. You take your pick. Whatever that business is, it’s all about simplification. For a model to deliver that simplification is all about again, your architecture, your engineers, not having to make 20 design decisions before something goes from the dock to production. We should be able to go, like any of us, take that product, roll it out of the bits or the box, put it into production and get it going quickly.
We’re spread out across all verticals. As I said, there were a couple up on the screen there that are actually using our storage underneath OpenStack. We’re committed to the Cinder driver development and more importantly, we’re very, much like you, focused on what our customer demands are. We had one specific customer who really loved the clone technology, the ability to take a volume and immediately turn it into a new set of VMs based on the same dataset. We named the feature after him, Itosom from Japan. We had to come up with a cool name, so image transfer optimization. Again it’s all about delivering that simplicity, the features the customers want.
I think from my short stint at EMC one of the most famous things we said was our best ideas come from our customers, best product ideas. Standing on the shoulders of giants or great artists steal, however you want to look at it, delivering the functionality to our customers, one, and delivering at a rapid pace, while not breaking the bank. It was interesting in Alan’s talk, OpenStack as a cost saving measure was I think the third or fourth most popular reason, but we know that, especially in the cloud model when your business is telling you, save money, go to the cloud, you know it’s not always about saving money, it’s really more about a agility, delivering better services. We see our customers considering OpenStack, but if the first thing out of the executive’s mouth is I have to save money, okay, we’re going in the wrong direction. Let’s talk about how we can do this more efficiently and in the long run make you more money, but in the short term we’re going to put some effort into making this work. There is no free lunch.
Frank: All right. Now we’re going to move to the sped round here. We’ve got good introductory answers. We’ve given everyone a chance to get their basic airtime and make their plugs. Let’s jump into a little bit more of some of the nuts and bolts of what we’re talking about today which is the first question. I’m going to go back to Patrick, two sentences or less.
Patrick: Thank you.
Frank: What do you see is the greatest challenge facing your customers using databases in a cloud?
Patrick: Two sentences.
Frank: Two sentences, maybe three sentences.
Patrick: Most critical challenge, and unfortunately it’s an insurance discussion, is data protection. We see customers investing a significant amount of money in the infrastructure to run database as a service, but data protection has always been an afterthought. For our customers it’s getting them to think differently about data protection and leverage the technology that’s built into modern storage arrays in the form of snapshots and replication for data protection. Three sentences.
Frank: Awesome, awesome.
Chris: All right. I’ll try to do it in two words. Noisy neighbor. That’s what the customers who come to us are looking to solve.
Frank: Okay.
Denis: I don’t know if I can do it that short, but I’ll try. I think the biggest problem is that databases are inherently an amalgam of data and metadata. Because the metadata is explicitly expressed in the table structure, there’s really, unless you do the tables right, there’s very, very tough time automating data. You end up with a big database in a big blob. As databases get bigger and bigger and bigger, it’s probably not going to fly. To give you a quick example, I asked a customer, hey do you actually put in a date stamp for the last time that record was accessed, and she said, no I only put a date stamp in when that record was first created. That’s a problem because that means we can’t do things like information lifecycle management. As long as we treat databases monolithically, I don’t think we can automate them to the extent we need to as they grow in size.
John: I think I know something that can solve those big blobs of data with metadata all together, really well at a large scale. Specifically related to the database problem, I would reflect that answer that you already gave about durability of your data and backups on that. Being able to make sure you have some sort of DR story on that. Obviously we can do a lot more with that with an object storage system. Looking as a target, as a place to put your backups in a place that can be automatically, geographically replicated and maintained at a very high availability and a very high durability is specifically what people come to us asking about with relation to databases. Or potentially even just saying, look I’ve got large blobs of unstructured data, don’t store it in your database, put it in the object storage system.
Denis: Absolutely
Frank: Excellent. I’m going to mix it up a bit here. This is the classic not going up and down the rows, but I’m going to pick a random pattern here on the next question. Chris, next question comes to you. Since this is a question that you actually wanted to see if we could dig into a little bit. What would you describe as the Achilles heel of DBaaS?
Chris: The Achilles heel of DBaaS in many situations is shared resource contention. This has been a problem for everybody who has ever tried to use the same storage system for multiple databases. You have your production system running just fine one day and all of the sudden IO8 is through the roof, you’re getting horrible performance, everyone is jumping up and down and yelling, you call and find out that either internally or externally your provider has another system running on the same storage system that is doing a re-index or something completely mundane that is sucking up all the resources. That goes back to that noisy neighbor problem. You have someone who is just taking more than their fair share.
If you’re using the same storage system for everything if you’re not taking a either monolithic or dedicated siloed approach or you’re trying to get away from that or you’re trying to get away from the podular approach with pods, various types of islands of storage, if you’re trying to use the same storage layer for everything, how do you guarantee quality of service for all the performance applications. How do you make sure everyone has what they need and isn’t able to, Cartesian product gets done and all of the sudden it’s over, you’re just completely burning the disc. That’s where any storage system should have, at least some time of tiering, if not full blown quality of service where you can designate minimum maximum versed IOPS.
Frank: Patrick, I see you shaking your head over here in agreement.
Patrick: Oh yeah, very common problem. In Legacy thinking we would overprovision storage in order to get to the performance required challenge being that we don’t know what performance will be required in a lot of these cases. As Chris and I spoke earlier, we’re in violent agreement on a lot of these topics. If you’ve been doing storage long enough, as soon as you start consolidating apps into an array, well he also threatened me with that arm, as soon as you start consolidating apps into arrays you run into challenges. I don’t care if it’s the largest most expensive box on the market, or the hot new startup, you can always be harmed by your own success. My hope is that Trove as a business, as a model takes off. The challenge that I see, the Achilles heel, is being a victim of your own success. Classically, again, standing on the shoulders of giants.
If we’re inserting metadata into databases so that we can expire records over time, I don’t know when that will be a reality except in existing Z system mainframe environments. On the flip side there are many vendors taking different approaches to day life cycle management. The fact that a lot of database environments are still stuck in the 90s in terms of data management, where if I have Dev test, UAT, Patch, you name it reporting any of those functions that I have to do on something other than a production instance. I don’t want to impact a production instance. We’re still in many cases dragging data across an internal V switch or an external actual land switch and moving that data across the environment. It seems like we’re chewing up hundreds of terabytes of storage every day in some environments. To make copies of data that we should be doing, virtual copies or clones, take your pick whatever you want to call it.
The Achilles heel is we may apply data management techniques of the 1990s to a brand new methodology of managing data. We have a real opportunity to innovate with this project. I see that we can take advantage of it. We just have to have the willpower to do it.
Frank: Let me shift gears here, I’m going to go to the next question, which I’ll pose this to Denis. With an eye toward storage, how do you see database operations emerging?
Denis: I think we’re at an inflection point. This is something I talk a lot to our customers about. It’s important that we understand, and I keep coming back to that old saw about the fact that you’ve got to remember that this stuff runs on something. Let’s take a look at what it used to run on, right. Back in the day, if this was ten years ago, we would probably have a nice little discussion about a clarion and how many spindles it can scale to and whether it was the symmetrics and how many spindles we could stick in that.
It’s very interesting, I had a customer come to me recently and say, oh I just bought 250 K drives for my VMAZ. I was dumbfounded saying, why on earth did you do that? The poor person said, well I need the performance. That’s actually the mindset we’ve had in the past. I’m here to tell you, don’t do that. Don’t use 15 K mechanical drives in today’s world. You’ve got to use flash. It’s no longer an option. It’s absolutely mandatory. A very important observation. Let me button this up. Three weeks ago we had the flash memory summit here in Santa Clara. Samsung, which is one of our strategic partners, showed a 2.5 inch form factor SSD, but it wasn’t really an SSD, it was an NVMe, basically a PCIE based device that plugged right into the motherboard. It was 16 terabytes worth of capacity, 800,000 IOPS. Now this is an important observation. Because EMC, to be able to do that in the past, would have had to string a bunch of spindles together and build a big refrigerator to be able to do that and the only way we could have such an expensive machine even financially viable was to advertise it with a lot of straws in a milkshake to everybody sharing it.
Then we get into the problem you guys are talking about. What is happening in terms of the future, which was the question, is that now that we have the power of the SAN in the palm of our hand and modern servers can probably have four to eight of these 800,000 IOP devices I want to run my database on something that essentially is hyper conversion. That changes things because that means, oh wait a minute, a hyper conversion inherently, even if it has two power supplies, has only three lines of availability. I have to have a software stack that can protect my data, otherwise I can’t afford to put it on there because if that sucker burst into flames right after I made a financial transaction worth two billion dollars then the money is lost. I can’t have that.
This is the challenge we’re facing in terms of storage. We’re at an inflection point towards hyper conversion, it’s power to save, and be every servers at this point in the game, yet we’re not stopping, were building big, big horizontal scalable storage stacks. ScaleIO is a thing you should download for free, just to play with it. That’s really where this stuff is going. It’s weird to hear an EMC guy say, I’m not so sure we’ll have a say in to any great extent in 20 years, but that’s probably where it’s going.
Patrick: Most of you heard it here first, EMC just said free software, and don’t buy 15K drives.
Denis: Free software, OpenSource.
Patrick: We’re taking selfies after this.
Frank: Let me ask John that same question in terms of the evolution of database operations. You may take a, Denis was pretty upmarket performance, performance, performance.
Denis: And distributed right.
Frank: And distributed.
Denis: Yeah, two things.
John: I’m not sure. I’m not, and I’ve never tried to claim to be a DBA or someone who is intimately familiar with that sort of thing. I think what’s different is that with a provisioning system like Trove and like you see with other provisioning systems inside of a OpenStack, the infrastructure administrators, if not actually application developers, depending on how that’s deployed, public cloud, private cloud, things like that. They actually can start treating the infrastructure resources as these programmatic constructs. That is the essence of what you get out of current buzz word de jour of DevOps and agile thingies. The point though s that it gives an enormous amount of flexibility and it does mean that the way that you are actually doing operations and management changes. You don’t just go build one thing, build up a silo for that application and then move on to the next thing and start building up these inefficiencies over time. Instead you’ve got something that can be provisioned on demand, which is very, very interesting.
How that actually is going to shape out and what that actually looks like I can’t particularly tell you, other than it’s different. I think we have different views on hyper converged and things like that. I think the point though is that, you’re getting a lot more on demand flexibility and power to the people who are managing it and running the infrastructure and taking that away from a particular, I don’t want to say vendor per say, but at least a particular isolated stack of hardware and software together.
Frank: Ok great. What one thing is missing from OpenStack storage today? Any sense of that John, think about what one thing. What one thing is in the top of your list?
John: It depends on how you’re looking at that. Obviously I’ve got features coming out of my ears for things we need to be doing inside of Swift, for object storage particularly. That answers not the general question. Inside of OpenStack for storage, in general, we’ve got database provisioning. We’ve got an object storage implementation. We’ve got block storage provisioning. We’ve got shared file system provisioning with Manila. I may even be missing some other things there.
To be honest I think that in that sense, we’ve kind of got the bases covered as far as how are people going to use and consume storage and what we need to do there. I don’t think we need to be looking out for what is the next kind of new project we can have inside of OpenStack that’s going to solve all these whiz-bang storage problems, half of which are just invented so I can make a new project. What really we’re missing, and this is specific for storage and generally applicable to a lot of OpenStack, is the applications. What we’re missing is the killer app. What we’re missing is all of the boring apps. What we need to be focusing on there is how do people consume this. How do people focus on the applications? How do we focus on those back up cases, use cases? How do we make sure that the next apps, by default, choose OpenStack projects as the obvious and default choice by which to implement, develop and deploy their applications? Why are the giants internet properties that we use and consume today, when they are building out their new product lines they should by default obviously choose OpenStack implementations.
That is the challenge going forward, specifically for storage, also for all of OpenStack, but looking on the storage perspective we need to make sure that there is not a segregation into different vendor drivers and only focus on those sort of things, but actually fight against the tragedy of the commons so, to speak. People need to contribute back into the core upstream OpenStack software with an eye towards ultimately the application itself because that’s what matters. It’s all about the applications. Nobody, not even anybody up here on stage, is excited about a hard drive. What we’re really excited about is Dropbox. What we really like are applications that can be used and consumed, that you can tell your mom about and you can see that everybody is using every day. That’s my focus on the object storage side of OpenStack, that’s what I think the integration parts as these different projects work together, working with Trove and how they’re interacting with Cinder and Manila and Swift and others. Those kind of things are what we’re focusing on so that we can enable application use cases.
What’s missing from OpenStack storage, it’s not a feature gap as far as we need to solve some other storage problem. What we need to make sure we’re doing is solving the application use cases and focus on that.
Frank: Let me spin it down to Patrick. I’ll go down to the far end of the board.
Patrick: Along the line of business use cases, it is going to be the unsexy applications. Swift is solving a problem that has existed for a long time, which is I have lots of data, I have no idea what that data is. I have no idea what the value is and so far we’ve just stuck it in a corner, usually we stick it in a file or somewhere. This gives us an opportunity to start solving that problem. But then from the business side if we think about who the consumers of OpenStack are on a grand scale, the largest customers, they’re solving a very particular set of problems. They want to be able to do something on a very large scale with reasonable performance. They want to automate a lot of those operations. If we think about the other problems we can solve here is, there are a lot of governmental organizations with shrinking budgets and also have talent gap that they don’t need more whiz-bang features, they need functionality. The 80/20 rule, they need 80% of the functionality of their existing package software with a reasonable support call support stack, and the functionality that meets their business requirements.
Think about your local municipality that has probably 20 or 40 instances of various database flavors scattered around the city, doing various tasks, if you can help them automate a lot of that process out, if you can help them reduce the burden on their DBAs by delivering this kind of functionality and working with the commercial vendors that the software runs on today. Again, we don’t want the users to have to rewrite their applications. We want to help them automate the management processes.
I know we all have a tendency to do this. I’ve worked in engineering organizations where it’s hard to get your developers to work on the really boring stuff that needs to be done like say integrating with active directory versus, oh, I want to write this cool new [unknown 29:31] feature, right. It’s easier to recruit talented engineers to work on sexy projects, but we have to really bear down and work on the things that matter to the end users, sorry the end users, the consumers, which is going to be the IT organizations, to make these processes less burdensome for them because again, we’re going to keep making larger and larger storage devices but we will keep storing more and more data. Every year IDC tells us that we’re going to store however many jigabytes, what was it 1.21 jigawatts. We’re going to keep storing more and more exabytes, petabytes, yottabytes of data. My example again, your local municipality doesn’t get to escape that reality either.
Frank: Awesome, well thank you Dr. Brown and your jigawatts reference. Finally as we’re kind of running out of time here, I just wanted to ask the last question and I take this prompt from my boss who did this at the last summit for a question. I’ll end on a positive note with a fun question. If OpenStack Trove were a car, what kind of car would it be? I’m going to jump on Chris first.
Chris: A Toyota Highlander Hybrid because not only it can it store a whole lot of tenants, it’s got three rows and everything. It’s efficient. It’s more efficient than your regular system, making maximum use of resources, 20 miles a gallon for that sort of vehicle is pretty good. Not to mention you can dial it up and get some serious horsepower out of it, if you have the right storage layer behind it. 280 horsepower is nothing to sneeze at. Yeah, Toyota Highlander Hybrid.
Frank: Denis, want to give us next here.
Denis: I’m not a car guy, but I’ll tell you if it ain’t electric, it doesn’t fly in my book, so it better be something like a TESLA Omnibus. How about that? It hasn’t been invented yet, so we’re here to invent this stuff together. We’re working it. It’s a journey. My biggest sort of footnote on that would be, we all know too much and the trick for us to do is if we have just a smidgen of grey hair or anything like that, we know too much. What we need to do is we need to go back and say, I pretend I know nothing and then we have a chance to actually be as innovative as the 16 year olds who are just hacking code together in their basement and that’s what we need to do. Let’s build the future together. Build the next generation car. Sounds like a plan to me.
Frank: All right John you’re up. What have you got?
John: I was thinking about that. What would it be? Trove is a provisioning system. It’s not the actual database implementation itself. In my opinion, it’s not actually the one that’s storing all your data. It relies on something else for that. It’s pretty good at giving you places to store your data and stuff like that. I’d say a fork lift. It goes around a satchel, underlying infrastructure. Hands you our exactly what you need, goes and fetches stuff.
Frank: If you got out in the parking lot you see a neon blue Ford transport van which I rented for the week. I thought you were going to say something like that. All right Patrick, bring it home for us.
Patrick: I’ll do my best to channel Nick Offerman from Parks and Rec. Trick question, Trove is a service, therefore it is Uber or Lyft.
Frank: Thumbs up or thumbs down. Come on guys. Great. Thank you guys. Chris, John, Denis, Patrick, thank you again for everyone. These guys I think are going to be around for the balance of the day if you have any questions for everyone. If you do have a chance again, I’d say Rosemary did a great job. Take a peek at the table over there. Pick up your copy of the OpenStack Trove book. Thank you.
The post OpenStack, DBaaS, and Storage in the Cloud with Trove appeared first on Tesora.