Softwareprodukte werden heutzutage in der Regel in Teams entwickelt, die ihre Arbeitsergebnisse in einer zentralen Build-Umgebung zu einer Einheit zusammenführen müssen. Der Continuous Integration-Ansatz (CI) sorgt dafür, dass neue Softwarekomponenten sofort flächendeckenden Tests unterzogen und danach zusammengeführt werden. Anstatt dies beispielsweise nur einmal täglich zu machen, werden im Rahmen des CI-Ansatzes neue Software-Builds erstellt, sobald eine Komponente für die Integration zugelassen wurde.

Softwareentwicklung und Kompilierung: ein Blick in die Vergangenheit

Eine Softwareanwendung setzt sich in der Regel aus einer Vielzahl einzelner Module zusammen. Dementsprechend ist die Vorgehensweise bei der Softwareentwicklung an diese speziellen Gegebenheiten angepasst, sodass das Gesamtprojekt häufig analog zu diesen Modulen von mehreren einzelnen Teams parallel entwickelt wird. Früher wurden Änderungen und Erweiterungen an dem Softwareprodukt in vielen Fällen in Form eines „Tagewerks“ realisiert. Konkret bedeutet das, dass die Zusammenführung der Änderungen, die von den isolierten Entwicklerteams innerhalb eines Arbeitstages erschaffen wurden, nur einmal täglich im Rahmen einer Kompilierung auf dem zentralen Build-Server konsolidiert wurden.

Erst danach wurden die neuen Funktionen und Features des Softwareprodukts im Kontext der erweiterten Codebasis getestet. Dieser traditionelle Ansatz der Softwareentwicklung birgt enorme Gefahren und Risiken. Falls ein neu geschaffener Code nicht kontinuierlich integriert und flächendeckenden Tests unterzogen wird, werden eventuelle Fehler im Code zu spät erkannt. Die Folgen sind zeitintensive und kostspielige Rückkopplungsprozesse. Vor der Einführung der Continuous Integration mussten einzelne Teams auf die Fertigstellung anderer benötigter Softwarekomponenten anderer Entwicklerteams warten, was sich auf die Effizienz des gesamten Projekts äußerst negativ auswirkt.

Continuous Integration im Überblick

Die Continuous Integration-Methoden, die in innovativen Unternehmen in Kombination mit DevOps zum Einsatz kommen, beziehen sich auf die kontinuierliche Integration einzelner Softwarekomponenten in die Gesamtcode-Basis (Codebase) des Softwareprojekts. Die wesentlichen Vorteile dieser Arbeitsweise spiegeln sich in den überschaubaren Schritten wider, die einen kontinuierlichen Arbeitsfluss fördern und die Möglichkeit bieten, Fehler in der Programmierung frühzeitig zu erkennen und zu beseitigen. Durch die gesteigerte Arbeitseffizienz ergibt sich eine höhere Softwarequalität. Die Arbeitsweise im Rahmen des Continuous Integration-Ansatzes unterscheiden sich stark, von der im obigen Absatz beschriebenen traditionellen Vorgehensweise. In Unternehmen, bei denen die kontinuierliche Integration zum Einsatz kommt, wird eine hohe Flexibilität gefordert.

Konkret bedeutet das, dass die in den kleineren Schritten vorgenommenen Änderungen oder Erweiterungen an dem Softwareprodukt in regelmäßigen Abständen zusammengeführt und getestet werden. Die Einspeisung wird über ein Versionsverwaltungssystem wie beispielsweise GitHub oder Bitbucket in einem unterteilten Code-Repository realisiert. Auf diesem Wege lassen sich Versionskontrollen durchführen, indem Build-Prozesse automatisiert werden, sodass stets die aktuelle Code-Version aus dem Repository übernommen wird.

Vor- und Nachteile von Continuous Integration

Obwohl der Continuous Integration-Ansatz zahlreiche Vorteile mit sich bringt, zeigt sich im Alltag auch, dass CI nicht nur Vorteile hat. Dass die langwierige Integrationsphase am Ende eines Softwareprojekts abgekürzt werden kann, lässt sich nicht beschreiten. Auftauchende Probleme können frühzeitig beseitigt werden. Für eingespielte Teams ist die Umstellung auf Continuous Integration jedoch oft mit Komplikationen verbunden. Anstatt dann effizienter zu arbeiten, kann das Verfahren sogar mehr Zeit in Anspruch nehmen.

Vorteile:

– kontinuierliches Feedback

– Fehler lassen sich frühzeitig identifizieren

– eine granulare Arbeitsweise wird gefördert

aktuelle und funktionsfähige Versionen sind stets verfügbar

– alle Änderungen werden im Detail protokolliert

Nachteile:

– es müssen flächendeckende Test-Abläufe entwickelt und implementiert werden

– Umstellung von einem gewohnten Arbeitsprozess

– es werden zusätzliche Server und Entwicklungsumgebungen benötigt

Welche Tools kommen bei Continuous Integration zum Einsatz?

