In-Memory Computing: Driving the Internet of Things

Dane Christensen: Good morning or afternoon depending on where you’re joining us from. I’m Dane Christensen, the Digital Marketing Manager at GridGain Systems.

I wanna thank you all for taking the time to join us today for the webinar In Memory Computing: What is Driving the Internet of Things? We have three speakers today, each one approaching the questions from a different perspective.

Jason Stamper is an Analyst with 451 Research with 20 years experience in the IT sector. Nikita Ivanov is the Co-founder and CTO of GridGain Systems, a leading developer of in memory data fabric used to drive many big data and fast data systems; and Ilya Sterin is the Senior Director of Engineering at ChronoTrack, an innovative internet of things company that utilizes internet computing technology to process massive amounts of data in real time.

So we’ll hear from each of these experts in turn, but before we dive in, I have just a few quick administrative points to make. Jason, Nakita and Ilya will present for about 40 to 45 minutes, after which we’ll have about 10 to 15 minutes for Q&A.

Now you’ll notice that just above the presentation screen is a questions button. Click there to ask a question at any point during the presentation and we’ll respond to your questions during the Q&A segment at the end.

We may not have time to get all of the questions during this event, but we’ll definitely answer all of them afterwards, so please take advantage of this opportunity to ask questions from these leading experts in the field.

Also, I wanted to make you aware that we have included a case study on ChronoTrack’s implementation of the GridGain in memory data fabric, as well as a pdf of today’s presentation in the attachments area.

And just one more item, you’ll notice that there’s a ratings button right next to the attachments button, please do rate this webinar at the end and provide any feedback that will help us improve our presentations in the future.

So with that, we’re ready to turn the floor over to our first speaker, Jason Stamper. Jason? You have the floor.

Jason Stamper: Thank you very much, Dane. So delighted to be a speaker on this webinar. Thank you very much everybody who’s dialed in and thank you Dane and GridGain for having me speak at this event.

So, my topic really is the road to the internet of your things, and as you’ll start to see, some of what we’re thinking about the internet of things is that it’s about focusing on what’s relevant to your company and not getting too hooked up on things like wearables and so on. I’ll come on to that later.

Very briefly about my company, we’ve been going for 13 years. Hardly anybody knows about us, 451 Research, and yet we’re the fourth largest technology company in the area of technology analysis.

Everybody’s heard, of course, of Gartner and Forrester. We’ve been a well-kept secret. We’ve not been brilliant at marketing, but we’ve made a number of acquisitions over the years including the Uptown Institute, Yankee Group, and so on, and we now are the fourth biggest in the world with over 1,000 clients and we’re really, we’re making gains.

So, I hope that part of this webinar will also make you think about whether or not there’s something that our organization has to offer your organization. Let’s focus on the challenge in hand then, the internet of things.

So, it’s not that new an idea. People started networking up Coca-Cola machines as long ago as 1991, so it’s not that new an idea, but it is something that now with sensors becoming cheaper and devices becoming smarter makes a lot more sense and is easier to do.

Now I’m afraid to say for my American friends, and I do have many of them, it was also a British man who came up with the idea of the internet of things, just like Tim Berners-Lee did with the internet itself.

And I’m afraid it was a British gentleman called Kevin Ashton who came up with the term anyway, who was working at the Auto ID Center at Massachusetts Institute. So he was working about how cars could be better networked, and some of the work he did started to work towards how you could see that devices could be networked up and so on.

So he kind of came up with the term and we’ll give him credit for that and he was a Brit, so that’s all good stuff; but the point is also that it was an idea that had been going on for many of years just like many of these things.

If you look at SOA or, you know, ESB’s or whatever, there are many, many years of kind of ideas and thoughts that go into the process before we get to where we are with the actual problem that we’re trying to solve.

So, what might IOT look like? This is a diagram from myotco.org, so basically, you know, the bottom layer, if we start at the bottom, you know, you’ve got some sensors.

They might be your smart phones, your iPhones, your Android devices, they might be sensors in industrial equipment. They are producing data that we may or may not want to analyze.

Higher up the stack, you need to send that data somewhere and this is the network and telecommunications equipment stack. You might need to distribute that data, share that data, et cetera.

Higher up the level which is where we start to get into the area that I really cover which is big data and analytics, you need to start to think about how you’re going to store that data, analyze that data, and make sense of it.

And then as you go up the stack, after you’ve stored it somewhere, you need to analyze it, which might need decision support tools, it might need business intelligence, it might need streaming data, analytics.

And then at the very top of the stack at the moment, we’re looking at this sort of data which you’re embedding into your own applications.

So, instead of me sitting in front of a screen and asking questions of my data, it’s already embedded into my applications. Whether I’m a user or a developer, or a customer, or a partner, some of the applications, some of that data is built into my application later on higher up the stack.

