eBizTalk - Berichten, Unterhalten, Weiterbilden

Als ich bei der eBiz Consulting GmbH anfing, bekam ich die Gelegenheit an einem internen Projekt zu arbeiten, in dem eine Microservices Architektur verwendet werden sollte. Das Projekt, die sogenannte „eBizConSuite“, ist eine Sammlung von Services für KMUs. Die eBiz selbst ist der erste Kunde dieser „eBizConSuite“. Die im Rahmen des Projektes erarbeitete Basisplattform („Digital Plattform“) soll zukünftig auch für andere Kundenanwendungen verwendet werden. Darüber hinaus haben wir das wichtige Ziel verfolgt, unser Wissen in aktuellen Microservices Technologien wie Kubernetes, Docker und .NET Core auf- und auszubauen. Dieses neue Wissen habe ich zu verschiedenen Gelegenheiten (z.B. Company Meetings und eBizTalks) an meine Kollegen und Kolleginnen in der eBiz weitergeben können.

Bevor ich mit dem Projekt beginnen konnte, habe ich das Best Practices Beispielprojekt "eShopOnContainers" von Microsoft (siehe https://github.com/dotnet-architecture/eShopOnContainers) analysiert und schließlich die Erfahrungen aus diesem Projekt für uns immer wieder als Referenz herangezogen. Es war für mich sehr hilfreich, ein solches Best Practices Projekt vorliegen zu haben, um die Grundlagen der Microservices Architektur zu verstehen, da ich zu diesem Zeitpunkt noch relativ wenig Wissen dazu hatte.

Abbildung 1: Monolithische Architekturen und Microservices Architekturen

Nachdem ich mir das Projekt "eShopOnContainers" angesehen hatte, hatte ich das Gefühl mich auf einem anderen Planeten zu befinden. Bis dahin hatte ich nur mit monolithischen Architekturen gearbeitet, in denen typischerweise fast alle Softwarekomponenten in einer Gesamtanwendung zusammengefasst waren. Aber in Microservices Architekturen sind diese Komponenten einer Anwendung durch bestimmte logische (meistens fachliche Kriterien, manchmal technische Kriterien) Kriterien getrennt, so wie es im obigen Bild (Abbildung 1) grob dargestellt ist.

Diese Komponenten (=Microservices) sind autonom und laufen unabhängig voneinander. Dieser Unterschied wirkt sich auf viele Bereiche aus, wie z.B. auf die zu verwendenden Tools und Bibliotheken. Zum Beispiel das Konzept der „Containerisierung“, das Kubernetes-Ökosystem oder die Notwendigkeit der Nutzung eines Service Bus sind ganz neue relevante Bereiche.

Daher dauerte es einige Wochen, bis ich diese neue Architektur und die Komponenten in diesem Umfeld richtig verstanden hatte.

Nachdem die neu erstellten Microservices mit Hilfe von Docker-Compose erfolgreich in der lokalen Umgebung entwickelt und debugged wurden, stellte sich das Deployment der Anwendung in Kubernetes ebenfalls als eine Herausforderung dar, die es zu nehmen galt.

Die Herausforderung, die Deployment Konfiguration mit YAML zu formulieren ergab sich aufgrund der vielen Funktionen und Einstellungen, die man in einer Kubernetes Umgebung vornehmen kann und beachten muss. Aber nachdem es einmal funktionierte, war es erstaunlich zu sehen, wie mächtig Kubernetes ist. Dazu gehört die Replikation und das Load Balancing von Services, die Health Checks, usw.. All dies dient dazu minimale Ausfallzeiten der Services und damit der Gesamtanwendung sicherzustellen.

Rückblickend betrachtet bin ich sehr zufrieden damit, dass ich mich mit diesen modernen Technologien und der Microservices Architektur beschäftigen konnte und habe dabei viele neue Erkenntnisse gewinnen können.

Obwohl ich einige Bereiche des Best Practices Projekts "eShopContainers" (z.B. Akzeptanz von Code-Redundanzen, minimale Codebasis usw.) zunächst als falsch empfunden habe, habe ich während meiner Lernphase die dahinterstehenden Gründe (aufgrund der Microservices Architektur) nach und nach verstanden. Es ist offensichtlich, dass Containerisierung zukünftig eine noch viel größere Bedeutung haben wird, und meiner Meinung nach wird Kubernetes die Rolle des führenden Orchestrierungstools und Hosting-Ökosystems weiter ausbauen.

Bilder in einen PowerBI Report zu integrieren ist eine leichte Aufgabe. Die Bilder abhängig von z.B. einem Status einzubinden wird schon etwas kniffliger. In diesem Beitrag möchte ich zeigen, wie man kleine Bilder, die in einer Datenbank gespeichert sind, dynamisch in einen Report einfügt.

Vorbereitung

Als Beispiel erstelle ich einen Projektreport. Für das Anzeigen eines Status habe ich hier folgende Bilder erzeugt:

Die Größe je Bild liegt bei ca. 11KB. Auf Grund der Größenbeschränkung von 32766 Byte beim Laden einer Spalte in den Report dürfen die Bilder eine bestimmte Größe nicht überschreiten. Meine Erfahrung hier ist, dass das Bild kleiner 20 KB sein sollte. Alles was darüber liegt, wird obwohl es unterhalb der Größenbeschränkung liegt, abgeschnitten.

Diese Bilder möchte ich nun in meinem Report als Projektstatus anzeigen lassen. Dafür habe ich die folgenden Tabellen angelegt.

Die State-Tabelle habe ich dann mit den Bildern befüllt

Daraufhin habe ich ein paar Beispielprojekte angelegt.

Mit diesen Daten bekommt man sicher keinen ganzen Report gefüllt, aber ich denke, das Prinzip des dynamischen Anzeigens der Bilder wird deutlich.

PowerBI Report

Im PowerBI Desktop wird ein neuer Report geöffnet und die gerade angelegte Datenquelle ausgewählt.

Die zwei Tabellen Project and State werden ausgewählt.

An den Queries müssen nun noch ein paar kleine Anpassungen gemacht werden. Dafür muss Edit Queries geöffnet werden.

In der State-Tabelle wird der Datentyp des Bildes auf Text geändert.

Und eine neue Spalte wird hinzugefügt. Diese neue Spalte muss wie folgt aussehen:

Mit Close and Apply diesen Schritt abschließen.

Dann wird auf die Tabellenansicht gewechselt.

Dort wird die Data Category der neuen Spalte auf Image URL geändert.

Auf der ersten Reportseite wird dann eine Tabellenansicht mit den Projekdaten und dem Statusbild angelegt.

Das Ergebnis ist eine Übersicht der Projeke und der Status wird als Ampel dargestellt.

Wird ein neues Projekt hinzugefügt oder ein bestehendes geändert, ändert sich das Statusbild im Report automatisch. Man muss bei diesem Vorgehen nur beachten, dass die zu verwendenden Bilder die Größe von ca. 20 KB nicht überschreiten, da sie sonst durch die Spaltengrößenbeschränkung beim Laden in den Report abgeschnitten werden.

Wie man bei größeren Bildern vorgeht, folgt in einem nächsten Beitrag.

In den letzten Monaten habe ich einen unserer Kunden bei der Entwicklung einer Azure Cloud Lösung unterstützt. Kern dieser Lösung ist Azure Service Bus, der dank seiner horizontalen Skalierbarkeit, dem zuverlässigen Messaging und der einfachen Nutzung in hybriden Szenarien, ein integraler Bestandteil vieler Integrationslösungen geworden ist.

Für Azure Service Bus existiert eine lange Liste an Beschränkungen (Quotas), z. B. was Kontingente und Drosselungsschwellenwerte angeht. Das Nichtbeachten einer dieser Quotas kann schwerwiegende Folgen haben. In unserem Fall war das System jeden zweiten Tag nicht mehr erreichbar und ein Neustart war der einzige Workaround.

Die Fehlermeldung lautete folgendermaßen: „Cannot allocate more handles. The maximum number of handles is 4999”. Wenn man die Meldung näher betrachtet, erkennt man, dass es sich um eine Limitierung handelt.

Für uns war aus den folgenden Gründen nicht klar, warum der Fehler aufgetreten ist:

• Der Fehler ist auch an Uhrzeiten aufgetreten, an denen sehr wahrscheinlich keine 5000 Verbindungen zum Service Bus bestanden.
• Laut der Beschreibung, sind nur NetMessaging und AMQP Verbindungen mit 1000 bzw. 5000 jeweils bestehenden Verbindungen betroffen: Der Fehler ist aber auch an Stellen aufgetreten, an denen wir keine AMQP Verbindungen erstellt haben. Das dachten wir zumindest…

Fast alle unserer Aufrufe machen von der Klasse „ClientEntity“ Gebrauch. Durch die Instanziierung und die Nutzung dieser Klasse werden implizit AMQP Verbindungen aufgebaut.

Die Lösung war zum Glück einfacher als gedacht, die Fehlersuche auf einem Test-System jedoch intensiv und komplex: AMQP Verbindungen werden implizit aufgebaut und müssen explizit geschlossen werden. D.h. da, wo eine Instanz von „ClientEntity“ nicht mehr gebraucht wird, soll die Verbindung explizit geschlossen werden. In der Dokumentation ist dieses Verhalten nirgendwo dokumentiert. Das lässt sich zum Glück mittels des Aufrufs von „ClientEntity.CloseAsync()“ einfach lösen.

Fazit

Das Motto „Kenne deine Grenzen“ war in meinem Fall leider nicht hilfreich, um diesen schwerwiegenden Fehler in der Produktionsumgebung zu vermeiden. Ich musste diese Grenzen zunächst selbst erforschen, um eine passende Lösung zu finden.

Letztes Jahr stand ich vor der großen Frage wo ich mich denn beruflich sehe und wie ich mich gerne weiterentwickeln würde. Schnell war klar: Ich möchte in die Projektmanagementwelt eintauchen. Die Vielschichtigkeit und die doch sehr unterschiedlichen Aufgabenbereiche, die mit Projektmanagement verbunden sind, haben mich neugierig gemacht, mich tiefer in dieses Thema einzuarbeiten.

Die Suche nach der richtigen Wissens-“Quelle”

Als diese wichtige Entscheidung gefällt war, stand ich vor der nächsten großen Herausforderung: Wo bekomme ich für den Wissensaufbau unter anderem gute Literatur, die nicht allzu trocken ist und man trotzdem einiges an Wissen mitnimmt, her. Die Suche nach der für mich richtigen Literatur gestaltete sich nicht ganz so einfach- bis ich eines Tages auf das Buch von Mario Neumann aufmerksam geworden bin: „Projekt-Safari - Das Handbuch für souveränes Projektmanagement“. Die Beschreibung von Mario Neumann zum Buch:

Was haben Kolumbus, Lindbergh und ein Projektmanager gemeinsam? - Ihre Abenteuer sind Projekte, überall lauern Gefahren, doch bei Erfolg winken Ruhm und Ehre! […]

Dieser Guide zeigt, wie Sie die abenteuerliche Reise durchs Projekt vorbereiten, Hürden überwinden und nie das Ziel aus dem Blick verlieren. Tipps für den Ernstfall, Erlebnisse erfahrener Projektleiter und theoretische Hintergründe fügen sich zu einem völlig neuartigen Handbuch für Projektmanager. So wird jedes Projekt aufregend und inspirierend wie eine Safari!

Okay, cool, scheint mal ein etwas anderer Ansatz zu sein. So schnell war das Buch auch schon bestellt und ich mitten in der Projektsafari eingetaucht.

Der Aufbau des Buches

Eine Etappenüberschrift mit einer kurzen Erklärung, auf welches Abenteuer man sich gerade begibt. Untergliedert wird das Ganze in verschiedene Etappenziele, welche einen Bezug zu einem fiktiven Projekt haben und in „Toms Tagebuch“ erläutert werden sowie eine kurze Zusammenfassung des Etappenziels und einer (negativen) Situation mit dazugehörigem Tipp, wie man diese vermeiden bzw. meistern kann.

Gerade für Neulinge (aber auch für gestandene Projektleiter) auf dem Gebiet eine super Sache, denn man kann sich direkt in die Situation hineinversetzen und kurz darüber nachdenken wie man selbst wohl mit dieser Herausforderung umgegangen wäre. Auch bekommt man durch die Tipps eine mögliche Herangehensweise vorgestellt. Natürlich muss man diese Tipps der Situation anpassen, aber zumindest als Anregung sind sie super.

Welche Etappen gibt es?

• Etappe 1: Lust auf ein Abenteuer? » Von der Idee zum Projektauftrag
• Etappe 2: Der Abenteuer-Plan » Das Geheimnis erfolgreicher Projektplanung
• Etappe 3: Das Abenteuer beginnt » Einen Fehlstart vermeiden
• Etappe 4: Das Umfeld gewinnen » Widerstände managen
• Etappe 5: Alles hört auf mein Kommando » Führen, ohne Chef zu sein
• Etappe 6: Kurs halten in gefährlichen Gewässern » Konflikte und Krisen meistern
• Etappe 7: Zum Endspurt ansetzen » Das Projekt erfolgreich abschließen

Die Etappen werden von einem kurzen Beispiel von „früher“ (z.B. wie Kolumbus ein Projekt gestartet hat) eingeleitet und dann auf die heutige Zeit bezogen, auch diese Segmente lockern das Projektmanagementthema etwas auf. Es wird also ein kompletter Projektzyklus, von der Idee, über die Planung bis hin zum Abschluss beschrieben.

Zusätzlich kann man sich, anhand der Beispiele im Buch, ein komplettes Workbook zusammenstellen. Auf folgende Dokumente wird eingegangen und anhand eines Beispiels vorgestellt:

• Statusbericht
• Projektplan
• Risikologbuch
• Änderungsantrag
• Projekttagebuch
• AIL (Action Item List)

In wie weit man alle Dokumente genauso einsetzt, ist jedem selbst überlassen, aber als Anregung ist es wirklich gut und man lernt zumindest die Begriffe und den Aufbau kennen.

Mein Fazit

Alles in allem hat mir die Projektsafari wirklich Spaß gemacht und was fast noch wichtiger ist: Ich habe sehr viel von diesem Buch gelernt und konnte doch einiges an Tipps mitnehmen und auch im Projekt einsetzen. Auch heute schlage ich immer mal wieder darin nach, wenn ich einen anderen Blick auf meine Herangehensweise haben möchte, oder mir wieder mal ein Thema vor Augen führen möchte. Ich würde das Buch definitiv (gerade für Junior PL / PMO) weiterempfehlen.

Jahrelang kannte ich nur den Team Foundation Server, kurz TFS, von Microsoft als Quellcode-Verwaltung. Er konnte alles, was ich bis dato brauchte. Check-in und Checkout, Shelve, Work-Item Verknüpfung, Historie. Auch Branching ging mit wenigen Klicks von der Hand.

Und dann kam Git

Git war erst einmal "nur" eine weitere Quellcode-Verwaltung. Wie groß kann der Unterschied schon sein? Das waren meine ersten Gedanken. Bis ich mich mehr mit Git beschäftigte. Ich muss zugeben, Git ist für den Umstieg vom TFS gewöhnungsbedürftig. Die Lernkurve ist steil. Es ist einfach nach einem anderen Konzept gestrickt.

Der erste Unterschied ist, dass Git ein verteiltes Versionskontrollsystem (Distributed Version Control System, DVCS) ist. Der TFS hingegen ist ein zentralisiertes System (Centralized Version Control System, CVCS). D.h. im TFS sind alle Informationen zu Dateien, Historie, Changesets etc. auf einem Server abgelegt, während bei Git eine lokale Kopie auf dem Rechner vorliegt, mit allen Informationen zu Dateien, Commits, Historie etc. Es Bedarf keiner Verbindung zu einem Server, es sei denn man möchte seine Arbeit mit dem Remote-Repository synchronisieren.

Meine ersten Erfahrungen mit Git sahen so aus, dass ich mir erst einmal die Bedeutung der Befehle klar machen musste. Commit, Push, Pull, Fetch, Checkout, um hier einige zu nennen. Während Checkout im TFS bedeutet, eine Datei zum Bearbeiten zu öffnen, heißt es in Git in einen anderen Branch zu wechseln. Check-in im TFS besteht in Git aus zwei Befehlen: Commit und Push.

Hier eine kleine Gegenüberstellung der Befehle:

Der zweite Unterschied ist die Art und Weise wie Git Dateien betrachtet. Der TFS betrachtet Dateien einzeln, mit deren Änderungen über die Zeit. Git hingegen, betrachtet alle Dateien als einen Stream sogenannte Snapshots. Diese „Schnappschüsse“ entstehen jedes Mal, wenn ein Commit ausgeführt wird. Git speichert nun diesen Zustand aller Dateien, in diesem Moment als Snapshot.

Diese Art der Verwaltung hat natürlich Vorteile in Sachen Geschwindigkeit. Ein Commit dauert nur den Bruchteil einer Sekunde. Blame oder die Historie aufrufen und filtern geht unglaublich schnell. Da Git alles lokal vorhält und somit keine Verbindung zu einem Server benötigt, kann Git hier viel Performance rausholen.

Wirklich interessant, wurde es erst mit Branches und Mergen.

Volle Power mit Branches

Die volle Power von Git bekam ich erst beim Anlegen und Arbeiten mit Feature-Branches zu spüren. Hier zeigt sich der dritte Unterschied. Der TFS muss für jeden Feature- oder Release-Branch einen eigenen Ordner angelegen und alle Dateien dorthin kopieren. Dieser muss dann vom Entwickler per „Get Latest“ abgeholt werden, was bedeutet, dass ein weiterer Ordner auf der Festplatte vorliegt und Speicherplatz verschwendet.

Git hingegen kopiert nicht den gesamten Parent-Branch. Stattdessen handelt es sich einfach um einen Zeiger auf den Parent-Branch, von wo aus wir unseren neuen Branch erzeugt haben.

Im Folgenden zeige ich euch wie das funktioniert.

Wir gehen davon aus, dass ihr bereits ein „git clone“ von einem Projekt eurer Wahl gemacht habt. Für gewöhnlich nennt sich dieser geklonte Branch „master“. Wir möchten nun ein neues Feature entwickeln und legen uns dafür einen Feature-Branch namens „tolles-feature“ an.

Mit dem folgenden Befehl kann ein neuer Branch angelegt werden:

$ git branch tolles-feature

Der Branch ist nun angelegt, wir sind aber noch nicht auf dem neuen Branch. Das sieht ungefähr so aus (man achte auf das Sternchen, es markiert den aktuellen Branch):

Wir führen nun folgenden Befehl aus, um zu wechseln:

$ git checkout tolles-feature

In Git sieht das wie folgt aus (auf das Sternchen achten):

Und hier noch die Kurzform der beiden oben genannten Befehle:

$ git checkout -b tolles-feature

Nun können wir auf dem neuen Branch arbeiten und Committen, Pushen etc.

Nachdem das Feature fertig entwickelt ist, müssen wir unsere Änderungen wieder zurück in den „master“-Branch integrieren. Wir führen ein Merge durch, um den Feature-Branch zurückzuführen. Um das zu bewerkstelligen, wechseln wir zurück auf „master“:

$ git checkout master

Anschließend kommt der Merge:

$ git merge tolles-feature

Das war’s schon. Und wo ist jetzt die Power? Nun, Git ist so intelligent und hat beim „mergen“ erkannt, dass in „master“ keine Änderungen (also Commits) vorliegen, die den Merge beeinflussen. Also wird ein „Fast-Forward“ gemacht. Das heißt, der Zeiger von „master“, wird einfach auf das letzte Commit von „tolles-feature“ gesetzt, wie in der Abbildung unten zu sehen ist:

Sollten Konflikte auftreten, weil in „master“ ebenfalls Commits vorhanden sind, können diese, wie im TFS auch, einfach aufgelöst (Resolved) werden. Im oben genannten Fall gibt es aber keine Konflikte, ergo kann der Zeiger verschoben werden. Im TFS würde dennoch eine große Merge-Operation stattfinden, die Dateien vergleicht und Änderungen übernehmen muss.

Da der Branch „tolles-feature“ nun nicht weiter benötigt wird, können wir den Branch mit folgendem Befehl löschen:

$ git branch -d tolles-feature

Und so wird in Git mit Branches gearbeitet. Cool oder?

Mein Fazit

Da ich nun seit ein paar Monaten mit Git arbeite und den anfänglichen Git-Schock überwunden habe, hat sich mein Arbeitsablauf verbessert. Ich bin schneller geworden. Dafür gibt es eine Reihe von Gründen:

1. Git selbst ist sehr schnell
2. Ich mache lokale Commits, das spart Zeit und ich kann Code committen ohne dass ich Gefahr laufe, den Build zu zerstören
3. Branches! Ich kann für alles einen Branch anlegen und darin arbeiten. Ist die Arbeit erledigt, kann ich die Branches einfach zurück mergen. Es ist zum Teil meines Arbeitsworkflows geworden.

Ich kann nur sagen: Der Umstieg lohnt sich!

Zum Abschluss möchte ich noch ein paar Tools erwähnen, die das Leben mit Git erleichtern, wenn man nicht auf der Kommandozeile arbeiten möchte:

• TortoiseGit – Integriert sich in das Explorer Kontextmenü und bietet umfangreiche Möglichkeiten in Verbindung mit Git
• TGit Extension – Eine Visual Studio Extension, die TortoiseGit ins Visual Studio integriert
• Git Diff Margin Extension – Eine Visual Studio Extension, zum Anzeigen von Änderungen