Was ist DevSecOps und sollte es mich interessieren?

DevSecOps (Development, Security, Operations, manchmal auch SecDevOps) schliesst den Themenkomplex Anwendungssicherheit in den DevOps-Prozess mit ein. Damit begegnet die agile Softwareentwicklung heutigen Herausforderungen der Cyber-Security. Durch Automatisieren und Schaffen einer Security-as-code-Kultur soll die Kollaboration zwischen Teams flexibel bleiben und die Sicherheit fortlaufend verbessert werden.

Was ist DevOps?

Bevor wir versuchen, den Begriff DevSecOps zu verstehen, müssen wir „DevOps“ verstehen. Was bedeutet dieser mittlerweile weit verbreitete Begriff? Er ist fast ähnlich vage wie die „Cloud“. Jedes moderne Business braucht sie beide, aber ist das etwas, was man einfach bestellen kann und geliefert bekommt? Wir verstehen unter DevOps die interdisziplinäre Zusammenarbeit zwischen Entwicklern (Developers) und Betreibern (Operators) von Software, was ermöglicht, Applikationen schnell und systematisch weiterzuentwickeln und bereitzustellen. Unser Verständnis von DevOps erklären wir im Detail unter „Was ist DevOps – was macht VSHN?“

Entstehung und Bedeutung von DevSecOps

Genau wie bei der traditionellen Trennung von Devs und Ops waren Security-Themen traditionell Aufgabe eines losgelösten Teams oder einzelner Personen. Sicherheitsbedenken wurden damit als outgesourced betrachtet und im Development eher hinten angestellt. Security als Silo, sozusagen. Security-Spezialisten sind gut darin, Sicherheitslücken zu entdecken, verstehen im traditionellen Umfeld aber nur selten, wie moderne Softwareentwicklungsteams – also eine agile DevOps-Organisation – zusammenarbeiten.
Um die Agilität und Reaktionsfähigkeit von DevOps voll ausschöpfen zu können und gleichzeitig der Anwendungssicherheit einen höheren Stellenwert zu geben, muss die Sicherheit integraler Bestandteil des Lebenszyklus sein und von Anfang an mit eingeplant werden.
Um die immer weiter zunehmende Bedeutung und Wichtigkeit der Cyber-Security zu unterstreichen, wurde deshalb der Begriff DevSecOps geformt.

DevSecOps bedeutet, dass alle, die am Softwareentwicklungsprozess beteiligt sind, mitverantwortlich für Sicherheit sind und diese fortlaufend gemeinsam verbessern, automatisieren und von Anfang an in den Entwicklungsprozess einbauen.

Security von Anfang an in DevOps-Workflows einbauen

Was wie eine Selbstverständlichkeit klingt, war (und ist) leider nicht immer so. Der klassische Entwickler macht sich mehr Gedanken über die Funktionalitäten als über die Sicherheit einer Applikation. Zusätzlich führen neue Technologien wie Container-Plattformen (bspw. Docker) und Microservices trotz der vielen Vorteile, wie der kontinuierlichen Bereitstellung von Code, auch zu neuen Problemen und Security-Bedenken, da immer kürzer werdende Releasezyklen manuell durchgeführten Tests nicht mehr standhalten können.
DevSecOps soll zu einem Umdenken führen, indem die IT-Sicherheit und Security-Features wo immer möglich in Automatisierungs-Workflows mit eingebunden werden. Die Integration bestehender Sicherheits-Teams und Mitarbeiter und eine damit einhergehende kulturelle Änderung ist hierbei ebenso wichtig wie die Auswahl der richtigen Security-Tools.
Beim DevSecOps-Ansatz soll die Sicherheit von Anfang an mit eingebaut sein und nicht nachträglich hinzugefügt oder erst nach Abschluss der Entwicklung angedacht werden. Sowohl Entwicklung, IT-Betrieb und Sicherheits-Teams müssen bezüglich Informationssicherheit sensibilisiert werden und am gleichen Strang ziehen. Transparenz, kontinuierliches Feedback und gegenseitige Einblicke sind genauso wichtig wie das Teilen bekannter Bedrohungen und Sicherheitslücken. Für Entwickler erfordert dies oft ein Umdenken, da diese Prozesse nicht immer Bestandteil der Anwendungsentwicklung waren.

DevSecOps Automatisierung = Automatisierung der Sicherheit

