Cloud: IaaS, PaaS, SaaS, DaaS, FaaS, DBaaS

Einführung

Vielleicht haben Sie etwas über einige der folgenden Themen gehört: IaaS, PaaS, SaaS, DaaS, FaaS, DBaaS. Wenn Sie kein DevOps-Ingenieur sind, haben Sie wahrscheinlich von einigen dieser Konzepte gehört, aber nicht von allen. Ich denke, selbst wenn Sie einige davon verwendet haben, wissen Sie höchstwahrscheinlich nicht alles, was Sie sollten. Möglicherweise haben Sie sogar einige Teile verwendet, ohne den Namen des angewandten Konzepts zu kennen.

Schauen wir uns das genauer an, um besser zu verstehen, was sie wirklich sind.

Warum auf eine Cloud-basierte Architektur umsteigen?

1. Notfallwiederherstellung — Sie können viele Datencluster auf der ganzen Welt haben, z. B. in den USA, Großbritannien, Japan, Australien, und wenn es irgendwo einen Hurrikan, eine Flut oder einen Lauffeuer gibt, können Sie Ihre Daten aus den überlebenden Datenspeichern klonen.
2. Verfügbarkeit — Nehmen wir an, es gibt einen Hurrikan in Puerto Rico, wo wir unzerstörbare Server in einem Luftschutzbunker haben, aber dort fällt der Strom aus, sodass Puerto Rico für zwei Tage komplett vom Rest der Welt abgeschnitten ist. Zum Glück haben wir andere Server in Deutschland, sodass die Web-App immer noch zugänglich ist.
3. Skalierbarkeit — Stellen wir uns vor, wir haben einen großen Serverraum. Wenn also die Anzahl unserer App-Benutzer, Daten und Anfragen wächst, können wir neue CPUs und RAM-Sticks dort platzieren, aber irgendwann wird es keinen Platz mehr geben. Zum Glück ist das mit der Cloud-Architektur kein Problem mehr, da Sie Ressourcen verwenden können, die sich überall auf der Welt befinden.
4. Kostensparend - Cloud Computing führt häufig zu Kosteneinsparungen durch reduzierte Hardware-, Software- und Personalkosten. ‍
5. Schlichtheit — lassen Sie uns das Thema Deployment fortsetzen. Wie stellen Sie die App bereit? Jedes Mal manuell? Oder erstellen Sie Ihr eigenes System für den kontinuierlichen Einsatz? Oder verwenden Sie einfach sofort einsatzbereite Dienste wie Heroku oder Google App Engine?‍
6. Automatische Softwareupdates — Sie verwenden z. B. MLab und in regelmäßigen Abständen gibt es eine aktualisierte MongoDB-Version mit so geringen Ausfallzeiten wie möglich kostenlos. Wenn Sie sie bezahlen, können die Ausfallzeiten praktisch nicht existieren.‍
7. Von überall aus arbeiten — Sie können z. B. ein Google-Blatt von jedem Gerät aus bearbeiten oder es von jedem Computer aus in ein GitHub-Repository übertragen.‍
8. Verstärkte Zusammenarbeit — z. B. kann ein Google-Tabellenblatt von vielen Nutzern bearbeitet werden, auch wenn ihnen verschiedene Berechtigungsebenen zugewiesen werden.‍
9. Versionskontrolle — Sie können eine Plattform wie GitHub, BitBucket, GitLab verwenden oder einfach eine Versionskontrolle von Dokumenten in Google Docs oder Confluence haben.‍
10. Sicherheit — auch wenn Ihr Laptop, Tablet oder Smartphone gestohlen wird, können Sie ein Backup auf DropBox, Google Drive oder iCloud erstellen.

<span class="colorbox1" fs-test-element="box1"><p>Lernen wie man eine effektive Cloud-Migrationsstrategie vorbereitet um all diese Vorteile zu nutzen.</p></span>

Es ist wichtig zu beachten, dass die Umstellung auf die Cloud ein schwieriger und ressourcenintensiver Prozess ist. Daher ist es wichtig, die Anwendung im Voraus entsprechend vorzubereiten. Der Prozess, das Produkt für die Umstellung vorzubereiten, kann Folgendes beinhalten Umgang mit technischen Schulden, das früher zur Seite gelegt wurde.

Aber lassen Sie uns zunächst über die Cloud im Kontext von Webanwendungen sprechen.

Die wichtigsten Arten von Backend-Architekturen

