Grundlagen

Warum OAuth?

• Benutzerkontrolle: OAuth ermöglicht es Benutzern, Anwendungen und Diensten den Zugriff auf ihre Konten bei verschiedenen Anbietern zu gewähren, ohne dabei ihre Benutzername/Passwort-Kombinationen preiszugeben.

• Sicherheit: Da die Anmeldeinformationen nicht direkt geteilt werden, reduziert OAuth das Risiko von Datendiebstahl und Missbrauch von Anmeldeinformationen.

• Granulare Berechtigungen: OAuth erlaubt es Benutzern, den Umfang und die Dauer der Zugriffsberechtigungen, die an eine Anwendung vergeben werden, präzise zu steuern.

Hauptkomponenten von OAuth

• Ressourcenbesitzer (Resource Owner)
  Der Ressourcenbesitzer ist normalerweise der Endbenutzer, der den Zugriff auf seine Daten und Ressourcen bei einem Ressourcenserver gewährt.

• Ressourcenserver (Resource Server)
  Der Ressourcenserver hostet die geschützten Daten und Ressourcen des Ressourcenbesitzers. Er ist dafür verantwortlich, die Autorisierung und Authentifizierung von Anfragen mithilfe von OAuth-Tokens zu überprüfen. (Kleiner Tipp am Rande. Bei den Tokens handelt es sich nicht um die Tokens, die man aus den Kryptowährungen kennt 😉 )

• Client
  Die Client-Anwendung ist der Konsument der geschützten Ressourcen. Sie stellt Anfragen an den Ressourcenserver, um im Namen des Ressourcenbesitzers auf die Daten zuzugreifen.

• Autorisierungsserver (Authorization Server)
  Der Autorisierungsserver ist für die Ausgabe, Überprüfung und den Widerruf von OAuth-Zugriffstokens zuständig. Er agiert als Vermittler zwischen dem Ressourcenbesitzer, dem Client und dem Ressourcenserver.

OAuth-Fluss

Man kann den OAuth-Fluss in vier grundlegende Schritte unterteilen:

• Anfordern der Autorisierung: Der Client fordert die Autorisierung des Ressourcenbesitzers an, um auf dessen Ressourcen zuzugreifen.

• Autorisierungsantwort: Der Ressourcenbesitzer gewährt die Autorisierung und leitet den Client an den Autorisierungsserver weiter. Der Client erhält einen Autorisierungscode.

• Anfordern eines Zugriffstokens: Der Client sendet den Autorisierungscode an den Autorisierungsserver und fordert ein Zugriffstoken an.

• Token-Ausgabe: Der Autorisierungsserver überprüft den Autorisierungscode, stellt ein Zugriffstoken aus und sendet es an den Client.

Nachdem der Client das Zugriffstoken erhalten hat, kann er es verwenden, um auf die geschützten Ressourcen des Ressourcenbesitzers zuzugreifen, indem er Anfragen an den Ressourcenserver stellt. Der Ressourcenserver überprüft das Token und gewährt den Zugriff entsprechend der Berechtigungen, die vom Ressourcenbesitzer festgelegt wurden.

Versionen und Unterschiede von OAuth

Es gibt zwei Hauptversionen. OAuth 1.0 und OAuth 2.0. Die Veröffentlichung von OAuth 1.0 fand im Jahr 2010 statt und verwendet einen komplexeren kryptografischen Ansatz für die Sicherheit. Im Jahr 2012 folgte OAuth 2.0 und ist eine überarbeitete Version, die eine einfachere und flexiblere Architektur bietet. Zweiteres basiert auf Bearer-Tokens. Bei beiden handelt es sich nach wie vor um offene Standardprotokolle zur sicheren Delegierung von Zugriffsberechtigungen. Obwohl sie gemeinsame Ziele verfolgen, unterscheiden sie sich in ihrer Architektur, ihren Sicherheitsmechanismen und besonders in der Benutzerfreundlichkeit. Durch die unterschiedliche Architektur ist keine Abwärtskompatibilität gegeben.

Sicherheitsmechanismen:

1.0: Verwendet einen kryptografischen Ansatz, bei dem man Anfragen mithilfe von kryptografischen Signaturen und einem gemeinsamen Geheimnis (Shared Secret) zwischen dem Client und dem Autorisierungsserver signiert. Diese Methode erfordert einen erhöhten Aufwand bei der Implementierung und Konfiguration.

2.0: Verwendet Bearer-Token, bei denen der Besitzer des Tokens (Client) Zugriff auf die geschützten Ressourcen erhält. Die Sicherheit basiert hauptsächlich auf der sicheren Übertragung und Aufbewahrung von Tokens (z. B. über https). Diese Methode ist einfacher zu implementieren und erfordert weniger kryptografische Kenntnisse.

Flexibilität:

1.0: Bietet einen starren Ablauf zur Anforderung und Nutzung von Zugriffstokens, der weniger Anpassungsmöglichkeiten für verschiedene Anwendungsszenarien bietet.

2.0: Ermöglicht eine größere Flexibilität und Anpassungsfähigkeit, indem man verschiedene „Grant Types“ (Genehmigungsarten) zur Verfügung stellt, um unterschiedlichen Anwendungsszenarien und Plattformen Genüge zu tun.

Einfachheit:

1.0: Die Implementierung und das Debugging von OAuth 1.0 können komplex sein, da Entwickler den kryptografischen Prozess und das Signieren von Anfragen verstehen müssen.

2.0: Die Implementierung von OAuth 2.0 ist einfacher und erfordert weniger kryptografische Kenntnisse. Dies führt zu einer schnelleren und einfacheren Integration in Anwendungen und Dienste.

Mobile und native Anwendungen:

1.0: Aufgrund seiner komplexeren Natur und der kryptografischen Anforderungen ist OAuth 1.0 weniger geeignet für mobile und native Anwendungen, bei denen Ressourcen und Konnektivität eingeschränkt sein können.

2.0: Durch die einfachere Implementierung und den flexibleren Ablauf eignet sich OAuth 2.0 besser für die Integration in mobile und native Anwendungen.

Vorteile

Sicherheit: Es erhöht die Sicherheit, indem man Anmeldeinformationen nicht direkt teilen muss und Tokens verwendet, um auf Ressourcen zuzugreifen.

Benutzerfreundlichkeit: Es ermöglicht Single Sign-On (SSO) und reduziert die Notwendigkeit, mehrere Benutzernamen und Passwörter zu verwalten.

Flexibilität: Es bietet eine flexible Architektur, die für verschiedene Anwendungsszenarien und Plattformen geeignet ist.

Granularität: Es ermöglicht, den Umfang und die Dauer der gewährten Berechtigungen genau zu steuern.

Nachteile

Komplexität: Die Implementierung von OAuth, insbesondere bei OAuth 1.0, kann komplex sein, da es verschiedene Abläufe und Mechanismen beinhaltet. Dies kann zu einer steileren Lernkurve für Entwickler führen, die sich nicht mit dem Protokoll auskennen.

Sicherheitsrisiken: Trotz der verbesserten Sicherheit, die OAuth bietet, gibt es immer noch Sicherheitsrisiken. Fehlkonfigurationen, unzureichende Validierungen und direkte Angriffe auf den Autorisierungscode oder das Zugriffstoken können die Sicherheit weiter gefährden.

