Jean Bozman (Director of Infrastructure Research, Neuralytix) moderates a panel discussion on multi-database environments with panelists Bryan Reinero (MongoDB), Brad Topol (IBM), Justin Michaels (Couchbase), and Matt Lord (Oracle) participating.
—
Transcript of Session:
Jean: My name is Jean Bozman. I’m the director of infrastructure and research at Neuralytix, which is a market research firm. Truth is, I actually know some of these folks up here so this is going to be fun. Ken and Frank asked me to come here today to do a bit of moderating, not quite a Charlie Rose, but moderating anyway. We’re going to go over an area that’s of great interest. Following up actually on the other things we heard from Alan and Ken, having to do with all right, we have all these databases in the enterprise, and the cloud, how do we live with that, what do we do with that. Let me just start by saying that our touch point here is that the cloud is fundamentally changed by computing and most importantly how we provision, consume, manage and interact with computing resources. We’re going to focus on that and of course that involves both SQL based and non-SQL based databases. There’s quite a lot facing the IT managers and the question is how do they cope with it.
To look at this subject we have four experts here as you can see. On my left, starting with that, we have Justin Michaels, from Couchbase here and Justin is a solution architect at Couchbase and responsible for driving customer success, actively managing technical deployments and supporting the Couschspace community. Next we have Brian Reinero. He’s a developer advocate for MongoDB. Right up the street actually. Helping the community of users grow. He helps people optimize MongoDB for scale and performance and he was a contributor to Java Driver. On my right side, we have Brad Topol, he’s an IBM distinguished engineer in the IBM cloud architecture and technology group. In his current role he leads a development team focused on OpenStack. He has cross IBM responsibility for coordinating its contributions to the OpenStack project. Finally, not least, we have Matt Lord from Oracle. He’s a project manager in the MySQL group at Oracle. Many years of experience in many environments actually. He spent the last 12 years working at MySQL. That’s the panel right there.
In thinking about this subject we wanted to know how has the consumption of database and database access, how has that changed. Obviously with the cloud and now with these OpenStack technologies through Trove. I guess the first question we can just throw it out to everybody, left to right, and see if they can all give a brief answer on this. How do we get to where we are today in having these multiple databases, most enterprises and even at cloud providers, how did that come about? Then, once we know we have them, how do we discover them? How do we visualize them? How do we operate them and deal with all these databases at the same time? Then, how does Trove help us do that? Justin, do you want to take first crack at that for a few minutes.
Justin: Sure. I think how we got here, it’s about use case. I think that’s where a lot of the discussions start as far as when you’re in the field and working with customers. I don’t think it’s a one size fits all type of discussion. It usually comes down to the application use case. As far as how we manage that I think that’s what the interesting part about Trove and being able to automate deployments and auto scale different type of clustering technologies.
Jean: All right. Brian, want to try that.
Brian: I think a lot of it is driven by the fact that services like OpenStack and AWS are providing infrastructure that people just didn’t have access to seven years ago. Maybe even not aware of as recently as five years ago. The notion is that if we have access to this infrastructure that we can scale up or scale down as we may need there’s going to be a new desire to leverage that kind of infrastructure, both for performance by scaling out and also by having a need for availability and redundancy in the systems. In the last decade or half decade even, as it’s accelerated, there’s this desire to use this infrastructure for large scale data storage and bandwidth. That means, as Justin had noted, it’s going to be based on the use case. How you need to scale what you’re doing and when you use systems that are distributed over a cloud platform. Management of a distributed system becomes obviously a greater challenge then just a single node. Trove in itself, just managing its single distributed system is highly valuable because you can operate on those systems with confidence, but when you get into a multi-database system being able to manage it all in one interface is going to be super helpful for confidence and deployment.
Jean: Okay, thank you. Brian, not Brian. I made my first mistake. Brad, too many Bs. All right. Go ahead.
Brad: Thank you for that heartfelt welcome. Thank you.
Jean: No problem. I love you too.
Brad: How we got here. Slightly different take. If you look back in history we had centralized databases and really focused on hey, I’ve always got to give the right answer back all the time. Transactional systems, very strong consistency. What we’ve seen over time is okay, there’s definitely a lot of that, but there’s a lot of applications, particularly at the cloud level as we get with greater scale where availability becomes more important. You see new databases come about like, CouchDB and others where they’re able to weaken the consistency model and go more the eventual consistency, which is a little bit less but still works great for the application and then really improve the availability. Particularly, if you have applications that are huge and have to be on a global scale or geographic scale. That’s where you see the multiple databases coming across.
The other factors coming into that is some of the newer databases work a little better with mobile applications. They don’t worry so much about, oh do I have the best SQL API ever. They think more about, hey, can I support a restful API, can I support JSON. That’s how you end up with multiple databases and the need for things like Trove to help manage the multiple database types. Then you’ll start seeing that next level of people wanting ease of use. I want database as a service. I want to do all that work I use to have to do administer and set up my pick your favorite database. I want to get scalability, availability, location, more for free. That’s the world we live in.
Jean: Okay. Matt.
Matt: I just want to say thanks again for chairing at the last minute.
Jean: No problem.
Matt: I lot of people don’t know about you filling in at the last minute.
Jean: Yeah, I just ran down the street. I put on a jacket first.
Matt: I think a lot of people have already commented on the main points. But, polyglot persistence is the norm today even for relatively small businesses. That’s partly because of the use cases. Each database server has its own strengths and weaknesses. Part of it may be about companies or products that you’ve acquired. Part of it may be your individual employees. They may say I’m a MongoDB guy. We’ve got to write this new application, so of course I’m going to use MongoDB. Overtime even relatively small companies end up with some MongoDB, some MySQL, some Postgres, some Couchbase, etcetera, some Oracle, some DB2. I think the bigger organizations have virtually everything across their organization.
The ability to have a single unified method for dealing with those is pretty valuable because each database server has its own way to manage configuration variables, its own way to start up and provision a new instance, to do upgrades, to do monitoring. To have to learn the monitoring tools and everything else for each individual database server can be a bit of a challenge for an IT organization. If you can abstract that, throw out a single interface for managing instances, starting them up, managing configurations files, accessing log files to do debugging, and monitoring, it’s pretty valuable. I think that’s where Trove has a lot of value. At the cloud level you obviously want to be able to allow internal organizations to provision a new database server. Say, hey I want this. Instead of in the past they had you call up Joe or Emily in the hardware team and say, hey, I need this four socket box, I have these hardware requirements and two weeks later you get it and you set it up with all of your software. Now with just a couple of clicks you can say hey, 32 BCPs, I need this many IOPS, and you have it all going. Now, Trove built on that to say, well I also want that to be used for MYSQL 5.6 and I want it to be part of a replication group and so on. I think there’s a lot of value in that.
Jean: I wanted to thank you for being the first person to use the word polyglot persistence. I did pick up on it at the coffee station. I know it’s becoming a more popular term, but that’s very helpful. Coming to your second point, you’re talking about skill sets. I think that’s really important. I think it’s kind of a soft sort of thing here, but essentially we saw this new PassWin database. Some people used to work in SQL server, Oracle DB2, and so on and so on and you had to learn each tool. I think what we’re hearing here with Trove is that’s going to make that easier. It’s going to make it more unified and give you a kind of leveling type situation for people in the enterprise. Brad, do you want to comment on that in terms of the skill set and how having a tool like this might be helpful.
Brad: Yeah. Any time that you have a tool that’s going to allow you to plug in a whole bunch of different databases, say into an OpenStack infrastructure and provide you a uniform interface that’s’ going to make life easy. It also takes care of a lot of nasty details, as you try and virtualize out. The big advantage of Trove when you build these images is it handles the attaching and detaching of the blocked storage, so people don’t do silly things like run their database just as the image and everything disappears when the image goes away or whatever. A lot of details hopefully going into place to give you that uniform ability to manage the different databases There’s that tension of how much can I do with a single unified interface. When do I have to call back out to the databases actual user interface for specialized things? The challenge for Trove is to figure out that balance, so it’s providing enough uniformity and value to make everybody’s life as best as we can. Do I get any credit for saying polyglot persistence, as the second one?
Jean: Yeah, you do.
Brad: I’ll take it.
Jean: That was good. Thank you. Thank you. And over here would you like to comment on some of these points about skillset, unified management, that sort of thing
Brian: Yeah. Absolutely. I think the day to day management is of course going to be a lot easier when you think in terms of interfacing with of all these database technologies in one spot. But implicit in this too is that if you think about traditional DevOps or Dev and Ops, developers adopt new technologies with verve, with glee. Then operations, its more along the lines of, my priority as an operations guy is to make sure the system is stable. Therefore, I may not be so happy to adopt new technologies. An important part of this ability to monitor all of your database systems from one interface is the idea that the ops load is decreased or simplified because you don’t have to manage multiple management systems, multiple monitoring systems. If it all integrates together, you’re going to have a capacity to adopt new technologies easier. You’ll get less resistance, which is an important part of being agile, being able to foster a polyglot persistence layer that all the kids are into these days.
Jean: That was the third person that mentioned that. It’s amazing.
Brian: Yeah. I had to be in there.
Jean: Justin, you have to go the same way.
Justin: I won’t mention it all.
Jean: Okay. But you’ll be thinking it.
Justin: I’ll think it. I think layer consolidation is important. I think Trove is helping with that as far as consolidating these platforms into a common interface. I think that’s one of the things that Couchbase is up to as well. I think it dovetails nicely with how Trove is approaching that same approach about choose the tool that makes sense for the use case that you’re trying to solve and then use a tool like Trove to help you kind of manage that animal. I don’t think that anything will necessarily go away, it’s just a matter of expanding and being able to support applications that maybe couldn’t have existed ten or fifteen years ago.
Jean: Yeah, I think before the panel, Justin, I think you were the one who mentioned there were different kinds of workloads, different kinds of applications and even in one work load and one application you might be tapping into a NoSQL or SQL database also, right, with both.
Justin: Yeah. We see that a lot with Couchbase. We’ll work with relational stores on the backend just because we come from a caching background. That was kind of where a lot of our foundation came from. For those that aren’t aware in 2010, Couchbase was formed by the merger of Couch 1 which was around the CouchDB project and Membase which was from the Mem-Cache-D project. Couchbase itself has a consolidated layer of not only a NoSQL persistence engine underneath the covers of a Memcache distributed managed cache. I think that’s one of the things that we’re trying to do is make it simpler to manage these large scale deployments and a lot of times the persistence going back to the word I promised that I wouldn’t say, where persistence isn’t only in the cache interior, but also in a relational store in the backend. I think that kind of a common type of deployment that we would see.
Jean: Very good. From where I’m standing, I can see that on the back of Brad’s shirt here it says hybrid cloud. I have to tell you that every vendor conference I’ve gone to, there it is, thank you, every conference I’ve gone to since spring hybrid cloud has been way up here. It’s been really pushed as the lead there. I think at this point it’s not even controversial people are doing hybrid cloud, but it does beg a few questions I’m sure you guys will want to answer, that is okay, I have my private cloud, or my cloud at my site, or my enterprise and then I have the one over there, maybe just to make it simple, one cloud provider, not more than one. How do I make decisions as an IT manager where to place my database? Where is it going to be and where am I going to want that database as a service. Any thoughts there. I like to say, moving around here in Silicon Valley, location, location, location. Where am I going to place some of these important databases or should I just split them up and divide them. You wan to start with that Brad.
Brad: Sure. At IBM we have lots of enterprise customers and these are great questions that we have. There are a huge number of customers where they’ve got certain databases that they know exactly where they’re going to be and they’re going to be on-prem. There’s HIPAA and there’s all kinds of regulations and a lot of data that they would never feel comfortable going up into a public cloud. We like to call that systems of record. At the same time there’s a lot of cool stuff that they want to do that typically has to deal with mobile and keeping track of what’s happening and summaries and what have you. That’s data that’s a little more free that could go into say, a public cloud. If they need it, if it’s Black Friday or whatever, and it’s a bursting situation, so there’s data that can go up in the public cloud or what have you and they can get the advantages across the two.
The key thing with dealing with these types of customers, and this is where OpenStack and Trove play a role, is how much focus we’re putting on OpenStack to enable interoperability. We’ve got a whole new project, RefStack, that’s focused on interoperability. We’ve done a whole bunch of work at OpenStack for federation to enable you to get access to different parts using standard protocol. All of this is sort of laying that foundation to give customers that choice and that ability to say, well here’s what I want to run locally, and here’s what I’m going to be comfortable with pushing up to different types of clouds, picking my favorite cloud.
Jean: Very good. On this side, gentlemen, do you want to take a hack at that.
Brian: Yeah. I think from the keynote as you mentioned, security is going to factor big into this. Typically when people think about their deployment, about where they’re going to put their database physically, it has a lot to do with availability and disaster recovery, but a strong notion about this as well is security aspects and that you might want to have the flexibility of the cloud and the security requirements of the private cloud, HIPAA compliance, FIPS compliance all that kind of stuff will factor into it. Again, the same notion is that when we talk about a cloud, that infrastructure needs to provide us with the amount of availability and failover that we need for our application. Not all applications need to have high availability. Not all of them need disaster recovery, but if we think about the kind of applications that were described in the keynote what would become known as systems of integration or systems of engagement, that users are out there and they’re doing competitive pricing. They want engagement with the application. They want it to be context relevant. They want it to be respondent to where they are and what they’re doing at that time. They’re not going to necessarily tolerate a downtime for maintenance or a downtime because the data center is in the middle of a network partitioning. That will factor into that as well.
Jean: Justin, do you want to add to that.
Justin: Yeah, the always on challenge is definitely I think another reason for the large number of vendors in this space as well. Trying to provide that always on, never down type of capability. But at the same time making sure that the data that is most important to the business is secure. Those are oftentimes competing challenges. Trying to make sure the data is synchronized, but also geographically available. I think that’s another area where OpenStack could potentially help facilitate and also keep things in synch between a lot of these different platforms.
Jean: Right. This is an exciting area. In fact, I’ve been sort of an HA advocate for quite some time. I just wrote a link, just to throw that in, on the Neuralytix website about three things that will never go out of style: high availability, quality of service and security. As we can see it came up organically here. Even though we have brand new databases, we’re changing things, we’re using the cloud, these illities keep coming up, and I think it’s just something that as long as you have IT, you’re going to have these requirements. And what came up in the context of the discussion on hybrid cloud as well.
I just want to shift gears a little bit, going back to slides that were up earlier about how quickly database as a service is growing. It’s growing quite rapidly. As I looked at the slide it looked like it was going from one billion to an estimated two billion dollars a year worldwide. That’s really fast. I just want to throw it out to the panel, where do you think this is going, not as an analysis, but in terms of the customers you see? How are they going to apply database as a service let’s say in the next year or so. What do you see there from your customers? Why are they going to that?
Brad: Can I start from here.
Jean: Of course, you have the hybrid cloud shirt.
Brad: We’re seeing a lot of excitement with database as a service in a variety of places. We see it at the platforms as a service layer. At IBM we have a platform as a service based on cloud foundry. It’s called Bluemix. It’s one of these things where as a developer you just have to write your small piece of stuff and there are a whole bunch of services out there that are restful base that you can go to the registry and use. They’re all born on the cloud, which means they’re all ready for themselves to be scaled. You get your little piece out, you push it out, you’re up and running. Then, if you need more scale you click a little button and boom the number of service instances go up. Really seeing a lot of traction there for database as a service. That’s one place we see it.
The other thing you see is the convenience. If you look at where we have our cloud database, its cloud and it’s based on Apache cached CouchDB. Taking care of all the nasty stuff for you as that database as a service. It’s going to handle doing all the triple replication that you need, so you have your availability and what have you. It’s going to do the auto-balancing and the sharding. People I think are going to demand that level of ease of use from their databases. I don’t want it to be like it used to be how many years ago, where I had to go get the data admin person, and let’s go figure out the tuning, let’s go figure out this. It’s going to take three months to get going. So much desire to say hey, I just want to get up and running and be quick about it.
Jean: Absolutely. Others want to jump in?
Matt: In my experience, anybody who is not using database as a service is looking into it. They want to use it. It’s enticing. For me, an easy way to think about it is, if in the past, in order to have a cellphone you had to go and get hardware and software all set up in order to use it. Whereas now you can just consume it as a service. All you need to do is just call up AT&T or Verizon or whatever, you get a service, your usage is metered, you pay based on what you use. That’s enticing in the database world, instead of having to figure out what hardware I need, which is limiting in itself because you never know how fast you’re going to grow. Instead of having to go out, purchase the hardware, get it all set up, get it configured, figure out how you’re going to monitor it, you can just consume it as a service. You can say, this is the initial hardware configuration that I think I’m going to need, I want it to be able to scale up and down when I have a cluster that can handle failover. It’ll manage the creation of the machines that are going to run it. It will manage the high availability set up, the failover. It will manage upgrades. It hides a tremendous amount of complexity
Jean: That sounds a lot easier. In my years covering clustering and high availability, the complexity and the difficulty was right up there with why people didn’t do it. And you saying now a lot of this is going to be easier to deal with day-to-day.
Matt: Well at a click of a button. At least for the consumer. The people who are going to have to be setting up OpenStack.
Jean: Yeah, behind the scenes. They still have to. Yeah, always true.
Matt: As a consumer you can just say, I want a cluster of five nodes, I want VHA, I want DR, and boom, it’s done. That’s just the incredibly attractive for an application team and the person managing that application team.
Jean: I think Brian had a comment.
Brian: Yeah. Database as a service, one of the biggest appeals are that I can be a client of this database as a service and then as a company or maybe a CTO of a smaller company, I don’t need to hire out the professional knowledge needed to maintaining a database, which is a extremely appealing. And of course, the expense, I’m paying for the service, but the expense is amortized with any other client for that service that’s also using the same platform, database as a service.
One thing to be aware of though, of course is that when you deal with cloud solutions, they’re going to be subject to nosy neighbor problems. You’re sharing infrastructure with somebody else who may be consuming a great deal of I/O bandwidth or RAM. These things can be mitigated I think as we move into database as a service it’ll be very important as a client for a database as a service to clearly articulate what your expected load back on the system is so that the provider of the service can know what is normal and provision for you. Also, articulate what your requirements are for availability. Not just uptime, but minimum time to recovery, because we often think of availability and how much, the five nines, I’m up the 95th percentile, I’m always up, but when there’s a failure on the system, the only thing people really care about is how soon can you recover. That’s part of the thing that we need to be clear about.
Database as a service is great. There are challenges as the service provider. We as clients need to make sure we articulate our needs to the service provider.
Jean: Yeah. And speaking of articulation, it’s very interesting someone noticed earlier, we do have competing database providers here. At the same time we’re all cooperating on OpenSource and Trove and everything else, there’s also a need for each individual vendor to highlight what their particular data source does, right. It’s kind of a coopetition thing, right, is that fair to say.
Brian: Yeah.
Jean: It’s both really.
Brian: At a higher level we’ve come to the think about the database environment that we’re living in right now as being RDBMS and then NoSQL.
Jean: Yes, right
Brian: But even within NoSQL, there’s a broad ecosystem of different technologies that operate for different cases with different pluses and minuses. A key value store can be very fast and lightweight, but it accesses a single type of access pattern. The way that you provision a key value store is going to be different than a relational database or something that has indexes that need to be supported. Knowing that difference could be important.
Jean: The customer needs to shop around as well. What’s on the backend? And Justin, your comment about either coopetition or the other point of view.
Justin: Going back to the hybrid cloud, that discussion, I think that kind of dovetails into this that even if you have the idea of database as a service, more than likely it’s going to end up being at a large enough scale, probably a hybrid solution. Most of the larger customers I work with, they’re looking at building a database as a service to leverage their existing teams. It’s not like you can just continue to go out and hire more and more DBAs or more and more IT folks in order to support an expanding business. You’re trying to leverage the skillset that you have and trying to leverage that across more and more applications that you’re trying to support. I think you end up in these hybrid modes and you also end up with almost an internal database as a service type of approach where no matter which one of the technologies you’re talking about and even one that aren’t represented here, you’re probably looking at a way to manage those at a reasonable scale based on resources that you have. Then when you’re starting to talk about DR and replication a lot of times that’s where the hybrid cloud could come into play as well.
Jean: This all seems to be relatively complicated in technical terms. I know, as an analyst, we often ask the question, how do we explain all this to the business manager. Have you confronted that? How do you take all this highly technical material and explain in perhaps simple terms as the IT people need to talk to the line of business people. We need to buy this or do this or whatever it is. How do we compress this down and say, what is the business value here. I’d like to hear a little bit more about that, the business value of doing this. Want to start on the right.
Matt: Sure. In general I think it always comes down to cost. You have reduced cost in that your application teams are able to innovate quickly. They can get the available RD hardware and software that they need up and running in minutes or even seconds versus days or weeks. They can get what they need immediately. They can easily and quickly scale. Also, as we’ve touched on a number of other questions; you need far fewer DBAs, far less expertise for each database management server that you use.
One other thing that we didn’t mention that I think is somewhat related to this is that Trove is really helpful in a multdatabase environment in that it helps you eliminate snowflakes or unique machines. If you’ve got n number of database management servers on n different OSs all across your organization, it can be nightmare for the administration team, the DevOps team. You have all these snowflakes everywhere. You don’t know what you’re dealing with. It really adds a lot of operational costs. With Trove, and with database as a service in general, you can centralize a lot of that, so you can control this is what a MySQL 5.6 database machine server is. I know that’s what it’s going to look like everywhere.
Jean: Making that quick reference, that no two snowflakes are alike, so it’s one off.
Matt: I don’t know if I get points for throwing out another popular, kind of marketingish term.
Jean: Kind of late in the day.
Matt: One person can say, okay, this is what a MySQL 5.6 or MongoDB 3 or so on server looks like. This is how the backups are done. This is the configuration that’s used, so you have control over that from a central location and then you know, okay, across my organization, I may have five different database servers in use, but I know that they’re all going to look like this.
Jean: Okay.
Matt: That alone has a huge value. It all comes down to costs and operational costs for the CIO.
Jean: So Brad, some more thoughts on business value?
Brad: Business value from a couple different perspectives. Obviously if you’ve ever seen the Trove UI and how nice it is that you can just pull down and once it’s all set up and we’ve got all our drivers plugged in and what have you and people built their images, you can just go down and pick which database and which version of the database that you want and click a button and provision. If you’re going down the path of the businesses starting to buy into wanting to run an OpenStack based cloud, that is the way to get seamless integration for all your database functionality through OpenStack.
The business value of being open in the coopetition is also huge. Think about what a great story it is to the customers to be able to say listen, this is all based on open infrastructure, OpenStack and Trove. The reality is there’s this large number of vendors that are supporting this, if God forbid my company doesn’t do a good job supporting you, you can very quickly, easily hop to another vendor or what have you. There’s a lot less vendor lock in because you’re based on something open.
People don’t always see this selling point, but when we go to the customers, there’s been such a switch between embracing open technologies, open source software , if you as a company want to hire the best talent, that best talent out there really wants to be working on something that’s open source based, open technology based because that whole notion of being able to do something out in the open and working with other people out in the open, besides getting to go to all the great OpenStack parties, which are awesome, that notion that people are able to see your work because what you’ve done and then you can collaborate with all the best people out there. When we work on OpenStack, HP has some incredible people that are doing certain parts, RedHat has incredible people, we have incredible people, you have the best minds coming together to solve a problem that a single company couldn’t pool their resources to do. You put all that together and you really want to convince the customer you want to be on an open based approach, you don’t want to be locked in, and things like Trove and OpenStack are the way to get you there.
Jean: Okay, so quick questions here and then we’re going to have the sum up. So, on the business value.
Brian: One thing I would say too is that cost, I think is a major, major factor. The calculus to determine how big your cluster should be based on how much bandwidth you expect can be quite complicated, but there’s another aspect in thinking in terms of business value is the opportunity cost. When we talk about systems that are going to be based on a polyglot architecture, we’re going to be managing multiple databases, we’re going to have multiple nodes, distributed systems in themselves are not the easiest things to manage and reason about. Having a tool that allows you to build these types of systems that are highly capable, easily and economically are going to save you the opportunity cost of not being able to perform that feature, perform that function, build the application that customers want. Someone else can eat your lunch on that. Having a system that allows you to manage these systems, gives you the capability with confidence to build these systems. That’s a big one.
Jean: Okay
Justin: I guess the only other thing I’d throw out there is, like we were talking about, we inherit a lot from what the business has been up to over the last 20 plus years or whatever, so I think that’s one of the approaches where microservices are starting to come into more building that around something that has existed for a long period of time and how do I manage that moving forward. And also, keep people interested. How do I maintain something that was maybe written in Cobalt and it’s still running today? How do I go out and find somebody that can help me support that as an IT manager. That’s important in creating microservices around kind of the monolithic animal that isn’t going away. That’s going to be important to keep in mind on how do I continue to support the things that are in my infrastructure and still be able to provide the flexibility and manpower to be able to be able to do that
Jean: I’m glad that you brought that up, the inheriting thing, because every time an IT manager walks into a shop they go, oh my goodness, this and that and the other. You actually have to do a discovery process, an exploration process and inventory to really see what you have in the first place. That’s terrific insight there Justin. I think based on the time, and anything is going on over there, there were a lot of things we didn’t get to. Everybody is going to be around the rest of the day. We might have talked about Hadoop and containers and security and distributed systems more. We have you flavor of database as a service, where it’s going. Now we come to my favorite part, the lightning round. The lightning round is, in about a minute or so all told, what would you like to see, how would you like to see this develop over the next year if we came back next year, what would you like to see have happened in this database as a service area or in Trove particular. Anything that you’re looking for in the next year or two. Who wants to start? We’ll start over here.
Justin: I’ll just say that I think from a customer perspective, the owning up to that push button deployment, if we could show that for the four of us sitting up here and actually be able to show that a year from now and production grade, I think that would be a big thing that I think from a customer perspective that people are actually after.
Jean: Okay. Brian.
Brian: Yeah, actually we have a cloud manager in MongoDB which we’re working to integrate with Trove that does have a push button deployment which is nice. I’m a big fan of developing cultures, internal technology cultures; I think part of that database as a service type of thing. More discussion about bringing dev and ops together so they’re working in coordination even if the developers are clients of the database service, fostering that kind of connection together would be really great. I think it would be beneficial for everybody.
Jean: Okay. Brad.
Brad: What I’d like to see and it’s very timely since one of my contributors to Trove is sitting there in the third row, there’s Asheida, the other one is on maternity leave, but definitely want to see more improvements in our plug ins that we have for DB2 Express-C and for Apache CouchDB, you know, back up, recovery, support and replication, better, tighter integration with Trove. We’ve got a long way to go though. We’ve got more to do. We want to see more done in a year. I’d also hope to see more folks embracing, sort of what Ken and others showed, with OpenStack and Trove starting to take off. More people trying it out. More customers seeing it. It can sometimes be a little hard to get started, but there are definitely people that are here to help you get started. If you want the benefits of OpenStack without the headache of OpenStack there’s Bluebox folks over there that would love to explain to you how that can happen very quickly and easily and how they can manage all that heartache for you, that we’re in, we’re trying to get these environments running.
Jean: All right and Matt.
Matt: For me I’m excited to see what happens over the next year with Trove in regards to the building out the cluster API, adding support for additional guest agents that utilize it. Up until today anyways, it’s largely been just single instance versions of whatever database it is. Of course you obviously start there, but what’s really exciting is as we build out on the cluster API, which I think in Kilo it’s only MongoDB and Vertica I think, but I know Liberty has support for I think Couchbase, some support for MySQL and Galera based offerings. I’m excited to see where we go over the next year in building out that cluster support so that people can leverage, a lot of the stuff we talked about was high availability, disaster recovery, so building out the clustering API and utilizing it for all the database servers is going to be a huge benefit.
Jean: The things that never go out of style. Right. Well I want to thank all the panelists. They had terrific insights here and as well there were a lot of things that you might want to probe into. We have our break, we have lunch, the Hadoop, the containers, how to distribute things where to place the databases and security, please feel free to do that and we’ll all be around the rest of the day. Thanks very much, we appreciate it.
The post Supporting a Multi-Database Environment appeared first on Tesora.