Der Continuous Integration-Ansatz lässt sich grundsätzlich ohne spezielle Tools umsetzen. Das ist jedoch oft mit viel Aufwand verbunden und erfordert einiges an Disziplin. Aus diesem Grund ist es viel einfacher, sich die Arbeit mit den richtigen Tools zu erleichtern. Diese helfen meist bei der Versionskontrolle und beim Kompilieren und Erstellen von Builds. Die bekanntesten CI-Werkzeuge sind:

Jenkins: Hierbei handelt es sich um ein bekanntes Java-Programm, das im Rahmen moderner Continuous Integration und Continuous Delivery-Prozesse eingesetzt wird.

Travis CI: Dieses Tools ist insbesondere wegen seiner reibungslosen Integration mit GitHub beliebt. Für Open Source-Projekte ist es kostenlos, für kommerzielle Softwareprojekte muss eine offizielle Lizenz gekauft werden.

Bamboo: Auch hier handelt es sich um ein Tool, das in der Programmiersprache Java erstellt ist. Wie Travis CI ist es für kommerzielle Projekte normalerweise kostenpflichtig, während es für Open Source-Projekte kostenlos genutzt werden kann.

CodeShip: Dieses Tool basiert auf der Container-Technologie, die von IT-Größen wie Google, Microsoft und Red Hat aktiv weiterentwickelt wird und aus der modernen Softwareentwicklung nicht mehr wegzudenken ist.

Einsatzgebiete

Continuous Integration ist insbesondere im Umfeld agiler Softwareentwicklung in Kombination mit DevOps sehr beliebt. Dieser moderne Ansatz hat immer zum Ziel, in kleinen, übersichtlichen Schritten zu arbeiten. Heutzutage gibt es keine Rechtfertigung, ein Softwareprojekt ohne einen Continuous Integration-Ansatz zu betreiben. Dies liegt vor allem an dem Erfahrungsschatz sowie der großen Anzahl an verfügbaren Tools. CI kann sein volles Potenzial jedoch erst dann entfalten, wenn alle Team-Mitglieder optimal in alle Prozesse eingebunden werden und das System mittragen. Aus diesem Grund kommt einer reibungslosen Kommunikation eine sehr wichtige Rolle zu.

Mit dem Begriff Continuous Deployment wird ein Entwicklungs- und Veröffentlichungs-Ansatz für Software-Produkte beschrieben, der sich mit der wachsenden Bedeutung von Webanwendungen in den letzten Jahren durchgesetzt hat. Im Rahmen des Continuous Deployment-Ansatzes werden Änderungen an dem Software-Produkt kontinuierlich veröffentlicht und Nutzern zugänglich gemacht.

Continuous Deployment, Continuous Integration und Continuous Delivery

Bei Continuous Deployment (CD) und Continuous Delivery (CI) handelt es sich um Teilbereiche, die dem Dachbegriff Continuous Integration entsprungen sind. Prinzipiell geht es bei diesen Prozessen darum, dass Software-Produkte kontinuierlich weiterentwickelt werden. Dabei liegt die Perfektionierung der entwickelten Software im Fokus aller Bemühungen, wobei jedoch auch in erster Linie auf eine kontinuierliche Auslieferung des Produkts geachtet wird. Durch den Einsatz flächendeckender automatisierter Tests während des gesamten Entwicklungsprozesses kann somit gewährleistet werden, dass sich neu zugefügte Komponenten nicht negativ auf die Lauffähigkeit und Performance des Software-Produkts auswirken und dass sich keine Fehler unbemerkt in das System einschleichen. Nichtsdestotrotz bleibt Continuous Integration ein kontroverses Thema, das sowohl zahlreiche Vorteile als auch einige Nachteile mit sich bringt.

Die Grundlagen im Überblick

Continuous Delivery verspricht prinzipiell eine bessere Qualität des entwickelten Software-Produkts. Somit rückt das altbekannte Phasenmodell, das in der Softwareentwicklung bereits seit Jahrzehnten erfolgreich eingesetzt wird, in den Hintergrund. Alle neu entwickelten Komponenten und Änderungen am System werden im Rahmen des CI/CD-Ansatzes in Kombination mit modernen DevOps-Methoden umfassend getestet, ehe sie in die laufende Software integriert werden. Für Anbieter und Kunden bietet Continuous Deployment eine Vielzahl unterschiedlicher Vorteile. So kann beispielsweise das laufende Software-Produkt jederzeit durch eine bessere Version ausgetauscht und mit neuen Funktionen und Features angereichert werden, ohne dass Nutzer lange auf die Implementierung einer neuen Version warten müssen. Dies ist insbesondere für Webanwendungen von Vorteil, da der Betrieb der laufenden Software während der Aktualisierung auf eine neue Version nicht unterbrochen wird und Nutzer in der Regel davon nichts mitbekommen. Der wesentliche Nachteil des CI/CD-Ansatzes spiegelt sich in der Tatsache wider, dass sich tiefgreifende Änderungen nur schwer implementieren lassen. Oftmals bringt das eine gigantische Umstellung mit sich, da alle Tests und Testroutinen an die neuen Bedingungen angepasst werden müssen.

