almost done hw12
This commit is contained in:
parent
7036b265dc
commit
629fd1eb28
|
|
@ -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
|
||||
|
||||
{.instructions
|
||||
|
|
|
|||
Reference in New Issue