Schwerpunktthema

Die Stärke einer Microservice-Architektur ist die lose Kopplung der Module. Und gleichzeitig ist es auch ein großer Nachteil, denn in jedem Microservice müssen Funktionen wie Monitoring, Tracing und Circuit Breaking erneut gelöst werden. Ein Service Mesh verspricht, viele der Funktionen in die Infrastruktur zu ziehen. So wird es endlich kinderleicht, Microservices zu entwickeln und auch zu bändigen - oder vielleicht doch nicht?

Blog-Post

Prometheus Counters and how to deal with them

Blog-Post

Carbon dioxide monitoring with Rust, InfluxDB and Grafana

Carbon dioxide monitoring with Rust, InfluxDB and Grafana.

Artikel

Deployment und Monitoring von Microservices

Beim Deployment von Microservices verschwimmen die Grenzen zwischen Mikro- und Makroarchitektur. Während das Team die Mikroarchitektur für jeden Service individuell entscheiden kann, muss man sich bei Makroarchitektur-Themen mit anderen Teams zusammensetzen, um die beste Lösung für Themen zu finden, die mehrere Services betreffen. In diesem Artikel wollen wir uns ansehen, welche Entscheidungen ein Team für sich treffen kann und welche mit anderen Teams abgestimmt werden müssen. Zu diesem Zweck möchte ich beispielhaft den Lernprozess beschreiben, den ich in Teams erleben durfte, die “einfach mal” mit Microservices angefangen haben.

Link

Wider den Blindflug: Logging und Metriken in verteilten Anwendungen

Podcast

Logging und Metrics

Moderne Ansätze zur Überwachung von verteilten Systemen

Artikel

Wissen, was läuft

Mit gutem Logging kann man eine Menge über laufende Anwendungen oder gar Anwendungsverbunde erfahren. Eine entscheidende Einschränkung geht mit Logging einher: Logs sind nur ein Strom von eingetretenen Ereignissen. Um herauszufinden, wie gut eine Anwendung läuft, ist jedoch deren Zustand interessanter.