oder wie es eine Line of Business App (LOB) an einem Nachmittag von on-prem auf Microsoft Azure geschafft und 10 Jahre überlebt hat!

Zuerst: was ist die Group Policy Search (GPS)?
Die GPS dient dazu schnellstmöglich herauszufinden ob es für eine gegebene Aufgabe/Einstellung eine passende Group Policy gibt.
Group Policies sind unternehmensweite Einstellungen für Software, allen voran Windows.

So ging es los

Es wird ungefähr das Jahr 2007 gewesen sein – ich selber war zu der Zeit noch ein Support Escalation Engineer bei Microsoft und meine Teamkollegen und ich benötigten täglich Group Policies (GP) und insbesondere auch die Möglichkeit bestimmte GPs an unsere Kunden weiterzugeben oder auch um die genutzten GPs (bzw. Group Policy Objects, GPOs) zu überprüfen.

Bis dato sah das so aus, dass man sich im worst case in das Tool „gpedit.msc“ begeben hat, dann mühsam die richtige Policy gesucht hat (sofern es eine passende gab) und diese dann händisch in eine Mail abgeschrieben hatte.
Es gab zu der damaligen Zeit auch die Möglichkeit in einem regelmäßig upgedateten Excel File zu suchen, das war aber auch nicht wirklich die beste Möglichkeit.

Ein Kollege von mir – Jean-Pierre Regente – und ich überlegten uns: „das muss doch besser gehen“ und haben eine kleine Anwendung mit folgender Architektur geschrieben, wobei sich JP um das Frontend und ich mich um das Backend gekümmert habe:

Die „Infrastruktur“ war ein Server unter meinem Schreibtisch (ich glaube er stand sogar neben dem Schreibtisch, das sind aber nur Details! 😉 ), auf dem sowohl die MSSQL DB als auch der IIS lief.
Nachteil an dieser LOB (und eigentlich sogar strenggenommen „Shadow IT APP“): sie war nur im Intranet verfügbar und wurde (weitestgehenst) nur von meinen Teamkollegen und mir genutzt.

Compelling Event – oder „warum musste sich eigentlich was ändern“?

Die GPS lebte also fröhlich neben meinem Schreibtisch und meine Kollegen waren happy und auch interne Benchmarks zeigten, dass der (Zeit) Invest in die Entwicklung mehr als angemessen war und zu einer deutlichen Verbesserung sowohl der Geschwindigkeit von GP bezogenen Anfragen als auch zu einer einfacheren und verständlicheren Weitergabe von GPs führte.

Damit war doch alles gut, oder nicht?

Ja – bis zu dem Zeitpunkt, als ich vor Ort bei einem Kunden war: dort benötigte ich zur schnellen Problemlösung die Dienste der GPS.
Ich loggte mich also per VPN [omg, dunkles Zeitalter! vgl. Zero-Trust] auf die on-prem GPS ein und konnte dem Kunden so schnell helfen.
Nun hatte der Kunde (also der Manager, der vor Ort war) gesehen, was ich benutzt hatte, und gab seinen Mitarbeitern daraufhin die Anweisung:
„der kommt hier erst raus, wenn ich auch Zugriff auf das Tool habe!“

Fand ich jetzt nicht so toll, wollte ich doch meinen Zug nach Hause erwischen! 😉

Dieses Ereignis war irgendwann in der Mitte von 2009. Dinge wie „Cloud“ hatten noch keine Bedeutung und interne Prozesse, um solch eine webbasierte App zu publishen, gab es zwar, die wollte aber niemand für solch eine kleine Anwendung ohne zu erwartenden, millionenschweren Revenue angehen.

Da standen wir also mit unserer klassischen On-Premises LOB und konnten sie nicht (mit vertretbarem Aufwand) an den Kunden bringen.
Hinzu kommt, dass für dieses Bestreben natürlich auch kein Budget vorgesehen war – und wo kein Budget geplant ist, da ist es schwer auch nur 1€ zu bekommen – das Problem kennt ihr sicher alle!

Die Lösung! Zumindest der erste Versuch…

Jetzt hatten wir natürlich einen Vorteil: wir arbeiten bei Microsoft – also dem Hersteller des Active Directory und damit auch dem „Erfinder“ von Group Policies.