Eine erfolgreiche Anwendung des DevSecOps-Prinzips setzt die Automatisierung von sich wiederholenden Aufgaben und Checks voraus, da manuelle Sicherheitsprüfungen zum einen viel Zeit beanspruchen, zum anderen auch fehleranfälliger sind.
Technologien, die DevSecOps erleichtern, sind Container und Microservices: DevOps-Sicherheitspraktiken müssen angepasst werden, da diese nicht für statische oder manuelle Tests geeignet sind. Die Informationssicherheit muss im gesamten Applikationszyklus integriert sein und kontinuierlich verbessert werden. Moderne agile Teams nutzen bereits automatisierte Validierungs- und Testpunkte innerhalb der DevOps-Pipelines, um die Sicherheit von Applikation und Code zu erhöhen und gleichzeitig schnelle Releasezyklen zu ermöglichen. Wenn die Tests und Checks nicht in die CI/CD-Pipelines integriert werden können, wird der Entwicklungsprozess die Sicherheitsprüfung voraussichtlich umgehen, was wiederum zu Sicherheitslücken führen kann.
DevSecOps macht die Sicherheit also zum festen Bestandteil im gesamten Prozess der Entwicklung. DevOps-Teams müssen die Sicherheit von Anfang an stufenweise einbauen und so gut es geht automatisieren, um sämtliche Daten, Microservices, Container und CI/CD-Prozesse kontinuierlich testen und schützen zu können. Integriertes Testing sollte dabei in Echtzeit dem Team einen Überblick geben können und Sicherheitslücken und Bugs schnell erkannt und geschlossen werden.

Fazit: Sicherheit ist heute wichtiger denn je

Fast tägliche Meldungen über Cyberangriffe, Sicherheitslücken, Datenverluste und lasche Security-Standards grosser Konzerne rufen uns immer wieder in Erinnerung, wie wichtig Security heute ist. Security sollte auch in DevOps-Teams zum Standardrepertoire gehören und mit heutigen Ansätzen und Tools ist der Zusatzaufwand meist überschaubar.
Durch die kurzen Entwicklungszyklen heute ist es möglich, früher zu testen und damit Probleme früher zu erkennen. Die Integration von Anwendungssicherheit bedeutet demnach auch, Security- und Testing-Tools bereits im Entwicklungsprozess einzusetzen und nicht erst im Live-Betrieb der Applikation.

Lohnt sich DevSecOps?

Natürlich bedeutet die Integration von Security in den DevOps-Prozess mehr Aufwand (als es nicht zu machen), langfristig lohnt sich dieses Investment aber. Agilität und Sicherheit lassen sich nicht nur verbinden, sie profitieren sogar voneinander, wenn das Team Transparenz, Offenheit und das Weitergeben von Know-How lebt. Und spätestens mit den Negativschlagzeilen aus der jüngeren Vergangenheit sollte jedem klar sein, dass wer bei Security spart, immer am falschen Ende spart.

SIGS DevSecOps Forum

Aarno, unser CTO, hat am SIGS DevSecOps Forum vom Di. 04.12.2018 bei der Mobiliar (Bern) einen Talk zum Thema Continuous (Security) improvement in the DevOps process gehalten.

Die Slides zu Aarnos Vortrag findest du hier:

Continuous security improvements in the DevOps process from Aarno Aukia

Weiterführende Links

In der agilen Softwareentwicklung gibt es auch den Begriff „nach links verschieben“ („shift left“), was soviel bedeutet wie, die Validierung in frühere Phasen der Entwicklung zu verschieben (siehe auch DevSecOps.org).
Oder Security wird als Customer Feature behandelt anstatt nicht-funktionale Requirements in das Product Backlog hinzuzufügen (Michele Chubirka aka „Mrs. Y“ auf postmodernsecurity.com).

Wie stehst du zu DevSecOps?

Was bedeutet das Thema DevSecOps für dich? Ist es für dich bereits der neue Standard oder nur eine weitere Etappe auf dem Weg zu GitOps? Über dein Feedback zum Thema würden wir uns sehr freuen, über @vshn_ch, per Mail oder das Kontaktformular unten.

Egal in welchem technischen Bereich der Softwareentwicklung du tätig bist, vermutlich musst du die Applikationen, die ihr aktuell entwickelt, möglichst schnell auf den Markt bringen.

