88. Monitoring Productivity through IoT

Corey: And what are some examples, both of you, that we would know from our everyday lives?

Brandon: The Nest Thermostat is probably one of the bigger ones, at least in the US where you could set certain temperatures at certain times to control the temperature in your home. And that object is connected over WiFi. That would be probably one of the more popular examples.

Yuri: So well, I think Android, it can be an IoT device as well, even though we don't see it because it's more of a general purpose device. It can be viewed as an IoT device too.

Corey: Okay. So you built a product for a company named RMS Intermodl and they're a freight transportation company. Could you explain that industry?

Brandon: A few years ago I actually didn't even know what Intermodl was. And it's the concept of transporting a shipping container with different vehicle types. So you could use a boat or a train or a truck or any combination of those. And what RMS is doing is they work on the operations logistics side inside these rail hubs. So there's a bunch of hubs throughout the United States where trains come into and then those loads of containers need to be unloaded or loaded as quickly as possible. They do other things as well, but that's definitely a large chunk of their business. And it's actually they're moving more now than, than ever before. So there's more stuff going across trains than recent years.

Corey: So this is really powering a lot of our shipping industry.

Brandon: Definitely.

Corey: And you built a product for RMS named Intermodl, would you explain what that product does?

Brandon: Yeah. The idea was, actually John Gray is the president over at RMS Intermodl and his son had come to us and had asked about tracking in the yard and just being able to see things better. Because right now what the managers had been doing was drive around in a truck with a radio and they would corral the troops as they unloaded from one track or the other. And it's a rather large yard, so they could be at the North end or the South end, and you would literally need to cruise around in a vehicle. And so the main objective in the beginning was to look at this live picture of the yard and to see everything buzzing around like a hive. And it has some similarities to maybe Uber or Lyft in that regard where you could see who's doing what and what their activity is, and maybe when they started that. And then that's how a manager could make a better decision. So that's kind of one portion of it.

Brandon: And then the other part of it is looking at yesterday's activity and recent activity in order to pull something from the data to understand, hey, how could we have actually loaded or unloaded differently here? Or how is the morning shift or the evening shift doing something that we could learn from? So it's this two part thing where they wanted to increase productivity and have a smoother operation. So we have this live picture of it, and then we have this analytical or data analysis portion of it.

Corey: So what is the experience of the driver using the Intermodl product?

Brandon: So something that's different about a driver with this application versus a driver that may be delivering for Amazon or FedEx, is that those drivers actually don't get out on the open road and head down the freeway and get off and head South and then turn left, they're within this large yard, that's like a big open construction site. So for the driver, we wanted to make it so that they would basically just do one or two steps and then everything else would be in the background. And one of the things that they used to do is that they used to have a vehicle checkout report, a VCR, which would be very similar to when you go and rent a car at a rental car place, you know how you have to check the car out and you walk around it to make sure there's no damage?

Corey: Yep.

Brandon: They do that same process, but they used to do it on paper. And so then they'd hand that over to the mechanic. And if there's anything they need to check out, replace some tires, or lights, or something like this, then the mechanics know that they need to check that out later on that vehicle. Or sometimes if it's more serious, they'll take the vehicle down. So that's the only step that the driver does for the most part, they log in, they say, "Hey, are there any problems or not?" Record the engine hours of the vehicle. And then that starts a session for the driver. And that's the driver's perspective of what's taking place in the application.

Corey: So the drivers in the yard are using your app on the Samsung tablets in the vehicles. What about the managers who are monitoring what's happening and making sure that everything's on track, how do they use your platform?

Brandon: So it's definitely different for managers. When managers log in, as of right now, they could log into the tablet and be out in the yard themselves, or they could log in from the browser. And when they log in, they see the live map first. And so they could see various colors and different shapes that correlate with different vehicle types and statuses. And then they could select these individuals or tag these individuals to see who might be working in one area and better monitor that individual or to see what they had been doing recently. And then from there they can navigate into other places in the application. Like they could do a quick audit on somebody if they'd like to, they could see what happened yesterday for productivity. They could check that person's activity for the past month. And these are some of the various things that could be seen and done from the manager's perspective.

