Beschleunigung der Cloud: Die Investition, Cloud native zu machen

Dieser Artikel ist der zweite Teil der "Accelerating Cloud Computing" -Serie von Ampere Computing. Sie können den ersten Teil [hier] lesen (ersetzen Sie hier durch Teil 1 Link).

Es ist viel einfacher, Ihre App auf Ampere Cloud Native Computing -Plattform zu migrieren, als Sie denken. Dies liegt daran, dass der größte Teil der Arbeiten zur Umsetzung von Anwendungen auf einen ARM-basierten Server bereits für Sie durchgeführt oder einfach nur umkompilieren.

Kurz gesagt, da der Cloud-native Prozessor von Ampere die ARM-Anweisungs-Architektur (ISA) verwendet, kann Software, die auf ARM ausgeführt wird, auch auf Ampere ausgeführt. In den letzten fünf Jahren ist die Unterstützung der Open -Source -Community für ARM exponentiell gewachsen, wobei eine Vielzahl neuer Software und Dienste entsteht. Beispielsweise bieten Anwendungen wie Redis, Nginx, Memcached, MySQL und Cassandra bereits bewährte ARM-basierte Versionen an.

Was bedeutet das für Entwickler? Die meisten von Unternehmen verwendeten Software sind bereits in der Cloud ausgeführt oder sind wahrscheinlich für Cloud -native Umgebungen bereit.

Betriebssystem (OS): Fast alle verfügbaren Betriebssysteme wurden auf ARM ISA portiert und auf ARM-basierten Kernen ausgeführt. Infolgedessen unterstützt der native Cloud -Prozessor von Ampere veröffentlichte Versionen der in der Cloud verwendeten Hauptbetriebssysteme.

, um die Zuverlässigkeit und Leistung weiter zu gewährleisten, Ampere -Tests und validiert das öffentliche Image und die vorverpackten Anwendungen des Betriebssystems auf seinem Ampere Cloud Native -Prozessor. Auf diese Weise können Entwickler sicher sein, dass ihre Anwendungen nahtlos auf Ampere ausgeführt werden können.

Vorverpackter Code: Normalerweise wird ein großer Teil einer Anwendung unter Verwendung von vorverpackten Anwendungskomponenten erstellt. ARM-basierte öffentliche Bilder der meisten dieser Anwendungen (von MySQL, Postgresql, Cassandra, Nginx und Tintenfisch zu einer Vielzahl von Anwendungen) wurden auf ampere Cloud-native Prozessoren getestet und verifiziert. Daher ist dieser Teil der Vorbereitung einer Anwendung für eine Cloud-native Computerplattform relativ einfach: Verwenden Sie einfach den bereits bereitgestellten ARM-basierten Spiegel. Es sind keine komplizierte Portierung oder Software -Umschreiben erforderlich.

kompilierte Sprache: Im Allgemeinen sind die meisten wichtigen Probleme, die bei der Wiedereinstellung eines Webservers aus Code erfolgen, der zum Ausführen von Ampere kompiliert werden muss. Für Code, der in Sprachen wie GO, C und C geschrieben wurde, erfordert der Umschreckenprozess einen zusätzlichen Schritt, da die vorhandenen Binärdateien für die X86 -Umgebung erstellt werden. Da die überwiegende Mehrheit der Programmiersprachen auf ARM und X86 verfügbar ist, müssen die meisten Probleme mit der Umsetzung das Build -Skript auf dem Ampere -Build -Knoten lediglich ausführen, um die richtige Binärdatum zu erzeugen.

Interne/Anpassung: Benutzerdefinierte Anwendungen können in vier Typen unterteilt werden: interpretiert, erweitert, binär und hardwarespezifisch.

