Del 29 al 30 de octubre, San Petersburgo organizará DevOops 2019, una conferencia dedicada a las soluciones de ingeniería de DevOps. Los temas principales son las nubes en general, y Cloud Native en particular, observabilidad, monitoreo y auditoría, CI / CD, seguridad, etc., en general, todo lo que puede esperar de una conferencia dedicada específicamente a devops.
Esta publicación central es una revisión del programa DevOops, que escribimos junto con el comité del programa de la conferencia.
En resumen:
- Anton Weiss hablará sobre mallas de servicio;
- Burr Sutter y Oleg Nenashev - sobre CI / CD;
- Dmitry Stolyarov y Sergey Fedorov - sobre monitoreo;
- Hay una gran sección sobre nubes y Kubernetes: Mete Atamel, Jessica Deen, Victor Gamov, Ivan Glushkov ...
El programa es amplio, con un total de 30 informes.
Las conferencias magistrales están dirigidas por Tim Lister (coautor de Peopleware), Hadi Hariri (jefe de Developer Advocacy en JetBrains) y Roman Shaposhnik (miembro de la junta directiva de Apache Software Foundation y Linux Foundation LF Edge ).
Debajo del corte, hablaremos sobre lo que está sucediendo en el mundo de los devops, dividiremos los eventos en grupos y veremos cómo encaja todo en un programa de 30 informes.
Estudio de caso
El primer grupo de informes es Estudio de caso. Recientemente, la situación en el mundo se ha desarrollado rápidamente, por ejemplo, la guerra de GitLab continúa con todos: GitLab lo tiene todo, y lo venderán como un solo producto (como se afirma en un artículo escandaloso del CEO de The Register, Sid Sijbrandij).
Sin embargo, no todo es tan color de rosa, y Nikita Sobolev solo quiere decir cómo se mudaron de GitLab a GitHub y por qué. En resumen, GitHub también tenía todo, aunque en la vista previa, pero las mismas acciones funcionan, el registro de paquetes funciona, la seguridad también funciona, etc. Por otro lado, las acciones aún continúan bombeando todo el repositorio, independientemente de la solicitud de extracción que esté probando en qué rama. Sí, al final subirás a Jenkins, porque la vida es dura y llena de horrores, pero al menos ya puedes armar la imagen del acoplador, y la mayoría de ellos serán suficientes para empezar. Este fue un ejemplo de la categoría Estudio de caso, pero hubo varios informes en general:
NB: Baruch Sadogursky continúa haciendo presentaciones sobre cada nuevo DevOops. ¿Golpeará la cima de nuevo? Hacemos apuestas.
Servicio de malla
En los informes de la categoría Service Mesh, exploramos formas de resolver el problema de la creciente complejidad. Somos geniales, pensamos en dividir los monolitos en microservicios, pero en lugar de resolver finalmente el problema, nos enfrentamos con la increíble complejidad del mundo de los microservicios. Las mallas se inventaron para reducir la complejidad, pero al final ... lo que sucedió, lo que sucedió. Algo me dice que no ha sido más fácil con las mallas, pero este es un tema para una gran conversación por separado.
Ahora puede encontrar más y más artículos e informes sobre el tema: pero dejemos de codificar con micro-hard y regresemos a los monolitos habituales. De hecho, tan pronto como quedó claro que los microservicios reducen la complejidad en la arquitectura, pero aumentan la carga de los administradores, la gente vino y dijo: "Oh, ¿tal vez esto no siempre es necesario"? Esta tesis no ha desaparecido, no siempre es necesaria. Por ejemplo, si su sistema necesita integrarse con algo grande y externo, con algún tipo de base de datos gruesa, entonces el número de problemas resueltos por microservicios es menor que los problemas creados: todo el estado pasará por esta base de datos y los microservicios ya no son micro, porque no pueden vivir el uno sin el otro. Incluso tenemos tales amantes de los monolitos en el programa, por ejemplo, Alex Thissen con el informe "Marcar sus características" habla sobre el hecho de que puede tomar una aplicación monolítica, cubrirla con banderas de características y luego siempre pasar del asistente.
¿Pero quién peleará con mallas de servicio? ¡Pregunta a nuestros oradores!
CI / CD
¡El viejo Jenkins se puede ejecutar sin Jenkins! Puedes correr en Travis, en cualquier lugar, ¿cómo te gusta esto, Elon Musk? (Esto es bastante serio ahora). En general, dado que Kubernetes está ahora en todas partes, todas nuestras herramientas de CI / CD se adaptan a este hecho, Kubernetes necesita soporte. Es por eso que obtuvimos JenkinsX, por lo que aparecen nuevos chips en TeamCity, es por eso que GitHubs y GitLabs implementan sus CI: todos necesitan Kubernetes.
La aparición de Kubernetes ha cambiado el enfoque de CD. A medida que los CD son más fáciles, comenzaron a aparecer nuevas variaciones sobre lo divertido que es implementar implementaciones canarias, implementaciones azul-verdes, etc., un montón de abstracciones listas para usar que puede usar y disfrutar de la vida. Un ejemplo de un CI / CD basado en los principios de Cloud Native es Tekton . Todavía no tenemos nada sobre Tekton (excepto que se menciona en los informes de Oleg Nenashev y Burr Sutter ), pero en la primavera trataremos de hacerlo. JenkinsX es exactamente el mismo chip, creado sobre la base de proyectos de Cloud Native para Cloud Native. Si alguien está interesado en lo que es este Cloud Native, vale la pena leer acerca de las aplicaciones de 12 factores , esto es todo. Como Kelsey recientemente bromeó:
Informes de categoría de CI / CD:
Monitoreo
En el mundo del monitoreo, todo es mucho menos tormentoso, pero hay preguntas fundamentales. Por ejemplo, a menudo se dice que nadie ha aprendido a monitorear monolitos. Parece que el problema no es eso, después de todo no hay mucho que aprender. El problema es que la mayoría de los monolitos son heredados, y atormentar el monitoreo a las aplicaciones existentes es una molestia. Si te dicen ahora: escribe un monolito de tal manera que sea conveniente monitorearlo, es hora de escupir: tomas todo lo que amamos, comenzando por registros y métricas y terminando con el rastreo, escribes todo maravillosamente allí y obtienes una total observabilidad.
El problema es que hoy estamos hablando de atornillar la supervisión a los monolitos grandes existentes, y esto es bastante no trivial. Y cuando todo funciona, tienes que vivir de alguna manera con el Frankenstein resultante. Por lo tanto, tenemos un informe de Dmitry Stolyarov sobre la cultura de guardia , no es muy técnico, pero recuerda, ¡devops no se trata solo de herramientas! Philipp Krenn le dirá que al escalar, comenzamos a perder eventos y, en general, esto es normal, pero aquí los auditores se acercan a nosotros y nos dicen: ¡queremos ver eventos individuales! Cómo casar la escala y la auditoría no está claro, es un problema desagradable.
En general, aún no hemos aprendido a fijar el monitoreo a los monolitos, y los microservicios se han acumulado además del trabajo. Microservicios y Cloud Native nos hicieron tener una visión completamente diferente de la observabilidad, porque entendemos que los métodos antiguos como el registro tonto, en el que seguimos haciendo cat, dejan de funcionar. Recientemente, una broma se deslizó en algún lugar en Twitter: "Si pega la identificación en cinco herramientas diferentes y luego las busca con esta identificación, entonces usted mismo es una herramienta de observación". En las arquitecturas de microservicios que se mueven hacia un modelo reactivo, la observabilidad se basa en los eventos con los que se transfieren internamente. Y si se trata de una orquestación, entonces no hay eventos y hay que desmontar los registros de una manera diferente. El mundo se ha vuelto varias veces más difícil de observar, y no todos han aprendido a observarlo.
Informes de la sección de monitoreo:
Nube
La nube es el tema más grande y voluminoso. Alguna vez se creyó que las nubes públicas son "nuestro todo". Entonces resultó que no todos. ¡Entonces resultó que tampoco era nuestro! Aparecieron muchos amantes de las nubes privadas, surgieron nubes híbridas. No comenzó este año, pero mucho antes. Ahora una de las preguntas principales es cómo combinar todo esto. Por ejemplo, cómo VMWare se combina con AWS, porque VMWare llegó a Azure y también a AWS , y esto ya es una gran noticia durante todo el año.
Por supuesto, en todas partes, en la mayoría de los informes (no solo en la sección de la Nube), Kubernetes se menciona de una forma u otra. Se infiltró en todas partes y alguien incluso comienza a esperar: ¿cuándo aparecerá el asesino de Kubernetes? Hasta ahora, esto no es visible. Hace un par de años, la pregunta principal era: cómo vivir con esta cosa compleja e incomprensible, pero ahora todos ya están acostumbrados a un vecino malvado y han aprendido a negociar. Operadores? Knative? Kotlin DSL?
Este nuevo mundo audaz es tan grande y diverso que no tiene sentido enumerar todo aquí, solo eche un vistazo a esta lista de informes:
Notas clave
También tenemos tres notas clave. Ocupan la sala más grande disponible, no hay otros informes en paralelo con ellos, y están diseñados para una amplia audiencia, están dirigidos por sus oradores más famosos.
La conferencia comienza con Timothy Lister, coautor de Peopleware, Waltzing with the Bears, adictos a la adrenalina y zombies de plantilla. Todos estos libros son clásicos en su campo y están escritos con colegas de Atlantic Systems Guild . En el informe "Personajes, comunidad y cultura: factores importantes para la prosperidad", Tim hablará sobre las mejores prácticas para las organizaciones, la cultura laboral, los aspectos útiles y perjudiciales de trabajar en una empresa. En general, sobre lo que ha estado hablando durante décadas, pero actualizado a las realidades de 2019. Si los detalles son interesantes, recientemente hicimos una gran entrevista con él para Habr . ¿Escriben un libro nuevo? Sí, lo hacen, leen la entrevista.
El primer día termina con Hadi Hariri, el legendario líder del equipo Developer Advocacy de JetBrains, desarrollador de código abierto y conferencista durante más de 15 años. En su informe Eliminar las barreras, sugiere reflexionar sobre la pregunta: ¿qué pasa si todas las barreras y problemas habituales han desaparecido, qué sigue? ¿Esto realmente conduce a una mayor productividad y una solución garantizada a los problemas? Resulta que no todo es tan simple, y la ausencia de barreras es en sí mismo un tema digno de discusión.
Y finalmente, la conferencia termina con Roman Shaposhnik, miembro de la junta directiva de Apache Software Foundation y Linux Foundation LF Edge , que personalmente intervino en el kernel de Linux, Hadoop, ffmpeg y otros proyectos populares. Su discurso principal "Por qué la industria de TI está pasando por tiempos oscuros, cómo es culpable de DevOps y por qué Capital puede ayudar" tratará de responder varias preguntas filosóficas sobre el surgimiento de plataformas multimedia en la nube, plataformas de código abierto (Kubernetes y Cloud Foundry), Edge Computación y demás.
Que sigue
El programa completo de la conferencia se publica en el sitio , hay descripciones detalladas en todas partes, los comentarios del comité del programa están en todas partes y etiquetas como #kubernetes le permiten navegar por el contenido sin tener que ir al boletín de calificaciones.
Le recordamos que DevOops 2019 se llevará a cabo del 29 al 30 de octubre en San Petersburgo, los boletos se pueden comprar en el sitio web oficial de la conferencia . Puede conocer todas las noticias importantes, ya sea desde nuestro blog en Habré o suscribiéndose a la lista de correo en la página principal .