Abhängigkeit von Drittanbietern: Die Verwendung von OAuth kann eine Abhängigkeit von Drittanbieter-Autorisierungsservern schaffen, die möglicherweise Ausfallzeiten, Sicherheitsverletzungen oder andere Probleme aufweisen können.

Datenschutzbedenken: Bei der Verwendung von OAuth besteht das Risiko, dass Benutzer mehr Daten preisgeben als erforderlich, da Anwendungen möglicherweise Zugriff auf mehr Informationen anfordern, als für ihre Funktionen notwendig ist.

Token-Hijacking: Obwohl es die Sicherheit gegenüber der direkten Weitergabe von Anmeldeinformationen verbessert, besteht immer noch die Gefahr, dass Angreifer Zugriffstoken abfangen oder stehlen können. Dies kann zu unbefugtem Zugriff auf Benutzerdaten führen.

Eingeschränkte Implementierung: Die Nutzung von OAuth in bestimmten Anwendungsszenarien, wie beispielsweise bei Geräten mit eingeschränkter Internetkonnektivität oder eingeschränkten Eingabemöglichkeiten, kann sich als schwierig oder teilweise unmöglich gestalten.

Best Practices

• Man sollte immer die neueste Version (aktuell OAuth 2.0) für bessere Sicherheit und Flexibilität verwenden.
• Implementierung von „Proof Key for Code Exchange“ (PKCE) Erweiterung ist zu empfehlen, um Angriffe, die den Autorisierungscode abfangen, verhindern zu können.
• Sichere Speicherung des Zugriffstokens und der Client-Anmeldeinformationen, um den Missbrauch zu verhindern.
• Verwenden von kurzen Gültigkeiten und Lebensdauern für Zugriffstokens und Erneuerungen bei Bedarf mithilfe von Aktualisierungstokens.
• Implementierung von Zustimmungsbildschirmen, um Benutzer über den Umfang und die Dauer der Berechtigungen, die man gewährt, zu informieren.

Fazit:

OAuth ist ein leistungsstarkes Protokoll, das die sichere Delegierung von Zugriffsberechtigungen im Internet ermöglicht. Durch das Verständnis der Grundlagen von OAuth und die Einhaltung der Best Practices können Entwickler Anwendungen erstellen, die eine sichere und benutzerfreundliche Erfahrung bei Login-Verfahren bieten.

Der Beitrag OAuth – Login ohne Preisgabe von Anmeldeinformationen erschien zuerst auf CEOsBay.

Grundlagen von JSON Web Tokens

JWTs sind als offener Standard definiert (RFC 7519) (Siehe Beitrag über RFC und HAL) und sind in vielen Programmiersprachen und Plattformen implementiert. Ein JWT besteht aus drei Teilen: Header, Nutzlast (Payload) und Signatur. Diese Teile sind durch Punkte getrennt und bilden einen kompakten Token, die man beispielsweise in einem https-Header oder einer URL übertragen kann.

Struktur von JWT

Header

Der Header enthält Informationen über den verwendeten Algorithmus zur Signatur des Tokens und den Token-Typ. Typischerweise sieht ein Header folgendermaßen aus:

{
"alg": "HS256",
"typ": "JWT"
}

Nutzlast (Payload)

Die Nutzlast enthält die eigentlichen Informationen, die man zwischen den Parteien austauscht. Diese Informationen bezeichnet man auch als Claims. Der Payload kann sowohl vordefinierte als auch benutzerdefinierte Claims enthalten.

Siehe nachfolgendes Beispiel:

{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

oder

{
  "user_id": "42"
}

Im zweiten Beispiel ist user_id der Claim-Schlüssel und 42 der zugehörige Wert. Diesen Claim kann man beispielsweise in einem JWT verwenden, um den authentifizierten Benutzer zu identifizieren.

Signatur

Die Signatur dient dazu, die Integrität des Tokens sicherzustellen und zu verhindern, dass man dessen Inhalt manipulieren kann. Dier Erstellung erfolgt durch die Verwendung eines geheimen Schlüssels und des im Header angegebenen Algorithmus (z. B. HMAC-SHA256).

Vorteile von JWT

Stateless und skalierbar

JWTs ermöglichen eine stateless Authentifizierung, da die Nutzlast alle erforderlichen Informationen enthält. Dies bedeutet, dass man keine Sitzungsdaten auf der Serverseite speichern muss. Dadurch sind und bleiben Anwendungen leichter skalierbar.

Einfache Implementierung

Da JWTs auf dem weit verbreiteten JSON-Format basieren, ist ihre Implementierung einfach und sie unterstützt eine Vielzahl von Bibliotheken und Frameworks.

Selbstenthaltend

JWTs enthalten alle erforderlichen Informationen in sich selbst. Dadurch sind keine zusätzlichen Datenbankabfragen zur Verifizierung des Benutzers erforderlich.

Nutzungsszenarien von JWT

Authentifizierung

Man nutzt JWTs häufig zur Authentifizierung von Benutzern in Single-Page-Anwendungen (SPAs) Single Page Applications und APIs.

Autorisierung

Man kann ein JWT auch zur Autorisierung verwenden. Dies lässt sich bewerkstelligen, sofern Informationen über die Rollen und Berechtigungen des Benutzers in den Claims des Tokens enthalten sind.

Informationen teilen

Da JWTs einfach zu erstellen und zu verifizieren sind, kann man sie verwenden, um Informationen zwischen verschiedenen Diensten oder Parteien sicher auszutauschen.

Sicherheitsbedenken und Best Practices

Sichere Übertragung

Man sollte JWTs immer über sichere Kommunikationskanäle wie https übertragen, um Man-in-the-Middle-Angriffe zu verhindern.

Gültigkeit bzw. Ablaufzeit

Tokens sollten eine Gültigkeit bzw. Ablaufzeit (Expiration Time) enthalten, um das Risiko einer Kompromittierung zu minimieren. Sobald ein Token abgelaufen ist, kann man nicht mehr auf die Ressource zugreifen. Dies schafft eine weitere Sicherheitsinstanz, da der Angreifer, selbst wenn er den Zugang gehacked hat, im Besitz des immer wieder neu generierten Tokens sein muss.

Aufbewahrung von geheimen Zugangsdaten

Man sollte den geheimen Schlüssel, den man zur Signatur von JWTs verwendet, sicher aufbewahren und vor unbefugtem Zugriff schützen.

Die Wahl des richtigen Algorithmus

Man sollte einen sicheren Algorithmus für die Signatur von Tokens verwenden. Beispielsweise HMAC-SHA256 oder RSA. Dies, davon ist auszugehen, kann sich mit der fortschreitenden Entwicklung der Quantencomputertechnologie ändern. Folglich ist es immer von enormer Wichtigkeit, die Entwicklungen dahingehend zu beobachten.

Token – Hijacking)

Man sollte darauf achten, dass JWTs nicht im Local Storage oder Session Storage des Browsers gespeichert sind. Dies kann die Seite bzw. Anwendung anfällig für Cross-Site-Scripting-Angriffe (XSS) machen. Daher kann es Sinn machen, https-Only-Cookies zu verwenden.

Fazit

