,

How We Think About Golioth at Golioth

This is an excerpt from our bi-monthly newsletter. You can sign up for future newsletters here.

Last week, we announced our new pricing and “free device management” for individual developers. Golioth’s prices have outwardly changed, making our platform more accessible for a wide variety of use cases. Internally, however, the change is more impactful. We’ve created a new framework for our pricing that better aligns with how we think about Golioth as a product and the value we provide to our customers. “Device Management” often carries ambiguity in the industry, let’s clarify how we, at Golioth, define this category and it’s distinction from other areas of our IoT development platform. Here’s how we think about Golioth from a product perspective:

Golioth is broken up into three distinct product feature sets:

  1. Device Management
  2. Data Routing
  3. Application Services

These three categories make up what we call an “IoT development platform” here at Golioth.

Device Management

We think of device management as the category of features that every single IoT device on the planet needs. When I first joined Golioth, I called these “table stakes” features: Software Updates (OTA), Logging, Settings, Remote Procedure Calls, Credentials, and the ability to view your devices online/offline status in a UI. Now, all of us at Golioth, myself included call these “basic rights” of an IoT developer. These are features you simply cannot live without as an operator of a production fleet of IoT devices.

Data Routing

For constrained IoT applications that need to capture sensor readings and send them up to the cloud, it is often very challenging to securely and efficiently get that data to its end destination — whether that be a time series database, a visualization tool or your backend that powers a consumer facing app. This is where Golioth’s category of “data routing” features comes in: arbitrary data ingestion, transformation, and streaming of data to any cloud destination through “output streams”. You can think of data routing on Golioth as a “pipeline” from your devices to your final data destination. Something neat about using Golioth for data routing is that you can effectively “federate” to different databases or application backends with “no code”. This means you could migrate from one cloud to another, or one database to another without the need for a firmware update.

Application Services

Application services are the category of services we offer to make your life easier as an IoT developer. The goal here is to offset the development time and cost of building your own custom backend APIs, hosting your own database infrastructure, and ultimately shorten time to market for IoT products. LightDB Stream for example is a lightweight time series database for storing and querying sensor readings. You can use it to get up and running quickly, see and store live data flowing from your IoT sensors into Golioth and even build visualizations on top of it. But you don’t have to use it. For advanced IoT applications where you need hyper-scale performance and more control you may want to consider routing your data to InfluxDB, or MongoDB Time Series. Optionality is why we think of them as separate standalone services.

Finally, there is a fourth a category of features around collaboration, less so for devices and more so for the human users of Golioth. Any robust developer platform extends beyond just the technical capabilities—it needs to create an environment where team collaboration, API access, and efficient organizational and billing processes integrate seamlessly. We’ve designed Golioth to support everyone from individual developers to teams of any size, with scalability in mind from a single project to custom enterprise solutions that require private deployment models. These features don’t quite fit as neatly as the other 3 categories, but you’ll see them fall under the “Platform” section on our pricing page.

Hopefully this gives some insight into how we think about Golioth, at Golioth (and adds some clarity around the new pricing framework). We’re continuing to invest in all categories of our product — device management, data routing, application services and “platform” features. We look forward to sharing a few additional product announcements that we have cookin’ soon!

As always, let us know if there are any areas you want to see improved (or if you have questions about our new pricing) by reaching out to [email protected] or in our community forum.

/by

An Ode to Industrial Standards

This is an excerpt from our bi-monthly newsletter. You can sign up for future newsletters here.

I love old* industrial standards like Modbus. It was created in 1979 and widely adopted by machine makers since then. It has survived and continues to be used because old industrial machinery just doesn’t seem to die. If the equipment doesn’t die and the equipment runs an industrial standard, by the transitive property, that standard isn’t going anywhere. In 2024 (a short 45 years after the inception of Modbus), there continues to be equipment out in the field that uses the standard. Some of that equipment is brand new, too!

Technically, Modbus is a communications protocol (OSI layer 7). But by default it doesn’t connect to the broader internet, it connects to other machines. For “Modbus RTU”, this involves hooking machines together using RS-485, another standard, but one for the data link layer (OSI layer 2).  It is hardened against interference for noisy industrial environments. As a result, it’s reliable. My experience in the industrial sector has taught me that more than anything else, reliability is key. It’s the same reason that 4-20 mA sensors are used, and the bulkiness of the electronics is normally not an issue. If a circuit requires a massive protection diode? Well, make the enclosure bigger! It needs to be reliable.