Corey: Now I want to talk a little bit about the tech. It seems like there are many pieces here. There's the driver app, the manager app, a web interface, sensors with a lot of signals output from those to your stack. So there's a lot to talk about here, but starting from the beginning, how do you even start building something like this?

Brandon: So it was a couple months of research before we even started. We went to the yards and just watched and we interviewed the managers and we sent out surveys using Survey Monkey. And we just did a lot of homework and discovery to see, what is this problem? That's one of the things that I've noticed is that sometimes when people describe their problems whether it's job related or not, there's a lens that they've put over the problem. And in order to tease out where the value and a solution could come from, there's a good amount of studying that needs to go in there. And like I said before, didn't have any experience specifically with Intermodl. So there was a good amount of learning in the beginning and just documenting what we see as their process and then passing that to the client saying, "Okay, so is this how it's done?"

Brandon: I actually had made a diagram of the steps that are taken to load and unload, and then matching that with the terminology that they call inbound and outbound, and then different move types that are done with the containers, whether you're placing, loading, unloading, clearing. So to understand their vocabulary, to understand what their current pain points are, to make sure that you're on the same page as to declaring the problem and declaring the solution, that was done for about two, three months before we actually started.

Corey: Started building.

Brandon: Started building. Yeah, there was definitely, I mean, there's some generic things that were for sure in there, like we knew that we'd have to host somewhere. That's why we're here. And we knew that there would be users and we knew that there would be sessions, but we didn't really know what a session would look like for a user and what would be in there. So it was just rough drafting a spec doc for a couple months with some simple use cases and user flows to make sure that we were aligned with what the client was seeing.

Corey: I want to do a bit of a hypothetical semi signal from the sensor and one of the vehicles and I start there and then I take a journey to your infrastructure. What is my journey? It's a bit of a funny question, but what is the signal's journey?

Yuri: Well, all of our tablets are Android ones and they're working on 3G and 4G networks. As they are vary, sometimes they can be in a very remote places across the US, we have to rely on 3G and 4G networks. And they mostly as a signal you would impart from the same sensors. We collect 10 data points on each tablet every two seconds. And you would be collected, you'd be center across the 13 network through an HTTP request. Then you would hit a lot of routers across the internet and stuff like that until you had a theoretical API, I think it's cowboy if I'm not drunk. And then from then on, you would be inside our core infrastructure.

Yuri: We have some node clusters, we have something around eight node notes on our infrastructure. And as of today, we're dealing with something around 100 and 100-something requests per second. So you would enter this infrastructure and debating on which signal you are, if you're a data point signal coming from the sensor, you would go to the Kafka. So you would produce a data for our Kafka broker, and you'd be there until our consumer gets you. And then you'd probably go to Postgres. If you're not coming as a sensor data, if you're not a signal from the tablet, if you are coming from, I don't know, from the browser or from the manager tablet, you would go straight to the Postgres.

Corey: So Yuri, you mentioned Kafka, which I'm spending some of my time in as a signal here. What made you decide to use Kafka in this case?

Yuri: Well, in the beginning we didn't use Kafka, even Redis. We started in a small yard in Oakland, California. So as we scaled up in the company and we scaled up into more yards. Brandon came to us once and said, "How about dealing with 1,000 vehicles online, 1,000 vehicles sending 10 data points of sensor data every second or every two seconds?" We needed a solution that could be reliable, where we would be able to store data for some time, for a period of time, in case of anything bad happens and bad things happen sometimes. We decided for Kafka because of its capabilities and its robustness.

Corey: How do you aggregate that data, and then present it to say a manager who just wants a summary of what's going on and how do you stay performing while you do that?

Yuri: As Brandon was saying earlier, we have a table that gets all the sensor data after Kafka processes it. We have three models of table because we aggregate them in time. Like, imagine that one device sends sensor data every two seconds or something around that, because there can be a 3G or a 4G network offline and latency and things like that. So we get all this data say for a minute, and then we create another data from it. We just accumulate it so we can have a bigger spectrum in time. And from this, we can also have an aggregate metrics. So, say a driver hasn't been driving for the best two hours and he should, because the train is there and the manager knows the train is there. And we get his sensor data, and then we are aggregate it into a bigger table.

