Conferencia DUMP | grep 'backend \ | devops'

La semana pasada asistí a la conferencia DUMP IT (https://dump-ekb.ru/) en Ekaterimburgo y quiero hablar sobre lo que se discutió en las secciones Backend y Devops y si las conferencias regionales de TI merecen atención.


Nikolay Sverchkov de Evil Martians sobre Serverless

¿Qué había allí en absoluto?

En total, la conferencia tuvo 8 secciones: Backend, Frontend, Mobile, Testing y QA, Devops, Design, Science y Management.

Las salas más grandes, por cierto, son Ciencia y Administración)) Con ~ 350 personas cada una. Backend y Frontend no son mucho menos. Devops Hall era el más pequeño pero más activo.

Escuché los informes en las secciones Devops y Backend y hablé un poco con los oradores. Quiero hablar sobre los temas tratados y dar una visión general de estas secciones en la conferencia.

Representantes del estudio web SKB-Kontur, DataArt, Evil Martians, Flag of Yekaterinburg, Miro (RealTimeBoard) hablaron en las secciones Devops y Backend. Los temas relacionados con CI / CD, el trabajo con servicios de cola, el registro, los temas sin servidor y el trabajo con PostgreSQL en Go se divulgaron bien.

También hubo informes de Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, pero no tuve tiempo de visitarlos físicamente (las grabaciones de video y las diapositivas de los informes aún no están disponibles, prometen publicarlas en dump-ekb.ru dentro de 2 semanas).

Sección Devops

Lo que sorprendió: la sección se celebró en el salón más pequeño, de unos 50 asientos. La gente incluso se paró en los pasillos :) Te contaré sobre los informes que logré escuchar.

Peso elástico en petabytes

La sección comenzó con un informe de Vladimir Lil (SKB-Kontur) sobre Elasticsearch en Kontur. Tienen un elástico suficientemente grande y cargado (~ 800 TB de datos, ~ 1.3 petabytes, teniendo en cuenta la redundancia). Elasticsearch para todos los servicios del circuito es único, consta de 2 clústeres (de 7 y 9 servidores), y es tan importante que hay un ingeniero especial de Elasticsearch en el circuito (de hecho, el propio Vladimir).

Vladimir también compartió sus pensamientos sobre los beneficios de Elasticsearch y los problemas que trae.

Beneficio:

• Todos los registros en un solo lugar, fácil acceso a ellos.
• Almacenamiento de registros durante un año y su fácil análisis.
• Alta velocidad con troncos
• Visualización de datos genial "fuera de la caja"

Los problemas:

• corredor de mensajes - debe tener (Kafka interpreta el papel de Kontur)
• Características de trabajar con Elasticsearch Curator (carga elevada creada periódicamente a partir de tareas regulares en Curator)
• sin autorización integrada (solo para dinero separado, bastante grande, o como complementos de código abierto de diversos grados de preparación para la producción)

Acerca de Open Distro para Elasticsearch, las revisiones solo fueron positivas :) El mismo problema de autorización se resolvió allí.

Características de desarrollo sin servidor

Informe adicional de Ruslan Serkin de DataArt sobre Serverless.

Ruslan habló sobre el desarrollo con el enfoque sin servidor en general, y cuáles son sus características.

Sin servidor es un enfoque de desarrollo donde los desarrolladores no tienen nada que ver con la infraestructura. Un ejemplo es AWS Lambda Serverless, Kubeless.io (Serverless dentro de Kubernetes), Google Cloud Functions.

Una aplicación ideal sin servidor es solo una característica que envía una solicitud a un proveedor sin servidor a través de una API de puerta de enlace dedicada. Un microservicio ideal, mientras que en el mismo AWS Lambda se admite una gran cantidad de lenguajes de programación modernos. El costo de soportar e implementar la infraestructura se vuelve cero en el caso de los proveedores de la nube; el soporte de pequeñas aplicaciones también será muy barato (AWS Lambda - $ 0.2 / 1 millón de solicitudes simples)

La escalabilidad de dicho sistema es casi perfecta: el proveedor de la nube se encarga de esto por sí solo, Kubeless se escala automáticamente dentro del clúster de Kubernetes.

Hay desventajas:

• desarrollar aplicaciones grandes es cada vez más difícil
• existe una dificultad con las aplicaciones de creación de perfiles (solo los registros están disponibles para usted, pero no la creación de perfiles en el sentido habitual)
• sin versiones

Francamente, escuché sobre Serverless hace unos años, pero en todos estos años no estaba claro cómo usarlo correctamente. Después del informe de Ruslan, apareció la comprensión, y después del informe de Nikolai Sverchkov (Evil Martians) de la sección Backend, se consolidó. No es de extrañar que fui a la conferencia :)

CI para los pobres, o vale la pena escribir su propio CI para web studio

Mikhail Radionov, jefe del estudio web de Flag de Ekaterimburgo, habló sobre el CI / CD auto-escrito.

Su estudio pasó de un "CI / CD manual" (conectado al servidor a través de SSH, git pull, repite 100 veces al día) a Jenkins y a una herramienta autoescrita que le permite controlar el código y ejecutar lanzamientos llamados Pullkins.