Continuous Deployment als Basis

Der Continuous Deployment-Ansatz kann als Hintergrund des gesamten Systems betrachtet und ist eng an DevOps gekoppelt. Das Software-Produkt wird kontinuierlich weiterentwickelt, sodass es jederzeit freigegeben und an den Nutzer bzw. Kunden ausgeliefert werden kann. Konkret bedeutet das, dass der gesamte Entwicklungsprozess im Rahmen des Continuous Deployment durch automatisierte Tests in isolierten Testumgebungen abgesichert wird, ehe neue Komponenten oder Versionen des Systems in die laufende Software integriert werden. Im Rahmen des Continuous Deployment-Ansatzes werden alle Änderungen an dem Software-System nach strengen Kriterien und vollautomatisch in die laufende Software implementiert. Auf diese Weise wird eine Continuous Delivery (kontinuierliche Auslieferung) des Software-Produkts ermöglicht.

Gefahren beim Continuous Deployment

Der Einsatz von Continuous Deployment bringt auch einige potenzielle Probleme mit sich, die bei monolithischen Entwicklungsansätzen kaum eine Rolle spielen. So ist im Rahmen des Continuous Deployment die Gefahr relativ groß, dass innerhalb eines einzelnen Teams oder eines gesamten Projekts der Fokus der Arbeit unpräzise und falsch gesetzt wird, was katastrophale Folgen für den Ausgang des Projekts haben kann. Statt eine kontinuierliche Verbesserung des Software-Produkts anzustreben, wird in erster Linie eine möglichst hohe Deployment-Frequenz anvisiert. Ein beachtlicher Teil des Erfolgs des Continuous Deployment-Ansatzes hängt auch in hohem Maße von den eingesetzten Testkriterien und Testumgebungen ab, die bei der automatisierten Implementierung der Änderungen in die laufende Software zum Einsatz kommen. Falls schwerwiegende Fehler gar nicht erkannt oder nur zu spät identifiziert werden, sind infolgedessen in vielen Fällen umfangreiche Revisionen notwendig, um die eingeschlichenen Fehler zu beheben. Außerdem müssen für viele Neuerungen und Änderungen eigene Tests geschrieben werden, welche wiederum Fehler enthalten können.

Chancen und Möglichkeiten

Continuous Deployment kann unter einer streng strukturierten Arbeits-Arbeitsaufteilung sowie einer klar definierten Zielführung durchaus von großem Nutzen sein und erstklassige Ergebnisse liefern. Dieser Ansatz der Softwareentwicklung wird von vielen Entwicklern und Unternehmen, wie beispielsweise Red Hat oder Microsoft, in erster Linie wegen seiner Geschwindigkeit und seiner hohen Nutzerfreundlichkeit hochgeschätzt. Continuous Delivery ist von seinem Umfang her eher an die Bedürfnisse mittelgroßer und großer Software-Projekte ausgerichtet. Da die entsprechenden Systeme und die benötigte Infrastruktur in vielen Fällen von Grund auf aufgebaut, getestet und implementiert werden müssen, ist der Umstieg auf Continuous Deployment, Continuous Integration und Continuous Delivery für viele Unternehmen mit hohem Aufwand und intensiven Kosten verbunden. Nach der erfolgreichen Implementierung bringt dieser Ansatz der Softwareentwicklung jedoch beachtliche wirtschaftliche Vorteile mit sich. Neue Funktionen und Features lassen sich dann schneller umsetzen und für den Nutzer bzw. Kunden freigeben.

Plattformunabhängigkeit bezieht sich auf Software, die auf einer Vielzahl von Hardwareplattformen oder Softwarearchitekturen ausgeführt werden kann, Sie wird als plattformunabhängig, plattformübergreifend, portabel oder auch als Cross-Plattform bezeichnet.

Plattformunabhängige Software kann in einer Vielzahl von Umgebungen ausgeführt werden, wodurch die Verwendung im gesamten Unternehmen vereinfacht wird. Sie erfordert weniger Aufwand und Planung als der Einsatz einer plattformabhängigen Software.

Die Bedeutung von Plattformunabhängigkeit ist, dass der von Java kompilierte Code (Bytecode) auf allen Betriebssystemen ausgeführt werden kann. Ein Programm ist in einer Sprache geschrieben, die für Menschen lesbar ist. Ein Compiler ist ein Programm, das den Quellcode eines anderen Programms aus einer Programmiersprache in ausführbaren Code übersetzt, wodurch die Software plattformunabhängig wird.

Warum ist es so gefragt?

Wenn Sie ein Softwareprodukt entwickeln und verkaufen, kann Ihnen die Unterstützung von Java für die Plattformunabhängigkeit dabei helfen, in mehr Märkten zu konkurrieren. Anstatt beispielsweise ein Produkt zu entwickeln, das nur unter Windows ausgeführt werden kann, können Sie ein Programm schreiben, das außer mit Windows ebenso mit OS / 2, Solaris und Linux funktioniert.

