almost done hw12
This commit is contained in:
parent
7036b265dc
commit
629fd1eb28
2 changed files with 187 additions and 0 deletions
41
src/sa/model/decisions/0008-heartbeat-as-monitor.madr
Normal file
41
src/sa/model/decisions/0008-heartbeat-as-monitor.madr
Normal file
|
|
@ -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
|
||||||
|
|
@ -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 <tupadr3/font-awesome/database>
|
||||||
|
|
||||||
|
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 <<user provided>>
|
||||||
|
[HomeKit smart sensor] as HS <<user provided>>
|
||||||
|
[MQTT smart device] as ZD <<user provided>>
|
||||||
|
[MQTT smart sensor] as ZS <<user provided>>
|
||||||
|
|
||||||
|
HD--HDF
|
||||||
|
HS--HSF
|
||||||
|
ZD--ZDF
|
||||||
|
ZS--ZSF
|
||||||
|
}
|
||||||
|
|
||||||
|
component "User Interface" as UIC {
|
||||||
|
interface " " as WSCF
|
||||||
|
|
||||||
|
[User Interface] as UI
|
||||||
|
[WebSockets API (JavaScript)] <<external>> 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 <<external>>
|
||||||
|
[paho.mqtt.java] as ZIG <<external>>
|
||||||
|
[Device Engine] as DI
|
||||||
|
|
||||||
|
note left of DI: Already implemented using Spring Boot
|
||||||
|
|
||||||
|
[javax.websocket API] as WSS <<external>>
|
||||||
|
[User and Device DB <$database{scale=0.33}> (PostgreSQL)] <<external>> 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)] <<external>> as TDB
|
||||||
|
|
||||||
|
TDBF-TDB
|
||||||
|
T -( TDBF
|
||||||
|
}
|
||||||
|
|
||||||
|
component "Scenes" as SCENE {
|
||||||
|
interface " " as SCDBF
|
||||||
|
|
||||||
|
[Scene Engine] as SC
|
||||||
|
[Scene DB <$database{scale=0.33}> (PostgreSQL)] <<external>> 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
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
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
|
# Ex - Flexibility
|
||||||
|
|
||||||
{.instructions
|
{.instructions
|
||||||
|
|
|
||||||
Reference in a new issue