¿Por qué no trabajó Jenkins? No ofrecía suficiente flexibilidad por defecto y era demasiado complicado para la personalización.

La "bandera" se está desarrollando en Laravel (marco PHP). Al desarrollar el servidor CI / CD, Michael y sus colegas utilizaron los mecanismos incorporados de Laravel llamados Telescope and Envoy. El resultado es un servidor php (preste atención) que procesa las solicitudes entrantes de webhook, capaz de ensamblar el frontend, el backend, implementar en diferentes servidores e informar a Slack.

Además, para la capacidad de realizar despliegues azul / verde, para tener configuraciones uniformes en entornos dev-stage-prod, cambiaron a Docker. Las ventajas siguen siendo las mismas, se agregaron las posibilidades de homogeneizar el entorno y la implementación sin problemas, y se agregó la necesidad de aprender Docker para que funcione correctamente.

El proyecto está en Github.

Cómo redujimos la cantidad de reversiones de lanzamientos de servidores en un 99%

El último informe en la sección Devops fue de Victor Eremchenko, ingeniero jefe de Devops en Miro.com (anteriormente RealTimeBoard).

RealTimeBoard, el producto principal del equipo de Miro, se basa en una aplicación Java monolítica. Recopilarlo, probarlo y desplegarlo sin tiempo de inactividad es una tarea difícil. Al mismo tiempo, es importante implementar tal versión del código para que no tenga que revertirse (un monolito pesado).

En el camino para construir un sistema que permita esto, Miro hizo un largo camino, incluido el trabajo en la arquitectura, las herramientas utilizadas (Atlassian Bamboo, Ansible, etc.) y el trabajo en la construcción de equipos (ahora tienen un comando Devops dedicado + muchos comandos Scrum separados de desarrolladores de diferentes perfiles).

El camino resultó ser difícil y espinoso, y Víctor compartió sus decisiones, el dolor acumulado y el optimismo que no terminó allí.


Ganó un libro para preguntas

Sección de backend

Tuve 2 informes: de Nikolai Sverchkov (Evil Martians), también sobre Serverless, y de Grigory Koshelev (compañía de Kontur) sobre telemetría.

Sin servidor para simples mortales

Si Ruslan Sirkin habló sobre qué es Serverless, Nikolai mostró aplicaciones simples usando Serverless, y habló sobre los detalles que afectan el costo y la velocidad de las aplicaciones en AWS Lambda.

Un detalle interesante: el artículo mínimo pagado es de 128 Mb de memoria y 100 ms de CPU, cuesta $ 0.000000208. Además, 1 millón de tales solicitudes por mes es gratis.

Algunas de las funciones de Nikolai a menudo excedían el límite de 100 ms (la aplicación principal estaba escrita en Ruby), por lo que reescribirlas en Go proporcionó excelentes ahorros.

Vostok Hercules - ¡haz que la telemetría sea grandiosa de nuevo!

El último informe de la sección Backend de Grigory Koshelev (empresa Kontur) sobre telemetría. La telemetría es registros, métricas, seguimientos de aplicaciones.

Contour utiliza sus propias herramientas escritas publicadas en Github para esto. La herramienta de informes, Hercules, github.com/vostok/hercules , se utiliza para entregar datos de telemetría.

Un informe de Vladimir Lila en la sección Devops analizó el almacenamiento y el procesamiento de registros en Elasticsearch, pero aún queda la tarea de entregar registros de miles de dispositivos y aplicaciones, y herramientas como Vostok Hercules los resuelven.

El circuito siguió el camino conocido por muchos, desde RabbitMQ hasta Apache Kafka, pero no tan simple)) Tuvieron que agregar Zookeeper, Cassandra y Graphite al esquema. No divulgaré completamente la información de este informe (no mi perfil), si está interesado, puede esperar las diapositivas y el video en el sitio web de la conferencia.

¿Cómo se compara con otras conferencias?

No puedo compararlo con conferencias en Moscú y San Petersburgo, puedo compararlo con otros eventos en los Urales y con el 404fest en Samara.

DUMP se lleva a cabo en 8 secciones, este es un récord para las conferencias de los Urales. Secciones muy grandes de Ciencia y Administración, esto también es inusual. La audiencia en Ekaterimburgo está bastante estructurada: la ciudad tiene grandes departamentos de desarrollo Yandex, Kontur, Tinkoff, esto deja su huella en los informes.

Otro punto interesante es que muchas compañías tienen inmediatamente 3-4 oradores en la conferencia (este fue el caso con Kontur, Evil Martians, Tinkoff). Muchos de ellos fueron patrocinadores, pero los informes están bastante a la par con otros; estos no son informes publicitarios.

¿Ir o no ir? Si vives en o cerca de los Urales, tienes la oportunidad y temas interesantes, sí, por supuesto. Si piensa en un viaje largo, miraría los temas de los informes y los informes en video de años anteriores www.youtube.com/user/videoitpeople/videos y tomaría una decisión.
Otra ventaja de las conferencias en las regiones, por regla general, es fácil comunicarse con el orador después de los informes, hay menos solicitantes para dicha comunicación.



Gracias a Dump y Ekaterimburgo! )