Das Bedürfnis nach Plattformunabhängigkeit entstand aufgrund der unterschiedlichen Betriebssysteme, die heutzutage genutzt werden. Wenn ein für Windows geschriebener Code unter Mac OS ausgeführt werden sollte, hatte das multiple Fehlermeldungen zur Folge und der Code musste entsprechend der jeweiligen Hardware- und Maschinenkonfiguration geändert werden. Die dadurch für Programmierer verursachten Probleme, machten die Code-Portabilität zum Gebot der Stunde, da der Gebrauch des Internets rasant zunahm.

Plattformunabhängige Sprachen

Java ist die bekannteste plattformunabhängige Sprache. Einige andere P.I. Sprachen sind Ruby, Lisp, Schema, Scala, Clojure, Python, Perl, PHP, C #. Außerdem können die Kriterien für die Entscheidung über die Plattformunabhängigkeit von Person zu Person variieren. Beispielsweise sind Sprachen wie C / C ++ auf Quellcodeebene plattformunabhängig, verlieren jedoch die Plattformunabhängigkeit, sobald der Code kompiliert wird, da nativer Code plattformspezifisch ist.

Java hingegen wird aufgrund seines Bytecodes als plattformunabhängig bezeichnet. Java-Code wird zuerst zu Bytecode kompiliert und in eine JAR-Datei gepackt. Diese Datei wird dann auf verschiedenen Plattformen identisch ausgeführt, z. B. auf verschiedenen Versionen von Windows und Linux. Dies ist in erster Linie der Grund für die Beliebtheit von Java, da es das Versprechen „Write Once Run Anywhere“ einhält.

Plattformunabhängigkeit und Virtualisierung / virtuelle Server

Die Distributed Management Task Force (DMTF) ist eine Organisation mit mehr als 4.000 aktiven Mitgliedern, 44 Ländern und fast 200 Organisationen. Es ist die Branchenorganisation, die die Entwicklung, Annahme und Förderung interoperabler Managementstandards und -initiativen leitet. Unter besonderer Berücksichtigung des Cloud Computing führte die DMTF das Open Virtualization Format (OVF) ein und unterstützte mehrere Initiativen für interoperable Cloud-Technologien, wie den Open Cloud Standards Incubator, die Cloud Management Working Group (CMWG) und die Cloud Audit Data Federation Working Gruppe (CADFWG).

Das Open Virtualization Format (OVF)  ist ein herstellerunabhängiges Format für Verpackungsstandards, das die Portabilität und Bereitstellung virtueller Appliances auf verschiedenen Virtualisierungsplattformen erleichtert. OVF kann von unabhängigen Softwareanbietern (ISVs) zum Packen und sicheren Verteilen von Anwendungen verwendet werden, und Systemabbilder können auf mehreren Plattformen importiert und bereitgestellt werden, wodurch eine plattformübergreifende Portabilität ermöglicht wird. Die Spezifikation ist das Ergebnis der Zusammenarbeit von Dell, HP, IBM, Microsoft, VMWare und XenSource bei der Definition eines plattformunabhängigen Virtualisierungsformats für das Packen von Software-Appliances. Ein erster Entwurf wurde der DMTF im Jahr 2008 vorgelegt. Derzeit hat die DMTF die Version 1.1.0 der Spezifikation veröffentlicht, die auch als ANSI-Standard INCITS 469-2010 (American National Standards Institute) ratifiziert wurde. Der Hauptzweck der Spezifikation besteht darin, ein plattformneutrales Format für die Verteilung von Softwarepaketen bereitzustellen.

Plattformunabhängigkeit und Betriebssysteme

Ein Betriebssystem ist reine Software, während eine Plattform die Kombination zwischen dem Betriebssystem und der Art der Hardware ist, wie der CPU, auf der es ausgeführt wird. Java wurde so konzipiert, dass sie auf mehreren Hardwaretypen und Betriebssystemen ausgeführt werden kann. Durch die Plattformunabhängigkeit von Java, können Unternehmen mit mehreren Computertypen eine spezielle Anwendung einmal schreiben und von praktisch jedem verwenden lassen, anstatt mehrere Versionen desselben Programms schreiben, verteilen und warten zu müssen.

BYOD und Plattformunabhängigkeit

Mit BYOD können Unternehmen wie auch Lehrer allgemeine Funktionen, die in den meisten Mobilgeräten zu finden sind, nutzen. Es enthält u. a. Tools zur Datenorganisation und webbasierte Anwendungen. Kontinuierlich entstehen neue Funktionen und machen BYOD langfristig zu einem ausgesprochen nützlichen Produkt für die Technologieintegration. Mit der Konvergenz von weit verbreitetem Breitband und dem Wachstum von leistungsstarken, plattformunabhängigen webbasierten Werkzeugen, ist BYOD sowohl pädagogisch als auch unternehmensspezifisch wertvoll.

