DevOops 2019 a través de los ojos del desarrollador

Del 29 al 30 de octubre en San Petersburgo se celebró la conferencia DevOops . En este artículo, compartiré mis impresiones y puntos de vista, así como breves notas sobre los informes que escuché. Un pequeño descargo de responsabilidad: dado que soy desarrollador, algunos pensamientos y comentarios pueden estar sesgados en Dev que en Ops, pero intentaré ser lo más objetivo posible.

DevOops es uno de los eventos organizados por el Grupo JUG Ru . Y debo admitir que la organización y el nivel de los informes estaban a nivel. La conferencia duró dos días, en tres transmisiones. Además, hubo áreas de discusión para la comunicación con los oradores, talleres y charlas relámpago, presentaciones más fáciles y cortas, incluso para aquellos que no se han presentado previamente y quieren probarse como oradores.

Lienzo temático DevOops 2019 - nube nativa. La mayoría de los informes se dedicaron directa o indirectamente a las nubes. El tema no ha sido nuevo durante mucho tiempo, pero existen muchas dificultades obvias que surgen en el proceso de uso de tecnologías en la nube. Y muchos vinieron a propósito para encontrar respuestas. Esto fue especialmente notable en las sesiones de control de calidad después de las presentaciones. A los oradores se les hicieron preguntas prácticas que realmente entusiasman a la gente. Casi todas las preguntas fueron seguidas por los comentarios de otros participantes "¡Tenemos el mismo problema!" Y comenzó una animada discusión.

Primer dia

Personajes, comunidad y cultura: factores importantes para la prosperidad (Timothy Lister, The Atlantic Systems Guild Inc.)

La conferencia fue inaugurada por Timothy Lister, quien en 1987 (!) Escribió un libro sobre las prácticas de DevOps. Tim habló mucho sobre lo que distingue a un equipo fuerte y exitoso con una atmósfera saludable y agradable de un equipo mediocre y tóxico. Recuerdo especialmente el pensamiento:

"Una buena compañía está llena de personas que dicen" No sé ".

Se trata de apertura y confianza dentro del equipo. Una atmósfera de apertura es esencial si tienes un objetivo ambicioso. Para hacer esto, todos en el equipo deben sentirse cómodos y libres. Esto no significa que en caso de un problema, un miembro del equipo lo escala de inmediato a todos. Una atmósfera de apertura es importante y la capacidad en cualquier momento de recurrir a alguien específico (independientemente de su posición) o a todo el equipo y establecer claramente lo que se necesita mejorar o cambiar. Tal cultura forma un fondo tranquilo para el trabajo, cuando todos saben que si surgen preguntas serán escuchadas.

En mi experiencia, para una operación productiva y estable, este factor es de gran importancia. Después de todo, siempre habrá dudas, fricciones y un cambio de dirección. Y la atmósfera de apertura es una herramienta universal que le permite hacer frente a los desafíos personales y de equipo.

Otro pensamiento que me parece correcto: no hay una fórmula verdadera para construir una cultura en una empresa.

“Ninguna cultura puede llamarse ideal. Y ni una sola cultura puede llamarse un fracaso completo ".

Tendencia reciente: cada vez más conferencias incluyen informes sobre gestión, comunicación, trabajo en equipo y cultura. DevOops no fue la excepción. Creo que esta es una tendencia positiva, porque estos factores tienen un impacto aún mayor en el resultado final que las dificultades tecnológicas.

"El líder no administra el equipo, sino que lo hace crecer".

¡Hazlo en código (no en YAML)! Desbloquee el poder de Kotlin DSL para Kubernetes (Victor Gamow, Confluent y Fedor Korotkov, Cirrus Labs)

Informe semi-funeral, pero expresa completamente el dolor de escribir un sinfín de archivos YAML, su apoyo y (¡oh, horror!) Depuración en caso de error o error tipográfico. Esto incluso condujo a la aparición de puestos separados del ingeniero de YAML.