Eure Kunden können nicht ewig warten – die Softwareentwicklung muss beschleunigt werden.

Zeit ist Geld und ein überaus kostbares Gut, insbesondere wenn ihr kurz vor der Markteinführung eurer neuesten Killerapplikation steht. Eure Kunden können nicht ewig warten und du musst deine Applikationen so schnell wie möglich auf den Markt bringen, wenn du in der schnelllebigen Techwelt bestehen möchtest.
Vielleicht wirst du auch intern dazu gedrängt, den Time-to-Market so kurz wie möglich zu halten.
Du kannst nicht erst interne Ressourcen aufbauen, Kollegen schulen und Erkenntnisse sammeln. Du musst den Konkurrenten immer einen Schritt voraus sein. IT-Teams müssen heutzutage immer mehr leisten, deshalb müssen sie intelligent geführt werden.

Häufige Probleme bei der Einführung von Applikationen

Der Weg bis zum Release einer Applikation kann steinig sein und viele Irrwege oder sogar Sackgassen aufweisen. Deshalb ist es so wichtig, jede kleine Optimierung oder Änderung in einer oder mehreren Testumgebungen zu prüfen, bevor sie in der für den Endnutzer sichtbaren Produktionsumgebung implementiert werden. Je früher ein Bug in der App oder in der Umgebung gefunden wird, desto schneller und einfacher kann er behoben werden.
Zu den teuersten und zeitaufwändigsten Fehlern zählen Abweichungen zwischen Test- und Produktionsumgebungen. Diese führen dazu, dass sich die Applikation während des Testings korrekt verhält, aber in der Produktionsumgebung plötzlich Fehler auftauchen, obwohl die gleiche Applikationsversion implementiert wurde und du weisst nicht, welche Änderungen zu den Problemen geführt haben. Die Folgen reichen von Fehlermeldungen bis hin zu katastrophalen Ausfällen in öffentlich zugänglichen Applikationen und das Resultat kann in einem langfristigen Imageschaden für dein Unternehmen enden.
Ein weiteres sicherheitsbezogenes Problem besteht darin, Test- und Produktionsumgebungen voneinander zu trennen, um zu verhindern, dass fehlerhafte Applikationen in der Testumgebung echte Kundendaten beschädigen.
Anstatt Dev-, Test- und Produktionsumgebungen manuell zu synchronisieren und diesen Aufwand in jedem Prozessschritt zu wiederholen, kann diese Arbeit auch mithilfe von bewährten cloud-basierten Tools automatisiert werden.

Warum solltest du Applikationen in die Cloud migrieren?

Möglicherweise zögerst du noch aus verschiedenen Gründen, eure Applikationen in die Cloud zu migrieren. Vielleicht bist du an die klassische Vorgehensweise zum Entwickeln und Testen von Applikationen gewöhnt. Vielleicht scheust du auch mühsame Migrationsprozesse oder ihr verfügt einfach nicht über das nötige interne Know-how oder die Ressourcen, um eine Cloud-Migration zu stemmen.
Allerdings kann ein gut vorbereitetes DevOps-Team, welches das Potenzial der Cloud voll ausschöpft, das Deployment von Applikationen rasant beschleunigen, ohne signifikante Erhöhung des Personals oder der langfristigen Kosten. Dadurch kann es deutlich einfacher werden, die Applikation später zu skalieren und es können zusätzlich nützliche Hilfsdienste genutzt werden.
Indem du unterschiedliche Umgebungen mittels der Open Source Software Docker vereinheitlichst, kannst du das weltweite Ökosystem und den globalen Erfahrungsschatz der Community nutzen. Je mehr Teile des Prozesses du automatisieren und integrieren kannst, desto effizienter kannst du deine Anwendung entwickeln und auf den Markt bringen.

White Paper „5 Schritte für eine erfolgreiche Migration von Applikationen in die Cloud”

Zusammengefasst ist die Migration in die Cloud eine sehr weitreichende Geschäftsentscheidung, deshalb solltest du dich zuvor ausführlich informieren. Lade unser White Paper „5 Schritte für eine erfolgreiche Migration von Applikationen in die Cloud” herunter um zu erfahren, wie du die Cloud für deine Software- und Applikationsentwicklungsziele nutzen und wie ihr als Team und euer Unternehmen als Ganzes davon profitieren könnt.