JSON Web Tokens bieten eine moderne, flexible und sichere Methode zur Authentifizierung und Autorisierung von Benutzern in Webanwendungen und APIs. Durch die Stateless-Natur, einfache Implementierung und Selbstenthaltung von JWTs lassen sich skalierbare Lösungen für die Identitätsverwaltung erstellen. Dennoch sollte man sich der Sicherheitsrisiken bewusst sein und Best Practices befolgen, um die Integrität und Sicherheit der Anwendung zu gewährleisten.

Der Beitrag JWT – JSON Web Tokens – Die moderne Authentifizierungsmethode erschien zuerst auf CEOsBay.

Continuous Integration (CI)

CI ist eine Praxis der Softwareentwicklung, bei der Entwickler ihre Änderungen am Code regelmäßig in einer zentralen Repository integrieren, in der Regel mehrmals täglich. Dieser Ansatz soll Probleme wie Merge-Konflikte oder schwer auffindbare Fehler aufgrund von Inkonsistenzen im Code frühzeitig erkennen und beheben.

Vor- und Nachteile von CI/CD

Einige der Hauptvorteile von CI sind:

• Früherkennung von Fehlern und Konflikten: Durch regelmäßige Integration und automatisierte Tests findet die Fehlerfindung und dadurch die Behebung der Fehler frühzeitig statt, bevor sie zu größeren Problemen führen.
• Reduzierung von Risiken: Da man Änderungen in kleineren Schritten und häufiger integriert, reduziert sich das Risiko, dass neue Funktionen bestehende Funktionen beeinträchtigen.
• Verbesserung der Codequalität: CI ermutigt Entwickler, Code häufiger zu testen, was zur Verbesserung der Codequalität beiträgt.

CI-Tools:

Es gibt eine Vielzahl von CI-Tools auf dem Markt, darunter Jenkins, GitLab CI, Travis CI und CircleCI. Diese Tools automatisieren den Integrationsprozess, indem sie den Code überprüfen, bauen und testen, sobald Änderungen eingecheckt sind.

Continuous Deployment (CD)

Continuous Deployment ist ein Prozess, bei dem man automatisierte Tests und Freigabeprozesse durchführt, um neue Codeänderungen kontinuierlich und in kürzester Zeit in die Produktionsumgebung einzuführen. Im Gegensatz zu Continuous Delivery, bei dem man die Freigabe in die Produktion noch manuell auslösen muss, geschieht dies bei Continuous Deployment vollautomatisch.

Vorteile von CD:

• Schnellere Markteinführung: Durch den Einsatz von CD kann man Software schneller auf den Markt und in Umlauf bringen, da man dadurch den manuellen Aufwand für die Bereitstellung minimiert.
• Automatisierte Fehlerbehebung: CD-Systeme bieten Möglichkeiten zur automatischen Fehlerbehebung und Rollbacks, um sicherzustellen, dass die Produktionsumgebung stabil bleibt.
• Bessere Zusammenarbeit: Durch CD kann man verschiedene Teams wie die Entwicklung, QA bzw. Testing und Operations besser aufeinander abstimmen, was die Zusammenarbeit und Kommunikation wesentlich verbessert.

CD-Tools:

Zu den beliebtesten CD-Tools gehören Spinnaker, GitLab CD, Octopus Deploy und Harness. Diese Tools helfen bei der Automatisierung von Bereitstellungsprozessen, einschließlich der Erstellung von Umgebungen, dem Ausführen von Tests und dem Verwalten von Konfigurationen.

Einige wichtige Punkte, die noch bei der Einführung und Anwendung von CI/CD zu beachten sind:

• Organisationskultur: Die Implementierung von CI/CD erfordert eine Veränderung in der Denkweise und Kultur eines Teams oder einer Organisation. Es ist wichtig, dass alle Beteiligten die Vorteile erkennen und bereit sind, sich auf kontinuierliche Verbesserung und Zusammenarbeit zu konzentrieren.
• Automatisierung: Um die Vorteile von CI/CD voll auszuschöpfen, ist es entscheidend, möglichst viele Schritte im Entwicklungs- und Bereitstellungsprozess zu automatisieren. Dies kann das Schreiben von Skripten für das Erstellen, Testen und Bereitstellen von Code oder die Verwendung von Tools und Plattformen umfassen, die diese Prozesse unterstützen.
• Testabdeckung: Um sicherzustellen, dass der Code in einer CI/CD-Pipeline zuverlässig funktioniert, ist es wichtig, ausreichende Testabdeckung sicherzustellen. Dies umfasst sowohl Unit-Tests als auch Integrationstests, um sicherzustellen, dass alle Aspekte einer Anwendung korrekt funktionieren. Hier macht es Sinn den Beitrag SonarQube zu erwähnen 😉
• Monitoring und Feedback: Im Zusammenhang mit CI/CD ist es wichtig, ein effektives Monitoring-System einzurichten, um Leistungsprobleme oder Fehler frühzeitig zu erkennen. Ebenso ist ein Feedback-System für Entwickler und Stakeholder entscheidend, um kontinuierlich voneinander zu lernen und Verbesserungen vorzunehmen. Hierzu schreibe ich in zukünftigen Beiträgen mehr. Bis es so weit ist, ist der Beitrag über Grafana erwähnenswert 😉
• Sicherheit: Bei der Implementierung von CI/CD ist es unerlässlich, Sicherheitspraktiken zu berücksichtigen. Dies umfasst die regelmäßige Überprüfung von Sicherheitspatches, die Durchführung von Sicherheitstests und die Einhaltung von Best Practices für sicheren Code.

Fazit

Continuous Integration und Continuous Deployment sind entscheidende Konzepte in der modernen Softwareentwicklung, die dazu beitragen, den Entwicklungsprozess zu beschleunigen, die Codequalität zu verbessern und die Zusammenarbeit zwischen Teams zu fördern. Durch die Einführung von CI/CD-Praktiken im Entwicklungsworkflow kann man Fehler frühzeitig erkennen, den Zeitaufwand für die Behebung von Problemen reduzieren und die Bereitstellung neuer Funktionen und Updates beschleunigen.

Indem man diese Faktoren berücksichtigt und CI/CD-Praktiken erfolgreich in einem Softwareentwicklungsprozess integriert, kann man von den Vorteilen der schnelleren Entwicklungszyklen, verbesserten Zusammenarbeit und von einer höheren Codequalität profitieren.

Der Beitrag CI/CD – Continuous Integration und Continuous Deployment erschien zuerst auf CEOsBay.

Man verwendet den Ausdruck Modultest unter anderem bei frühen Teststufen, in denen man die inneren, detailliertesten Komponenten der Software testet. Gemäß Software Validation & Verification Plan sind diese Tests nur für Module mit geringer Kritikalität nicht notwendig. Im Grunde genommen bei Fehlern, die dem User nur geringfügige Unannehmlichkeiten bereiten.

In einer Abstraktion der verwendeten Programmiersprache, spricht man von Komponente oder Softwarebaustein. Den Test eines solchen einzelnen Softwarebausteins bezeichnet man auch allgemeiner als Komponententest.