Also warum nicht einfach die zuständige Engineering Einheit fragen:
„Wollt ihr das nicht haben und publishen?„

Auf den ersten Teil der Frage haben wir – wie zu erwarten war – ein „ja“ bekommen, auf den zweiten Teil allerdings nur ein „nein“. 🙁

Damit konnten und wollten wir uns nicht zufrieden geben!

Glücklicherweise erwähnte einer der Engineering Kollegen in einem der nächtlichen Calls (mit der USA Westküste sind familienfreundliche Call-Zeiten eher schwer zu finden): „Why don’t you put it on Azure?“ [„Warum stellt ihr die App nicht einfach auf Microsoft Azure?“]

Erste Reaktion: „what are you talking about???“

Man erinnere sich, es war ca. Oktober oder November 2009 und wir hatten in unserem Bereich noch nie etwas von Microsoft Azure gehört!

Die Lösung! Zweiter und erfolgreicher Versuch!

Also beschäftigten wir uns mit Microsoft Azure – was damals etwas schwierig war, denn es gab dazu extern noch nichts, also keine Doku, keine Trials, keine … und intern sah es fast genauso aus.

Hinzu kam, dass auch für uns intern die Verwendung von Azure Diensten Geld kostet und – ich erwähnte es oben schon – wenn man genau 0€ Budget hat, dann sind auch die prognostizierten <$50 illusorisch.

Wir haben uns also auf die Suche gemacht und verschiedenste Ideen ausprobiert – und sind an allen Fronten gescheitert, zum einen, weil unterjährig irgendwo Budget zu „finden“ in jedem Unternehmen schwierig ist, zum anderen, weil das Gesamtkonstrukt so neuartig war, dass es auch nicht in einem Satz vermittelbar gewesen ist und es somit auch schlicht nicht verstanden wurde.

Jedoch (!) gab es natürlich dann auch innerhalb von Microsoft Deutschland Menschen, die auf die Vermarktung von Microsoft Azure angesetzt wurden – und genau hier haben wir ein – nein zwei offene Ohren gefunden!

In der damaligen DPE (Developer and Platform Evangelism, dem Vorgänger der DX und mit etwas Fantasie dem Vorgänger der OCP/GPS – Global Partner Solution) haben wir interessierte Kollegen gefunden, die uns nicht nur die notwendigen Azure Resourcen (zu der neuen Architektur siehe weiter unten), sondern auch das notwendige Know How für die Migration der LOB App in eine PaaS (Platform as a Service) App auf Azure zur Verfügung gestellt hatten.

Die Migration

Damals – Anfang 2010 – gab es in Azure noch keine IaaS. Das heißt, dass ein einfacher „Lift & Shift“ Ansatz überhaupt nicht möglich war und damit von vorneherein klar war, dass wir auf PaaS migrieren mussten!

Dazu haben wir uns an einem Dienstagnachmittag getroffen, die Architektur aufgemalt, die IIS Webservice App mit dem Azure SDK neu kompiliert, Kaffee getrunken, dabei die SQL DB exportiert und in SQL Azure importiert und dann länger einen Fehler gesucht, warum denn die App nicht funktionierte.
Funfact: der Fehler war eine hard-gecodete URL in Javascript („Doh!“), der Rest ging so durch, denn dadurch, dass wir komplett auf einer klassischen Microsoft Architektur aufgesetzt hatten, war auch der Switch zu einer Azure Webrole (ja, so hieß das damals!) überhaupt keine Herausforderung!

Damals sah die Architektur also so aus:

Wie man im Vergleich mit der ursprünglichen Architektur sieht hat sich letztlich nur die Ausführungsschicht von IIS->Azure Webrole und die DB von MSSQL zu SQL Azure gewandelt.

„nur“ – das ist (leider) nur die halbe Wahrheit. Denn zum damaligen Zeitpunkt unterstützte SQL Azure noch keine Volltext Suche („What??? :O“ )!

Wie gut, dass ich in der aller, aller, aller ersten Version der GPS noch nicht die MSSQL Volltextsuche genutzt hatte und „zum Glück“ ein Code Messi bin und den alten Such-Algorithmus nur auskommentiert hatte. Somit konnte ich den Code sehr schnell dahingehend anpassen wieder den alten Weg zu gehen und es hat damit tatsächlich nur diesen einen Dienstagnachmittag gedauert, bis die GPS von on-premises zu Azure PaaS migriert war.

