In 30 seconds
Fred George describes a personal home-automation experiment using an event bus and small services to coordinate heterogeneous devices. His deployment shortcuts are specific to that experiment and should be evaluated against each system’s risks.
- 1Uncertain goalsThe speaker treats home automation as an uncertain problem.
- 2Device APIsDevice-specific interfaces can be isolated behind services.
- 3Event busSmall services exchange events asynchronously.
- 4Rapids and pondsStreams and stored views serve different purposes.
- 5Missing responsesA request may have no listener or response.
- 6Sticky colorsSeveral services can restore a desired light state.
- 7ExperimentationTesting and deployment practices must match the risk of the system.
Takeaways
- The speaker treats home automation as an uncertain problem.
- Device-specific interfaces can be isolated behind services.
- Small services exchange events asynchronously.
- Streams and stored views serve different purposes.
- A request may have no listener or response.
- Several services can restore a desired light state.
- Testing and deployment practices must match the risk of the system.
Read the edited text by chapter
Experimenting at home
Uncertain requirements and heterogeneous devices.
In this 2017 GOTO talk, Fred George describes a home-automation experiment using small asynchronous microservices. He presents it as a personal exploration of changing requirements, not a universal architecture for every home or production system.
George distinguishes problems with predictable cause and effect from complex situations where teams must experiment and observe. He argues that uncertain home-automation goals are a useful setting for trying ideas incrementally.
He demonstrates changing lights in his home and describes a collection of devices with different APIs. The challenge is to combine them without tying every higher-level behavior directly to one vendor’s interface.
Asynchronous architecture
Events, streams and service responsibilities.
His design uses small services and an asynchronous event bus. Device-facing services publish observations and receive commands, while other services can react without directly calling every device-specific implementation.
He calls the shared event stream the “rapids,” filtered streams “rivers,” and stored current-state views “ponds.” This is a way of thinking about event flow and queryable state, not a guarantee of ordering or delivery.
In his “need” pattern, a service publishes a request without assuming a particular listener will respond. Asynchronous systems must handle missing responses and other failure cases explicitly.
George separates hardware access from higher-level scenes and cross-device behaviors. Monitoring services observe the event stream and can flag conflicting commands or failed components.
Sticky colors and lessons
State restoration, monitoring and tradeoffs.
His “sticky colors” example polls light state, publishes it and reapplies a desired color when a light comes back in a different state. Several small services cooperate without a central orchestration service.
He favors fast experimentation and abundant messages for developer productivity. In his home experiment he also argues for deploying without some tests; that tradeoff should not be generalized to systems where failures can harm people or cause significant loss.
George connects the approach to agile values, suggesting that teams working on uncertain problems may organize around experiments and feedback. He describes potential future work on sensors and smaller hardware.
More from this channel
39:12EN
22:33EN
34:11EN
28:15EN
46:36EN
28:23EN