Überblick über Cloud-Terminologien

(Last Updated On: 3. Juli 2017)

Häufig gibt es noch einige Unsicherheiten über Begrifflichkeiten in der Cloud. In diesem Beitrag versuche ich auf kontroverse Art und Weise, die entsprechenden Begrifflichkeiten einfach zu erklären sowiedie Vor- und Nachteile der verfügbaren Optionen aufzuzeigen.

Private vs Public Cloud

Bevor wir uns weiter mit den Deployment-Optionen und den Strategien der Cloud Thematik befassen, stehen Sie als Kunde vor der Wahl, ob Sie sich für eine Public- oder Private-Cloud-Lösung interessieren. Bei einer Public Cloud teilen Sie sich die Bereitstellungsumgebung Ihrer Cloud-Lösung mit anderen Kunden. Halt: Das heißt nicht unbedingt, dass Sie sich die Ihnen zugesicherten Ressourcen mit anderen Kunden teilen. Sie kennen das vielleicht, wenn Sie sich einen Virtual Private Server (VPS, V-Server) bei einem Server-Hoster bestellen. Da bietet Ihnen der Anbieter „bis zu 4 CPU-Kerne“ und „bis zu 6 GB RAM“ an, jedoch garantiert er nicht, dass Ihnen diese Ressourcen jederzeit zur Verfügung stehen.

So kann es mitunter sein, dass Sie zu Lastzeiten nur 2 CPU-Kerne zugesichert bekommen, weil die Nachbar-Mieter gerade ebenfalls sehr hungrig sind. Das ist allerdings mit der „Public Cloud“ nicht gemeint. Je nach Vertragsgewerk steht Ihnen in einer Public Cloud Option der volle zugesicherte Infrastruktur-Scope zu. Es ist in der Public Cloud sogar üblich, dass Ihnen jederzeit genau das zur Verfügung steht, was Ihnen auch zugesichert wird.

Was ich meine mit der Aussage „Sie teilen sich die Betriebsumgebung mit anderen  Kunden“ ist die der Umstand, dass Sie mit den anderen Kunden „mitgehen müssen“, wenn sich etwas an dieser Betriebsumgebung ändert. Aktualisiert der Cloud-Anbieter etwa das Betriebsystem oder die Software, die er Ihnen anbietet, dann gilt die neue Sotwareversion für alle Kunden. Das heißt Sie bekommen hier häufig nicht die Wahl, ob Sie noch auf dem alten Softwarestand verweilen wollen.

So düster schaut es nach diesem Poster häufig nicht mehr in Ihrer Cloud Strategie aus

So düster schaut es nach diesem Poster häufig nicht mehr in Ihrer Cloud Strategie aus

Das könnte etwa der Fall sein, weil Sie das Wartungsfenster für die entsprechende Software-Aktualisierung verschieben wollen, oder weil Sie Eigenentwicklungen haben, die bekannter maßen noch nicht kompatibel mit der neuen Software-Version sind. Als WordPress-Blogger kennen Sie diese Thematik schon selbst, weil Sie evtl. noch Plugins installiert haben, die mit der neuen Version von WordPress noch nicht kompatibel sind. Diese Option „zu warten“ bekommen Sie in der Public Cloud nicht.

De fakto ist es bei Public Cloud Optionen häufig nicht möglich, die genutzte Cloud-Software durch Eigenentwicklungen zu erweitern, weil der cloud-Anbieter Ihnen in der Public Cloud nicht garantieren kann, dass Ihre Entwicklungen in der neuen Software-Version noch funktionieren werden. Das heißt auch beispielsweise, dass Sie häufig in der Public Cloud keine Drittanbieter-Lösungen installieren dürfen.

Wenn Sie beispielsweise Ihren Blog nicht wie ich auf einer eigenen Infrastruktur betreiben, sondern Ihren Blog auf wordpress.com betreiben (also vom Software-Hersteller hosten lassen), dürfen Sie selbst keine Plugins installieren. Es ist zwar ein Standard-Satz von Plugins im Auslieferungsumfang vorhanden, aber den Großteil der auf dem Markt verfügbaren Plugins können Sie nicht in Ihren Blog integrieren.

ein weiterer Punkt, der für die Private Cloud spricht, ist der architektonische Sicherheits-Vorteil. Da Ihre Daten mitunter nicht auf der selben Hardware und nicht auf der selben Software (mitunter werden Ihre Daten beispielsweise innerhalb der selben Datenbank gespeichert, nur mit verschiedenen Tenants dahinter) gehostet werden, haben Sie aus architektonsicher Sicht schon einen Sicherheits-Vorteil gegenüber der Public Cloud.

