Google Hackathon für Sovereign Cloud von T-Systems

Ich hatte die Chance, am Sovereign Cloud Hackathon teilzunehmen, welcher am 27. und 28. April stattfand. Ziel dieses Hackathons war es, innerhalb von zwei Tagen eine industriespezifische Lösung auf Basis der Google Cloud zu entwickeln. Man konnte sich als Team oder Einzelperson anmelden. Insgesamt waren ca. 200 Kolleg*innen der T-Systems dabei.

Der Auftakt des Hackathons war sehr schön gestaltet. Wir hatten Wortmeldungen von den entsprechenden Leads auf T-Systems Seite. Die für Europa und Deutschland zuständigen Direktoren von Google waren auch anwesend und haben ihre Pläne mit der Sovereign Cloud und zukünftigen Google Services vorgestellt. Danach ging es direkt mit der Teamarbeit los. Ich habe direkt die Zügel in die Hand genommen, unser Team angeschrieben und in eine WebEx eingeladen.

Wir haben erstmal ein wenig socialized und uns kennengelernt. Meine Teampartner waren ein aus Ägypten stammender Cloud Architekt, der inzwischen in Berlin lebt und ein Junior Programmierer aus Barcelona. Nachdem wir wussten, wer wir sind, haben wir uns über unser Knowhow unterhalten. Dabei stellten wir fest, dass wir moderate Kenntnisse in Google Apps Script und ein sehr breites Wissen für (Google) Cloud Services hatten. In unserem Team fehlten definitiv Fähigkeiten zur Frontendentwicklung und praktisches Programmiererwissen. Das mussten wir also später bei der Bearbeitung unserer Aufgabe beachten.

Apropos Aufgabe, jedes Team hatte die Auswahl zwischen verschiedenen Challenges. Unser Team hatte sich schon auf den Bereich Healthcare festgelegt. In diesem gab es zwei mögliche Aufgaben:

**Challenge A)**
*Status Quo*
Clinical diagnostic is expensive and variable and often inaccurate. The idea is to use AI and ML services to predict, e.g. chest cancer.

*Challenge*
Use the Chest Chancer Dataset and find a way to predict whether a patient has cancer or not.
Dataset link here.

*Material to use*
• Auto ML Vision
• Dataset link here

**Challenge B)**
*Status Quo*
In the healthcare industry, the use of speech recognition leads to a great relief of the medical staff, e.g., when dictating findings or documenting nursing measures. Unfortunately, existing speech recognition products are either too expensive or process data on potentially non-trusted platforms.

*Challenge*
Build a voice bot on Google Cloud Platform (GCP) that helps with dictating findings or support nurses with documentation. Use only services that are available on the GCP Sovereign Cloud (Kubernetes, VMs, Cloud Storage, Big Query, Network) and aim for Open-Source technology and a cost-efficient architecture. Can the results be translated into a discharge letter, for example? Could the discharge letter (target group: physicians) also be supplemented by a patient-friendly version in simple language?

Helpful Links:
• Open-Source-Toolkit Kaldi zur Spracherkennung

Wir haben uns für die zweite Challenge, die Analyse von natürlicher Sprache unter Zuhilfenahme der Healthcare spezifischen Sprach-KI von Google entschieden. Auf Basis dieser Aufgabe haben wir versucht, einen Business Case zu erdenken und für diesen eine Lösung zu gestalten. Mit unseren bestehenden Erfahrungen mit Apps Script hatten wir die Idee, Google Workplace zu integrieren. Dadurch mussten wir auch kein eigenes Frontend bauen, sondern konnten einfach das bestehende Google Produkt erweitern. Unser Business Case war damit:

Ein Kunde verwaltet Gesundheitsakten in Google Workplace und muss Texte in Dokumenten und Listen von Medikamenten für jeden Patienten manuell und per Tastatur aktualisieren. Der Kunde will das vereinfachen und zukünftig nur noch in ein Smartphone oder einen PC diktieren. Alle Dokumente sollen automatisch durch die KI aktualisiert werden.

Uns ist natürlich klar, dass Gesundheitsakten nichts in so einem Tool verloren haben, deshalb haben wir die eigentliche Lösung so gebaut, dass sie mit vielen Systemen via einfacher API kompatibel ist. Wir haben Google Workplace lediglich ans Frontend für unsere Demo verwendet.

