Montag, 19. April 2021

Softwarearchitektur: Micro Service oder Monolith

Micro Service oder Monolith: Welches ist die besser Software Architektur?

Klarte Antwort, it depends.

Mirco Services sind seit ca. zehn Jahren die vorherrschende Software-Architektur, wenn es um Server-Anwendungen geht. Die meisten stellen sich nur die Frage, wie gross darf oder kann ein Micro Service sein. Aber gibt es Alternativen zu Micro Services? Ja und zwar mindesten zwei:

  1. Serverless
  2. Monolith
Zum ersten Punkt der Serverless Architektur kommen wir später. Punkt 2 der Monolith gilt als überholt und wird mit der Softwarekrise in den 90er Jahren in Verbindung gebracht, nicht ganz zu unrecht, waren damals doch fast alle Softwareprodukte Monolithen.

Seit den 90er hat sich allerdings einiges getan, wie Software entwickelt wurde. Agile Softwareentwicklung hat mehr oder weniger zu den Micro Services geführt. Ein grosser Vorteil der Micro Services war und ist, das man durchaus in der Lage ist die Softwareentwicklung horizontal, also mit der Anzahl der Entwicklerteams, zu skalieren. Aber offen gesagt, ist dies auch mit Monolithen möglich. Mit der aktuellen Technik, ein paar alten bewährten Software Regeln ist auch möglich Monolithen mit multiplen Teams parallel mit der selben Geschwindigkeit zu entwickeln wie Micro Services. Dazu benötigt man nur zwei Regeln:
  1. Share Nothing
  2. Dinge, die zusammengehören sind im selben Package
Eine Anmerkung zu Punkt 2, das bedeutet nicht das ein Package mit Controller und eins mit Services und so weiter hat. Diese Packetierung ist falsch, das ist so als würde man die Pflanzen nach ihr Blütenfarbe klassifizieren. In einem Packet befindet sich Controller, Service, Model, Repository die zusammen einen Anwendungsfall implementieren. Pakete selbst sind unabhängig von einander und benutzen keine Klassen aus anderen Paketen. Und fertig ist der skalierbar programmierte Monolith.



PS: Fehlende Buchstaben im Text sind verursacht durch Apples grandiosen Versuchen Tastaturen für MacBooks neu zu erfinden.

PS 2: Die Paketierugsstrategie vieler Domain Driven Ansätze ist komplett falsch.

Montag, 2. November 2020

Was ist Chaos Engineering?

 



Chaos Engineering ist ein Disziplin um Software zu Testen. Dabei wird das zu untersuchende Software System auf bekannte und unbekannte Fehler getestet. Das Ziel ist es, die Fehlertoleranz oder Robustheit von Software oder Software Systemen zu erhöhen und die Auswirkung von Fehlern zu begrenzen. Gesteht wir in der Regel das Produktionssystem oder äquivalente Produktions-ähnliche Systeme.


Geschichte

Mit dem Aufkommen von verteilten Software-Systemen und anderen komplexen Micro-Service-Systemen war es notwendig, die Zuverlässigkeit dieser Systeme zu erhöhen. Das war die Geburtsstunde des Chaos Testens. Bekanntester Vorreiter war Netflix 2011. Das Chaos Testen ist ein Vorläufer des Chaos Engineerings. Bekanntester Vertreter ist der Chaos Monkey von Netflix. Parallel zu diesen Entwicklungen wurde seit 2013 auch in Deutschland Chaos Engineering eingesetzt (Otto Group).


Systeme

Auswahl:

  1. Chaos Monkey
  2. Toxi Proxy
  3. Chaos Mesh


Literatur

  1. Casey Rosenthal, Lorin Hochstein, Aaron Blohowiak, Nora Jones, Ali Basiri: Chaos Engineering. Building Confidence in System Behavior through Experiments, O’Reilly Media, Inc, 2017
  2. Mikolaj Pawlikowski: Chaos Engineering. Site reliability through controlled disruption, Manning Publications, 2021 (angekündigt)
  3. Laine Campbell, Charity Majors: Database Reliability Engineering, O’Reilly Media, 2107


Links



Dienstag, 18. August 2020

Tools die auf keinem Mac von Softwareentwicklern fehlen sollten

  1. brew
  2. clamav
  3. gpg
  4. docker desktop
  5. vim o. ä. 
  6. jq
  7. yq
Brew - der nicht vorhandenen Paketmanager, ohne ihn geht auf Mac keine Softwareentwicklung.
Installation im Terminal: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"


ClamAV - Freier Viren- und Malware Scanner, ein Klassiker auf seinem Gebiet mit guter Erkennungsleistung. Am besten einfach einen CRON einrichten.

GPG aka PGP der Standard, wenn es um Verschlüsselung geht.

Docker Desktop - Docker ist Teil der meisten Backend-Projekte. Hier sollt man nicht den Docker von Brew verwenden, der bereitet nur Probleme. Stabiler ist die Alternative Docker Desktop.

VIM - oder ein vergleichbarer reiner Texteditor ist Tipp für schnelles Arbeiten jenseits einer IDE.

JQ - Json Query, ein Tool um schnell JSON Dateien zu prüfen oder zu parsen. JSON Nodes lassen sich einfach aus JSON Dokumente filtern. JQ beherrscht selber auch Pipelining. JQ ist quasi ein Art JSON grep.

