DUMP-Konferenz | grep 'backend \ | devops'

Letzte Woche war ich auf der DUMP IT-Konferenz (https://dump-ekb.ru/) in Jekaterinburg und möchte darüber sprechen, was in den Abschnitten Backend und Devops besprochen wurde und ob regionale IT-Konferenzen Aufmerksamkeit verdienen.


Nikolay Sverchkov von Evil Martians über Serverless

Was war überhaupt da?

Insgesamt bestand die Konferenz aus 8 Abschnitten: Backend, Frontend, Mobile, Testen und Qualitätssicherung, Devops, Design, Wissenschaft und Management.

Die größten Hallen sind übrigens Wissenschaft und Management.)) Mit jeweils ~ 350 Personen. Backend und Frontend sind nicht viel weniger. Devops Hall war die kleinste, aber aktivste.

Ich habe mir die Berichte in den Abschnitten Devops und Backend angehört und ein bisschen mit den Sprechern gesprochen. Ich möchte über die behandelten Themen sprechen und auf der Konferenz einen Überblick über diese Abschnitte geben.

Vertreter von SKB-Kontur, DataArt, Evil Martians, dem Webstudio Jekaterinburg Flag und Miro (RealTimeBoard) sprachen in den Abschnitten Devops und Backend. Themen im Zusammenhang mit CI / CD, der Arbeit mit Warteschlangendiensten, der Protokollierung, Themen ohne Server und der Arbeit mit PostgreSQL in Go wurden ausführlich behandelt.

Es gab auch Berichte von Avito, Tinkoff, Yandex, Jetstyle, Megafon und der Ak Bars Bank, aber ich hatte keine Zeit, sie physisch zu besuchen (die Videoaufnahmen und Folien der Berichte sind noch nicht verfügbar, sie versprechen, innerhalb von 2 Wochen auf dump-ekb.ru veröffentlicht zu werden).

Devops Abschnitt

Was überraschte - die Sektion fand in der kleinsten Halle mit etwa 50 Sitzplätzen statt. Die Leute standen sogar in den Gängen :) Ich werde Ihnen von den Berichten erzählen, die ich gehört habe.

Elastisches Gewicht in Petabyte

Der Abschnitt begann mit einem Bericht von Vladimir Lil (SKB-Kontur) über Elasticsearch in Kontur. Sie haben eine ausreichend große und geladene Elastic (~ 800 TB Daten, ~ 1,3 Petabyte, unter Berücksichtigung der Redundanz). Elasticsearch für alle Dienste der Schaltung ist einzeln, besteht aus 2 Clustern (von 7 und 9 Servern) und ist so wichtig, dass es einen speziellen Elasticsearch-Ingenieur in der Schaltung gibt (tatsächlich Vladimir selbst).

Vladimir teilte auch seine Gedanken über die Vorteile von Elasticsearch und die Probleme, die er mit sich bringt.

Vorteil:

• Alle Protokolle an einem Ort, einfacher Zugriff auf sie
• Protokollspeicherung für ein Jahr und deren einfache Analyse
• Hohe Geschwindigkeit mit Protokollen
• Coole Datenvisualisierung "out of the box"

Die Probleme:

• Nachrichtenbroker - muss haben (Kafka spielt die Rolle von Kontur)
• Funktionen für die Arbeit mit Elasticsearch Curator (regelmäßig hohe Belastung durch reguläre Aufgaben in Curator)
• Keine eingebaute Autorisierung (nur für separates, ziemlich großes Geld oder als Open-Source-Plug-Ins mit unterschiedlicher Produktionsbereitschaft)

Über Open Distro for Elasticsearch waren die Bewertungen nur positiv :) Das gleiche Autorisierungsproblem wurde dort behoben.

Serverlose Entwicklungsfunktionen

Weiterer Bericht von Ruslan Serkin von DataArt über Serverless.

Ruslan sprach darüber, was Entwicklung mit dem Serverless-Ansatz im Allgemeinen ist und welche Funktionen er hat.

Serverless ist ein Entwicklungsansatz, bei dem Entwickler nichts mit Infrastruktur zu tun haben. Ein Beispiel ist AWS Lambda Serverless, Kubeless.io (Serverless in Kubernetes) und Google Cloud Functions.

