El participante llega al curso o intensivo. Ve filas ordenadas de soporte técnico, cables de alimentación cuidadosamente instalados, la disposición ordenada del aula, imágenes vibrantes y esquemas en las diapositivas. Los ponentes, con bromas y sonrisas, presentan la información de tal manera que uno solo puede intentar entender. Los stands están configurados, las tareas prácticas fluyen rápidamente de los dedos, aunque a veces se necesita la ayuda del soporte técnico.
Y también hay pausas para café con personas afines, una atmósfera animada y dinámica, intercambio de experiencias, las preguntas más inesperadas para los ponentes. Y las respuestas son información que no encontrarás en los manuales, sino solo en la práctica.
¿Cuánto tiempo, esfuerzo y nervios creen que se necesitaron para que esto se vea así?
Gracias a Volodia Gurianov, administrador certificado de Kubernetes e ingeniero/líder de equipo en Southbridge, quien desde el principio fue testigo y participante activo en la creación de muchos cursos de Slyom.
Él vio el trasfondo de la creación de los cursos: las dificultades y los tropezones, los insights y las soluciones inesperadas. Y los intensivos ya habituales sobre Kubernetes, como Slyom Básico y Slyom Mega. Y el nuevo curso, en gran medida reestructurado. , que se aproxima inexorablemente y comenzará el 19 de agosto.
Pero, supongo que es suficiente de lírica; pasemos a la historia en sí. Cómo de un par de temas del intensivo se transformó gradualmente en un curso completamente autosuficiente y multifacético. . Así que comenzaré a contar cómo se crean y desarrollan los cursos — como si fuera "Hace mucho tiempo en una galaxia muy, muy lejana…".
¿Y qué hay detrás de escena?
Si preguntas cómo hacemos los cursos y por dónde todo comienza, responderé simplemente: "Todo comienza con una idea".
Normalmente, la idea llega de algún lugar; no estamos sentados, encadenados en un sótano, esperando a pensar: «¿Sobre qué tema debemos hacer un curso?». Las ideas llegan solas de fuentes externas. A veces, la gente comienza a preguntar activamente: «¿Qué saben sobre esta tecnología específica?». O como pasó con Docker, que no se podía incluir en el cronograma del intensivo — claramente había que llevarlo afuera para poder contar algo dentro del intensivo.
Así es como surge la idea.
Después de que se presenta, comienza, en mi opinión, el momento más complicado — entender qué incluir en este curso — esto es muy comparable a cómo se preparan los ponentes para diversas conferencias.
Hay un problema principal cuando eliges un tema y piensas: "¿Qué tengo que contar sobre esto? Esto es demasiado simple, esto es obvio, esto también lo sabe todo el mundo".
Pero en realidad no es así en absoluto. Y personalmente he comentado en muchos lugares que lo que te parece obvio a ti, para quienes vendrán a escucharte o a tomar el curso, no es obvio en absoluto. Aquí hay una gran cantidad de trabajo y un conflicto interno sobre qué incluir en el curso. Como resultado, obtienes una lista de capítulos delineados con grandes pinceladas sobre de qué se tratará el curso.
Luego comienza el trabajo rutinario simple:
- Selección de material
- Leer atentamente la documentación de la versión actual, ya que el mundo de TI ahora avanza a velocidades cósmicas. Incluso si trabajas con algo y haces un curso sobre eso, te ves obligado a revisar la documentación y ver qué hay de nuevo, sobre qué es interesante hablar, sobre qué puede ser especialmente útil mencionar.
- Y aparece un esqueleto del curso, donde ya hay una gran parte de los temas, en general, detallada y parece que solo tienes que grabar los videos y lanzarlos a producción.
- Pero en realidad no es así, luego comienza el trabajo duro, pero ya no para los autores del curso, sino para quienes hacen las pruebas. Por lo general, nuestro soporte técnico actúa como testers alfa, quienes, en primer lugar, revisan los cursos en busca de errores sintácticos y gramaticales. En segundo lugar, nos golpean fuerte con palos y se quejan cuando hay lugares que son totalmente no obvios y confusos. Cuando surgen en los textos oraciones complicadas o tonterías evidentes. Ellos revisan todo esto y están atentos.
- Luego comienza la etapa de pruebas prácticas, donde también se detectan cosas evidentes que no funcionan y se muestran momentos que se pueden simplificar, ya que se vuelve poco interesante simplemente sentarse a copiar, y se identifican lugares donde exigimos mucho de las personas que tomarán este curso. Y entonces llegan las recomendaciones: "Hagan esto, chicos, más simple, será más fácil de entender y habrá más beneficio de ello".
- Una vez que se ha completado este volumen de trabajo, se ha escrito aquella parte que se relaciona con el video; aparentemente, todo está bien. Ya se puede proceder con el lanzamiento y la promoción de este curso. Sin embargo, no es tan sencillo; es prematuro — ya que últimamente hemos dejado de confiar un poco en nosotros mismos y hemos comenzado a trabajar más con la retroalimentación. Apareció el concepto de beta-testing: se invita a personas externas, que no están relacionadas con nuestra empresa, a mostrarles todas las partes del curso, videos, textos, tareas prácticas, para que evalúen la calidad del material, su accesibilidad y nos ayuden a hacer que el curso sea lo mejor posible.
- Y cuando pasan varias iteraciones como estas, con ponentes, pruebas alfa a través del soporte técnico, beta-testing y mejoras, todo comienza de nuevo — soporte técnico, beta-testing, mejoras.
- Y en un momento determinado se llega a la comprensión de que, o bien dejamos de hacer mejoras, porque hacer algo que le guste a todos es completamente irreal, o se toman decisiones drásticas. Cuando muchos comentarios sobre ciertas secciones son críticos — hay que rehacerlas a gran escala porque algo salió mal.
- Luego llega el tiempo de los ajustes menores: en algún lugar una frase no está bien formulada, en otro lugar a alguien no le gusta la fuente 14,5, y quisiera 15,7.
- Cuando quedan comentarios de este tipo, el curso se abre más o menos, y comienzan las ventas oficiales.
Y a primera vista, la tarea de hacer un curso corta y simple resulta ser todo menos simple y toma un tiempo increíble.
Y hay otro punto importante: el trabajo con el curso no termina cuando se publica el curso. En primer lugar, leemos con atención los comentarios que se dejan sobre las distintas partes. Y a pesar de todos los esfuerzos que hemos realizado, aún se identifican algunos defectos, errores que se corrigen y mejoran en tiempo real, para que cada usuario posterior reciba un servicio de mayor calidad.
Cada curso cuenta con su propio product owner, quien no solo define el concepto general y verifica los tiempos, sino que también hace anotaciones al margen para cuando llegue el momento de reescribir el curso por completo, lo que definitivamente sucederá, porque dentro de dos años, o incluso uno, parte de lo que estamos enseñando se volverá obsoleto simplemente porque moralmente quedará anticuado. El product owner toma notas sobre las preguntas más comunes, qué aspectos no fueron claros, qué tareas parecieron muy difíciles y cuáles, por el contrario, parecieron muy sencillas. Todo esto se toma en cuenta al regrabar el curso, en cualquier refactorización, para que cada iteración global del curso sea mejor, más accesible y cómoda.
Así es como surgen los cursos.
Cómo nació el curso de Docker
Este es un tema aparte, incluso inusual para nosotros. Porque, por un lado, no planeábamos hacerlo, ya que muchas escuelas en línea lo ofrecen. Y, por otro lado, él mismo pidió salir a la luz y encontró un lugar lógico en nuestra concepción de la formación de especialistas en TI en Kubernetes.
Hablando de manera general, todo comenzó con el curso de Kubernetes, cuando recién empezaron, creo que después del primer Sлёрм. Recopilamos retroalimentación y vimos que mucha gente quería leer algo adicional sobre Docker y, en general, muchos llegan al curso básico de Kubernetes sin saber qué es. .
Por eso, para el segundo Sлёрм, hicimos un curso, o más bien, no un curso, sino que creamos un par de capítulos sobre Docker. Donde explicamos las cosas más básicas, para que las personas que asisten al intensivo no se sientan excluidas y entiendan qué está sucediendo.
Y luego los eventos se desarrollaron de la siguiente manera. La cantidad de material creció y no cabía en 3 días. Y surgió una idea lógica y obvia: ¿por qué no crear un pequeño curso a partir de lo que enseñamos en Sлёрм Básico, al que podríamos enviar a las personas que quieren ver algo sobre Docker antes del intensivo de Kubernetes?
Sлёрм Junior es, de hecho, una combinación de varios cursos básicos. Al final, el curso de Docker se convirtió en una parte de Sлёрм Junior. Es decir, es un nivel cero antes de y . Y luego, ahí había abstracciones muy básicas.
En algún momento, la gente comenzó a preguntar: "Chicos, esto es genial, es suficiente para entender lo que están explicando en los intensivos. ¿Dónde puedo leer más sobre lo que puede hacer Docker, cómo trabajar con él y qué es exactamente?". Así surgió la idea de crear un curso completo sobre , para que, por un lado, se pudiera enviar a las personas que llegan a Slurm por Kubernetes, y por otro lado, para aquellos a quienes incluso no les interesa en esta etapa el desarrollo de Kubernetes. Para que un especialista en TI pueda venir, ver nuestro curso sobre Docker y comenzar su camino evolutivo simplemente con Docker puro. Para que tengamos un curso terminado y completo; y muchos después de mirar este curso, tras trabajar un tiempo con Docker puro, hayan crecido hasta el nivel en que ya necesitan Kubernetes o algún otro sistema de orquestación. Y vinieron, en particular, a nosotros.
A veces surge la pregunta: "¿A qué personas no les puede ser útil Kubernetes en este momento?" Pero esta pregunta no se trata de las personas, más bien es sobre las empresas. Aquí hay que entender que Kubernetes tiene casos específicos en los que es adecuado y tareas que resuelve bien, y, por el contrario, hay escenarios de uso de Kubernetes que causan más problemas y sufrimientos. Por lo tanto, no se trata de las personas, sino de lo que y cómo desarrollan las empresas.
Por ejemplo, un horroroso monolito Legacy — probablemente no valga la pena forzarlo a Kubernetes, porque eso causaría más problemas que beneficios. O, por ejemplo, si es un pequeño proyecto — tiene bajas cargas o, en general, no tiene mucho dinero y recursos. Entonces no tiene sentido llevarlo a Kubernetes.
Y en general, probablemente, como ya muchos han dicho, si te preguntas: "¿Necesito Kubernetes?", lo más probable es que no lo necesites. No recuerdo quién fue el primero en decir esto, creo que fue Pasha Selivanov. Estoy 100% de acuerdo. Y hay que crecer hasta Kubernetes, y cuando ya aparece la comprensión de que realmente necesito Kubernetes y que a nuestra empresa le es necesario, que ayudará a resolver ciertos problemas, entonces probablemente tenga sentido ir a aprender y entender cómo configurarlo bien, para que el proceso de transición a Kubernetes no sea demasiado doloroso.
Ciertas dolencias infantiles y algunas cosas simples, e incluso no tan simples, se pueden conocer, en particular, con nosotros, en lugar de pasar por tropiezos y dolores propios.
Muchas empresas han recorrido el camino de tener inicialmente alguna infraestructura simple sin contenedorización. Luego, cuando se volvió difícil administrar todo, pasaron a usar Docker, y en algún momento llegaron a un estado en el que dentro de Docker y lo que ofrece se hacía estrecho. Comenzaron a mirar alrededor, qué sistemas resuelven estos problemas y, en particular, Kubernetes es uno de esos sistemas que permiten abordar problemas cuando en Docker puro se vuelve limitado y se necesita funcionalidad adicional. Este es un buen caso de cómo las personas avanzan gradualmente desde abajo hacia arriba, comprenden que esta tecnología no es suficiente y evolucionan a un siguiente nivel. Usan algo, de nuevo se queda corto, y así avanzan.
Es una elección consciente, y eso es genial.
En general, veo que nuestro sistema se está organizando muy bien, por ejemplo, , incluso en formato de video. Luego, después de Docker, viene , luego , luego . Todo se organiza de manera lógica: la persona pasa por el proceso y obtiene una profesión completa.
En principio, el conjunto de cursos permite cubrir muchos casos, realmente modernos. Hay todavía áreas que permanecen como zonas grises, espero que pronto hagamos algún curso que aborde estas áreas grises, en particular, algo sobre seguridad. Porque esto se está volviendo muy relevante.
En resumen, hay ciertas áreas grises que sería muy bueno cerrar, para que realmente veamos un panorama completo, y las personas puedan venir y, al igual que Kubernetes, que se presenta como un constructor de Lego, se pueden armar diferentes cosas, y si todavía falta algo, se puede complementar; así también con nuestros cursos, para que las personas comprendan qué necesitan de esto, armando un rompecabezas, un constructor con nuestros cursos.
Si me hago la pregunta correcta y honesta: "¿A quién le será útil ahora un curso activo de Docker?", entonces:
- A los estudiantes que están comenzando a involucrarse.
- A los empleados del departamento de pruebas.
- De hecho, hay muchas empresas donde todavía no solo no utilizan Docker, sino que nadie ha oído hablar de esta tecnología y, en general, no saben cómo usarla. Y conozco varias grandes empresas en San Petersburgo que han estado trabajando en desarrollo durante muchos años y que siguen utilizando tecnologías antiguas. En particular, para estas empresas, para los ingenieros de estas compañías, este curso puede ser muy interesante, ya que, por un lado, permite sumergirse rápidamente en esta tecnología y, por otro lado, en cuanto haya varios ingenieros que comprendan cómo funciona todo, pueden llevarlo a la empresa y desarrollar esta cultura y estas direcciones dentro de la misma.
- En mi opinión, este curso también puede ser útil para aquellos que ya han trabajado con Docker, pero muy poco y más en el estilo de 'haz esto, haz aquello' — y ahora están buscando de alguna manera interactuar con Kubernetes, y eso les impone ciertas obligaciones. Si tienen conocimientos muy superficiales sobre qué es Docker, cómo ejecutarlo, pero no saben cómo funciona internamente, no saben qué es mejor hacer con él y qué es mejor evitar, entonces este curso será adecuado para sistematizar y profundizar sus conocimientos.
Pero si sus conocimientos están en el nivel de: 'No sé cómo escribir correctamente los Dockerfiles, tengo una idea de lo que son los namespaces, cómo funcionan los contenedores y cómo están realmente implementados a nivel de sistema operativo' — entonces no tiene sentido venir con nosotros, no aprenderán nada nuevo y se sentirán un poco decepcionados por el dinero y tiempo gastados.
Si tenemos que formular cuáles son las ventajas de nuestro curso, sería:
- hemos intentado estructurar este curso con suficientes casos prácticos que les permitirán no solo entender la parte teórica, sino también comprender por qué necesitan esto y cómo lo van a usar en el futuro;
- Hay varias secciones que rara vez se encuentran en otros lugares, y en general no hay tanto material sobre ellas. Se refieren a la interacción de Docker con el sistema operativo, de hecho, un poco diferente. ¿Qué mecanismos ha tomado Docker del sistema operativo para implementar el sistema de contenedorización? Esto proporciona una comprensión más profunda de toda la cuestión del lanzamiento de contenedores dentro del sistema operativo Linux. Cómo funciona, cómo interactúa entre sí dentro del sistema operativo, fuera de él y así sucesivamente.
Es una mirada bastante profunda que es bastante rara, y a mi parecer, es muy importante. Si realmente quiere entender bien cualquier tecnología y saber qué esperar de ella, debe tener al menos una idea general de cómo funciona a un nivel bajo.
Nuestro curso muestra y explica cómo está estructurado desde el punto de vista del sistema operativo. Por un lado, todos los sistemas de contenedorización utilizan los mismos mecanismos del sistema operativo. Por otro lado, toman lo que ya existe en el sistema operativo Linux, como Docker. Otros sistemas de contenedorización no han inventado nada nuevo; han tomado lo que ya existe en Linux y han escrito una simple envoltura que permite llamarlo rápidamente, ejecutarlo o interactuar con él de alguna manera. Docker, por ejemplo, no es una capa muy grande entre el sistema operativo y la línea de comandos; es una utilidad que permite no tener que escribir toneladas de comandos o algo de código en C para crear un contenedor, sino hacerlo introduciendo un par de líneas en el terminal.
Y, además, si hablamos específicamente de Docker, lo que realmente trajo al mundo de IT son los estándares. Cómo debe ejecutarse una aplicación, cómo debe funcionar, cuáles son los requisitos para los logs, cuáles son los requisitos para la escalabilidad y la configuración de la misma aplicación.
En gran medida, Docker se trata de estándares.
Los estándares también se trasladan a Kubernetes; allí están exactamente los mismos estándares. Si sabes ejecutar bien tu aplicación en Docker, es 99% probable que también funcione bien en Kubernetes.
Si te interesó no solo cómo se creó el curso de Docker y otros cursos, sino también el mismo curso desde un punto de vista práctico, entonces
¡Estaremos encantados de verte!
Fuente: habr.com
