• Zuhause
  • Artikel
  • Liebes Bereitstellungstagebuch: Serverless ist verdammt schwer
Veröffentlicht am 21-02-2019

Liebes Bereitstellungstagebuch, Serverless ist verdammt hart

Ich bin Softwareentwickler. Ich arbeite in einem großen Software-Unternehmen mit hunderten von Mitarbeitern in unterschiedlichen Zeitzonen. Es ist ein großes Chaos. Trotzdem geht es dem Unternehmen gut und bewegt sich in einem schnellen Tempo.

Wie viele andere Tech-Unternehmen war alles mit einem kleinen Server ausgestattet, der im Laufe der Jahre immer größer wurde. Softwareprodukte entwickeln sich naturgemäß wie Bäume. Sie säen sie, indem Sie Ihren Server pflanzen und ihn der Außenwelt aussetzen - dieses kleine Wankeln muss in den richtigen Bedingungen gehalten werden, um ihn am Leben zu erhalten. Die CPU% sollte niedrig bleiben und der eingehende Datenverkehr sollte nicht blockiert werden, und natürlich sollte jemand alle Fehler besprechen. Mit den Sprints werden der kleinen Pflanze immer mehr Funktionen hinzugefügt, die zu einem echten Baum wird: viele Äste, verschiedene kleine Früchte und neue Benutzeroberflächen. Damit es am Leben bleibt, ist viel mehr Arbeit erforderlich. Jede Frucht hat ihre eigene Art von Käfern und es müssen weitaus mehr Bereiche in der Pflanze überwacht werden. Zu diesem Zeitpunkt gibt es viele Menschen, die am Leben dieses Baumes beteiligt sind. Irgendwann kann der Baum es nicht schaffen. Es ist einfach zu groß, monolithisch und alt. Höchstwahrscheinlich kann der Baum den Anforderungen an seine Früchte nicht gerecht werden.

ES BRAUCHT BEREICH Zu einem Obstgarten. Aber wie Bäume sind, können Sie sie nicht einfach in kleinere Bäume schneiden. Sie pflanzen also einen neuen Baum und hoffen, dass der neue Baum dabei hilft, neue Funktionen zu erstellen und den älteren Baum mit den alten Funktionen zu unterstützen. Aus offensichtlichen Gründen werden Sie dieses Mal, wie beim letzten Mal vor ein paar Jahren, das genetisch am weitesten fortgeschrittene Saatgut auswählen.

In der Saatbranche geht es schnell voran. Vor 10 Jahren würden Sie einen Apache Tomcat-Server mit einer Oracle-Datenbank als Ausgangswert verwenden und die meisten Teile schreiben, um Ihre Geschäftslogik auf diesem Server auszuführen. Vor fünf Jahren fangen Sie an, den großen Server in einige EC2-Instanzen und Docker-Container aufzuteilen und einige der Arbeiten an SaaSs von Drittanbietern zu delegieren. Und natürlich sieht Node.js jetzt nach einer guten Option aus. Vor drei Jahren würden Sie sich fragen, ob Sie vielleicht Kubernetes verwenden können, um die Verwirrung Ihrer Container zu verwalten. Im letzten Jahr überlegen Sie, ob Sie Ihre neuen Funktionen mit einer serverlosen App ausführen möchten. Das hochmoderne System, mit dem Sie schneller wachsen und zuverlässiger und wartbarer werden können. Alle für einen Bruchteil einer Gebühr für AWS, Azure und die dritte, vergaßen ihren Namen für eine Sekunde. Oh ja, es ist GCP.

Hier ist der Haken, alle diese Leute, die sich um den kleinen Baum gekümmert haben, sind neu in der neuen Anlage.

Ihre Leute in der DEV-Organisation, die wissen, wie man neue Funktionen und neue Fehler in einem großen J2EE-Server erstellt, schreiben nun ihre Geschäftslogik in Form von API-Gateways, Lambdas und Streams. Um es einfach zu machen, speichern sie es auf Service-Speichern wie DynamoDB und S3. Dieser große alte Server, den jeder Code hinzufügt, der nach jeder Zusammenführung getestet wird, wenn Sie Glück haben. Da es so groß ist, braucht es Zeit, um zu bestätigen, dass nichts gebremst wird. Alle paar Monate wird eine neue Version davon geboren.

