Introducing the Golioth Simulator

At Golioth we are on a quest to improve the security, reliability, and efficiency of IoT products. Today we are launching the Golioth Simulator as part of an increasing focus on addressing the organizational challenges that come with building those products. The Simulator enables cloud engineering teams to generate data that mimics what devices deployed in the field will eventually send to Golioth, prior to the devices being ready. This eliminates bottlenecks caused by long hardware and firmware development cycles, and allows for the services that interact with device data to be developed in parallel.

The Development Cycle Mismatch

Building connected products is challenging for a number of reasons, but one of the most prominent is the range of engineering work that is required. This is illustrated by comparing to the development of products that are either only software, or non-networked hardware. In the former, engineering work ranges from distributed systems and backend development to frontend and graphic design. In the latter, the range may be from electrical engineering and PCB design to firmware development.

IoT products essentially take those two spectra and join them.

While this clearly increases the breadth of skills that are necessary for a team to possess, it also introduces a more subtle challenge: wildly different iteration cycles and development timelines. In the worst case scenario, the longest development cycle, which is typically hardware, will dictate the velocity of an entire project. A common fallacy is to compare the relative effort of software development to hardware development and conclude that the former can be delayed until the latter is in its final stages. In reality, any aspect of the engineering spectrum can derail a product.

However, even if a team properly prioritizes all aspects of developing the product, it is easy to fall into the trap of creating both implicit and explicit dependencies between components of the system. Mitigating these organizational hazards can be a force multiplier.

Innovation at the Interface

We frequently describe Golioth as the interface between firmware and cloud engineers. Sitting between these two groups comes with a responsibility to present a familiar set of tools to both parties, but also an opportunity to introduce new functionality that closes the gap between them. While the Golioth platform presents separate APIs for devices and servers, each designed to be familiar to the respective consumer, the commonality between them is data.

Ultimately, connected products are about producing data in one location, and consuming it, or some transformation of it in another location. Typically, the majority of data for our customers today is being produced by devices, and consumed by servers. All of this data flows through Golioth, meaning that customers have a consistent interface for both sending and receiving data. But what about the shape of the data itself?

In the end, it will depend on the behavior of devices, but software iteration that depends on managing physical devices, or even firmware running in an emulated environment, to produce data is sacrificing efficiency. In the ideal case, firmware and cloud teams use the shape of data as a contract between systems, and software engineers are able to easily produce data that adheres to that contract. If that contract changes in the future, the tooling should make testing and updating the software that interacts with it seamless. The Golioth Simulator is a first step in that direction.

How it Works & Getting Started

As of today, the Simulator is available in the Golioth console for all users. Navigating to any device in your fleet should result in the Simulator launcher appearing in the bottom right corner of your screen. Clicking on it will open a floating window.

Navigate to the Credentials tab of the chosen device, and copy your preferred PSK ID and PSK into the Simulator. Use the default JSON payload or enter your own, then click Send. If you navigate to the LightDB Stream tab, you should see a new message with your payload.

To view new messages as you send them, be sure to enable Auto-Refresh. Because the Simulator is actually interacting with Golioth device APIs, messages will also flow through to any Output Streams you may have configured in your project.

Next Steps & Feedback

The initial functionality of the Golioth Simulator is intentionally basic as we are interested in seeing how users leverage the new interface to increase their pace of development. If you have feedback about how you would like to see the Simulator evolve to support more use cases, please reach out to us on the forum.