Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE, the consultancy that helps companies create value from data to accelerate growth. And our guest today is Jonathan Beri, CEO of Golioth. Golioth is an IoT development platform built to speed up development and increase the chance that your pilots will be put into production. In this talk, we discussed the role of a middleware platform in the IoT product development process, including hardware integration, connectivity, management, and troubleshooting. We also explored the technical and organizational challenges and the journey from idea to MVP to production for an IoT product.

If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research strategy or training initiative that you'd like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you. Jonathan, thank you for joining us today.

Jonathan: Thank you for having me, Erik.

Erik: So this is a conversation I'm really looking forward to, I think it'll be quite educational for me. But before we get into the nuts and bolts of what Golioth is building, I'd love to learn a little bit about your background. Because I think you've worked with quite a few of the more interesting companies out there, everything from WeWork to Particle to on the board of Thread Group to Google and Nest. I mean, could you just take a few minutes and walk us through your learning process that led you then to define the business model around Golioth?

Jonathan: So for me, I've always worked on technical products. I'm definitely a super nerd and have worked on operating systems and protocols. But my journey into IoT really started when I was at Google. I joined the Nest team shortly after the acquisition and knew nothing about IoT. I know a little bit about hardware because I took science undergraduate, but nothing to the degree of millions of devices, consumer electronics.

I call that time in my career, my PhD in IoT, and in part, because I found out after the first few weeks that half the engineers on my team had PhDs. And I go in bright-eyed, bushy tailed, barely understanding the core concepts of distributed systems and internet protocols. And my tech lead has a lifetime achievement award. And so I got to see firsthand what it takes to actually build devices at scale, millions of units, consumer grade electronics, manufacturing, security and I was hooked on IoT. Everything about IoT finally clicked for me in terms of where I want to spend my career. And ever since then, I've been going down that that path.

And as part of that role, I worked on our embedded software as a product manager and our wireless protocols originally proprietary, which then became an open standard. And that standard is called Thread, which is in every Nest product in my team also developed an open source project called Open Thread. The experience of being part of the team that uses the protocol and then actually helping evangelize the technology, I was super rewarding, but also got me a pretty deep insight into how things like a protocol gets designed, implemented, deployed. And it's kind of fun because obviously worked on the Nest product and proud of the stuff the team did while I was there, and I got to participate in.

But Thread more recently has seen quite a resurgence in interest, even more recently, with the latest Apple devices now support the thread mesh networking technology and the belle of the ball for CES when it comes to smart home is this new standard called Matter which if you've had any consumer electronics recently, that's the thing everyone's looking at and it uses thread as a foundation.

So I got to see what it takes to build consumer grade millions of devices, high scalability at a company like Google, then I got the bug to leave the big company. And getting close to the manufacturing process, design choices, because primarily, I’ve a software background, so I joined a startup called Particle. And Particle is a IoT dealing platform full stack, everything from the hardware to the connectivity to the device management. And I got to work on all things related to hardware as well as software and tooling.

And before starting Golioth, I had opportunity to work at WeWork, which was an amazing experience being on the platform team working on a lot of IoT things. But primarily, the biggest thing I focused on was physical security. So we built from scratch probably the world's most scalable physical security platform. So you can go book a room or halfway across the world, walk to the front desk, show a QR code, and it turnstile opens, tap your phone with NFC and an elevator will come down and pick you up. And right before you're about to get to your conference room, it use Bluetooth and unlock the door. And we've got that all from scratch, custom hardware, edge computing, scalable infrastructure, and in those decade of experiences led me to work on Golioth.

Erik: Yeah. And so you have a really a nice range of experiences, everything from building hardware products to support protocol, then to a platform and then back to basically building an iOS system for one of the largest networks abilities on the world, great diversity of experience here. What led you to prioritize the problems that you're solving it Golioth as a thing that you want to now dedicate the next X number of years of your life to because I'm sure you came out of that experience with 20 different ideas and somehow this one bubbled to the top?

Jonathan: Well, actually, it wasn't the original idea that I want to work on after leaving WeWork. I actually had a hardware startup idea. I was in the space of asset tracking and multimodal mobility. And I actually had a prototype, so your asset tracker with a GPS, worked with the CM to get a proof of concept. I had some cloud software that this asset tracker could speak with.