Und am 19. April 2010 erblickte dann die GPS offiziell das Licht der Welt!

Was kam danach?

Eigentlich erstaunlich wenig! Denn der Vorteil von einem PaaS Dienst ist ja grade, dass der Entwickler sich nicht um die Infrastruktur kümmern muss und diese „einfach funktioniert“.

Jedoch hat sich natürlich auch Azure weiterentwickelt:

Zuerst kamen irgendwann (2013) die Azure Websites – und hier haben wir gerne geswitcht, da diese einen Kostenvorteil gegenüber einer klassischen Webrole hatte. Die Migration war unkritisch, da letztlich über das SDK und Visual Studio nur der andere Deploymentweg genutzt werden musste – und leider damit auch eine andere URL notwendig wurde.
Also die Webrole nur noch für das Weiterleiten auf die neue URL genutzt und go! [btw. ganz schön teure 301er! 😉 ]

Als nächstes bekam SQL Azure dann irgendwann (2015) die Volltextsuche als Feature hinzu – und – oh Wunder – ich hatte natürlich auch meinen alten Volltextsuche-Code nicht weggeschmissen und konnte damit sofort nach GA diese wieder aktivieren! 😀

Dann – und das war wirklich schmerzhaft – wurde SQL Azure von einer reinen Lizensierung basierend auf der DB Größe auf eine zusätzliche Lizensierung der DPUs erweitert – schmerzhaft deswegen, weil ohne diese DPU Messung (und Begrenzung) lief die DB und damit insbesondere auch die Stored Procedures auf voller Performance, was echt „geil“ war. [For the English translation – this got lost in translation – what it means is: „this was awesome!“]
Damit mussten wir uns also entscheiden: Geld vs. Performance! Und haben uns für einen gangbaren Mittelweg entschieden, so dass die GPS von nun an auf einer SQL Azure „S0“ [10DPUs] lief.

Die aktuelle Architektur

An der eigentlichen Architektur hat sich seitdem nicht mehr viel geändert.
Das hat zwei Gründe: 1. die verfügbare Zeit für eine Pflege/Weiterentwicklung der GPS und (viel wichtiger) 2.: geht doch auch so! 😉

Sprich aktuell läuft die GPS nach wie vor als Azure Website mit einer SQL Azure DB im Rücken.
Allerdings haben wir die 301er Webrole mittlerweile aufgelöst und nutzen das freigewordene Budget für eine cleverere Nutzung von Cloudinfrastruktur:

Aus den Performance Logs der Azure Webseite ergibt sich ein recht deutliches Bild, dass die Nutzung der GPS von den Arbeitszeiten von Indien/China, Europa und USA abhängt. [Was leider quasi rund um die Uhr bedeutet].
Jedoch sehen wir auch – und das war zu erwarten – eine geringere Nutzung am Wochenende.

Also läuft die SQL Azure DB von Montagmorgens 8h Neu Delhi Zeit bis Freitagabends 5pm PST auf einer S1 und am Wochenende auf der „alten“ S0 Performance. Und dies sogar zu einem günstigeren Preis als wenn die Webrole weitergelaufen wäre.
Dieses dynamische Wechseln habe ich über entsprechende Power Automate Scripte realisiert:

Und wen es interessiert, die passende Stored Procedure ist ziemlich einfach:

ALTER DATABASE [mydb] MODIFY (SERVICE_OBJECTIVE = 'S1');

HAPPY BIRTHDAY GPS!!!

Und als Geschenk zum 10. Geburtstag gibt es ein neues Kleid:

Feedback zum neuen Layout bitte über die FB Seite: https://aka.ms/GPSatFB

Update März 2023:

Durch den Einsatz von Azure OpenAI/ChatGPT konnten wir die Bottlenecks in den Stored Procedures identifizieren und beseitigen, so dass die GPS nunmehr ausschließlich auf einer S0 läuft – und das sogar merklich schneller, als früher auf der S1!!!
Siehe meinen Artikel dazu: Der ROI von ChatGPT und Copilot