Microsoft Build 2019: Die Roadmap, die eine Firma in Gang setzte

8. Mai 2019

  • Startseite
  • Blog
  • Microsoft Build 2019: Die Roadmap, die eine Firma in Gang setzte
Microsoft Build 2019: Die Roadmap, die eine Firma in Gang setzte

6.–8. Mai 2019, Washington State Convention Center, Seattle. Die letzte vollständig vor Ort durchgeführte Build vor der Pandemie – und aus dem Rückblick von 2026 eine der folgenreichsten Keynotes, die Microsoft im letzten Jahrzehnt gehalten hat. Sie wirkte nicht wie eine Produktshow. Sie wirkte, als zöge Microsoft ein Entwicklerpublikum eng an sich heran und drückte ihm eine Landkarte der nächsten fünf Jahre in die Hand, mit der unausgesprochenen Anweisung: Hier, halte das eine Weile fest.

Wir schauten sehr genau hin, denn wir waren zehn Wochen alt. ThreeB IT war am 1. März 2019 gegründet worden, und fast jede strategische Wette, die wir gerade platziert hatten – beim Microsoft-Stack bleiben, bauen und betreiben, Windows und .NET als Produktionsplattform ernst nehmen –, würde auf einer Bühne in Seattle entweder bestätigt oder leise widerlegt werden. Sie wurde bestätigt. Und zwar gründlich.

Die Skyline von Seattle mit der Space Needle in der Dämmerung, der Austragungsstadt der Microsoft Build 2019

„Vertrauen als Design-Prinzip"

Satya Nadella eröffnete nicht mit einem Feature, sondern mit einem Rahmen. Das wiederkehrende Wort der Keynote war weder „KI" noch „Cloud" – es war Vertrauen. Der Satz, der bei uns hängen blieb, klang fast eher nach einer Ingenieursanweisung als nach einem Slogan:

„Trust in everything that we build, in the technology we build, is so core." — Satya Nadella, Build-2019-Keynote

Er stellte ihm einen schärferen zur Seite – „privacy is a human right as much as it is an engineering design principle" – und die Idee unter beiden war die, die er seit ein paar Jahren umkreiste: Wenn Computing sich in alles um uns herum auflöst, dürfen die, die Plattformen bauen, Vertrauen nicht als Marketing-Nachgedanken behandeln. Es muss im Entwurfsprozess wohnen, neben dem Datenmodell und dem Bedrohungsmodell.

Für eine zwei Monate alte Firma, die gerade entschied, was für ein Laden sie sein wollte, traf das hart. Wir bauen für Branchen, in denen ein Bug keine kosmetische Regression ist – sondern ein verpasster Export, eine fehlgeschlagene Zahlung, ein Compliance-Befund. Den CEO der Plattform, auf die wir gewettet hatten, auf der Bühne sagen zu hören, dass Vertrauen in den Kern-Entwurfsprozess gehört und nicht in die Pressemitteilung, war die Erlaubnis, auf die wir, ohne es zu wissen, gewartet hatten. Es ist ein Satz, nach dem wir seither still eine Firma führen.

Windows lernte Linux lieben – diesmal richtig

Die Ankündigung mit der lautesten, ehrlichsten Entwicklerreaktion war WSL 2: das Windows Subsystem für Linux, neu aufgebaut auf einem echten Linux-Kernel, der zum ersten Mal innerhalb von Windows ausgeliefert wird, statt der System-Call-Übersetzungsschicht, die WSL 1 benutzt hatte.

Das war kein Detail, das man zur großen Sache aufblies. Es war umgekehrt. WSL 1 war clever, aber undicht – alles, was den Kernel auf ungewöhnliche Weise berührte, neigte zum Brechen, was in der Praxis Docker hieß. WSL 2 reparierte das Fundament. Microsoft verpflichtete sich, einen echten, quelloffenen Linux-Kernel auszuliefern (zunächst 4.19), abgestimmt auf eine leichtgewichtige Utility-VM und über Windows Update gewartet. Die Leistungszahlen auf der Leinwand waren von der Art, die man normalerweise nicht ehrlich behaupten kann:

  • Bis zu 20× schneller beim Entpacken eines gezippten Tarballs, gegenüber WSL 1.
  • 2–5× schneller bei alltäglichen Entwickleroperationen – git clone, npm install, cmake.
  • Natives Docker – der echte Linux-Build, der endlich in Windows läuft, weil die System-Call-Kompatibilität endlich vollständig war.

Für uns war das der Unterschied zwischen einem Windows, das man für Linux-Arbeit ertrug, und einem, das man tatsächlich wählen würde. Unsere ganze Botschaft lautet „auf dem Microsoft-Stack bauen, ohne etwas aufzugeben". WSL 2 löschte einen der letzten ehrlichen „Aber"-Sätze aus diesem Versprechen.

Ein Entwickler-Terminal mit mehreren Tabs, in denen verschiedene Shells nebeneinander laufen