Normally you’d have a Modbus sensor talking back to an industrial controller like a PLC. This was the localized control that allows fast action on the factory floor (“the temperature sensor is too high, turn down the heating element”, etc). As the times modernized, so did the connectivity options on the PLCs. But in many cases, it’s overkill. If you just want to push the data from a sensor to the internet, it’s a lot of extra equipment. Not to mention, that bulky-yet-reliable equipment? It often comes with a hefty price tag.

A few weeks ago, we released a reference design that skips a lot of these steps. In fact, all that’s required is a piece of hardware that has an RS-485 interface and an internet connection. In our case, it’s the nRF9160 plus some breakout boards, talking back to the Golioth Cloud. We showcased the Modbus Vibration Monitor Reference Design using a motor monitoring sensor, but now we’re able to swap out that sensor for any other Modbus (RTU) sensor. That’s the power of an industrial standard. Now that we have a connected, embedded device talking Modbus, the rest is just firmware updates. Oh yeah, Golioth does that part too!

Modbus is far from the only standard out there. It benefits from wide ranging, long time adoption due to the fact that it’s openly published, royalty free, and easy to implement. But there are other sensors and end devices running things like EtherCAT, CAN, PROFIBUS, HART, BACnet, Foundation Fieldbus, DeviceNet, and more. Once you start to think of these protocols and standards as a common language among end devices, the power of a common platform like Golioth hardware, firmware, and Cloud software really starts to emerge. Let us know if you see a need for any of these other standards in your projects!

* somewhere an engineer is saying, “you think that’s old, check out this other industrial standard!”

A proper Ode

Oh, Modbus, protocol of precision, thou art,
In the realm of data, thou playest a crucial part.
With thy structure elegant, and format clear,
Thou bringest connectivity far and near.

From the industrial floors to automation’s lair,
Thy presence is felt, ubiquitous and fair.
In the language of ones and zeros, thou speak,
Binding machines together, strong and sleek.

With thy bit twiddling dance, thou dost choreograph,
In the symphony of automation, thou art the staff.
Thy messages traverse through wires unseen,
Connecting devices, a diligent machine.

In the world of SCADA, thou never are flawed,
Transmitting signals at 9600 baud.
Reliable, robust, thy virtues abound,
In the realm of control, thy praises resound.

Oh, Modbus, thou art a beacon bright,
Guiding engineers through the darkest night.
With thy registers and coils, thou dost empower,
Enabling systems to function by the hour.

Though newer protocols may rise and fall,
Thy legacy, Modbus, shall stand tall.
For in the annals of technology’s lore,
Thy name shall echo forevermore.

So here’s to thee, Modbus, noble and true,
In the world of automation, we honor you.
For without thy steadfast hand to guide,
The wheels of progress would surely slide.

/by
,

The Hard Thing About Abstraction

This is an excerpt from our bi-monthly newsletter. You can sign up for future newsletters here.

Our lives are built on abstraction. It is what allows us build things much faster than we previously could. A person, or a group of people, decides that everyone else shouldn’t need to think about the gritty details of a problem — and voila, a new layer in the stack!

This is great until someone comes along and builds on that new layer, then discovers it obfuscates a lower level detail that they need. The abstraction that was intended to be, and in many cases is, an enabler has suddenly become a hindrance. There are a few options for how abstraction builders can choose to handle this trade-off.

The simplest solution is to decide that they are targeting a narrow audience, acknowledging that they won’t be a good fit for everyone. In reality, nearly all technology is optimized for some subset of the total possible consumers. Even the most ubiquitous products are disliked by some, and don’t fit the requirements of others. Choosing where you want to exist on the spectrum from a narrow audience to a broad one is critically important when designing a product.

Another option is to break the abstraction layer into a set of smaller, modular abstractions that can be assembled in a variety of configurations. This typically enables faster iteration, and when exposed to end-users, widens the audience for the product. The downside is that you are also pushing more cognitive burden onto the end-user, forcing them to understand multiple components and how they should piece them together.