¿Cómo empezó todo? Érase una vez había guiones. Luego hubo más de ellos. Y mas Era necesario unificar, simplificar y escalar soluciones. Entonces, en el mundo DevOps, apareció el formato YAML y se convirtió en el estándar en muchas herramientas.

Los autores del informe pensaron y dijeron: "algo en el conservatorio está mal".

• No está claro cómo probar los archivos YAML.
• Es fácil cometer un error. Además, algunos errores son casi imposibles de atrapar y muy dolorosos de corregir. Por ejemplo, puede especificar fácilmente la versión de una dependencia como un número, en lugar de una cadena. Y luego descubra durante mucho tiempo por qué se utiliza la versión incorrecta, que se indica en la configuración. Y se trata de fundición de tipo y redondeo.
• Si el error es sintáctico, se detectará lo suficientemente rápido en CI. Pero esto no es exacto.

Lo más destacado del informe fue la carga de una configuración no válida en Kubernetes, a lo que respondió con calma: demasiados errores .

Victor y Fedor ofrecen escribir configuraciones en Kotlin DSL, lo que ayuda a hacer frente a todos estos problemas. Sí, la solución es interesante y conveniente, pero no es universal y funciona solo para k8s. Además, en caso de actualizar la API, también debe actualizar la biblioteca.

Tuberías y vainas: DevOps con Kubernetes (Burr Sutter, Red Hat)

Un informe ligero sobre el concepto general y los componentes principales de Kubernetes, así como otras herramientas y prácticas de Ops de moda. Para un principiante en el tema, lo que se necesita. Encajaría perfectamente en el programa de la conferencia para desarrolladores, pero era extraño escuchar un informe de este nivel en una conferencia especializada en DevOps. Sin embargo, la revisión resultó ser buena, simple y clara.

Pero formar JSON a partir de código Java usando StringBuilder es de alguna manera demasiado. Incluso teniendo en cuenta que este es un proyecto de demostración.

Patrones y antipatrones de actualizaciones continuas en la práctica de DevOps (Baruch Sadogursky, JFrog)

En el informe de Baruch, es difícil destacar una idea u orientación. Más bien, es una colección de experiencias personales, historias de vida, ejemplos de "cómo hacer el bien y qué tan mal", cuentos, otros trucos y "fakapchikov".

Especialmente de este informe, recordé la historia cuando, debido a un error en el proceso de implementación, Knight Capital Group perdió $ 440,000,000 en 45 minutos y se declaró en quiebra.

Al final, Baruch contó una historia sobre un error en el software Airbus A350. Debido a este error, las aerolíneas se vieron obligadas a reiniciar el avión cada 149 horas, y para esto tuvo que ser plantado en el suelo. Y si alguien se olvida de hacer esto, el avión se congelará. Un error tan desagradable. El problema es simple: se produce un desbordamiento en el código. Arreglar también es simple. Pero supongamos que todavía se olvidaron de reiniciar el avión, despegó en un vuelo de Los Ángeles → Londres y 3 horas antes del aterrizaje, los pilotos se dieron cuenta de que en una hora el avión se congelaría. "Houston, tenemos un problema". "¡Ahora lo arreglamos!" Los despachadores respondieron, reunieron a los programadores de AirBus, lo arreglaron, todo funciona. ¿Qué hacer a continuación? ¿Desplegar una nueva versión en un avión por aire? ¿O no correr riesgos? Baruch estaba determinado: “Despliegue. No será peor ".

Segundo dia

CDK e infraestructura como código (Sergey Kurson, AWS)

Sergey habló sobre AWS CDK (Cloud Development Kit). Este es un conjunto de bibliotecas que le permite administrar su infraestructura de código. La decisión es controvertida, ya que la gestión de la infraestructura en un estilo imperativo es una especie de retroceso. Todas las herramientas de automatización modernas le permiten describir la infraestructura en un estilo declarativo (es decir, el estado que debería resultar). Sin embargo, hay ventajas en este enfoque. Por ejemplo, el proceso de prueba de la infraestructura implementada se simplifica enormemente, y el proceso de implementar y decidir qué y cómo implementar se vuelve mucho más flexible. Además, existen grandes oportunidades para una gestión de infraestructura dinámica y extremadamente flexible por eventos, atributos o métricas.

