Der Schlüssel zu den Clouds: Wie können Sie Ihre Anwendung Cloud-Native machen?

    In einem früheren Beitrag haben wir beschrieben, wie Cloud-Services zum inoffiziellen Standard für die Bereitstellung von IT-Services geworden sind. Es ist nicht schwer zu erraten, dass Unternehmen, die immer noch mit Benutzeranwendungen Geld verdienen möchten, sich anpassen und neue Produkte basierend auf dem Cloud-Native-Ansatz erstellen müssen. Für die Entwickler sind dies jedoch durchaus positive Nachrichten, denn der Einsatz von Cloud-Technologien eröffnet ihnen enorme neue Möglichkeiten. Die Hauptsache ist, sie ordnungsgemäß entsorgen zu können.


    Wenn die Anwendung die Umgebung bestellt


    Wenn Sie den Leitfaden zu Cloud-Technologien bereits gelesen haben, können Sie sich sicherlich daran erinnern, dass die Virtualisierungstechnologie eine der "magischen Quellen" der Cloud ist. Daher muss der Entwickler praktisch nicht über die Parameter der Server nachdenken, auf denen seine Anwendung ausgeführt wird. Warum Zeit verschwenden, wenn ein ordnungsgemäß konfigurierter Hypervisor oder Container eine Maschine mit fast allen Merkmalen konfigurieren kann, die eine Anwendung benötigt?

    Die Entwicklung dieser Idee ist der Ansatz Infrastructure as Code (IAC). Im Wesentlichen geht es darum, Entwicklern oder operativen Diensten zu ermöglichen, dieselben Ansätze zu verwenden, mit denen die Infrastruktur während der Entwicklungsphase gewartet wird. Damit können Sie gängige Software-Steuereinheiten im Voraus vorbereiten und solche Komponenten einfach in neue Projekte integrieren.

    Die Fähigkeiten moderner Rechenzentren ermöglichen es uns bereits, auf die deklarative Sprache des Infrastrukturmanagements umzusteigen. Idealerweise sollte die Anwendung selbst den Ressourcenpool verwalten, den sie im Rechenzentrum belegt. Auf diese Weise kann der Entwickler nicht an die Einschränkungen gebunden werden, die mit der Arbeit mit der Infrastruktur verbunden sind, wenn eine vorherige Bestellung und Planung erforderlich ist oder wenn dieselben Infrastrukturkomponenten in verschiedenen Projekten wiederholt werden.


    In der Tat stellt der Entwickler oder Techniker eine Pull-Anfrage, in der sich die Konfiguration der virtuellen Maschine befindet (Kernel, Speicher, Netzwerk, Muster usw.). Dann erstellt der Manager für virtuelle Umgebungen die Maschine selbst oder erstellt eine neue Datenbankinstanz oder startet einen vorinstallierten Dienst entsprechend den Einstellungen in Datei. Dieser Ansatz ist eine echte Erlösung, wenn Sie mit Big Data und neuronalen Netzwerken arbeiten. Anwendungen, die mit diesen Technologien verbunden sind, erfordern in einigen Fällen dynamisch änderbare Speicher- und Verarbeitungsleistungen.

    Um ein Netzwerk zu trainieren, müssen Sie beispielsweise Hunderte von Gigabyte an Informationen durch das Netzwerk „fahren“, und die Clouds stellen bei Bedarf die nötige Energie zur Verfügung. Nach Abschluss der Schulung werden die Ressourcen an den Provider-Pool zurückgegeben, und der Entwickler muss nicht darüber nachdenken, was er tun soll oder wie die Anwendung auf eine andere Art und Weise konfiguriert werden muss, damit sie mit weniger Energie arbeitet.

    Monolith vs. ordentliches Chaos


    Da sich die Clouds elastisch an die Anforderungen des Entwicklers anpassen können, vereinfacht dies theoretisch eine weitere Aufgabe - das Problem der Skalierung von Anwendungen. Warum theoretisch?

    Leider ist die Aufgabe des Skalierens von Anwendungen nicht linear. Damit eine Anwendung bei Belastungsspitzen (oder Computing) mit hohen Belastungen zurechtkommt, reicht es nicht aus, ihr nur zusätzlichen Speicher und Prozessorleistung zu geben. Absolut jede traditionelle Anwendung hat eine Schwelle, nach der sie keine neuen Ressourcen mehr „verdauen“ kann und eine Steigerung der Produktivität zeigt. In diesem Fall liegt das Problem nicht in den Ressourcen, sondern in der Architektur der meisten Programme.

    Dieses Problem ist besonders akut für Anwendungen mit einer monolithischen Architektur, bei denen es sich tatsächlich um einzelne Binärdateien handelt. Die Vorteile dieses Ansatzes liegen auf der Hand: Monolithische Anwendungen sind relativ einfach und linear. Alle Szenarien des Benutzerverhaltens können vorhergesagt, verfolgt und gegebenenfalls debuggt werden.

    Eine solche Einfachheit hat jedoch einen Preis. Erstens sind dies die oben bereits erwähnten Skalierungsprobleme. Irgendwann wird selbst die durchdachteste monolithische Anwendung durch das Upgrade der Serverkonfiguration, auf der sie ausgeführt wird, nicht mehr effizienter.


    Zweitens ist eine monolithische Anwendung nicht so einfach auf neue Server zu übertragen, und dies erfordert möglicherweise eine vollständige Neukompilierung des Programms.
    Drittens ist eine solche Anwendung schwierig zu warten und zu entwickeln. Jede Aktualisierung wird so umgewandelt, dass das gesamte Programm vollständig zusammengebaut werden muss, und ein Fehler in einem der Codeblöcke kann zum Absturz des gesamten Systems führen.

    Auf der Suche nach Ideen zur Lösung dieser Probleme wurde ein anderes Konzept entwickelt - die serviceorientierte Architektur (SOA). Dies impliziert, dass die Anwendung in mehrere Module unterteilt ist, von denen jedes einige andere Funktionen bietet. Die Module interagieren untereinander über eine Reihe von Web-Services und können unabhängig voneinander auf eine einzelne Datenbank oder auf ihre eigene Datenbank zugreifen.

    Ein solcher Ansatz vereinfacht die Unterstützung des Programms wirklich und macht sein Update nicht „zur Arbeit eines Sappers“, bei dem kein Fehlerraum besteht. aber es hat seine Nachteile. Der Schlüssel sind die Probleme bei der Skalierung der Entwicklung solcher Anwendungen. Mit dem Wachstum des Programms wird es immer schwieriger, neue Funktionen in die vom Architekten genehmigten 5-10-Pakete zu "stopfen". Ihre Anzahl nimmt zu, was zu Supportproblemen führt.

    Microservice als Element der Anwendungsentwicklung


    Das Ergebnis der SOA-Entwicklung war die Idee einer Microservice-Architektur, die beim Aufbau von Cloud-Anwendungen verwendet wird. Konzeptionell sind die Ideen beider Ansätze sehr ähnlich, und einige Architekten heben die Microservice-Architektur nicht einmal in einem separaten Paradigma hervor, da sie dies als einen besonderen Fall von SOA betrachtet.

    Die Microservice-Architektur impliziert, dass eine Anwendung nicht aus einer großen Anzahl großer Module besteht, sondern aus vielen unabhängigen Teilen. Im Gegensatz zu einem Monolithen können Sie in einer Microservice-Anwendung verschiedene Arten der Interaktion zwischen den Komponenten verwenden. Das System hat keinen einzigen vorbestimmten Zustand. Stattdessen arbeitet jede Komponente "situationsabhängig": Sobald ein Ereignis eintrifft, beginnt es zu arbeiten. Dies ermöglicht eine sehr flexible und unabhängige Architektur.
    Gleichzeitig ändert sich die Anzahl der Dienste in der Microservice-Anwendung ständig - einige werden hinzugefügt, andere werden gelöscht. Bei dem neuen Ansatz ist es möglich, jeden Microservice zu ersetzen und stattdessen die Microservice-Kette zu ersetzen. Andere Dienste funktionieren weiterhin stabil, da sie nicht direkt miteinander verbunden sind. Dies ist die natürliche Entwicklung des Programms. Entwickler und Architekten haben daher die Möglichkeit, schnell etwas zu ändern, um auf geänderte Geschäftsanforderungen zu reagieren und Konkurrenten zu übertreffen.

    Neben der Beschleunigung der Veröffentlichung von Updates ermöglicht die Verwendung einer Microservice-Architektur auch die Dezentralisierung der Steuerung. Das Team, das für die Entwicklung eines Dienstes verantwortlich ist, hat das Recht, seine interne Architektur und seine Funktionen zu bestimmen. Ein solcher Ansatz setzt derzeit den Sberbank Architectural Council im Block of Technologies um.

    Gleichzeitig sollte das Sitzen bei der Entwicklung Ihrer Cloud-Anwendung nicht mit dem schnellen Aufteilen in seine Bestandteile einhergehen. Der Hauptgegner dieses gedankenlosen Ansatzes ist Martin Fowler; Er ist auch einer der Autoren der Idee der Microservice-Architektur. Es ist einfacher, zunächst den monolithischen Ansatz zu verwenden und dann die Entwicklung der Anwendung „natürlich“ anzuregen, indem Engpässe eingeengt und zusätzliche Funktionen hinzugefügt werden.

    Daher können wir die folgende Regel formulieren: Die Aufgabe des Programmierers bei der Arbeit mit der Microservice-Architektur besteht nicht nur darin, die Anwendung in die maximale Anzahl von Komponenten aufzuteilen, sondern ihre Verantwortung für den Empfang und die Verarbeitung von Daten einigermaßen zu definieren.

    Vier Details


    Neben vielen offensichtlichen Vorteilen verfügt die Microservice-Architektur über eigene Funktionen, die bei der Entwicklung Ihrer Cloud-Anwendung berücksichtigt werden müssen. Um den Betrieb einer solchen Anwendung zu unterstützen, müssen insbesondere die erhöhten Anforderungen an die Qualität der Verwaltung interner APIs aufrechterhalten werden.

    Wenn eine der Komponenten ihre Schnittstelle ändert, muss sie die Abwärtskompatibilität aufrechterhalten, um die vorherige Version ihrer eigenen API beizubehalten. Wenn diese Regel eingehalten wird, können Sie ohne Fehler dynamisch von der alten Version zur neuen wechseln. Wenn die Unterstützung für die Vorgängerversion der API nicht entwickelt wird, droht sie bestenfalls mit dem Verlust einiger Funktionalität der Anwendung und im schlimmsten Fall mit dauerhaften Ausfällen.

    Das zweite wichtige Merkmal von Microservice-Anwendungen ist die Schwierigkeit, darin Fehler zu finden. Wenn eine Anwendung, die in monolithischer Logik oder SOA geschrieben wurde, „fällt“, ist es leicht, die Ursache des Problems zu finden. In einer Anwendung, die aus vielen Diensten besteht, kann die Suche nach der Ursache eines Fehlers sehr verzögert sein, da Daten des Benutzers häufig durch mehrere Mikrodienste verarbeitet werden, und es ist schwierig zu bestimmen, welcher von ihnen ausfällt. Gleichzeitig muss die Suche nach einem Fehler sehr sorgfältig durchgeführt werden: Jedes erfolglose Refactoring kann zum Absturz des Arbeitsmoduls führen, und zusätzlich zum anfänglichen Problem erhält der Entwickler das zweite.


    Das dritte wichtige Detail, das bei der Entwicklung einer Cloud-Anwendung berücksichtigt werden muss, ist die Art und Weise, wie ihre Komponenten miteinander interagieren. Wie in SOA verwenden Dienste Webdienste für den Datenaustausch. In der Microservice-Architektur sind jedoch Interaktionsmuster aufgetreten, z. B. Streaming, CQRS, Event-Sourcing. Normalerweise erwarten Entwickler, dass die Antwortzeit zwischen der Anforderung und der Antwort in der Anwendung eher kurz ist. In einem verteilten System können Sie sich nicht einmal auf die Antwort verlassen.

    In der Cloud-Anwendungsarchitektur verwenden Microservices verschiedene Datenbanken, die sich am besten für die Lösung ihrer spezifischen Aufgaben eignen. Zum Beispiel können Raster schnell lesen, aber mit einer großen Anzahl von Datenänderungsvorgängen kaum umgehen. Eine solche Datenbank ist gut geeignet, um Einlagenkonten zu führen - sie ändern sich selten. Eine andere Art von Vorgang ist die Verarbeitung. Jeden Tag kann es Dutzende von Änderungen auf jeder Karte geben, und umgekehrt gibt es wenige Datenlesungen.

    Die vierte Tatsache, die bei der Entwicklung einer Cloud-Anwendung zu berücksichtigen ist, ist die Mikroservice-Architektur, die sich hauptsächlich auf die Verwendung zustandsloser Dienste konzentriert. Sie sollten nicht ins Extreme gehen. Einige Dienste können bei Bedarf den Status aufrechterhalten, wenn die Geschäftslogik dies erfordert, und sie sollten besonders sorgfältig entworfen werden.

    Beispiel: Wenn ein Benutzer einen Kredit anfordert, muss das System, das die Anwendung erhalten hat, diesen Status speichern, um ihn an andere Dienste zu übertragen. Der Dienst, der für die Suche nach Informationen in der internen Kreditverlaufsdatei verantwortlich ist, speichert den Status jedoch möglicherweise nicht und vergisst nicht, welchen benannten Benutzer er vor ein paar Minuten gesucht hat - jedenfalls kommt eine neue Anfrage (obwohl in diesem Prozess) unterschiedliches Dienstverhalten sein).

    Alle oben genannten Beispiele und Praktiken werden bereits von führenden Unternehmen der globalen IT-Branche aktiv eingesetzt. Beispielsweise ist Netflix ein Pionier bei der Entwicklung von Microservice-Architekturen. Das Unternehmen hat zahlreiche Open-Source-Anwendungen, -Bibliotheken und -Frameworks zum Überwachen, Ausgleichen und Protokollieren von Mikroservice-Anwendungen veröffentlicht.

    Jetzt auch beliebt: