Letzte Woche hatte ich die Gelegenheit, nach London zu reisen, um am AWS Enterprise Summit (6. Juli) und am AWS Summit (7. Juli) teilzunehmen. Als ehemaliger Mitarbeiter von Amazon (vor AWS) und Microsoft Azure war es faszinierend zu sehen, wie weit die Entwicklung im Bereich Cloud Computing fortgeschritten ist. Hier sind einige meiner wichtigsten Erkenntnisse aus dieser gelungenen Veranstaltung.

#1) Der (richtige) Umstieg auf die Cloud bedeutet die Einführung einer DevOps-Kultur.
Das hat mir sehr gut gefallen. Stephen Orban (Der Leiter der globalen Unternehmensstrategie, der am ersten Tag des Enterprise Summit die Keynote hielt) griff diesen Punkt sofort auf: Ihr Infrastrukturteam MUSS zu einem Cloud Center of Excellence werden und damit beginnen, die operative Verantwortung von oben nach unten auf die Produkt-/Serviceteams, das interne IT-Team und das Desktop-Supportteam zu verteilen.

Ich zitiere oft Dr. Werner Wogels (CTO von Amazon.com, der täglich eine Keynote hielt) in meinen eigenen Vorträgen, und das veranlasste mich, darüber nachzudenken, dass es nun so weit ist über 10 Jahre Denn er sagte in einem Interview mit Jim Gray den berühmten (berüchtigten?) Satz: „Wer’s baut, der betreibt’s auch.“ Aber ich stets Dem voranzustellen sei, was er unmittelbar zuvor gesagt hat (meine Hervorhebung): „ Entwicklern operative Verantwortlichkeiten hat die QUALITÄT der Dienstleistungen sowohl aus Kunden- als auch aus Technologiesicht erheblich verbessert. Ich bin fest davon überzeugt, dass dies der Grund für den anhaltenden Erfolg von Amazon.com und AWS ist und den Kern dessen ausmacht, was die DevOps-Kultur repräsentiert.

#2) Softwareunternehmen (also ihr alle) migrieren komplett in die Cloud.
Das geht weit über die auf der Konferenz oft zitierte, etwas augenzwinkernde Redewendung „Freunde lassen Freunde keine Rechenzentren bauen“ hinaus. Unternehmen wie GE (die sich selbst als „Technologieunternehmen“ oder „Software- und Analyseunternehmen“ verstehen) betreiben ihre Systeme nicht einfach wie bisher im Modus 1, sondern schließen aktiv Rechenzentren (30 ihrer 34 weltweit) und profitieren bereits davon. Besonders gut gefallen haben mir die zahlreichen Blaupausen, Referenzanwendungen und Projekte, auf die Steven und Werner in ihren Keynotes immer wieder hingewiesen haben. Es ist wirklich spannend, diesen Wandel in der Branche zu beobachten.

Dies hat einige wirklich interessante Auswirkungen auf die Reaktion auf Sicherheitsvorfälle. In einer Keynote wies der CTO von FanDuel darauf hin, dass ihr Betriebsteam zwar nur aus etwa zehn Personen besteht, sie aber auf den AWS Enterprise Support angewiesen sind, um den Betrieb aufrechtzuerhalten. Seien Sie gespannt, wie PagerDuty in Zukunft bei der Bewältigung solcher Fälle helfen könnte (Hinweis: Verwendung von …). Reaktionsmobilisator ).

#3) Es ist an der Zeit, über die Infrastruktur hinauszugehen.
Es ist leicht gesagt, aber viel schwerer umzusetzen: „Serverless“ war definitiv ein häufig diskutiertes Thema auf der Konferenz. Laut Travelex ist Serverless „wie das Spielen mit Lasern und Magneten – einfach Magie“. Versteht mich nicht falsch, wir bei PagerDuty haben uns damit nicht nur oberflächlich beschäftigt: Wir haben unsere neue Benutzerdefinierter Ereignistransformator Um JS-Snippets mit AWS Lambda zu hosten. Lassen Sie sich aber nicht täuschen: Das bedeutet nicht, dass Sie weniger in die allgemeine Betriebsfähigkeit investieren müssen oder dass dadurch irgendwie das sagenumwobene #NoOps ermöglicht wird.

Insgesamt war es ein wiederkehrendes Thema, die Entwickler dazu zu bringen, mehr Zeit für das Kerngeschäft (z. B. umsatzgenerierende Services) aufzuwenden. Sobald also mehr als die Hälfte der Belegschaft in die Infrastruktur investiert ist, besteht die nächste Herausforderung darin, die richtigen Dinge zu entwickeln, nicht die Dinge richtig zu entwickeln. Angesichts des umfangreichen AWS-Portfolios bin ich gespannt, ob Amazon in Zukunft in die Schließung dieses Entwicklungszyklus mit Produktmanagement-Tools investieren wird. (Mein Kollege hat dazu einen hervorragenden Blogbeitrag verfasst und spricht darüber.) Produktmanager in einer DevOps-Welt sein Du solltest es lesen!

#4) Ihre Services müssen sich möglicherweise weiterentwickeln: von SOA zu Microservices.
Werner teilte wertvolle Erkenntnisse über Amazons erste Versuche mit serviceorientierter Architektur (SOA) Anfang der 2000er-Jahre. Insbesondere bemängelte er die zu starke Ausrichtung auf Datensätze (Kunden, Katalog usw.) anstatt auf Funktionen oder Zuverlässigkeits-/Skalierbarkeitsmerkmale. Im Zuge des Übergangs zu Microservices präsentierte er zudem eine hervorragende Zusammenfassung der „Anzeichen dafür, dass Sie noch nicht auf Microservice-Niveau sind“.

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

Diese Weiterentwicklung der Services hat auch einen tiefgreifenden Einfluss auf Ihren Workflow bei der Reaktion auf Sicherheitsvorfälle. Sie sind entscheidend dafür, wie Sie Ihre Reaktion ausrichten und organisieren. Deshalb investieren wir weiterhin in die Bereitstellung dieser Services. das richtige Servicekonzept in PagerDuty Vergiss es einfach nicht Gallsches Gesetz wenn Sie in Ihre Dienstleistungen investieren:

„ Ein komplexes System, das funktioniert, ist stets aus einem einfachen, funktionierenden System hervorgegangen. Ein von Grund auf neu entwickeltes komplexes System funktioniert niemals und lässt sich auch nicht nachträglich reparieren. Man muss mit einem funktionierenden, einfachen System von vorn beginnen.

Eine Schleife drumherum binden
Bei Amazon begann meine Laufbahn im Bereitschaftsdienst, daher fühlt es sich fast wie eine Heimkehr an (oder vielleicht eher wie ein Besuch im Ferienhaus 5000 Kilometer entfernt). Das AWS-Portfolio ist riesig, und dennoch entwickelt sich das Unternehmen ständig weiter und verändert die Branche grundlegend.