And one of the realizations was while I was doing a hardware startup, I was effectively building another cloud platform, partly because of the challenges of the hardware we had, it needs to support multiple technologies on the back end, so WiFi and cellular and I need to be very data efficient. And so as I was getting through this process, I realized I'm about to build yet another IoT cloud. And there is this aha moment at some point during the design phase was, well, why am I doing this yet again? I participated in that at Nest, I had hands on experience at Particle, we built this all from scratch WeWork. And this seems like a movie I've seen before.

And well, shouldn’t this be solved? And the catalyst for Golioth was why are we keep on solving the same problem over and over again of device management, of device security, of software updates, where honestly, they're kind of similar? And if we did that once, then well, I wouldn't have to go start to build a cloud platform for my hardware idea and hopefully, other entrepreneurs and companies wouldn't either. So, the pivot was really fundamentally solving this common pain of connecting devices and manage those devices so that hopefully, if we're successful, people don't have to solve that ever again.

Erik: So Jonathan, the backstory makes a lot of sense why you arrive at your development of support technology for building IoT solutions, given your experience in your struggles in building the architecture from the ground up before. Helps us understand what does the Golioth do and what does it not do? Because this concept of a platform, I think, it's a term that's very widely used, and it can mean a lot of different things. So just give us the 101 on the value proposition, we can get into the technical architecture later.

Jonathan: As part of that journey figuring out this hardware startup idea and then pivoting towards building a cloud solution that's more generally applicable, there was this kernel of a sort of thesis that drives what we do. And the idea is that everything in our life, everything physical is going to become an IoT device. And the people who are going to build that, they're going to be hardware companies. And [inaudible 09:07] enable all those companies to build the connected products of the future, they need cloud software. They need cloud infrastructure.

And what our research and our experiences that point us to is that hardware companies and software companies are actually quite different. And they're very few companies that exist in the world that are both hardware companies and cloud companies. I think my experience at Nest was pretty rare. I got that opportunity to see just what it takes to have a 600 person engineering team with all those competencies.

And so, the idea behind Golioth is what if we build a company that was really focusing on the hardware teams, the hardware companies or responsibilities, devices, and build the cloud for them? So understand the needs and requirements of hardware companies, and provide the solutions that they require in order to actually go build those transit devices. And the reason why that's somewhat different than companies before us and companies that we compete with is that for the most part IoT cloud platforms, things that help connect devices were all coming from the world of software. And so when they view a machine, they really just see a server or cell phone.

But in fact, a scooter, a sump pump, a pet tracker, right, those are fundamentally different and have different requirements. And so it does require you to basically design a different type of system. Now you can use the hyper scalars and modern cloud software, you just can't use the solutions that have been built for the servers and the cell phones. And that's effectively what we're doing and providing these capabilities with insights from our users, our community of hardware developers so that they can be more successful and really empower them to build their products.

Erik: So, first of all, you can divide companies into IoT developers into a few different categories. The way I think about it is you have your digital native companies, which are often startups, and they're basically an integrated hardware software device, then you have your legacy companies that have a big hardware asset base in the world and they're now trying to add some IoT capabilities to that asset base, but fundamentally, they're mechanical, electrical engineering companies. And then the third are the conglomerates who have managed to hire thousands, or maybe tens of thousands of software engineers, and now so here we're looking at the ABDs and Bosch’s of the world who can credibly have a strong foot in both. What are those categories do you think would be a best fit as a user of Golioth? And what's the logic behind that?

Jonathan: Yeah, we tend to see the first two categories, as you call them digitally native as well as hardware makers who understand their discipline or are leaders in their discipline but have not gone through their digital transformation or have to reevaluate their current solutions and expand to different areas. I also slice those a little bit further into four kinds of categories that we see among those.

And the first category is what I call product creators. And so these are companies who build solutions for commercial intent. That might be to B2C. That might be B2B. But for example, Nest as a product creator, by that definition. They might make many things, they might be in the hundreds of thousands, they might be in the tens of millions. But the nature of their product is around selling to third party. There's a second category, which is a surprisingly big category and that's what I call internal solutions.

So for example, my group within WeWork, we were responsible for phone booths, a lot of these office buildings have phone booths, we can take private conversations. While they're dumb phone booths that usually you buy, and we instrumented them with motion sensors for occupancy and air quality and created a dashboard where you can see availability so you know where to go to find a free phone booth.