Im Büro und besonders auch im Homeoffice ist es leicht, mit Informationen regelrecht überschwemmt zu werden. Für effizientes Arbeiten müssen die notwendigen Daten zur Verfügung gestellt werden, aber ohne die Ablenkung mit überflüssigem Material. Wrike ist ein Werkzeug, mit dem effektive Abläufe im Team organisiert werden können.

Anforderungen an Projektarbeit heute

Auch wenn Ihre Mitarbeiter auswärts tätig sind, müssen alle mit den für ihren Projektbeitrag erforderlichen Informationen versorgt werden. Oft wird dieses Problem mit dem Versenden von E-Mails gelöst. Eine Verteilerliste für E-Mail ist aber nur eine grobe Steuerung des Informationsflusses. Viele Empfänger erhalten für sie unnötige und ablenkende Informationen. Welche Version eines Berichts die aktuelle ist bleibt oft unklar.

Arbeiten in verteilten Teams

Ob auf Geschäftsreise oder im Homeoffice, jeder Projektteilnehmer muss seinen Beitrag leisten können. Die technischen Verbindungsmittel dafür existieren, über die Schiene des Breitbandinternets können alle notwendigen Daten praktisch verzögerungsfrei übermittelt werden. Cloud Computing nutzt genau diese Übertragungen, um mit zentralen Servern Speicherplatz und Rechenleistung zur Verfügung zu stellen. Diese Dienste sind für alle Teammitglieder jederzeit abrufbar.

Es bleibt aber die Frage, wie diese Abläufe für Ihr Team organisiert werden. Alle Daten ständig an alle zu übertragen würde eine Überladung und Ablenkung bedeuten, die effektives Arbeiten nicht unterstützt und sogar behindern kann.

Der Begriff New Work

New Work bezeichnet die Idee und Umsetzung flexibler Arbeitsmodelle. Die heute zur Verfügung stehende Informationstechnologie ermöglicht einen neuen Arbeitsstil mit wesentlich mehr Wahlmöglichkeiten für jeden Ihrer Mitarbeiter, was den Arbeitsort und die Arbeitszeit betrifft. Wird dieses Modell erfolgreich umgesetzt, sind die positiven Folgen mehr Effizienz statt Leerlauf und damit auch höhere Motivation, die auch durch größere Erfolgserlebnisse gestützt wird. Damit New Work funktioniert, muss aber das Informationsmanagement richtig organisiert werden.

Wrike als Werkzeug

Die Entwickler von Wrike verfolgen das Ziel, mit diesem Tool Arbeitsgruppen effektiver und produktiver zu machen. Wrike bewerkstelligt das durch die Verwaltung, Steuerung und auch Automatisierung des Informationsflusses im Team.

Wrike wird für Projektmanagement von vielen angesehenen und erfolgreichen Firmen verwendet. Die Qualität von Wrike hat Citrix davon überzeugt, das Unternehmen Wrike zu übernehmen.

Wrike stellt einen Workspace bereit, der auf die besonderen Bedürfnisse eines Teams angepasst werden kann. Alle Teammitglieder können so auf einen gemeinsamen Terminkalender und individuell gestaltete Dashboards zugreifen.

Wrike dient auch als Ort der Speicherung der jeweils aktuellen Version von Berichten und Dokumenten, die dort für Teammitglieder abrufbar sind.

Wrike ist so entwickelt, dass der Informationsfluss steuerbar ist. Jede Information erreicht nur diejenigen Projektteilnehmer, die sie auch für ihre Arbeit brauchen.

Business Intelligence mit Wrike Analyze

Wrike Analyze kann erweiterte Analysen erstellen, die im System selbst generiert werden. Da kein Exportieren der Daten in andere Programme erforderlich ist, können auch keine Probleme mit Kompatibilität der Datenformate entstehen. Wrike lässt so oft lästige Hindernisse erst gar nicht entstehen.

Mit dieser Funktionalität werden die Projektfortschritte für die Teammitglieder dargestellt und aufbereitet. Dashboards zeigen die Arbeitsschritte und auch Problemfelder. Das System macht es damit leicht, auf noch zu wenig entwickelte Projektteile zu reagieren, bevor Lücken zu einem Problem werden.

Visualisierung spielt in Wrike eine wesentliche Rolle, weil die Entwickler den Wert von Grafiken für eine schnelle und unmittelbare Übermittlung von Informationen erkannt haben. Neben Teammitgliedern profitieren besonders das Management und Investoren von dieser Art der Darstellung.

Integration von Apps bei Wrike

Für verschiedene Aufgaben bieten sich verschiedene Apps an. Mit dieser Vielfalt ergeben sich aber natürliche Probleme der Integration. Mit Wrike Integrate lässt sich dieses Problem elegant lösen.

Vorlagen als Tools bei Wrike