I mean, and one of the big questions that I’m often asked and, you know, in complete honesty I don’t need the answer to, is does the internet of things really matter? Does it exist?

Well, this was a study by GE on industrial applications and they found that if this was applied properly and effectively, then efficiency gains of one percent could result in 15 year savings of all these things.

Now I won’t read them out to you, but it just shows you – this is just one area of, for example, the airline industry, healthcare, patient and treatment flows, and fuel consumption in the gas industry, it just shows you, that’s just a few areas where they’re saying, you know, in this report, there’s massive savings to be made.

So should we be looking at it? Yes, we probably should. But also, of course, with caution and with care and without thinking that it’s gonna change the world like we think about many of these things in the technology industry.

So what’s holding it back, and if it’s been talked about since 1981, why aren’t we there yet? Well, there are a few reasons: the first thing is sensors are getting cheaper and easier to deploy and so on, but they’re not free.

And there’s still an issue around, you know, how much investment do we want to make in, for example, our supply chains? If it’s a box of, you know, I don’t know, cardboard, or if it’s a box of toys or whatever, do you want to put sensors on it? Do you want to track that? Do we need to track that?

There are other areas, obviously, where it becomes important, and I know, for example, that in the supermarket area, the most stolen goods are razor blades, and that’s because they’re very high expense relatively and very small fraud factor.

So that’s an area where we might think about putting sensors on them to reduce fraud, for example, and theft. There isn’t a standard this internet of things. Some companies are starting to work together between themselves, but there certainly is an internet of things.

They’re starting to become networks of things. This is one of the reports I’m working on at the moment, so, for example, Volvo, who I’ve spoken to recently, shared their information about wheel traction control with the Swedish Road Authority in order to try and help the Swedish Road Authority, you know, send their gritters out to the right place and improve road safety.

So Volvo is sharing some information with some organizations, but, of course, they certainly wouldn’t necessarily want to share their information with Ford, and Ford wouldn’t want to share their information with Google, so we’re having little networks built up.

For example, Nike might want to share its fuel band information with Garmin or it might not want to, and so we’re seeing these networks build up rather than a complete, true internet of thing.

And that’s partly because the standards aren’t there and also these companies don’t really want to share all of their information with their competitors for obvious reasons; so there isn’t a single standard and there’s a balance to be struck between the benefits.

Just briefly, again, the Volvo example is very interesting in that when they first announced that they had telemetry in their cars, they sold it as an extra add-on to customers.

And they said to them that if they bought this add-on at the time of purchase and they had an accident and the air bag was deployed, then Volvo would know about it and they’d either send in an ambulance or they’d phone them or whatever and help them.

And they had very low take up of that, something like 13 percent take up on using telemetry for that reason. A year or two later, Volvo realized that actually what Swedish people wanted to is have their cars warmed up before they got in them, and they enabled people to turn on the heating with their smart phones, you know, half an hour before they went down to their car.

And when they sold that as an extra add-on, they got 86 percent take up according to their CIO who told me about that. So it’s kind of like looking at the business case and where the real business value is.

And obviously users are going to be the real ones who decide on how the internet of things impacts them and how the internet of things actually delivers real value; rather than being something that a company can offer, you know, just because it can as it were.

This is a slide which I’m sure for many of you will be a little bit small, but it shows the growth in sensors and sensor devices. So, this is MEMS, which is the scale is microelectronic mechanical systems, including sensors and actuators.

This is a study not by 451 but by IHS, so we’ll credit to them. I won’t go into too much detail, but you can see predominantly obviously that the blueish, the dark, the greenish blue line is laptops and mobiles and so on.

Obviously they’re already smart so it’s easy to network them up and get some value from them, but we’re also seeing growth in the top line there from gaming, from cameras, from wearable devices and so on; and I think sensors also will play an increasingly effect in all of this.

So, you know, one of the reasons we did this particular webinar is because all of this internet of things creates a challenge for databases as well, and traditional databases like Oracle, IBM, DB2, you know, Sybase, et cetera, I suppose I should mention SAP Hana as well – you know, they weren’t designed with the internet of things in mind.

And so there’s become a challenge in the sense that application developers, DBA admins as well, are struggling to keep up with the challenges that some of this analytics is creating.

So, you know, a study by my previous magazine, Computer Business Review, found that 98 percent of CIO’s thought that IT was not delivering what the business expected, you know, that 98 percent of CIO’s think that the business isn’t getting what it wants.

And that is because of the challenge of delivering fast, rapid analytics on time, on the platform that people need it, but without a huge development cycle, you know?

It’s all very well developing something that gives you real time analysis, but if it takes you nine months to develop it, it’s still not helping the business as much as they need.

So these are some of the challenges that we’ve seen in the enterprise. So for data management, you know, first of all, Hadoop isn’t gonna save the world I’m afraid.