Well, there's probably, 1,000 phone booths, and the pilots. And when one breaks, they'll make the 1000s in one. And it's not for commercial intent. It's an internal solution and specifically for WeWork and it's customers, members. Now, they actually look and feel like commercial products tends to have similar requirements, the scale is quite different, the budgets might be different. But fundamentally, a lot of companies don't think about those as a huge category.

But the last two categories are kind of interesting. And that may be more of a nature of just the type of user we attract. One is the harder ecosystem. That's just a term I made up. But we're talking a lot with our channel partners on the chip solution side, so the raw components. They are either looking for solutions to enable their customers go to market faster. Some of them are looking for new sources of revenue. Instead of selling a $1 chip to customer, they're looking for ways to have recurring revenue around subscription services. So it's a 30 cent chip, but for 3-5 years of subscription is a lot better in economics.

And then there's the connectivity providers. These are the telcos, the NVNOs satellites, etc, they are looking to enable themselves to be more than just a dumb pipe. And sometimes it's even for their own use. So monitoring the facilities that they operate in or for contracts that they already have white labeled and things like that. So, those last two in particular are not in the same vein as the others; like they're not a John Deere going from the legacy tractor to the GPS-enabled tractor. There’s something else and so we've discovered them along the way as we built our product.

Erik: And then the type of problem that's being solved, so I have a case right now, which is, I would say on the low level of complexity but nonetheless a big pain in the ass for the project team. So the situation is basically building a IoT device that would be deployed in taxes. Initially, the system had a 2G connectivity just because this is very much a legacy device company, so that's kind of what they had ready. And we found out that then creates all sorts of connectivity issues, so we want to upgrade to a 4G. And the engineering team then says, okay, that's going to be four months for us to do because they have other priorities; they're supporting the core business, and then they're supporting this innovation team.

And so this, on the one hand, is a very simple device and it's a very simple problem; on the other hand, it's a four month delay in getting the next prototype out for testing. Is this too simple of a situation for Golioth? Does it make more sense to use this type of platform for building more complex IoT devices and systems of devices or would this also be kind of an applicable problem to solve?

Jonathan: Yeah, actually it’s very applicable. And it's a good framing for how someone might decide to use Golioth and what problems would solve for them? Actually, in my career, most IoT problems are actually quite simple is the thing on or not, it could be worth hundreds of millions of dollars. But the problem is to get the information you need for the backend data science team to know if this thing is on or not, or how long it's been on is this mountain of complexity. It's the black box between the machine you're trying to know if it's on or off and you’ve the database in the backend.

And really, if we were to draw a diagram, that's the parts we solve. You could categorize Golioth is IoT, middleware, device management, something in between enablement. But a lot of the cases we're seeing, a lot of customer use cases is this on? Is this moving? How quickly as it's moving? And it's a very simple sensor. The hardware is very basic. But the challenges from going from collecting that information to getting it to your back end is lots of layers. So first, you have to design the hardware you want.

And the number one reason people have come to us is because of a flexibility in hardware. This goes back to what are the requirements for hardware teams? Well, choice in hardware is the fundamental first thing that any platform needs to do enable or is becoming a limiting factor. We have pretty broad flexibility on the hardware side. And then once you design your hardware, you got to write some software to collect that information. Well, software updates is a fundamental piece to what we offer and managing the software updates, the security of the new updates of software from the cloud down to the device and doing it at scale, all that is before you even collected any sensor information, is this on or not?

Once you have your fleet of devices, and they're all running the firmware, you need some way to get the information off that device over the cellular network to wherever it needs to go. And that's sort of the plumbing part that we also offer and are very important, because there's security, there's protocols, there's data management, there's compression, and all these other things. But from a hardware perspective, you're just like, I need to send this motion data somewhere. And from the cloud team's perspective, it’s like, I just need to know if this thing is moved or not. We're the middleware between the device and the databases.

And so whether it's a very complicated multi-sensor, fusion algorithm or just on or not. The challenges of the design of that hardware, connecting it to the cellular network, sending the data in a secure and compressed way, and making sure that it reliably gets to the destination, understanding which pieces of information all at the end of the day get into database, that's what we do. And that's a great use case for what Golioth enables.