Monolith. Das gesamte Backend wird an einem Ort bereitgestellt, daher ist es sehr umfangreich und für große Apps schwer zu skalieren.

Mikrodienste. Das Backend ist in viele Microservices unterteilt (das hängt hauptsächlich von der Größe der App ab, aber normalerweise sind es 10 bis 80), die auf verschiedenen physischen Servern bereitgestellt werden können. Jeder Microservice sollte eine Geschäftsfunktion widerspiegeln, z. B. Authentifizierung, Zahlungen, Auktionen, E-Mails oder Inventar.

<span class="colorbox1" fs-test-element="box1"><p>Sind Microservices immer besser als Monolith? Glaube dem Hype nicht! Erkunden Sie das Thema in Die Fallstudie Monolith im Vergleich zu Microservices</p></span>.

Funktionen. Im Gegensatz zu Monolith und Microservices sind sie keine Daemons (die ständig laufen), sondern werden nur innerhalb von maximal wenigen Sekunden ausgeführt, wenn es nötig ist; ein Beispiel ist AWS Lambda, geschrieben in es7:

XaaS

Es ist ein allgemeines Akronym, das alle... aaS-Lösungen bedeutet.

dBaaS

Datenbank als Service — es ist eine Plattform, die hostet unsere Datenbank und bietet Backups, Clustering und Hochverfügbarkeit. Die beliebtesten DBaaS sind Amazon Aurora, Amazon DynamicDB, mLab, IBM Cloudant und MongoDB Atlas.

IaaS

Infrastructure as a Service — das ist die niedrigste Stufe aller XaaS. Es bietet uns eine große Leistung, erfordert aber viel Konfiguration. IaaS bietet eine virtuelle Maschine, die wir warten müssen. Der Unterschied zwischen IaaS und einem physischen Serverraum ist Wir müssen keine physischen Computer kaufen und wir können Server in verschiedenen Teilen der Welt haben. Im Vergleich zu anderen XaaS ist IaaS jedoch schwieriger zu verwalten und erfordert eine gute DevOps Ingenieur, der die virtuellen Maschinen so konfiguriert, dass sie effizient und sicher arbeiten.

PaaS

Platform as a Service ist ein einfache Möglichkeit, eine App bereitzustellen in einer bestimmten Technologie (z. B. Node.js, Ruby, PHP, Python, Java, .NET - es wird also oft verwendet von .NET-Entwicklungsunternehmen). Die beliebtesten Plattformen sind Heroku und Google App Engine.

Im Allgemeinen Sie müssen CI nicht konfigurieren (kontinuierliche Integration). Drücken Sie einfach einen Commit, es erkennt, dass sich die App in Node.js befindet, und es werden npm install (Sie können zusätzliche Befehle im Postinstall-Skript hinzufügen, das von NPM nach der Installation der Abhängigkeiten ausgeführt wird) und npm start ausgeführt. Wenn sich die App in Ruby befindet, wird die Paketinstallation und ähnliches für andere Umgebungen ausgeführt.

Der Hauptnachteil ist, dass es nicht zu flexibel ist, weil es benutzerdefinierte Systemabhängigkeiten können nicht installiert werden (z. B. von apt-get) und du kannst verwenden Sie nur eine der verfügbaren Technologien. Wenn Sie also Ihre eigene Programmiersprache erstellen, die auf keiner verfügbaren Plattform läuft (z. B. in Node.js können Sie TypeScript, CoffeeScript, Elm... neben JavaScript verwenden oder in Java Virtual Machine können Sie neben Java auch Scala, JRuby, Jython, Kotlin, Groovy... verwenden), aber direkt in den Bytecode kompiliert wird, können Sie PaaS nicht verwenden.

Ein weiterer Nachteil ist der Daten sind nicht sicher. Wenn Sie beispielsweise Heroku als Paas und MLab als DBaaS verwenden, hat nicht nur MLab Zugriff auf Ihre Daten, sondern auch Heroku, da Sie nie wissen, welcher Code tatsächlich auf dem Server ausgeführt wird. Vielleicht anders als dein Code, weil sie ihre eigenen Middlewares hinzufügen, um etwas zu protokollieren.

SaaS

Software as a Service bietet sofort einsatzbereite Software wie NPM//GEM-Bibliotheken, aber es erfordert keine Bereitstellung/Serverwartung von uns.