Eine ideale Anwendung ohne Server ist nur eine Funktion, die eine Anforderung über eine dedizierte Gateway-API an einen Anbieter ohne Server sendet. Ein idealer Microservice, während im selben AWS Lambda eine große Anzahl moderner Programmiersprachen unterstützt wird. Die Kosten für die Unterstützung und Bereitstellung der Infrastruktur werden bei Cloud-Anbietern gleich Null. Die Unterstützung für kleine Anwendungen ist ebenfalls sehr günstig (AWS Lambda - 0,2 USD / 1 Million einfache Anfragen).

Die Skalierbarkeit eines solchen Systems ist nahezu perfekt - der Cloud-Anbieter kümmert sich selbst darum, Kubeless wird automatisch innerhalb des Kubernetes-Clusters skaliert.

Es gibt Nachteile:

• Die Entwicklung großer Anwendungen wird immer schwieriger
• Es gibt Schwierigkeiten bei der Profilerstellung von Anwendungen (Ihnen stehen nur Protokolle zur Verfügung, jedoch keine Profilerstellung im üblichen Sinne).
• keine Versionierung

Ehrlich gesagt habe ich vor ein paar Jahren von Serverless gehört, aber all diese Jahre war mir nicht klar, wie ich es richtig verwenden soll. Nach Ruslans Bericht erschien Verständnis, und nach dem Bericht von Nikolai Sverchkov (Evil Martians) aus dem Backend-Bereich konsolidierte er. Kein Wunder, dass ich zur Konferenz gegangen bin :)

CI für die Armen, oder lohnt es sich, ein eigenes CI für das Webstudio zu schreiben?

Mikhail Radionov, der Leiter des Flag-Webstudios aus Jekaterinburg, sprach über das selbstgeschriebene CI / CD.

Sein Studio ging von einer „manuellen CI / CD“ (über SSH am Server angemeldet, git pull, 100-mal täglich wiederholen) zu Jenkins und zu einem selbst geschriebenen Tool, mit dem Sie den Code steuern und Releases namens Pullkins ausführen können.

Warum hat Jenkins nicht gearbeitet? Es bot standardmäßig nicht genügend Flexibilität und war für die Anpassung zu kompliziert.

Die "Flagge" wird in Laravel (PHP-Framework) entwickelt. Bei der Entwicklung des CI / CD-Servers verwendeten Michael und seine Kollegen die integrierten Laravel-Mechanismen namens Telescope and Envoy. Das Ergebnis ist ein PHP-Server (Achtung), der eingehende Webhook-Anforderungen verarbeitet, das Frontend, Backend zusammenstellen, auf verschiedenen Servern bereitstellen und an Slack berichten kann.

Um eine blau / grüne Bereitstellung durchführen zu können und einheitliche Einstellungen in Umgebungen mit Entwicklungsstufen zu erzielen, wechselten sie zu Docker. Die Vorteile blieben gleich, die Möglichkeiten zur Homogenisierung der Umgebung und zur nahtlosen Bereitstellung wurden hinzugefügt, und die Notwendigkeit, Docker zu erlernen, um richtig damit zu arbeiten, wurde hinzugefügt.

Das Projekt ist auf Github

Wie wir die Anzahl der Rollbacks von Server-Releases um 99% reduziert haben

Der neueste Bericht im Bereich Devops stammt von Victor Eremchenko, Lead Devops Engineer bei Miro.com (ehemals RealTimeBoard).

RealTimeBoard, das Kernprodukt des Miro-Teams, basiert auf einer monolithischen Java-Anwendung. Das Sammeln, Testen und Bereitstellen ohne Ausfallzeiten ist eine schwierige Aufgabe. In diesem Fall ist es wichtig, eine solche Version des Codes bereitzustellen, damit er nicht zurückgesetzt werden muss (schwerer Monolith).

Auf dem Weg zum Aufbau eines Systems, das dies ermöglicht, hat Miro einen langen Weg zurückgelegt, einschließlich der Arbeit an der Architektur, den verwendeten Tools (Atlassian Bamboo, Ansible usw.) und der Arbeit am Aufbau von Teams (sie haben jetzt einen dedizierten Devops-Befehl + viele separate Scrum-Befehle von Entwicklern verschiedener Profile).