It’s very much batch, it’s very much process oriented, it’s very much aimed at putting a lot of data in there which you don’t know what to do with yet but you might analyze later on.

So we’re looking for new platforms, new analytic technologies that can break through the bottleneck of some of the relational technologies, and thereby give business people the analytics that they want and start to analyze some of this real time data that’s very different from what we used to have.

We used to have very structured, transactional data that came in because people made a purchase and it was a simple transaction. Now we’re trying to analyze data that we’re gathering every second from sensors on machinery, web logs, data and so on.

It’s much more complicated, it’s much more difficult to do with traditional technology. So here’s some of the answers and many of you will have looked at some of them, in memory options have been added to relational databases.

There’s pure in memory databases, there’s streaming, and analytics is a service and so on. The question is what exactly is your company trying to do, which of these makes the most sense in terms of your existing skill set, which means you have the least re-writing of existing applications and that you don’t have to throw away, you know, existing investments and so on.

Those are many of the sort of questions that you will think about when you come to those things. And also, where really is the business value and, you know, a lot of companies have phoned us up, 451, and said, you know, we’re looking at Hadoop. What should we do?

It’s like, if your question is what should you do, you probably haven’t thought it out right just yet. So those are a few thoughts from 451 Research on in memory and on the internet of things.

I hope you found some value in that and I’m now gonna hand over back to Nikita. Nikita, over to you.

Nikita Ivanov: Thank you, Jason. Great introduction. Welcome everybody. Thanks for joining us today. My name is Nikita Ivanov. I’m from GridGain Systems.

So what I’m trying to do as Dane mentioned in the very beginning is to kind of all of us three to give us a little bit different perspective on IT market and our technology around us.

So what I’m gonna do is kinda talk about technology that is frequently used and is gaining tremendous momentum in the analogy market, which is the in memory processing, in memory data processing.

And at GridGain, here at GridGain, we’re actually developing more of a key technology in this space and technology, and I want to give you a quick overview and a kinda peek into the how it’s used in IT applications and we can naturally dive into the example with contracts.

So before we dive into the GridGain product, I always start any conversation about in memory computing with a couple of thoughts about in memory, in general.

Why all of a sudden we talking about in memory computing in a very broad spectrum of applications from IT to big data, fast data, and practically anything that relates to a modern data processing?

So what’s in memory computing? In memory computing basically is a very simple concept. As you move your critical data from slow stream based in a slightly faster flash systems to a DRAM of computers across multiple computers in a clusters, things will grow faster, and that’s basically a simple definition of that.

And what’s interesting and a couple of interesting facts about in memory or in memory computing is that a DRAM, the ram in your computers, is anywhere between from eight thousand times to five million times faster than, for example, streaming is.

It’s a staggering performance numbers and that’s what basically attract a lotta people for the last, you know, two or three or four decades, into the in memory process, because if you do it right and if you have enough RAM, things can go dramatically fast.

Now, historically they have pretty natural challenges to our, to in memory computing. One major one was the cost. If you remember, you know, 10 or 15 years ago, the cost of Terabyte of RAM would be astronomical, and only big companies and three letter agencies could afford that.

That has changed in the last decade and when I presented on this topic, I always leave for example that a cluster, let’s say, 10 computers, 10 commodity blades from Dell, each having a 100 Gigabyte of RAM, total capacity with cluster is one Terabyte of RAM with all the gear, with all networking gear, with all the power gear.

This little cluster today costs less than $25K. Think about this: for the price of less than the price of a new car, you can buy a full functional cluster with a Terabyte of RAM.

Just to give you a perspective of what Terabyte RAM can do, just a short three or four years ago, the entire working set of Twitter, which is about a week of Tweets globally, was about seven Terabytes.

So that gives you essentially a pretty good ratio between what you can do at what price today with in memory computing, and in the last – and if you look at this chart again, you barely see that on the right, there’s a price of DRAM.

What’s interesting about this chart is that the price of DRAM is on exactly same trajectory of the price of spinning disks, and spinning disks today are essentially free; and the price of DRAM goes about 30 percent every year and a half.

So, the price, the economics of in memory computing has dramatically changed, and all the analysts believe that essentially it kinda crossed a pivotal point where the price and economics of RAM is not, is no longer a problem.

The RAM is available, RAM is cheap enough relative to its value that a lotta companies jumpin’ on. But what really also changed in the last, again, five to seven, maybe two decade, last decade, is that unlike 15, 20 years ago, we now have a tremendous demand, and the IUT is a tremendous force behind the demand.

We didn’t have the things like fast data over the big data in terms of the size and the volume velocity. We naturally didn’t have the IUT as [unintelligible] as we have it today. All of those things drive tremendous demand into the real time data processing.

I mean, you cannot build an IT system of any kind if, you know, your processing takes minutes, sometimes even seconds is not allowable in this context.