Like any early-stage company, we at Golioth have wrestled with where we fall on the “audience spectrum”. Historically, we have leaned towards a more opinionated platform, prioritizing simplicity and ease of use over letting customers adjust all the knobs. There is good reason for this approach. Golioth connects two fairly disparate technical domains, firmware and the cloud, and many of our customers have deep expertise in one, but not both. The tricky thing about this strategy is that making the firmware highly customizable and the cloud opinionated, or vice versa, results in half our users having an experience that is not catered to their current capabilities.

We could take the simple solution and decide that we are only really targeting half of the total potential audience. Perhaps we could build an incredible platform for firmware engineers who don’t want to think about the cloud. Unfortunately, our users are building products based on connecting hardware to the internet, which is no simple feat. In the early stages, they typically want to shrink scope as much as possible. If functionality is not absolutely necessary, it can wait. But down the line, their team may grow, their product may expand, and they may decide that a domain they were previously happy to consume abstractly is now an area where they need fine-grained control. Golioth needs to serve users along each step on that journey.

Over the next few weeks, we are rolling out significant updates to Golioth that give you more control over the platform. But don’t worry, the simple, streamlined experience you know and love isn’t going anywhere. Alongside these changes, we’ll also give you more insight into your usage, and if you don’t want to think about managing custom configuration, we’ll provide reasonable defaults that allow you to keep using Golioth as you always have. With these new capabilities, from prototype to production, we can’t wait to see what you will build!

/by

You Can Build It Yourself…But Should You?

This is an excerpt from our bi-monthly newsletter. You can sign up for future newsletters here.

I’m a car guy…well sort of; more of a gearhead than someone who obsesses over the luxury amenities or posh and circumstances of the high-end brands. My fondest memories from childhood are of working in the garage with my dad on whatever clunker he had recently brought home and was determined to get running again. At 10 years old I was spending my free time wedged under a car changing oil and checking grease fittings. At 16, I rebuilt the engine in my first car – a 1970 Ford Maverick with a straight 6 250 and 250,000 miles on it. 

 

What I loved then about working on cars, what I’ve always loved, was the feeling I got every time I took something broken down, sometimes well beyond operational, and brought it back to life, as good or better than it was. The beauty of the modern automobile (pre-electrification) is the simplicity and elegance of interchangeable parts, shoutout to Henry Ford! Is your oil plug stripped? Get a new one! Brake pads worn down, exhaust manifold cracked, head gasket blown? Just break ‘em down, rip ‘em out, and replace them with a new part as good or even better than what was there originally. 

 

These days I’m rarely under the hood of a car. Not because I can’t be, or because I don’t love it, but because there are other things in my life that I love more. Spending time with my family, being outdoors, volunteering, solving hard problems at the office, all of these things are simply more important to me now than the time I spend in the garage. It’s a simple question of utility – every minute I spend working on my car is a minute I can’t spend doing something else important to me. So just this morning, even though it hurt me a little inside, I scheduled my wife’s car for some routine maintenance with the local mechanic. 

 

Now here’s the kicker, the mechanic has an operation purpose built to service my vehicles. He has all the tools, the lift, the garage space, not to mention the thousands of hours of expertise working on my car and countless others like it. So not only does taking my car to the mechanic save me time and allow me to focus on what I care about most, I’m also getting better quality maintenance from someone fully equipped to look after a resource my family and I depend on. 

 

There’s an allegory here to Golioth and the conversations I have nearly every day with our partners and customers. Golioth is the mechanic down the street, there with the right tools and experience to manage your IoT devices and, when necessary, help strip away the old bulky code and replace it with some upgraded aftermarket cloud services. It’s not that our customers CAN’T build their own IoT management layer, it’s just that there are more important things for them to be spending their time (and money) on. 

 

Most of our customers build connected products from end to end. They start with hardware selection and prototyping, develop their embedded software, work through testing, trials and validation and end at production ready connected solutions. They need purpose built tools and services made by people whose core focus and expertise lies in those tools. Like a mechanic in the shop, Golioth is that purpose-built solution with the team to match. 

 

I still love working on the family cars, but these days I trust the mechanic to do what he does best. The rest of my life is simply too important to spend my time under the hood. Just like I trust the mechanic, Golioth’s customers trust us to bring our knowledge and expertise to bear and be careful stewards of their connected fleet. We give them the peace of mind to know that the things they need are already taken care of, so they can focus on the more important things.

/by
,

Using the Best Tool for the Job

This is an excerpt from our bi-monthly newsletter, which covers our recent news and happenings around the IoT ecosystem. You can sign up for future newsletters here.

