Easy|Secure|Reliable: Not Just in the Marketing Materials
SensorFu’s Beacon is unlike some other software appliances. While these try to support loads of features, and weird use-cases, we don’t. Beacon does one thing: it calls home. This lets us make deployments as straightforward as possible, without having to compromise on security or reliability.
Zero Configuration (for real!)
Because Beacon only does one thing, there isn’t a lot to configure. In fact, everything is baked-in to the Beacon images that you spawn from your instance of Home. All you need to specify is the Beacon’s name and IP settings (static or DHCP/Autoconf), and you’ll receive a ready-to-go virtual or physical disk image. There is one more setting, Home’s address, but this is the same for every Beacon and will be automatically configured in the near future.
After booting Beacon, there’s nothing that you need to — or could — configure. Beacons are immutable, meaning they cannot store configuration changes or data.
Immutable Beacons
A driving factor behind this architecture was the question: “How do we know that a Beacon is working, if it’s in an isolated network?”. The answer was, to make Beacon as simple as possible, with the absolute minimum amount of end-user configuration. What’s more, making Beacon immutable means that once it’s up and running, there are few things that could cause it to stop working.
“How do we know that a Beacon is working, if it’s in an isolated network?”
One of the two things that can vary from Beacon to Beacon, is its network configuration (the other is its name 🙂). Using a good ol’ ICMP ping, you can check that a Beacon is alive and its network stack is working. There’s not a lot more that could go wrong, so you can be reasonably sure that the Beacon is working. Due to the self-service nature of Home, you can spawn as many test Beacons as you like to verify end-to-end functionality.
Getting started
After receiving credentials to your organization’s instance of Home, you can login and begin spawning Beacons. There’s not much to it: for each Beacon, you create a configuration which contains its name and network settings. Then you build the configuration, choosing which type of image (.ova or Raspberry Pi) you need. The downloaded image can finally be deployed… and that’s it!
Easy upgrades
Upgrading software appliances is usually not a trivial task. For low-level upgrades, within the OS, you need to follow the manufacturer’s upgrade notes carefully. What’s more, you aren’t the person who setup the software initially, so its configuration and quirks aren’t easily apparent. High-level upgrades, where you outright replace a part of the appliance (for example the OS disk image), can be easier, but aren’t always available. With these, you also need to be careful not to affect the appliance’s persistent data, be it in an external database, data disk, or some other medium.
Because Beacons are immutable, there is no configuration information or data that needs to be transferred during an upgrade. All you have to do is deploy a new beacon with the same configuration. Configurations for each Beacon are stored in Home, so you can rebuild an existing one whenever you like, using the latest software version.
Going Forward
If you would like to read more about the inner workings of Beacon, my colleague Ossi has written about:
