RubyRussia 2019: Nikolay Sverchkov über Serverless

28. September auf der Konferenz RubyRussia Nikolai Sverchkov wird eine Präsentation halten Serverless is Ruby Future. Ivan Solovyov diskutierte in einem Interview, warum dieser Trend interessant ist und warum Rubisten darauf achten sollten.




Sag mir, wie du zu Ruby gekommen bist?

Er begann an der Universität zu programmieren. Alle Übungen waren in C ++, aber ich habe die letzten Semesterarbeiten und Abschlussarbeiten in Ruby gemacht. Warum ich mich für Ruby entschieden habe, werde ich nicht mit Sicherheit sagen, wahrscheinlich weil die Sprache zu dieser Zeit dem Hype folgte. Niemand wusste es an der Ruby University, geschweige denn lehrte. Aber nach dem Abschluss wollte ich in Java schreiben. Dann schien es mir, dass Java etwas Besonderes ist, die coolsten Entwickler, eine Art höhere Kaste von Programmierern, und ich wollte einer von ihnen sein. Mein erstes Vorstellungsgespräch war in Java Junior und ich habe erfolgreich versagt. Aber er konnte in eine Firma gelangen, in der Ruby gebraucht wurde. Vielleicht ist es das Beste! Nur ein paar Jahre bewegten sich in Richtung Elixir. Jetzt arbeite ich in Evil Martians und mache Backend.

Ihr Bericht auf Serverless. Wie sind Sie in diese Richtung gekommen? Ist der Zugang zur Technologie schwierig?

In seiner Freizeit begann er zu lernen. Ich hatte eine echte, aber nicht mit der Hauptarbeitsaufgabe verbundene. Dann begann er, Serverless in den Projekten des Unternehmens einzusetzen. Die Eintrittsschwelle ist ziemlich niedrig, ich denke, dass sie nur geringfügig höher ist als die von Heroku. Schreiben Sie Ihr erstes "Hallo Welt!" Es wird sehr einfach sein - es gibt eine Reihe von Artikeln, Tutorials und eine äußerst umfangreiche Dokumentation von Amazon. Und dann wird es natürlich Schwierigkeiten geben. Es gibt Fallstricke, über die ich im Bericht sprechen werde.

Sollten Anfänger in Serverless eintauchen und es in der Produktion verwenden?

Ich denke, ja! Aber Sie müssen sich nicht beeilen, um alles mit Serverless zu implementieren. Zu Beginn können Sie sich Ihre Anwendung ansehen und darin eine kleine Geschäftslogik finden, die Sie in einen separaten Dienst stellen können. Wenn dieser neue Mikrodienst über eine einfache Kommunikationsschnittstelle verfügt, können Sie ihn mit einer Wahrscheinlichkeit von 99% mit demselben AWS Lambda implementieren. Wenn es sich um eine zustandslose Geschäftslogik handelt, müssen Sie im Idealfall nicht darüber nachdenken, wie die Ergebnisse gespeichert werden sollen, sondern über die Artefakte bei der Ausführung Ihrer Lambda-Funktion. Zum Beispiel kann das Senden eines Briefes eine gute erste Aufgabe sein. In meinem Bericht werde ich separat die Frage aufwerfen, für welches Aufgabenspektrum das serverlose Computermodell am besten geeignet ist.

Die Hauptempfehlung besteht darin, den Geschäftslogikcode von den Lambdas selbst zu trennen. Dies ist eine Variation der schmerzlich bekannten Regel „Thin Controller, Thick Models“. Erstens wird es einfacher sein, auf diese Weise zu testen. Zweitens können Sie, wenn Sie dabei feststellen, dass Serverless nicht für Ihre Aufgabe geeignet ist, problemlos auf eine bewährte Lösung migrieren. Ersetzen Sie beispielsweise die Serverless-Eingabeschicht durch einen normalen Webserver. In dieser Hinsicht sehr gute Jets . Dies ist ein Ruby Serverless-Framework, mit dem Sie eine Anwendung schreiben können, die sofort sowohl für AWS Lambda als auch für eine reguläre Amazon EC2-Instanz bereitgestellt werden kann.

Erzähl mir mehr über dieses Ruby-Framework?

Jets ist einzigartig. Trotz der Tatsache, dass es andere serverlose Frameworks gibt, die auf bestimmte Sprachen zugeschnitten sind, ist Jets am funktionalsten. Jetzt hat er mehr als 2500 Commits im Master. Das Framework verwendet viele bekannte Konventionen für einen Ruby-Entwickler. Es ist ein solches "Ruby on Rails on Serverless". Das hat aber auch Nachteile. Da Sie mit einem Serverless-Computing-Modell für die Ausführungszeit des Codes bezahlen, ist das Initialisieren und Laden einer großen Anzahl starker Abhängigkeiten im wahrsten Sinne des Wortes teuer. Die Offenlegung dieses Themas wird auch in meinem Bericht berücksichtigt.

Welche Plattformen sind derzeit für Serverless am häufigsten, was sind ihre Unterschiede, welche ist besser zu wählen? Soweit ich weiß, ertrinken Sie jetzt für Amazon Web Services, da Sie die meiste Zeit darüber sprechen.

Sie fragen, warum ich in unserem Gespräch oft das Wort „Lambda“ verwende? Ich denke, die Geschichte ist wie bei Karcher oder Xerox. Es gibt Marken, bei denen es üblich ist, eine ganze Nische von Produkten zu nennen. Im Jahr 2014 war Amazon das erste Unternehmen, das öffentlichen Zugriff auf ein Modell ohne Server - AWS Lambda - gewährte. Alle anderen: Microsoft mit Azure-Funktionen, Google mit Cloud-Funktionen, IBM mit IBM Cloud-Funktionen sind geistig immer noch in der Rolle des Aufholens. Obwohl der Markt ohne Server boomt, sind die Servicepreise von AWS häufig höher als die der Wettbewerber. So können neue Versionen wie Google Cloud Run das Spiel über Nacht drehen. Wenn wir eine detailliertere Analyse der Plattformvergleiche durchführen, würde ich empfehlen, ein Video von Ruslan Serkin von DataArt von der DUMP 2019-Konferenz anzusehen .

Was denkst du, in welche Richtung wird sich Serverless entwickeln?

Oh, das ist der interessanteste Teil meines Berichts! Ich kann auf Spoiler verzichten - komm hör zu! Stattdessen kann ich über Serveless und Produktion sprechen. Im April dieses Jahres war ich auf der RubyConfBy-Konferenz in Minsk, auf der der Autor derselben Jets sprach. Auf der Afterparty diskutierten wir über die Entwicklung ohne Server und warum wir bei Unterstützung durch wichtige Akteure der Branche die Massenverteilung von Lambda-Funktionen nicht sehen. Die Vorteile des Modells liegen auf der Hand, das Ökosystem ist transparent, aber es gibt kein weit verbreitetes Vertrauen seitens der IT-Community. Infolgedessen kamen wir zu dem Schluss, dass Serverless jetzt eine Art Schattenspieler ist und die Situation etwas an die Situation erinnert, die zu einer Zeit bei Docker war. Es wurde lange geglaubt, dass Docker in der Produktion Selbstmord ist. Jetzt sehen wir, dass die Containerisierung das Hauptwerkzeug für die Softwareverteilung ist. Ich denke, in Zukunft erwartet Serverless dasselbe. Immer mehr Menschen werden ihm vertrauen.

Werden serverlose Monolithen getötet?

Diese Frage kann wie folgt umformuliert werden: "Tötet die Microservice-Architektur Monolithen?" Da Serverless ein idealer Mikroserver ist - er ist klein, zustandslos und verfügt über eine minimale Schnittstelle für die Kommunikation mit der Außenwelt. So wie Mikrodienste keine Monolithen töten, töten Lambdas keine Monolithen. Alle drei Architekturen haben einen bestimmten Aufgabenbereich, für den sie sich ideal eignen. Und umgekehrt - es gibt Aufgaben, bei denen beispielsweise die Verwendung von Serverless unpraktisch ist. Suchen Sie nach Details in meinem Bericht.

Was tun mit der Anbietersperre? Sie haben beispielsweise ein Lambda für Amazon entwickelt, sich jedoch für Google entschieden.

Die Migration zwischen Plattformen ist schmerzhaft, wenn Sie kein Framework verwenden, z. B. ohne Server , das eine abstrakte API über Cloud-Anbieter bietet und es Ihnen ermöglicht, dieselbe Funktion sowohl bei Amazon als auch bei Google bereitzustellen. Wenn Sie grob gesagt alles mit Ihren Händen tun, dann wird es ein wenig schmerzhaft sein.

Was tun mit gewöhnlichen Lambdas, wenn Code verwendet wird? Zum Beispiel einige gemeinsame Komponenten, einige nützliche Funktionen und so weiter.

Zu diesem Thema gibt es noch keine Best Practices. Und die Frage kann erneut in "Wie fummelt man einen gemeinsamen Code zwischen Mikrodiensten?" Umformuliert werden, weil die Bedeutung dieselbe ist. Es gibt eine Option, wenn Sie die wiederverwendete Logik irgendwo in Shared halten und in der Funktion selbst verbinden. Dieser Ansatz funktioniert beispielsweise gut mit Go, wo die Ausgabe eine ausführbare Datei ist. Eine andere Möglichkeit besteht darin, die Komponentenkonnektivität zu beseitigen und Duplikate zuzulassen. Wahrscheinlich einen Versuch wert und sehen, was am besten funktioniert. Das einzige, was ich raten kann, ist nicht zu versuchen, Lambda-Funktionen universell zu machen. Irgendwann scheint es Ihnen, dass eine Überfunktion die perfekte Lösung für das Problem der Codeduplizierung ist. Aber mit der Zeit werden Sie feststellen, dass dies der Weg ins Nirgendwo ist. Sie erhalten eine bestimmte „monolithische Version von Serverless“ mit allen Problemen der ersten und zweiten Architektur.

Wir werden nach dem Bericht über RubyRussia genauer diskutieren!

Komm und du, die Registrierung ist noch offen, die Konferenz findet nächsten Samstag, den 28. September statt.

Es wird nicht nur Berichte geben, sondern auch Stände der besten Unternehmen:

Veranstalter - Evrone
Komplementärin - Toptal
Gold Partner - Gett
Silberpartner - Valarm , JetBrains , Bookmate und Cashwagon
Bronze Partner - InSales