Kostenvergleich On-Premises und Public Cloud
Sehr geehrte Damen und Herren,
ist eine Public Cloud wirtschaftlicher zu betreiben als eine On-Premises-Lösung? Wir haben unterschiedliche Ausprägungen beider Betriebsarten einem großen Kostenvergleich unterzogen – mit teils überraschenden Ergebnissen. Mehr dazu lesen Sie in der aktuellen Ausgabe unseres Datacenter-Newsletters.
Stehen auch Sie vor der Herausforderung, Ihre IT-Prozesse agil gestalten zu wollen, während der Betrieb so geregelt und gesichert wie bisher laufen soll? Wir zeigen Ihnen, wie ServiceNow Sie bei der Steuerung einer modernen IT-Landschaft optimal unterstützt.
Die Aufgaben der IT-Abteilungen sind über die letzten Jahre hinweg stetig gewachsen und haben immer wieder neue Rollen generiert, die die IT innerhalb des Unternehmens erfüllen muss. Wie sie sich auch als Cloud Service Broker oder Multi Cloud Provider perfekt aufstellen kann, beantworten wir in der vorliegenden Ausgabe.
In unserer Backup-Kolumne nehmen wir dieses Mal die Rolle von Bandtechnologien in modernen Backup-Architekturen unter die Lupe.
Wie sich die widersprüchlichen Anforderungen von DevOps – bei denen Entwicklung und Betrieb in der Hand ein und desselben Teams liegen – und Compliance – die auf eine klare Trennung von Zuständigkeiten und Verantwortung setzt – unter einen Hut bringen lassen, zeigt unsere aktuelle Agile-IT-Kolumne.
Lesen Sie darüber hinaus, wie Sie Ihre DevOps-Umgebungen sicher gestalten können, sodass alle wichtigen Security-Anforderungen erfüllt sind.
Wie immer freuen wir uns über Ihr Feedback, damit wir die Schwerpunkte aufgreifen können, die für Sie von Interesse sind.
Herzliche Grüße
Markus Kunkel
Group Partner Management
Computacenter präsentiert vom 9. bis 11. Oktober 2018 auf der it-sa in Nürnberg sein Security-Portfolio Digital Trust.
Weitere InfosComputacenter plc. hat heute die vorläufigen Zahlen für das erste Halbjahr 2018 bekanntgegeben
Weitere Infos
Cloud-Dienste helfen dabei, die hohen Anforderungen an die heutige IT zu bewältigen: Der Betrieb muss verlässlich funktionieren, während neue Services schnell und agil bereitgestellt werden sollen – und das alles möglichst kosteneffizient. Doch was ist eigentlich wirtschaftlicher – der Betrieb der benötigten IT-Services On-Premises oder in der Public Cloud?
Die vorherrschende Meinung lautet, die Nutzung von Public-Cloud-Ressourcen sei der Königsweg. Die Vorteile liegen auf der Hand: Ressourcen stehen quasi unbegrenzt und sofort zur Verfügung und können von den Fachabteilungen selbst verwaltet werden. Zudem erscheinen die Kosten pro virtuelle Maschine unschlagbar günstig. Die Nutzung der Public Cloud etabliert sich immer mehr, sodass auch anfänglich vorhandene Datenschutzbedenken in den Hintergrund treten.
Dem gegenüber stehen die IT-Abteilungen der Unternehmen, die bisher die IT-Services aus dem eigenen Rechenzentrum oder aus einer Colocation zur Verfügung gestellt haben. Manche beziehen die Services auch als Managed Services, sodass ein Dienstleister für die Erbringung verantwortlich ist. Bei diesem Ansatz ist es schwieriger, auf Änderungen zu reagieren, was den IT-Abteilungen häufig ein negatives Image verschafft. Sie werden als Hindernis wahrgenommen, wenn es um die Einführung neuer oder um die Anpassung bestehender IT-Services geht.
Mit der Maßgabe, dass in beiden Fällen für Self-Service-Angebote eine für Konsumenten geeignete Cloud-Management-Plattform zum Einsatz kommt, können jedoch auch beim On-Premises-Betrieb Public-Cloud-ähnlicher Komfort und Flexibilität erreicht werden.
Um die jeweiligen Kosten für den Betrieb On-Premises und in der Public Cloud zu ermitteln, haben wir die Kosten für die Anschaffung von Hardware (Compute und Storage) und Software sowie für Wartung und Support herangezogen. Darüber hinaus haben wir bei den On-Premises-Lösungen die Kosten für Installation und Inbetriebnahme mit eingerechnet. Hier haben wir moderne Serversysteme mit der Scalable-Prozessor-Architektur von Intel vorausgesetzt, die deutlich wirtschaftlicher sind als ältere Systeme.
Für diese Gegenüberstellung haben wir uns auf die beiden führenden Public-Cloud-Anbieter konzentriert. Diese Anbieter sind nahezu überall verfügbar und bieten eigene Kalkulatoren für die Total Cost of Ownership (TCO) an. Die Ergebnisse dieser Kalkulatoren bilden die Basis für die Kostenbetrachtung der folgenden Public-Cloud-Anbieter:
On-Premises sind die IT-Infrastrukturen, die im eigenen Rechenzentrum oder in einer Colocation betrieben werden.
Für unsere Gegenüberstellung haben wir klassische Infrastrukturen (Converged) bestehend aus Compute, Netzwerk und Storage, Hyperconverged-Systeme sowie einen Software-definierten Ansatz ausgewählt:
Auf Wunsch stellen wir Ihnen den Kostenvergleich gern im Detail vor und beraten Sie, ob in Ihrem konkreten Fall eine Public Cloud oder eine On-Premises-Lösung kosteneffizienter ist. Sprechen Sie uns an!
DevOps-Projekte sind der aktuelle Hype. Alles muss agil sein, damit das Vorhaben Erfolg verspricht. Oder doch nicht? Und was ist eigentlich mit der IT Infrastructure Library? Sind die Investitionen der letzten 20 Jahre in den geregelten IT-Betrieb nun entwertet? Nein, DevOps und Agilität müssen, nein, dürfen kein Gegensatz zu einem geregelten Betrieb sein!
Die IT Infrastructure Library (ITIL), aktuell in der Version 3 aus dem Jahr 2011, gilt als der internationale Standard für die Prozesse und Funktionen im IT-Betrieb und entspricht im Großen und Ganzen den Inhalten der ISO 20000. Aber ITIL gilt auch als Prozess-Moloch, das heißt, die Prozesse und Verfahren gelten nicht als sonderlich schnell und flexibel und schon gar nicht als agil. Der große Vorteil von ITIL-basiertem IT-Service-Management ist aber ganz klar der geregelte und verlässliche IT-Betrieb, um den nachhaltigen Wert der IT für eine Organisation beziehungsweise ein Unternehmen sicherzustellen. Genau aus diesem Grund haben viele Organisationen ITIL für sich adaptiert und stehen nun vor der Frage, wie das mit aktuellen Strömungen in der Entwicklung und Bereitstellung von IT zusammengeht.
Aktuelle IT-Projekte werden häufig agil, nach Methoden wie KANBAN, Scrum oder Lean umgesetzt, weil diese Methoden für komplexe Sachverhalte oder bei unklaren Zielstellungen viele Vorteile in der Umsetzung bieten, etwa die schnelle Anpassung der Entwicklung an das Feedback der Anwender.
Für das erste Quartal 2019 wird die neue Version von ITIL erwartet, welche die bisherigen Prozesse um die Verwendung in agilen Organisationen erweitert. Axelos, der Inhaber und die federführende Organisation für die ITIL-Weiterentwicklung, betreibt einen Blog, in dem über die neusten Erweiterungen und Anpassungen berichtet und zur Diskussion eingeladen wird.
Kritiker bemängeln, dass der Change-Management-Prozess jegliche Agilität ersticke und somit ITIL in agilen Organisationen nicht oder nur bedingt einzusetzen sei. Analysiert man ITIL aber im Detail, dann ist dort zwar beschrieben, was man im Prozess realisieren sollte, aber nicht das Wie der Umsetzung. Wenn man also die Parameter des ITIL-Prozesses anpasst, dann kann man den Prozess ohne Weiteres im agilen Umfeld einsetzen. Dazu sind beispielsweise folgende Punkte zu berücksichtigen und gegebenenfalls anzupassen:
Diese Auflistung bildet nur einen Ausschnitt der möglichen Punkte ab, die im konkreten Anwendungsfall auf die jeweilige Organisation und die verfolgten Ziele angepasst werden müssen. Insbesondere eine Erhöhung der Anzahl der Standard-Changes – um einen höheren Automationsgrad erreichen zu können – zieht zahlreiche zusätzliche Aufgaben nach sich, wie beispielsweise die Definition gemeinsamer Qualitätskriterien für die Tests von Release Packages zwischen Entwicklung und Betrieb. Bei der immer noch vorherrschenden Organisation in technologischen Silos sind vertrauensbildende Maßnahmen wesentlich für eine erfolgreiche Umsetzung.
Ein weiterer Aspekt ist die Unterstützung der angepassten ITIL-Prozesse mit entsprechenden Werkzeugen. Dazu eignen sich Plattformen wie ServiceNow besonders gut, weil auf der Plattform alle Daten für die Steuerung der IT und ihrer Prozesse zur Verfügung stehen.
Die Bereiche IT-Entwicklung, IT-Betrieb und IT-Management können auf der Plattform die jeweils eigenen Prozesse weitgehend automatisiert umsetzen und den jeweils anderen Bereichen die Daten sowie die Prozess-Status transparent bereitstellen, sodass sich einfache End-to-End-Prozesse realisieren lassen. Diese End-2-End-Prozesse können unter Verwendung der jeweiligen Business Rules automatisiert und mittels SLA-Management bewertet und dargestellt werden.
ServiceNow ist eine cloudbasierte Plattform, die es ermöglicht, unterschiedliche Prozessmodelle automatisiert bereitzustellen und dabei auf eine gemeinsame Datenbasis zuzugreifen. Ein detailliertes Rechte- und Rollensystem sorgt dafür, dass die Daten von allen autorisierten Personen – und nur von ihnen – verwendet werden können und dass Doppeleingaben und damit einhergehende Fehler vermieden werden. Zusätzlich ermöglicht es dieser Umstand, Fähigkeiten – neudeutsch Capabilities – über die Grenzen der einzelnen Prozessdomäne hinweg wieder zu nutzen, was den Einsatz im gesamten Unternehmen vereinfacht und die Prozessumsetzung stark beschleunigt. Dafür wird die in der Abbildung gezeigte Architektur verwendet. Die Cloud-Infrastruktur (untere Schicht) wird von ServiceNow weltweit bereitgestellt und betrieben, sodass die Anwender weder in Hard- und Software noch in den Betrieb investieren müssen.
Der Betrieb auf Basis von weltweit geltenden Standards zu Verfügbarkeit, Sicherheit und Datenschutz hilft den Kunden dabei, die Serviceprozesse kosteneffizient und regelgerecht (compliant) zu gestalten.
Die enthaltene Service-Management-Plattform (mittlere Schicht) stellt alle zentralen Fähigkeiten der Lösung zur Verfügung. Dazu zählen sämtliche Werkzeuge zur Konfiguration und Weiterentwicklung, aber auch die zentrale Datenbank, Workflow Engine, Service-Kataloge und so weiter.
Darauf setzt dann die Prozessebene (obere Schicht) auf, welche die Prozessmodelle in den verschiedenen Fachbereichen bereitstellt.
Die zentrale Bereitstellung und der immer aktuelle Stand der Plattform helfen dabei, alle Konfigurationen aktuell und updatefähig zu erhalten. Daraus ergeben sich im Betrieb gegenüber klassischen Prozessmanagement-Plattformen, insbesondere in ITSM-Umfeld, wesentliche Vorteile bei Aufwänden und Kosten.
Computacenter ist als ServiceNow Gold Service Partner in der Lage, Sie bei der Auswahl der richtigen Module und der Implementierung zu unterstützen. Hierbei sind unsere Kenntnisse auch aus anderen ITSM- und Prozessmanagement-Systemen sehr hilfreich, wenn es um die Migration von ITSM-Systemen und die Integration von Drittsystemen geht. Bei Interesse an diesem Themenspektrum sprechen Sie uns gern an!
Ein Broker vermittelt zwischen Verkäufer und Käufer. So einfach ist es bei Cloud Services nicht. IT-Bereiche müssen zusätzlich die Grundlage dafür schaffen, dass die Geschäftsbereiche Cloud Services schnell, einfach, sicher und den Unternehmensregeln entsprechend nutzen können.
Mehr und mehr Anwendungen, Digitalisierungsprojekte oder -prozesse werden auf der Basis von Public Cloud Services entwickelt. Dabei übergehen Geschäftsbereiche schon mal die IT, weil sie schneller sein müssen als die Konkurrenz. Die IT steht damit vor der Herausforderung, auch für „moderne“ Applikationslandschaften als Partner der Geschäftsbereiche akzeptiert und nicht auf die Rolle des „Legacy Betreibers“ reduziert zu werden.
Außerdem hat sich in der Praxis gezeigt, dass es viel effektiver ist, die Grundlagen für eine Cloud-Nutzung zentral zu steuern. Es ist nicht sinnvoll, dass jeder Geschäftsbereich eigene Verträge, Konzepte, Architekturen, Compliance-Regeln, Sicherheitsvorschriften und so weiter für Cloud Services erarbeitet. Zudem bestehen viele Konzepte bereits, die lediglich angepasst oder erweitert werden müssen (zum Beispiel Virenschutz, Backup) – ein idealer Startpunkt für die IT.
Wenn diese „Cloud-Plattform“ einmal erarbeitet ist, kann die IT damit jeden Cloud Service für alle Kunden schnell und einfach nutzbar machen (auch Services die on-premises produziert werden) und wird damit zum Cloud Service Broker oder Multi Cloud Provider.
Wenn Sie mehr über eine sinnvoll gestaltete Vermittlerrolle der IT bei Cloud Services erfahren möchten oder Unterstützung bei der Erarbeitung eines umfassenden Konzepts wünschen, hilft Ihnen Ihr Ansprechpartner bei Computacenter gern weiter.
Eine Eigenart der IT-Industrie ist, dass immer wieder Technologien als veraltet gelten und trotzdem neue Projekte und Beschaffungen genau diese Technologien betreffen. Das gilt beispielsweise für Mainframe-Systeme oder UNIX-Plattformen wie AIX oder Solaris. Auch Tape ist eine solche Technologie, die immer wieder kontrovers diskutiert wird. Computacenter stellt die unterschiedlichen Argumente möglichst objektiv dar und bewertet die Rolle von Tape in modernen Backup-Architekturen.
Beginnen wir mit den Fakten. Eine gute Quelle dazu ist ein seitens Gartner regelmäßig erstellter Report („Discover the Truth About the Use of Disk, Tape and Cloud Backup in 2017”; 27.03.2017, Gartner). Hier finden sich zwei Kernaussagen:
Basierend auf diesen Daten lässt sich sagen, dass der Einsatz von Bandtechnologien in den Rechenzentren stark rückläufig ist.
Diese Analysen stimmen im Grunde mit den Erfahrungen von Computacenter in Deutschland überein. Auch wenn Europa und Deutschland, wie auch im Gartner-Report erwähnt, „tape-lastiger“ sind, ist in den Backup- und Archivierungsprojekten ein Rückgang festzustellen – allerdings existieren nach wie vor aktuelle Projekte, in denen Bandtechnologien beschafft werden.
Um die Argumentationsketten der Pro- und Kontra-Vertreter für die Tape-Technologie zu verstehen, ist es hilfreich, möglichst objektiv auf die Fakten zu schauen.
Für die Einführung von Bandtechnologien und -lösungen werden die folgenden Argumente häufig aufgeführt:
Auch die Kontra-Tape-Fraktion hat eine Reihe durchaus fundierter Argumente auf ihrer Seite:
Wie so häufig gibt es auch hier keine Schwarz-Weiß-Antwort. Objektiv betrachtet sind beide Argumentationsketten, die dieser Artikel auszugsweise aufgeführt hat, valide und nachvollziehbar. Das wird dazu führen, dass das Pendel in beide Richtungen ausschlagen wird und Kunden entweder die Tape-Infrastruktur modernisieren oder auf neue Plattformen wie Object Storage wechseln. Wahrscheinlich wird sich, auch aufgrund der zunehmend positiven Erfahrung mit Object Storage, der von Gartner (siehe Abschnitt Markttrends) beobachtete Trend fortführen, sodass das Pendel häufiger in Richtung diskbasierter Lösungen ausschlagen wird.
Für eine ergebnisoffene und möglichst objektive Diskussion der Pro- und Kontra-Argumente sowie für eine Gegenüberstellung steht Ihnen Ihr Ansprechpartner bei Computacenter gern zur Verfügung.
In einer modernen IT-Umgebung, die auf agilen Grundsätzen basiert, spielen sowohl DevOps als natürlich auch die Compliance eine große Rolle. Was jedoch das Zusammenspiel von Entwicklung und Betrieb anbelangt, ergibt sich aus beiden ein Widerspruch. Wie lässt sich dieser am besten auflösen? Computacenter hat die Antwort.
DevOps wird gern wie folgt umschrieben: „You build it. You run it.“ Demnach liegen Entwicklung und Betrieb in einer Hand, eine Trennung ist nicht vorgesehen. Compliance wiederum steht für eine klare Trennung der Verantwortungen und Rollen. Ein Team entwickelt, es erfolgt eine Freigabe und dann geht die Lösung in den Betrieb. Hier setzt man auf eine klare Trennung mit Freigabeprozessen.
Wie sollen diese widersprüchlichen Anforderungen in der Praxis umgesetzt werden? Dazu spannen wir den Bogen – exemplarisch – über klassische Entwicklungsprozesse und DevOps-Modelle bis hin zu Diskussionsgrundlagen für umsetzbare Modelle.
Im klassischen Entwicklungsprozess verwenden Entwicklungsteams Werkzeuge wie GIT (als Repository für Softwarecode) und Continuous Integration (CI) Pipelines, aufgebaut mit Werkzeugen wie Jenkins, um Software zu entwickeln und zu testen. Zu einem definierten Zeitpunkt, zum Beispiel am Ende eines zweiwöchigen Sprints, steht eine neue Version oder ein Update bereit und soll in die Produktion gehen. Dazu übergibt die Rolle „Softwareentwicklung“ an den Test-Manager und das Tester-Team, die den Code aus GIT übernehmen und in einer Testumgebung die erforderlichen Funktions- und Lasttests durchführen. Anschließend erfolgt eine Freigabe, beispielsweise durch den Test- und den Release Manager (Vieraugenprinzip) und der Code wird in die Produktion überführt und dort durch Operations im Regelbetrieb überwacht und verantwortet.
Das sind insgesamt mindestens drei getrennte Teams (Development, Test, Produktionsbetrieb), in der Praxis können auch weitere Rollen vorhanden sein. Und zwischen diesen Teams erfolgt eine Übergabe der Software und der Verantwortung.
Das Business hat eine neue Produktidee und beschließt, in einem Design-Sprint innerhalb von zwei Wochen ein MVP (Minimal Viable Product) erstellen zu lassen. Nach zwei Wochen steht das MVP und man beschließt, es in einem dedizierten Team, das organisatorisch ein und derselben Personalverantwortung unterliegt, weiterzuentwickeln und an den Markt zu bringen. Das Team organisiert sich intern eigenständig und verantwortet das Produkt von der Entwicklung bis in die Produktion aus einem Guss. Dazu werden CI/CD-Verfahren verwendet, die ähnlich beginnen wie im klassischen Entwicklungsprozess, aber zusätzlich ein Continuous Deployment – automatisiert – erlauben. Bei Störungen in der CI/CD Pipeline oder im Regelbetrieb nimmt ein verfügbares Teammitglied die Task auf und behebt die Störung. In diesem reinen DevOps-Modus existiert die klassische Rollentrennung nicht und das Mantra „You build it. You run it.“ steht im Vordergrund.
Auf den ersten Blick scheinen beide Modelle zueinander im Widerspruch zu stehen und eine Compliance für DevOps erscheint aufgrund der Rollentrennung (klassisch) versus ein Team (DevOps) nicht umsetzbar zu sein. Tatsächlich ist dieser Widerspruch auflösbar. Dazu soll zuerst betrachtet werden, wie DevOps-zentrische Modelle die Compliance und Sicherheit erhöhen.
DevOps-zentrische Modelle stellen den Business Service – End-to-End – in den Vordergrund. Von der Entwicklung über die Produktion bis zur Abschaltung der Anwendung in naher oder ferner Zukunft wird alles über Werkzeuge wie CI/CD in einen Prozess gegossen und automatisiert. Das umfasst auch automatisierte Prozesse, um auf aktuelle Versionen und Patch-Stände zu gehen, Deployments reproduzierbar und basierend auf einheitlichen Playbooks durchzuführen und manuelle Eingriffe und damit auch menschliche Fehler zu reduzieren.
Damit werden Silos geöffnet und anstelle aufwendiger Abstimmungsmeetings und -runden (wer kennt nicht den klassischen War Room) wird kontinuierlich an einer verbesserten Automation gearbeitet und der End-to-End Prozess überwacht.
Das bedeutet aber nicht zwangsläufig, dass durchgängig keine Rollentrennung möglich oder sie nicht sinnvoll wäre.
Für den End-to-End-Prozess können über die diversen Stages (Development, Test, Produktionsbetrieb) hinweg auch unterschiedliche Rollen und verbunden damit Personen zuständig sein – sofern alle Personen den automatisierten Gesamtprozess im Blick haben und klare Definitionen existieren, wo die Übergabepunkte und damit auch die Zuständigkeiten liegen.
Aber bereits die Begriffe „Silos öffnen“ und „Sicherheit automatisieren“ erfordern ein massives Umdenken in Abläufen und Organisationen. Es werden Rolle und Zuständigkeiten neu definiert und neue Aufgaben kommen auf die Teams und Mitarbeiterinnen und Mitarbeiter zu. So kann es sein, dass in einem DevOps-Team auch Softwareentwickler in Rufbereitschaft für eine Fehleranalyse bereitstehen und über eine Rollentrennung Dev und Ops innerhalb eines Teams differenziert werden – ohne jedoch die gemeinsame Verantwortlichkeit infrage zu stellen.
Die Frage nach der richtigen Aufstellung, einem Betriebsmodell und dem Erreichen der Compliance ist komplex und benötigt Zeit. Positive Beispiele wandeln sich graduell über einen Zeitraum hinweg zu neuen Organisations- und Betriebsformen und versuchen nicht, über Nacht durch den Aufbau von Parallel- und Schattenorganisationen eine getrennte Einheit zu schaffen – weil die bestehende Erfahrung im Unternehmen wertvoll ist und wegen den derzeit massiven Ressourcenengpässen am Arbeitsmarkt die Menschen im Unternehmen das wertvollste Asset sind. Daher ist die Transition und Adaption der automatisierten End-to-End-Sicht über einen sinnvollen Zeitraum mit neuen Aufgaben und Rollen ein möglicher Weg in eine sichere DevOps-orientierte IT.
Computacenter begleitet Kunden seit 2015 in der Einführung von DevOps-orientierten Modellen in den unterschiedlichsten Ausprägungen – inklusive der Technologie wie auch der Betriebsleistungen – und steht Ihnen jederzeit für Fragen und zur Unterstützung zur Verfügung. Wenden Sie sich dazu einfach an Ihren Ansprechpartner bei Computacenter.
Was ist DevOps, was ist DevSecOps und wie passt das zu Cloud, Digitalisierung und Security? Zwar wird viel über diese Begriffe gesprochen, was jedoch wirklich dahintersteckt, bleibt oft im Verborgenen. Computacenter klärt auf.
Entwickler lieben sie, Operations weiß nichts mit ihr anzufangen, Security kennt sie nicht. Die Cloud ist nach wie vor ein Thema, zu dem fünf Köpfe zehn Meinungen haben – zumal es ja auch mit der Entwicklung von Anwendungen und der Digitalisierung zusammenhängt. Dabei ist die Verwendung der Cloud keine Voraussetzung für den Aufbau einer DevOps-Umgebung. Schaut man sie sich aber genauer an, wird klar, weshalb sie sich zunehmender Beliebtheit erfreut.
Die Cloud – ob Private oder Public Cloud – wurde extra für die Entwicklung von Anwendungen geschaffen. Von Entwicklern für Entwickler. Eigentlich eine ideale Kombination, bei dem die Hersteller eines Produkts genauso denken wie dessen Konsumenten und in der Lage sind, neue Anforderungen bis ins kleinste Detail zu verstehen. So wurde mit Cloud-Plattformen ein Produkt geschaffen, das die Arbeit von Entwicklern stark vereinfacht und beschleunigt.
Beschleunigung bedeutet auch kürzere Release-Zyklen, geringere Entwicklungskosten und einen schnelleren Return of Investment. Es gibt weniger Abhängigkeiten und Entwickler können sich auf ihre eigentliche Aufgabe fokussieren. Hinzu kommt, dass häufig verwendete Funktionen mittlerweile von Cloud Providern als Service angeboten werden, was wiederum Entwicklungszeit einspart. Das regelmäßig angeführte Beispiel hierfür ist der Chatbot, der Anfragen von Anwendern und Kunden entgegennimmt und wie ein Mensch interagieren kann.
DevOps wird häufig gleichgesetzt mit Digitalisierung. So ganz verkehrt ist das auch nicht. Es geht um die schnelle Umsetzung von Ideen zur Digitalisierung und um die flexible Änderung von Applikationen, um Kundenanforderungen bestmöglich umsetzen zu können. Alles Anforderungen, die man auch im DevOps-Bereich hat. Doch DevOps bedeutet zudem einen kulturellen Wechsel in der Arbeitsweise und damit auch in der Organisation von Unternehmen.
Bei DevOps geht es darum, dass sich die unterschiedlichen Bereiche wie Business, Development, Infrastruktur, Operations und Security untereinander austauschen, um bestmöglich vom Wissensschatz und von den Erfahrungen der anderen profitieren zu können. Ein wichtiges Merkmal besteht darin, dass alle Ressourcen in einem Team zusammenarbeiten, um einen Service best- und schnellstmöglich zur Verfügung zu stellen. Dabei haben alle ein gleichgewichtetes Mitspracherecht. Die Vorreiter in diesem Bereich bauen Abteilungen sogar dahingehend um, dass diese eine End-to-End-Verantwortung für einen angebotenen Dienst übernehmen können. In diesen Abteilungen kommen Experten aller Fachbereiche zusammen, sodass ein Höchstmaß an Kompetenz für alle Anforderungen gegeben ist.
Der Austausch oder Umbau von Abteilungen ist extrem wichtig, da die IT in zu viele unterschiedliche Themenbereiche aufgeteilt wurde, als dass eine Fachrichtung alle Anforderungen und Einflüsse berücksichtigten könnte. Es dürfte jedem klar sein, dass ein Mitarbeiter aus dem Betrieb ein anderes Verständnis von IT hat als ein Entwickler oder ein Sicherheitsarchitekt. Ein Kollege brachte das einmal gut auf den Punkt, als er sagte: „Sie gehen ja auch nicht zum Zahnarzt, wenn Sie Bauchschmerzen haben.“ Das verdeutlicht zum einen sehr schön, wie komplex heutige IT geworden ist, zum anderen auch, wie wichtig der Austausch der Experten ist.
Letzten Endes geht es immer um eine optimale Zusammenarbeit. Das wiederum hat auch Auswirkungen auf die Durchführung von Projekten. Wurde in der Vergangenheit häufig das klassische Wasserfallmodell verwendet, setzt man heute auf agile Methoden wie SCRUM. Neben dem eingesetzten Toolstack und der damit verbundenen Arbeitsweise berücksichtigt SCRUM, das heutige Projekte deutlich flexibler sein müssen als früher und dass sich die Projektanforderungen permanent ändern. Die Auswertung von Kunden-Feedback und die Anpassung der damit verbundenen Zielsetzungen sind fester Bestandteil von SCRUM. Für Entwickler bedeutet das, dass sich ihr Produkt permanent ändert beziehungsweise weiterentwickelt, um es an die Kundenwünsche und Marktanforderungen anzupassen. Die Forderung nach einer IT-Infrastruktur, die diese Arbeitsweise ermöglicht, ist also verständlich. Dazu wurde das Konzept der Continuous Integration / Continuous Delivery Pipeline (CI/CD) geschaffen. Eine CI/CD Pipeline erlaubt es Entwicklern, ihre Anwendung mehrmals am Tag zu ändern, zu testen und auszurollen. Innerhalb ihrer Pipeline sind die Entwickler frei in dem, was sie tun und wie sie es tun. Aber sie verändern die Struktur der Pipeline nicht.
Für den Aufbau der Pipeline und für Änderungen daran ist Operations zuständig (Anmerkung: Dem Autor ist bewusst, dass der Anspruch „You build it, you run it!“ existiert, der in kleineren Entwicklungsumgebungen durchaus funktionieren kann. So wie es früher auch den einen EDV-Mitarbeiter gab, der sich um alles gekümmert hat. Doch auch der skalierte nicht, als die Umgebungen größer wurden.). Insofern ist es die Aufgabe von Operations, eine Pipeline aufzubauen, die den Anforderungen der Entwickler gerecht wird, und diese permanent zu optimieren. Und dann kommt auch noch die Security dazu.
Während sich der Begriff DevOps in den letzten Jahren durchgesetzt hat, ist der Begriff DevSecOps noch nicht sehr weit verbreitet. Dabei ist es in der heutigen Zeit so wichtig wie nie zuvor, Sicherheitsanforderungen zu berücksichtigen.
Öffentliche Cloud-Infrastrukturen weisen ein erhöhtes Risiko auf, da sie von überall aus erreicht werden können. Ihre Schnittstellen sind frei aus dem Internet erreichbar, die abgelegten Daten können mit wenigen Mausklicks für die ganze Welt zugänglich gemacht werden. Hinzu kommt, dass die zugrunde liegende Hardware von Cloud-Infrastrukturen häufig von mehreren Kunden genutzt wird. Somit können Schwachstellen wie Spectre oder Meltdown erheblichen Einfluss auf die Sicherheit einer Umgebung haben. Das ist ein Grund, weshalb Cloud-Plattformen für Angreifer attraktiv sind. In Zeiten von Kryptowährung und Bitcoin-Mining kommt noch die praktisch unlimitierte Skalierbarkeit hinzu, die unsichere Cloud-Infrastrukturen bieten. Es bedarf einiges an Erfahrung und Kenntnissen, um zu verstehen, wie Angreifer eine Infrastruktur oder Anwendung angreifen können und welche Angriffsformen aktuell genutzt werden. Zugleich müssen Security-Experten die Anforderungen der Entwickler verstehen und berücksichtigen. Es ist also elementar wichtig, auch die Security-Experten von Anfang an in die Planung und Umsetzung von DevOps-Projekten mit einzubeziehen.
Dabei sind Sicherheitslösungen für die Cloud nicht gleichzusetzen mit Sicherheitslösungen für DevOps-Umgebungen. Während man bei Cloud-Umgebungen noch den On-Premises Toolstack nutzen kann, den man über Jahre hinweg aufgebaut hat, benötigt man für DevOps-Umgebungen häufig ganz neue Tools. Mit Containern hält nämlich auch ein neuer Abstraktionslayer Einzug. Die wenigsten Umgebungen setzen bereits Schutzmaßnahmen auf Containerebene ein, Security-Abteilungen müssen sich aber mit diesem Layer auseinandersetzen, um zu verstehen, welche Bedrohungen existieren und wie man sich schützen kann.
Die Aufgabe der Security-Abteilungen ist es also, ihre Vorgaben an schnelllebige DevOps-Umgebungen und sich ändernde Bedrohungslagen anzupassen. Dazu gehört auch, althergebrachte Grundsätze neu zu überdenken und wenn nötig über Bord zu werfen. Des Weiteren müssen neue Sicherheitsanforderungen wie zum Beispiel jene an Nanosegmentierung oder Image Signing evaluiert und die Vorgaben angepasst werden. Zudem müssen Sicherheits-Tools in der Lage sein, auf sich ändernde Infrastrukturen zu reagieren und automatisch Ihre Schutzfunktionen neu auszurichten.
Auf der anderen Seite müssen Entwickler akzeptieren, dass es ganz ohne Security nicht geht. Sicherheitsleitlinien, die von der Security-Abteilung erlassen werden, haben ihre Daseinsberechtigung und sind zu berücksichtigen. Letzten Endes geht es immer um die stabile Bereitstellung eines sicheren Services. In unserem Beispiel der DevSecOps Pipeline kann der Aufbau also erst als abgeschlossen betrachtet werden, wenn sowohl Entwicklungs- als auch Betriebs- und Security-Aspekte mit einem ausreichend tiefen Detailierungsgrad berücksichtigt wurden.
Haben Sie Fragen zu DevSecOps? Wir beraten Sie gern! Wenden Sie sich einfach an Ihren Ansprechpartner bei Computacenter.