Erik: Let's use the same example then to also dig into the stakeholder perspective here. So, I think this is a fairly typical arrangement for a corporate not necessarily for a startup project, but for a corporate product innovation situation. So here you have the product management team, which I would say is semi-technical, they have some technical competence, but primarily their job is validating the market need, defining features defining the path, the market, etc. Then you have a technical competence center that sits in the core business and has other priorities, which are managing the core business, but are also supporting this. Of course, you have general management. And then you have also third party teams that are supporting with building out particular parts of the technology, for example, the end user application, among these different stakeholders who would be the primary and secondary users of Golioth?

Jonathan: Because of our entry point into an organization, it's really on the hardware, usually, it's the hardware person or hardware team depending on what kind of company we're talking about that finds Golioth or we find them and they become enthusiast or really a champion within an organization and pull us in. That's part of our bottoms up strategy. We do a lot of content and training and we provide open source software to enable those folks to be really successful. Because at the end of the day, if every hardware IoT problem starts down to the hardware, then they're the first line of defense, but also where the buck stops.

We build software and documentation. And honestly, our tagline used to be “empower the hardware developer”, because they can actually get to that pilot, that proof of concept, demonstrating ROI way faster because they have a solution that makes them work more effectively. But ultimately, the solution is part of a larger system. And we are far more successful when we have that conversation with the cloud owner.

And different organizations looks different. Sometimes they might have the title of cloud architect, IoT cloud solutions. They might just be GM. But they're that interface from that black box on the other side of the black box of hey, we have this motion data from the taxi cabs. But I have a data science team. I have a data infrastructure. I have databases, app developers. I'm responsible for that group. And all they care about is that information in its clean upstream form.

And so when you go to two organizations who have been starting with Golioth or piloting with Golioth, we tend to have a conversation together because we enable the hardware team to move fast and reduce the complexity of their design, and be able to basically prove out the product idea. And then we can turn to the cloud team saying you don't have to worry about any of that hardware stuff. You don't have to worry about IoT protocols and cellular connectivity. Here is the clean data you need, then the ways that your team needs to consume it, the formats and the integrations. And they just say, great, now I don't have to worry about this. I can reduce to three, four engineers who I originally going to plan on managing the device connectivity and now I’ll just focus on building out those apps in those databases.

So it's almost like by creating a middleware solution for IoT teams, it's a form of collaboration because the hardware team can just give the cloud team the information they need, and the ways they can consume it and the cloud team can no longer have to focus on the device complexities and they can build the final solution together. So effectively, the hardware leader or the hardware owner, and the cloud infrastructure architect, sometimes see so is the other stakeholder and depending on the organization, one might be the primary versus secondary.

Erik: So the situation here is in this example, is that the company is an automotive company and building third tier components supply for automotive. Automotive is a very risk averse, high control industry. And so everything they've done is from the ground up incremental changes, generation after generation over, whatever 30-40 years, because their customers need to make sure that everything that they put in the vehicle has meeting their safety requirements. And now, they're building solutions that are outside of automotive.

So, you can be quicker, you can just kind of get the product out to market, as long as it works, it's fine. But their background is very much in we build the entire stack from the bottom up. And it's therefore, I would say, probably a fairly quirky stack. So, just it's one of those things that's just been built over decades, which I think is, again, true for a lot of companies that are looking at building solutions. So what would be the requirements for a team that's coming from this kind of legacy perspective to upskill themselves to be ready to use Golioth?

Jonathan: And we see this quite a bit in a lot of industries that are evolving. A lot of medical devices were primarily built by medical companies. But now we're seeing a lot of consumer grade medical devices that don't have the same types of requirements, or honestly, thresholds, and also just brownfield, lot of industrial systems, which cannot be changed or they have this legacy PLC infrastructure. They're adding on devices that can be modern and lower cost and flexible. And if they fail, doesn't take down the factory. And so we're seeing that in mobility as well.

So the questions to ask them is, okay, well, it all starts with your hardware. What are your hardware requirements? What are the constraints of your system? With Golioth, we've taken an approach of trying to have as much flexibility on that side, not getting into the technical details. But we provide software that goes on that device, it is open source, and this is part of our go-to market strategy. Because for industries like automotive where there is safety critical applications or near safety critical applications, they can take that source code, they can look at it, they can fork it, they can modify it, they can take it to third party auditing.