Als Testbasis kann man in der Regel die komponentenspezifische Anforderung und das Softwaredesign der Komponente (auch Komponentenspezifikation genannt) heranziehen. Für Whitebox-Testfälle oder um Aussagen zur Codeüberdeckung zu erhalten, kann man zusätzlich den Sourcecode einer Komponente analysieren und diesen als Testbasis verwenden. Wobei dabei auch Tools wie Jacoco helfen können. Ob die Komponente auf einen Testfall richtig reagiert, muss man allerdings auch hier auf Basis der Design- und Anforderungsdokumente beurteilen.

Typische Testobjekte sind wie bereits beschrieben Programmunits, -Module bzw. Klassen. Aber auch Kommandozeilenskripte des Betriebssystems (Shell-Skripte), Datenbankskripte, Datenkonvertierungs- oder Migrationsprozeduren, Datenbankinhalte sowie Konfigurationsdaten können Testobjekte sein. Kennzeichnend ist in der Regel der isolierte Test eines einzelnen Softwarebausteins. Dies dient primär, um komponentenexterne Einflüsse beim Testen auszuschließen. Alle so ermittelten Fehler kann man so dem spezifischen Modul zuordnen.

Klar zu unterscheiden ist auf jeden Fall der Integrationstest, den ich in einem separaten Beitrag thematisiere. Bei einem Integrationstest konzentriert man sich auf die Wechselwirkung mit Nachbarkomponenten.

Die Erstellung solcher Tests ist in der Regel die Aufgabe eines Programmierers. Dies liegt zum einen daran, dass man ein ausgeprägtes Verständnis für die Programmiersprache in der die Anwendung geschrieben ist haben muss. Und zum anderen daran, dass man meist auch einen Testtreiber benötigt, dessen Programmierung in der Regel auch der Entwickler übernimmt.

Einordnung im Testprozess

Algorithmen auf Unitebene besitzen meist nur eine begrenzte Komplexität und man kann sie über klar definierte Schnittstellen aktivieren. Daher kann sie mit relativ wenigen Testfällen weitgehend vollständig testen. Dies gilt als Voraussetzung für die anschließende Teststufe. Dem Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können. Die modulspezifischen Detailkonstellationen lassen sich damit auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle signifikant reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile gesichert ist.

Test des Vertrages und nicht der Algorithmen

Man testet bei Modultests gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Sind die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), kann der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher empfiehlt man in der Regel das sogenannte Black-Box-Testing, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Was sind die Vorteile von Unit Tests?

• Mittels automatisierter Unittests kann man im Schnitt 30 % der Fehler erkennen. Bei der Verwendung von TDD (Test Driven Development) kann man im Schnitt 45 % und im besten Fall 85 % der Fehler vermeiden.
• Fehler erkennt man durch Modultests bereits während der Entwicklung. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten (Dazu später mehr) um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann man diesen sehr viel genauer eingrenzen und damit schneller finden und beheben.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benamung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, muss man viel weniger mögliche kombinatorische Ausführungspfade berücksichtigen als bei anderen Testarten. Bei übergeordneten Tests kann man sich dann stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit die Anzahl dieser Tests deutlich reduzieren.
• Da man nur einzelne Module testet, kann man Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausführen als andere Testarten.
• Wenn man Fehler mit einem Test absichert, kann man den erneuten Auftritt des gleichen Fehlers verhindern.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da man Abhängigkeiten zwingend vermeiden muss, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann man schneller auf wechselnde Anforderungen reagieren. Siehe Agile Manifest 😉
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch kann man die Entwicklungsstufen schneller durchlaufen und die Release-Zyklen signifikant verkürzen.

Was sind die Nachteile von Unit Tests?

• Bei der Implementierung neuer Funktionen muss man nicht nur die Funktion implementieren, sondern auch die dazugehörenden Tests vorbereiten bzw. definieren. Dadurch ergibt sich ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen muss man nicht nur die geänderten Funktionen, sondern auch die dazugehörenden Tests anpassen. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft eher ein Hindernis.
• Da man die Funktionalität der Tests verwendet, ist in den IDEs schwerer ersichtlich, ob eine Funktionalität keine Verwendung mehr findet und ob man es daher entfernen kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Fehlerkosten 10er Regel (Rule of ten)

Die Zehnerregel der Fehlerkosten besagt, dass je weiter ein Fehler sich unentdeckt in die späten Phasen des Werdegangs eines Produktes oder Prozesses bewegt – oder gar bis zum Kunden –, desto höher steigen die Kosten zur Behebung des Fehlers. Eindrucksvoll untermauert durch die Ergebnisse einiger Studien aus den 70er Jahren in Japan, USA und Großbritannien, die sich mit den Ursachen von Produkt- bzw. Qualitätsmängeln beschäftigten. Alle Analysen lieferten nahezu die gleichen Ergebnisse: Ca. 70 % aller Produktmängel hatten ihre Ursache bereits in der Entwicklung, Konstruktion und Arbeitsvorbereitung. Der Herstellungsprozess selbst hat bezüglich der Endqualität des Produktes offensichtlich eher einen sekundären Einfluss. Eine VDMA-Studie zum Thema „Qualitätsbezogene Kosten“ Anfang der 90er Jahre in der Bundesrepublik Deutschland bestätigt dieses Ergebnis.

Die Zehnerregel der Fehlerkosten oder „Rule of ten“ sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation und schlussendlich auch für den User bzw. Kunden.

Ansonsten sind diese auch in der DIN 55350-11 im Rahmen des Qualitätsmanagements festgehalten. Doch darauf gehe ich in einem separaten Beitrag ein.

Wo sind die Grenzen der Unit Tests?

Unit Tests können (wie jeder Test) die Fehlerfreiheit der getesteten Units, Module usw. nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Unit Tests liegen primär nur in den Fällen vor in denen man Fehler finden kann, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nur bedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, kann dazu führen, dass man tatsächlich (unbewusst) nur so viel testet, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis des (TDD) Test Driven Development.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u.U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Unit Tests (für den alten Code) zu tun, schafft Raum (wie jede Änderung im Code) für neue Fehlerrisiken und kann deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Unit Tests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und verpasst gegebenenfalls die Chance, diese aufzudecken. Wenn es sich um dieselbe Person handelt, kann man die vorrangige Entwicklung der Tests ebenfalls nicht garantieren, da sowohl die beabsichtigte Funktionsweise des Codes als auch die zukünftige Gestalt bereits im Gedankengut des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die man möglichst vermeiden sollte.

Der Beitrag Unit Tests – Fundament für stabile und effiziente Software erschien zuerst auf CEOsBay.

Kurze Zeitreise und die Entstehung von Community of Practice

Die Entstehung des Begriffs Community of Practice geht zurück auf das Jahr 1991. Geprägt durch die beiden Sozialwissenschaftler Jean Lave und Étienne Wenger. Sie stellten das Lernen in den Kontext sozialer Beziehungen. Dabei zeigten sie, dass für den Wissenserwerb – neben Strukturen oder Modellen – insbesondere die Teilnahme an einer Gemeinschaft entscheidend ist, in der man das Wissen konstruiert.