Da wir zwei Architekten im Team hatten, dauerte es nicht lange, bis eine Architekturskizze aufgetaucht ist. Diese war dann Grundlage unserer weiteren Teamorganisation. Um die einzelnen Aspekte zu realisieren, haben wir uns aufgeteilt. Ein Kollege hat sich um unsere Integration in Google Workplace gekümmert. Ein weiterer Kollege hat sich mit Speech-to-Text auseinandergesetzt und der Dritte im Bunde hatte die Aufgabe, das Healthcare NLP zum Laufen zu bringen. Uns war auch direkt klar, dass wir eine Serverless Implementierung wollten, um nicht noch extra etwas mit Docker, Kubernetes oder VMs machen zu müssen.

Nachdem die Rahmenbedingungen klar waren, konnten wir uns alle in unsere Arbeit stürzen. Dabei sind wir in unserer WebEx geblieben und haben normal weitergearbeitet. Gelegentlich haben wir uns abgestimmt oder Ideen ausgetauscht. Außerdem haben wir uns gegenseitig geholfen, um Unklarheiten bei der Nutzung der APIs und Services zu lösen. Ein Aha-Moment: Solange die Probleme nur in meinem Kopf stecken, habe ich sie noch nicht komplett verstanden, erst wenn ich sie jemand anderem erklären will, entsteht ein komplettes Verständnis.

Da wir mit Serverless arbeiten wollten, mussten wir unseren Programmcode in Cloud Functions realisieren. Wir haben uns für die Programmiersprache Python entschieden, weil diese gut unterstützt wird, uns sehr gut bekannt ist und Google viele Bibliotheken für die Cloud Services für Python bereitstellt. Beim Entwickeln selbst fiel uns dann auf, dass eine Aktualisierung einer Cloud Function schon mal mehrere Minuten dauern kann. Das ist für den normalen Betrieb kein Problem, aber wenn man viele kleine Probleme korrigieren oder Unbekanntes ausprobieren will, ist das eine enorme Bremse. Zumal wir auch nur einen Tag Zeit hatten, tat uns jede Warteminute besonders weh. Wir haben also nach Alternativen gesucht, um unseren Code zu testen. Dabei sind wir relativ schnell auf Jupyter Notebooks gekommen, besonders auf den zugehörigen Google Dienst Colab. In diesem kann man kleine Codeschnipsel in einem Kontext mit seinem Google Account ausführen. Dieses Notebook kann auf alle Google Dienste im eigenen Namen zugreifen und ist interaktiv bedienbar. Das war der nächste Aha-Moment. Geschwindigkeit ist enorm wichtig, vor allem in der Konzeptphase und bei unbekannten Themen. Man sollte ALLES andere aufgeben, um Geschwindigkeit zu erhalten. Security ist irrelevant, wenn man keine Funktion hat. Performance ist irrelevant, wenn man keine Funktion hat. Design ist irrelevant, wenn man keine Funktion hat. Kosten sind irrelevant, wenn man keine Funktion hat. Nachdem man dann bewiesen hat, dass die eigentliche Funktion implementierbar ist, macht man sich daran, die vorher ignorierten Anforderungen wieder einzuweben.

Um die Funktion von Colab zu illustrieren, folgt ein kleines Code Beispiel, das Daten von Google Drive in ein Cloud Bucket überträgt. Alles natürlich vollständig authentifiziert, geschützt und verschlüsselt. Ja, da ist keine einzige zusätzliche Zeile nötig. Für unsere finale Implementierung war dann lediglich noch eine Übersetzung der Shell Befehle in Python Code nötig. Also ist es final doch noch etwas länger geworden. Über die meiste Zeit im Hackathon war das aber genau unsere Upload Funktion und sie war zu 100% ausreichend!

Nach diesem Muster haben wir effektiv in allen Aspekten des Projektes gearbeitet. Am Anfang stand immer eine wilde Mischung aus Shell Befehlen, Web-Aufrufen und Fragmenten von Python Code. Das haben wir dann immer weiter „pythonisiert“, bis wir eine komplette Implementierung in Python hatten. Die dabei entstandenen Funktionen waren meist sehr lang und unverständlich. Am Ende haben wir diese weiter optimiert und immer, wenn wir darauf geschaut haben, sind die Cloud Functions weiter geschrumpft, weil wir vorhandene Module besser genutzt oder Code intelligent umgestellt haben. Letztendlich waren am Ende keine unserer Cloud Functions länger als 50 Codezeilen. Man könnte auch sagen: „echte“ Microservices. Das war ein weiterer Aha-Moment. Die erste Implementierung war immer effektiv, aber unwartbar. Beim zweiten Mal wurde es besser, dann wurden unsere Programme immer länger und letztendlich haben wir alles ordentlich gemacht und die Programme wurden wieder sehr kurz. Das erinnert ein wenig an das bekannte Zitat: 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupéry, Airman’s Odyssey