Dafür bietet eine Public Cloud den Vorteil, dass Sie in der Regel viel schneller neue Features einer Software adaptieren können und Public Cloud Anbieter wesentlich schneller skalieren können, weil sie keine Rücksicht auf die Kompatibilität jeder einzelnen Kundenumgebung legen müssen. Diese Vorteil der Public Cloud wird häufig als „Burstability“ bezeichnet. Eine Public Cloud „brennt“ einfach viel intensiver als eine Private Cloud.

Wenn Sie also die von Ihnen genutzte Cloud-Umgebung durch eigens entwickelte Anwendungen und User Exits bereichern wollen, steht Ihnen häufig als einzige Option die Private Cloud Option zur Verfügung. Hier wird für jeden Kunden eine eigene Betriebsumgebung bereit gestellt (bzw. simuliert). Das heißt: Wenn andere Kunden auf eine neue Software-Version aktualisieren wollen, heißt das nicht zwangsläufig, dass Sie das auch tun müssen. Somit können Sie sich mit der Anpassung Ihres Codings Zeit lassen.

Sie müssen sich nicht grundsätzlich für einen Cloud Approach entscheiden. Stattdesen können Sie einige IT-Services in der Public Cloud und andere wiederum in der Private Cloud nutzen.

Single Throat To Choke vs All Eggs In One Basket

Nachdem Sie sich einen Überblick über die Vorteile von Public Cloud und Private Cloud Modellen verschafft haben, geht es in der Entscheidungsphase weiter. Wollen Sie sich dazu entscheiden, Ihre Cloud-Services grundsätzlich bei ein und dem selben Cloud-Anbieter zu buchen, oder sind Sie grundsätzlich dazu bereit, mehrere Dienstleister zu beauftragen?

Die Vorteile der Offenheit gegenüber mehrere Dienstleister liegt auf der Hand. Sie können für jeden IT-Service, den Sie in die Cloud auslagern möchten, individuell bewerten, welcher Dienstleister der beste für gerade diesen IT-Service ist. Ausschlaggeber für Ihre Entscheidung kann hier das Preis-/Leistungs-Niveau, die Informationssicherheit, die Reaktionsstärke, die finanzielle Stabilität des Dienstleisters oder etwa der Standort sein.

Weiterhin, wenn Sie Ihre Services auf mehrere Cloud-Anbieter auslagern, ist es nicht ganz so schlimm für Sie, wenn der Service-Anbieter mal Probleme hat. Diese Probleme können ganz unterschiedlich sein. Beispielsweise kann der Anbieter entweder Probleme mit der Performance, mit der Sicherheit oder mit Datenverlust haben. Haben Sie all Ihre Eier in einem Korb, geht mitunter gar nichts mehr, wenn es hier einmal hapert. Mit einer Diversifizierung Ihrer Cloud-Anbieter können Sie sich hier hingegen absichern.

Dem gegenüber steht der offensichtliche Nachteil, dass Sie im Falle von Problemen immer den jeweilig zuständigen Anbieter kontaktieren müssen. Sie müssen mit jedem Anbieter einzeln die Service Level Agreements (SLAs) verhandeln und haben mitunter das Problem, dass Sie Service A von Anbieter A mit Service B von Anbieter B verbinden müssen. Entscheiden Sie sich für den Single Throat to Choke Ansatz, ist für Ihre Cloud-Services ein einziger Anbieter verantwortlich. Das bedeutet für Sie weniger Aufwand, da Sie diesen einzigen Anbieter für alle ihre zentralen Cloud-Problematiken in Griffweite haben.

Die Deployment-Optionen SaaS vs IaaS vs PaaS

Bei manchen herrscht noch Unsicherheit über die drei hier beschriebenen Begriffe. Was ist die Bedeutung von Software as a Service (SaaS), Infrastructure as a Service (IaaS) und Platform as a Service (PaaS)?

Wie viel von Ihrer on-premise-Landschaft wird in Zukunft von der Cloud eingenebelt?