¿Por qué necesitamos un tamiz de servicio? (Anton Weiss, software de Otomato)

Quizás uno de los mejores y más profundos informes de esta conferencia. Por "tamiz de servicio", un orador significa una malla de Servicio, una capa separada de infraestructura de nube que controla la comunicación de servicios entre ellos. El patrón de malla de servicios delega muchas tareas desde el nivel de servicio (es decir, desde el desarrollador de la aplicación) hasta el nivel de tamiz de servicio (en DevOps):

• gestión de seguridad;
• monitoreo de tráfico;
• gestión del tráfico

Aunque el servicio de malla como tecnología existe desde hace varios años, el autor hizo un informe en profundidad sobre él y analizó la historia de su origen, cómo evolucionó y cómo se desarrollará en los próximos años.

El informe es especialmente útil para los desarrolladores, ya que las tareas que resuelve la malla del Servicio ahora se resuelven a menudo a nivel de servicio. Y esto lleva a los desarrolladores tiempo extra y hace que sea difícil concentrarse en resolver problemas comerciales.

Acelerar las solicitudes de Internet y dormir tranquilo (Sergey Fedorov, Netflix)

Sergey trabaja en Netflix para garantizar que el servicio funcione para los usuarios finales lo más rápido posible. Todas las solicitudes en él se dividen en dos grandes grupos:

• solicitudes en la nube (dinámica);
• Consultas CDN (estáticas).

En muchos casos, es necesario realizar solicitudes simultáneamente a las partes dinámicas y estáticas de la infraestructura. Pero tal esquema tiene una sobrecarga: debe establecer al menos dos conexiones, realizar TLS Handshake dos veces, etc.

Hubo la idea de que si realiza una solicitud solo a una infraestructura estática, instala un proxy inteligente y le confía que haga solicitudes dinámicas a la nube en su nombre, esto acelerará las solicitudes de los clientes. El equipo de Netflix ha implementado dicho esquema, realizado pruebas en usuarios reales. Sin embargo, quedó claro que no siempre funciona y no para todos, algunas solicitudes comienzan a procesarse peor.

Por lo tanto, el equipo decidió ir a otro lado. Se les ocurrió un esquema que permite a cada cliente decidir individualmente cómo es más rentable realizar solicitudes dinámicas: directamente desde el cliente o confiar la representación de esta solicitud a la parte estática de la infraestructura.

Este es un buen ejemplo de no tener que alejarse de los desafíos técnicos. Debe ser valiente y elegir una opción de compromiso si mejora el producto y la vida de los usuarios es más fácil.

Por qué la industria de TI está pasando por tiempos oscuros, cómo es culpa de DevOps y por qué Capital puede ayudar (Roman Shaposhnik, ZEDEDA Inc.)

El informe más "visionario" de esta conferencia. En él, Roman habló mucho sobre cómo las tecnologías (y el capital) están interconectadas (e inseparables). Creo que esta tesis es muy importante para los ingenieros y para comprender que las tecnologías se crean para resolver problemas específicos de personas y empresas. Con tal pensamiento, se vuelve más fácil priorizar tareas y comprender qué es importante y qué no. Roman también habló sobre por qué las políticas cerradas y las corporaciones, que aumentan cada vez más su influencia, pueden conducir a una crisis global en la industria de TI. Además de un todo sobre la historia y la filosofía del campo de la tecnología de la información.

DevOops es sobre desarrollo

Varios oradores preguntaron a la audiencia quién está involucrado en la operación y la infraestructura, y quién se está desarrollando. Los resultados me sorprendieron: la distribución es de aproximadamente 50 a 50. Es genial que cada vez más desarrolladores quieran entender qué sucede con su código después de que se escriben, cómo se implementan las aplicaciones y cómo se comunican entre sí. Con esta comprensión, al escribir código, inmediatamente piensa en cómo funcionará en las condiciones de vida y dónde puede colocar pajillas.