Zeit für mich zu fliegen ... zu rendern

Der unten dargestellte Hype-Zyklus von Gartner kann auf die meisten Aspekte der Technologie angewendet werden:

Wenn neue Innovationen in ihre jeweiligen Zyklen eintreten, werden die Erwartungen schließlich erfüllt, was zu einem gewissen Grad an Akzeptanz führt.

Das Ziel jeder Innovation besteht darin, das Plateau der Produktivität zu erreichen, bei dem die Verbraucher festgestellt haben, dass der Nutzen der Einführung der Innovation alle bekannten Risiken bei weitem überwiegt.

Gleichzeitig gibt es einen Punkt, an dem das Produktivitätsplateau zu sinken beginnt, was zu einer Abkehr von dieser Innovation führt. Ein einfaches Beispiel wären Pager (oder Piepser), die üblich waren, bevor Mobiltelefone/Geräte das Plateau der Produktivität erreichten.

Als Technologen sind wir bestrebt, Funktionen, Frameworks, Produkte oder Dienstleistungen bereitzustellen, die die Produktivität steigern. Das Gleiche gilt für diejenigen, die wir verwenden.

Vor Kurzem hatte ich das Gefühl, dass die Produktivität meiner aktuellen Hosting-Plattform abstürzte. Tatsächlich hat mich eine aktuelle Ankündigung dazu veranlasst, mich zu fragen, ob es nicht an der Zeit sei, andere Optionen in Betracht zu ziehen.

Da ich mit Render PaaS gute Erfahrungen gemacht habe, wollte ich sehen, wie einfach ich eine meiner Heroku-Anwendungen konvertieren, PostgreSQL übernehmen und auf Render migrieren kann. Ich beschreibe diese Reise in dieser zweiteiligen Serie:

• Teil 1: Wir konzentrieren uns auf die Migration meiner Backend-Dienste (Spring Boot und ClearDB MySQL).
• Teil 2: Wir konzentrieren uns auf die Portierung und Migration meines Frontend-Angular-Clients.

Warum ich Render gewählt habe

Wenn Sie noch nie von Render gehört haben, schauen Sie sich einige meiner früheren Veröffentlichungen an:

• Verbringen Sie mit Render PaaS keine Zeit mit DevOps

• Die perfekte Cloud: AWS, GCP und Azure in einem

• Zweckorientiertes Microservice-Design

• Bringen Sie Ihre Startup-Idee an einem Tag auf den Markt

• Wie ich Render verwendet habe, um meine Microservices-App einfach zu skalieren

Was ich an Render spannend finde, ist, dass sie den Weg der Aufklärung weiter erklimmen und gleichzeitig aktiv eine solide Lösung für Anwender bereitstellen, die das Produktivitätsplateau erkennen.

Wie ich in meinen Artikeln festgestellt habe, bietet Render ein „Zero DevOps“-Versprechen. Das entspricht perfekt meinen Bedürfnissen, da ich nicht die Zeit habe, mich auf DevOps-Aufgaben zu konzentrieren.

Die Heroku-Plattform hat mehrere Dinge, die mir nicht besonders gefallen:

• Tägliche Neustarts führten zu unerwarteten Ausfallzeiten bei einem meiner Dienste.

• Einsteigermodell (alles, was ich wirklich brauche) Postgres auf Heroku ermöglicht vier Stunden Ausfallzeit pro Monat.

• Aus Verbrauchersicht lässt sich das Preisniveau nicht gut skalieren.

Aus preislicher Sicht erwarte ich erhebliche Kosteneinsparungen, nachdem ich alle meine Anwendungen und Dienste von Heroku auf Render migriert habe. Was noch erstaunlicher ist, ist, dass ich für diesen Preis besseren Speicher und bessere CPU bekomme, mit linearer Skalierung, wenn mein Anwendungs-Footprint wachsen muss.

Konvertieren eines einzelnen Dienstes

Wie ich oben erwähnt habe, ist dies Teil eins einer zweiteiligen Serie, und ich werde mich in diesem Artikel auf die Serviceebene konzentrieren. Der Dienst, den ich konvertieren möchte, weist die folgenden Attribute auf:

• Spring Boot RESTful API-Dienst

• Heroku CloudAMQP (RabbitMQ) Nachrichtenbroker

• Heroku ClearDB (MySQL)-Datenbank (einzelnes Schema)

• Okta-Integration

Auf der Render-PaaS-Seite wird das neue Servicedesign wie folgt aussehen:

• Render-Webdienst, der den Spring Boot RESTful API-Dienst hostet (über Docker)

• Render Private Service, der RabbitMQ Message Broker hostet (über Docker)

• Rendern Sie Postgres mit der Möglichkeit, dass mehrere Schemata vorhanden sein können

• Okta-Integration

Nachfolgend finden Sie einen direkten Vergleich der beiden Ökosysteme:

Mein allgemeiner Angriffsplan für die Konvertierung lautet wie folgt:

Bereiten Sie Heroku auf die Konvertierung vor

