diff --git a/src/sa/model/decisions/0008-heartbeat-as-monitor.madr b/src/sa/model/decisions/0008-heartbeat-as-monitor.madr new file mode 100644 index 0000000..928a5c0 --- /dev/null +++ b/src/sa/model/decisions/0008-heartbeat-as-monitor.madr @@ -0,0 +1,41 @@ +## ADR #0008: Heartbeat monitors are used to monitor availability + +1. **What did you decide?** + + An Heartbeat monitor shall be used to monitor availability of the engine components of SmartHut. + +2. **What was the context for your decision?** + + Given the existent of three different engine components, the availability monitor strategy shall + minimize network traffic so at not to overload the network between the three components. The chosen + strategy shall also be able to effectively give a reasonable indication of availability of each engine + component of SmartHut, so that the health of the SaaS deployment (and even of the user-controlled + deployments) may be checked by a dashboard page. + +3. **What is the problem you are trying to solve?** + + Which is the most effective and network-concious technique to monitor availability of engine components of SmartHut? + +4. **Which alternative options did you consider?** + + - Watchdog monitor + - Heartbeat monitor + +5. **Which one did you choose?** + + - Heartbeat monitor + +6. **What is the main reason for that?** + + An heartbeat monitor implementation requires half the amount of messages between the monitoring component and + the component to check. With an appropriate clock, a heartbeat monitor can be as effective as a watchdog monitor + to check availability of engine components. + + Pros: + - Less network traffic + - Easier to implement + + Cons: + - Implementation of services is "active" (i.e. aware of the need to signal availability) + - Power users with a personal deployment who do not wish to deploy an availability monitor are subjected to additional + network traffic \ No newline at end of file diff --git a/src/sa/model/index.md b/src/sa/model/index.md index 7484068..787280f 100644 --- a/src/sa/model/index.md +++ b/src/sa/model/index.md @@ -1772,6 +1772,152 @@ Exceed: 1, 2, 3, 4, 5, 6, 7, 8 } +1. The architecture laid down for homework 11 is already compatible with a SaaS deployment. Considering the deployment view, all nodes other than the +device the user uses to browse the UI and smart devices, all other components will be served in the cloud. Each engine component and each database could be served in a docker container, and as pointed out already in the deployment view the static assets for the frontend could be served by an existing CDN like Cloudflare. + +2. A three-tier pricing system for the SaaS deployment could be implemented in this way: + - Up to 10 devices and 5 scenes: free + - Up to 100 devices and 50 scenes: 5.99 CHF/mo + - Unlimited devices and scenes: 9.99 CHF/mo + +3. A general 99.9% (three nines) availability of all engine components and the CDN shall be implemented to achieve the components. The time of application of a state change from the time it has been commanded by the UI shall not exceed 2 seconds. The time between a device included in a trigger +and the corresponding scene being applied on the user's devices shall not exceed 5 seconds. + +4. An updated bottom up component diagram including the monitoring solution follows. The `Heartbeat monitor` component shall be +deployed on a separate node and expose an HTTPS component which the engine components shall call periodically to signal that they are alive. + +```puml +@startuml +skinparam componentStyle rectangle + +!include + +title Smarthut.sm Logical View + +interface " " as DIF +interface " " as TF +interface " " as SCF + +component "Heartbeat monitor" as MON { + interface " " as CF + interface " " as MF + + [Clock] as C + [Monitor] as M + [Dashboard] as DS + + C-CF + M-MF + + CF)-M + MF)-DS +} + +component "IoT Devices" as IOT { + interface " " as HDF + interface " " as HSF + interface " " as ZDF + interface " " as ZSF + + [HomeKit smart device] as HD <> + [HomeKit smart sensor] as HS <> + [MQTT smart device] as ZD <> + [MQTT smart sensor] as ZS <> + + HD--HDF + HS--HSF + ZD--ZDF + ZS--ZSF +} + +component "User Interface" as UIC { + interface " " as WSCF + + [User Interface] as UI + [WebSockets API (JavaScript)] <> as WSC + + WSCF)--UI + WSC--WSCF +} + +component "Users and Devices" as DEV { + interface " " as DIDBF + interface " " as HAPF + interface " " as ZIGF + interface " " as WSSF + + [HAP-java] as HAP <> + [paho.mqtt.java] as ZIG <> + [Device Engine] as DI + + note left of DI: Already implemented using Spring Boot + + [javax.websocket API] as WSS <> + [User and Device DB <$database{scale=0.33}> (PostgreSQL)] <> as DIDB + + HDF )-- HAP + HSF )-- HAP + ZDF )-- ZIG + ZSF )-- ZIG + + DI--(WSSF + WSSF--WSS + HAP--HAPF + ZIG--ZIGF + HAPF )-- DI + ZIGF )-- DI + DIDBF-DIDB + DI -( DIDBF +} + +component "Triggers and Automations" as TRIG { + interface " " as TDBF + + [Trigger and Automation Engine] as T + [Trigger and Automation DB <$database{scale=0.33}> (PostgreSQL)] <> as TDB + + TDBF-TDB + T -( TDBF +} + +component "Scenes" as SCENE { + interface " " as SCDBF + + [Scene Engine] as SC + [Scene DB <$database{scale=0.33}> (PostgreSQL)] <> as SCDB + + SCDBF-SCDB + SC -( SCDBF +} + +DI--DIF +TF--T +SCF--SC +WSS <..> WSC: WebSocket protocol (RFC 6455) +DI --( TF +T --( SCF +DIF )-- SC +DIF )-- UI +UI --( SCF +UI --( TF + +MF )- DI +MF )- SC +MF )- T + +skinparam monochrome true +skinparam shadowing false +skinparam defaultFontName Courier +@enduml +``` + +![Architectural Decision Record](./decisions/0008-heartbeat-as-monitor.madr) + +8. As external dependencies are the smart devices owned by the users, the system cannot function de facto without them being available to the +Device engine component. However, I plan to implement a "shadow" state for unavailable devices which is regularly maintained as the actual state +of working devices, which will be applied once the device comes back online. The user interface will also make the device failure visible and notify +that a "shadow state" is maintained while the device is not reachable. + # Ex - Flexibility {.instructions