Ein Terminal, das man tatsächlich nutzen konnte

Direkt neben WSL 2 kam Windows Terminal, und der Saal verstand sofort, warum das zählte. Jahrelang war die Windows-Konsole der peinliche Verwandte beim Familienessen gewesen – funktional, uralt, allergisch gegen alles Unicode. Das neue Terminal war ein sauberer Bruch:

  • Tabs, jeder mit dem verbunden, was man wollte – Eingabeaufforderung, PowerShell, eine Ubuntu-Shell auf WSL, einen Raspberry Pi über SSH.
  • Eine GPU-beschleunigte DirectWrite/DirectX-Textrendering-Engine, die CJK-Zeichen, Emoji, Powerline-Symbole, Icons und Programmier-Ligaturen mühelos zeichnete.
  • Einstellungen in einer strukturierten Textdatei, Profile, eigene Schriften, Farben, Transparenz.
  • Open Source, auf GitHub, samt Konsolen-Kern.

Den Teil „Open Source, auf GitHub" überliest man heute leicht, und 2019 war er ein echtes Statement. Die Firma, die ihren Quellcode einst wie Kronjuwelen behandelte, lieferte ihr Terminal – und ihre Konsole – offen aus und lud zu Pull Requests ein. Diese Haltung sagte uns mehr als jedes einzelne Feature, dass der Kulturwandel bei Microsoft echt war und keine Konferenzfolie.

Die Wette des Jahrzehnts: ein .NET

Am selben Tag legte Microsoft, in einer Entwickler-Session und einem Blogbeitrag von Programm-Manager Richard Lander, den Schritt dar, auf dem alles ruht, was wir heute tun: .NET 5. Der Plan war, .NET Framework, .NET Core, Xamarin und Mono – vier Linien, die in ein verwirrendes Gewirr abgedriftet waren – zu einer einzigen .NET-Plattform zusammenzuführen, einer Runtime und einem Satz Bibliotheken, anvisiert für November 2020.

Schon die Namensgebung erzählte die Geschichte: Man übersprang „.NET Core 4", um die Kollision mit dem Windows-only .NET Framework 4.x zu vermeiden, und ließ das Suffix „Core" ganz fallen. Die Botschaft war es gibt von nun an nur ein .NET. Eine Runtime überall – Desktop, Web, Cloud, Mobile – mit einheitlichem Verhalten und einer einzigen Entwickler-Erfahrung.

Wir wollen bei der Chronologie präzise sein, weil sie wichtig ist: Die einheitliche .NET-5-Vision wurde rund um die Build 2019 dargelegt (der öffentliche Blogbeitrag erschien am 6. Mai 2019, dem Eröffnungstag der Konferenz), und die Plattform selbst kam im November 2020. Wir beschreiben hier eine Roadmap-Ankündigung, kein fertiges Produkt vom Stand.

Aber diese Roadmap ist, mehr als jede andere einzelne Entscheidung, der Grund, warum ThreeB IT seine technische Zukunft mit gutem Gewissen auf diesen Stack setzte. Die Zersplitterung der .NET-Welt war ein echter Grund zur Vorsicht gewesen. Microsoft sich öffentlich und mit Datum dazu verpflichten zu sehen, diese Zersplitterung zu beenden, räumte den größten Einwand aus, den wir gegen ein volles Bekenntnis hatten. Sechs Jahre später läuft jedes Produkt, das wir ausliefern, auf der Plattform, zu der diese Vision wurde.

Ein Whiteboard voller Architektur-Skizzen und einer Roadmap-Zeitleiste

Fluid, Edge und ein früher Blick auf Agenten

Zwei weitere Ankündigungen sind es wert, herausgegriffen zu werden – eine, weil sie strategisch interessant war, und eine, weil sie im Rückblick eine leise Vorschau auf alles war, was die Build sieben Jahre später beherrschen würde.

Fluid Framework war Microsofts Versuch, das Dokument zu sprengen. Statt dass eine Datei ein Monolith im Besitz einer App ist, schlug Fluid ein webbasiertes, komponentisiertes Dokumentmodell vor: Inhalt in kollaborative Bausteine zerlegen, sie mit hoher Geschwindigkeit und Skalierung gemeinsam bearbeiten und über Anwendungen hinweg neu zusammensetzen. Am bemerkenswertesten im Rückblick war die dritte Säule – Fluid machte ausdrücklich Platz für intelligente Agenten, die neben Menschen arbeiten, Text übersetzen, Inhalte holen, Änderungen vorschlagen und Compliance-Prüfungen im Dokument durchführen. Lesen Sie diesen Satz noch einmal mit den Augen von 2026. Die Agenten-Geschichte, um die Microsoft heute ganze Konferenzen baut, hatte auf der Build-2019-Bühne einen klar erkennbaren Vorfahren.