1998 erweiterte Etienne Wenger das Konzept für die Organisationsentwicklung und bestimmte damit einen neuen Entwicklungsschwerpunkt. Wenger hat mehr oder weniger die theoretische Grundlegung des Konzeptes beschrieben und generelle Verständnisgrundlagen des Konzeptes dargelegt. Aber auch außerhalb von Organisationen finden sich Communities of Practice. Besonders trifft man auf CoP’s bei internetgestützten Arbeitsgemeinschaften. Die Community of Practice wird heute in enger Verbindung zu Online-Communities und zum Wissensmanagement gesehen und stellt eine wichtige Möglichkeit zur Bildung sozialen Kapitals dar. Der Begriff des Wissensmanagements ist dabei von den beiden Herrschaften kritisch gesehen. Laut Lave, Wenger und anderen Sozialwissenschaftlern ist das Management von Wissen grundsätzlich nicht möglich. Wissen ließe sich ebenso wie die Bildung von Communities of Practice nicht „allein“ durch eine top-down Anordnung oder durch systematische Einrichtungsprozesse implementieren. Sozialwissenschaftler scheinen die Begriffe des „Gardening“ und „Nurturing“ zu bevorzugen.

Struktur

Eine Community of Practice besitzt in der Regel eine Struktur, in der Personen nicht via Festlegung eine bestimmte Rolle erhalten, sondern aufgrund ihrer Tätigkeit und der Akzeptanz bzw. Ablehnung durch andere Mitglieder eine Rolle erwerben. Mit „Festlegung“ ist in diesem Fall die Vorgabe durch Führungskräfte, Organisationsdiagramme oder andere „formale Vorgaben“ gemeint.

Den Begriff der Rolle, der besonders im deutschsprachigen Raum eine längere Tradition hat, verwenden die Sozialwissenschaftler dabei ungern. Sie sprechen von „Identität“, die sich ausbildet, und von Aufgabenverteilungen, die man untereinander aushandelt. So entwickeln sich auf Basis der Kommunikationsprozesse aktive und weniger aktive Mitglieder, Moderatoren und Experten. Diese Moderatoren darf man sich nicht als starr vergebene Positionen innerhalb des Geflechts der Community of Practice vorstellen. Es handelt sich hierbei auch um situativ ausgehandelte Funktionen und Aufgaben innerhalb der Community. Ebenso können sich Untergruppen bilden oder man bindet externe Personen als Gäste ein.

Aus eigener Erfahrung, beispielsweise im Open Source Space, kann ich sagen, dass zwar in der Öffentlichkeitsarbeit ein gewisses Bild einer Hierarchie erkennbar ist, doch innerhalb einer Arbeitsgruppe Rollen weitestgehend irrelevant sind. Dies liegt zum einen daran, dass man es meist mit sehr facettenreichen und gebildeten Personen zu tun hat und zum anderen daran, dass in diesem Umfeld das Lernen und die Wissensvermittlung im Vordergrund stehen.

Phasen

Fünf Phasen charakterisieren die Entwicklung einer Community of Practice.

1. Die erste Phase (Potential/Potenzial) ist durch eine oder mehrere Personen gekennzeichnet, die sich einer bestimmten Thematik annehmen.
2. Die zweite Phase (Coalescing/Vereinigung) ist geprägt durch die Bildung einer Grundstruktur, in der man Ziele, Aufgaben und Kommunikationswege skiziiert.
3. In der dritten Phase (Maturing/Reifung) beginnt die eigentliche Arbeit der Gemeinschaft. Der Wissensaufbau und Austausch. Mit zunehmender Aktivität steigt in der Regel auch die Zahl der Mitglieder. Fortlaufend werden Ziele, Aufgaben und Kommunikationswege bewertet und an die Bedürfnisse der Mitglieder durch die Mitglieder selbst angepasst.
4. Als vierte Phase (Stewardship/Verantwortung) wenn für die Mehrzahl der Mitglieder ein akzeptabler Stand erreicht ist und kein Bedarf für weitere Aktivitäten erkennbar sind. In diesem Fall sinkt die Anzahl der eingepflegten Informationen im Vergleich zu jener der entnommenen Informationen.
5. In der fünften und letzten Phase (Transformation/Umwandlung) verliert die Gemeinschaft zunehmend an Gewicht als zentraler Informationsknotenpunkt, weil man auf andere Quellen ausweicht oder die Thematik selbst an Bedeutung verliert.

Diese Phasen können, aber müssen nicht auf diese Art und Weise auftreten bzw. durchlaufen. Diesen Phasenablauf haben Wenger, Snyder und McDermott aus verschiedenen Fällen generalisiert, um so ein „Gerüst“ für den jeweiligen Unterstützungsbedarf für das Florieren der Community zugrunde zu legen.

Die Pflege von Community of Practice

Design for evolution

Stetige Veränderung ist notwendig: Anpassung an neue Mitglieder, Einführung neuer Mitglieder, Veränderung von Ressourcenlagen, Veränderung von Diskurstraditionen, Veränderung von Problemlagen von Mitgliedern, Veränderungen in der Struktur der CoP.

Open a dialogue between inside and outside perspectives

Der Austausch mit der Umgebung und die aktive Aushandlung von Bedeutung in der „Arena“ der CoP bilden den Hauptantriebsgrund, warum Menschen sich zu CoPs zusammenschließen.

Invite different levels of participation

Von Kernaktivisten allein wird keine CoP getragen. Man muss sich auch um den Nachwuchs für Positionen innerhalb der CoP kümmern. Der Einbezug von anderen „Zonen“ in der CoP trägt auch zur Pluralität der Blickwinkel auf ein spezifisches Problem bei.

Develop both public and private community spaces

Auch wenn die CoP oftmals selbst im „Organizational Underlife“ angesiedelt ist, so gibt es auch hier Bereiche, in denen sich Untergruppen treffen, in denen man Themen abseits der eigentlichen Agenda diskutiert, in denen man auch persönliche Problemlagen und Differenzen ansprechen kann, ohne vor das „Plenum“ der CoP zu treten. Spannungen bleiben unter Umständen bestehen, wenn man solche Probleme nicht abseits der „offiziellen Bühne“ diskutiert bzw. diskutieren kann. Oftmals bilden solche Nebenschauplätze auch die Geburtsstätte für nachfolgende Themen einer CoP, die diese dann aufrechterhält, wenn auch in vielleicht geänderter Konstellation.

Focus on value

Die Sicherstellung von Qualität ist auch für CoPs wichtig. Das betrifft sowohl die Pflege der CoPs auf einem Meta-Niveau als auch die Beiträge zum „Situated Negotiation of Meaning“.

Combine familiarity and excitement

Auch CoPs leben von tragenden Strukturen aus mehr routinisierten Praktiken und frischem Wind.

Create a rhythm for the community

Auch der Puls verschiedener Aktivitäten trägt zum Fortbestand und zu einem guten Arbeitsklima innerhalb der CoP bei.

Vorteile für das Individuum durch Community of Practice

Bei Community of Practice-Meetings geht es primär darum, Informationen und Fragen zu bestimmten Problemen aus dem professionellen Alltag zu besprechen und gemeinsam Lösungen zu finden. Die gegenseitige Unterstützung und Zusammenarbeit zwischen den Mitgliedern stehen damit im Vordergrund. Der große Vorteil liegt darin, dass Personen miteinander interagieren, die sonst im Alltag meist nicht miteinander arbeiten. Bei CoP-Meetings hat man die Möglichkeit individuelle Erfahrungen miteinander zu teilen, um daraus wiederum neue Möglichkeiten zu kreieren und bestimmte Herausforderungen zu meistern. Einzig durch die Interaktion von unterschiedlichen Netzwerken können neue Ideen entstehen, wobei jede Partei ihre eigenen Sichtweisen teilt, die Einfluss auf die Entscheidungen der anderen hat und dadurch ein Lerneffekt entsteht. Arbeiten und Lernen gehören im professionellen Kontext stets zusammen. Eine Community of Practice fördert diese Zusammenkunft von Arbeit und Lernen.

