 Okay, thanks for joining everybody. My name is Kiran Dines. I work for Talent, and we're an integration software vendor. I guess that's why we might have been asked to host this panel today. I wouldn't call them Motley Crew, but it's definitely the key vendors, I think, in the NoSQL space. We have, I guess, starting from our left over here, we have Patrick McFadden representing data stacks. We have Dipty Borca representing couch base. We have Matt Kaplan. Callen. Callen, sorry, from TenGen, and we have Jim Weber from Neotech. So I'll let each individual, when we kick it off, basically just kind of give, I guess, their flavor in terms of what they want to get out of this particular session. But maybe just kicking it off, I just want to get a show of hands just to see who we have in the room. If we start off with who here is the developer or coder who works directly with NoSQL technology? Okay, good. Alrighty, you got a good sense. Who's more of an IT manager person that might be looking after either a dev team or kind of making the decisions of which one of these NoSQL databases are more should they be looking to use? Okay, good. And who is none of those things kind of more business or has wandered into this convention as thinking it was something completely different? Okay, best of luck. I guess we kick it off and start by maybe just throw it back to the panel. So guys, what do you think we can discuss today in terms of what is standards and conventions? Maybe just try to frame it for each person in terms of what you think that might mean as a topic, as a subject matter. So maybe we start with Jim on this side. So Jim, what do you think this means for people? So I think from a kind of IT management point of view standards are something that gives us a level of comfort. So we're looking for some guarantee that if my vendor goes underwater today and God forbid these venture funded NoSQL databases whatever go away, they all seem so stable that I can replace that infrastructure with minimal pain and fuss and keep continuity of service going. I also want to keep my costs low. I don't want to have to relearn things every week when the new shiny comes out and standardization holds up the promise of precisely that. Okay, so just a corner. It's protectionism against you personally who will obviously inherit millions and islands and all those great riches once said VC basically takes the cash. Something like that. Yeah, let's go with that. Okay, cool. Does that go for everybody else? Anybody else want to offer something slightly different? Or is it the protectionism or what else? What are the key things that we get from a session like this? What are we looking to try to achieve? I think it is about preventing getting locked into a vendor as we just talked about but it's a little bit more than that. It is being able to interoperate between multiple systems. Being in the integration space yourself you see the importance of a standard because you don't want to integrate with 100 different NoSQL solutions coming out but want to have one way of perhaps connecting with all these systems and that's the other aspect of it which is a more practical aspect where you really want to have a broader integration with multiple systems. And it also makes the conversation broad. It's not just one vendor saying here's how it should be. It really opens it up to the community, to customers, to users saying if we take a step back this is how this will fit in our overall enterprise stack and not just one vendor putting a solution out. Okay, so best guess, best estimate it took maybe 15 to 20 years, maybe 25 years to get to SQL in 92. So starting from today we've got some time on our hands to basically achieve a certain amount of standards. Maybe go a little bit deeper into sort of the tech in terms of maybe Patrick you think about what are the intersection points that you might say okay what are the best candidates you might hope for for standards that we could look for across the NoSQL landscape. What's possible? What's off? Completely off reservation, you can't do it. Probably the thing that everybody can agree on are the ones that no one wants to use or talk about security. Security is easy because everybody has to have it and it's a commonality. If we talk about things like query languages then we have to get into architectures. But if we talk about security everybody sucks at security and no one will ever be good at it. So if you can come up with the standards around that and there already are plenty of them but if you agree that we can maybe adhere to certain standards that are already there and then enhance it with others then distributed computing has a whole different problems when it comes to security. And is security different in NoSQL than you could say in normal traditional databases are there characteristics that are so different in terms of what you guys are doing or what you're seeing or is it just more of the same but as you say basically applying standards uniformly across all these different implementations. Well definition. I don't know. I can't put one vendor on this panel that doesn't have a replication story. Replicating data means that your data is spreading out. How do you assure someone that we're following some sort of standard that your data is okay when it's spread out? There are difficulties though, right? So at the surface level you bang on, right? We all need to kind of seal off attack vectors but then imagine things like authorization. Now on your stack, authorization could well be around atomic documents, right? This user gets access to this document. You guys probably have this more in common than I do. This user gets access to this document and you could apply some security rules around that which could be common. But on my stack the security would be a user has a path to some resource deeper in the graph and then kind of that's the point which I would diverge from you guys. You don't leave me behind giggling saying how you can't be part of our security party. So when you said architecture that kind of triggered me. It's architecture, it's also data model. It's kind of funny, right? No SQL we've kind of been lumped together even though actually I can enumerate four different data models even along this table and we're lumped together under the same umbrella and admittedly I'm the oldest by far of the data models represented here. Unquestionably, right? But it's not like you guys are identical either and I think anything that's going to be properly secure that you could really tie down in a fine grained and useful fashion is going to have to be accommodating our data model and I'm not convinced that standardization helps when you get down into that nitty gritty. It could actually be a hindrance because we'd end up being at loggerheads I need paths in security and you're like well I hate paths, I couldn't care less about paths. Shut up, Jim. Yeah I think everything that comes up to be the interface between right at the front end right of the database you would use SSL for example over the wire it's a standard, everyone would use it you know certificates and all that. As soon as you get below that and you start looking at granularity as Jim pointed out then you get into data models and the data models are so different with Oracle, IBM and SQL Server where it started off everyone at least had the same relational database and the same relational data model. They might have had different languages with PLSQL still being very very popular and over time DB2 and the others came up with a migration for PLSQL itself which was still not a standard. So I think the data model piece is where it needs to start. Again there's Bison, JSON, you know there's a column family databases every no SQL database is slightly different and even before talking about a query language if we do not have a uniform data model at the back it becomes very difficult to talk about paths or structures or arrays or nested objects where do you start if the data models are not not really the same. I see a lot of head nodding. So that's certainly a way you can do it but yeah that's what takes longer to really create some normalization of all that. Look at the automobile industry. It is somewhat standardized on the atom. A bolt has a measurement. It could be metric or SAE which is one of the standards. That's the thing about standards, right? There's so many good ones to pick from. So there's not a lot of convention within the automobile industry about the exact size of wheel base or how big a tire should be or any of that. They've determined that we'll all still use the same bolt sizing or that the steering wheel should be on this side of the car. And you know. Well Kira do we have that right in the UK? So if I build a standard car for the UK it's now on this side. So there's variation. As we refer to it as the right side. We're sitting here talking about whether we should have standards or not but I wonder if we should ask the audience a vote of whether they would like a query language. Who would like... Maybe it's an unfair question. Who would like standards? Let's just ask that. And then we're going to ask you to ask you the question, why? But who would like standards or who would like to see standards in no-ceful? Has anyone been put off no-ceful databases because of lack of standardization? I think they wouldn't be here. Exactly, right? We want standards. Well we've already got data in databases. We're getting a great deal of value from it. So what do I care? There are standards that we've got to think about from a consumer standpoint. How do you handle projects? How do you handle security? Security, security, security. Yup. And what do you think was the right to ban theory back then? We said, oh, it's not that's how we get everyone to ban theory. That's like it. I would like to say that what do you think is the right to present people with their model security or safety law? Well, the right representation is whatever I do. And I will now enforce UTI and deviate from your roadmap and waste your time building to my specification. Because that's the other side of vendor standards. They're a weapon in a commercial marketplace. And they can be used in that way. We all muttered earlier before we joined the panel about how actually we've all been profoundly damaged by participating in standards. I can't believe you're still smiling. We're all battle scarred. Actually, I would hazard a guess that all of us have seen standards being wielded in a corporate driven, politically motivated fashion. So the downside of standards is actually they choke competition and choke innovation. So be careful what you ask for. Because you might be like making a perfectly viable set of you, kind of disparate, kind of blooming environments of data stores boringly gray and the same. On that note of positivity, on that note of positivity, positivity came over here with the pre-writters, right? Yes. XYC also, at that time, if we all tried to what is the best product or the language for for all the big news and community, if you pick that spirit of the standards can be very successful because one of the things which hits you from a standard which is a very important thing Well, you're talking about a common thread which is object-based languages. We have object-based languages that need a common descriptor language. UML works awesome. Hey, we're common family database. How is that going to work on a document database? Not. We're talking apples and oranges at this point. If we have to do this, we have to find the commonality. It's not going to be a data model. I guarantee it. To your point, I think in theory, yes, everyone agrees with the spirit of a standard. Everyone thinks independently to come up with something that's common and that would help at the end for the greater good of the community. But there's the other side where when I'm thinking about how it works roadmap, I want to be agile and fast. It takes a long time to get consensus between people, between vendors. Forget about the fact that a lot of the larger companies, maybe the IBMs and Oracles will probably dominate some of that discussion. Maybe the little vendors might get left out on the side. There is definitely good to it when you look at the interoperability. But the impact it has on the vendor will probably be pretty deep. So I think that there's both sides to that point. So 18 months is too long for us. So 18 months there will probably be another database out there. That's five versions of 18 months. Too long. Sure. Correct. Correct. Nobody is here yet? So I think at some point in time what happens is I'm going to university from technology. I'll be expecting a return on investment. My whole business is not technology. I do something else. Everything can happen. I want to get something out of it. It's just that having a variety but with some kind of standardization. Everybody is going to do the exact same thing. I don't mean so many of them. And also just looking at it differently is a better business than the factory was mentioning, right? Because we have different things. So we need different things. But there is some level of commonality here. It's not that... There are a few axes here, I think. And I think what it would be premature to standardize is the exciting stuff in the SQL. So all of us, we're doing some quite innovative stuff. For me in the graph data world, it's all about graph data models and innovative query languages and all that kind of stuff. And standardizing that now, particularly if we involve these guys who have a radically different data model, that would be both difficult and premature because it would stymie innovation. But there are a bunch of things where I think we have a diligent duty right now to be standard. We shouldn't be baking our own operational counters. We should be absolutely standard compliant for all of that. So we're going to start with the data model that we represented here. Drop it in your data center and your ops guy is like, oh, okay, that's just a database. Because the last thing you want is for your ops guys to find a database to be exciting, right? Databases... Operationally, databases have a duty to be done. An exciting database in production is not a good thing. So I think where I think we could start to gain agreement is, okay, let's all agree that we're going to use XYZ monitoring protocol or protocols, right? Yeah, tied it away first. And then we can take a step back. How successful was that? Have we tried the standardization path amongst a bunch of vendors now? Can they cooperate like grown-ups to make something that isn't, for them, business critical happen, but which is business critical for the user and customer community? I think once we've got that pathway kind of lubricated, then we can take a step back and think, okay, is there any value in other things you might choose to standardize? That's going to be... you're going to have to standardize within the verticals. You might get the document database standard, the graph database standard, but you're not going to get the no SQL standard. And in fact, I would go out on a limb here and say, shame on you if you think that you could not learn, right? Because this movement is going so quickly that you are going to have to learn new tech. You're not going to be able to wrap all this in your schoolboy SQL and hope for the best. So sorry if you thought standards are going to stop you from performing so let's go back. Let's take the next person on the road, that's okay. Yeah, so I mean in concept the same things apply, right? So you say CRUD or IUD operations or whatever it is, right? But when you again go back to the data model you don't do an insert into table column A comma B comma C comma D you're going to do an insert into and you know open a curly bracket and put in JSON in there for column family it's going to look different, right? There is a concept of key value, I think there is some commonality there with key and a value and maybe the value is it could be column family database it could be JSON it could be something else, right? So there's even with the most basic operations currently, right, at the moment they do look very different for the different databases. I think that at least the way I see it key value access is probably one thing that's common across these databases it could be a place to start where you at least have the basic insert update delete statements and then you can get into paths and all the other implementation details of the data model perhaps. SQL is the other thing you mentioned where a lot of the older the generation before the JSON databases let's say XML where we added in a lot of the syntax and new extensions to SQL, right? They were popular for some of the XML databases like SQL XML, right? But when you actually look at these databases inherently they're so different that there is no SQL core at all and so just extending SQL by itself does not make as much sense however, I think there is a lot of value in a SQL like language to make sure that people can reuse a lot of what they already know but for a different format which has hierarchy built in so and for CouchPace that's the direction that we're moving in again it's not going to be a standard again it's going to be our own language for CouchPace however, again, it's open source right so that allows people to pick up a language perhaps and do more with it and then timing is a big thing right now a lot of us are innovating building in a lot of core features and so we've got to maybe two or three years down once you know as this gentleman said we have some maturity in the core database is that's where we start talking about standards at least for the basic core I think one thing is worth kind of laying out that you know SQL is good in certain cases right when you really have the power and you want to be expressive about data discovery and joining one field to any other field that is on the panel we see that actually not as efficient for agility if the developers in Java or C Sharp or Python or whatever all day it's actually not a benefit that I have to learn another language just to read and write my data right so you know why developers love Mongo is that they use their native programming language the top 12 languages and they can insert you know read write directly from their program now I'm not saying that's best in all cases that's when I have an object I just save it and then get it back there are other times when I really want an expressive query language and maybe that's where there's maybe a need for another language but really most people don't want another language it's only because SQL is already there and people are comfortable with it they may look for another language but if you look at application development I just want to save my object I have I don't want to have to write a stored procedure write a big SQL query just to do that so that's important to realize like one might be the different if you segment the uses and the usage patterns you might say one is from programming language another might be a query language across no SQL databases there might be a need for that for more data discovery and that's where SQL is used or a SQL variant that goes across any database at all like that would be great but just people should realize it's not just we're not just going to have a SQL variant for no SQL because that's not the most effective agile way to build applications a lot of the time so back in the day when I started in IT I was in a small Irish company called Iona Technologies which were a great supporter of the OMG but one of the things we used to always lead with was standards that was huge distributed object technology it made a lot of sense and I guess over time then these things became commodities we landed in the world of J2E again arguably it's a set of standards to the JCP I guess back to what Dipty just mentioned you mentioned that wonderful world of open source when you look at the vendors here and you look at a lot of what's going on with no SQL open source basically pervades this part of the industry and the segment has open source done away with the need for standards I mean it would appear that there are no standards today yet everybody in this room is using no SQL is standards is not relevant is it just that it's open source and that gives you openness flexibility and agility and lack of vendor lock-in so what's going on with this what does open source mean to this whole conversation around standards I guess I don't see that it changes the because the requirement from the customer and the user base is still that vendor independence and not lock-in and so it definitely I think the need is still there I don't know how much it changes the game I was talking earlier about a topic similar to this and it is good that at least in open source everybody can start playing with the technologies and you get a lot of use cases to build standards from instead of a vendor saying well here's what we use we're going to submit that to be a standard and maybe not that many people have used it so maybe good from that perspective but it seems like standards are still very useful there is zero there is no control in open source if you think you have it data stacks we work with we don't own it a lot of the commuters work for us but not all of them they work at other companies it's not like we're going to go in there and impose a standard they'll be rebellion it's open source it's meant to be a meritocracy not a dictatorship and if you're a single vendor with a single product you can do that because you can say this is our product we have product managers and we know exactly what's going on we own the code base but for open source companies there's the F word fork that happened you have myra you have flock drizzle everything you do not want that you want to try to keep it together so if you're trying to come in there heavy handed and say look we're going to start doing these standards groups and everything just log into IRC and watch the IR it'll get crazy because no one's going to want to try to just jump into this that's why I think what is cool is the unsexy stuff that no one's going to care about and the best standards committees I've ever worked on is on the most boring unsexy stuff and we could all agree on it I think it does it doesn't the need for standards doesn't go away because it's open source I think what it does help do is the code is all open you could look at the code build a driver or extend a language or in some sense and so you could the user base the community might actually see what they can do with that language if they like it maybe they build a driver to mongo right maybe they build a driver to kassandra and so that happens organically a lot more so that as a vendor I am not pressurized to say oh I need to build an API for this or I need to build an API to another product it might actually just happen the community might just pick it up they have access to the code and they could do a lot more with it which was obviously never happened with the big three relational database companies so that's the positive that is a good point at least if there are standards that start to come about you're not relying on the vendors to implement it particular mongo DB we control the roadmap at least but still there's tons of open source third party adapters integration points and all that so that's a good point that at least the standards get start to be defined you don't rely on the vendor to solidify you can't have others in the community to solidify it a good idea tends to stick that idea is dying absolutely people voting their feet so when I was a young man first entering IT I was a supplier to a little irish company who led with the standards first I don't know what you tell me so who led with the standards first inside of we they were interested in orbs and interoperable objects and we were interested in OTS and if those standards led to such a pleasant interoperability story for all of us because those orbs were all talking to each other and our OTS didn't need any modification to work with Iona's orb at all to be honest and me and Mr. it's a few times after a few times so let's not let's remember that standards aren't always to the letter successful even if they are developed in a spirit of cooperation and awesome unicorn nuts here here and and Bonasky has found himself now in the no secret community so what does this mean to us he's moved away from objects and now from middleware absolutely so we'll throw it back to the audience I would be interested I think we he is now a fran of Erlang is true he's forever down there is an ISO standard for Erlang it will be much more successful is that ISO or NIS fencing the cage of mind right yeah so we throw it back to the audience maybe just for one last question I'll be keen to kind of then move on to wrap up the session so has anybody got any things they would like to throw at the panel in terms of you know either feedback or accusations or other or what you would like to see in terms of another point of standardization that'll be easy okay we made him to say that that's what I say right open source good okay the only benefit though you're right that no one switched or not many people switched you know in bulk it did help the ecosystem they're like the eye and other tools on top of the database that is you know that is one benefit that at least I want to talk about the ecosystem in a second up studio see that's perfectly boring absolutely the most boring thing I've ever heard do you work for IT ops or do you work sorry yeah I think I had a question there as well so you would say a set of conventions I think back to the jet it's boring I almost fell asleep sure sign that it's going to work because I've got my best sleep in a standards committee meeting okay take another point of view here so I would recommend an open source ETL tool for that activity sorry convention yeah we care a lot because we have half the number of developers to connect to all these things but hey that's another story convention that's a convention don't use a relational tool on a non-relational database there's a convention now we need a new convention how do you manage non-relational databases yeah and I think to your point the ecosystem is where it really becomes important right I think that talent has kind of done that one of the few that has actually plugins or connectors adapters to each and every no-ascual database out there or Hadoop or whatever it is makes it a lot easier for you but the vendor had to do that themselves they had to build individual connectors because there is no commonality between the databases and that's where some set of conventions or at least mapping between data models to see how do you flatten JSON so you put it into relational and then it becomes interoperable across platforms, across other systems that's where I think in the short term a lot of the focus needs to be because I want to have every other BI tool work with couch base too right and so instead of getting each BI vendor to build a connector for me I'd rather have something that is let's say a common API or a common language at least for the data format if it's JSON then it's JSON and that's a standard right there so I think that's where we should focus as vendors ourselves is having trying to really understand formats so that we have a common language if you will to talk to each other across these systems a query language will take some time it will take a while for it to get into a database interface whether it's programmatic interface or a query language across even a document database Yeah I think and I come to this question what we kind of see today is we see Hadoop actually being that bridge between a lot of what we see here today in terms of different no-SQL databases it's kind of like the Knackers yard for data as we would call it Knacker being a place that you stick a horse because a lot of what's happening today so it's kind of a very simple caveman view of the world we kind of see that a lot of people are installing that type of convention but I want to ask for you to have a question or a point here Excellent is that primarily for things like lineage or what we're using the metadata for Yeah so we'll wake up Patrick at the end Sorry he was sleeping there Patrick is that an exciting or non-exciting question No metadata is almost cool So I'd say that's the next phase Sure I mean metadata is important but again it goes to the actual use case and the model and where everyone is different I think that's going to be a challenge where do I store customer data my answer is going to be in about 10 different calling families What's your answer going to be? In a document Exactly So it's a different answer so trying to even address that again we're all running back to relational databases which have been around for so long saying well they had a standard well if they're so great why don't we still use them We do use them but the point was made out in the audience that no one even all that standard has brought us is that I can log into a terminal and probably the SQL I remember from university will work that's what that standard has brought us nothing more because you've never switched off SQL server and replaced it with Oracle yesterday afternoon you always have a nine-month migration plan for your constantly changeover so that standard has basically brought us nothing Just as a challenge that point because I'll challenge that one if you look at the Hadoop community which is somewhat closely related in proximity to this conference they have all embraced an SQL variant on top of Hive and you've got to ask why now is it driven because they as vendors feel it's valuable or their end users basically feel from analytics perspective it's valuable to them otherwise what you would end up basically is just a set of different types of Hive QL or other variants for take Pivotal versus Hortonworks versus CloudEra or SAP God forbid they would ever have been a starter Hadoop is for data discovery though and that's actually where SQL is well suited very suited yeah so it's no SQL is more for the operational workload it's not always a good but did that same language make it into the inter-pregal did it make it into draft did it make it into dry out? Absolutely not so again you've got that same proliferation of non-standard what you're saying is a thing called Hadoop has a language which fortunately hasn't been subjected to too much vendor squabbling but again there's no notion of like the Hadoop languages being prevalent in other Hadoop like processing infrastructure so you could still have that same shit fight between those stacks how do I migrate from Hadoop to Giraffe in an afternoon so it could be the case that we look at the different implementations up here that a single implementations that standards across the group is quite a tricky thing to maybe consider but maybe within the product categories there are room for standards I do take your point security definitely seems to be one of the impediments for any adoption of technology it's an obvious one but then I think from an operational standpoint how do you actually host and run a database in an environment is a key critical question so some convention or standards there that help people like that I think they're good things one last question or point from the audience and then we would ask just for closing remarks yeah on behalf of the OMG sorry yes so you'll be outside basically with folding car and sign up registration forms through the OMG okay but a final point or a final question then to the panel I was hoping I was hoping not to have to mention object oriented databases today but yeah oh wow there was an extra seat yeah there was an extra seat okay so to that to your point I think you know it just goes back to the data model all those modeling all those modeling tools and all those you know conventions and standards worked great because we were working all of them on top of a relational database right but and maybe some different types of data models but here where we are where we are right now at least it looks so different in our world that sometimes it's how to look at Patrick and even talk but and that's kind of where we are I think a very good point maybe this gentleman in the middle here that the rapid innovation is kind of what I would imagine most people here are looking for and keep the openness and the flexibility and just keep rocking because you're doing a great job depending on which flavor of database people want to hear I mean that seems to be what you're kind of saying guys just keep going you're doing a good job so that's a kind of thumbs up I guess from the audience maybe get closing remarks from Neotech and we will then we'll wrap it up what would Neotech say I don't know what Neotech would say operational standardization is going to happen it's going to be driven by market forces you don't play nice with other systems in the data center you won't get adoption standardization a data model at query language level we're still busy innovating at this point so any effort to standardize is premature it's going to stifle innovation watch this space give us another decade we might think about standardizing it's not too long because you're still using the databases and getting great value from them from our perspective the thing that would most help and common desires in all of us is definitely the operational and the kind of security and all that probably is the lowest hanging fruit also the ecosystem now I mean all of us would like when you switch databases from relational to a no-SQL database it's not just switching the databases switching the BI tool the reporting ETL at least ETL is easier and there's vendors supporting it already but that's the other thing driving would drive adoption for all of us would be if there was a standard at least for BI otherwise the BI vendors just have to write to each of us what they are doing I think Mongo more than others but that's my opinion but yeah it seems like things are changing so fast and not really consolidating on a single usage pattern that it might be hard to do that soon Dipty? Well standards have the good, the bad and the ugly as we've talked about and I think it will be a while before we have particularly programming interface or a query language across the same database I think we are working in the right direction where both databases like Mongo and Couchbase are building adapters to common tools I think that's where it should start but it shouldn't prevent us from catching up on coffee every now and then and talking about standards because there is the good part of it that hopefully will come along and do you think that will be driven mostly by the ecosystem or the vendors themselves will get together and have that chat? Well it will depend on what the space looks like right I mean I think for it to happen the space in general needs to continue growing which means that each of us need to collaborate more than compete in some sense for standards and also it will depend on what the other bigger database guys do we could see consolidation we could see a company being bought by someone and putting a sequel layer on top but it's hard to say right now it's the phase where we're into innovating heavily and we'll take it from there Okay good, Patrick I mean I don't want to be a inflammatory no I do No I mean it's clear I think to everyone in this space that we're innovating quickly we really don't want standards right now and there are some standards that we are doing that are small and like I said boring for lack of a better word but just things that have to be done give us a decade I like that and when you see a standards body being formed at OSCON pay attention because that's where it's going to happen this open source is going to change the way we think we thought differently about the way we manage our data let's think a little differently about how we manage standards too Good so I think we'll leave it there I'd like to really sincerely thank all the experts for basically joining today hopefully and again I would actually thank all of the you guys here in the room for basically contributing I guess we're around afterwards if you want to follow up and talk about war stories of OMG JCP all that type of stuff and if you want to solicit Jim, Patrick, Dipta or Patrick to join the OMG I think they'd be more than happy to have that conversation afterwards so thanks very much everybody and enjoy the rest of the conference