So the demand on the one side and economics on the other side is what basically this maxus of this two trends is what driving the rapid adoption in memory computing.

The last part I wanna leave you with is kind of provocative thought but it’s a very interesting one, is that if you think about in memory computing, this is practically a lost frontier in a data storage technology.

Think about this: from late ’60’s we use takes for predominantly for, you know, predominant data storage technology. Late ’60’s, early ’70’s, we switched to hard disks, and hard disks with IBM systems and spinning systems become available and economically feasible.

So we switch to the hard drive disk and spinning disk, and we have this technology being progressed up until in our early ’90’s. In mid-’90’s, we developed the flash technology. From mid-’90’s to mid-2000’s, the flash was the key speed-wise.

And now we’re moving to a in-RAM and in-memory process of data storage data, and it’s fast and it’s great. But think about this. What’s next? If you think about it, there’s nothing really next.

We always knew that the absolute frontier, absolute Holy Grail of data storage stored in RAM because it’s a tremendously fast, it’s close as possible to application, and we are essentially there.

There’s a software widely gained in some of the projects and products, there is a economics there, there’s men there, hardware’s are really there. What’s next? There is really nothing next.

You know, people say what about a CPU cache? Well, a CPU cache is about three times faster than the DRAM, it has very small capacity with physical limits.

So there is literally nothing else beyond in memory computing, unless we fundamentally change the architecture of the computer as we know that.

And that’s what gives in memory computing and like flash a very different filter. This is not a stop gap solution. This is to basically acknowledge that it’s gonna be with us for the next 10, 15, 20, 30 years until we fundamentally re-think how we build our computers. And that’s what makes in memory computing really exciting.

So let me talk about what is it we do at GridGain to really make this reason reality. What we develop is what we call in-memory data fabric. Essentially it’s a Java based, distributed software, middleware that allows it to take data from a variety of traditional data sources that depict on the bottom of the slide: sequel, no SQL databases, Hadoop pay loads, and move some or all of this data into the fabric.

And new applications on top can now use this data in an in memory fabric to run a variety of different types of use cases and types of payloads processing.

And what makes the fabric a fabric is really the long set of different types of processing you can do on that data once it’s in the fabric.

You can reproduce map produce, rather support three types of map reduce application of processing will support traditional Hadoop based, yarn based, map reduce and support, essentially two types of optimizing memory map reduce applications or type of processing.

We’ll support traditional data grid use cases with full processionality, full sequel, full key value access and we’ll talk about as well.

We’ll support compute grids where you basically can run in paralyzed computations in a variety of different shapes and forms which support traditional message passing MPI style processing, MPP processing, just RPC, close or based execution, a variety of different things.

On top of that, we supports three different types of payloads: we have had various implementation of streaming with a full sliding window and SQL distributing as well.

On top of that we have, you know, things, for example, like file system and Hadoop acceleration for [unintelligible] based systems and what not.

So when you basically start learning about Apache GridGain and we’re actually based on Apache Ignite project, the words fabric will start making sense.

It is not just a once analogy, one particular small use case. We look at in memory processing more strategically. It will give you a strategic view on in memory processing with a variety of different types of payloads you can process on that fabric.

So let’s talk a little bit quick on a specific functionality that we have. Again, we only have about left about seven to eight minutes, so I’ll be pretty quick here.

So, again, the key behind the fabric and the one thing I want you to remember, is that it’s not just a one use case. It’s a variety of types, of different types of payloads and types of processing.

It’s a very important to know distinction between what we do and the rest of the industry, because in memory is literally just a generic storage layer.

You can do lots of different things. It’s not only SQL, it’s not only map reduced, it’s not only streaming, it’s not only compute, it’s not only file system.

You can do all those different things and different applications require different leagues of this functionality. And that’s why we basically call it fabric where it essentially denotes the idea that in memory is just a strategic storage layer for you.

What you can do on it is a long list of different types of payloads. So, for example, data grids. Data grades are all about parallelizing data storage. How do you basically – if you have a long, lost disk set, how do you store it as data set in a data grade?

How do you parallelize, how do you transact, how you load down, how do you fail over, how do you do processing of this data through a key value access, through a sequel access? We support all of that in data grade.

Contig grid’s another side. Deal with the parallelization of a processing. How do you paralyze your all grids? Again, it sounds very simple but it actually has a lot of functionality behind it.

Again, how do you load down, how do you fail over, how do you do clustering around that, how do you do all these different things? It’s also part of the fabric. We have a service grid. Again, how do you run services with SNLA on a grid or on a cluster of computers?

Lots of different options there as well. Training yet another use case on exactly the same in memory storage layer. How is it different from data grade? Well, it’s different because training has no beginning and no end.

It requires a different types of processing. Typically it’s based on a sliding window of lost in-events, lost five minutes, lost anything. So essentially a sliding window. You can define a function on that sliding window and get a call back from application standpoint.