Vorteile für die Community

Communities profitieren von Community of Practice dahin gehend, dass das Team sich selbstständig und selbstorganisiert weiterentwickelt, ohne, dass Führungspersonen oder Verantwortliche kostspielige Ausgaben für Fortbildungen oder Ähnliches ausgeben müssen. 

Voraussetzungen hierfür sind natürlich, die verfügbare Zeit und die Ressourcen für die eingesetzte Hard- und Software bzw. je nachdem, in welchem Umfeld und mit welcher Zielsetzung man unterwegs ist. Die in den Meetings neu erlangten Kenntnisse wirken sich direkt auf die Leistungen im täglichen Leben aus.

Fazit

In meiner Wahrnehmung bzw. in meinem Verständnis, gehe ich davon aus, dass bei der Themenverarbeitung durch einige Sozialwissenschaftler im „Community of Practice“ von einer physischen Präsenz der Teilnehmenden die Rede ist. Zumal die Literatur, die ich gelesen habe, noch aus den frühen 90’ern ist. Jedoch habe ich diese Art von CoP’s primär online kennenlernen dürfen. Dementsprechend habe ich an Meetings virtuell bzw. remote teilgenommen, was seit den Anfängen der Coronapandemie immer häufiger stattgefunden hat und auch im konventionellen Geschäftsleben mehr und mehr ankommt. Besonders im Blockchain Space hat sich diese Methode sehr stark etabliert. Folglich konnte ich die genannten 5 Phasen mehrfach, sowohl mit einem positiven als auch mit einem negativen Verlauf wiedererkennen. Alles in allem sehe ich es von Vorteil, sich mit diesem Thema auseinanderzusetzen. So erhält man eine etwas differenzierte Sicht auf die Zusammenarbeit innerhalb und außerhalb von Communities und kann bewusst mit diversen Herausforderungen umgehen.

Der Beitrag Community of Practice – Kraft des gemeinsamen Lernens und Wachsens erschien zuerst auf CEOsBay.

Sie ist als bedarfsgerechte Verfügbarkeit von Computer-Systemressourcen, insbesondere von Datenspeichern (Cloud Storage) und Rechenleistung zu verstehen. Mittlerweile kann man fast die gesamte IT-Infrastruktur ganzer Unternehmen in die Cloud verfrachten. Darüber hinaus wird es heutzutage fast schon erwartet, dass der Administrator bzw. Nutzer die Server als auch die Komponenten der Infrastruktur nicht mehr direkt bzw. aktiv selbst verwalten oder warten müssen.

Große Cloud-Anbieter stellen oft Server bzw. Funktionen zur Verfügung, die auf mehrere Standorte und Systeme verteilt sind. Dadurch werden die Verfügbarkeit und die Zugriffszeiten auf einem optimalen Niveau und redundant gehalten. In der Regel handelt es sich bei jedem dieser „Zugriffspunkte“ meistens um eigenständig agierende Rechenzentren. Cloud Computing beruht auf der gemeinsamen Nutzung von Ressourcen, um im Best-Case-Szenario maximale Kohärenz bzw. Redundanz und damit eine erhöhte Ausfallsicherheit zu erreichen. Meistens wird ein „Pay-as-you-go“-Modell angeboten, welches zur Kostensenkung beitragen soll, aber auch zu unerwartet hohen Betriebskosten führen kann.

Seit wann schicken wir unsere Daten in, durch und über die Wolken durch Cloud Computing?

Die ersten Time-Sharing-Konzepte wurden in Form von RJE realisiert. Was an „JRE“ „Java Runtime Environment“ erinnert, dass ich durchaus in einem späteren Beitrag thematisieren werde, sich aber eigentlich um Remote Job Entry bzw. Remote-Job-Eingabe handelt. Die Konzepte dafür erfreuten sich einer gewissen Popularität in den 60ern größtenteils bei den Computergiganten IBM und DEC. Anfang der 70er waren Time-Sharing-Lösungen auf Plattformen wie Multics (auf GE-Hardware), Cambridge CTSS und den ersten UNIX-Ports (auf DEC-Hardware) verfügbar. Dennoch war das „Rechenzentrums“-Modell, bei dem die Benutzer den Betreibern Aufträge zur Ausführung auf den IBM-Mainframes erteilten, vorherrschend.

Ist/war Time-Sharing bereits Cloud Computing?

In der Informatik handelt es sich bei Time-Sharing, um die gemeinsame Nutzung einer Rechenressource durch viele Benutzer zur gleichen Zeit mittels Multiprogramming und Multitasking.

Was ist/war RJE

Es ist ein Verfahren, mit dem von entfernten Arbeitsplätzen aus Anfragen für nicht interaktive Datenverarbeitungsaufgaben (Jobs) an Großrechner gesendet werden und damit auch den Prozess des Empfangs der Ausgabe solcher Jobs an einem entfernten Arbeitsplatz zu ermöglichen.

Das Aufkommen als führendes Computermodell in den 70er Jahren stellte einen bedeutenden technologischen Wandel in der Geschichte der Computertechnik dar. Durch die Möglichkeit, dass viele Benutzer gleichzeitig mit einem einzigen Computer interagieren konnten, senkte die Kosten für die Bereitstellung von Rechenkapazitäten drastisch und ermöglichte es Einzelpersonen und Organisationen, einen Computer zu nutzen, ohne diesen besitzen zu müssen. Zeitgleich wurde dadurch die interaktive Nutzung von Computern und die Entwicklung neuer interaktiver Anwendungen gefördert bzw. vorangetrieben.

In den 90er Jahren begannen Telekommunikationsunternehmen, die zuvor hauptsächlich dedizierte Punkt-zu-Punkt-Datenleitungen anboten. 

Was ist eine (P2P) Punkt-zu-Punkt-Verbindung

Eine Punkt-zu-Punkt-Verbindung ist eine private Datenverbindung, die zwei oder mehr Standorte für private Datendienste sicher miteinander verbindet. Es handelt sich dabei in der Regel um einen geschlossenen Netzdatentransportdienst, der nicht über das öffentliche Internet läuft und von Natur aus etwas „sicherer“ ist. Ich persönlich kannte als Vergleich das Tunneling, welches in der Regel bei VPN-Diensten zum Einsatz kommt. VPN-Dienste (Virtual Private Networks). Dieses Thema werde ich zu einem späteren Zeitpunkt in einem separaten Beitrag aufgreifen.

Weiter mit der Entstehungsgeschichte

Sie begannen, das Cloud-Symbol zu verwenden, um die Grenze zwischen dem, wofür der Anbieter und dem, wofür die Nutzer verantwortlich waren, zu markieren. Mit dem Cloud Computing wurde diese Grenze auf alle Server und die Netzinfrastruktur ausgedehnt. Mit der zunehmenden Verbreitung von Computern erforschten Wissenschaftler neue Möglichkeiten. Primär um die Rechenleistung in großem Maßstab durch Time-Sharing einer größeren Audienz zur Verfügung zu stellen.