Der Weg erwies sich als schwierig und dornig, und Victor teilte seine Entscheidungen, den angesammelten Schmerz und den Optimismus, der dort nicht endete.


Gewann ein Buch für Fragen

Backend-Bereich

Ich hatte zwei Berichte - von Nikolai Sverchkov (Evil Martians), ebenfalls über Serverless, und von Grigory Koshelev (Kontur Company) über Telemetrie.

Serverlos für bloße Sterbliche

Wenn Ruslan Sirkin darüber sprach, was Serverless ist, zeigte Nikolai einfache Anwendungen mit Serverless und sprach über die Details, die sich auf die Kosten und die Geschwindigkeit von Anwendungen in AWS Lambda auswirken.

Ein interessantes Detail: Das minimal bezahlte Element ist 128 MB Speicher und 100 ms CPU, es kostet $ 0,000000208. Darüber hinaus ist 1 Million solcher Anfragen pro Monat kostenlos.

Einige der Funktionen von Nikolai haben häufig die Grenze von 100 ms überschritten (die Hauptanwendung wurde in Ruby geschrieben), sodass das Umschreiben auf Go zu hervorragenden Einsparungen führte.

Vostok Hercules - Telemetrie wieder großartig machen!

Der neueste Bericht aus dem Backend-Bereich von Grigory Koshelev (Firma Kontur) über Telemetrie. Telemetrie ist Protokolle, Metriken, Anwendungsspuren.

Contour verwendet hierfür seine eigenen schriftlichen Tools, die auf Github veröffentlicht wurden. Das Berichtstool Hercules, github.com/vostok/hercules , wird zur Bereitstellung von Telemetriedaten verwendet.

Ein Bericht von Vladimir Lila im Abschnitt Devops befasste sich mit dem Speichern und Verarbeiten von Protokollen in Elasticsearch. Es besteht jedoch weiterhin die Aufgabe, Protokolle von vielen tausend Geräten und Anwendungen bereitzustellen, und Tools wie Vostok Hercules lösen diese Probleme.

Die Strecke verlief wie viele - von RabbitMQ bis Apache Kafka, aber nicht so einfach)) Sie mussten Zookeeper, Cassandra und Graphite zum Schema hinzufügen. Ich werde die Informationen zu diesem Bericht (nicht mein Profil) nicht vollständig offenlegen. Bei Interesse können Sie auf die Folien und das Video auf der Konferenzwebsite warten.

Wie im Vergleich zu anderen Konferenzen?

Ich kann mich nicht mit Konferenzen in Moskau und St. Petersburg vergleichen, ich kann es mit anderen Veranstaltungen im Ural und mit dem 404fest in Samara vergleichen.

DUMP wird in 8 Abschnitten abgehalten, dies ist ein Rekord für die Ural-Konferenzen. Sehr große Bereiche der Wissenschaft und des Managements, dies ist auch ungewöhnlich. Das Publikum in Jekaterinburg ist ziemlich strukturiert - die Stadt hat große Entwicklungsabteilungen Yandex, Kontur, Tinkoff, dies hinterlässt seine Spuren in den Berichten.

Ein weiterer interessanter Punkt ist, dass viele Unternehmen sofort 3-4 Redner auf der Konferenz haben (dies war bei Kontur, Evil Martians, Tinkoff der Fall). Viele von ihnen waren Sponsoren, aber die Berichte sind anderen durchaus ebenbürtig, es handelt sich nicht um Werbeberichte.

Gehen oder nicht gehen? Wenn Sie im oder in der Nähe des Urals leben, haben Sie die Möglichkeit und interessante Themen - ja, natürlich. Wenn Sie über eine lange Reise nachdenken, würde ich mir die Themen der Berichte und Videoberichte aus den Vorjahren www.youtube.com/user/videoitpeople/videos ansehen und eine Entscheidung treffen.
Ein weiteres Plus an Konferenzen in den Regionen ist in der Regel die Kommunikation mit dem Redner nach den Berichten. Es gibt weniger Bewerber für eine solche Kommunikation.



Danke an Dump und Jekaterinburg! )