So there are different type of processing, but, again, it’s based on the same fundamental idea and memory processing and utilizing the same storage layer, and the list goes on.

For example, we have a very cool Hadoop accelerator that requires absolutely no change to code, complete plug and play acceleration for Hadoop.

Again, the idea that we inject this in memory data fabric in a head stack is we actually redevelop the map reduced HDFS fast to make it full grade memory. We have our own HD fast compatible file system and our own yarn based map produced implementation.

Both of them give us this ability to inject fabric into the Hadoop cluster and really gain the performance benefits. By the way, it’s pretty cool technology. We – if you run the data fabric in the Hadoop with absolutely zero code change, you get anywhere between 2 to 50 times faster processing of your unchanged map reduced code written Java maverick, Hive, Pig — anything you like. Pretty cool stuff.

And then on top of that, we have a file system, we have a messaging, we have a events, we have different data structures that are fully optimized in memory costing, and the list goes on.

Once again, the – on the short kind of quick overview, one thing I want you to remember about in memory data fabric is that it is strategic view on in memory as a storage layer.

We think about it as basic and we provide you all this different types of processing and payload processing on that fabric. Quick slide about a change, about the difference between open source and enterprise version, but we are based on Apache Ignite.

It’s a full Apache project. Everybody’s welcome to look at. What GridGains does, we provide you basically enterprise version of that, that has a number of a production features that you really like in production settings, such as security management, data center application, rolling updates and what not.

So you guys can peruse this information right in our website if you’re interested. Couple of words about a use case. It’s kinda, I think it’s important to list those use cases to understand where it’s been used.

We’re used in a pretty wide variety of different use cases. Financial services would be one of the cardinal or key use for us. The whole in memory computing started there about 20, 25 years ago and it still is today one of the top users of this technology.

So anything from automated, you know, trading systems, you know, any types of risk analysis, real time analysis for portfolio, for trading, any kind of, you know, high traffic with the trading applications and the rate applications would be what has been used here.

We also use quite a lot in our on-line mobile advertisement, any kind of a geo in an ad hoc advertisement is really making a real time process a lot of information we use there.

Big data analytics is kinda an amorphous term, but you will probably, you are hearing a lot about in memory analytics and the key take away here is that everybody use everything right away.

And in memory computing is all about performance and if we see a lotta usage of that performance around the technology and a lot of this analytics applications, you have big data, essentially big data sets is analyzing and quick in real time.

On-line gaming is another scenario we used actually by Sony and quite a few games house on the back end. Again, modern online gaming really shifted away from a console orientation to the back orientation where a lot of different functionalities in the back end. That’s where all the money is made by optimizing the emerging platforms for the online games.

If the use case kind of crosses the industry’s as a SaaS enablement, we see a lotta customers in years basically more [unintelligible] traditional clients or architects to the SaaS basis and SaaS models.

And what happens there is essentially overnight you get into a dramatically more users in the same infrastructure, you have to have multiple accounts, you know, if you have to have very different kind of scalability profiles, and once, again, in memory processing helps dramatically here; because nothing else can give you a three to four orders of magnitude performance increase the way, you know, comparing to disk and flash other than RAM, other than in memory processing.

And we’re seeing that with a source enablement trends in the last couple of years. One of the coolest examples involved the coolest customers we had was a contract and Ilya will talk a lot more into just what ChronoTrack does.

We work with ChronoTrack a couple years ago and it’s really one of the coolest examples we had. It was considered one of the pure IT plays.

They captured thousands of, you know, over advanced RFID chips attached to the racers, and the ChronoTrack, you know, basically does the race management and race automation, and they collect those events and they have to really process them in real time.

And unlike anything else, this is one of the clearest IUT use cases we’ve seen in a while. And without further adieux, Ilya, let me switch to you so you can best talk about details there.

Ilya Sterin:
Okay, great. Thanks, Nikita. Hi, my name is Ilya Sterin. I’m the Senior Director of Engineering and Product Management here at ChronoTrack, and you guys probably noticed that I like black slides with light text on them, unlike everyone else.

We’re also – you can, you notice that there’s a lifetime logo here. We’re a part of a bigger organization which is life and fitness. Lifetime Fitness is a global German company.

Many of you I’m sure in different states are from parts of least the United States, probably have been or seen a Lifetime Gym. So I’ll just jump right into what we do and what we did with GridGain and just in memory computing.

So, how do we keep our lights on? Again, we’re a contractor to the global leader in endurance event solutions, which means marathons, triathlons, cycling events and so on.

We do some of the biggest events out there like the New York Marathon, Paris Marathon, you know, Santiago Marathon in Chile and so on.

We – as Nikita mentioned – we provide RFID tags and those tags go – for those of you that aren’t runners – those RFID tags go on bibs that are then attached to the runner.