Am nächsten Morgen ging es darum, unser Projekt zu finalisieren, alles zusammenzufügen und zu testen. Dabei kamen dann noch ein paar Problemchen auf, die aus unseren verschiedenen Arbeitsweisen resultierten. Das war alles gut lösbar. Danach haben wir uns an unsere Präsentation und den Pitch gemacht. Wir wussten, dass am Ende des Hackathon eine Vorstellung fällig wird und unser Projekt anhand der gezeigten Innovation, Kreativität, technischen Umsetzung, Business Impact und Qualität unserer Vorstellung bewertet wird. Für die Vorstellung hatten wir 4 Minuten Zeit, also nicht sehr viel. Am Ende haben wir uns dazu entschieden, unsere Präsentation zu zweit zu halten und fast nur mit Bildern zu arbeiten.

Bei der Vorstellung selbst gab es erst ein Halb-Finale, bei dem innerhalb der einzelnen Bereiche ein erster Platz gekürt wurde. In unserem Healthcare Bereich gab es 4 Teams, die sehr unterschiedlich waren. Das größte Team hatte 7 Mitglieder, kannte sich und hat sogar in einem Büro zusammengearbeitet. Ich will mir gar nicht vorstellen, wie schwer es das den Juroren gemacht hat, da diese Gegebenheiten auch in die Bewertung eingeflossen sind. Die Projekte der anderen Teams waren ebenfalls sehr kreativ und jeder hatte interessante Ideen. Einige Teams haben aber die Vorstellungszeit stark überzogen, ein Team war mit knappen 15 Minuten absoluter Spitzenreiter. Das sorgte wieder für Aha-Momente. Die langen Vorträge sind vor allem auch durch viel Text aufgefallen, generell hatten Vorträge mit vielen Bildern mehr pepp. Außerdem ist in 4 Minuten Vortragszeit nicht viel Platz große Erklärungen, man muss sich bewusst simpel und fokussiert halten. Was mich wieder an ein Zitat erinnerte:

Ich habe den gegenwärtigen Brief aus keiner andern Ursache so lang gemacht, als weil ich nicht Zeit hatte, ihn kürzer zu machen.

Blaise Pascal

Unsere Präsentation war dann fast genau in der Zeit und sogar unsere Live-Demo lief fast problemlos. Man konnte auf jeden Fall erkennen, dass die Live-Demo deutlichen Eindruck erzeugt hat. Nach den Vorträgen gab es keine weiteren Fragen oder Abstimmungen und die Juroren haben sich direkt zurückgezogen, um die Bewertung vorzunehmen. Ich nehme an, dass sollte ein wenig Startup-Atmosphäre simulieren, bei der man nur eine Chance hat, es richtig zu machen. Die Juroren waren übrigens ausschließlich von Google, damit eine faire Beurteilung gewährleistet ist und man am Ende keiner T-Systems Einheit eine Bevorzugung vorwerfen konnte. Nach einer halben Stunde Wartezeit gab es dann die fröhliche Meldung. Unser Team hat das Halbfinale gewonnen und wir können im Finale vor großer Runde unseren Pitch erneut zeigen.

Im Finale haben wir dann unsere Pitches noch einmal im großen Kreis inklusive Top-Management vorstellen können. Das war noch einmal ein anderes Level an Aufregung. Hier haben wir dann auch zum ersten Mal die Lösungen aus den anderen Sektoren gesehen. Für diese lässt sich genau das Gleiche wie in unserem Bereich sagen. Alle Lösungen hatten ein interessantes Problem zugrunde liegen und alle Lösungen hatten technische Raffinessen, die man bewundern konnte. Leider kam es auch hier wieder zu überzogenen Vorstellungszeiten, die diesmal nach 5 Minuten Gesamtzeit hart abgebrochen wurden. Ebenfalls ein weiterer Aha-Moment, man muss sich eben auch an bestimmte Regeln halten. Die letztendliche Bewertung wurde dann via Publikumsvoting über die Telekom Plattform vote.telekom.net gelöst. Leider haben wir diese Wahl dann nicht mehr gewonnen. Wir sind aber mit unserem Platz im Halbfinale bereits mehr als glücklich. In den kommenden Tagen soll es noch ein kleines Goodie-Paket geben, das unsere Leistung würdigt.

---

Du willst das Morgen und Übermorgen bei uns mitgestalten? Dann schau gleich bei unserer Stellenbörse vorbei und werde Teil unseres Teams:
> (Senior) Cloud Engineer (m/w/d)