But then they can integrate that into their design and through that software that we provide as well as the ecosystem we built around it, they can either choose hardware they've already support from a wide array of hardware or match the harder they have, learn how to use our SDK through our documentation, our training material, our YouTube videos, and blog posts, and third party content, and webinars, and through that process, build that proof of concept.

Sometimes we see people do a prototype in 48 hours, which is pretty cool. And then they can start using the Golioth cloud. Because the software we provide is a form of software development and SDK enables the different services that Golioth provides as middleware. So things like telemetry, like reading the sensory information that they may be reading for the device; device health and metrics, like device logs, and is this device performing an operating correctly.

The ability to know is this device running the software? They think it is. If not, can you push new version of software? So software updates and fleet management. And it's all from this sort of very easy to integrate SDK on the device side. And then there's the console, which then that engineer can go in and see what's happening and monitor the device and verify what they think is being collected is collected. And a lot of our pilots look like that. It's probably one to three hardware folks or maybe they're working with a product department shop and they're doing the device bring up and they have a look like, hey, we're using this new piece of hardware, the new 4g modem, I'm seeing the motion data being sent to Golioth.

And let's move to the next phase of the project, which is what do we need to do with this data? Oftentimes, that's really prescribed. There's a large AWS infrastructure that has a data pipeline and databases and message queues and all the stuff that the cloud team that needs. And usually it's just here, take this endpoint and consume the data and you're done. And then everything else is in the wheelhouse of the software team. Or sometimes it's a custom solution and we need to work with them and figure out how do they consume that data. But ultimately, once they've connected the device and managed it with Golioth and is just improving the software over time it's on the device or figure out different ways they might want to extract that data or wrap that data to wherever it needs to go.

Erik: What does the business or the pricing model look like? Because I guess you have very different dynamics or you have, maybe companies like Nest, which are building one product that is maybe multiple products, but a small set of products that are very scalable, you have companies like Xiaomi that are building hundreds of products, each company medium size in scale, companies that are just trying to get a lot of MVPs out to test them, so innovation type of programs. Again, using Golioth, if you just want to make an MVP, what would it look like as they start to scale that up and bring product market?

Jonathan: So the vision for Golioth and how we support companies is actually we want to be the middleware for everyone. That means the two person startup that barely has two pennies to rub together to get their idea off the ground to Fortune 500 companies to humongous organizations and telcos and everyone in between.

And so we have two models. And we launched the first line, the Golioth cloud, that is fully hosted and managed by us. It's globally available and scalable. And that looks like a system you could put your credit card in and scale from one device to 50 devices to 10,000 devices and up and up and up. Our bigger vision is actually getting that scale. And this is the problem I saw at Nest and at other companies afterwards is, when you get to a certain point, a SaaS product actually doesn't make sense. It's not cost effective for you as the buyer. But also from a unit economics just for everyone, 10 million devices, you're paying five cents per device, one cent per device, doesn't really work.

Because if you look at the world of enterprise software and infrastructure, they move to different pricing models altogether. Everybody wants to remove the cloud device management from their bomb, and rather integrate it within your optics. And that's usually how people start to evaluate Golioth is I need 2-4 engineers to manage their devices. Even I'm using a turnkey service. We have our cloud offering and that's our primary way in our current customers are using it and scaling with us on the cloud.

But the idea is as you get to a certain point when the unit economics of per device per month or buckets of devices per month, don't make sense anymore, that's when we have our enterprise offering, which is coming out hopefully later this year that scale with you. And that moves from utility based pricing to platform based pricing. So you can be a lot more predictable and your costs. You can maybe advertise your cloud infrastructure bill, if let's say you want to have it on premise, or if you're in very regulated industries or countries that have data privacy, you can literally right behind your own firewall and have full control.

And so this spectrum starting with the easy to get started low cost cloud and scaling up with us and then when you get to a certain point or certain level requirements can move on to enterprise. So this dual model that hopefully gives the flexibility companies need to grow with us and we can scale to meet their needs.

Erik: Well, let's get into the tech stack a little bit and maybe it just makes sense to walk through the capabilities of Golioth. So supporting 100+ Plus hardware components SDK based on Zephyr integration with COAP, MQTT, etc. But can you basically break down what is the tech stack look like and then how does that relate to the functionality or features that you're providing?