• Erläuterungscode: Unkompilierter Code, der in interpretierten Sprachen wie Java oder Python geschrieben wurde, ist auf Cloud-nativen Plattformen sehr einfach zu wiederholen. Da der Code interpretiert und ausgeführt wird, kann er auf einer Cloud-nativen Computerplattform ausgeführt werden, ohne den Code zu ändern. Stattdessen wird der Code auf einem Interpreter ausgeführt, der für ARM anstelle von x86 zusammengestellt wurde. In der Regel ist es ein einfacher Prozess, einen Dolmetscher für einen Cloud-nativen Prozessor neu einzuführen, der in wenigen Minuten durchgeführt werden kann, wenn das Bild nicht vorhanden ist.
• Erweiterter Code: Es ist auch relativ einfach, Code in Sprachen auf hoher Ebene wie C/C für Cloud-native Plattformen zu erstellen. In den meisten Fällen muss die Anwendung nur für ARM ISA neu kompiliert werden. In der Regel wird dies verwaltet, indem der Compiler einfach mit ARM anstelle von x86 konfiguriert wird. Wenn während des Zusammenstellungsprozesses Warnungen oder Fehler auftreten, können diese Probleme normalerweise leicht gelöst werden oder bestätigen, dass es sich nicht um Probleme handelt.
• Binärdateien: Das häufigste Reployment -Problem für viele Anwendungen ist die Verwendung von Binärdateien. Eine Binärdatei ist Code (normalerweise eine Bibliothek), die in der Anwendung enthalten ist. Dies kann Produkte umfassen, die nur in binärer Form erhältlich sind und Abhängigkeiten für Ihre Anwendung sind. Überprüfen Sie vor dem Erstellen Ihrer Bewerbung einfach die Abhängigkeiten, die Ihr Code hat, und stellen Sie sicher, dass der verwendete binäre ARM-basiert anstelle von X86 basiert.
• hardwarespezifischer Code: Code für einen bestimmten Prozessor oder Code, der eine bestimmte Prozessorfunktion für Leistungszwecke verwendet (z. B. eine Grafikbibliothek), kann eine begrenzte Portierung erfordern. Dies geschieht nur, wenn keine spezielle ARM -Version verfügbar ist. Unabhängig davon ist der Transplantationsprozess normalerweise einfach und kann höchstens in wenigen Stunden abgeschlossen werden.

Real World Redeployment

Lassen Sie uns sehen, was es braucht, um die Anwendung auf ampere Cloud native Prozessor neu zu streichen. Betrachten Sie Momento, das sich der Bereitstellung von Diensten widmet, die Caches im Maßstab verwalten, damit Entwickler sie selbst nicht verwalten müssen. Momento Serverless Cache basiert auf Pelikan, einer Open -Source -Caching -Engine, die ursprünglich für die spezifischen Cache -Anforderungen von Twitter entwickelt wurde. Pelikan wurde in letzter Zeit vollständig in Rust umgeschrieben. Momento will Pelikan auf der auf Google veranstalteten Ampere-basierten Tau T2A-Virtual Machine neu einsetzen.

Rote Bereitstellung ist schnell und nahtlos, ohne einen Code zu ändern, um Pelikan und momento serverloser Cache zu lenken. Darüber hinaus konnte das Momento -Team einige einfache Optimierungen implementieren (keine Code -Optimierung erforderlich), die den Durchsatz schnell verdreifachten. Wir geben Ihnen einen detaillierten Blick auf die Leistungsvorteile, die Sie in Teil 4 dieser Serie erwarten können.

Ein weiteres Beispiel für die Umschichtung ist die Plesk. Mit Plesks Software können Menschen ihre Webinfrastruktur über ein zentrales Bedienfeld verwalten. Lukas Hertig, Senior Vice President von Plesks Business Development and Strategic Alliance, beschrieb seine eigenen Erfahrungen im Umsatzprozess. "Ich hatte zunächst eine verrückte Idee, eine ARM -Version zu haben. Ein paar Wochen später kam mein Ingenieurteam zurück und sagte mir: 'Oh, es funktioniert jetzt.'

Plesk dient dem SMB -Feld, und es ist nicht offensichtlich, Cloud Native zu wählen. Aber Hertig sagte kurz nach der Umsetzung: „Wir haben in der Produktion von 1.000 Arms überschritten. Natürlich hängt die Komplexität der Umschleppung Ihrer Anwendung auf eine Cloud-native Computing-Plattform davon ab, wo Sie den Code erhalten. Im Allgemeinen ist jedoch die Investition in die Umsetzung der meisten Anwendungen für Cloud-native Prozessoren minimal, da 80-90% der Anwendungen nur neu kompiliert werden müssen.

Im dritten Teil dieser Serie werden wir den Cloud-nativen Umbauprozess weiter untersuchen.

Das obige ist der detaillierte Inhalt vonBeschleunigung der Cloud: Die Investition, Cloud native zu machen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!