Managed Services als Teil Ihrer Cloud-Strategie

Der Cloud-Zwang

Verschiedene Unternehmen haben unterschiedliche Gründe für den Wechsel in die öffentliche Cloud und insbesondere zu AWS. Bei Xebia hören wir oft, dass (Managed Services-)Kunden die folgenden Gründe nennen:

• Sicherheit - C-Level- und IT-Führungskräfte verstehen, dass die erforderlichen Investitionen in die Sicherheit heutzutage phänomenal sind und nur im Hyperscale-Bereich möglich sind.
• Kosten - die Größenordnung, in der die führenden Cloud-Anbieter operieren, verschafft ihnen enorme Größenvorteile, die sie an ihre Kunden weitergeben.
• Produktivität - durch den Einsatz der Public Cloud können Unternehmen Produktivitätssteigerungen erzielen, die es ihnen ermöglichen, mehr Wert für das Unternehmen zu schaffen, ohne den Personalbestand erhöhen zu müssen.
• Modernisierung - die öffentliche Cloud bietet Unternehmen einen einfachen Zugang zu Technologien, die sie benötigen, um ihre Anwendungslandschaft zu modernisieren und ihren Kunden einen Mehrwert zu bieten
• Flexibilität - die Elastizität der öffentlichen Cloud ermöglicht es Unternehmen, jederzeit nach oben und unten zu skalieren, wenn sie es brauchen.
• Agilität - die Zeit bis zur Markteinführung wird erheblich verkürzt, wenn Ihnen eine Plattform zur Verfügung steht, die die erforderlichen Fähigkeiten und Ressourcen bietet, wann immer sich eine Geschäftsmöglichkeit bietet.

Die öffentliche Cloud wird zunehmend als die neue Normalität angesehen, und das ist an sich schon ein weiterer zwingender Grund für den Wechsel in die öffentliche Cloud. Die Frage ist nicht mehr 'ob' und 'warum', sondern 'wann'.

Bereitstellung der Plattform

Die Art und Weise, wie Unternehmen Public Cloud-basierte Plattformen aufbauen und bereitstellen, kann je nach dem erwarteten Ergebnis variieren. Wenn der Schwerpunkt ausschließlich auf der Senkung der Kosten bestehender Arbeitslasten liegt, wäre es naheliegend, einen kleinen Satz zentral verwalteter kodifizierter Muster anzubieten, die es den Anwendungsteams ermöglichen, die von ihnen benötigten Umgebungen einzurichten. Geht es hingegen darum, Zugang zu Technologien zu erhalten, um aus den großen Datenmengen, über die das Unternehmen verfügt, einen Nutzen zu ziehen, aber es ist unklar, welche Technologie am besten geeignet ist, kann das Unternehmen beschließen, die Plattform auf eine ganz andere Weise bereitzustellen. Im letzteren Fall ist es unwahrscheinlich, dass ein zentrales Team in der Lage wäre, ein bewährtes Muster für das anstehende Problem zu erstellen. Höchstwahrscheinlich wird ein Team, das die Plattform nutzt, die besten Ergebnisse erzielen, wenn es relativ uneingeschränkten Zugang zu den Tools hat, die die Plattform zu bieten hat.

Wie auch immer das gewünschte Ergebnis oder der Anwendungsfall aussieht, es gibt wahrscheinlich eine Lücke zwischen dem, was der Public Cloud-Anbieter standardmäßig anbietet, und den IT-Richtlinien und -Standards des Unternehmens. Die Plattform, wie sie innerhalb des Unternehmens angeboten wird, muss diese Lücke schließen. Am einen Ende des Spektrums haben wir bereits die Einschränkung von Teams durch die Bereitstellung zentral verwalteter und kodifizierter Muster erwähnt. Das zentrale Team sorgt dafür, dass die Muster Konfigurationen oder Ergänzungen enthalten, die die Einhaltung der Unternehmensstandards gewährleisten. Dies scheint zwar ein attraktiver Ansatz zu sein, funktioniert aber möglicherweise nicht in allen Anwendungsfällen. Ein Beispiel für eine solche Ausnahme wurde bereits genannt: das Datenteam, das noch auf der Suche nach der besten Technologie für seinen Anwendungsfall ist und für das noch keine Unternehmensstandards festgelegt worden sind. Ein weiteres Problem bei der Beschränkung von Teams auf die Verwendung vordefinierter Muster ist die Annahme, dass alle erforderlichen Muster erfasst und zentral bereitgestellt werden können. Was aber, wenn diese Annahme nicht zutrifft?