Bevor Sie beginnen, empfiehlt es sich, alle vorhandenen Heroku-Dienste in den Wartungsmodus zu versetzen. Dadurch wird Verbrauchern der Zugriff auf die Anwendungen oder Dienste untersagt.

Während der Quellcode bereits gesichert und in einem Git-basierten Repository gespeichert sein sollte, ist es eine gute Idee, sicherzustellen, dass eine Datenbanksicherung erfolgreich erstellt wurde.

Konvertierung von Heroku-Diensten

Aus Sicht der Konvertierung musste ich zwei Elemente konvertieren: den Dienst selbst und die ClearDB-Datenbank (MySQL).

Die Konvertierung meines Spring Boot RESTful-Dienstes war nicht mit viel Aufwand verbunden. Tatsächlich konnte ich den Ansatz nutzen, den ich bei einem früheren Projekt von mir verwendet hatte.

Für die Datenbank musste ich von MySQL nach PostgreSQL konvertieren. Mein Ziel war es , den Heroku Migrator von Render zu verwenden, um Heroku Postgres einfach zu Render Postgres zu migrieren, aber ich musste zuerst von MySQL nach PostgreSQL konvertieren.

Zunächst begann ich mit dem pgloader- Pfad, der mir als gängiger Ansatz für die Datenbankkonvertierung erschien. Allerdings führte die Verwendung meines MacBook Pro mit M1-Chip zu einigen unerwarteten Problemen.

Stattdessen habe ich mich für die Verwendung von NMIG entschieden, um MySQL in PostgreSQL zu konvertieren. Weitere Informationen finden Sie im Abschnitt „ Highlights aus der Datenbankkonvertierung “ weiter unten.

Erstellen Sie Dienste in Render

Nach der Konvertierung der Datenbank und des in Docker ausgeführten Spring Boot RESTful-Dienstes bestand der nächste Schritt darin, einen Render-Webdienst für den Spring Boot RESTful API-Dienst zu erstellen.

Dies war so einfach wie das Erstellen des Dienstes, das Vergeben eines Namens und das Verweisen auf das entsprechende Repository für meinen Code in GitLab.

Da ich auch einen RabbitMQ-Dienst benötigte, habe ich diese Anweisungen befolgt, um einen privaten RabbitMQ-Dienst zu erstellen, der auf Render ausgeführt wird. Dazu gehörte die Einrichtung einer kleinen Menge Festplattenspeicher, um nicht verarbeitete Nachrichten dauerhaft aufzubewahren.

Schließlich habe ich im Render-Dashboard die erforderlichen Umgebungsvariablen sowohl für den Spring Boot RESTful API-Dienst als auch für den RabbitMQ-Nachrichtenbroker erstellt.

Initialisieren und validieren Sie die Dienste

Der nächste Schritt bestand darin, meine Dienste zu starten. Nachdem sie ausgeführt wurden und die APIs mithilfe meiner Postman-Sammlung validiert wurden, habe ich meine Clientanwendung so aktualisiert, dass sie auf den neuen Render-Dienstspeicherort verweist.

Sobald alles betriebsbereit war, sah mein Render-Dashboard wie folgt aus:

Nächste Schritte

Zu diesem Zeitpunkt mussten nur noch die noch auf Heroku laufenden Datenbanken gelöscht und die migrierten Dienste aus dem Heroku-Ökosystem entfernt werden.

Bei Verwendung von Heroku wurde der Code jedes Mal, wenn ich Code in den Master-Zweig meines Service-Repositorys zusammenführte, automatisch bereitgestellt, sofern ich GitLab CI/CD für die Bereitstellung in Heroku in meinem Quell-Repository verwendet habe.

Es ist jedoch nicht erforderlich, mit Render Code zum Quelldatei-Repository hinzuzufügen. Ich musste lediglich den Build & Deploy Branch im Render-Dashboard für den Dienst angeben:

Ich liebe das Zero DevOps-Versprechen.

Highlights aus der Datenbankkonvertierung

Durch Befolgen der oben genannten Schritte verlief die Konvertierung von Heroku zu Render reibungslos und erfolgreich. Die größte Herausforderung für mich war die Konvertierung der Daten. Im Großen und Ganzen lief es hauptsächlich auf eine Reihe von Befehlen hinaus, die über das Terminal meines MacBook Pro ausgeführt wurden.

Zuerst habe ich über Docker eine lokale Postgres-Instanz gestartet:

 docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres

Als nächstes habe ich mit dem folgenden Befehl (oder pgAdmin) eine Datenbank namens „example“ erstellt:

 createdb example

Zum Konvertieren meiner auf Heroku ausgeführten ClearDB-Instanz (MYSQL) in meine lokal ausgeführte Postgres-Beispieldatenbank habe ich NMIG verwendet, ein Node.js-basiertes Datenbankkonvertierungsdienstprogramm.

Nach der Installation von NMIG habe ich die Datei config.json mit Datenbank-Endpunktinformationen und Anmeldeinformationen eingerichtet und dann Folgendes ausgeführt:

 /path/to/nmig$ npm start