Diese bereits bestehenden Vorlagen sind für bestimmte Arten von Projekten erstellt worden. Für jedes Projekt ist das Ziel, mit einer Vorlage das Management und die Zusammenarbeit eines Teams im jeweiligen Geschäftsbereich zu unterstützen.

Wenn Sie spezielle Vorlagen benötigen und eine für Sie passende Vorlage noch nicht verfügbar ist, brauchen Sie nur eine Nachricht an Wrike zu senden. Innerhalb von 24 Stunden meldet sich ein Experte für Projektmanagement bei Ihnen, um die weiteren Schritte für eine Ihnen passende Vorlage einzuleiten.

Zu den verfügbaren Vorlagen gehören Organisationsformen für das Projektmanagement. Das  Projekt wird in einzeln umsetzbare Elemente aufgeteilt, die eine Deadline erhalten. Eine solche Vorlage stellt auch den Fortschritt am Projekt dar, der so ständig evident gehalten wird.

Vorlagen existieren auch für die Einführung von neuen Produkten. Etwas anders gelagert sind Arten von Projekten, die keinen definierten Abschluss besitzen und aus einer potentiell unbegrenzten Reihe von Elementen bestehen. Zu solchen Vorlagen gehören Abläufe für die Bearbeitung von Anfragen oder für ein Ticket-System, das den Informationsfluss für einen Kundendienst steuern kann.

Bei einem Hypervisor, der auch als Virtual Machine Monitor (VMM) bezeichnet wird, handelt es sich um eine leistungsstarke Software zur Virtualisierung von Computerressourcen. Der Hypervisor weist den verschiedenen virtuellen Maschinen Rechenressourcen wie Arbeitsspeicher, CPU oder Festplattenspeicher zu. Er ist außerdem für die Trennung der virtuellen Maschinen untereinander zuständig und erlaubt den parallelen Betrieb mehrerer verschiedener Betriebssysteme auf demselben Computer.

Allgemeine Informationen zum Hypervisor

Die Virtualisierung von Computerressourcen und Betriebssystemen hat ganz neue technische Möglichkeiten mit sich gebracht. Statt ein komplettes Computersystem inklusive Hardware und Software aufzubauen, können Sie sich durch den Einsatz moderner Virtualisierungslösungen, wie beispielsweise Hyper-V oder VMware schnell und unkompliziert eine virtuelle Version davon schaffen. Virtualisierung kommt beispielsweise in der modernen Softwareentwicklung zum Einsatz, um eine sichere Test- und Entwicklungsumgebung zu schaffen. Damit dies realisiert werden kann, muss eine virtuelle Maschine auf einem physischen System betrieben werden. Zwischen diesen beiden Schichten muss es eine Entität geben, die eine Vernetzung herstellt und für die Kommunikation zwischen diesen beiden Ebenen zuständig ist. Als Vermittler kommt an dieser Stelle eine abstrakte Schicht zum Einsatz – der sogenannte „Hypervisor“.

Was ist ein Hypervisor?

Eine virtuelle Maschine (VM) nutzt als Basis einen physischen Computer, wie beispielsweise einen Server oder Desktop-PC. Konkret bedeutet das, dass eine VM auf die physische Hardware angewiesen ist. Ein Hypervisor stellt eine Schicht zwischen der Hardware- und der Virtuellen-Ebene dar, die für die Verwaltung zuständig ist. Prinzipiell handelt es sich bei einem Hypervisor um eine Software, welche die Kontrolle und Verwaltung über die benötigten Ressourcen übernimmt. Die auch unter der Bezeichnung Virtual Machine Monitor (VMM) bekannte Software, weist im Rahmen eines Computersystems CPU- und Netzwerk-Ressourcen sowie Festplatten- und Arbeitsspeicher zu. Aus diesem Grund können auch mehrere unterschiedliche virtuelle Maschinen auf einem einzelnen Host-System effizient betrieben werden, da sich ein Hypervisor darum kümmert, dass es nicht Konflikten zwischen den einzelnen VMs kommt und dass die benötigten Kapazitäten zur Verfügung gestellt werden.

Eine virtuelle Maschine bekommt von den Organisationsschritten des Hypervisors in der Regel nichts mit. Der Virtual Machine Monitor abstrahiert die zur Verfügung gestellte Hardware auf solche Weise, dass die VM diese von einer dedizierten Hardware-Umgebung nicht unterschieden kann. Da sich bei virtuellen Maschinen die Anforderungen in Abhängigkeit von den laufenden Anwendungen ständig ändern, ist ein bedeutender Vorteil des Hypervisors, dass er Ressourcen dynamisch und in Echtzeit zur Verfügung stellt. Auch davon bekommt die virtuelle Maschine nichts mit. Sie hat nämlich keine Möglichkeit, das Vorhandensein anderer VMs auf derselben physischen Hardware zu erkennen. Durch die strikte Trennung zwischen den einzelnen virtuellen Maschinen, wird nicht nur für eine effiziente Verteilung der Ressourcen gesorgt, sondern es steigert auch die Sicherheit. Der Hypervision stellt sicher, dass eine VM nicht auf Dateien einer anderen VM zugreifen kann.