Ein einfaches Beispiel ist eine Mailing-App wie SparkPost oder SendGrid. Alles, was wir tun müssen, ist eine HTTP-Anfrage mit der Absenderadresse, Empfängeradresse, E-Mail-Betreff, E-Mail-Inhalt usw. zu senden. Andererseits müssten wir ohne diese Art von Tool einen SMTP-Server einrichten und ihn skalieren, wenn die Anzahl der E-Mails wächst.

Andere Beispiele sind: Google Apps (z. B. Google Drive), DropBox und Slack — diese Apps können von einem menschlichen Nutzer verwendet werden, haben aber tolle Integrationsmöglichkeiten ebenso. Neben den bereits existierenden SaaS bieten einige Unternehmen (z. B. SAP) an, auf Abruf neue SaaS zu schreiben.

DaaS

Data as a Service ähnelt SaaS und kann sogar als Teilmenge von SaaS betrachtet werden. Genauer gesagt ist es ein (normalerweise HTTP) API, die einige Daten zurückgibt z. B. Wechselkurse, Sportergebnisse oder Wettervorhersagen.

Was ist das größte DaaS? Wahrscheinlich Facebook, das viele Daten sammelt und sie für Facebook-Apps bereitstellt. Andere beliebte DAAs sind Google Maps, Google Translate API oder AccuWeather.

Eine Liste nützlicher DaaS ist verfügbar hier.

Häufig gestellte Fragen

Function as a Service ist noch einfacher als PaaS. Wie der Name schon sagt, basiert es auf den Funktionen, die durch ein bestimmtes Ereignis ausgelöst werden können, es ist also ein ereignisbasiert Architektur. Das Maß an Einfachheit ist so hoch, dass es als bezeichnet wird serverlose Architektur. Der Entwickler schreibt einfach eine Funktion und muss nicht über Themen wie Bereitstellung, Serverressourcen, Skalierbarkeit nachdenken... Das liegt daran, dass FaaS automatisch skalierbar. Daher basiert die Abrechnung auf dem tatsächlichen Verbrauch, nicht auf dem angegebenen Ressourcenbedarf.

Das bekannteste Beispiel ist AWS Lambda, aber es gibt auch andere wie Google Cloud Functions, Microsoft Azure Functions, Iron.io und WebTask.io.

Einer der größten Nachteile von FaaS sind unterstützte Technologien. Es gibt sogar weniger verfügbare Technologien als bei PaaS. Genauer gesagt (Stand 2017) unterstützt AWS Lambda .NET, Java, Node.js und Python. Microsoft Azure Functions unterstützt .NET, Java, Node.js und PHP, wohingegen Google Functions nur Node.js unterstützt. Wie Sie also feststellen können, unterstützt keines der beliebtesten FaaS Ruby im Gegensatz zu PaaS (z. B. Heroku).

Was können FaaS-Funktionen tun?

Teilen wir die Funktionen nach den Funktionen von Microsoft Azure Functions auf:

• Generischer Webhook — verarbeitet eine HTTP-Anfrage wie ein Controller in einem Monolith oder Microservice, kann entweder von unserem System (eine andere Funktion oder ein Microservice) oder von einem externen System aufgerufen werden, das Webhooks unterstützt (das bedeutet, dass ein externes System eine HTTP-Anfrage an unseren Webhook sendet) wie Stripe oder Slack
• GitHub-Webhook — eine bestimmte Art von Webhooks, die auf GitHub-Ereignissen aufgerufen werden. In der Microservices/Monolith-Architektur könnte dies mit CI geschehen
• Timer-Trigger — Wird zur angegebenen Zeit aufgerufen, in der Microservices/Monolith-Architektur könnte dies innerhalb des Codes (setTimeout/setInterval) oder mit einem Warteschlangen-Tool wie RabbitMQ erfolgen
• Cosmos DB-Trigger — wird aufgerufen, wenn Cosmos DB-Dokumente hinzugefügt oder aktualisiert werden, sodass es wie ein Datenbank-Trigger funktioniert. Auf anderen Plattformen als Microsoft Azure Functions können FaaS-Funktionen von anderen DBMS aus ausgelöst werden
• BLOB-Trigger — wird aufgerufen, wenn Microsoft Azure Storage-Blobs zu Containern hinzugefügt werden. Eine nützliche Anwendung ist das Ändern der Bildgröße
• Warteschlangen-Trigger — ermöglicht die Verarbeitung von Warteschlangen, in einer Monolith-/Microservices-Architektur könnte dies mit einem Warteschlangen-Tool wie RabbitMQ erreicht werden
• EventHub-Trigger — wird im Internet der Dinge verwendet