When building out the Golioth platform, we’re constantly examining the user experience. We ask ourselves why it would make sense to use Golioth over alternative solutions, whether in house or off the shelf. While we want to have the most engineers using the Golioth platform as possible, we prioritize the real goal of making it easier to build secure, efficient, and useful products. We want our users to use the best tool for the job. Let’s dig a little deeper into how we do that.

When comparing Golioth to an in-house solution, we ask our customers a simple question: Is building your own IoT platform helping you differentiate your product? While some of you may answer “yes,” the majority of folks find that focusing on the IoT infrastructure is a distraction. For them, using Golioth helps drive down costs while increasing organizational efficiency. Those are tangible metrics for us to target; they are manifested in our pricing, our seamless device on-boarding, and straightforward user management.

When we compare Golioth to off-the-shelf solutions, our outlook is somewhat unique. Rather than trying to be the last software product you will ever need, we look to be the best platform for managing devices that connect to the internet. To do that, we build differentiated device management services, such as OTA updates, instant device settings, and real-time logging—to name a few—and we heavily optimize network throughput and efficiency. For simpler IoT products, we also provide application services such as LightDB State and LightDB Stream so that you can move beyond device management to basic data storage.

At Golioth, we care about moving the industry forward without forcing our users to compromise. The IoT product landscape is complex and heterogeneous. It would be naive of us to think that Golioth would be suitable for every aspect of any one product. That’s why we curate a large ecosystem of partnerships to enable you beyond the realm of device management. Our latest partnership announcement will enable devices to talk to Memfault over a single, secure connection. We aim for Golioth to integrate with best-of-class cloud platforms and enable their usage without complicating the firmware running on-device.

Crucially, the best tool for the job may look different today than it does tomorrow, in 6 months, and in 2 years. The promise of Golioth is that as long as your devices are sending data using our firmware SDK, you will have the flexibility to change where that data is going, how it is being processed, and how it ultimately is presented to the end-user, all without changing a line of firmware code. Golioth Output Streams currently enables this, but over the next few months, we will announce an even more robust set of features in this area, starting with our Memfault integration, which you can sign up to be notified about here.

/by

The Design-For-Hire Ecosystem

This is an excerpt from our bi-monthly newsletter. You can sign up for future newsletters here.

I spend a lot of time thinking about the folks that offer design services to others. I came from that space as a lowly one-person consultancy (dev shop? product development firm? what do we call these things?). It’s an interesting set of challenges, including offering opinions and expertise to others for money. Some days, I felt on top of the world, like I knew everything and could solve anything. On other days, I felt defeated and lost, trying to find a solution for my clients, who I served as best I could. I joined Golioth when I saw a solution to a problem I was trying to solve as a hardware consultant: I just created a beautiful piece of hardware; now, how do I connect it to the cloud? I was clueless about cloud capabilities, but that didn’t stop my clients from asking for them.

One of the key points in the design-for-hire game is that you need to understand your area of expertise well and deploy that knowledge confidently. That starts to get tough for IoT / connected products. Every day, there’s a new communication protocol, web technology, component, or other efficiency that could save your client money and make your dev shop look better. How do you stay on top of your game when doing so means you’re giving up dollars deploying the knowledge you already have?

We stay on top of these technologies at Golioth, as well. It’s why we maintain an active blog. It’s why we partner with silicon companies in order to better prepare you for the next generation of components (hint: there are some great products coming soon). It’s why we do free training and why we’re going to make it even better in the new year. The ground is shifting, and we shift with it. Even internally, we are making our SDK more efficient, and we’ll need to adjust to change by updating our examples, reference designs, content, and more. We will push these changes to all of you so you can have a starting point for your client designs and deliver better products faster.

IoT can be very challenging, and we’re here to help you cross every hurdle. You hopefully know (and love) our content, but the Golioth platform is designed to make you more efficient: read how the product development firm Ovyl based out of Nashville was able to prototype a solution 30 times faster with Golioth when they were building a Thread prototype.

Whether you’re a successful dev shop, or a brave solo consultant, we’d love to work with you. Golioth users often reach out to us for help, and we’d love to send them your way. We’d also love to create content both for you, and with you, the design-for-hire virtuoso. Sign up here if you’d like to partner with Golioth on content, joint customers, new opportunities, and more.

/by