Als nächstes habe ich die Daten mit dem folgenden Befehl in einer Datei gesichert:

 pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump

Anstatt mir die Mühe zu machen, eine signierte URL in AWS zu erstellen, habe ich einfach den pgAdmin- Client verwendet, um das Backup in eine neu erstellte Postgres-Instanz auf Heroku zu importieren.

Während die Postgres-Instanz ausgeführt und die Daten validiert wurden, habe ich eine neue Postgres-Datenbank auf dem Render PaaS erstellt . Dann musste ich nur noch den folgenden Befehl ausgeben:

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/example example.dump

Unterwegs gelernte Lektionen

Wenn ich auf meine Umstellung von Heroku auf Render zurückblicke, sind hier einige Lektionen, die ich dabei gelernt habe:

• Ich hatte ein kleines Problem damit, dass die Postgres-Datenbank den Datums-/Uhrzeitwert aktualisierte, um den DST-Offset einzuschließen. Dies war möglicherweise ein Problem mit meinem ursprünglichen Datenbankdesign, aber ich wollte es weitergeben. In meinem Fall wird die betroffene Spalte nur für Datumswerte verwendet, was sich für mich nicht geändert hat.

• Ich habe eine Datenbankspalte mit dem Namen END in eine meiner Tabellen eingefügt, was zu einem Problem führte, wenn entweder Postgres oder Hibernate versuchten, eine native Abfrage zurückzugeben. Der Dienst hat den END-Spaltennamen erkannt und ihn als SQL-Schlüsselwort eingefügt. Ich habe die Spalte einfach umbenannt, um dieses Problem zu beheben, was ich eigentlich nicht tun sollte.

• Mit Render musste ich den RabbitMQ-Dienst zu einem privaten Dienst machen, da die Option „Webdienst“ den erwarteten Port nicht verfügbar macht. Bei diesem Ansatz habe ich jedoch die Möglichkeit verloren, auf die RabbitMQ-Administratoroberfläche zuzugreifen, da Private Services nicht extern verfügbar gemacht werden. Es sieht so aus, als ob Render plant, auf diese Funktionsanfrage einzugehen.

Alles in allem waren diese kleinen Hürden nicht groß genug, um meine Entscheidung für die Migration auf Render zu beeinflussen.

Abschluss

Der wichtigste Aspekt des Produktivitätsplateaus von Gartner ist die Bereitstellung von Produkten, Frameworks oder Dienstleistungen, die es den Verbrauchern ermöglichen, erfolgreich zu sein und ihre Ziele zu erreichen. Das Produktivitätsplateau soll weder auffällig noch modisch sein – im metaphorischen Sinne.

Als ich Ed, einem Developer Advocate bei Render, diese Schlussfolgerung mitteilte, war seine Antwort etwas, das ich mitteilen wollte:

„Render versucht ganz offenkundig nicht, ‚modisch‘ zu sein. Wir versuchen, nicht überraschend und zuverlässig zu sein.“

Eds Antwort berührte mich tief und erinnerte mich an eine Zeit, als mein ehemaliger Kollege mir erzählte, mein Code sei „langweilig“ für ihn. Sein Kommentar erwies sich als das größte Kompliment, das ich bekommen konnte. Mehr können Sie hier lesen.

In jedem Aspekt der Technologie sollte die Entscheidung, welchen Anbieter Sie auswählen, immer mit Ihrer Technologieposition übereinstimmen. Wenn Sie sich nicht sicher sind, ist der Gartner-Hype-Zyklus ein guter Anhaltspunkt, und Sie können hier mit einem Abonnement für ihren Dienst beginnen.

Ich habe mich auf das folgende Leitbild konzentriert, das meiner Meinung nach auf jeden IT-Experten anwendbar ist:

„Konzentrieren Sie Ihre Zeit auf die Bereitstellung von Features/Funktionalitäten, die den Wert Ihres geistigen Eigentums steigern. Nutzen Sie Frameworks, Produkte und Services für alles andere.“

- J. Vester

Wenn ich mir das Render-PaaS-Ökosystem ansehe, sehe ich eine Lösung, die meinem Leitbild entspricht und gleichzeitig innerhalb meiner Hype-Cycle-Präferenz liegt.

Was die Sache noch besser macht, ist, dass ich voll und ganz davon ausgehe, dass ich bei meinen persönlichen Auslagen eine Einsparung von 44 % erzielen werde – sogar noch mehr, da meine Dienstleistungen vertikal skaliert werden müssen.

Wer über Hosting-Lösungen nachdenkt, dem empfehle ich, Render zur Überprüfung und Analyse zur Liste der Anbieter hinzuzufügen. Sie können kostenlos loslegen, indem Sie diesem Link folgen.

Der zweite Teil dieser Serie wird spannend. Ich werde zeigen, wie ich von der Bezahlung meines in Angular geschriebenen statischen Clients wegkomme und den kostenlosen Static Sites-Dienst von Render mit Vue oder Svelte nutzen kann. Welches Framework werde ich wählen … und warum?

Ich wünsche Ihnen einen wirklich tollen Tag!