Alexander Kastil

Früh kamen Data-Pipeline-Projekte mit dem SQL Server Integration Tooling dazu, geliefert nach Kundenspezifikation, als es noch keine Cloud-Infrastruktur gab. Danach bin ich mit ASP.NET und SharePoint in die Webentwicklung gewechselt. Beide renderten am Server, liefen auf derselben Platform und hingen immer stärker an JavaScript im Client. Deshalb habe ich mich auf Client-Side spezialisiert: Progressive Enhancement, touch-optimiertes HTML für den WebKit-Browser des iPhone 4 und Touch Events in Production, als es noch keine Mobile Frameworks gab.

Mit dem Postback-Modell stieß jede Interaktion an dieselbe Grenze. Die Touch-Interfaces für das iPhone 4, gebaut bevor es Zugang zum iOS SDK gab, haben gezeigt, dass der Browser schon als Application Runtime taugte, wenn man ihn so nutzte. Darauf baute die Arbeit der folgenden Jahre auf.

Mit SharePoint habe ich schon vor 2003 gearbeitet, parallel zur Infrastruktur. Vor 2007 habe ich die ersten SharePoint Development Classes geschrieben, zu Web Parts, Event Receivers und Content Types. Mein Schwerpunkt war das Solution Packaging: Mit WSP Builder ließen sich komplexe Deployments wiederholbar ausliefern, als es dafür noch kein ordentliches Tooling gab. Das hat diese Projekte von üblichen Intranet-Projekten unterschieden.

Das Postback-Modell von ASP.NET, auf dem SharePoint lief, schickte jede Interaktion zum Server und zurück. Das ging lange gut, irgendwann nicht mehr. Mit Office 365 und den Sandboxed Solutions fiel die serverseitige Option ohnehin weg, es blieb nur Client-Side. AngularJS kam zur passenden Zeit: Two-Way Binding ersetzte die manuelle DOM-Manipulation in den UIs der SharePoint-Projekte, und das Pattern hat sich so bewährt, dass es mein Standard wurde, bevor sich Microsoft selbst auf einen Weg festgelegt hatte. Die Erfahrung mit client-seitigem JavaScript in SharePoint war die Grundlage für die nächste Phase.

Der Übergang begann mit AngularJS in SharePoint. Als Angular 2 als frühe Beta erschien, bin ich umgestiegen, gleichzeitig mit der frühen Beta von .NET Core. Beides war instabil. Ich musste mich ernsthaft mit objektorientiertem JavaScript beschäftigen und dann mit TypeScript, das nah genug an C# war, um mich zu überzeugen. So wurde Angular mein Schwerpunkt, und zusammen mit Microsoft 365 und Azure konnte ich Sonderfälle lösen, bei denen Frontend Architecture und Enterprise Platform aufeinandertrafen. Nebenbei liefen Ionic und Hybrid Mobile: früh eingesetzt, mit instabilem Tooling, Cordova Pipelines und den Eigenheiten jeder Plattform, bevor sich das Ökosystem gefestigt hatte. Mit der Node.js Toolchain des SharePoint Framework habe ich Visual Studio Professional gegen VS Code und das Windows Subsystem for Linux als tägliche Entwicklungsumgebung getauscht.

Damit fiel die Bindung an die Platform weg, die bis dahin jede Entscheidung mitbestimmt hatte. Ab da war die Arbeit portabel und ließ sich kombinieren, passend zur Unix-basierten Infrastruktur, die Cloud-Native-Entwicklung braucht. Frontend und Cloud wuchsen zusammen, weil die Umgebung für beides taugte.

Von der Arbeit im Terminal war es ein kleiner Schritt zur Azure-Entwicklung. Als die COVID-19-Pandemie kam, war ich einer der wenigen zertifizierten Azure Developers und Azure DevOps Engineers, die in verteilten Umgebungen in Europa und im Nahen Osten arbeiteten. Ich habe verteilte Systeme auf Azure Container Apps entworfen, mit Dapr für Service-to-Service-Kommunikation, State Management und Distributed Application Patterns. .NET Aspire übernahm Orchestration und Observability der Microservices. CI/CD-Automatisierung und Infrastructure-as-Code waren in allen Projekten Standard.

Mit der Pandemie wurde aus einer Option eine Pflicht. Unternehmen, für die Cloud-Native-Infrastruktur eine Architekturfrage gewesen war, brauchten sie innerhalb weniger Wochen für den laufenden Betrieb. Sauber gebaute verteilte Systeme waren plötzlich für Business Continuity gefragt. Dass ich genau zu diesem Zeitpunkt in diesem Stack arbeitete, war das Ergebnis von sechs Jahren Aufbau an der Infrastruktur.

Mit Azure Cognitive Services bin ich zu AI gekommen. Daraus wurden zwei Stränge: Semantic Kernel, Copilot Studio und Microsoft Foundry für Agentic AI, und GitHub Copilot, im Einsatz seit dem ersten öffentlichen Release, für Agentic Software Engineering.

Heute führe ich beide im Microsoft Agent Framework zusammen: mehrstufige, autonome Workflows mit einer Architektur, die auf dreißig Jahren Microsoft Platform beruht. Anthropic Claude gehört fest zu diesem Stack.

Seit dreißig Jahren arbeite ich über Stack-Grenzen hinweg. Daher kommt der Name integrations.at.