Jonathan: So before we really wrote any of the software, we interviewed hundreds of developers, developers of large companies, consultants, people in our network, who build hardware and/or connected hardware. And there was a series of things that kept on coming up in all these conversations. And the first thing that came up was choice in hardware. Because just like you can make any recipe, gourmet food has very particular set of ingredients. And that's the heart of every hardware product is painstakingly deciding which hardware you can use, which form of connectivity, whether it's 4G or 3G, or BLE, or BLE 5.0, 5.2. And so flexibility in the hardware was critical.

And so that allows us to go to a company or company comes up saying, hey, I've already built this thing, now going to get it online and allow us to adapt to them. So through our SDK, we can match to their current hardware requirements because of the design of our SDK as well as we're constantly adding new devices over time.

And one of the ways we do that is based on you mentioned, Zephyr, Zephyr is open source operating system for IoT devices. It’s part of the Linux Foundation. So it's behind some of the great names of Linux itself and other large organizations that develop software together. And it's a community driven project. And so it's sponsored by Linux. It's contributed by literally thousands of companies at this point, and it is fully featured. But more importantly, it goes back to something I said earlier, is open source.

So other companies like Golioth can contribute to Zephyr and making it better. That means us building our SDK on top of Golioth, means we can take advantage of contributions from other companies. And if you actually pull up the Zephyr project website, you'll see some pretty big names who are contributing to that, especially the silicon folks. So everyone from Nordic to TI to Silicon Labs, Infineon, Qualcomm, they're all contributing to not just the core technology, but actually supporting for their devices. So this is one of the ways we can continue to add support, either through our partnerships with those chipset vendors and the overall contribution of Zephyr.

So hardware team says, hey, we built this thing. It's using this ST part here and this Infineon WiFi there. Can we work with Golioth? And usually, the answer is yes, because of Zephyr, take our SDK, integrated into your hardware, and now validate that it works. So, running SDK on your particular device.

Well, with that SDK, the device side can turn on different services. And the second thing we heard from our interviews was, I need software updates, like, I have no idea how I'm going to do software updates. I don't know if it's easy or hard, is it going to be secure, insecure? I just need to know that, while I'm developing this product, I don't know what the functionality will be and there's a guarantee that I'm going to update functionality over time and I got a WiFi modem on this thing and I need to just do it.

And so we focused a lot of our original development on doing that fundamental service. What is software updates? Which happens to be a lot of things: it has to do with security, it has to do with protocols, it has to do with integration with hardware, it has to do with integration with cloud software. But effectively, by uncommenting, a line of code on the device, they now get software updates managed by Golioth with different levels of functionality underneath all that security, I mentioned all the different protocols. But from the hardware team’s perspective, it is literally just integrating our SDK on the device.

And I would say that's the most common reason people are looking for a solution like Golioth and how we get into the conversation. I have this device, it is running some software and you get new stuff or update on it.

But the last thing that came up from those conversations, besides some details about how I want security, or how would I want to use a protocol, whereas common set of services that you wouldn't think about to build until you need them? So for example, Device Health, to know is this device online? Is the battery charged? You could go build that solution bespoke. But if you think about that user, that hardware team, that one person startup or a five person digital transformation team, they may not have engineers to go stand up a service that can collect all that device health information.

And so we have a series of different device services that are solving the most common pain for any IoT device, regardless of industry or sector or if it's a cellular device or WiFi device. So things like getting Device Health, collecting sensor information, and others that we're continuing to add over time.

So what you're seeing is the core set of functionality, integration through 100 devices, software updates, a series of device services that are common and useful across different sectors. And also, more importantly, that the hardware team themselves didn’t have to build and then a series of different integration points. We provide tools like API's, so you can integrate Golioth into your own back end and ways to get the data out of our system into your database and a bunch of other things that we can dig into.

Erik: You're not yet doing anything in terms of machine learning or so forth, or that would all be done through a open source or third party application and then integrated through Golioth, but not done on the client platform, is that correct?

Jonathan: Somewhere in between. Our roadmap of all these different devices all based off of customer feedback. And we asked ourselves, what is a service in the cloud that would be complicated that you couldn't use a generic, let's say, service that was designed for servers or cell phones that we could do, that we are uniquely positioned to do?