Yuri: And from that, we can know that this guy has been slacking or idle for a certain amount of time. After that, especially for the web app we've been using Redis a lot to cache data, especially as we are creating more metrics to learn more about the driver's performance and how they've been performing in time, like for the past 90 days and a whole yard for the past nine days, we've been using Redis and we've been using somewhat of a background jobs. We use a Heroku Scheduler, a lot to run some background jobs and to do some heavy calculation.

Corey: So it sounds like between Heroku Postgres, Heroku Redis, Heroku Scheduler or Apache Kafka on Heroku, you're using pretty much Heroku native tools that are available right on the platform for most of your infrastructure, it sounds like.

Yuri: Yeah. I think from outside of Heroku, we're using, I think, yeah, it's mostly AWS S3 and AWS SQS because we do some imports. We import some data from the train companies and even from RMS as well from their internal systems, we are becoming kind of a proxy, a gateway where we aggregate not just the sensor data, it's our core, but we are also starting to aggregate data from all their systems and integrating with different systems being shifts system or railroad systems.

Corey: And it sounds like you're really leaning on Postgres to manage all of this aggregated data. Are you doing the aggregations in an app and then loading them to the database? Is it aggregations by query? What's the mechanism for essentially turning in a lot of data and individual signals or from other systems into quickly queryable data?

Yuri: Part of this aggregation we do in the Kafka consumer. So yeah, we do some calculation in memory because when we get Kafka data, we don't just pass them through Postgres at once, we wait, so we accumulate some data and we do some aggregation in heavy calculations in memory in the Kafka consumer, before bulk creating the rows in Postgres. That's for the sensor data.

Yuri: For the other kinds of data that we receive from the company in other systems, we have the SQS query, this consumer downloads the files. We deal with a lot of CSV and spreadsheet imports and we do some calculation there as well. And then we save on Postgres. In Postgres itself, we use PostGIS a lot, the extension, because as we're dealing with yard maps, and as we are dealing with driver's movements inside yards, it's very helpful to have zones and polygons in the map so we can derive and have bearing sight about the data that we are receiving.

Yuri: Postgis is a Postgres extension to deal with the geographic data. We lean on it a lot. We've been leaning on it for the past two years. We've recently upgraded Postgres from version nine to 12 and Postgis for two to three as well. And it's been great, sometimes challenging, but very interesting to work with it as well.

Corey: So, one thing that I personally really like about what you're talking about is that you're using these really well-established open source tools, you're making platform decisions that allow you to manage everything centrally on Heroku, which I imagine saves a lot of time. How did you end up there? Did you think at the start about where you would put your apps and your data, and did you compare Heroku to any other platforms and what drove your decision to really centralize on Heroku?

Yuri: So in a previous project, I had used Heroku before, and it was so simple. And although I can code, I'm so slow, that Heroku is great for me, because I understand how to turn things on and off. And some of it is just like a UI, obviously not all of it is, but the premium that's paid for Heroku is just so worth it. For example, looking at Kafka, we didn't know that we were going to use that in the beginning. We knew we were going to need something like it, but it just seemed like a no brainer because we needed to get to the point to prove what we were going to need or to prove the viability to just go with Heroku, because we didn't want to have to get caught up in the DevOps.

Yuri: I'd also say that I don't know that there's a reason to necessarily leave Heroku given the size of the project and how the end client would like to receive the project. Probably I would imagine most clients would just want something that's just plug and play. And once you have something up that's working, that's nice that they like, they could probably just stay with Heroku. And it makes sense to. The libraries that have a lot of support so that when we do hit a wall, hopefully somebody has been somewhere in the vicinity and we could hopefully find some help.

Corey: Yeah, absolutely. That's great to hear. I want to zoom out a little bit. So we've been talking about a specific IoT app here. I want to zoom out to Internet of Things in general. We might have listeners who are interested in entering this space, who are really curious about it. So I'd be really interested in your personal stories around, how did you decide to get started in IoT, and what was it like? Was it intimidating at first? How did you learn, what resources would you recommend for someone else? That's like 15 questions, but I'm just really curious.