Durch die Bereitstellung von Leitplanken erhalten die Teams, die die Plattform nutzen, mehr Freiheit. Anstatt die Kontrollen auf der Ebene des Musters zu platzieren, können die Kontrollen auf der Ebene der Komponenten platziert werden, aus denen das Muster besteht. Teams, die ihre eigenen Muster definieren, werden auf Komponentenebene getestet und erhalten (frühes) Feedback. Ein Beispiel, das vielen bekannt vorkommen dürfte, ist die Prüfung von Dateisystemen auf die richtige Verschlüsselungsmethode. Zentral bereitgestellte Muster werden an denselben Standards gemessen. Alle Komponenten, aus denen diese Muster bestehen, müssen diese Konformitätstests auch einzeln bestehen, damit das Muster als Ganzes konform ist.

Eine Größe passt nicht allen

Diagramm 1: Standardisierung versus Fertigkeiten

Natürlich hängt es auch vom Reifegrad der Teams ab, wie sie die Plattform anbieten. Die Realität sieht so aus, dass in großen und sogar kleinen Unternehmen die Fähigkeiten und der Reifegrad der Teams unterschiedlich sind. Die Anforderungen in Bezug auf Fähigkeiten und Reife variieren auch je nach Anwendungsfall.

Wie das Diagramm auf der rechten Seite zeigt, schließen geringe Fähigkeiten und ein geringer Reifegrad in einem Team nicht aus, dass es ein hohes Maß an Freiheit hat, solange die Arbeitsbelastung dies rechtfertigt. Das hier angeführte Beispiel ist ein Sandkasten, der zum Experimentieren und zum Aufbau von Fähigkeiten genutzt wird. Es ist auch durchaus denkbar, dass reife Teams Komponenten als Baustein für ihre Muster verwenden oder Bausteine zur Community beisteuern.

Wenn Sie in Ihrem Unternehmen eine öffentliche Cloud-Plattform anbieten möchten, müssen Sie eine Reihe von Anforderungen erfüllen. Zunächst einmal müssen Sie sich mit den Gründen für den Wechsel in die Cloud auseinandersetzen. Gleichzeitig sollte die Plattform berücksichtigen, dass verschiedene Anwendungsfälle und Teams unterschiedliche Anforderungen haben. Eine Größe passt nicht unbedingt für alle.

Das Betriebsmodell

Die Einführung der Public Cloud scheint weitgehend mit einer anderen wichtigen Entwicklung in der IT-Branche zusammenzufallen: dem Wechsel zu DevOps. Viele werden argumentieren, dass die öffentliche Cloud oder die Cloud im Allgemeinen DevOps tatsächlich erleichtert. An diesem Argument ist zwar viel dran, aber die Umstellung auf DevOps ist definitiv keine notwendige Voraussetzung für die erfolgreiche Einführung der Public Cloud. In Wirklichkeit haben einige Teams DevOps bereits eingeführt, bevor sie in die öffentliche Cloud wechseln. Andere Teams ziehen den Wechsel vielleicht in Betracht. Und es mag Teams geben, für die es keinen Business Case oder keine Notwendigkeit gibt, die DevOps-Arbeitsweise zu übernehmen.

Eines der überzeugendsten Argumente für die Umstellung auf eine DevOps-Arbeitsweise ist die Verbesserung der Agilität durch die Beseitigung von Abhängigkeiten. In einer traditionell organisierten IT-Abteilung sind Anwendungsentwicklung, IT-Infrastruktur und Betrieb oft strikt voneinander getrennt. Wenn der Code in die Produktion geht, kommt es zwangsläufig zu Übergaben zwischen Entwicklung und Betrieb. Wenn ein einziges Team für die Entwicklung und den Betrieb zuständig ist, kann dieses Hindernis weitgehend beseitigt werden.

Diagramm 2: Drei Ebenen von DevOps

Warum also nicht gleichzeitig ein anderes Problem in Angriff nehmen? Wir beziehen uns auf eine häufig geäußerte Frustration von Teams, nämlich dass sie Anfragen oder Tickets für die Infrastruktur stellen müssen. Die Einführung einer Self-Service-fähigen Plattform kann hier den Unterschied ausmachen. Aber was ist mit dem täglichen Betrieb? Es ist eine Sache, die Umgebungen einzurichten, die benötigt werden, um eine neue Anwendung oder Funktion in Produktion zu bringen. Die Umgebung stabil, leistungsfähig und sicher zu halten, ist eine ganz andere Sache. Die Cloud hat diese Aufgabe auf jeden Fall sehr erleichtert, denn sie unterstützt den Ansatz "Vieh statt Haustiere" und setzt auf "Infrastruktur als Code". Aber die Realität ist, dass einige Teams einfach noch nicht so weit sind.