And so let’s take machine learning is an example, especially machine learning at the edge, sometimes called TinyML. Understanding machine learning is actually not one of our core competencies. And there's companies doing machine learning infrastructure and designing and developing your machine learning models. But they all have a similar problem. There's actually two problems. One is getting the raw training information off the device in the field, because that taxicab is going to be very different than an oil pump. So you want to actually use your real devices as the source of training information.

How do you get that training information off a device over the cloud network to your machine learning back end, the partner or anyone else do that training? That's problem one. So it's a connectivity problem. It's a data pipeline problem. It's a middleware problem, which is what Golioth is really well suited to do. And once you have that trained model, how do you get that model onto the device? You now have to send a blob of code over a cellular network onto a device somewhere in the field that needs to be secure, you need to verify who did that.

So we can take what we know about middleware for IoT devices and extend it to machine learning. So we can enable companies who want to take advantage of the latest greatest machine learning companies, whether it's a hosted service or using technology built in house and be the pipe to get the training data off the device and the models onto the device. And that's, again, that middleware part that is really hard to figure out but we can do it because we can leverage the same infrastructure we built for software updates, for example.

Erik: And then once you get the data into whatever ML platform is being used, then it doesn't really matter where the data comes from, so that segment of the stack is fairly horizontal. Jonathan, let's use maybe one or two examples to show what this would look like end-to-end, are there a couple of cases that you'd be able to walk through from an end-to-end perspective of how they're using Golioth?

Jonathan: Yeah. And we're still super early and we can't expose any of our early customers. But I can talk about their use cases, pretty openly. One of the areas we invest a lot early on was cellular, and so we see a lot of low power Wide Area Networks cellular solution. So in the US is primarily Canon One, in Europe and other parts of the world, MBIOT, because we chose to implement really efficient protocols. And so we're seeing a lot of conversations around mobility, whether that's asset tracking, micro-mobility, remote monitoring, where there is no other form of connectivity.

So, one example would be a micro mobility company. They're pretty innovative. They're not like your typical scooter that crazed the world a couple of years ago. But they have a mobile device that is for individually writer. And they have a custom system. They have motor controllers. They have speedometers. They have lighting subsystems. And they need to know where the mobile devices at any given time. They need to be able to remotely unlock the device. They also need to be able to locate the device for repair and diagnostics. So because nothing in their machine is off the shelf, they had to build their own IoT device. So, cellular modem, GPS location, and then integration into this automotive like device.

And so they need to be very flexible and dynamic because this thing doesn't exist. And there's no other company in the market that they can just buy from. And so they designed the solution that integrates Golioth into their cellular part of their system. They just plop it in into their micro mobility device. And we are the search solution for collecting the location information from the GPS as well as the automotive subsystems and we stream it back via Golioth to their cloud engineering team.

So they're that example of the hardware team designed the cellular GPS tracking subsystem, wrote the code that collects the information, sends it to Golioth, and then hands off the integration to the cloud team. And then they're done. The hardware team doesn't have to think about what happens to that data. And the core team just gets a raw stream of sensor data and is doing their integration based off of that.

As their enabling news functionality, as we know with software updates, they're just pushing new features that improve the capabilities, but also literally unlock features for the bike remotely as a new development. So the two teams are very happily co-developing, expanding their functionality with Golioth. That's an example.

Another one is for remote monitoring. We see a lot of public spaces that need some sort of remote monitoring. There's no WiFi. It might be a public park. It might be office park, so some sort of commercial center. And things like Waste Management's for trash bins or people counting for estimating traffic. And there's just nothing there. There's no WiFi. There's no other connectivity. So all they do is have a simple sensor, kind of like the taxi sensor with a little tracker that somebody walked by.

And that is the fundamental hardware problem, build a cellular device with a motion sensor or for waste management, a trash sensor, collect that information, maybe go to sleep because it needs to be offline for a little bit, collect the data sent to the cloud. And same story, they arrives through Golioth and they get sent to the mobile app team and they build a system that notifies you hey, the trash can is full, goes into park ranger or probably should send a sweeper to the main path because there's been too many people. Those are pretty similar in terms of use cases.

And we have pretty wild things that I would not expect, certainly consumer type of devices. One company that's really interesting that I wish I could talk more about is in the prospect space. And so they're trying to reduce the cost for prosthetics. Well, this thing is tens of thousands of dollars normally, and through cost reduction and clever innovation, they want to make it more accessible for people to have custom prosthetics.