And as the runners cross various check points in a race, we have RFID readers that capture that data and that data is then streamed over GPRS modems or various other networking means to our call servers.

We also do registration of athletes for participating in these events. That’s basically our e-commerce platform. We do timing and scoring, so what timing and scoring is, is basically what happens when this RFID chip reaches our call service center.

We aggregate the data, calculate the time and the range of these athletes, and before we do all of this, we map the actual RFID chip to an actual athlete that’s participating in this event. So there’s a lot of data processing.

We also do messaging in media. Basically what that is, is athletes and their family, friends, followers can sign up to receive notifications about their progress in the race. These notifications are through SNS, Facebook, Twitter and so on.

We also do media, which is photography and finish line videos. We have various algorithms that work with the temporal data that’s streamed to us from our RFID readers, and we do the matching for the photos so you can, you know, go to the website and out of the thousands and thousands of photos can just look at the five photos of you.

Same thing happens with our finish line video. So, issues we had and we still have some of these issues as any company does, so we’ve grown quite rapidly and endured, you know, quite some growing pains while we grew.

What was developed for a couple of events initially coming out of a start-up and a few thousand runners not have to scale to thousands of events and millions of runners.

Our traffic patterns are somewhat predictable in terms of what we know, like, how many events we do for the weekend and how many runners are participating in those events; but we can’t predict, like, the popularity of the events and how many people are gonna be registering this weekend and so on.

So this creates a lot of contention in our system which leads to various interweaving of traffic patterns and so on which are really hard to predict.

We had, you know, we have load tests and, you know, they all passed with flying colors when we ran ’em, but only to be surprised on the weekend when the patterns were completely different.

So, thousands of races and a few million athletes doesn’t sound like a lot, but the data points that are associated with timing these are quite large.

So when you consider each athlete that crosses about three to five check points, and then the RFID readers transmit these crosses, and so a lotta times they read, they do multiple reads, right? So you don’t just receive a single read for an athlete crossing a checkpoint.

And each race then places the athletes in three plus brackets. Brackets are basically groupings of athletes. For example, your age group, your overall group and so on. So, a 10,000 person race, 5 check points, 3 brackets for each athlete quickly turns into, you know, 300,000 data points, right?

And then multiply that by 50 races on the weekend and now you have your, you know, about 50 million data points that we’re processing here.

We sometimes have little control of the order and the way the data gets to us, and even though we own the devices, you know, we don’t necessarily control the devices at the race site.

So race timing is a very intense exercise so at any given time, you know, controllers are going off-line, someone forgets to configure something, network goes out, it’s raining and so on.

So the point I’m trying to make is that we don’t have predictable data flows or algorithms have to create order out of chaos. We started with a single relational database system and although the rest of our software is pretty stateless and horizontally scalable, it was pretty easy to do from an architecture on the software side.

The database remained our single point of value, right, and the single point of contention, our relational database. So, that was a big issue for us and as any other start-ups, you know, we have to move fast.

Features trumped engineer impurity, you know? No one wanted to end up with a greatest technical product and no customers. So we did, you know, we did our thing and along the way acquired quite a bit of architectural technical depth, and it wasn’t very easy to pay it back at the time what we needed to pay back quickly.

So, ideally, this is where we wanted to get, right? So we started thinking about our architecture. Some basic high level necessities came out of that. We wanted to get away from using a relational database system for data that needed to scale.

We wanted to be able to partition our data that would allow us to basically horizontally scale our data storage, and since we’re partitioning our data, you know, why move it around at that point? We can just do the calculations on that data right on the, within that memory.

Basically, you know, making computations and memory without any networking overhead was our goal, or was our eventual goal. We wanted to be able to add and remove data and rows on the fly. That was a big deal for us.

So the dynamic being horizontally scaling was big because of our traffic patterns, and because they are unpredictable, we needed to be able to do that at any given point in time.

And, you know, while the genie was out of the bottle, we wanted also our system to be economist, though responding to any basically no loudigous network fragmentation, et cetera that can happen in distributed systems.

So, you know, a lotta people stay away from distributive systems for as long as they can because of all the issues that, all the complexities that come with distributive systems, or at least used to in the past.

So, what did we do to make things better? So with any new start-up, we wanted to see improvements and we wanted to see them quick, right? Everything was a 24 hour turnaround. We started by simply distributing computations without any data storage changes.

The data still had to be pulled from the database and it still traveled over the network, but at least we, you know, secured their actual computation distribution. We didn’t make it any faster at the time, but it was definitely super, super stable.

The contention was still there. We still used the single database, but our computations were now distributed amongst multiple CPU’s. We built this in a week. It was right before Thanksgiving weekend. Thanksgiving weekend is our heaviest weekend.

A lot of people, you know, want to eat – I’m sorry – want to run before they indulge in the turkey, you know? So there’s a lot of, like, turkey trials and so on, so we do a lot of races on Thanksgiving weekend.

