Wenn Software im Team entwickelt wird, ist es wichtig strukturiert zu arbeiten, um Komplexität in der Code-Basis zu vermeiden. Ein Aspekt bei der Strukturierung von Code ist die Architektur – diese sollte sich in der Codebase wiederfinden. Doch was ist Architektur und wie kann diese in der Code-Base abgebildet werden?

Beim Monitoring ist das Logging wohl die bekannteste Möglichkeit, Applikationen zu beobachten. Beim Loggen werden Textnachrichten einer Applikation aufgenommen und gespeichert. Strukturiertes Logging ist eine Technik, bei der Log Nachrichten in einem strukturiertem Format, wie JSON, gespeichert werden. Meta-Daten helfen dem Entwickler den Kontext der Log-Nachricht zu verstehen. Viele Sprachen und Laufzeitumgebungen haben ein Konzept von Threads um Meta-Daten beim Loggen aufzunehmen. Eine ähnliche API suchte man bei NodeJS vergebens – das hat sich mit AsyncLocalStorage geändert.

Eine hohe Erreichbarkeit ist für viele Applikationen essentiell und gutes Testen bei Aktualisierungen von Applikationen ist deshalb unvermeindlich. Das Problem: gewisse Konfigurationen und Umstände lassen sich außerhalb der Produktionsumgebung trotz beinnahe identischer Staging-Umgebung nicht testen oder sie existiert gar nicht erst, da Software kontinuierlich ausgeliefert werden soll. Damit neue Software ausgerollt werden kann, muss deshalb eine Strategie her, die den möglichen Schaden neuer Versionen minimiert – Canary Releases, das graduelle Ausrollen neuer Versionen.

Beim GitOps-Ansatz werden Änderungen in ein gemeinsames Git-Repository eingepflegt. Während der Entwicklung müssen jedoch kontinuierlich neue Versionen auf das System deployed werden. In diesem Beitrag schaue ich mir das CI-System-orienterte Push- und das CD-System-orientierte Pull Modell an.

Wenn es um IT-Infrastruktur geht, gibt es mehrere Aspekte die es bei verschiedenen Ebenen zu beachten gibt. GitOps und Infrastructure as Code ist ein Ansatz, Systeme als Code abzubilden. In diesem Beitrag lege ich die verschiedenen Ebenen einer IT-Infrastruktur dar, und zeige das Tooling, um diese mit dem GitOps Ansatz abzubilden.

Datenhaltung durch Datenbanken ist ein essentieller Teil der meisten serverseitigen Anwendungen. Damit Datenbanken Anfragen parallel beantworten können, bieten diese mit dem Konzept Transaktionen Spielraum, verschiedene Zustände bei paralleler Verarbeitung zu ermöglichen, die für die Entwicklung von Applikationen einen wichtigen Faktor darstellen. In diesem Beitrag schaue ich mir die Probleme paralleler Datenverarbeitung von Datenbanken und dessen Transaktions-Isolationslevel an.

Kubernetes ist wohl einer der meistgenutzten Container-Orchestratoren. Doch das Netzwerking von Kubernetes ist mit verschiedenen Techniken umsetzbar. In diesem Beitrag schaue ich mir die verschiedenen Kubernetes Service Typen und dessen Anwendungsfälle an.

JavaScript hat sich nicht zuletzt durch den Single-Application-Hype Client-seitig etabliert und wurde durch NodeJS sogar server-seitig salonfähig. Trotzdem doppeln viele Unternehmen Logiken unnötig in verschiedenen Packages. In diesem Beitrag wollen schaue ich mir den Wandel vom Multi-Repo zum Mono-Repo an.

Applikationen brauchen häufig eine Datenhaltung. Um eine Datensicherheit zu gewährleisten und Risiken zu mitigieren, kommen deshalb meistens verteilte Datenbanken zum Einsatz. In diesem Beispiel stelle ich RAFT vor, ein Algorithmus zum Erreichen von Konsensus für verteilte Datenbanken.

Werden in einer IT-Landschaft mehrere Applikationen kontinuierlich deployed und Betrieben — meistens von verschiedenen Teams — kann die IT-Landschaft schnell unübersichtlich werden. Ein Ansatz um das Problem zu beheben ist GitOps. In diesem Beitrag zeige ich die Vorteile auf, die GitOps bringt und welches Problem es löst.