Chromium-basiertes Edge wurde ebenfalls gezeigt – ein neu gebauter Browser auf der Chromium-Engine, mit einem Internet-Explorer-Modus für betagte Unternehmensseiten, Collections und besseren Datenschutz-Standards. Für diejenigen unter uns, die Branchenanwendungen pflegen, die irgendein Kunde irgendwo noch im IE öffnet, war das IE-Modus-Versprechen weniger aufregend und mehr zutiefst praktisch beruhigend.

Unter allem hämmerte Nadella weiter das Thema Plattform-Offenheit – „.NET und Java sind erstklassig, SQL und Postgres sind erstklassig" – und positionierte Azure als „den Computer der Welt". Offen per Voreinstellung, mehrsprachig, multi-datenbank. Auch das passte zu der Firma, die wir bauen wollten: nah an Microsoft, aber nicht eingesperrt.

Warum es für uns zählte

Hier kommt der Teil, der sich noch immer leicht unwahrscheinlich anfühlt, wenn wir ihn aussprechen.

ThreeB IT war seit etwa zwei Monaten eine juristische Person, als diese Keynote lief. Wir hatten einen niedergeschriebenen Plan, einen gewählten Stack und die gewöhnliche, leise Nervosität einer brandneuen Firma, die sich fragt, ob sie aufs richtige Pferd gesetzt hat. Und dann stand, über drei Tage in Seattle, das größte Softwareunternehmen der Welt auf und zeichnete – detailliert, mit Daten – genau die Welt, in der wir uns zu bauen entschieden hatten.

Ein .NET. Wir hatten uns auf .NET festgelegt; Microsoft legte sich darauf fest, es zu vereinen.

Windows, das Linux ohne Kompromiss ausführt. Wir wollten auf Windows bauen, ohne uns dafür zu entschuldigen; WSL 2 nahm die Entschuldigung weg.

Vertrauen als Ingenieursprinzip, nicht als Pressemitteilung. Wir hatten uns entschieden, Branchen zu bedienen, in denen Korrektheit die ganze Aufgabe ist; Nadella stellte diesen Wert ins Zentrum der Keynote.

Offen per Voreinstellung – .NET und Java, SQL und Postgres, alles erstklassig. Wir wollten nah an einem Anbieter bleiben, ohne von ihm gefangen zu sein; Microsofts Offenheit machte das zu einer schlüssigen Position statt zu einem Widerspruch.

Die strategischen Wetten, die wir am 1. März 2019 platziert hatten, bekamen zehn Wochen später ihre Bestätigung – von der Bühne. Das ist nicht der Grund, warum wir sie platziert haben – man gründet keine Firma in der Hoffnung, dass eine Keynote einem zustimmt –, aber es lässt sich kaum überschätzen, was es mit dem Selbstvertrauen eines jungen Teams macht, den Plattform-Eigner unabhängig bei der eigenen These ankommen zu sehen. Wir brauchten die Bestätigung nicht, um weiterzumachen. Wir waren trotzdem sehr froh, sie zu haben.

Es gibt eine Linie von jenem Raum 2019 zu dem Punkt, an dem wir heute stehen. Wir waren auf jeder Build seit 2012, und die, die in Erinnerung bleiben, sind nicht die mit der schillerndsten Demo – sondern die, bei denen die Richtung an ihren Platz rastet. 2019 war eine davon. WSL 2 und Windows Terminal machten unsere tägliche Arbeit noch im selben Jahr besser. .NET 5 wurde das Fundament unter jedem Produkt, das wir später ausliefern würden, Xircuit und Outastory inklusive. Und die Agenten-Idee, die in Fluid Framework steckte, erwies sich als Keim des ganzen Jahrzehnts, das folgte.

Build 2019 zeigte nicht nur ein bisschen Software. Für eine zehn Wochen alte Firma in Ibbenbüren bestätigte sie die Landkarte. Wir navigieren seither nach ihr.

Eine Anmerkung zur Chronologie: Die einheitliche .NET-5-Vision wurde am 6. Mai 2019 veröffentlicht, dem Eröffnungstag der Build, und die Plattform selbst kam im November 2020 – wir beschreiben sie hier als die Roadmap-Ankündigung, die sie war. Die Leistungszahlen für WSL 2 sind Microsofts eigene veröffentlichte Benchmarks aus der Ankündigung.

Bildnachweise

Alle Fotos werden unter ihren jeweiligen Creative-Commons-Lizenzen verwendet; wir danken den Fotografen.

  • Seattle 3 — © Daniel Schwen, CC BY-SA 4.0, via Wikimedia Commons (source).
  • Arch Linux system update via pacman on an Acer laptop — © Solijon Solayev, CC BY-SA 4.0, via Wikimedia Commons (source).
  • Important whiteboard diagram - save! — © pepperlime, CC BY-SA 2.0, via Flickr (source).
Microsoft Build .NET WSL Windows Terminal Azure Fluid Framework Edge Build 2019
ZUM BLOG