We built a solution on top of GridGains’ compute grid, and the first time we deployed it was on the Thanksgiving weekend. It was pretty nerve racking at the time, I remember, but the system ran flawlessly like all weekend.

I remember commenting to someone a few weeks later that, you know, we needed to go in and do some monitoring on the system, and I literally forgot where this thing was running, right? It was just flawless, you know?

The box came down, you know, we would add another box and so on, so everything was pretty flawlessly running. So, the second thing we wanted to do – the second stage in our endeavor was to utilize the in memory data grid.

We put data required for calculations into the data grid. At that point we had to rewrite our algorithms to do the calculations or ranking, you know, to all the queries and do them in memory. That transition was pretty straightforward as I remember.

It’s been a couple years. The data, the great thing was the data was modeled very closely of how it was originally stored in our relational database, and this is because of the way GridGain’s storage is.

It’s basically built on top of sequels so you can model your data the same way you would in a relational database. You have to think about partitioning, you have to think about various other things, but you definitely don’t have to, you know, jump through all the hoops that you have to with just regular key value storage.

Our overall experience with GridGain was really good overall, you know, from the first project. We’ve been working with them for a few years now.

We did look at a few competitors. Nothing really stood out at the time, mostly because the GridGains’ guys really had a really intuitive, simple API and DSL’s on top of, you know, their data grid, their compute grid, and, of course, we could just write sequel queries which was great.

We were used to writing sequel queries. And then a lotta people, you know, think these days the only way to scale is distributive no SQL, but there’s nothing about sequel that makes it less scalable than anything else out there in no SQL store.

It’s just mostly the leftovers from the old, you know, relational database world. If you look at most of the, most sequel vendors out there, they now started to have their own variations of sequels to their product, right?

They don’t call it sequel. They call it some other query language, but they’re all doing it. One of my favorite quotes I remember by Michael Stonebraker, I was at a conference watching one of his presentations.

He said most sequel folks are basically doing what relational folks did over 30 years ago, and they’re now doing basically on-job training; and what came out of that, you know, 30 years ago was sequel and a declarative way to, you know, to run queries on your data in a way to sort of model your data; and it, you know, doing it in those sequels is quite a bit harder.

So after we did this, what did we, what were the results? All right. We went through all these exercises, we engaged in this – the second project was a little lengthier than the first one, and what did we get out of it?

Our timing and scoring which we used to call “real time” at the time was two to five minutes, and we shaved it down with this last project to basically less than ten seconds.

Queries that rank athletes or athletes get ranked based on their age groups and their overall groups and so on, they run in real time versus before we’d basically have to pre-cast their rankings by materializing things in the relational database, and that was just a very lengthy, heavy process.

And it all happened on disk, so it took, you know, up to five minutes at times depending on the complexity and the size of the race. The other thing that we have now is we can add capacity on demand.

We didn’t have that with our relational database. With our relational database, basically we run everything on Amazon AWS or we used the RKS box. We were consuming at the time – I think there were 8X boxes which is the largest – and we were still running out of ’til after the end of the weekend.

And now we can add capacity on demand. When heavy weekends are coming up, we can add more notes, we can take ’em down as needed. So, what do are we doing now? This is a joke, of course. You know, we took a long, hard nap afterwards.

It was a lengthy process from going from start-up to, you know, fixing all of our scaling issues, but we did it and, but seriously, what we’re doing is we’re growing pretty fast.

What our new architecture allowed us to do is basically focus on our product and features, and not have to worry every weekend whether, you know, our system is gonna go down or whatever, not gonna have enough capacity and so on.

We also learned a great tool which is GridGain and now on open source Apache Ignite, and, you know, we are planning on using it further down the road for other projects to help us scale other pieces of our infrastructure that need scaling.

And last but not least, you know, obligatory we’re hiring because we’re growing, and we have many positions in engineering and product, and if anybody is interested, you can connect with me and my contact information is on the screen and I’m sure the slides will also be emailed to you. Thanks.

Dane Christensen:
All right. Thanks, Ilya and thank you Jason and Nikita for your presentations as well. We do have a few questions that have come in and so let’s go ahead and, you know, take a few of those questions for the folks.

We don’t have a whole lotta time for questions, but we’ll get as many of them as we can in here. I’ve got a question for Jason. Jason? What role do you think Hadoop will play in the era of the internet of things?

Jason Stamper:
Thanks, Dane. It’s a great question. I think Hadoop will be used for solo stuff that we don’t yet know what we want to do with it; and to some extent that’s a bit of a contradiction, because, you know, companies might ask themselves why they really want to be storing stuff that they don’t know what the value is yet.

But they certainly will be. In the area of the internet of things is the question I’ve called it. There’s all sorts of data that’s gonna be flowing in from sensors, machines, web logs, other computer logs and so on.