Sie experimentierten mit Algorithmen zur Optimierung der Infrastruktur, der Plattformen und Anwendungen. Primär zur Priorisierung der Berechnungen durch die CPUs, der auszuführenden Aufgaben und zur Steigerung der Effizienz für die Endnutzer. CPU’s = Central Processing Unit – Die zentrale Recheneinheit – In anderen Worten, das Gehirn des Computers. Hier werden in einem bestimmten Rhythmus Befehle interpretiert und ausgeführt.

Die Verwendung der Cloud-Metapher für virtualisierte Dienste geht mindestens auf General Magic aus dem Jahr 1994 zurück. Die wurde verwendet, um das Universum der „Orte“ zu beschreiben, die mobile Agenten in der Telescript-Umgebung aufsuchen konnten. Wie von Andy Hertzfeld beschrieben:

„Das Schöne an Telescript“, so Andy, „ist, dass wir jetzt nicht mehr nur ein Gerät zum Programmieren haben, sondern die gesamte Cloud, in der ein einzelnes Programm zu vielen verschiedenen Informationsquellen reisen und eine Art virtuellen Dienst erstellen kann.“

Die Verwendung der Cloud-Metapher wird dem Kommunikationsmitarbeiter von General Magic, David Hoffman, zugeschrieben. Es basiert auf der langjährigen Verwendung im Netzwerk- und im Telekommunikationsbereich.

Im Jahr 2002 legte dann Amazon mit der Tochtergesellschaft Amazon Web Services nach. Es ermöglichte Entwicklern, innovative und unternehmerische Anwendungen zu entwickeln. Im März 2006 führte Amazon seinen Simple Storage Service (S3) ein. Dicht gefolgt von Elastic Compute Cloud (EC2) im August desselben Jahres. Diese Produkte leisteten so gesehen Pionierarbeit für die Nutzung der Server-Virtualisierung bzw. zur Bereitstellung von IaaS (Infrastructure as a Service). Dazu aber später mehr. 

Im April 2008 veröffentlichte Google die Beta-Version von Google App Engine, welches PaaS, dass eine vollständig gewartete Infrastruktur und eine Bereitstellungsplattform für Benutzer zur Erstellung von Webanwendungen in den gängigen Programmiersprachen Python, Node.js und PHP bot. Dies war damals etwas völlig neuartiges. Ziel war es, einige der für ein IaaS-Modell typischen Verwaltungsaufgaben zu eliminieren. Gleichzeitig sollte eine Plattform geschaffen werden, auf der die Nutzer solche Anwendungen einfacher bereitstellen und je nach Bedarf skalieren konnten.

Ebenfalls im Jahr 2008 wurde dann Nebula veröffentlicht. Ein Produkt aus einem Programm der NASA, dass im Rahmen des von der Europäischen Kommission finanzierten „RESERVOIR“-Projekts weiterentwickelt wurde. Es wurde zur ersten quelloffenen Software für den Einsatz privater und hybrider Clouds.

Mitte 2008 sah Gartner bereits die erhöhte Wahrscheinlichkeit, dass Cloud Computing die Beziehung zwischen den Nutzern von IT-Diensten und denjenigen, die IT-Dienste zur Verfügung stellen, grundsätzlich verändern wird. Gartner ging davon aus, dass Individuen und Unternehmen von unternehmenseigenen Hardware- und Software-Assets zu Service-basierten Modellen wechseln werden. Diese Verlagerung auf das Cloud Computing, sollte in einigen Bereichen zu einem dramatischen Wachstum und in anderen Bereichen zu einer deutlichen Reduzierung bei IT-Produkten führen.

So schlecht war die Prognose eigentlich gar nicht. Wir befinden uns nach wie vor in diesem Prozess 😀

Im gleichen Jahr startete die U.S. National Science Foundation (NSF) das Cluster Exploratory-Programm, um akademische Forschungsarbeiten zu finanzieren, die Google-IBM-Clustertechnologie zur Analyse großer Datenmengen einsetzen sollte.

Wieso Cloud Computing?

Das Ziel des Cloud Computing ist es, den Nutzern die Möglichkeit zu geben, von allen „neuen“ Technologien zu profitieren, ohne, dass man über tiefgreifende Kenntnisse oder Erfahrungen mit jeder einzelnen Technologie verfügen muss. Die Cloud soll die Kosten senken und den Nutzern helfen, sich auf ihr Kerngeschäft zu konzentrieren. IT-Hindernisse sollen die Arbeit nicht behindern. Die wichtigste Grundlagentechnologie für Cloud Computing ist die Virtualisierung. Virtualisierungssoftware unterteilt ein physisches Computersystem in ein oder mehrere virtuelle Maschinen. Jedes Einzelne zur Ausführung Verwendung und Verwaltung von Computeraufgaben.

Durch die Virtualisierung auf Betriebssystemebene, die im Wesentlichen ein skalierbares System aus mehreren unabhängigen Computergeräten schafft, können ungenutzte Computerressourcen effizienter zugewiesen und genutzt werden. Virtualisierung bietet die nötige Flexibilität, um den IT-Betrieb zu beschleunigen und die Kosten durch eine bessere Auslastung der Infrastruktur zu senken. Autonomic Computing automatisiert den Prozess, durch den der Benutzer Ressourcen nach Bedarf bereitstellen kann. Durch die Minimierung des Benutzereingriffs soll die Automatisierung die Prozesse beschleunigen, die Arbeitskosten senken und die Möglichkeit menschlicher Fehler reduzieren.

Obwohl die serviceorientierte Architektur „Everything as a Service“ (mit den Akronymen EaaS oder XaaS oder einfach aas) befürwortet, bieten Cloud-Computing-Anbieter ihre „Dienste“ nach verschiedenen Modellen an. Diese sind in die drei Standardmodelle nach NIST gegliedert. Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Diese Modelle bieten eine zunehmende Abstraktion. Sie werden daher oft als Schichten in einem Stapel dargestellt. Infrastruktur-, Plattform- und Software-as-a-Service, aber diese müssen nicht miteinander verbunden sein. So kann man beispielsweise SaaS auf physischen Maschinen implementieren. Jedoch ohne die zugrunde liegenden PaaS- oder IaaS-Schichten zu verwenden. Und umgekehrt kann ein Programm auf IaaS ausgeführt und direkt darauf zugegriffen werden, ohne es als SaaS zu verpacken.

Infrastructure as a service (IaaS)

Infrastructure as a Service stellt Unternehmen IT-Ressourcen zur Verfügung. Darunter fallen Server-, Netzwerkkomponenten und Speicher, sowie Stellflächen im Rechenzentrum auf der Basis nutzungsabhängiger Gebühren.

Die Vorteile von IaaS

• Man muss nicht in eigene Hardware investieren oder für die Wartung persönlich eingreifen.
• Die Infrastruktur kann bei Bedarf zur Unterstützung dynamischer Workloads skaliert werden.
• Bei Bedarf erhält man relativ flexible und innovative Services.

Platform as a Service (PaaS)

Platform as a Service stellt eine Cloud-basierte Umgebung mit allen Komponenten bereit. Zur Unterstützung des gesamten Lebenszyklus, von der Erstellung bis zur Bereitstellung, von webbasierten (Cloud-) Anwendungen.