Wie viel von Ihrer on-premise-Landschaft wird in Zukunft von der Cloud eingenebelt?

  • Software as a Service (SaaS), häufig auch bekantn als „Cloud Application Service“, sind der am schnellsten wachsende Markt im Cloud-Umfeld. Im Software as a Service Ansatz wird eine komplette Softwarelösung an den Endkunden ausgeliefert. Der Kunde hat also auf seiner eigenen Seite keine eigenverantwortlichen Schritte durchzuführen, bevor er die Software in ihrer Grundfunktionalität nutzen kann. Dropbox ist beispielsweise ein sehr berühmtes SaaS-Beispiel. Sie können die Dropbox sofort nach Ihrer Registrierung ohne großartige Eigeninitiviative nutzen.Die meisten SaaS-Anwendungen können direkt im Webbrowser genutzt werden, häufig wird zusätzlich eine Desktop-App angeboten. Häufig nutzt man Software as a Service, um bestehende on-Premise Lösungen abzulösen. Der Kunde erhofft sich beim Einführung einer SaaS-Lösung häufig die schneller Adaption neuer Produkt-Features, die schnellere Skalierung des Produktes auf gestiegene Nutzerzahlen und die Möglichkeit zur Auslagerung von IT-Know-How auf einen spezialisierten Cloud-Anbieter.
  • Platform as a Service (PaaS) wird häufig im Umfeld der Software-Entwicklung eingesetzt.  Eine PaaS-Lösung liefert häufig eine Software-Basis, die dann von den Entwicklern für eigene Lösungen weiter entwickelt werden kann. Sie bietet sich aber auch an, wenn man eine eigene Anwendung auf Basis eines bestimmten Software-Frameworks online betreiben möchte. PaaS vereinfacht hierbei häufig nicht nur die Entwicklung, sondern auch das Testen und das Deployment der anwendungen.Eine PaaS-Lösung kümmert sich häufig um den Storage, die Netzwerk-Infrastruktur, die Virtualisierung und das Betriebssystem, häufig wird auch die Datenbank schon im Vorfeld bereit gestellt und ein Software-Framework vor installiert, auf dessen Basis dann die endgültige Anwendung geschrieben wird. Der Kunde muss sich hier also um nichts anderes mehr kümmern, außer um die eigentliche Entwicklung seiner Anwendung.  Das berühmteste Beispiel für Plattform as a Service (PaaS) ist klassisches Web-Hosting.

    In diesem Szenario haben Sie meistens eine Webanwendung, die beispielsweise mit PHP auf Basis eines Frameworks die Yii2 oder Symfony entwickelt wurde. Der Web-Hosting Anbieter liefert Ihnen die PHP-Laufzeitumgebung, eine Datenbank sowie die darunter liegende Infrastruktur. Sie bringen hingegen Ihre eigene Anwendung und betreiben diese auf der vom Anbieter zur Verfügung gestellten Plattform. Rein logisch betrachtet gibt es kaum PaaS-Dienste, die als Public Cloud angeboten werden. Denn PaaS lebt ja davon, dass Sie Ihre eigenen Anwendungen auf dieser Plattform betreiben. PaaS ist eigentlich immer Private Cloud.

  • Infrastructure as a Service (IaaS) liefert im Vergleich zu den oberen Plattformen lediglich die „metallene Hülle“. Das heißt hier wird lediglich die Netzwerk-Infrastruktur, der Storage, die eigentlichen Server und die Virtualisierung bereit gestellt. Der Endkunde muss sich immer noch selbst um die Installation und den Betrieb von Betriebssystem, Datenbank und Anwendung kümmern. IaaS wird häufig genutzt, um kurzfristige Lastspitzen zu überbrücken (etwa zum Weihnachtsgeschäft) oder um in Zukunft schneller hoch skalieren zu können (weil beispielsweise im firmeneigenen Rechenzentrum keine Kapazitäten für neue Hardware bestehen).

Die Tabelle unten zeigt typische Beispiele für die einzelnen Deployment-Strategien

SaaSPaaSIaaS
Google Apps, Salesforce, Workday, Concur, Citrix GoToMeeting, Dropbox, Cisco WebExWeb-Hosting, Apprenda, AWS Elastic Beanstalk, Heroku, Force.com, Google App EngineAmazon Web Services (AWS), Microsoft Azure, Google Computing Engine (GCE), Joyent, Cisco Metapod

Da für viele Unternehmen häufig interessant ist, beim Outsourcen an die Cloud zu denken, fahren Sie sehr häufig eine Cloud First Strategie. Dies würde besagen, dass

  • zuerst versucht wird, ein Problem über eine Software as a Service Lösung anzugehen
  • falls dies nicht verfügbar ist, eine Platform as a Service Lösung zu nehmen
  • falls dies nicht verfügbar ist, Infrastructure as a Service in Anspruch zu nehmen
  • und erst als letzten Hilfeschrei die Lösung on-Premise, also komplett eigenständig, zu betreiben.

Cloud Philosophien