DevOps erfordert drei Dinge: Menschen mit der richtigen Einstellung, gemeinsame Prozesse und die richtigen Tools. Docker Software Container tragen dazu bei, diese Herausforderungen zu lösen und bieten eine standardisierte Plattform für die Entwicklung und den Betrieb von Applikationen.

Container aus der Sicht des Entwicklers

Aus der Perspektive einer Webagentur stellt jedes Projekt andere Anforderungen an das Zielsystem, wie z. B. unterschiedliche Versionen von Programmiersprachen und Frameworks. Diese Kombinationen müssen in der Entwicklungsphase mittels Continuous Integration (CI) eingehend getestet werden, was bei traditionellen Systemen zeitaufwändig und fehleranfällig ist.
Eine Virtualisierung mittels Containern, wie z. B. mit Docker, schafft da Abhilfe. Docker verwendet sogenannte „Images”, also Software-Zusammenstellungen, um einzelne Instanzen einer App zu starten – sogenannte Container. Anders als traditionelle virtuelle Maschinen umfassen diese Images kein Betriebssystem und sind deshalb kleiner und schneller. Ideal für Continuous Integration.
Aus Sicht des Softwareentwicklers ist es einfach, die Pipelines mit Docker, beispielsweise innerhalb von GitLab CI, zu konfigurieren. Man muss nur das Image spezifizieren und der Runner kümmert sich um alles Weitere. Die Applikation wird somit enkapsuliert getestet und erfordert keine weitere Software auf dem Server.
Docker nutzt Ressourcen effizienter als traditionelle Systeme im CI-Umfeld und bietet eine echte Zeitersparnis dank einfacherer Konfiguration.

Container aus der Sicht des Betreibers

Docker-Container sind eine standardisierte und effiziente Möglichkeit, Software mit allen zusätzlich erforderlichen Tools zu bündeln. Dies trägt zum Einen dazu bei, externe Abhängigkeiten zur Laufzeit zu verringern, sodass die richtigen, zu verwendenden Versionen von PHP, Java usw. mit allen erforderlichen Modulen, Erweiterungen und Plugins nicht separat auf dem Server verwaltet werden müssen.
Zum Anderen ist die Änderung des Applikationscodes und eine Änderung des Applikationsservers nun identisch: Eine neue Version eines Container-Images wird automatisch erstellt und in der Testumgebung deployed und anschliessend kann das geprüfte Image auch in der Produktionsumgebung ausgerollt werden.

Die Vorteile der Standardisierung von Software-Containern ähneln den Vorteilen von Containern in der Logistikbranche.

• Container standardisieren die Handhabung von Inhalten: In der Logistikbranche verfügen alle Container über die gleichen Aufnahmepunkte in den Ecken – egal, ob der Inhalt des Containers flüssig, fest oder gasförmig ist. In der Software sind Entrypoint, Listenport und Storage-Volumes exakt gleich definiert, ungeachtet davon, ob PHP, Java oder .NET Core ausgeführt werden soll.
• Die Containertechnologie ist portabel, so dass sie ebenso wie andere Transportmittel in allen Infrastrukturen und bei allen Anbietern gleich funktioniert.
• Dank Standardisierung sind Container effizienter: So wie ein Containerschiff mit der gleichen Mannschaft 21.000 verschiedene Container transportieren kann, so kann ein PaaS-Anbieter hunderttausende Container in unterschiedlichen Kundeninfrastrukturen und bei verschiedenen Cloud-Anbietern betreiben.

Deshalb wird die Lösung in der Software-Logistik als Container-Orchestrierung bezeichnet, deren bekannteste Umsetzung Kubernetes ist. Sie standardisiert und automatisiert Software-Betriebsprozesse wie Deployment/Update, Skalierung, Load-Balancing, Service-Discovery, Storage-Volume-Management oder Monitoring, Backup, Verteilung von Containern auf mehrere Server sowie die Isolation von mehreren Applikationen, Testumgebungen, Teams und/oder Kunden.

Was bedeutet das für dich – solltest du deine Applikation containerisieren?

