Tuesday, 27 October 2015

Podcast Interview with Luanne Misquitta, GraphAware

A few weeks ago I had a great conversation with Luanne Misquitta from GraphAware. Luanne has been part of our community for a long time, has written a lot on the Neo4j blog, and is just a generally lovely person to talk to. So we spent some time on a Skype call, and this is what that conversation went like:

Of course, there's also a transcript of our conversation:
RVB: 00:01 Hello everyone. My name is Rik - Rik van Bruggen - from Neo Technology,  and here I am recording a podcast with someone from a very different part of the world - all the way from India, in Mumbai - Luanne Misquitta. Hi Luanne. 
LM: 00:17 Hi Rik, how are you? 
RVB: 00:18 I'm very well. Thanks for joining us. It's great to have someone from the Eastern part of the world joining us in the podcast [chuckles]. 
LM: 00:27 I'm glad to be here. 
RVB: 00:29 Yeah, super. Luanne, I think we've known each other for a couple of years. I first got to know you when you were writing about Flavor Networks, which I did a couple of blog posts about, as well. Actually, they were one of my most popular blog posts. How did you get into graphs, Luanne? Could you explain it to us? 
LM: 00:52 I've been working with graphs for about six years. I think that's close to the time there was this Neo4j challenge running to write an application on Heroku using Neo4j, and Flavorwocky was the application that I submitted, that eventually I won the challenge. Some time before that, I got into graphs because I was working for a company that had trouble managing the profile of a person. This was a people management company so dealt with all kinds of aspects - hiring, talent management, compensation, learning, all kinds of things. And central to this entire system was the concept of the profile of a person. Up until the time that I found Neo4j, it was modelled in a relational database, and at some point it was the table that stored data for the person profile.  It was huge. It had over 200 columns, and most of them were null, and it was normalized and denormalized very frequently, and it just didn't make sense any more. So, I was looking for something to solve this problem and that's when I came across this thing called a graph database, and of course, that was Neo4j. At that time, there wasn't any Cypher, there wasn't the Neo4j server either, it was just good old embedded. 
RVB: 02:27 Good old embedded, yeah [chuckles]. 
LM: 02:30 And immediately I knew that was the thing to model this, because it was schema-free, there were direct connections between a person and everything he's done. So one of the problems we have is that when you're collecting information about a person's profile, there are no two profiles that are the same in terms of the kinds of attributes they capture on a person. Of course, there are the usual standard ones - your name and where you live - but there are things like gaps in employment history, there are gaps in their learning. There are different types of learning. You do your talent manage-- your talent section looks quite different depending on where you are, and what you are doing, in which company you are in. So these kinds of things are very hard to fit into rows and columns, and that's where I thought Neo4j fit in. Once I started with it, I have never looked back. It's really been the solution for most things. 
RVB: 03:27 Yeah, it's quite a common thing, right? You've got a really complex domain that really is so difficult to model and store, query in traditional relational systems and then you take it to the graph world and a-- 
LM: 03:42 That's right. 
RVB: 03:42 --whole range of problems go away. 
LM: 03:44 That's right. 
RVB: 03:46 It's very, very cool. And how did you do the-- 
LM: 03:48 It wasn't just modelling the person. I'm sorry. 
RVB: 03:52 No, go for it. 
LM: 03:54 It wasn't just modelling the person, but just the fact that we could model it this way  exposed a whole lot of insights that we did not think about earlier, and for that kind of-- for the company that I was in that was really important. So, you weren't just interested in a model of a person and then spitting it back out to whoever is looking at your profile, but you wanted insights into potential jobs that this person might be good for, or if he's got a high flight risk, then who is going to replace him, what sales does he match. Is he in the wrong job at this time? Is he really sitting in your company working in a job that he hates, and he's blogging about other things? And the last one I mentioned it was real use case. When I did a quick POC in about two hours one night, and I just picked up random data from one of our internal company social networks, and the first thing that surfaced was this guy who was sitting and doing java development, there quite miserable, but he was blogging about and doing sample applications on iOS. At the very same time, the very same company was looking for people to work in their new iOS team. And here he was sitting under their noses, and no one knew about him. So these were the kind of things you could source immediately, which staring at a table-- 
RVB: 05:19 You would never find it. 
LM: 05:20 Impossible. Almost impossible. 
RVB: 05:22 Totally right, very cool. So I'm hearing the modelling advantages but what did the flaring-- the flavor example have to do with that? That was an interesting one as well? How did you get into that one? Are you a chef? 
LM: 05:39 Well, I love food. No, I'm nowhere near a chef but I love food, I love cooking. And I was thinking of what am I going to submit to this contest? Most of the enterprise-y things were done and I was quite bored with enterprises at that time.
Then I thought about food, I like food. Something that I had been reading about recently, actually a book review called the Flavor Bible, which lists ingredients and what they pair with. The rest of which from the classical triangle. So, two ingredients  paired with a third and you can then combine them and produce something that tastes really good. So I thought that is a good graph problem, and it was really simple, but it was a domain that I liked and I thought it was fun to work with. That's how Flavorwocky came about. 
RVB: 06:40 Luanne, recently - more recently, at least - you actually started working full-time with Neo projects at GraphAware, right? You're part of the GraphAware team-- 
LM: 06:49 That is right, I work for GraphAware now. Yeah. 
RVB: 06:53 How is that going for you [chuckles]? 
LM: 06:56 Very great. There can't be anything better than  working with Neo4j all day. At the moment, I am part of the Spring Data Neo4j team, and as you know, we've just released our Spring Data Neo4j 4 in September. So it's going really good. We've produced some great stuff and-- 
RVB: 07:18 Very cool. I am a big fan. Last night I met up with Michal in London and we were doing some Czech beer tasting [chuckles]. It was an eventful evening. Very cool. 
LM: 07:33  What do you know? 
RVB: 07:35 No, don't get started on that one [chuckles]. That's going to be a very long podcast then. No. Let's talk about the future, Luanne. What does the future hold? You've been involved in some really exciting projects like, for example, Spring Data Neo4j. Where do you see this going? Can you share some of your perspectives? 
LM: 08:00 Well, I'll share with you what I've been noticing over the past couple of years and-- and as you know, I do the trainings for Neo4j in India as well, so I've been looking at various kinds of audiences coming in through for at least two years now. And there has been a definite shift in attitude towards graph databases from the early days where it was a real struggle to get people to understand why it's important. Although they got it, it was still something that they would really have to fight very hard to use in their organization. That has changed significantly over the last, well, even the last six months really, where you have people who already know about graph databases, they can immediately see where it's going to fit into solving their problems. I think with the kind of-- the reputation that Neo4j has , it's now becoming easier to get Neo4j are used in these kinds of companies, and I'm not talking about startups which pick up Neo4j very quickly, the other larger, mid sized company or enterprises. I think what I would like to see at some point and fairly soon is when graph databases become something that you just use. If you're planning a new project, it's very common to say, "Hey, we need a database," and no one will challenge you. You'll go and you'll pick up a database and you'll use it, typically an RDBMS. If you were to say, "Hey, we need a graph database," then it should be exactly that. Pick it up and use it. You shouldn't have to be debating for months over whether it's better than sequel or not and whether it fits or not. I'm really looking at that day as a defining moment for graph databases  where they are just used, and people know when to use them and why to use them, and there aren't any questions about should I or should I not, unless it's a really stupid use case. That's what I think would be the ultimate future for Neo4j and graph databases. 
RVB: 10:20 I'm looking forward to that day as well. And I think lots of us work towards that goal and it would be a great thing. What about the Spring Data stuff? Is that ready for prime time right now? Are you guys planning new stuff there? 
LM: 10:37 Yes, it is. The Spring Data for that been released in September is, of course, ready. We are always planning new things. We have support for-- as you know, Spring Data 4 supports currently the remote Neo4j server mode only, and it was written from ground-up to actually support that, so it's  really fast. We've broken it up into-- it's not only Spring Data Neo4j 4. It actually depends on a new library called the Neo4j Object Graph Mapper. So, if you want really fast OGM, then-- and not Spring, you can use the OGM directly. If you're a Spring person, then, of course, Spring Data Neo4j really uses the OGM under the covers, so there are a lot of features planned for both of those two. Very shortly, one of them is support for embedded Neo4j, and a whole lot of the new protocol, which is [crosstalk] coming up in Neo4j. Support for those, and as well as-- there is so much to do, but we are continuing to work on that and you should see some releases out pretty soon I hope. 
RVB: 11:51 Super. And I'm hoping that I'll see you at GraphConnect in San Francisco? 
LM: 11:55 I think you will, yeah. 
RVB: 11:57 Yeah, well, looking forward. That's super, great. All right, thank you for coming on the podcast, Luanne. It's been a great chat and I really appreciate it. 
LM: 12:06 Thank you Rik - it was great talking to you again. 
RVB: 12:08 Same here, and I look forward to seeing you on the West Coast. 
LM: 12:12 Yeah, soon. 
RVB: 12:14 Cheers, bye. 
LM: 12:15 Bye-bye.
Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!

All the best

Rik

No comments:

Post a Comment