Wie Sie sehen, können wir mit FaaS implementiere einen beliebigen Algorithmus (Turing-Vollständigkeit) Da wir eine HTTP-Anfrage bearbeiten können, können wir eine weitere HTTP-Anfrage senden und außerdem Zeit- und Warteschlangenereignisse verarbeiten.

Was kann FaaS (Function as a Service) nicht?

Die einzigen Einschränkungen betreffen die Unterstützung bestimmter Technologien, z. B. eines bestimmten FaaS-Anbieters. unterstützt das MQTT-Protokoll nicht Es erfordert also die Verwendung einer Anwendung, die MQTT in HTTP umwandelt, ein anderes von FaaS unterstütztes Format, oder wir benötigen einen Endpunktteil des Systems, der mit dem Menschen (Web-App, mobile App oder Desktop-App) oder der physischen Umgebung (ein Roboter, der die Wetterbedingungen überprüft, ein Drucker, eine Glühbirne...) interagiert — das alles kann in der FaaS-Architektur eingebaut werden, erfordert aber einige Adapter außerhalb der FaaS-Welt.

Funktionen können sein kombiniert mit Microservices, damit wir FaaS mit PaaS verbinden können, aber es ist auch möglich, das zu erstellen gesamtes Backend auf FaaS (mit einigen Einschränkungen für die auf der Backend-Seite verwendeten Technologien).

Lassen Sie uns jedoch einen weiteren Nachteil besprechen — wir schreiben einen Code, der auf einer bestimmten FaaS (z. B. Microsoft Azure Functions) läuft, sodass für den Wechsel zu einem anderen FaaS (z. B. Google Functions) möglicherweise sogar die Hälfte des als FaaS-Funktionen geschriebenen Codes neu geschrieben werden muss. Andererseits sollte der Wechsel von einem PaaS zu einem anderen relativ einfach sein.

Was kommt als Nächstes?

Es gibt noch mehr XaaS, als Sie sich vorstellen können:

• Analytik als Service
• Authentifizierung als Service
• Backup als Service
• Geschäft als Service
• Kommunikation als Service
• Informatik als Service
• Inhalt als Service
• Desktop als Service
• Energiespeicher als Service
• Betrug als Service
• Spiele als Service
• Hardware als Service
• IT als Service
• Jobs als Service
• Wissen als Service
• Loggen als Dienst
• Mashups als Service
• Mobiles Backend als Service
• MongoDB als Service
• Überwachung als Service
• Netzwerk als Service
• Oracle als Service
• Zahlungen als Service
• Qualität als Service
• Query als Service
• Erholung als Service
• Replikation als Service
• Roboter als Service
• Routing als Service
• Suche als Service
• Sicherheit als Service
• Speicher als Service
• Testen als Service
• Versorgungsunternehmen als Service
• Virtualisierung als Service
• WLAN als Service//WLAN als Service
• WAN-Optimierung als Service

‍

Zusammenfassung

Wie Sie sehen, können viele der XaaS sogar dasselbe Akronym haben und eines kann eine Teilmenge eines anderen sein. Es ist eine schwierige Frage, welches XaaS in einem bestimmten Projekt und einer bestimmten Situation verwendet werden sollte. Ich nehme an, gleichzeitig könnten verschiedene DevOps-Ingenieure ganz unterschiedliche Lösungen wählen. Unser bevorzugter Ansatz ist die Erstellung einer Microservice-orientierten Architektur in PaaS, da sie Flexibilität mit Einfachheit kombiniert.

Natürlich sollten wir uns das Leben erleichtern, indem wir einige externe SaaS wie SparkPost- oder Slack-Integrationen und einige externe DaaS verwenden, um Daten wie die aktuellen Wechselkurse einfach abzurufen. Darüber hinaus können wir einen Teil unseres Systems (5% bis 20%, je nach Bedarf) auf FaaS stützen — einfache zustandslose Funktionen, die mehrere Dienste verbinden, sodass die Verwendung von FaaS einfach Zeit bei der Bereitstellung und Überwachung spart.

Wir hoffen, dass dieser Artikel Ihnen hilft, das richtige XaaS (oder viele davon gleichzeitig) in Ihrem Projekt auszuwählen.