Cloud Commute
How to connect millions of devices every day
every architect who would decide your student system knows that the queuing system have one big advantage in your decoupled a lot of systems in order for scale, but usually queuing systems have one big issue. What are you going to do if your central point, your central communication broker is going down or is slow or whatever or you have a service degradation? You're listening to SimplyBlox Cloud Commute Podcast, your weekly 20-minute podcast about cloud technologies, Kubernetes, security, sustainability and more. Hello everyone, welcome back to this week's episode of SimplyBlox Cloud Commute Podcast. Today, as always, another incredible guest. You know me. I say that every time. I don't have stupid guests. Why would I invite them anyways, right? So another incredible guest, Dominic from HiFemQ, a nice German startup in a slightly different area than we normally have. So most of the time, we talk about security, cloud, stuff like that. So there is cloud aspect to that and I bet Dominic will introduce that. But HiFemQ is mostly like MQTT. So Dominic, maybe just introduce yourself and say a few words about you. Who are you? Where are you from? What do you do? And we'll take it from there. Yeah, thank you, Chris. And thank you for inviting me to this podcast. So my name is Dominic Oremaya. I am CTO and one of the founders of a company called Heifenkeel. We're a company, as I mentioned, original in Germany. But these days, we are around the globe mainly focusing on the US market and the European market. And we built the, we believe the most best MQTT platform. And this is mainly used by customers, many Fortune 500 customers that are building use cases from connected cars to logistics use cases, to big energy grids, to industrial IoT. And so we are truly a horizontal platform that's connecting devices, physical assets with our digital world. And we do that since quite some time. So we started the company in 2012. They're mainly focusing on the automotive space. So if you, if one of our listeners happens to drive in a German car, you are either using Heifenkeel while you drive, or you very likely would have Heifenkeel being used while the car was manufactured. The same is true for most US cars. And also, since a bit also is true for Asian cars. So we really did a lot of work here. And in the last few years, we focused also mainly on logistics. So if one of the listeners sometimes gets a parcel delivered, also chances are that Heifenkeel is being used while the parcel was delivered. And we do a ton of manufacturing, especially in the US these days. And the key words here are really the unified namespace. And I'm happy to talk about this later, what it means. But yeah, we, we do a lot of technology, deep technology, we do pretty high scale. And yeah, it's, and I, I happen to run all the product and the engineering at this company. All right. You basically already answered the next question, which was like, what is Heifenkeel? But that's, that's fine. That's fine. That's how it works. That's how it works. So, so you mentioned that you're pretty big, or that you basically started with like the automotive industry. And I think, I mean, I know a little bit more about MQTT than probably a lot of the audience. And I think the automotive industry makes a lot of sense for that reason, because you have like a lot of different, well, you could call them devices with a lot of different data points. But maybe, maybe you can give a little bit of an introduction, like, why is MQTT different from platforms like Kafka or nuts or stuff like that stuff that you probably know more commonly when you work on cloud infrastructures. Yeah, yeah, right, right. So let me quickly, it was MQTT for the listener who have, listeners who haven't heard of that, or are, are really trying to, to understand where it does fit in. So MQTT is a technology, it's a standardized technology. And, and we tend to think about it, that what HTTP is for the human web, MQTT is for the Internet of Things. So it's, on its core, it's a communication protocol. It's an open communication protocol. Obviously, all communication protocols should be open. In a sense that it's an ISO standard. It's not like a single implementation or single vendor implementation standard. For example, I mean, if you look at Kafka as an example, there seems to be a few companies who are driving that, but it's not an ISO standard. But it can be compatible, of course, but, but like the underlying protocol can change, basically. So this is an ISO standard similar to, to most communication standards. And, and it's been around for quite some time. So it's been around since 1999, so which is really, really old in, for, in computer age. And it's really interesting. It, it got a renaissance in, since 2010. So MQTT was a technology that's based on a published subscribe architecture pattern. So many of the listeners who are familiar with enterprise architectures might know about queues and, and these kind of things that will decouple actual communication. And MQTT is also one of these invented in 1999 for one specific program, monitoring and acting for oil pipelines. And if you think about it, oil pipeline goes through very remote areas where, especially in 1999, you definitely do not have mobile connectivity and forget that you have any kind of cable. This means satellite communication was the main way to connect stuff. And even today, satellite communication is extremely expensive. Back then, it was even more expensive. And so the task was for two gentlemen, one of them is called Aaron Nipper, who's now the company called Sirius Link. And, and the other one is Andy Sandvo Clark, who is, who is working with IBM. And they invented a communication protocol that saves bandwidth and also gives a almost like, for real time experience, even more very slow networks. And, and then it was pretty much buried, was not used a lot outside of IBM projects. In 2010, IBM decided to make it open, like just open a standard promise to don't sue anybody who's implementing a specification. And, and it was, it's not a real standard, right? So it's not an open standard. And then, yet to make a very long story short, we decided that this is exactly the kind of technology that we believe can power the internet of things because the web technology really don't work for many reasons, when it comes to a lot of devices. And, I mean, anybody who's who ran some Java enterprise applications with tens of thousands of users, most of the struggle, the struggle is real. And now I mentioned you have multiple millions of devices connected 24/7 without downtime on the single deployment. So really, really tough problem. And we believe MQT is the solution for this. So we built a company around this, this worked pretty well. And, and so, so yeah, and, and since then it got an ISO standard, I had also with that together with some other gentlemen at IBM and other companies. And, and yeah, and since 2000, I think 16 or 17, also the big cloud vendors, Microsoft as well as AWS picked, picked up with their own version, with their own support. Yeah. And back then a bit more preliminary this place, also a pretty specific, supported specification. And, and so yeah, this is where MQT really goes from a niche use case, technology to mainstream technology than being used every day. But all of you listen us for pretty much everything that's connected with a physical device to a data center. Chances are that you use MQT without even knowing similar to that you don't know that you use HTTP every day. It's interesting. I didn't know the history of MQT. I knew it was like super old, but the oil industry, that was, that was news to me. But it makes sense. As he, as he said, even today, MQT T compared to like the other things that I mentioned, like Kafka stuff, is, is like a super, super lightweight protocol, because it is design or that's why it is used in the, in the industry industry, in the IoT industry so much, because it is so lightweight, it is low overhead, works on slow connections, and, and, and all of that. And it's specifically designed for like scaling out in, in terms of the numbers of connected devices, and HiveMQ did some magic to make it even, even broader. I mean, I've used MQT in the past, and I've tried some other tools and they all have their issues. So, yeah. Yes, it's very interesting. Like, especially the scaling part was, I mean, MQT itself has a few problems. Like, if you look at the specification itself, like the most obvious one is, and everybody, every architect who would decide their system knows that the queuing system have one big advantage, you decouple a lot of systems in order for scale, but usually queuing systems have one big issue. What are you going to do if you're central point, you're central communication broker is going down, or is slow, or whatever, or you have a service degradation. And so, this is, I think, one of the reasons why MQT really never picked up in the enterprise, let's say, for enterprise customers. Because, I mean, they're very open source brokers out there. So, today, like many people, with something called Mosquito, you can, on any Linux machine, you can get it as open source is awesome. It's small. Roger Light, who was, was one of the first people actually implementing MQT outside of IBM, and he's still doing this to this day. So, this is great. He did such a great service to the community and to everybody by doing this, maintaining it. Super small, super lightweight. And there is also other software out there. But what really was one of the problems we discovered is, if you run around this in a mission critical system, like in a connected calculate form, or in a factory. So, for example, a public case study we have is Mercedes-Benz, since 2014, they run Hyperimcure on their factories. They cannot go down. So, you don't have a maintenance window. You cannot update the software easily. And there is one real big problem with MQT in itself. It has standing TCP collections. Similar to, I mean, most people know they're smartphone, they have a push notification service, either Apple or Android and so on. And how these things work is, they have an open TCP connection connected to a cloud at all times, which allows the cloud pretty much to push data immediately to a device with a very low latency. So, you don't need to pull the data. The problem here is, from a text standpoint, I'm saying TCP connection is not one. It's very hard to scale to big numbers. And the second thing is, what's happening if you update it, if you upgrade things. So, you can't, this can need to service disruptions. And so, what we built was, we pretty much invented clustering for MQT. And this was much harder, like in hindsight, much harder than we thought, much much harder. But once we got it right, this really helped us immediately get to big customers. This is it, all of the Sherman car makers reached out to us. And yeah, since then, we were pretty much in all the Carnegie car platforms for most companies on the globe. This is a really, really hard problem. And, I mean, just to give you a few things on scale, when I say scale, I mean, scale is usually something, many companies want to have scale, most people don't need scale, but with IoT, you actually need scale. One of the, one deployment, and this is a single customer, one installation on one cloud. They have, I just looked at the numbers before this conversation, they have more than 20 million devices connected to the platform. This means we talk about 20 million standing TCP connections. They have billions of Q messages at any point of time, and they have 30 million topics. So, a topic is similar to if you look at whatever Kafka also has a concept of topics, so they have 30 million individual topics. And this is also very, you asked about other technologies. MKT has one thing that's very, very different towards event stream platforms like Kafka, or traditional messaging systems, like chain S based systems, or I mean, there's active, there is a revenue queue, for example, which has been used a lot of enterprise architectures. These things are very queue centric, usually, and you don't have millions of queue users, it's very unusual. You usually have a few of them. Also with Kafka, it's, I mean, you can have a lot of topics, but likely, like, whatever, we have hundreds of thousands or so, but I've never seen a deployment that has, but there are tens of millions of Kafka topics. This is not what you want to do, usually. It's, usually, I will not be your friend anymore. No, it's, it's, like, side reliability engineers hated if you, if you put so many topics into a Kafka. It's not designed for that. Like Kafka is great. Kafka is an awesome, great, big pipe. And this is why it's so great for system integrations, especially in the IT side. You don't need 30 million of applications you connect with, if you have, what about if Microsoft's communication or dual Kafka? How much do we have, whatever? 10, 20, 100, 500. But sometimes even more, some companies are going crazy on microservices, but it's not like you would have tens of thousands of individual applications speaking to each other. I mean, you can, but this is more real, actually. With MQLT, tens of thousands of devices, easy, 20,000 devices, this is not even scale. We don't even start talking about it. You can do this on a, I mean, on a Raspberry Pi in an old generation one. It's like not scale at all. And so, think of MQLT as many small thin pipes to individual deployments. And what's really, what's really important is, think of an actual use that's connected car is great for that. If you have 20 million cars running around with actual people in there, and you could have mentioned functionality, like, I can open the car remotely with basically use it as a key. This is a very popular use case instead with cars. And just imagine, it works for everybody else, but for you, it doesn't work. The problem is, this is an actual user that will call your cohesiveness as your software sucks. Your car sucks. Your premium brand is not delivering on the premium promise. This means even if you say, oh, you know what, it's okay if I have whatever 0.1% message loss, or if I, if 1% of all users have high latency, no, it's not because these are actual users. And so, you know, it's a really tough problem to bring it to scale and also have predictable latency is also the very high scale. This is, this is, I mean, this would be a probably deep dive conversation, but it's a very challenging problem. We work many years on to actually get this right. And now it's the other thing, with MQDT, you are not in control of the client. If you use Kafka or ChamS or other things, usually you have an end-to-end control because it's not based on open standards. If you look at ChamS as an example, the channel messaging service for people who are not familiar with the term, it's pretty much an API. It doesn't dictate the underlying via protocol. So, if I build a ChamS application based on IBM software, Chances are that it will not work out of the box with orgi software, although I don't need to change my, my travel implementation if I use it. But the underlying via protocol, the language changes. And, and even with, and also with Kafka, I mean, Kafka, Kafka, Kafka has a Kafka client and a Kafka server. This means if you add their small functionality on the Kafka server available in new versions, the Kafka client can also be updated. So, it's an end-to-end system. With MQDT, everybody can implement it. There's no control or decline. So, the server implementation is a really tough problem being compatible with pretty much every implementation out there you don't even know about. And this is another thing why it's not easy to build an MQDT platform. You would be surprised to see what kind of MQT clients people are building out there. And there's a lot of non, a lot of behavior that is not allowed to happen, but you will see it happening a lot. So, I know, I know. Yeah, I hear you. It's funny. You mentioned Mosquito earlier. And I think Mosquito is like, be to go MQTT bank for home assistant and anything like in general like, home automation deployments. I'm actually running it myself. The other thing that you be, I think you didn't really mention, which I find very interesting about MQTT, it's very resilient towards disconnects as well. I mean, if we're talking about connected cars, there's a good chance, at least if you're in Germany, that you actually lose connection to mobile networks for a bit, and then you just reconnect. For Kafka, that would be a disaster. It really hates that. For MQTT, you reconnect and you are pushing. Yeah, you actually make a great point here. And the ultimate testers of people, especially here in Europe, or in Germany, in particular, go to a German train system and try to move there, you will challenge every application. And usually, MQTT connectivity works much much better than most others, because it's so slim and lightweight. As long as you have a TCP connection that is not aborted, you can still use it. And it's very, very efficient here. But you mentioned a great feature of MQTT. It was designed for programmers not being, they don't need to care about, am I connected or not? You can resume with their application if a connection or because it queues locally, it queues in a client on the server, and it actually resumes. So the only thing you do is similar to other messaging protocols, you pretty much tell the underlying transport, "Oh, I want to have a fire and forget, because I truly don't care about the data, or I want to deliver at least once, but I don't care if it's duplicate, or make sure the protocol makes sure that this piece of data arrives exactly once. And I think what I also didn't mention is everything is in order. So the program makes sure that the data is in order. It would be, for many use cases, a disaster. Again, let's assume I would lock and unlock my car. If this message would arrive out of order, actually like unlock lock, then I would lock it first and then unlock it and then move away from my car. This would be pretty bad. And this might sound like trivial use cases, and people sometimes say, "Yeah, you should do this otherwise," and so on. Yes, this is true, but the guarantee is the communication protocol gives you is extremely important. And I think the last one, what I want to mention, what many people don't really appreciate a lot, is if you go without the sound like NQUT, you can change your implementation on the server at any point of time. So as an example, if you are building, again, a car and you have for 10 to 15 years, you have a very hard time actually changing the software. So the interface, the almost API, it must be compatible. So if they, in our case, if we don't do our show properly, and one of our customers decides that they are discontinuing the work with us and replacing us with some other protocol compliance software, they can do that because there's no login. And this is very different to most messaging systems. So I mean, I remember when I started my career, I was working with other software, queuing software, they were selling you actual client implementations and so on. So that the business model really was different. So you always have a login effect. And NQUT is one of the fuel communication protocols that tries actually to be a centers compliant and not rely on the vendor. And I think this is great. The reason why the internet is great, the reason why we have all this innovation is because we built that communication network as humans, what we call the internet is based on open standards and the one. And this is also, I think, where NQUT gets so much popularity. And we now see, by the way, what we see 2010 to 2020 in the IoT age, I would say, we now see basically switching towards industrial IoT inside factories and all of this legacy technology, all of these legacy protocols, vendors will sell you gladly their client implementations for a lot of old-school proprietary protocols just to connect things. And people really get fed up by that. Why would you do that in 2024? So NQUT is now getting a lot into factories with a lot of work here. If you look at Fortune 500 companies from pharma to automotive, to package storeings and logistics, discrete manufacturing and process manufacturing, all of them are looking to NQUT based architectures. And the promised building is what they call unified namespace. It allows you finally to connect all of your applications and physical assets together in a way that you can exchange data without paying a lot of money and without actually waiting multiple months or even years to get some data flows changed. And this is something that's really exciting. And NQUT now goes full circle from oil pipelines, satellites, to cars and connect two brushes and whatnot to actual factories. And finally, again, again, back to oil pipelines. So things go full circle in these materials. We already crossed the 20-minute mark. That was like super super fast. There's two questions I want to ask you still. Sorry for the audience. It's going to be a longer episode. Again, I think I've never had the 20-minute mark. So first of all, you can install it on-prem. I think that was always an option. But there's also HiVimQ Cloud. And we're a cloud podcast. Also, Kubernetes podcast, does that run on Kubernetes? So, HiVimQ, we love Kubernetes. On-premises, a lot of our customers are running on Kubernetes. If you look at more than connect a car platforms, a lot of them are using Kubernetes. HiVimQ Cloud itself is we have a lot of Kubernetes expertise. I cannot share too much about this, but Kubernetes is a first-class citizen for everything we do. We have a Kubernetes operator that's, I would say, pretty sophisticated. And what we do is we dog food everything ourselves. So also our own cloud runs in the same technology that we sell to our customers. And what companies are building is this kind of edge-to-cloud central nervous system. You really want to connect the data flows. And you can do that with HiVimQ very easily. And by the way, for the listeners who say, "You know what? This NQL key thing looks great, but I don't want to install stuff at home." We have something called having a cloud serverless. It's completely free, no credit card required. It's really like, this is what we give back to the community that gave so much to us. And it really helped us also grow as a company. This is our gift to the community. It's free up to 100 devices. You can connect whatever you want. It will be free forever. And you will even get some integrations to other services that believe Kafka is aware of and others. So you can just hook it up, use it, have an endpoint in the cloud. It's secure and it doesn't cost you a dime. And it's probably the easiest way to get started with NQL. That's cool. I didn't know about that. It was not a Roman Outlook blast at HiVimQ. Good to know. All right. So final final question. Final question. That is a thing. We think it's basically always the last question. What do you think is the next big thing? In terms of cloud, for you, probably message-based communication, database, AI, I don't know. Yeah. So I try to keep it brief, especially the AI thing is interesting. But I won't go into it. I won't go into other things in my opinion on this. What's really big is the whole universe names of this topic for me. I am really excited that companies are thinking of making data available to the users that actually can benefit from a data, outside of data lakes and so on. For the last, I mean forever, since I'm working in the industry, everybody wants to move the data to the cloud. And you have data lakes and all of that and it's great and it's awesome. But actually making the data available to the people on the shop floors, working every day. And not only to the data, it was something that's really, really interesting for me. And so it's about really spilling it's kind of central nervous system. I really care about this. I do see this as a big trend even outside of manufacturing. We see it in the energy and on. We don't see it in, let's say, the traditional cloud technology business so much. I think when the trends are, I think there's other people who can talk about it. I really care about the customer use cases and how the industries are transforming. I can just tell you, I'm so excited if I look at how, for example, in the energy grids, how sustainable energy grids are being built these days to get us away from, let's say, these unsustainable way of doing stuff on our earth. This excites me when I see customers we have are deploying billions of infrastructure just to get away from coal and other things. So energy and it's humbling very frankly to see that having us being used pretty much managing those energy grids and all of that. So yeah, it's not an IT trend, but I'm very, very thankful that we see with our customers trends that we make our world more difficult place. I think that is a perfect sentence to end the show. That is brilliant. We all want to do something better for the environment, I think. We know our industry creates a lot of CO2 footprint and there's ways to optimize better. I think that is a big trend that needs to go onwards. All right, cool. As I said, we're way over time already. That doesn't matter though. As long as people are listening, it's all fine. Thank you, Dominic. Thank you for being here. That was a delightful chat. And for the audience, you know where you find us. Same place, same time, next week. I hope you listen again. Thank you very much. Thank you, Dominic. Thank you, Chris. The Cloud Commute podcast is sponsored by Simply Block. Your own elastic block storage engine for the cloud. Get higher IOPS and low predictable latency while bringing down your total cost of ownership. www.simplyblock.io.