And I think some companies will store some of that in Hadoop, and some of it they’ll try and analyze on the fly using more real time systems and more analytic systems like GridGain. I think Hadoop’s failure so far is that it’s mostly geared up towards back processing.

It’s not really designed for real time analytics. Of course, there are projects in the open source space like Apache Storm and Apache Spark streaming, which are trying to deal with some of that deficiency.

But for the moment, I think Hadoop is sort of somewhere to put your data that you don’t know what to do with yet, and people have called it a data lake; but of course once you’ve got it all in there, it can become what some other analysts have called a data swamp in the sense that it’s very hard to know what’s in there and how to then analyze it and get value from it.

So, a very long answer but to summarize, I think it will have a role to play for data that you don’t know what to do with yet.

Dane Christensen:
Okay, great. Great answer. Here’s a question for Nikita. Isn’t in memory computing dangerous since memory is temporary storage and power loss means data loss? How is this being protected?

Memory processes faster than hard drives can, they can’t be in sync.

Nikita Ivanov:
Well I think it lists two questions in this one. So the question about durability in memory solutions has been raised for the last quarter century, and we find ways to deal with this long time ago.

So there is a back-up strategy where a data is backed up on multiple computers in a cluster, there’s natural an ability to do synchronous in asynchronous deck out to local drives if you wanna do that.

On top of that, there is an option of disk central application if you really want to have a geographically distributed data store, and kinda disaster, you know, recovery situation, you can do a geo-distribution between multiple data centers.

On top of that, we actively working with a newly developed non-volatile RAM, which is the entire topic of conversation we have. So on top of the features that I mentioned already, you know, a year or two from now, you know, we’re gonna have, you know, pretty good availability of a non-volatile RAM which is called _____, and this whole issue will disappear as issue at all because RAM will become non-volatile.

You can unplug the RAM from power, plug it back, it’s gonna retain its data or basically without any issues. So that issue is solved today and it’s gonna be solved even more elegantly going forward.

Now the question about synchronization between hard disks and RAM is somewhat related to that, but not necessarily. There is a great technology built in the GridGains specifically to keep your RAM storage and whatever else disk based storage; whether it’s just a file system or, you know, a DOT basic or no SQL Hadoop to keep those two in sync and in sync in a way you want it to be.

You know, if you wanna have a full transactionality synchronization, you have that, but obviously gonna pay the performance penalty there. You can have all kinds of optimizations around that.

You can do the asynchrony in a offered or not, so you can basically have synchronization between your RAM in between your non-RAM storage in any way possible you want; all the way from full synchronization to a very fast asynchronous way.

And you as a developer, you know, you have the knobs to turn to decide which task synchronization, if any by the way, you need to have.

Dane Christensen:
Okay, excellent. And, you know, we just have probably time for one more question, and I’ve got this question for Ilya. Ilya, maybe just like a one to minute response on this. Somebody asks what other in memory computing solutions did you try before deciding on GridGain?

Ilya Sterin:
Yeah, so, we tried – so when we first started off, we tried – I remember ’cause it was many years ago – a company called Gigaspaces. Basically it was an in memory Java space architecture model.

It was a good architecture at the time, but the solution, the system itself had a lot of things to be sort of desired. It had pretty bad monitoring that I can remember, so, you know, even though everything was running in the grid, it was really hard to know when things went wrong and where to look and so on.

And then grid management capabilities were pretty weak. And this – we were also using them, I think this was like back in 2009 and it was right before the financial crisis and I think all of their customers at the time, they weren’t in an open source solution and all of their customers were financial companies and so they lost a lotta business and almost went out of business.

I think they’re still in business and I’m not sure what they do now. I think they focus more on very specific solutions, but I won’t comment on that.

We also, as probably any other company, looked at Hadoop pretty extensively, and me, myself, you know, especially working in a start-up, we don’t have a huge infrastructure team.

Hadoop requires a lot of infrastructure and not only from a harder standpoint, but just from a management standpoint. It was just a nightmare. And then everything sort of has to be programmed to a very rigid, you know, map reduced model.

It fits very well for some use cases, but it doesn’t in others. And then the whole idea of batch versus real time, I think, was also disconcerting with Hadoop, right? We needed answers in real time, and at the time, you know, Hadoop was a batch solution and we couldn’t wait that long.

And we also, I think – again it’s been a while – but I remember we looked at some data and compute grids. They were separate, though, you know?

They were, I mean, they were distributed store solutions and there were other tools to allow you to distribute your jobs around, you know, your CPU nodes, but none of them were very well integrated, right?

So if you wanted to actually have data and you wanted to store your data and, you know, and compute that data within that same sort of memory segment, you couldn’t do that. Or at least you couldn’t do that very easily without a lot of integration and so on.

So, at the time and I think it still is the case, I think GridGain is just, you know, the leading solution out here. At least I haven’t seen anything that beats it.