Wenn Sie sich nun dazu entschieden haben, welche Deployment Option Sie für welche IT-Services Sie in der Cloud bevorzugen, geht es daran, sich über eine Cloud Philosophie Gedanken zu machen. Wann sollen denn bei Ihnen im Unternehmen IT-Dienstleistungen überhaupt in die Cloud ausgelagert werden? Grundsätzlich gibt es folgende Vorgehensmodelle

  • Cloud First. Bei Cloud First bevorzugt man für einen IT-Service grundsätzlich die Cloud, schließt jedoch eine on-Premise Lösung nicht aus. so definiert man bestimmte Unternehmens-Richtlinien, die bestimmen, wann ein Service als SaaS-, PaaS-, IaaS- oder on-Premise-Lösung ausgerollt wird. Dabei gilt in der Priorisierung die gerade genannte Reihenfolge.Das heißt das Unternehmen möchte möglichst vermeiden, on-Premise-Lösungen einzusetzen und möchte möglichst viel Verantwortung an den Cloud-Dienstleister abgeben. Jedoch können beispielsweise Security- und Governance-Richtlinien dazu führen, dass bestimmte Dienstleistungen weiterhin on-Premise betrieben werden müssen.
  • Cloud Only. Hier stellt sich die Frage nach einer on-Premise Lösung nicht mehr. Das Unternehmen möchte sämtliche IT-Dienstleistungen vollständig an Cloud-Dienstleister auslagern. Viele Unternehmen wählen diese Strategie, wenn sie ihre interne IT-Abteilung nur noch auf ein Minimum reduzieren möchten, um sich auf das Kerngeschäft konzentrieren zu können. Die Eigenheiten der Cloud werden akzeptiert, so dass beispielsweise gewisse Einschnitte im Security-Umfeld in Kauf genommen werden, um die Vorteile der Cloud konsumieren zu können.
  • Cloud Never. Hier ist es gerade umgekehrt. Es stellt sich nie die Frage, ob eine IT-Dienstleistung in die Cloud ausgelagert werden soll. Es werden stattdessen immer eigens betriebene on-Premise Lösungen genutzt. Unternehmen mit geringer Risikotoleranz wählen häufig diese Philosophie. Ein Cloud Never Ansatz ist daher in der Pharma-, Raumfahrt- und Waffen-Industrie etwa sehr weit verbreitet.Ausnahmen bestätigen jedoch auch hier die Regel. Häufig herrschen hier  keine technischen Security-Ängste. Stattdessen sind viel „trivialere“ Themen Ausschlaggeber für eine Cloud-Never-Philosophie, wie etwa die Erpressbarkeit des Cloud-Dienstleisters bzw. deren einzelner Mitarbeiter. Ein weiterer wichtiger Faktor ist die Frage nach einer Exit-Strategie. Wie einfach kommt das Unternehmen im Zweifelsfall wieder aus der Cloud heraus?

Temporary Cloud-Strategien durchleuchtet

In diesem Abschnitt durchleuchten wir gängige Strategien, in denen es nur während eines beschränkten Zeitraums zu einem Cloud-Deployment Ihrer Services kommt.

Vor allem Großunternehmen verfolgen temporäre Cloud-Strategien für Übergangszeiträume

Vor allem Großunternehmen verfolgen temporäre Cloud-Strategien für Übergangszeiträume

Rent the Spike

In einer Rent the Spike Strategie werden die IT-Dienstleistungen überwiegend weiterhin on-premise bereitgestellt. Jedoch werden zur Skalierung in Lastzeiten, beispielsweise im Weihnachtsgeschäft, Cloud-Server hinzugekauft (häufig als IaaS oder PaaS), um diese Lastspitzen zu überbrücken. Häufig wissen Sie als Dienstleister nicht, wie hoch diesmal die Belastung zum Weihnachts- oder Ostergeschäft sein wird. Da Sie deswegen schlecht voraussagen können, wie viele zusätzliche on-premise Maschinen Sie anschaffen und betreiben müssen, halten Sie sich die zusätzlichen Knoten lieber in der Cloud und schalten diese bei Bedarf zur schnellen Skalierung einfach dazu.

Spin-Up/Tear-Down

Diese Strategie beschreibt den Ansatz, dass kurzfristig Systeme für bestimmte Zwecke in der Cloud gemietet werden, die nicht permanent sind. Beispielsweise brauchen einige Unternehmen nicht ständig ein Test-System oder eine Sandbox für ein IT-Projekt. Stattdessen mietet man für kurze Zeit ein entsprechendes System, um die Tests durchzuführen (Spin-Up), und tötet das System danach wiederum (Tear-down). Entscheidend für diese Strategie sollte die Frequenz sowie der damit verbundene Kostenfaktor sein, in der sie ein bestimmtes System benötigen. Steht das System meist ungenutzt rum, kann es sich für Sie lohnen, wenn das System nur sporadisch zugekauft wird.

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.