Ich hatte letzte Woche die Gelegenheit, nach London zu reisen, um am AWS Enterprise Summit (6. Juli) und AWS Summit (7. Juli) teilzunehmen. Als ehemaliger Mitarbeiter von Amazon (vor AWS) und Microsoft Azure war es faszinierend, einen Schritt zurückzutreten und zu sehen, wie weit diese ganze „Cloud“-Geschichte wirklich gekommen ist. Hier sind einige wichtige Erkenntnisse, die ich von einer großartigen Show mitgenommen habe.

#1) Die (richtige) Migration in die Cloud erfordert die Einführung einer DevOps-Kultur
Das hat mir sehr gefallen Stephen Orban (Leiter der globalen Unternehmensstrategie und Eröffnungsredner beim Enterprise Summit des ersten Tages) sprang gleich auf diesen Punkt ein: Ihr Infrastrukturteam MUSS zu einem Cloud Center of Excellence werden und beginnen, die operative Verantwortung von oben nach unten auf die Produkt-/Dienstleistungsteams, das interne IT-Team und das Desktop-Supportteam zu verteilen.

Ich zitiere oft Werner Wogels (CTO von Amazon.com und der jeden Tag eine Keynote hielt) in meinen eigenen Vorträgen, und es veranlasste mich, über die Tatsache nachzudenken, dass es jetzt über 10 Jahre seit er in einem Interview mit Jim Gray den berühmten (berüchtigten?) Satz sagte: „Du baust es, du betreibst es.“ Aber ich stets Stellen Sie dem voran, was er unmittelbar davor sagte (Hervorhebung von mir): „ Entwicklern Operative Verantwortung hat die QUALITÄT der Dienste sowohl aus Kundensicht als auch aus technologischer Sicht erheblich verbessert. „Ich bin fest davon überzeugt, dass Amazon.com und AWS deshalb weiterhin so erfolgreich sind und dass dies das Herzstück der DevOps-Kultur darstellt.“

#2) Softwareunternehmen (das sind übrigens Sie alle) migrieren komplett in die Cloud
Es geht über den auf Konferenzen oft zitierten frechen Satz „Freunde lassen Freunde keine Rechenzentren bauen“ hinaus. Unternehmen wie GE (die sich selbst als „Technologieunternehmen“ oder „Software- und Analyseunternehmen“ bezeichnen) betreiben Mode-1-Systeme nicht nur weiter wie bisher, sondern schließen aktiv Rechenzentren (30 von 34 weltweit) und beginnen, die Vorteile zu ernten. Besonders gut gefielen mir alle Blaupausen/Referenz-Apps und -Projekte, auf die Steven und Werner an verschiedenen Stellen in ihren Keynotes hingewiesen haben. Ziemlich cool, diesen Einstellungswandel in der Branche zu sehen.

Dies hat einige wirklich interessante Auswirkungen auf die Reaktion auf Vorfälle. In einer Keynote wies der CTO von FanDuel darauf hin, dass ihr Betriebsteam zwar nur aus etwa 10 Personen besteht, sie sich aber auf den AWS Enterprise Support verlassen, um den Betrieb aufrechtzuerhalten. Bleiben Sie dran, um zu erfahren, wie PagerDuty in Zukunft bei der Bewältigung dieser Art von Fällen helfen könnte (Tipp: Verwenden Sie den Reaktionsmobilisator ).

#3) Es ist Zeit, über die Infrastruktur hinauszugehen
Es ist leicht gesagt, aber viel schwerer umzusetzen. „Serverless“ war definitiv ein häufiges Thema auf der Konferenz. Laut Travelex ist Serverless „wie das Spielen mit Lasern und Magneten – einfach Magie“. Verstehen Sie mich nicht falsch, wir bei PagerDuty haben uns nicht nur damit beschäftigt: Wir haben unsere neue Benutzerdefinierter Ereignistransformator um JS-Snippets mit AWS Lambda zu hosten. Aber glauben Sie nicht, dass Sie dadurch weniger in die allgemeine Bedienbarkeit investieren oder dass dadurch irgendwie die sagenumwobenen #NoOps möglich werden.

Insgesamt war es ein wiederkehrendes Thema, die Ingenieure dazu zu bringen, mehr Zeit für das eigentliche Geschäft aufzuwenden (z. B. Dienstleistungen, die den Umsatz steigern). Wenn also die Hälfte Ihres Personals nicht mehr in Ihre Infrastruktur investiert, besteht die nächste Herausforderung darin, die richtigen Dinge zu bauen, und nicht darin, die Dinge richtig zu bauen. Angesichts des umfangreichen Portfolios von AWS bin ich gespannt, ob Amazon in Zukunft in die Schließung dieser Entwicklungsschleife mit einigen Produktmanager-Tools investieren möchte. (Mein Kollege hat einen großartigen Blog-Beitrag zum Thema geschrieben und spricht über Produktmanager in einer DevOps-Welt sein . Das sollten Sie lesen!)

#4) Ihre Dienste müssen sich möglicherweise weiterentwickeln: von SOA zu Microservices
Werner berichtete über viele tolle Erkenntnisse aus Amazons ersten Vorstoß in die serviceorientierte Architektur (SOA) Anfang der 2000er Jahre. Insbesondere erwähnte er, dass die Organisation zu stark auf Datensätzen (Kunden, Katalog usw.) und nicht auf Funktionen oder Zuverlässigkeits-/Skalierbarkeitsmerkmalen basierte. Mit der Umstellung auf Microservices teilte er auch eine fantastische Zusammenfassung von „Einige Anzeichen, dass Sie noch nicht auf Microservice-Niveau sind“:

Foto mit freundlicher Genehmigung von Denise Yu: https://twitter.com/deniseyu21/status/750993932591521793 .

Diese Weiterentwicklung der Services hat auch tiefgreifende Auswirkungen auf Ihren Workflow zur Reaktion auf Vorfälle. Sie sind entscheidend dafür, wie Sie Ihre Reaktion ausrichten und organisieren. Deshalb investieren wir weiterhin in die Bereitstellung das richtige Servicekonzept in PagerDuty . Vergiss nur nicht Gallsches Gesetz wenn Sie in Ihre Dienste investieren:

„ Ein komplexes System, das funktioniert, ist ausnahmslos aus einem einfachen System entstanden, das funktioniert hat. Ein komplexes System, das von Grund auf neu entwickelt wurde, funktioniert nie und kann nicht geflickt werden, damit es funktioniert. Man muss mit einem funktionierenden einfachen System von vorne beginnen.“

Eine Schleife draufmachen
Bei Amazon begann meine Reise als Bereitschaftsarbeiter, daher fühlt es sich fast ein bisschen wie eine Heimkehr an (oder vielleicht eher wie ein Ferienhaus 3000 Meilen entfernt). Das AWS-Portfolio ist riesig, und dennoch sind sie weiterhin innovativ und verändern das Gesicht der Branche.