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.