Die hohe Effizienz und Flexibilität von einem Hypervisor

Ein Hypervisor bildet nur eine abstrakte Schicht, die der virtuellen Maschine eine simulierte Hardware-Umgebung zur Verfügung stellt. Eine virtuelle Maschine, also das Gastsystem, ist nicht an einen bestimmten Hypervisor oder an ein bestimmtes Host-System gebunden. Damit bietet die Virtualisierung ein hohes Maß an Flexibilität und ist insbesondere für Anbieter von Cloud-Services sehr interessant. Cloud-Anbieter können die virtualisierten Umgebungen einfach auf andere physische Server verschieben, ohne dass die Programme, die auf den virtuellen Maschinen laufen, neu installiert oder konfiguriert werden müssen. Ein Hypervisor im Rahmen einer Virtualisierungssoftware, wie beispielsweise Hyper-V oder VMware, stellt dem Anwender außerdem eine Vielzahl unterschiedlicher Verwaltungsoptionen bereit. So können Anwender Gastsysteme schnell und einfach organisieren, einstellen und erstellen.

Verschiedene Typen im Überblick

Prinzipiell wird zwischen zwei verschiedenen Hypervisor-Arten unterschieden, und zwar Typ 1 und Typ 2. Der Typ 1 wird auch als Bare Metal Hypervisor bezeichnet. Diese Art des Virtual Machine Monitors funktioniert so, dass er direkt auf die physische Hardware aufgesetzt wird. Da ein solcher Hypervisor keine Verbindung zu dem Betriebssystem des Hosts hat, muss er alle benötigten Gerätetreiber selbst zur Verfügung stellen. Der Systemressourcenverbrauch ist bei dem Typ 1 relativ gering, da die Ressourcen nicht über das Betriebssystem des Hosts bereitgestellt werden. Diese Art des Virtual Machine Monitors ist in erster Linie an Anwender gerichtet, die damit einen dedizierten Server für Virtualisierung einrichten möchten. Für kleinere Projekte ist dieser Typ zu kompliziert und zu aufwendig.

Der Typ 2, der auch unter der Bezeichnung Hosted Hypervisor bekannt ist, ist hingegen auf ein bestehendes Betriebssystem angewiesen, das wiederum die physische Hardware als Basis nutzt. Ein Hypervisor des Typs 2 wird wie eine gewöhnliche Software auf den Computer installiert und verwaltet nach der erfolgreichen Installation alle Virtualisierungsprozesse. Die Gerätetreiber müssen hier nicht wie beim Typ 1 im Hypervisor selbst installiert sein, sondern dank der Einbindung in das bestehende Betriebssystem werden diese automatisch bereitgestellt. Dieser Komfort hat jedoch auch einige Nachteile, die sich in erster Linie auf eine schlechtere Performance auswirken. Ein beachtlicher Teil der Ressourcen wird nämlich bereits vom Betriebssystem des Hosts in Anspruch genommen, sodass für die virtuellen Maschinen weniger Ressourcen übrigbleiben. Dank der einfachen Installation sowie der schnellen und unkomplizierten Installation ist dieser Typ in erster Linie auf die Bedürfnisse kleinerer Projekte ausgelegt.

Im IT-Bereich wird mit Skalierung bzw. Skalierbarkeit die Fähigkeit eines Systems oder einer Anlage beschrieben, sich den schrumpfenden oder auch den wachsenden Anforderungen in Bezug auf die Performance der Software- und Hardware-Ebene möglichst flexibel anpassen zu können. In der Praxis wird Skalierung jedoch auch oft mit Wachstum gleichgesetzt.

Skalierbarkeit im Detail

Im Bereich moderner Informationstechnologien gelten Prozesse als skalierbar, wenn sie parallel zu den vorgegebenen Aufgaben wachsen oder schrumpfen können. Ein IT-System oder eine Anlage, die im Rahmen einer Skalierung den neuen Anforderungen angepasst wurde, ist auch nach der Implementierung der neuen Maßnahmen voll funktionsfähig. Skalierung bedeutet jedoch nicht nur, dass die skalierte Anwendung oder das System funktionieren, sondern dass auch die daraus resultierenden Vorteile weiterhin nutzbar sind. So gilt beispielsweise zum Beispiel eine Datenbank als skalierbar, wenn sie von einem einzelnen Server auf ein verteiltes Server-Cluster übertragen werden kann.

Die Vorteile einer solche Skalierung spiegeln sich in erster Linie in kürzeren Antwortzeiten und einer effizienteren Verwaltung der MySQL-Datenbank. In der Praxis ist es oft so, dass sich eine Skalierbarkeit viel einfacher nach oben als nach unten realisieren lässt. Dies ist auf die Tatsache zurückzuführen, dass bei einer Herunterskalierung das System eine gute Performance in einer kleineren Umgebung bereitstellen muss, während bei einer Skalierung nach oben zusätzliche Ressourcen zur Verfügung gestellt werden. Die Leistung eines Systems lässt sich auf zwei verschiedene Arten steigern, und zwar vertikal und horizontal.