Mit der neuen Technologie entstehen neue Erwartungen. Nachdem DEV (auf eine harte Weise) etwas über die technischen Schulden auf dem alten Server erfahren und sich frustriert hat, nicht schneller vorankommen zu können, möchte DEV eine CI / CD-Pipeline einrichten, um sie effizienter ausführen zu können.

Ihre OPS-Leute haben sich früher mit EC2-Befehlen befasst und ihr Bereitstellungsskript ausgeführt, das das Installationsprogramm von DEV aufruft. Sie überwachten Ihre Server und riefen Sie nachts an, wenn etwas nach Süden ging. Wenn Sie Glück haben, hat OPS ein zentrales Protokollierungssystem eingerichtet, das Ihnen bei der Problembehandlung hilft. In großen Unternehmen würde ein Überwachungssystem Alarmmeldungen liefern und helfen, Probleme im Vorfeld zu erkennen, und OPS würde sich auch darum kümmern.

Mit der neuen Technologie ist es jedoch ein Durcheinander. Nur zu viele Symbole im AWS Services-Menü. Es übersetzt sich in einen großen Schlammballen, eine Mischung aus Helm-Diagrammen, Köchen, Puppen, Bash-Dateien, Python-Skripten und allen Arten von CloudFormation-Yaml-Dateien.

Und wir haben den Siedepunkt erreicht… Die Geschäftslogik, die in Java in Form eines REST-Endpunkts codiert wurde, ist jetzt in API-Gateways aufgeteilt, die mit einer Reihe von Lambdas verbunden sind. Was früher in einem eigenständigen Ordner mit Klassen gespeichert wurde, wird nun in CloudFormation-yaml-Dateien und in einigen s3-Adressen in einer Reihe von Gläsern beschrieben.

Warten. Was? CloudFormations sind OPS-Assets. Sind sie nicht So in etwa. Dies bedeutet, dass einige Inhalte dieser Dateien alle wichtigen Informationen enthalten, die OPS verwendet, um Produktionssysteme am Leben zu erhalten. Assets wie Rollen und Richtlinien helfen verschiedenen Mandanten beim Schutz ihrer internen und externen Grenzen. Mit S3 kann OPS Daten für die Notfallwiederherstellung sichern. Die Netzwerkverwaltung, Maschinen und Cluster werden ebenfalls über diese Dateien gesteuert.

Wer sollte also dafür verantwortlich sein, alle kleinen Teile in einer serverlosen App zu kleben?

Kann OPS das tun? Natürlich können sie! Es bedeutet jedoch, dass sie praktisch DEV-Mitglieder werden. Wollen sie das tun? Es ist auch nicht klar, ob DEV-Teams sie als neue Mitglieder akzeptieren werden.

Kann DEV es tun? Ja. Das ist einfach. Es ist nur eine andere Sprache als Java, aber es ist eine Sprache. Kann DEV es jedoch in einem Produktionskonto bereitstellen? Wahrscheinlich ja. Das bedeutet jedoch, dass sie sich selbst auf mehr Art von OPS-bezogener Arbeit einstellen. An was können sich manche vielleicht nicht beteiligen? Außerdem mag OPS nicht die Idee, DEV in der gepflegten Produktionsumgebung frei laufen zu lassen.

Das heilige Gral Wenn wir DEV nur mehr Freiheit geben könnten, ohne dafür zu garantieren, dass unser Werk nicht stirbt. Im Allgemeinen arbeiten AWS, Azure und GCP daran, dass DEV mit Self-Service-Lösungen mehr erreichen kann. Außerdem versuchen einige weitere Startups, dieses spezifische Problem anzugehen. Inzwischen muss DEV jeden kleinen Schritt, den sie mit OPS unternehmen, koordinieren. Das ist also meine Freunde, warum Serverless so verdammt hart ist.

Siehe auch

So finden Sie den richtigen Hai-Staubsauger für Ihre BedürfnisseAn alle unsere geschätzten MitgliederMagisk Systemless Root für AndroidThema: SonstigesMac Services - Tipps und auch Vorschläge!Auf dem Mobile World Congress 2019 startet 1oT das revolutionäre eSIM für IoT