Add slide about Scandio
This commit is contained in:
@@ -16,7 +16,7 @@ und den Backends liegt.
|
||||
|
||||
Ein kurzer Überblick über den Vortrag: Nach dem Projektsetup (also Hintergrund, Motivation und Ziel des Projekts) beschreibe ich
|
||||
euch die Problemstellung etwas genauer und dann natürlich auch die Lösungen, also: wie sieht die Architektur des Systems jetzt
|
||||
ab, was genau passiert, wenn das System Updates bekommt, und zum Schluss noch: was wären unsere Wunschträume für die
|
||||
aus, was genau passiert, wenn das System Updates bekommt, und zum Schluss noch: was wären unsere Wunschträume für die
|
||||
Architektur, wenn Zeit und Geld keine Rolle spielen würde oder wir ganz von vorne anfangen würden.
|
||||
|
||||
Eine organisatorische Bemerkung: wenn während des Vortrags Fragen aufkommen, stellt sie gerne sofort und ich werde sie so gut
|
||||
@@ -49,7 +49,7 @@ Heimdall neu zu entwickeln.
|
||||
Ich will hier einmal schematisch zeigen, welche Aufgabe Heimdall hat. Eure smarte Herdplatte von vorhin muss regelmäßig an das
|
||||
Herdplattenstatusbackend die Information senden, welche Herdplatten auf welcher Stufe angeschaltet sind. Gleichzeitig tauscht
|
||||
das smarte Heizungsthermostat eures Nachbarn Nachrichten mit einem Backend aus, um herauszufinden, ob die Heizung nach oben oder
|
||||
unter geregelt werden sollte, und die smarte Dunstabzugshaube eurer Tante meldet an das entsprechende Backend, dass die Filter
|
||||
unten geregelt werden sollte, und die smarte Dunstabzugshaube eurer Tante meldet an das entsprechende Backend, dass die Filter
|
||||
mal wieder eine Reinigung bräuchten. Heimdall sitzt zwischen den Geräten und den Backends und sorgt dafür, dass die richtigen
|
||||
Nachrichten das richtige Backend erreichen, und dass umgekehrt auch Nachrichten in die Gegenrichtung versendet werden können:
|
||||
beispielsweise kann das Herdplattenbackend die Herdplatte anweisen, sich abzuschalten. Die Geräte halten dazu eine Verbindung zu
|
||||
@@ -65,7 +65,7 @@ potenziell zu Überlastung von Heimdall oder den Backends führen, wenn die Neuv
|
||||
Ein Szenario gibt es aber, in dem Verbindungen auf keinen Fall gehalten werden können: nämlich wenn der Server, mit dem die
|
||||
Hausgeräte verbunden sind, ein Update bekommt und daher ersetzt werden muss. Deswegen ist eins der größten Ziele bei der
|
||||
Entwicklung der Architektur von Heimdall, dass solche Neustarts bei den meisten Konfigurationsänderungen des Systems nicht
|
||||
notwendig sind, sondern die Konfigurationsänderung am Live-System durchgeführt werden können.
|
||||
notwendig sind, sondern die Konfigurationsänderungen am Live-System durchgeführt werden können.
|
||||
|
||||
## Lösungen
|
||||
|
||||
@@ -102,7 +102,7 @@ scheitern. Da sind asynchrone Aufrufe die bessere Lösung. Das heißt, dass entw
|
||||
erst im Nachgang verarbeitet, oder dass der WSM die Nachricht an einen hochverfügbaren Message Broker schickt und die Backends
|
||||
die Nachricht in ihrer Geschwindigkeit zu einer späteren Zeit konsumieren können. Egal, für welche Lösung man sich hier
|
||||
entscheidet: das Backend muss eine Nachricht zurück an das Gerät senden, weiß aber noch nicht, mit welcher WSM-Instanz das Gerät
|
||||
verbunden ist. Übrigens hätten wir das selbe Problem auch ganz ohne synchrone Aufrufe: sagen wir mal, euer Nachbar möchte seiner
|
||||
verbunden ist. Übrigens hätten wir das selbe Problem auch ganz ohne asynchrone Aufrufe: sagen wir mal, euer Nachbar möchte seiner
|
||||
Heizung mitteilen, dass sie die Temperatur in der Wohnung auf 22 Grad hochregeln soll, weil er jetzt auf dem Heimweg ist. Dann
|
||||
muss das Heizungsbackend eine Nachricht an den Thermostat schicken. Wenn das Backend versucht, die Nachricht über eine zufällige
|
||||
Instanz des WSM zu schicken, ist die Chance nicht sehr hoch, dass der Thermostat gerade mit dieser Instanz verbunden ist.
|
||||
@@ -168,9 +168,9 @@ nicht zu schnell wieder verbinden können. Natürlich ist das ein ungünstiger Z
|
||||
verbundenen Geräte eine ganze Weile eingeschränkt sein kann.
|
||||
|
||||
Jetzt kommen wir mal zum geplanten Fall: eine neue WSM-Version soll deployed werden. Das Deployment läuft dann so ab: In einem
|
||||
ersten Schritt werden 1/3 der Instanzen als Canary-Deployment durch Instanzen der neuen Version ersetzt. Diese neue Version
|
||||
ersten Schritt werden 1/3 der Instanzen durch Instanzen der neuen Version als Canary-Deployment ersetzt. Diese neue Version
|
||||
läuft parallel zu der alten für eine Woche, bevor auch die übrigen Instanzen ersetzt werden. So können Fehler frühzeitig erkannt
|
||||
werden.
|
||||
und behoben werden, bevor alle Geräte betroffen sind.
|
||||
|
||||
[30] Das bedeutet übrigens nicht, dass nach dem Canary-Deployment 1/3 der Verbindungen auf der neuen Version stattfinden. Die
|
||||
Wahrheit ist hier etwas komplizierter: die Geräte, die sich nach dem Abschalten mancher der alten Instanzen neu verbinden,
|
||||
|
||||
BIN
public/consulting.png
Normal file
BIN
public/consulting.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
public/development.png
Normal file
BIN
public/development.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
BIN
public/operations.png
Normal file
BIN
public/operations.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
@@ -19,6 +19,36 @@
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section data-background-image="/backgrounds/normal.svg" data-background-position="top right">
|
||||
<h2 style="margin: 48px;">Über Scandio</h2>
|
||||
<center class="r-stretch" style="display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 36px; justify-items: center;">
|
||||
<img src="consulting.png" style="height: 200px;">
|
||||
<img src="development.png" style="height: 200px;">
|
||||
<img src="operations.png" style="height: 200px;">
|
||||
<small>
|
||||
<b>CONSULTING</b>
|
||||
<p>
|
||||
Wir analysieren und beraten; von Cloud-Architektur über agile Beratung bis hin zu Migrationen in die Atlassian Cloud.
|
||||
</p>
|
||||
</small>
|
||||
<small>
|
||||
<b>DEVELOPMENT</b>
|
||||
<p>
|
||||
Webanwendungen oder Softwarearchitektur, IoT oder Data Science: unsere Teams decken jeden Aspekt von agiler
|
||||
Softwareentwicklung ab.
|
||||
</p>
|
||||
</small>
|
||||
<small>
|
||||
<b>SYSTEMS ENGINEERING</b>
|
||||
<p>
|
||||
Mit Best Practices aus dem DevOps-Bereich and agilen Methoden entwicken unsere Teams maßgeschneiderte
|
||||
Cloud-Architekturen.
|
||||
</p>
|
||||
</small>
|
||||
</center>
|
||||
<p style="margin: 48px;"><a href="https://www.scandio.de/">www.scandio.de</a></p>
|
||||
</section>
|
||||
|
||||
<section data-background-color="black">
|
||||
Projektsetup
|
||||
</section>
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
@import "./colors";
|
||||
|
||||
// Include theme-specific fonts
|
||||
@import url(https://fonts.googleapis.com/css?family=Raleway:900|Roboto:300);
|
||||
@import url(https://fonts.googleapis.com/css?family=Raleway:900|Roboto:300,700);
|
||||
|
||||
|
||||
// Override theme settings (see ../template/settings.scss)
|
||||
|
||||
Reference in New Issue
Block a user