Die Habr-Konferenz ist keine Debütgeschichte. Früher haben wir ziemlich große Toaster-Events für 300-400 Personen abgehalten, aber jetzt haben wir entschieden, dass kleine thematische Treffen relevant wären, deren Richtung Sie beispielsweise in den Kommentaren festlegen können. Die erste Konferenz dieses Formats fand im Juli statt und war der Backend-Entwicklung gewidmet. Die Teilnehmer hörten sich Berichte über die Besonderheiten des Übergangs vom Backend zu ML und über das Design des Quadrupel-Dienstes auf dem State Services-Portal an und nahmen auch an einem runden Tisch zum Thema Serverless teil. Für diejenigen, die nicht persönlich an der Veranstaltung teilnehmen konnten, verraten wir in diesem Beitrag das Interessanteste.
Von der Backend-Entwicklung bis zum maschinellen Lernen
Was machen Dateningenieure im ML? Inwiefern ähneln und unterscheiden sich die Aufgaben eines Backend-Entwicklers und eines ML-Ingenieurs? Welchen Weg müssen Sie einschlagen, um von Ihrem ersten Beruf in Ihren zweiten Beruf zu wechseln? Dies erzählte Alexander Parinov, der nach 10 Jahren Backend-Arbeit in das maschinelle Lernen einstieg.
Alexander Parinow
Heute arbeitet Alexander als Computer-Vision-Systemarchitekt bei der X5 Retail Group und trägt zu Open-Source-Projekten im Zusammenhang mit Computer Vision und Deep Learning bei (github.com/creafz). Seine Fähigkeiten werden durch seine Teilnahme an den Top 100 der Weltrangliste von Kaggle Master (kaggle.com/creafz), der beliebtesten Plattform für maschinelle Lernwettbewerbe, bestätigt.
Warum auf maschinelles Lernen umsteigen?
Vor anderthalb Jahren beschrieb Jeff Dean, Leiter von Google Brain, Googles Deep-Learning-basiertem Forschungsprojekt für künstliche Intelligenz, wie eine halbe Million Codezeilen in Google Translate durch ein neuronales Tensor-Flow-Netzwerk mit nur 500 Zeilen ersetzt wurden. Nach dem Training des Netzwerks stieg die Qualität der Daten und die Infrastruktur wurde einfacher. Es scheint, dass dies unsere glänzende Zukunft ist: Wir müssen keinen Code mehr schreiben, es reicht aus, Neuronen zu erstellen und sie mit Daten zu füllen. Aber in der Praxis ist alles viel komplizierter.
ML-Infrastruktur bei Google
Neuronale Netze sind nur ein kleiner Teil der Infrastruktur (das kleine schwarze Quadrat im Bild oben). Es sind viele weitere Hilfssysteme erforderlich, um Daten zu empfangen, zu verarbeiten, zu speichern, die Qualität zu prüfen usw. Wir benötigen eine Infrastruktur für Schulungen, die Bereitstellung von Code für maschinelles Lernen in der Produktion und das Testen dieses Codes. Alle diese Aufgaben ähneln genau der Arbeit von Backend-Entwicklern.
Maschineller Lernprozess
Was ist der Unterschied zwischen ML und Backend?
Bei der klassischen Programmierung schreiben wir Code und dieser bestimmt das Verhalten des Programms. In ML haben wir einen kleinen Modellcode und viele Daten, die wir auf das Modell werfen. Daten in ML sind sehr wichtig: Das gleiche Modell, das auf verschiedenen Daten trainiert wurde, kann völlig unterschiedliche Ergebnisse liefern. Das Problem besteht darin, dass die Daten fast immer verstreut sind und in verschiedenen Systemen (relationale Datenbanken, NoSQL-Datenbanken, Protokolle, Dateien) gespeichert sind.
Datenversionierung
ML erfordert nicht nur eine Versionierung des Codes, wie bei der klassischen Entwicklung, sondern auch der Daten: Es ist notwendig, klar zu verstehen, worauf das Modell trainiert wurde. Dazu können Sie die beliebte Data Science Version Control-Bibliothek (dvc.org) verwenden.
Datenmarkierung
Die nächste Aufgabe ist die Datenkennzeichnung. Markieren Sie beispielsweise alle Objekte im Bild oder sagen Sie, zu welcher Klasse es gehört. Dies übernehmen spezielle Dienste wie Yandex.Toloka, deren Arbeit durch das Vorhandensein einer API erheblich vereinfacht wird. Schwierigkeiten entstehen durch den „menschlichen Faktor“: Sie können die Qualität der Daten verbessern und Fehler auf ein Minimum reduzieren, indem Sie dieselbe Aufgabe mehreren Ausführenden anvertrauen.
Visualisierung im Tensor Board
Die Protokollierung von Experimenten ist erforderlich, um Ergebnisse zu vergleichen und anhand einiger Metriken das beste Modell auszuwählen. Es gibt eine große Auswahl an Visualisierungstools – zum Beispiel Tensor Board. Es gibt jedoch keine idealen Möglichkeiten, Experimente zu speichern. Kleine Unternehmen begnügen sich häufig mit einer Excel-Tabelle, während große Unternehmen spezielle Plattformen für die Speicherung der Ergebnisse in einer Datenbank nutzen.
Es gibt viele Plattformen für maschinelles Lernen, aber keine deckt 70 % des Bedarfs ab
Das erste Problem, dem man sich stellen muss, wenn man ein trainiertes Modell in die Produktion bringt, hängt mit dem Lieblingswerkzeug von Datenwissenschaftlern zusammen – Jupyter Notebook. Es gibt keine Modularität darin, das heißt, die Ausgabe ist ein solches „Fußtuch“ aus Code, der nicht in logische Teile – Module – unterteilt ist. Alles ist durcheinander: Klassen, Funktionen, Konfigurationen usw. Dieser Code ist schwer zu versionieren und zu testen.
Wie gehe ich damit um? Sie können sich wie Netflix damit abfinden und Ihre eigene Plattform erstellen, die es Ihnen ermöglicht, diese Laptops direkt in der Produktion zu starten, Daten als Eingabe an sie zu übertragen und Ergebnisse zu erhalten. Sie können die Entwickler, die das Modell in die Produktion bringen, dazu zwingen, den Code normal neu zu schreiben und ihn in Module aufzuteilen. Bei diesem Ansatz kann es jedoch leicht passieren, dass ein Fehler auftritt und das Modell nicht wie vorgesehen funktioniert. Daher besteht die ideale Option darin, die Verwendung von Jupyter Notebook für Modellcode zu verbieten. Vorausgesetzt natürlich, die Datenwissenschaftler sind damit einverstanden.
Modell als Blackbox
Der einfachste Weg, ein Modell in Produktion zu bringen, besteht darin, es als Blackbox zu verwenden. Sie haben eine Art Modellklasse, Ihnen wurden die Gewichte des Modells (Parameter der Neuronen des trainierten Netzwerks) gegeben, und wenn Sie diese Klasse initialisieren (die Vorhersagemethode aufrufen, ihr ein Bild füttern), erhalten Sie eine bestimmte Vorhersage als Ausgabe. Was drinnen passiert, spielt keine Rolle.
Separater Serverprozess mit Modell
Sie können auch einen bestimmten separaten Prozess starten und ihn über eine RPC-Warteschlange senden (mit Bildern oder anderen Quelldaten). Am Ausgang erhalten wir Vorhersagen.
Ein Beispiel für die Verwendung eines Modells in Flask:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Das Problem bei diesem Ansatz ist die Leistungsbeschränkung. Nehmen wir an, wir haben von Datenwissenschaftlern geschriebenen Phyton-Code, der langsam ist, und wir möchten die maximale Leistung herausholen. Dazu können Sie Tools verwenden, die den Code in nativen Code umwandeln, oder ihn in ein anderes, auf die Produktion zugeschnittenes Framework umwandeln. Es gibt solche Tools für jedes Framework, aber es gibt keine idealen; Sie müssen sie selbst hinzufügen.
Die Infrastruktur in ML ist die gleiche wie in einem regulären Backend. Es gibt Docker und Kubernetes, nur für Docker müssen Sie die Laufzeitumgebung von NVIDIA installieren, die es Prozessen im Container ermöglicht, auf Grafikkarten im Host zuzugreifen. Kubernetes benötigt ein Plugin, damit es Server mit Grafikkarten verwalten kann.
Im Gegensatz zur klassischen Programmierung gibt es bei ML viele verschiedene bewegliche Elemente in der Infrastruktur, die überprüft und getestet werden müssen – zum Beispiel Datenverarbeitungscode, Modelltrainingspipeline und Produktion (siehe Abbildung oben). Es ist wichtig, den Code zu testen, der verschiedene Pipeline-Teile verbindet: Es gibt viele Teile und an Modulgrenzen treten sehr oft Probleme auf.
So funktioniert AutoML
AutoML-Dienste versprechen, das optimale Modell für Ihre Zwecke auszuwählen und zu trainieren. Aber Sie müssen verstehen: Daten sind im ML sehr wichtig, das Ergebnis hängt von ihrer Aufbereitung ab. Markup wird von Menschen vorgenommen, was mit Fehlern behaftet ist. Ohne strenge Kontrolle kann das Ergebnis Müll sein, und es ist noch nicht möglich, den Prozess zu automatisieren; eine Überprüfung durch Spezialisten – Datenwissenschaftler – ist erforderlich. Hier bricht AutoML zusammen. Es kann jedoch bei der Auswahl einer Architektur hilfreich sein – wenn Sie die Daten bereits vorbereitet haben und eine Reihe von Experimenten durchführen möchten, um das beste Modell zu finden.
Wie Sie in das maschinelle Lernen einsteigen
Der einfachste Weg, in ML einzusteigen, ist die Entwicklung in Python, das in allen Deep-Learning-Frameworks (und regulären Frameworks) verwendet wird. Diese Sprache ist für diesen Tätigkeitsbereich praktisch Pflicht. C++ wird für einige Computer-Vision-Aufgaben verwendet, beispielsweise in Steuerungssystemen für selbstfahrende Autos. JavaScript und Shell – zur Visualisierung und für so seltsame Dinge wie das Ausführen eines Neurons im Browser. Bei der Arbeit mit Big Data und für maschinelles Lernen kommen Java und Scala zum Einsatz. R und Julia werden von Leuten geliebt, die mathematische Statistik studieren.
Der bequemste Weg, erste praktische Erfahrungen zu sammeln, ist auf Kaggle; die Teilnahme an einem der Wettbewerbe der Plattform ermöglicht mehr als ein Jahr Theoriestudium. Auf dieser Plattform können Sie den von jemand anderem geposteten und kommentierten Code nehmen und versuchen, ihn zu verbessern und für Ihre Zwecke zu optimieren. Bonus – Ihr Kaggle-Rang wirkt sich auf Ihr Gehalt aus.
Eine weitere Möglichkeit besteht darin, dem ML-Team als Backend-Entwickler beizutreten. Es gibt viele Startups im Bereich maschinelles Lernen, bei denen Sie Erfahrungen sammeln können, indem Sie Ihren Kollegen bei der Lösung ihrer Probleme helfen. Schließlich können Sie einer der Datenwissenschaftler-Communitys beitreten – Open Data Science (ods.ai) und anderen.
Der Referent hat unter dem Link weitere Informationen zum Thema gepostet
„Quadrupel“ – ein Dienst zur gezielten Benachrichtigung des Portals „State Services“
Evgeny Smirnov
Der nächste Redner war der Leiter der Abteilung für die Entwicklung der E-Government-Infrastruktur, Evgeny Smirnov, der über Quadruple sprach. Dies ist ein gezielter Benachrichtigungsdienst für das Gosuslugi-Portal (gosuslugi.ru), die meistbesuchte Regierungsressource auf dem Runet. Das tägliche Publikum beträgt 2,6 Millionen, insgesamt gibt es 90 Millionen registrierte Nutzer auf der Seite, davon 60 Millionen bestätigte. Die Auslastung der Portal-API beträgt 30 RPS.
Technologien, die im Backend der Staatsdienste verwendet werden
„Quadrupel“ ist ein gezielter Benachrichtigungsdienst, mit dessen Hilfe der Nutzer durch die Einrichtung spezieller Benachrichtigungsregeln zum für ihn passenden Zeitpunkt ein Angebot für eine Dienstleistung erhält. Die Hauptanforderungen bei der Entwicklung des Dienstes waren flexible Einstellungen und ausreichend Zeit für Mailings.
Wie funktioniert Quadrupel?
Das obige Diagramm zeigt eine der Betriebsregeln des Quadrupel am Beispiel einer Situation mit der Notwendigkeit, einen Führerschein zu ersetzen. Zunächst sucht der Dienst nach Benutzern, deren Ablaufdatum in einem Monat abläuft. Ihnen wird ein Banner mit einem Angebot zur Inanspruchnahme der entsprechenden Dienstleistung angezeigt und eine Nachricht per E-Mail verschickt. Für Benutzer, deren Frist bereits abgelaufen ist, ändern sich Banner und E-Mail. Nach erfolgreichem Rechteaustausch erhält der Nutzer weitere Benachrichtigungen – mit einem Vorschlag zur Aktualisierung der Daten in der Identität.
Aus technischer Sicht handelt es sich um groovige Skripte, in denen der Code geschrieben wird. Die Eingabe sind Daten, die Ausgabe ist wahr/falsch, übereinstimmend/nicht übereinstimmend. Insgesamt gibt es mehr als 50 Regeln – von der Bestimmung des Geburtstags des Benutzers (das aktuelle Datum entspricht dem Geburtsdatum des Benutzers) bis hin zu komplexen Situationen. Jeden Tag identifizieren diese Regeln etwa eine Million Übereinstimmungen – Personen, die benachrichtigt werden müssen.
Vierfache Benachrichtigungskanäle
Unter der Haube von Quadrupel befinden sich eine Datenbank, in der Benutzerdaten gespeichert werden, und drei Anwendungen:
- Arbeitnehmer zur Aktualisierung von Daten vorgesehen.
- Rest API holt die Banner selbst ab und liefert sie an das Portal und die mobile Anwendung.
- Scheduler startet Arbeiten zur Neuberechnung von Bannern oder Massenmailings.
Um Daten zu aktualisieren, ist das Backend ereignisgesteuert. Zwei Schnittstellen – Rest oder JMS. Es gibt viele Ereignisse; vor dem Speichern und Verarbeiten werden sie aggregiert, um unnötige Anfragen zu vermeiden. Die Datenbank selbst, die Tabelle, in der die Daten gespeichert sind, sieht aus wie ein Schlüsselwertspeicher – der Schlüssel des Benutzers und der Wert selbst: Flags, die das Vorhandensein oder Fehlen relevanter Dokumente anzeigen, deren Gültigkeitsdauer, aggregierte Statistiken zur Reihenfolge der Dienste von dieser Benutzer usw.
Nach dem Speichern der Daten wird im JMS eine Aufgabe gesetzt, damit die Banner sofort neu berechnet werden – diese müssen sofort im Web angezeigt werden. Das System startet nachts: In Benutzerintervallen werden Aufgaben ins JMS geworfen, nach denen die Regeln neu berechnet werden müssen. Dies wird von den an der Neuberechnung beteiligten Prozessoren erfasst. Anschließend gelangen die Verarbeitungsergebnisse in die nächste Warteschlange, die entweder die Banner in der Datenbank speichert oder Benutzerbenachrichtigungsaufgaben an den Dienst sendet. Der Vorgang dauert 5–7 Stunden und ist leicht skalierbar, da Sie jederzeit entweder Handler hinzufügen oder Instanzen mit neuen Handlern auslösen können.
Der Service funktioniert recht gut. Doch das Datenvolumen wächst, da es mehr Nutzer gibt. Dies führt zu einer erhöhten Belastung der Datenbank – selbst unter Berücksichtigung der Tatsache, dass die Rest-API auf das Replikat schaut. Der zweite Punkt ist JMS, das, wie sich herausstellte, aufgrund seines hohen Speicherverbrauchs wenig geeignet ist. Es besteht ein hohes Risiko eines Warteschlangenüberlaufs, der zum Absturz von JMS und zum Stoppen der Verarbeitung führt. Danach ist es unmöglich, JMS zu starten, ohne die Protokolle zu löschen.
Es ist geplant, die Probleme mithilfe von Sharding zu lösen, wodurch die Belastung der Datenbank ausgeglichen werden kann. Es gibt auch Pläne, das Datenspeicherschema zu ändern und JMS auf Kafka umzustellen – eine fehlertolerantere Lösung, die Speicherprobleme löst.
Backend-as-a-Service vs. Serverlos
Von links nach rechts: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend as a Service oder serverlose Lösung? An der Diskussion dieses drängenden Themas am Runden Tisch beteiligten sich:
- Ara Israelyan, CTO CTO und Gründer von Scorocode.
- Nikolay Markov, Senior Data Engineer bei der Aligned Research Group.
- Andrey Tomilenko, Leiter der RUVDS-Entwicklungsabteilung.
Moderiert wurde das Gespräch vom Senior-Entwickler Alexander Borgart. Die Debatten, an denen sich auch die Zuhörer beteiligten, präsentieren wir in einer gekürzten Fassung.
— Was ist nach Ihrem Verständnis Serverlos?
Andrew: Dies ist ein Rechenmodell – eine Lambda-Funktion, die Daten verarbeiten muss, sodass das Ergebnis nur von den Daten abhängt. Der Begriff stammt entweder von Google oder von Amazon und seinem AWS Lambda-Dienst. Für einen Anbieter ist es einfacher, eine solche Funktion zu bewältigen, indem er ihm einen Kapazitätspool zuweist. Verschiedene Benutzer können unabhängig voneinander auf denselben Servern verwaltet werden.
Nikolaus: Vereinfacht gesagt verlagern wir einen Teil unserer IT-Infrastruktur und Geschäftslogik in die Cloud, ins Outsourcing.
Ara: Auf Seiten der Entwickler - ein guter Versuch, Ressourcen zu sparen, auf Seiten der Vermarkter - um mehr Geld zu verdienen.
— Ist Serverless dasselbe wie Microservices?
Nikolaus: Nein, Serverless ist eher eine Architekturorganisation. Ein Microservice ist eine atomare Einheit einer Logik. Serverless ist ein Ansatz, keine „separate Einheit“.
Ara: Eine serverlose Funktion kann in einen Mikrodienst gepackt werden, dies ist jedoch nicht mehr serverlos, sondern keine Lambda-Funktion mehr. Bei Serverless beginnt eine Funktion erst zu funktionieren, wenn sie angefordert wird.
Andrew: Sie unterscheiden sich in ihrer Lebensdauer. Wir haben die Lambda-Funktion gestartet und vergessen. Es funktionierte ein paar Sekunden lang und der nächste Client kann seine Anfrage auf einer anderen physischen Maschine bearbeiten.
— Was skaliert besser?
Ara: Bei der horizontalen Skalierung verhalten sich Lambda-Funktionen genauso wie Microservices.
Nikolaus: Wie viele Replikate Sie auch festlegen, es werden genauso viele davon vorhanden sein; Serverless hat keine Probleme mit der Skalierung. Ich habe einen Replikatsatz in Kubernetes erstellt, 20 Instanzen „irgendwo“ gestartet und 20 anonyme Links an Sie zurückgegeben. Nach vorne!
— Ist es möglich, ein Backend auf Serverless zu schreiben?
Andrew: Theoretisch, aber es macht keinen Sinn. Lambda-Funktionen basieren auf einem einzigen Repository – wir müssen die Garantie gewährleisten. Wenn ein Benutzer beispielsweise eine bestimmte Transaktion durchgeführt hat, sollte er bei der nächsten Kontaktaufnahme sehen: Die Transaktion wurde durchgeführt, das Geld wurde gutgeschrieben. Alle Lambda-Funktionen blockieren diesen Aufruf. Tatsächlich wird eine Reihe serverloser Funktionen zu einem einzigen Dienst mit einem Engpass-Zugriffspunkt auf die Datenbank.
— In welchen Situationen ist der Einsatz einer serverlosen Architektur sinnvoll?
Andrew: Aufgaben, die keinen gemeinsamen Speicher erfordern – dasselbe Mining, Blockchain. Wo Sie viel zählen müssen. Wenn Sie über viel Rechenleistung verfügen, können Sie eine Funktion wie „Berechnen Sie den Hash von etwas dort …“ definieren. Sie können das Problem mit der Datenspeicherung jedoch lösen, indem Sie beispielsweise Lambda-Funktionen von Amazon und deren verteilte Speicherung übernehmen . Und es stellt sich heraus, dass Sie einen regulären Gottesdienst schreiben. Lambda-Funktionen greifen auf den Speicher zu und geben dem Benutzer eine Antwort.
Nikolaus: Container, die serverlos ausgeführt werden, verfügen über äußerst begrenzte Ressourcen. Es gibt wenig Erinnerung und alles andere. Wenn Ihre gesamte Infrastruktur jedoch vollständig in einer Cloud bereitgestellt wird – Google, Amazon – und Sie einen dauerhaften Vertrag mit ihnen haben und für all dies ein Budget vorhanden ist, können Sie für einige Aufgaben serverlose Container verwenden. Es ist notwendig, sich innerhalb dieser Infrastruktur zu befinden, da alles auf den Einsatz in einer bestimmten Umgebung zugeschnitten ist. Das heißt, wenn Sie bereit sind, alles an die Cloud-Infrastruktur zu binden, können Sie experimentieren. Der Vorteil besteht darin, dass Sie diese Infrastruktur nicht verwalten müssen.
Ara: Die Tatsache, dass Serverless nicht verlangt, dass Sie Kubernetes, Docker, die Installation von Kafka usw. verwalten, ist Selbsttäuschung. Dasselbe Amazon und Google installieren dies. Eine andere Sache ist, dass Sie ein SLA haben. Sie könnten genauso gut alles auslagern, anstatt es selbst zu programmieren.
AndrewHinweis: Serverless an sich ist günstig, für andere Amazon-Dienste – zum Beispiel die Datenbank – muss man allerdings viel bezahlen. Die Leute haben sie bereits verklagt, weil sie für das API-Gate wahnsinnige Summen verlangt haben.
Ara: Wenn wir über Geld sprechen, müssen Sie diesen Punkt berücksichtigen: Sie müssen die gesamte Entwicklungsmethodik im Unternehmen um 180 Grad umdrehen, um den gesamten Code auf Serverless zu übertragen. Dies wird viel Zeit und Geld kosten.
— Gibt es sinnvolle Alternativen zum kostenpflichtigen Serverless von Amazon und Google?
Nikolaus: In Kubernetes starten Sie eine Art Job, er läuft und stirbt – aus architektonischer Sicht ist das ziemlich serverlos. Wenn Sie eine wirklich interessante Geschäftslogik mit Warteschlangen und Datenbanken erstellen möchten, müssen Sie etwas mehr darüber nachdenken. Dies alles kann gelöst werden, ohne Kubernetes zu verlassen. Ich würde mir nicht die Mühe machen, zusätzliche Implementierungen in die Länge zu ziehen.
— Wie wichtig ist es, zu überwachen, was in Serverless passiert?
Ara: Hängt von der Systemarchitektur und den Geschäftsanforderungen ab. Im Wesentlichen muss der Anbieter Berichte bereitstellen, die dem Entwicklerteam helfen, mögliche Probleme zu verstehen.
Nikolaus: Amazon verfügt über CloudWatch, wo alle Protokolle gestreamt werden, auch die von Lambda. Integrieren Sie die Protokollweiterleitung und verwenden Sie ein separates Tool zum Anzeigen, Warnen usw. Sie können Agenten in die von Ihnen gestarteten Container stopfen.
- Fassen wir es zusammen.
Andrew: Es ist nützlich, über Lambda-Funktionen nachzudenken. Wenn Sie selbst einen Dienst erstellen – keinen Microservice, sondern einen, der eine Anfrage schreibt, auf die Datenbank zugreift und eine Antwort sendet – löst die Lambda-Funktion eine Reihe von Problemen: mit Multithreading, Skalierbarkeit usw. Wenn Ihre Logik auf diese Weise aufgebaut ist, können Sie diese Lambdas in Zukunft auf Microservices übertragen oder Dienste von Drittanbietern wie Amazon nutzen. Die Technologie ist nützlich, die Idee ist interessant. Wie berechtigt dies für die Wirtschaft ist, ist noch offen.
Nikolay: Serverless eignet sich besser für Betriebsaufgaben als für die Berechnung einiger Geschäftslogiken. Ich betrachte es immer als Ereignisverarbeitung. Wenn Sie es in Amazon haben, wenn Sie in Kubernetes sind, ja. Andernfalls müssen Sie einen erheblichen Aufwand betreiben, um Serverless selbst zum Laufen zu bringen. Es ist notwendig, einen konkreten Geschäftsfall zu betrachten. Eine meiner Aufgaben ist jetzt zum Beispiel: Wenn Dateien in einem bestimmten Format auf der Festplatte erscheinen, muss ich sie nach Kafka hochladen. Ich kann WatchDog oder Lambda verwenden. Aus logischer Sicht sind beide Optionen geeignet, aber von der Implementierung her ist Serverless komplizierter und ich bevorzuge den einfacheren Weg, ohne Lambda.
Ara: Serverless ist eine interessante, anwendbare und technisch sehr schöne Idee. Früher oder später wird die Technologie den Punkt erreichen, an dem jede Funktion in weniger als 100 Millisekunden gestartet werden kann. Dann steht grundsätzlich außer Frage, ob die Wartezeit für den Nutzer kritisch ist. Gleichzeitig hängt die Anwendbarkeit von Serverless, wie Kollegen bereits sagten, vollständig vom Geschäftsproblem ab.
Wir danken unseren Sponsoren, die uns sehr geholfen haben:
- IT-Konferenzraum «» für die Konferenzseite.
- Kalender mit IT-Veranstaltungen und Veröffentlichung“» für Informationsunterstützung und Neuigkeiten.
- «„für Geschenke.
- für Co-Creation.
- „Verein für elektronische Kommunikation“ für Engagement und Erfahrung.
- Hauptsponsor - für alles!
Source: habr.com