Vertikale Skalierung

Im Rahmen einer vertikalen Skalierbarkeit (Scale Up) werden Ressourcen innerhalb einer logischen Einheit zusammengefügt. Konkret bedeutet das, dass die Leistungssteigerung durch das Hinzufügen von Ressourcen innerhalb eines Systems realisiert wird. Prominente Beispiele für diese Art der Skalierbarkeit wären:

– das Vergrößern der vorhandenen Speicherplatzkapazität

– das Hinzufügen einer leistungsstärkeren CPU

– Aufrüstung von Arbeitsspeicher

– Einbau einer besseren GPU

Bei einer vertikalen Skalierung kann die vorhandene Software sehr einfach angepasst werden, in vielen Fällen ist sogar eine Anpassung überhaupt nicht nötig. In der Regel muss keine Zeile Code neugeschrieben werden, um einen Leistungszuwachs durch vertikales Skalieren zu erhalten. Die vertikale Skalierbarkeit stößt jedoch früher oder später an Grenzen des Möglichen, weil man beispielsweise bereits die schnellste Hardware nutzt und eine Aufrüstung demzufolge nicht möglich ist.

Horizontale Skalierung

Bei der horizontalen Skalierbarkeit (Scale Out) sind im Gegensatz zu der vertikalen Skalierbarkeit keine Grenzen in Bezug auf die Performance der Hardware gesetzt. Hier wird die Leistungssteigerung des Systems durch das Beifügen zusätzlicher Server bzw. Computer realisiert. Wie gut diese Art der Skalierung letztendlich funktioniert, hängt in erster Linie von der eingesetzten Software ab, denn nicht jede Anwendung lässt sich gleich gut parallelisieren. Konkret bedeutet das, dass eine horizontale Skalierung dann vorliegt, wenn weitere Server- oder Rechner-Knoten hinzukommen, damit der steigende Workload mit gleichbleibender Leistung verarbeitet werden kann.

In einem Cloudsystem verteilen sich dann die anstehenden Aufgaben auf mehrere Rechner-Instanzen. In der Praxis wird das dadurch gelöst, dass ein Server als Verteiler für die Workloads (Load Balancing) in dem jeweiligen Server-Cluster eingesetzt wird. Der Einsatz eines Load Balancers ist immer dann nötig, wenn viele einzelne Ressourcen als eine Einheit zusammen im Rahmen einer horizontalen Skalierung fungieren müssen. Aus diesem Grund ist der sogenannte „Skalierbarkeitsfaktor“, also das Verhältnis zwischen der gewonnenen Leistung und den eingesetzten Ressourcen, hier prinzipiell niedriger als bei vertikaler Skalierbarkeit. Hinzu kommt noch, dass die horizontale Skalierbarkeit in der Regel kostengünstiger als vergleichbare Skalierungsmaßnahmen ist. Hinsichtlich des Overheads sind vertikale Skalierungsmaßnehmen jedoch viel effizienter als es bei der horizontalen Skalierbarkeit der Falls ist.

Skalierungsmaßnehmen und das Schichtenmodell

Um ein IT-System möglichst skalierbar zu gestalten, hat es sich im Laufe der Jahre bewährt, sämtliche Skalierungsmaßnehmen als Schichtenmodell zu implementieren. Im Rahmen dieses Ansatzes werden die einzelnen Schichten logisch voneinander getrennt, sodass jede einzelne Schicht für sich selbst skaliert werden kann. Eine äußerst beliebte Architektur im Bereich der Webentwicklung ist die sogenannte „3-Schichten-Architektur“. Um dabei eine möglichst hohe Skalierbarkeit zu erzielen, muss die Architektur so umgesetzt sein, dass sich jede dieser drei Schichten möglichst flexibel und unkompliziert skalieren lässt. Eine 3-Schichten-Architektur setzt sich aus folgenden Komponenten zusammen:

– Präsentationsschicht: Diese Schicht wird auch als Front-End bezeichnet und ist für die Darstellung der Daten zuständig.

– Logikschicht: Diese Schicht vereint die gesamte Anwendungslogik.

– Datenbankschicht: Diese Schicht enthält die Datenbank, wie beispielsweise MySQL oder PostgreSQL, und ist für die Speicherung und die Bereitstellung von Daten zuständig.

Während sich die Präsentationsschicht relativ einfach horizontal skalieren lässt, ist im Rahmen der Logikschicht eine Anpassung des Codes nötig. Dabei sollte beachtet werden, dass eine möglichst große Menge der Code-Logik parallelisiert werden muss, um eine effiziente Skalierung zu erhalten. Am kompliziertesten ist die Skalierung der Datenbankschicht, weshalb diese Optimierungen komplexes Expertenwissen benötigen.