Diagramm 3: Entwicklung versus Betrieb

Diagramm 3 ist eine grafische Darstellung der Bereiche, in denen, wie oben beschrieben, Herausforderungen auftreten können. Da Plattformen, die auf einer öffentlichen Cloud basieren, in der Regel recht neu sind, ist es sinnvoll, ein einziges Team für den Aufbau und den Betrieb der Plattform verantwortlich zu machen, wie es den jüngsten Trends in der IT entspricht. Workloads (Anwendungen einschließlich der erforderlichen Infrastruktur, Datenplattformen usw.) sind wahrscheinlich eine andere Sache. Einige Teams haben möglicherweise bereits die Verantwortung für die Entwicklung und den Betrieb von Infrastruktur und Anwendungen übernommen. Einige Teams sind vielleicht noch in der Übergangsphase und einige Teams werden vielleicht nie so weit kommen (wollen). Wenn Sie dies als Realität akzeptieren, muss die Plattform, die Sie bedienen, in der Lage sein, all diese verschiedenen Modi zu berücksichtigen.

Überleitung

Während des Übergangs zu DevOps und Public Cloud sollten Sie nicht nur über eine Plattform verfügen, die verschiedene Betriebsmodelle unterstützen kann, sondern auch über die Kapazitäten zur Unterstützung der Teams, die sie nutzen. Zusätzlich zum Plattformteam benötigen Sie möglicherweise temporäre Kapazitäten, um Betriebs- und Entwicklungskapazitäten bereitzustellen, während die Teams reifen, bis sie bereit sind, die volle Verantwortung für ihre Workloads zu übernehmen. Sobald die Teams den gewünschten Reifegrad erreicht haben, sollten Sie auch bereit sein, diese Kapazität zu reduzieren.

Die Unterstützung der Teams bei der Übernahme der richtigen Muster mit dem geringstmöglichen operativen Fußabdruck wird die Reise beschleunigen. Die Teams werden Coaching und Schulungen in diesem Bereich benötigen, was Sie ebenfalls einplanen sollten. Ob Sie ein voll funktionsfähiges Cloud Center of Excellence (CCoE) aufbauen, eine Cloud-Migrationsfabrik einrichten oder ah-hoc-Fähigkeiten während der Planungsphasen einbringen, hängt von Ihrer spezifischen Situation ab.

Mit der Einführung der Public Cloud als Plattform in Ihrem Unternehmen führen Sie auch einen Cloud-Service-Anbieter in Ihre Anbieterlandschaft ein. Infolgedessen müssen Sie möglicherweise die derzeitige Kapazität, die die Infrastruktur bereitstellt, überdenken, neu schulen oder rationalisieren. Dabei kann es sich um eine interne Abteilung oder einen Anbieter handeln, wenn diese Funktion ausgelagert wurde. Wenn der derzeitige Anbieter auch operative Dienste anbietet, wie steht er zu einer neuen Plattform und der Umstellung auf DevOps?

Die Einführung eines Cloud Service Providers in die Anbieterlandschaft und die Umstellung auf ein verbrauchsbasiertes Modell erfordert an sich schon eine Reihe von neuen Fähigkeiten. Die genaue Überwachung des Cloud-Verbrauchs, die Optimierung des Kaufmodells, die konsolidierte Abrechnung, die Ermutigung der Teams zur Re-Sizing und die Übernahme der richtigen Muster und Architekturen aus finanzieller Sicht sind nur einige der Fähigkeiten, die im Volksmund als FinOps (Erfahren Sie mehr über FinOps auf unserer Plattform).

AWS Verwaltete Cloud-Dienste

Wir bieten ein breites Portfolio an Managed Cloud Services an, da wir sehen, dass sich Unternehmen auf ihrem Weg in die Cloud auf vielen verschiedenen Reifegraden befinden. Wir arbeiten eng mit den Anwendungsteams unserer Kunden zusammen, die diese Services in Anspruch nehmen, um sicherzustellen, dass die Cloud-Plattform das liefert, was das DevOps-Team der Anwendung auf kontrollierbare Weise benötigt. Was brauchen Sie von der AWS Managed Cloud? Finden Sie unsere Cloud-Lösungen hier.