Möglicherweise gibt es viele Gründe, warum du noch nicht auf Docker oder Containertechnologien im Allgemeinen setzt. Vielleicht bist du an die klassische Vorgehensweise zum Entwickeln und Testen von Applikationen mittels traditioneller VM-Technologie gewöhnt. Vielleicht scheust du auch mühsame Migrationsprozesse oder ihr verfügt nicht über das nötige interne Know-how oder Ressourcen. Oder du hast eine Legacy-Applikation, die sich nicht so einfach in die Cloud übertragen oder migrieren lässt.
Solltest du also auf diesen Zug aufspringen – oder um bei der gleichen Metapher zu bleiben – auf dieses Schiff steigen?
Ein gut vorbereitetes DevOps-Team, welches das Potenzial der Containertechnologie voll ausschöpft, kann die schnelle Bereitstellung (Deployment?) von Applikationen ohne signifikante Erhöhung von Personal oder Kosten stemmen. Mithilfe von Containertechnologien wie Docker, Kubernetes oder OpenShift ist es sehr viel einfacher, deine Applikation in die Cloud zu migrieren.
Darüber hinaus wird das spätere Skalieren der Applikation sehr viel einfacher, Zugriff auf nützliche Hilfsdienste wird ermöglicht und die Applikation insgesamt einfach zukunftssicherer. Wenn du also bisher mit einer Legacy-Applikation gearbeitet hast, lohnt es sich wahrscheinlich für die Zukunft, jetzt die Zeit und Ressourcen zu investieren, um die Applikation bereit für Containertechnologien zu machen.
Indem unterschiedliche Umgebungen mittels der Open Source Software Docker vereinheitlicht werden, kann das weltweite Ökosystem und der globalen Erfahrungsschatz der Community genutzt werden. Je mehr Teile des Prozesses automatisiert und integriert werden, desto effizienter kannst du deine Applikation entwickeln und auf den Markt bringen. Deine Kunden und Teamkollegen werden es dir danken.

White Paper „5 Schritte für eine erfolgreiche Migration von Applikationen in die Cloud”

Wenn du mehr über die Migration deiner Applikation in die Cloud erfahren möchtest, lade unser kostenloses White Paper „5 Schritte für eine erfolgreiche Migration von Applikationen in die Cloud” herunter und finde heraus, wie du die Cloud für deine Software- und Applikationsentwicklungsziele nutzen kannst.

DevOps ist ein weit verbreiteter Begriff, aber leider ähnlich vage wie „Cloud“: zwar weiss jeder, dass er es will oder braucht und dennoch ist es nicht etwas, was man einfach bestellen und geliefert bekommen kann.
Wir verstehen unter DevOps die interdisziplinäre Zusammenarbeit zwischen Entwicklern (Developers) und Betreibern (Operators) von Software, um die Applikationen schnell und systematisch einzusetzen.

Ähnlich wie bei Agiler Softwareentwicklung (z.B. Scrum) – bei dem der „Product Owner“ mit den Softwareentwicklern zusammen die jeweils nächstfolgenden Entwicklungsschritte spezifiziert und fertiggestellte Arbeiten abnimmt – fördert dies die Kommunikation zwischen den beteiligten Parteien und vermindert Missverständnisse und dadurch teure Fehler.
Die Förderung der Zusammenarbeit zwischen Entwicklern und Betreibern steht im Kontrast zur bisherigen Praxis, diese Teams strikt zu trennen – sei dies aus Gründen der Gewaltentrennung (kein Zugriff der Entwickler auf Produktionsdaten) oder weil Entwickler und Betreiber unterschiedliche Anforderungsprofile erfüllen mussten (Programmierkönnen, Bereitschaftsdienst).
Unterdessen sind aber eine Reihe von Erkenntnisse und bewährte Verfahren aus der Softwareentwicklung auch in den Betriebsprozessen angekommen:

1. Infrastructure as Code: Die Beschreibung und Konfiguration der Infrastruktur-Komponenten mittels Skripts, um wiederkehrende Aufgaben (z.B. Installation eines Servers oder Installation / Upgrade einer Applikation) schnell und zuverlässig zu automatisieren. Je nach Anwendungsfall und Umgebung gibt es dafür unterschiedliche Werkzeuge – Docker, Ansible, Puppet, SaltStack, etc. – die bereits eigene Frameworks und Ökosysteme mit fertigen Bausteinen für Standardkomponenten mitbringen.
2. Testsysteme: Wenn das Aufsetzen eines Servers komplett automatisiert ist, minimiert dies den Aufwand, einen oder mehrere Testserver zu erstellen. Wenn die Entwickler einen Testserver benutzen können, der gleich aufgesetzt ist wie ein Produktionsserver, können sie Fehler finden, bevor sie auf der Produktion auftreten.
3. Versionierung: Ist die Infrastruktur oder zumindest Teile davon in Code abgebildet, so kann man diesen mit bekannten Code-Versionierungstools (Git, SVN, etc.) verwalten. Dies ermöglicht die Nachvollziehbarkeit von Änderungen an der Infrastruktur („Wer hat was wann geändert?“, „Warum funktioniert das plötzlich nicht mehr, obwohl an der Software nichts geändert wurde?“) und das lückenlose Zurückrollen von Änderungen, falls doch mal ein Fehler auftreten sollte.
4. Kontinuierliche Integration des Infrastrukturcodes: So wie auch die eigentliche Applikation automatisch bei jeder Änderung kompiliert und sowohl komponentenweise als auch gesamtheitlich funktional getestet wird, können auch die Anforderungen an die Infrastruktur anhand automatisierter Tests verifiziert werden. Durch das möglichst frühzeitige Erkennen eines Fehlers werden die Auswirkungen minimiert. Zum Beispiel kann das Publizieren von Änderungen gesperrt werden, falls Fehler beim Testen aufgetreten sind.

Umgekehrt fliessen auch Erfahrungen aus dem Betrieb in moderne Softwarearchitekturen ein:

1. Paketisierung und Versionsverwaltung: Damit über den gesamten Qualitätssicherungsprozess von Test- / Entwicklungsserver, Abnahme durch den Product Owner, evtl. externes Testen / Validieren (Beta-, User-, UX-Tests), Integration mit externen Schnittstellen (Backends, APIs) bis zur Produktion alle beteiligten Personen von der jeweils gleichen Version der Software sprechen, wird diese in einem versionierten Paket abgelegt. Die Art der Paketierung kann dabei von der Entwicklungs- (z.B. JAR bei Java, WAR bei Tomcat) oder Betriebsumgebung (z.B. DEB/RPM bei Linux, MSI bei Windows) vorgegeben oder wie z.B. im Falle von Docker auch unabhängig sein. Dies stellt sicher, dass die Software komplett (mit allen benötigten Bibliotheken) installiert und aktualisiert werden kann und automatisiert diese Schritte soweit möglich.
2. Service Oriented Architectures (SOA) und Microservices: Sobald eine Applikation in der Entwicklung so umfangreich und / oder komplex wird, dass sich mehr als eine handvoll Teams darum kümmern, ist es einfacher, die Teams in kleinere Sub-Projekte („Microservices“) aufzuteilen und die Schnittstellen dazwischen explizit zu definieren als alle Teams untereinander im gleichen „Projekt“ bezüglich Technologie, Entwicklungsfortschritt und interner Zuständigkeiten zu koordinieren. Damit können die Teams nicht nur entkoppelt voneinander weiterentwickeln, sondern könnten sogar für ihren Zweck geeignetere Technologien wählen – vorausgesetzt, die Schnittstelle zu anderen Teams ändert sich nicht. Optimalerweise wären die meisten Komponenten / Services untereinander fehlertolerant, funktionieren also bei Ausfall einer Sub-Komponente mit eingeschränkter Funktionalität weiter, wodurch das Gesamtprojekt robuster wird.
3. Configuration Management: Die meisten Applikationen haben Schnittstellen zu anderen Applikationen – zum Beispiel zu einer Datenbank oder anderen APIs / Services – und schreiben Protokolldateien. Während der Entwicklung, dem Testing in der Qualitätssicherung und für die Produktion werden unterschiedliche Endpunkte (Adressen, Zugangsdaten etc.) dafür verwendet. Dies ermöglicht die Isolation von Test- und Produktivdaten; ein Test einer neuen Version kann also nicht aus Versehen die produktiven Kundendaten löschen. Darum werden die Zugangsdaten nicht direkt im Code verwaltet, sondern in Konfigurationsdateien, die wiederum für jede Umgebung automatisch generiert oder aus Umgebungsvariablen gelesen werden können. Eine moderne Definition dafür ist zum Beispiel die Zwölf-Faktoren-Methode (http://12factor.net/de/).
4. Skalierbarkeit: Applikationen und Services, die klar definierte Schnittstellen haben, können einfach horizontal – also über verschiedene Server verteilt – skaliert werden. Dies ermöglicht dem Betrieb, den Service mehrfach, redundant und damit hochverfügbar anzubieten und auf unterschiedliche Last durch hinzufügen oder entfernen von Servern zu reagieren. Selbst diese Schritte können automatisiert werden: Es ist möglich, automatisch aufgrund der aktuellen Auslastung mehr Serverressourcen zu beziehen respektive wieder frei zu geben und abhängig vom Abrechnungsmodell der einzelnen Ressourcen Kosten nur dann zu produzieren, wenn die Leistung auch effektiv genutzt wird.

Was bringt nun die Verschmelzung von Entwicklungsmethoden und Betriebsprozessen konkret?

1. Die Automatisierung der Infrastruktur (siehe „Infrastructure as Code“ oben) macht die Infrastruktur schneller, zuverlässiger und verhindert Inkonsistenzen durch (fehlende) manuelle Schritte auf verschiedenen Systemen. Sie ermöglicht, dass Entwickler und Product Owner ihre Ergebnisse effektiv unter gleichen Bedingungen wie die Produktion testen können.
2. Die Automatisierung des Software-Lebenszyklus von der Entwicklung bis zur Produktion macht den ganzen Prozess schneller, zuverlässiger und kann optimalerweise vom Product Owner selbst nach Freigabe der neuesten Version durchgeführt werden. Dadurch geben nach den Entwicklern auch die Betreiber dem Business die Zügel für die Applikation in die eigenen Hände und stehen für Weiterentwicklungen zur Verfügung. Damit kann der Product Owner sowohl den Umfang als auch die Frequenz der Deployments bestimmen. Je häufiger ausgerollt wird, was zur Folge hat, dass der Umfang der jeweiligen Änderungen kleiner ausfällt, desto kleiner ist das Risiko von unerwünschten Nebenwirkungen und Fehlern. Tauchen dennoch einmal Fehler auf, kann der Product Owner selbst die letzte Änderung rückgängig machen und die Entwickler zur Nachbesserung aufbieten, ohne den Betrieb damit zu belangen.
3. Beides zusammen verhindert, dass die IT im Selbstzweck den kritischen Pfad des Projektes blockiert und befähigt die Entwickler und das Business zur „Selbstbedienung“. Natürlich bedeutet das auch einen Kulturwandel innerhalb eines Unternehmens: schlägt ein Deployment fehl oder treten Probleme in der Produktion auf, so müssen Entwickler und Betriebsleute das Problem zusammen beheben und sicher stellen, dass es nicht wieder vorkommt (z.B. mittels automatischem Test). Dabei ist unerheblich, warum oder wegen wem das Problem aufgetreten ist: es muss kein „Schuldiger“ gefunden, sondern der Gesamtprozess kontinuierlich verbessert werden.

Wir bei VSHN machen den ganzen Tag nichts anderes, als verschiedene Entwicklungsprozesse, verschiedene Technologien, verschiedene Backends (Datenbanken, Cache-Server, Proxies, WAFs etc.) zu automatisieren und gemäss Anforderungen unserer Kunden und / oder Entwicklungs-Partnern auf beliebiger Infrastruktur – seien das öffentliche Clouds wie Amazon, Azure, Cloudscale.ch, Cloudsigma, Exoscale.ch, Safe Swiss Cloud, Swisscom Cloud oder private, also firmeninterne Infrastrukturen auf VMware- oder Hyper-V-Basis – zu betreiben.
Wir beraten unsere Kunden bezüglich Ort der Datenspeicherung (CH, EU, international), sind auch selber bald ISO27001-zertifiziert und können zusammen mit unseren Partnern Hosting gemäss FINMA-Standard anbieten.
Unsere Kernwerte sind Vertrauenswürdigkeit und Erreichbarkeit der fachlichen Kompetenz. Vertrauenswürdigkeit und Sicherheit durch Transparenz: transparente Kommunikation der Prozesse, transparente Auftragsdefinitionen und Verrechnungsmodelle. Wir arbeiten agil mit unseren Kunden und kommunizieren regelmässig. Wir sind 24×7 rund um die Uhr erreichbar und kümmern uns proaktiv um „unsere“ Applikationen.
Wir sind VSHNeers.