The problem is it's a very complicated piece of machine. And so they have a technician who comes and sits with the patient, fix it to make sure it's right, trains them on how to use it, trains them on the mobile app software. Well, they need to be monitoring that thing for the first few months. And the first few months, they may have reliability on the network. So they actually started with a cellular product and they're going to soon have a WiFi product. And they're literally money to this device until the user is comfortable with it and then they turn off monitoring and enable the customer to get the data of themselves. And so that's a IoT problem. It's no fundamentally different than tracking people in an office park. But we are enabling them to build something like that.

Erik: Jonathan, I think we've covered a fair bit. What have we not touched on yet, that would be important for people to know?

Jonathan: We talked a little bit about our business model and our go-to market motion. But it's worth just kind of focusing a little bit on that. Because we fundamentally believe that if these hundreds of thousands of companies you're building the trends of devices are going to be successful, they need a solution to actually come to market. And so with Golioth, actually, last year, we launched our platform in general availability.

But most importantly, we launched it with a free tier, because we believe that it's really important for any developer who has an idea or is on the hook to solve this problem can get started quickly and easily. And so that free tier plus our investment in open source software, and the thing that we're most proud of right now is our community that we've been building is enabling hardware developers to get the skills they need to find the solutions that actually can make them do their job well, but also collaborate.

And we've been slowly building out this developer community around Golioth, but more broadly about the IoT ecosystem. And we produce a lot of content in the form of video, tutorials, and blogs. We participate in all these events, because we actually believe that it starts with the engineer. So that's why our website is more focused these days on the technical jargon and speaking to them.

And it's actually been pretty rewarding to see folks who like I worked with this vendor, it's been a year, I still haven't got my product off the ground and they can turn around say, I just did this in one month with Golioth. And those are the things that we think will be powerful for just the community in general to unlock the capabilities and potential of IoT and stop focusing on the hard parts of connecting hardware and really shift us more talking about digital transformation, enabling more use cases and actually creating value through applications and data. But yeah, our developer community is one that we are investing a lot in and continue to give back to those as well.

Erik: So a lot of the best use cases we've seen out there have been really just relatively old technologies that just the form factor, the bond cost and the integration effort became feasible, and all of a sudden you have something new in the world. Just a couple last questions. One, are there any barriers to Golioth working in China? I've just because obviously, this is a challenging market for a lot of software companies, but if you're based in the cloud, I'm thinking maybe not. But have you looked into this?

Jonathan: Yeah, I have a little bit of experience, working with the team at Nest that was also based in China. It was amazing the first time I gave a technical talk in China. Because even though I didn't speak the language, all the questions were spot on as if they were engineers down the street from me in the Bay Area. I think it’s a huge untapped opportunity for developer companies like us in China. I've certainly participated in different developer events over the years.

And part of the vision for being the middleware for everyone and everything is this sort of enterprise skew to it. And so we've built Golioth from the ground up so that we can run it across any cloud. We're actually in the cloud from the hyper scalars to data centers, to even it closets, and very specifically to make sure that we can take that code that's not tied to an Amazon or Google or Microsoft's infrastructure and run on any of the Chinese providers so that it can be operated within in-country.

But even oil refineries that have no cloud connectivity, if you have a bunch of sensors, well, how you going to manage those devices? How you going to get that sensor data? So, on-prem, looks fundamentally similar to us private instance in a country like China.

Erik: I know you're a relatively young company, do you have a funding round planned that you would be able to share with folks just in case anybody's listening that might be interested in participating?

Jonathan: Yeah, so we are relatively young; we raised our first round in late 2020. And we're still on track with our revenue projections, and our burn. But we're probably going to be planning fundraising in the next couple quarters. So would be interested in talking to anyone  who wants to talk about that.

Erik: And then last question, how to folks get in touch with you?

Jonathan: Golioth.io is our main website. You can find me on Twitter as well. I'm sure we'll give that in show notes. Or you can email hello@golioth.io and it'll probably get to me.

Erik: Awesome. Jonathan, thank you for taking the time to talk to us today.

Jonathan: Thank you. It was a pleasure.

Erik: Thanks for tuning into another edition of the IoT spotlight podcast. If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend the speaker, please email us at team@IoTONE.com Finally, if you have an IoT research, strategy or training initiative that you would like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.