Alexander Kastil

Early on came data pipeline projects with SQL Server integration tooling, delivered to client specification before cloud infrastructure existed. Then I moved into web development with ASP.NET and SharePoint. Both rendered on the server, ran on the same platform, and leaned more and more on JavaScript in the client. So I specialized in the client side: progressive enhancement, touch-optimized HTML for the iPhone 4’s WebKit browser, and touch events in production before mobile frameworks existed.

With the postback model, every interaction hit the same limit. The touch interfaces for the iPhone 4, built before there was access to the iOS SDK, showed that the browser already worked as an application runtime if you used it as one. The work of the following years built on that.

I worked with SharePoint before 2003, alongside the infrastructure work. Before 2007 I wrote the first SharePoint development classes, on web parts, event receivers, and content types. My focus was solution packaging: WSP Builder made complex deployments repeatable before proper tooling existed. That set my projects apart from typical intranet work.

The ASP.NET postback model that SharePoint ran on sent every interaction to the server and back. That worked for a long time, then it stopped working. With Office 365 and sandboxed solutions, the server-side option disappeared anyway, which left the client side. AngularJS arrived at the right time: two-way binding replaced manual DOM manipulation in the SharePoint project UIs, and the pattern held up well enough to become my default before Microsoft itself had settled on an approach. The next phase grew out of that client-side JavaScript work in SharePoint.

The transition started with AngularJS inside SharePoint. When Angular 2 came out as an early beta, I switched, at the same time as the early .NET Core beta. Both were unstable. I had to get serious about object-oriented JavaScript and then TypeScript, which was close enough to C# to win me over. Angular became my focus, and together with Microsoft 365 and Azure I could solve edge cases where frontend architecture met the enterprise platform. Ionic and hybrid mobile ran alongside: adopted early, with unstable tooling, Cordova pipelines, and the quirks of each platform, before the ecosystem settled. With the SharePoint Framework’s Node.js toolchain I swapped Visual Studio Professional for VS Code and Windows Subsystem for Linux as my daily development environment.

That removed the platform dependency that had shaped every decision until then. From then on the work was portable and composable, a fit for the Unix-based infrastructure that cloud-native development needs. Frontend and cloud grew together because the environment suited both.

From working in the terminal, Azure development was a small step. When the COVID-19 pandemic hit, I was one of the few certified Azure Developers and Azure DevOps Engineers working across distributed environments in Europe and the Middle East. I designed distributed systems on Azure Container Apps, with Dapr for service-to-service communication, state management, and distributed application patterns. .NET Aspire handled orchestration and observability across the microservices. CI/CD automation and infrastructure-as-code were standard on every project.

The pandemic turned an option into a requirement. Companies that had seen cloud-native infrastructure as an architecture question needed it for day-to-day operations within a few weeks. Well-built distributed systems were suddenly in demand for business continuity. I was in exactly this stack at that moment because of six years of infrastructure work.

Azure Cognitive Services got me into AI. Two tracks grew out of that: Semantic Kernel, Copilot Studio, and Microsoft Foundry for agentic AI, and GitHub Copilot, in use since its first public release, for agentic software engineering.

Today I bring both together in Microsoft Agent Framework: multi-step autonomous workflows with an architecture based on thirty years of the Microsoft platform. Anthropic Claude is an essential part of that stack.

For thirty years I have worked across stack boundaries. That is where the name integrations.at comes from.