Safeguarding your workloads with Microsoft’s own internal Linux Distro | Inside Azure for IT - YouTube

Channel: Microsoft Azure

[0]
Hi, ich bin Erin Chapple, CVP
[2]
von Azure Core Produkt and Design.
[4]
Willkommen zur dritten Folge von Inside
[6]
Azure für IT, in der
[7]
wir zwei meiner
[8]
Lieblingsthemen behandeln:
[10]
Open Source und Linux.
[12]
Open Source spielt
[13]
eine wichtige Rolle bei der
[15]
digitalen Transformation von Unternehmen.
[16]
Seit über einem Jahrzehnt,
[17]
setzt Microsoft bereits
[18]
auf einen Open Source-Ansatz
[20]
als Teil unserer eigenen Entwicklung
[21]
und als ein Mittel, Kunden, Partner
[23]
und Gemeinschaften durch Innovation zu verbinden.
[26]
Vergessen Sie bitte nicht, dass
[27]
das hier der zweite von drei
[29]
Teilen dieser Folge ist.
[30]
In Teil 1 sprach ich mit Red Hat
[32]
über unser gemeinsames Produktangebot
[34]
und unsere Zusammenarbeit darin,
[35]
Kunden bei Ihrer
[36]
Cloud-Modernisierung und
[38]
Migration zu helfen.
[39]
In Teil 3 spreche ich mit Sarah Novotny
[42]
über das Ausführen von Open Source
[43]
Technologien in der Cloud,
[45]
über die Beziehung
[46]
zwischen IT und Entwicklern
[47]
bei der Ermöglichung von Open Source-Innovationen
[49]
und Microsofts Führungsrolle bei der
[50]
und Beitrag zur Sicherung
[52]
von Open Source-Software.
[54]
In diesem Segment sprechen wir über
[56]
Mariner, Azures Linux-Distribution, die von
[58]
Entwicklern verwendet wird, um Services darauf zu entwickeln.
[60]
Wir teilen mit Ihnen,
[61]
welche Entscheidung hinter der
[62]
Erstellung unserer eigenen Linux-Distribution stand
[63]
und wie Entwickler und
[65]
Kunden davon profitieren.
[74]
Zuerst möchte ich zwei Menschen
[75]
in diesem Segment begrüßen,
[76]
denen Linux und die Open Source
[77]
Community alles andere als fremd ist.
[79]
Willkommen Krishna Ganugapati,
[80]
VP of Software Engineering bei
[82]
Edge OS,
[83]
und Brendan Burns, CVP von
[84]
Azure Cloud Native.
[86]
Vielen Dank, Erin.
[86]
Es ist wundervoll, persönlich hier zu sein.
[88]
Danke, Erin. Ich freue mich, hier sein zu können.
[90]
Wir arbeiten in einem so aufregenden
[91]
und wachsenden Bereich,
[92]
dass ich das Gefühl habe,
[93]
mich selbst weiterentwickelt
[95]
und die Evolution des Unternehmens
[96]
dahingehend gespiegelt zu haben,
[97]
wie wir über Linux und Open Source
[99]
nachdenken, dazu beitragen und es nutzen.
[101]
Am Anfang habe ich mich noch zu 100%
[103]
auf Windows und Windows Server konzentriert.
[105]
Dann habe ich gelernt, Upstream-Beiträge zu machen,
[107]
damit Linux gut auf Hyper-V laufen kann,
[109]
und inzwischen stehen Open Source und Linux
[110]
im Mittelpunkt der Entwicklung von Azure.
[113]
Dieser Wandel wurde sowohl
[114]
von Kunden und ihren
[116]
Bedürfnissen als auch
[117]
von den internen Entwicklungsteams
[119]
und ihren Bedürfnissen angetrieben.
[121]
Einige der Zuschauer wissen
[122]
vielleicht nicht, dass es sich bei bestimmten
[124]
Azure-Services um verwaltete
[125]
Open Source-SaaS-Angebote handelt,
[127]
wobei der Azure Kubernetes Service
[128]
einer der größten davon ist.
[130]
Tatsächlich verwenden wir bei
[131]
bei Microsoft eine Linux-Infrastruktur
[132]
zum Erstellen und Ausführen von Programmen.
[134]
Krishna, könntest du uns jetzt
[135]
erzählen, wie wir uns diesem Bereich
[137]
angenähert haben und was das für
[139]
interne Engineering-Teams bedeutet?
[140]
Danke, Erin. Nun, wie du gerade gesagt hast,
[142]
wissen viele Leute nicht,
[143]
wie viele Kunden-Workloads auf
[144]
internen Linux-Services laufen.
[147]
Das bedeutet, dass wir zum Schutz
[148]
der Kunden-Workloads auch diese internen
[150]
Linux-Services schützen müssen.
[152]
Unsere internen Engineering-Teams
[154]
haben uns das deutlich klar gemacht
[155]
und gesagt, dass wir
[157]
eine einheitliche, standardisierte
[158]
und sichere Linux-Distribution benötigen,
[160]
die sie als ein Ingredient-OS benutzen können.
[162]
Deshalb haben wir Mariner erschaffen.
[164]
Es ist unsere interne Linux-Distribution
[166]
für unsere First Party-Services.
[168]
Du hast Standardisierung als einen
[170]
treibenden Faktor erwähnt.
[171]
Lass uns näher auf die Entscheidung eingehen,
[174]
unsere eigene interne Distribution zu erstellen.
[176]
Das ist nämlich eine Frage,
[176]
die mir oft von Kunden gestellt wird,
[178]
die sich für unseren Ansatz interessieren.
[180]
Nun,
[180]
könntest du erklären, warum
[181]
wir uns dafür entschieden haben,
[182]
anstatt ein fertiges Produkt zu verwenden?
[185]
Natürlich sollte erwähnt werden,
[187]
dass viele unserer Services
[188]
bereits fertige Distributionen verwenden
[190]
und das auch so bleiben wird.
[192]
Aber als eine Hyperscale-Cloud,
[193]
haben wir eine sehr vielseitige Reihe an
[195]
Anforderungen und Szenarien,
[197]
wobei wir einige dieser
[198]
Szenarien nicht immer mit
[200]
vorgefertigten Distributionen umsetzen können.
[202]
Und bevor wir beschlossen haben, unsere eigene
[204]
interne Linux-Distribution zu entwickeln,
[205]
haben wir eine umfassende Studie der Dinge durchgeführt,
[207]
die Azure-Services brauchen würden.
[210]
Wir haben daraus gelernt, dass
[212]
es vor allem darauf ankommt, wie wir
[214]
die Qualität unserer Azure-Services verbessern
[216]
und wie wir die Bereitstellung
[217]
unserer Azure Linux-Services
[218]
beschleunigen können.
[221]
Obwohl es viele Faktoren gibt,
[222]
möchte ich mich vor allem auf zwei Gründe konzentrieren,
[224]
weshalb eine interne Distribution Sinn gemacht hat.
[228]
Den ersten Grund bezeichne ich gerne als
[229]
"Gerade genug OS" oder als den "Kleinen Fußabdruck".
[232]
Ich arbeite schon ziemlich lange
[233]
als ein OS-Entwickler
[234]
und ich liebe Betriebssysteme.
[237]
Aber ich habe auch gelernt, dass
[238]
das beste Betriebssystem das ist,
[240]
welches man nicht sieht.
[242]
Das heißt, man braucht ein
[243]
Betriebssystem, das gerade groß genug ist,
[244]
um den gewünschten Service auszuführen.
[246]
Es ist so: Je größer das OS,
[247]
das man benutzt, umso schwieriger ist es,
[248]
es zu verwalten.
[250]
Aber je kleiner der Fußabdruck des OS ist,
[251]
umso besser ist seine Verwaltbarkeit.
[253]
Und das bedeutet im Umkehrschluss auch
[255]
eine bessere Sicherheitsgewährleistung.
[256]
Bei der Entwicklung von Mariner,
[258]
war das eines unserer
[259]
zentralen Ziele:
[261]
Wir wollten die Möglichkeit haben,
[262]
mit dem kleinstmöglichen OS-Fußabdruck anzufangen
[264]
und später alles zu ergänzen, was zum
[265]
Ausführen von Anwendungen gebraucht wird.
[267]
Der nächste große Faktor ist Sicherheit.
[269]
Und es gibt sehr viele
[270]
Aspekte der Sicherheit,
[271]
aber ich möchte besonders über zwei davon sprechen.
[274]
Die Einfachheit des Patchings und Compliance.
[277]
Es ist für uns von größter
[278]
Bedeutung, zu gewährleisten,
[278]
dass unsere Kunden-Workloads
[280]
immer geschützt sind.
[281]
Um das zu erreichen,
[282]
müssen wir dafür sorgen, dass Sicherheitsschwächen
[284]
sobald sie upstream bekannt sind,
[285]
so schnell wie möglich
[287]
gepatcht werden können.
[289]
Das Buildsystem von Mariner
[290]
führt durchgehend Prüfungen
[291]
auf Sicherheitsschwächen von
[293]
Upstream-Projekten durch
[294]
und wir patchen
[295]
die Distribution in Echtzeit.
[297]
Compliance ist ein weiterer wirklich großer
[299]
und wichtiger Bereich für uns.
[301]
Wir wollen sicherstellen, dass
[301]
all unsere Linux-Services auf
[303]
einer Plattform ausgeführt werden, die
[304]
konsistent die Anforderungen für alle
[306]
obligatorischen Sicherheitszertifikate erfüllt.
[308]
Das sind nur zwei der Erwägungen,
[310]
wegen denen wir gesagt haben:
[311]
„OK, ich denke, wir sollten wirklich darüber nachdenken
[313]
unsere eigene Linux-Distribution
[315]
für unsere internen Services zu erstellen.“
[317]
Und das alles bedeutet
[318]
letzten Endes auch
[320]
schnellere Funktionen und
[321]
weniger Überraschungen für Entwickler
[323]
und Support-Teams.
[325]
Aber gehen wir nun vom Team,
[326]
das unsere Linux-Distribution verwaltet,
[328]
zu den Teams über, die darauf entwickeln.
[329]
Nun, Brandon, als ein Kunde
[331]
und Partner von Mariner –
[332]
welche Erfahrungen hat das Team
[333]
beim Entwickeln auf Mariner gemacht?
[336]
Oh, es war wirklich fantastisch
[337]
ein Team zu haben, das sich
[338]
auf ein Linux-Betriebssystem
[340]
für Azure konzentriert hat
[342]
und für uns ein echter Partner darin war,
[344]
Services auf Linux bereitzustellen.
[347]
Man hat ein bestimmtes Maß an
[348]
Konsistenz und Verlässlichkeit,
[350]
wenn man weiß,
[350]
dass alles,
[351]
was das Team tut,
[352]
auf deine Services und die Dinge
[354]
konzentriert ist, die du versuchst,
[356]
deinen Kunden zu bieten.
[357]
Letzten Endes hilft uns diese
[359]
Optimierung der Distribution für Azure dabei,
[361]
bessere Arbeit zu leisten.
[363]
Ihr beide habt Zuverlässigkeit erwähnt.
[365]
Ein unzuverlässiges System
[366]
kann die Geschäftskontinuität
[367]
für Entwickler und Endkunden
[369]
stark beeinträchtigen
[370]
und zu Serviceausfällen führen.
[372]
Deshalb tun wir bestimmte Dinge,
[374]
um die Verlässlichkeit der Plattform
[375]
für Mariner zu gewährleisten.
[376]
Krishna, kannst du uns mehr darüber erzählen?
[378]
Natürlich.
[379]
Die Zuverlässigkeit der Plattform
[380]
ist ausschlaggebend für das Buildsystem von Mariner.
[382]
Ich möchte hierbei drei Dinge ansprechen.
[384]
Erstens wurde die Build-Pipeline
[386]
so konstruiert, dass
[387]
sie problemlos mehrere Tests integrieren kann.
[390]
Wir versuchen wo immer wir können
[391]
das Shift-Left-Prinzip anzuwenden.
[393]
Wie können wir Probleme identifizieren und beheben,
[395]
lange bevor sie in der Produktion landen?
[397]
Zweitens haben wir
[399]
stark in unsere Update-Mechanismen
[400]
und die Erstellung zuverlässiger
[402]
Rollback und Rollforward-Mechanismen investiert.
[404]
Drittens sind die Build Gates von Mariner so automatisiert,
[406]
dass sie die Weiterleitung
[407]
fehlerhafter Builds verhindern.
[409]
Auf diese Weise können wir schnell reagieren,
[411]
aber mit dem Wissen,
[412]
dass Produktionsbereitstellungen
[413]
nicht beeinträchtigt werden.
[415]
Damit soll erreicht werden,
[416]
dass wenn wir alles richtig machen,
[417]
Kunden-Workloads vor allen
[419]
möglichen Auswirkungen stark isoliert sind.
[421]
Und Brandon – auch wenn
[422]
Mariner ist für die interne Nutzung gedacht ist,
[424]
profitieren davon letztendlich die Kunden,
[426]
weil sie stabile Services
[428]
und ein optimales Erlebnis erhalten.
[430]
Du hast vollkommen recht, Erin.
[432]
Wir können mit Krishna und seinem
[433]
Team zusammenarbeiten, um Patches zu finden,
[435]
die in Mariner integriert werden müssen.
[437]
Aber wir können auch einen
[440]
Ansatz verwenden, der den Upstream priorisiert
[441]
und bei dem wir die Patches
[442]
wie ein Open Source-Projekt behandeln,
[443]
das wie eines der vielen Open Source
[445]
Projekte ist, die wir nutzen.
[447]
Und die Kunden sollten spüren, dass
[448]
die Plattform, die wir nutzen, wie Krishna
[450]
schon gesagt hat, das kleinstmögliche OS ist.
[453]
Es ist unsichtbar.
[454]
Und die Kunden möchten nur wissen,
[455]
dass wir Ihnen einen besseren,
[455]
verlässlicheren Service mit schnelleren
[457]
Verbesserungen bieten.
[459]
Nun, Brendan, da Mariner
[460]
inzwischen auf GitHub ist,
[461]
auch wenn es eine Plattform ist, die
[463]
für Microsofts internen Gebrauch erstellt wurde –
[464]
kannst du uns mehr darüber erzählen,
[466]
was die Gründe für die Veröffentlichung waren?
[467]
Klar. In erster Linie ist Github,
[469]
natürlich, ein wundervoller Ort,
[470]
um Software zu entwickeln, nicht wahr?
[472]
Deshalb denke ich, dass wir
[473]
auf jeden Fall in GitHub arbeiten werden.
[474]
Die einzige offene Frage ist dann,
[475]
ob das Projekt als
[476]
privat oder öffentlich markiert wird.
[477]
Und meiner Meinung nach spielt
[480]
die Privatheit keine große Rolle darin,
[482]
ein Mariner zu sein.
[483]
Wir möchten diese Art von Transparenz haben.
[485]
Denn Mariner existiert als Teil
[487]
der Linux-Community als Ganzes,
[487]
in der es sehr viele
[489]
unterschiedliche Distributionen gibt.
[491]
Und ich glaube auch, dass unsere Kunden
[493]
immer mehr wollen, dass wir ihnen helfen
[494]
zu verstehen, was
[496]
es mit Open Source
[496]
wirklich auf sich hat.
[497]
Deshalb schauen sie sich
[499]
unseren Arbeitsansatz an und
[500]
sagen nicht
[501]
„okay, was können wir als
[503]
Open Source behandeln“, sondern eher
[504]
„weshalb sollte das
[505]
nicht Open Source sein“?
[507]
Ich denke, dass sie bei uns nach
[508]
Hilfe für die selbe Art
[509]
von Problemen suchen.
[511]
Und im Laufe der Jahre
[512]
haben wir wirklich viel
[514]
in die Verbesserung unserer Zusammenarbeit
[516]
mit der Open-Source-Community investiert.
[517]
Nicht nur, um zu sagen, dass wir
[519]
Open Source verstehen, sondern um
[521]
zu zeigen, dass wir über die richtigen Grundlagen
[522]
und die Philosophie verfügen, dass eigentlich
[524]
alles Open Source sein sollte.
[527]
Um die Rolle zu verstehen, die
[528]
Microsoft bei Open Source
[529]
Initiativen gespielt hat,
[530]
schauen Sie sich das dritte
[531]
Segment dieser Folge an,
[532]
in dem ich mit Sarah Novotny rede,
[534]
der Leiterin der Open Source
[535]
Strategie für Azure.
[537]
Zurück zu dir, Krishna.
[538]
Was sind die zukünftigen Entwicklungen für Mariner?
[540]
Nun, Erin, das ist für uns eine Evolution,
[542]
bei der wir erst kriechen, dann gehen, dann rennen.
[545]
Und ich glaube, wir fangen gerade an zu gehen,
[546]
mit festem Schritt, hoffe ich,
[548]
aber wir beginnen zu gehen.
[550]
Im Moment haben wir damit zu tun,
[552]
unseren internen Kunden beim
[553]
anfänglichen Setup zu helfen,
[554]
und das ist einiges an Arbeit.
[556]
Wir erhalten manchmal bereits Anfragen dazu,
[558]
ob Mariner nicht eine Distribution für den
[560]
allgemeinen Gebrauch sein könnte, aber
[561]
da unsere Kunden
[562]
bereits durch das großartige Angebot
[563]
unserer Distributionspartner gut bedient sind,
[565]
werden wir vor allem auch weiterhin
[566]
dafür sorgen, dass
[567]
unsere Partner-Distributionen immer
[568]
so gut wie möglich auf Azure laufen können.
[571]
Und was die Zukunft angeht,
[573]
müssen all unsere Pläne sich
[574]
daran orientieren,
[575]
was unsere Kunden brauchen
[577]
und wie Microsoft diese Bedürfnisse
[578]
am besten Erfüllen kann?
[580]
Und um das besser zu verstehen –
[581]
Brendan hat bereits darüber gesprochen –
[583]
haben wir die Mariner Quellverzeichnisse
[584]
öffentlich gemacht.
[587]
Die gesamte Entwicklung ist transparent
[589]
und die Mariner ISOs sind frei verfügbar.
[592]
Das bedeutet zwei Dinge.
[594]
Erstens können Kunden
[595]
Mariner nach Herzenslust ausprobieren.
[597]
Sie können es erstellen,
[597]
sie können es ausführen
[598]
und besser informiert sein und
[600]
sie können selbst sehen,
[600]
ob es etwas gibt,
[601]
das Mariner tun kann oder sollte.
[603]
Unsere Kunden
[603]
sind eben
[605]
unsere besten Lehrer.
[606]
Zweitens – und vor allem –
[608]
und Brendan hat das bereits angesprochen,
[609]
geht es dabei um Transparenz.
[611]
Es gab viele Fragen, viel
[613]
Interesse, Aufregung und Spekulation.
[616]
Alles öffentlich
[617]
verfügbar zu machen,
[618]
erlaubt es allen –
[619]
unseren Kunden, unseren Partner
[621]
und unseren Stakeholdern, sich selbst
[623]
mit Mariner vertraut zu machen
[624]
und direkt von uns zu hören.
[626]
Und wir können unsere Kunden auch hören.
[629]
Krishna, Brendan,
[630]
es war wunderbar, dass ihr Teil der Show wart.
[632]
Wie ich höre, seid ihr beide Redner
[633]
beim Azure Open Source Day am 15. Februar.
[635]
Ich freue mich darauf, euch dort zu sehen.
[637]
Vielen Dank, Erin.
[638]
Danke, Erin. Ich habe mich gefreut, hier zu sein.
[639]
Es war toll, euch persönlich zu sehen.
[641]
Ebenfalls.
[642]
Und wenn Sie sich Fragen, warum wir es
[644]
Mariner nennen, werden Brendan und Krishna,
[646]
diese Geschichte in ihrer
[647]
Sitzung beim
[648]
Azure Open Source Day erzählen.
[649]
Registrieren Sie sich dafür über den unteren Link.
[652]
Und vergessen Sie nicht,
[653]
sich auch die anderen Segmente
[654]
dieser Folge von Inside Azure für IT anzusehen.
[657]
Wir reden mit Mike Evans
[657]
und Xavier Lecauchois von Red Hat
[659]
und diskutieren Open Source
[661]
mit Sarah Novotny.
[662]
Und für all unsere Videos, Analysen
[664]
und Schulungsinhalte,
[665]
gehen Sie zu
[666]
Azure.com/InsideAzureforIT.
[668]
Bis zum nächsten Mal.