Brandon: Well, for me personally, the first startup team that I was on, it was a pretty small team as well. We were called Bibs and that was after the runners bibs that runners ware.

Corey: Oh, wow. Yeah.

Brandon: We were looking at RFID equipment and we built this technology that allowed us to communicate with various RFID hardwares. That was this value add for all these race directors that have 5 Ks, 10 Ks marathons. And so we were able to give them affordable tech that made them more attractive to draw in more athletes. And that was my first intro to Internet of Things. And that was over six years ago. Now that was where I found out about the Internet of Things. And I know that the whole innovation tech world just keeps moving forward. And so AI and machine learning right Things are pretty big, but I could also see that the Internet of things just has so much more potential.

Brandon: It's just that it's on the enterprise boring side. And so it's not as excitingly disrupting and like flashy. I just think that it still has a ways to go and it still has a lot of growth, but yeah, so for me, it was with RFID and I just liked the idea to have something physical. I liked the idea that there's an object and it's not just all an application that's on your phone. It seems more personal. And there's a little bit more reward to know that it's out there in the wild impacting this real object or something like that.

Corey: Yeah. To be able to stand in a yard and know that what you built is playing a role in all of this motion, that's just wild. And how did you get started Yuri?

Yuri: I've been developing, not for IoT, but web development for the past five years. And before joining GNAR, I've never worked with IoT or I've never worked in a project where such a high reliance and such a high throughput was needed. So I can say that I started here.

Corey: And for someone listening who might be looking to enter this space, or they just think this is really cool and want to learn more about IoT, where would you recommend they look first?

Brandon: The starting of the previous project and the startup that I was at. It was kind of just, it was looking around to friends of friends and it was somebody who was a race director and they had to buy this equipment that was really expensive at the time. And I'm sure the price has come down now, but we're just like, wow, why did they have to pay that much for that equipment? And what actually is the problem? Can it be cheaper? When we started to pry out if it was even possible to mess with that RFID equipment, that's where we discovered this opportunity. Granted, it's not a huge industry, like these smaller running events, obviously people have heard about the LA marathon, Boston marathon, but it's just this niche problem that was in this RFID space. And for this particular problem, like I said before, the Intermodl industry was something also that, that I didn't know about and I wasn't familiar with, but once you start to really dive into the problem, there's definitely something there that allows you to extract data from these vehicles and these individuals in order to make a better business decision.

Brandon: And that's like one of the main things that we're tackling with this problem, or with this project, I guess I could say. So I'm not quite sure how to say how you get started. It's that there's something around you more than likely that somebody you may be related to, or that you know, that is in an industry that is probably going towards the Internet of Things, or is checking out the idea of, what is all this stuff? What is the mechanics of our operations? And how do we make a better business decision? Diving in there and becoming obsessed over one of those little corners of these things to be on the internet or slowly coming on the internet is one way of doing it.

Brandon: It wasn't specifically that we wanted to be in Intermodl per se, but we've liked this problem. And working with RMS has actually been really cool because the freedom to build and test and break and move forward has been awesome with them. So because, you build something, you're not quite sure what's going to happen sometimes. So it's been really cool as we've discovered some new processes that have been impacting on operations is awesome. But yeah, I would say that, asking around and looking around and seeing what industries may be changing and what are those things that could monitored, to impact the business for that industry's operations.

Yuri: Yeah. I will just say that another way of looking how to get into IoT is to ask yourself about, what do you want to learn? What do you want to work with? What do you want to do? Because these questions will help you because IoT, it's so broad, you have so many options and you have so many solutions. You can start with a very small hardware. You can get started with an Arduino device or a Raspberry PI, or you can even go to an Android device. So asking yourself about what I want to do, it's a good way to start, if you have this in mind. If not, any general material will help you and get to an overview of what's going on in IoT.

Corey: Great. Wow. Well, this has been a great conversation. For listeners who may be interested in GNAR and want to read about some of the projects that you've worked on, where can they go?

Brandon: They want to go to gnar.io. G-N-A-R.io.

Corey: Well, Brandon, Yuri, thanks so much for being on Code[ish]. It's been a great conversation.

Brandon: Awesome. Yeah. Thank you.

Yuri: Thank you, Corey.