Die Vorteile von PaaS

• Schnellere Entwicklung und Markteinführung von Anwendungen.
• Bereitstellung neuer Webanwendungen in der Cloud innerhalb kürzester Zeit.
• Geringere Komplexität mit Middleware as a Service.

Software as a Service (SaaS)

Cloud-basierte Anwendungen – oder Software as a Service. Im Grunde genommen auf Remote-Computern „in der Cloud“ ausgeführt, deren Eigentümer und Betreiber in der Regel externe Anbieter sind. Die Nutzer stellen über das Internet und primär über einen Web-Browser eine Verbindung zu diesen Remote-Computern her.

Die Vorteile von SaaS

• Man kann nach der Anmeldung und Einrichtung relativ schnell mit der Nutzung und Erstellung innovativer Anwendungen beginnen.
• Der Zugriff auf Anwendungen und Daten ist von jedem angebundenen Endgerät aus möglich.
• Bei einem Ausfall des Endgeräts kommt es zu keinem Datenverlust, da die Daten in der Cloud gespeichert sind.
• Der Service kann dynamisch an die Anforderungen der Nutzung angepasst werden.

Public Cloud

Eigentümer und Betreiber von Public Clouds sind Unternehmen oder Individuen, die schnellen Zugriff auf kosteneffiziente IT-Ressourcen über ein öffentliches Netzwerk bereitstellen möchten. Bei Public-Cloud-Services müssen die Nutzer keine Hardware, Software oder unterstützende Infrastruktur einkaufen. Die sind und bleiben in der Regel Eigentum des jeweiligen Providers und werden von diesem betrieben und gewartet.

Vorteile der Public Cloud

• Innovative SaaS-Anwendungen, die von CRM-Anwendungen (Customer Resource Management) über das Transaktionsmanagement bis zu Datenanalysen reichen.
• Flexible, skalierbare IaaS für sofort einsatzbereite Speicher- und Rechenservices.
• Leistungsfähige PaaS für Cloud-basierte Umgebungen für die Anwendungsentwicklung und -bereitstellung.

Private Cloud

Eine Private Cloud ist eine Infrastruktur, die nur für ein einziges Unternehmen oder ein einziges Individuum betrieben wird. Für deren Management und Hosting kommt entweder das Unternehmen, der Nutzer selbst oder ein externer Provider in Frage. Private Clouds können die Effizienz der Cloud nutzen. Sie bieten jedoch mehr Kontrolle über die Ressourcen und verzichten auf die Nutzung des Multi-Tenant-Modells.

Vorteile der Private Cloud

• Self-Service-Schnittstelle zur Steuerung der Services, die IT-Mitarbeitern oder Spezialisten eine schnelle Provisionierung, Zuordnung und Bereitstellung von IT-Ressourcen bei Bedarf ermöglicht.
• Hochautomatisiertes Management von Ressourcenpools für alle Aspekte von Rechenkapazität bis zu Speicher, Analytics und Middleware.
• Ausgereifte Sicherheit und Governance, die für die Anforderungen des jeweiligen Unternehmens konzipiert sind.

Hybrid Cloud

Eine Hybrid Cloud nutzt eine Private-Cloud als Grundlage, die mit der strategischen Integration und Nutzung von Public-Cloud-Services kombiniert wird. Tatsächlich kann eine Private Cloud nicht isoliert von den übrigen IT-Ressourcen eines Unternehmens oder Individuums und der Public Cloud existieren. Die meisten Unternehmen und Individuen mit Private Clouds, weiten das Workload-Management auf eine Kombination von Rechenzentren, Private Clouds und Public Clouds aus. Dadurch entstehen Hybrid Clouds.

Vorteile einer Hybrid Cloud

• Möglichkeit für Nutzer und Unternehmen, kritische Anwendungen und sensible Daten in einer traditionellen Rechenzentrumsumgebung oder einer Private Cloud auszuführen bzw. zu speichern.
• Nutzung von Public-Cloud-Ressourcen wie SaaS (für die neuesten Anwendungen) und IaaS (für anpassungsfähige virtuelle Ressourcen).
• Einfachere Portierbarkeit von Daten, Anwendungen und Services plus größere Auswahl an Bereitstellungsmodellen.

Nachteile aller Cloud Computing Lösungen

Nun, bevor ich zu jeder einzelnen Lösung jeweils die Nachteile aufzähle, hier die Nachteile für alle Lösungen zusammengefasst.

• Datensicherheit & Datenverfügbarkeit – Das Argument der Abhängigkeit von einem Anbieter kann für Individuen Unternehmen schwer wiegen.
• Begrenzte Individualisierung.
• Abhängigkeit vom Cloud-Anbieter und Cloud-Dienstleister.
• Schlechte Portabilität – Wenn man mal den Anbieter wechseln will.
• Verfügbarkeit – Ja, man benötigt immer einen Internetanschluss. Ansonsten geht gar nichts 😀

Fazit

Soweit ich es beurteilen kann, ist Cloud Computing bereits im Unternehmensalltag angekommen. Nach der anfänglichen Skepsis und Unsicherheit, gehen die meisten Individuen, Unternehmen und bekannte Dienst- und Content-Creator über in die Cloud. Sie entwickeln immer mehr Cloud Computing Anwendungen und Dienste. Sicherlich ist nicht außer acht zu lassen, dass die größeren Anbieter eher im amerikanischen Raum vertreten sind. Folglich wird dadurch auch eine gewisse Abhängigkeit geschaffen.

Es zeigt sich jedoch auch, dass traditionelle Anwendungen, Netzwerkstrukturen und Bereitstellungsmodelle neuen, innovativen Anwendungen nicht mehr lange standhalten können. Die Nutzer erwarten auch bei der mobilen Arbeit einen einfachen Zugang und eine gewisse Flexibilität. Dies kann fast nur über Cloud Lösungen ermöglicht werden.

In meiner Idealvorstellung kann sich eine globale Netzwerk-Infrastruktur bilden lassen, die von Landesgrenzen relativ losgelöst ist. Ich kann mir vorstellen, dass in der Zukunft dezentralisierte Open Source Cloud Computing Plattformen geschaffen werden. Diese können dem Nutzer bzw. der Gesellschaft einen Mehrwert bieten. Ohne zeitgleich ein Vermögen von einzelnen Individuen oder Unternehmen zu fordern. Ein Sprungbrett dafür bietet die Blockchain und die bereits bestehende globale Open Source Gemeinde. Und vielleicht kann auch so das Fundament für ein funktionsfähiges Metaverse geschaffen werden.

Die Netzwerk-Infrastruktur wird sich ohnehin weiterentwickeln, um sich den durch Virtualisierung und Cloud Computing getriebenen Innovationen rasch anzupassen. Cloud Computing befindet sich meiner Meinung nach immer noch in einer gewissen Entwicklungsphase. Daher können bereits heute die Weichen dafür gestellt werden, um nicht nur den vereinigten Staaten die Hoheit über Cloud Lösungen zu überlassen, sondern der ganzen Welt als Einheit.

Der Beitrag Cloud Computing – Skalierbare Ressourcen und grenzenlose Möglichkeiten für agile Lösungen erschien zuerst auf CEOsBay.