 Good day everyone. What we wanted to do was the format of this session is going to be very, very informal and we're going to get like two luminaries. I'd like to introduce them to you. First of all is Mohit. Mohit is the CEO and founder of InMobi, one of the truly successful companies in the mobile ad tech space and they're doing wonderfully well. And the entire startup community is actually really kind of impressed by all the traction that InMobi has garnered over the last like three or four years. And I would also like to welcome Trini Srinivasan. He's the founder of Aerospike. And prior to this, he's been a database whiz, got his PhD out of Wisconsin Madison, worked for IBM, worked for a couple of startups like Liberate and one more startup which got acquired by Yahoo. And he spent a number of years at the Yahoo big data analytics kind of function before starting Aerospike. Please welcome Trini. Thank you. So what we'll do is we'll actually kind of just sit down informally and what I'm going to do is like break this session into four major themes. I hope all of you can hear me. Please. So we start with Mohit first. Mohit, in today's world, a startup is no longer a startup. What it used to be like in the 1990s when I did my first startup. Everything moves fast. There's velocity of business. There's veracity of information that you want to actually provide to your user base, especially being mobile online. So could you just talk us through some of the challenges from when M code started became in movie and all the things that you deal with not only on the business side, but the technology side, etc. So before I, you know, delve into the history of M code in the movie and the scaling, I just want to mention a very, very unique fact about training. So I have a very special bond with Trini. When I was coming to India from US to start this company, Trini was sitting right next to me on the plane and we started chatting and he said, So what do you do? So I said, I don't do anything as of now. I'm going to India to start a company, something to do with mobile. I just gave him the vague idea and here we are, I think. Then we met after three years in movie. M code became in movie and Trini launched his own company and then he wanted to basically walk us through this unique product that he built for ad technology. So that's where, you know, sometimes things are meant to be and he was glad to be here with him. So the answer to your question is, I think we knew when we were founding a startup in mobile that this is the whole domain is going through the explosion. And just to guys give you a sense, M code initially was a search based mobile startup. It was very much like, you know, what you see today group on something on something on mobile, short, short SMS and all those kind of things. In seven months that model fade and we figured out we were ahead of little time and we needed to, you know, re engineer whole thing. So we pivoted the whole model again to mobile advertising the way it is today very contextual based on the user and it's basically basically on app and mobile and we wrote all our software. And as soon as we basically got first two customers, the server crashed. Because we were hoping that, you know, the whole thing was designed for 100,000 requests per second per day. And we thought this is a pretty huge volume. I mean, who would have thought and then there used to be a small publisher, even in those times who was selling this ringtone and music. And within two hours, the whole server crash and that's when we realized that we are in the world basically where number one matters. Eventually you need to be ready for all these eventualities way ahead of time and that's where we were early in the game. We heavily invested on our data system, not only on the bad side, even on the real time processing and the traditional databases system. So in that sense, I think we took some early calls which has helped us over here separating our application that what can be processed through batch what can be processed in real time and what can be done in a classic database system. So I think some early thought, early thinking and some good calls, I would say we have been lucky in that way has helped us. So today you find yourself at stupendous volumes compared to what it was maybe four years ago. Could you just care to shed some light in terms of how many data centers you have? What is the volume of data that you kind of process, say on a per second basis and on a per day basis and how many apps you serve? So currently basically we are serving add in at least 165 countries across the globe. So every second there are around 125,000 requests per second that hit our system. Our data center are located four continents across the globe so that we can wheel out the user to the best possible location based on their own location because of latency. And in act act it's basically a three kind of major processing that happens. The first one is the enrichment of the data as soon as a request comes in how much you know about the user. You know we have a lot of cached information where we want to see what do I know about user what what he likes what he doesn't like. And then the second process is after enrichment is the inference. Sometimes you get a lot long which doesn't mean anything but then you start to figure out hey this is the point of interest. This is what is going on in that place. So those sort of influence is made over there and the third part is auction and all these three things generally needs to happen in less than 20 millisecond. So 120,000 requests per second that we get we have to process them and respond in a best possible way in 20 millisecond because mobile word is very limited latency sensitive within 100 milliseconds. If you don't respond generally your request is terminated and that's the opportunity lost. And in order to do all these we roughly generate 50 terabyte of data every day. We have more than a petabyte of active cluster where we do all these numbers crunching science analysis whatever needs to happen and that is sent back to these application server that cash information and they process it all on the real time. So these are some numbers just to give you a sense all these numbers they have tripled year over year. So we are expecting the active cluster to be roughly three petabyte in a year from now the request somewhere more than 600,000 requests per second and similarly you know the bad processing will be triple what we have been doing this year. So now coming back to this old kind of association that you have with training I'm sure it had nothing to do with you picking aerospace very early but you're one of the earlier doctors of aerospace and actually had fun with it. Let's put it that way and it's actually served you well. Could you shed some light on that? So when I was talking about these processing you know where you do enrichment in France and you do the auction that you know who wins the bid. We were using age cash and the problem is basically you know in today's world is nothing you can scale up you cannot just throw on the memory you can just cannot throw on the money. And we are still a very stingy startup every last dollar that I have probably I would spend on a good engineer then on a software and hardware. So that's the philosophy I believe in. So we were in that mode but this was just becoming more and more complex and that's when you know she wrote me a mail and he said I have a product very precisely for ad tech industry and I want you guys to just take a test ride and see what it is. And we really looked at and at this point of time I think Aerospike was the only product that was solving three of our main requirement. One was basically we have a very heavy right because we are updating this information all the time. You know some fees are coming in there update updating it all the time and at the same time I don't want to suffer on the read. So if you use Cassandra Memcache and all those things there is a there is always a trade off and we were not OK doing any kind of training anything needs to happen on a real time basis. If I want to write 500,000 requests per second you should be able to handle it same thing on the read. And the third most important I don't want to deal with the redundancy and the fail failure mechanism. You know I don't want to build anything it should just run and I think those are the three things we tried it. And I think the whole demo was roughly 15 days and even production I think that was one of the fastest we just tried it. We just push it into the production and since then we have you know Aerospike has been a very integral part of our whole stack where we use it all the time for all kinds of steaming processing. I also find Aerospike to be very sensitive to the needs I think they are very much listened to what's happening on the real life and what are some of the challenges. So I find it a very collaborative environment over there and the recent effort of making it open sources I think icing on the cake so hopefully a lot of people will know. Let's turn over to Srinu. We've got like tremendous endorsement here from Mohan. But one of the things challenges with the NoSQL big data trends is like there's too many people making similar noises. And so it'll be great to kind of hear from you how you position yourself differently, why you are like maybe 100 times faster than let's say a Mongo in certain situations. If you can shed some light on that I think it'd be very useful to the audience. So thanks Mohit for sharing that how we met and so on. One of the things before I go into answering Srikanth's question, one of the things that has been most valuable and most cherished about Aerospike and the fact that founded it with of course a colleague who was here last year, Ryan was here last year on the keynote. The thing I'm most cherished is that I get to work with people like Mohan and others. And we are trying to do work moving forward both the technology, product, the business in multiple markets all over the world. It's just a pleasure to work with folks like Mohan and Srikanth. Now to answer the question, the philosophy I'm just going to give you like two high level software points. One is Aerospike and Ryan and I met, we discovered or I think Ryan discovered first the presence of SSDs and how storage has changed forever. The example I have is here in Bangalore main memory in terms of distance is probably like two or three kilometers away. Rotational disk is really California. What SSDs give you is maybe UBC. So now that you are different between here to UBC and here to California, you can build a database by rewriting, you know, not just based on SSDs but also multi-core, better processors, better DRAM and so on, something is 100 times faster. So we invented that. There's a whole bunch of details you can go look at, code is open source. The second part is actually relevant to what Mohan talked about. You know, I was at that time at Yahoo and Ryan was in other companies and I was going on the Internet. What we repeatedly saw was the difficulty of building Google scale things. Google had solved it of course. What we at Aerospike wanted to do was to build technology which enables other people like Mohan, for example, but several others, our customers to build Google scale applications. Four years later we're sitting here and InMob is definitely Google scale and we have, you know, nine of the 15 non-Google Google scale companies as customers. So that is kind of an interesting question. So a couple of things. You mentioned open source. I think when you started the first few versions of UBC, these are the non-Google source. Now you're focusing on that. Please give us a little bit of insight in terms of what that roadmap looks like, how do you want to build that community because competition, I would call them competition but other players in the space like MongoDB and so on have actually put things out and that becomes very critical also in terms of adoption within the customer base outside. So when we started the company, both Brian and I, even the early days, almost four years ago, had discussions about making a product open source. We were a little bit more traditional in the sense that we're C programmers. We worked inside Units kernels, real-time clients and dealt with a lot of real-time issues. What we wanted to do was to build the technology and prove it in the market before we kind of donated it to the community and that's precisely what we have done. We have used the most highest performing internet applications as a test pad to prove out our technology. Now that we know that it actually does work better than everything else out there in a class of use cases, we would like now the community to kind of take benefit from it of course but also start contributing to it. We do realize that in every company that you can think of, the smartest engineers are outside the company. So we just wanted to make sure that we built something which was valuable enough for these smart people and then shared with them. The second thing is we believe the time is right currently with the crossover of internet-based enterprises to the general enterprise area. So from a traditional break and click perspective, you're out there selling now and you're seeing some fraction in the financial services space in addition to it. So in the context of traditional break and click, how did that success happen in the first place and how was it positioned? Because they have millions of like database technologies inside, they have tools, etc. and this is yet another new product. Yeah, I think some of the interesting things is you got to look at the trends. If you look at the evolution of database technologies, a lot of them happened in the enterprise 30 years ago, 20 years ago when I was doing my PhD and so on. And then for whatever reason, the problems at the enterprise level were solved. All the new data problems were happening on the internet side. And there's no kind of surprise that a lot of the new databases and those SQL databases, if you will, were all products of internet companies. Now, many of them actually didn't attack it the way, for example, Aerospa did, but that doesn't matter really. The key thing is the new problems that enterprises need to solve are related to consumers, all being internet consumers. In CIO of a bank where Met recently told me that every one of his customers was now spoiled by the Google. What that meant is they wanted instant access to their information and they wanted consistent access to the information. And that's kind of the difference, right? I mean, some of the things we talked about on the internet are about speed, scale and reliability. Speed actually provides you scale and reliability. That kind of what we have found in Aerospa, enormous speed provides you enormous scale and enormous reliability. And that's what folks like Invo we are benefiting from. Now, to cross over to the enterprise, we also, from day one, we are a traditional database. So we care about consistency and safety of the data about speed and scale and reliability. So having all four of these enables enterprises now to service internet-like applications. So that's the trend we should be looking forward to. Move back to you. A couple of things. Whenever you are in a start-up environment and you are dealing with another start-up who is part of it in all this time. It is very critical that enough innovation happens at both ends and both go towards the same goal because otherwise it could be disastrous. So in this case, it's obviously worked out beautifully with Aerospa. Have you actually contributed a lot of ideas back to Aerospa again? Have they actually come back? Has it been a very, very good symbiotic relationship and is that critical? Yes, I think it's very critical and I believe if you are a start-up, it's always very beneficial to work with a different start-up. Because they understand the pain point exactly what you are going through. They also understand that money will be a problem. It will not be spent very easily. And they also understand that we are in this together and it needs to be a very collaborative approach. So I think whenever Shriini is here, I think we always catch up. And I think his team is also very helpful. Some of his team member, we made a point. I think we need roughly two times in a year and go over some very real use cases. And I think so far I have seen a very good approach to it, how to solve it. Because we are representing a very strong industry. Advertising is a very big force in mobile and digital world. Google and Yahoo of the world, they have already proven it. So it itself is a pretty huge economy. So the problem that we face is not something very unique. It's very changing. So I think it has helped both in that way to figure out what's the right way to move forward. And I think with this open source, I believe that can be taken to a very next level as well. As a company, we are a very staunch believer in open source philosophy. We have actually open source some of many of our own software. And now this one that AeroSpike has made that we already use. So I'm pretty sure I think we will look forward to do a very active contribution in that. In solving some new problems. I want to actually turn it over to Shriini. From a positioning standpoint, again going back to my first question. There is enough noise, people clearly have taken advantage of the trends in hardware and we as we are finding out how to build something 100 times faster. At the same time, when you have a scale and serve the needs of hundreds of enterprises, what are some of the challenges that you see and what are you trying to build in your roadmap which will actually fortify yourself from those challenges? Right, to some extent. I just want to before I go ask a question, I want to point one thing. There are a couple of key features of AeroSpike which have been impacted or basically done because of the engagement in the movie. One of them is steps and you see more of those happen. In terms of what we see as challenges, we are actually not doing any different than what IBM and CyBase and Oracle did in terms of building traditional databases. They first built out, for example IBM built out IMS. It's still actually a billion dollar business. And then they built DB2 and queries. Oracle similarly had its data storage system they built. And then on top of which they added features over the years. Eventually they of course did applications in a mature company and very successful as well. So when we started AeroSpike, our goal was not any different. We just wanted to modernize the database technology to the level where we can provide a general purpose system for the internet scale applications which we believed then five years ago was just going to happen all over the world. And we're now starting to see that. In order to do that, we had to build out of those solid platform scales. And then we had to add features. So we spent time adding features of queries and so that, you know, do not be surprised if you see some level of SQL support from AeroSpike in the future. The trick for us, the challenge for us is not to slow down the basic read-write path on which we are so fast as we add more features. And we have actually proven to ourselves that we have more than doubled our key value read-write throughput between version 2 and version 3 of AeroSpike while adding map reduce like query support, user defined functions, time series queries, secondary indexes and so on. That's actually a technological challenge. Business wise, the challenge is not to do one-off things. As Mohit pointed out, there are features we add because of engagement with companies like Inmobi, which to us are lighthouse and representative of a vast variety of companies in that space. So we pay a lot of attention to landing in a particular vertical, like financial, retail banking, for example, where we are very applicable. You know, telcos, where telcos are moving from their older system dealing with voice to networking-based things in order to do more traffic and travel, for example. So what we do is we look at each of those verticals, figure out what general purpose features are needed, and it so happens that what is needed on the internet is now needed in enterprise. Travel is needed. For example, caching. We can replace caches with a database as fast as a cache. So that is the kind of challenge we are tackling. So this is a very important point for all the budding entrepreneurs out there. As you come up with new ideas, if you engage, and everything becomes a one-off, and there is no discipline in basically figuring out patterns, then scalability becomes an issue. And that is basically underscoring what Srini just mentioned. I want to turn it over to Mohit now from an open-source perspective, right, when you actually are kind of encouraging a bunch of your developers to actually contribute. How successful have your contributions been back to some of the ISPs, next-generation ISPs like Srini? So far, our open-source contribution has been limited to on the data side. And I think as I said earlier, we were early in investing on this big data system, assuming that we are going to be processing a lot of information. So just to give you a sense, I think we were just one-year-old company and around 2008 or 2009, we invested basically first in building our own Hadoop cluster. And it was breaking every night. And we knew that, you know, we have to learn it hard way and what we built over there was basically with the help of the community. And at that time, it was very clear that, you know, whatever scale and what we have achieved with the help of some very smart engineer outside of the company, and we wanted to leverage them and contribute back. So even entire team has been pretty, you know, serious about that idea. In last three, four years, I think we have open-source at least four software and one of them, which is a very complex piece of data lifecycle management tool, it's called Falcon, has been contributed to Apache Foundation already and it's in the incubation mode. Hopefully, it will be a main project pretty soon. In fact, very good traction on that. Hortonworks itself has adopted that. And similarly, I think we have one more software which is on the way and I know one of our engineers, she's sitting over here on Rishwari. She just had the talk before that. I think she's on her way to submit one more project possibly this year. So I believe in basically utilizing the community and as she was saying the best engineers are all over the place, may not be in your company. So there's no better way to make them work for you than releasing your software out there in the open and you'll get hundreds of engineers for free. It will be contributing and might be building something very, very useful. Thank you, Mohit. So with that, what I'd like to do is we've actually covered some basic themes here. I'd like to actually turn it over to the audience to take a few questions and please feel free to engage both on the business side and the technology side and try to do a round robin operator principle for the best possible scenario. But like I'm sure there are mics all over. So any questions? Please, please announce yourself company. So yeah, I think there is a this sort of a backlash going on for banner apps. The main reason is they appear out of nowhere and generally they are not aligned with the aesthetic of the content and sometimes they look very different in that scheme as well. So I think with the new trend is and I think we are also very ahead in that it's called native which means you have to basically adopt to the environment you are in. So short answer to your question is definitely I think in mobile everything is moving towards very relevant native content at and it's not there yet banner is still a huge part of monetization but I think it will completely shift over there. This sort of problem here. My question to you, did you compare Redis? We almost tried everything. We did Redis, Cassandra, MongoDB and even Memcache, a lot of those things. We do use Redis at some place where the right uses there but all the precise requirement that we had, you know, like I told you heavy reads heavy writes with almost microsecond microsecond latency and completely failed proof system. I think this was the closest that we come around that point and there's always a, you know, in a startup you want to focus on 10 things and you want to figure out what are the four that you are going to work on so that you do a really good job and what is something that you can use out of the box that works. So in that entire decision, I think Aerospike really... How do you compare Redis? In all these parameters, stability, operability, read and write across the globe. As I told you that, you know, it needs to be in sync with all that location so I think those factors. My question is for Srini. So in the discussion several times. So, I mean, looking at Aerospike as more of a very enhanced key value store. Does it really? I mean, compared with the aggregation framework, it has a quite an advanced query engine, right? And also if you look at something like Couchbase, which builds on CouchTV, you have prepared queries and it is in memory. I mean, how do you really compare as a use case? I mean... So the way I look at it in Mongo, of course, is another good job of content sites and so on. Think of Aerospike. I'd rather not get into too many product-to-product comparisons here but what I would tell you is there are use cases for which I think Mongo is the right thing. You know, there may be some use cases for Couch but if you're really looking at read, write workloads, if you're looking at continuous uptime, if you're looking to pet your business and not be called at night, those are certain characteristics of workload. It's not just high transactions throughput. What high-speed transaction throughput at low latency gives you for reads and writes is the ability to deal with failures seamlessly. So you can still be running 10,000 transactions per second on your system while two nodes have failed, three more are being added because we can do a million in a node. It's not like an application is a million. It is what the system can do. If you think of that way, you know, certain kinds of use cases, it's a real time. Aerospike is far ahead of every other database. Mainly because we are, as Shri Gaurav's pointed out, we focused on getting the most out of the latest advantages of the hardware. So we are actually writing the Moose Locker, even software. So that's all. So I remember from, you know, one of the benchmarks that we had with MongoDB in the early days so in our key value store, there was around one billion values and we were doing a full refresh of it and at the same time we wanted our system to work. We should be able to query it without a sweat and once the whole merge is done, it should flip to a new store. I think in early days, three, four years ago when we tried, there was a corruption problem in MongoDB. Whenever we are doing a lot of frequent updates, that was one issue that we faced. I don't know where it is. One last question. I mean, personally I've been looking at the evolution of Aerospike as the releases have gone on and the clients have developed. I kind of feel that you guys really ignored the Python community because over the years the client for Aerospike which has stayed on the sideless list, you haven't added the features to the Python client. It's just, I mean, is there a reason for that? No, we're actually working on it right now. The only reason is we're a startup and we focus on various things and I think it is now a very high priority right now. In fact, we've had a discussion on it just yesterday. So yes, you will see it in the future and please do post to our forums and make your voice heard. That's how we kind of fuel some of these requests these days. I think this is more from a generic point of view. When you look at a startup and the founders clearly have a lot of vision in this spot market. So a lot of the engineering and tech sort of platforms get decided sort of post understanding what is the opportunity of changing. So one is chasing the opportunity at the right time scaling fast and probably being the first sort of mover in a particular space and the second piece is followed by second is, I mean, we look at companies like PayPal. Let's say security was one of the key aspects of core technology which actually helped them succeed vis-a-vis, let's say, payments. So when you look at, let's say, in Mobi as an example how you've scaled up and how you've got funding how do you sort of really evaluate all the factors? One, is it the vision, market opportunity followed by engineering or is it something unique to me on the technology side which then differentiates you and then you can decide which operating opportunity it is based on what you're doing. So I'll give you my sense and then Shini can give about Aerospike. So in Mobi, we are not a software company so we don't build software and sell it. So our proposition is a very different user base and app ecosystem monetization basic proposition. So we are always very driven through the vision that we have and the vision that we have is basically just fueling the growth of this mobile ecosystem by providing monetization to publisher by providing right audience and user to advertiser and simply user the great experience and the most relevant act. So for us decision is generally led through that but at the same time we also want to make sure that we take proud in what we build and we build it to scale and we build it to last. So platform has been a very integral part of our engineering and technology organization. There are specific platform teams who and they are mandated to not worry about context and business but worry about a technology problem that will help to solve that business problem. So I think that's the balance that we strike but if I have to take a hard call it's always we go through the vision first and then we will invest on it. We are actually a start-up of the purely technology company. The one thing I do believe which kind of drives us as a company is that software and I don't know those of you who have read Mark and recent article on software eating the world I am a big believer in that. In fact my whole career is being done and what that means is you do expect hardware to double whatever every few years all kinds of innovations to happen. Now the goal of a software company in this case we chose to focus on a fast liable database which is also consistent. That's just the problem we solved. If you had a product which would actually do that on the hardware and as hardware continues to improve you can not just go at the rate of moose law but you can go faster. Look at the big data business. This is the business opportunity but technologically we want to build the fastest best whatever but why do we do that right? We do that because and the timing has to be right also. Big data has been going way faster than moose law in terms of how much data has to be crunched to deal with real-time access. Now if you have something a software like ours can now we have a problem which it will solve which other people can't. Now you have both right? Just doing technology for technology is saying it's not definitely something I'm interested in and I would have been in research and wanted to do that. That's perfectly fine, there's nothing wrong with it but they are really looking at 10-year-old 5-year-old kind of improvements. We are looking at how can we sell more customers expand the business with the technology today. We have space for about a couple more questions. So I think... I have a question. I wanted to get a sense of pure reflection when you open source of a software you built so I'm told from Acoma and what I wanted to know is how do you get the community behind you? How do you get that traction when you open source stuff? For example, when Hadoop was open source the Google people was there and then it was a widely applicable use case across domains, across companies and then that was a rallying point. So when you open source stuff when you open source your software I wanted to know how do you get the community what are you used to get the surface art developers who already have a traction with the community? So the first thing is basically when you're doing open source development and you are planning to open source some of your software it's very important to understand whether it's generic enough and it's solving some real problem that can be applicable to several other people. So if you are solving something very specific to you probably that software may not be a good candidate for open source but if you believe that you have solved something very unique and can help other people as well. So that's the first step and after that obviously you basically would like to interact and talk to some people who are doing something similar or maybe you know related to the problem in some way and sense and see how you know what kind of response you get over there and once you get over there probably definitely you want to bring in the backing of a community or some sponsor who can be the stable member of that particular project and help yourself. So in our case for example when we launched one of the Falcon data life cycle management software we obviously approach to a lot of other Hadoop community member and we validated whether they are experiencing the same problem and after understanding that this is a real problem and generally no software stack exist who has solved that I think we were able to generate some response from them and I think in one year there is a lot of community people now behind this as a software so it's a process one step at a time but as long as the problem solved is meaningful the software approach is generic enough I think community contributes. If I may add to that we are new to this process but here is what we are doing because it is usually an open source company which goes to closed source I don't know if any other company which is closed source has gone open source at this level that we are trying to do here but here is what our basic thought is right we have a community already it's essentially our customers they are very small but they are very what I would call dedicated they believe in us and they are developers and making it open source makes them bet their business on ours more but more interestingly we could potentially we are using our customers like InMobil here in Bangalore, Snapdeal in Delhi other companies in New York so we are going to start doing meetups and then we will invest as a core in each of these markets make it really easy to use for developers so our whole open source strategy is based on developer adoption so we will be doing a whole bunch of ease of use for example I don't want to recognize Mongo in that they have done a great job making it really easy to use for developers but anybody including us can learn from that so those are the things that you should probably need ease of use and presence in lots of markets all over the world that's how we are going to do it Any other question? I think there was one So Aerospeak as a database it assumes quite after-war monoidical services in space so things like stock exchanges or trading forms you know doing risk analysis So do you have any use cases from there? The answer is yes we have actually signed financial services customers we are going to be deploying later this year typically in retail banking is where we started and the way not just financial services but some others the use cases are to do with replacing caches that's by a database of record we do not apply though to real-time stock training those are really very specialized databases running nanoseconds we are not that but we can do milliseconds microseconds tens of microseconds but there are some things you mentioned like risk analysis, retail banking those are I think things where Aerospeak is I'll also give a shout out to our Bangalore team here who invented a lot of the technology that Aerospeak actually uses Thank you, you've been a great audience with that we actually have to bring this thing to a close because we have a hard stock