YQ - Yaml Query, analoges Tool zu JQ nur für YAML Dateien.

Mittwoch, 12. August 2020

Welche Tools sollten auf keinem sicheren Mac fehlen.

 


  1. ClamAV
  2. GPG
  3. Privacy Badger
  4. TOR

ClamAV - Freier Viren- und Malware Scanner, ein Klassiker auf seinem Gebiet mit guter Erkennungsleistung. ClamAV lässt sich sehr bequem per brew installieren. Am Besten ClamAV regelmässig per CRON updaten und ausführen.

2 12 * * * /usr/local/bin/freshclam --log=/Users/avaragejoe/logs/clam.log
17 12 * * * /usr/local/bin/clamscan -i --log=/Users/avaragejoe/logs/clam.log -r ~/Downloads
47 12 * * * /usr/local/bin/clamscan -i --log=/Users/avaragejoe/logs/clam.log -r ~/Desktop



GPG aka PGP der Standard, wenn es um Verschlüsselung geht. GPG verschlüsselte Na hrihteno können nicht mitgelesen werden, auch nicht von Regierungen.

Privacy Badger ist ein Browser Plugin der EFF der  Web Tracking unterbindet. Das Plugin gibt es für Firefox, Edge, Opera und Chrome. Bei TOR ist er standardmässig mit dabei.

TOR - der sichere Browser für alle denen der Privacy Badger alleine noch nicht reicht. Der Tor TOR Browser basiert auf Firefox und basiert ein Onion Routing um seinen Standort zu verschleiern.

Zusätzlich noch als Tipp eine Alle die Tiefen einstiegen wollen: 

Samstag, 1. August 2020

Java Streams

Ich habe mich lange gedrückt um einen Artikel über Java Streams zu schreiben, jetzt nach Jahren ist es so weit. 

Als ich das erste Mal Java Streams sah, ich glaube es war in einem Meetup, kamen mir zwei Gedanken:
  1. Wow, cool
  2. Welches Problem wird durch Java Streams gelöst.#
  3. Parallelisierung für lau
In den nächsten Jahren sickerten die Streams so in die allgemeine Java Programmierung. Streams waren ja nicht Neues, ich habe Streams (Pipes) exzessiv mit BASH and Splunk eingesetzt.  

Meine anfänglich Begeisterung sank recht schnell auf den Nullpunkt. Java Streams schienen in der Praxis mehr neue Probleme zu verursachen, als sie lösten, und welches Problem sollten Streams nochmal lösen.

Jetzt nachdem der Hype weitergezogen ist, hier in aller Ruhe ein paar Tipps und Antworten zu Java Streams. 

Frage: Welches Problem löst Java Streams?

Streams sind eine weitere From oder Alternative zu Schleifen (for, while). Sie bieten zwei Vorteile gegenüber den normalen Schleifen. Bei grossen Datenmengen kann man Streams parallelisieren, was auf Multi-Prozessorsystemen einen Geschwindigkeitsvorteil bringt. Dazu zwei Anmerkungen, in Cloud Umgebungen ala Marathon, Kubernetes, AWS - schaut in euere Configs ob ihr Überhaupt mehr als eine CPU habt, wenn nicht, bringt die Parallelisieren von Streams nichts. Die zweite Anmerkung, nur bei grossen Datenmengen ist die Parallelisieren sinnvoll, weil sonst der Overhead durch die Verteilung des Codes und der Daten über mehrere Cores die Geschwindigkeitsgewinn der Parallelisieren aufrisst.

Hier ein Beispiel für eine super simple Parallelisierung mit Java Streams: https://www.adam-bien.com/roller/abien/entry/java_8_from_ordinary_for


Das zweite Vorteil von Java Streams gegenüber normalen Schleifen ist, das die Abarbeitung strukturierter erfolgt (stream -> (filter -> map)* -> collect). Das war für mich eher selten das Problem, aber es eindeutig ist das ein Vorteil von Java Streams. Das Problem sind nicht die Streams, das Problem sind die Programmier die mit Java vertraut sind. Sie fangen jetzt an das bekannte Exception Handling und Verzweigungen in den Streams einzubauen. Das ist generell ein Fehler oder besser der Fehler beim Umgang mit Streams. 

Streams behandeln nur positive Fälle. Ein Exception Handling oder ein Handling von Alternativen führt zu extrem schwierig zu lesendem Code. So etwas sollte in einem zweiten Stream gemacht werden. Streams sind verzweigungslos. Das macht sie so elegant und verständlich. 

Java Entwickler die es gewohnt sind Exceptions nahe am Ursprung zu behandeln, müssen umdenken und diese Funktionen in Filter und einem zweiten Stream auslagern.


Zusammenfassung:

  1. Streams sind ein sinnvolles Pattern für die Softwareentwicklung
  2. Wer Pipes toll fand wird Streams lieben
  3. Streams sind verzweigungsfrei zu bauen, entsprechende Filter, ggf. Mappings und alternative Streams sind umzusetzen

Samstag, 25. Juli 2020

Video: The Future of Programming von Robert C. Martin

Robert C. Martin aka Mister Clean Code von seiner besten Seite. Ein schönes Video über die Vergangenheit, den aktuellen Stand und die Zukunft der Sofwareentwicklung. Aber ich will nicht spoilern, seht selbst.