O participante chega ao curso ou intensivo. Vê fileiras bem organizadas de suporte técnico, cabos de força organizados, a disposição ordenada do auditório, imagens vibrantes e diagramas nos slides. Os palestrantes apresentam as informações com piadas e sorrisos, de forma que é só acompanhar. Os estandes estão configurados, as tarefas práticas fluem das mãos, apenas às vezes é necessário o apoio do suporte técnico.
E ainda há os coffee breaks com pessoas que pensam como você, uma atmosfera animada e dinâmica, troca de experiências e as perguntas mais inesperadas aos palestrantes. E as respostas e informações que você não encontrará nos manuais, mas apenas na prática.
Quanto tempo, esforço e nervos foram necessários para que tudo parecesse exatamente assim?
Agradeço ao Volodya Guryanov, administrador certificado de Kubernetes e engenheiro/líder de equipe na Southbridge, que desde o início foi testemunha e participante ativo da criação de muitos cursos do Slyorm.
Ele viu os bastidores da criação dos cursos — as dificuldades e armadilhas, os insights e soluções inesperadas. E dos já conhecidos intensivos sobre Kubernetes, como Slyorm Básico e Slyorm Mega. E do novo curso, em grande parte reestruturado, que se aproxima implacavelmente e começará no dia 19 de agosto.
Mas, provavelmente, já chega de lirismos, vamos à história. Como de alguns tópicos do intensivo foi crescendo um curso bem autossuficiente e multifacetado, Então começarei a história de como os cursos são criados e desenvolvidos — é praticamente "Há muito tempo, em uma galáxia muito, muito distante…"
E o que há nos bastidores?
Se você perguntar como fazemos os cursos e de onde tudo começa, eu responderei simplesmente: "Tudo começa com uma ideia".
Normalmente, a ideia vem de algum lugar — não ficamos algemados em um porão até que pensemos: 'Qual tema devemos escolher para o curso?'. As ideias surgem de fontes externas. Às vezes, as pessoas começam a perguntar ativamente: 'O que você sabe sobre uma determinada tecnologia?'. Ou como aconteceu com o Docker, que não conseguia ser incluído no tempo do intensivo — era óbvio que precisava ser abordado separadamente, para que pudéssemos ensinar algo durante o intensivo.
É assim que a ideia aparece.
Depois que ela surge, começa, na minha opinião, o momento mais difícil — entender o que deve ser incluído nesse curso — isso é muito semelhante ao que os palestrantes precisam considerar para várias conferências.
Há uma dor principal quando você parece ter escolhido um tema e pensa: "E o que contar sobre isso? Isso é muito simples, isso é óbvio, todos já sabem".
Mas na verdade não é nada disso. E eu, pessoalmente, falo muito que o que parece óbvio para você, para aqueles que vem te ouvir ou fazer o curso, não é nada óbvio. E aqui surge uma grande quantidade de trabalho e conflito interior sobre o que incluir no curso. O resultado é uma lista de capítulos com grandes pinceladas do que será o curso.
A partir daí, começa o trabalho rotineiro simples:
- Seleção de materiais
- Leitura atenta da documentação da versão atual, já que o mundo de TI está se desenvolvendo a uma velocidade incrível. Mesmo que você esteja trabalhando em algo e faça um curso sobre isso, você precisa ir para a documentação e ver o que há de novo, sobre o que é interessante falar, sobre o que pode ser especialmente útil mencionar.
- E surge uma espécie de esqueleto do curso, onde já há uma grande parte dos tópicos, em geral, escrita e parece que é só gravar vídeos e colocar em produção.
- Mas na verdade não, começa o trabalho difícil, mas agora não para os autores do curso, e sim para aqueles que testam. Normalmente, temos a equipe de suporte técnico como testadores alfa, que, em primeiro lugar, revisam os cursos em busca de erros sintáticos e gramaticais. Em segundo lugar, nos dizem muitas verdades e reclamam quando há partes que são bem não óbvias e incompreensíveis. Quando surgem textos com orações subordinadas complexas de várias páginas ou um óbvio absurdo. Eles revisam tudo isso, ficam de olho.
- Depois, começa a fase de teste prático, onde também algumas coisas óbvias que não funcionam são captadas e mostradas algumas partes que podem ser ou, por outro lado, complicadas, pois isso se torna pouco interessante — apenas ficar copiando — e são identificados pontos onde temos expectativas muito altas dos alunos que farão o curso. Então surgem recomendações: "Façam, pessoal, aqui mais simples, será mais fácil de entender e haverá mais benefício disso".
- Depois que este volume de trabalho foi realizado e a parte relacionada ao vídeo foi escrita, parece que está tudo bem. Já podemos encaminhar para a liberação e a divulgação deste curso. Mas, novamente, não; é cedo — pois, ultimamente, começamos a desconfiar um pouco de nós mesmos e, de maneira geral, começamos a trabalhar mais com feedback. Apareceu algo como o beta testing — onde convidamos pessoas externas, não relacionadas à nossa empresa, e, em troca de alguns benefícios, mostramos todas as partes do curso, vídeos, textos, tarefas práticas, para que avaliem a qualidade do material, a acessibilidade do conteúdo e nos ajudem a tornar o curso o melhor possível.
- E quando várias dessas iterações acontecem, com os palestrantes, alfa testing através do suporte técnico, beta testing e ajustes. E então tudo começa de novo — suporte técnico, beta testing, ajustes.
- E em um certo momento, chega a compreensão de que ou paramos com os ajustes, porque agradar a todos é completamente irreal, ou tomamos algumas decisões radicais. Quando muitos dos comentários sobre certos aspectos são críticos — reescrevê-los de forma global, porque algo saiu errado.
- Depois chega o momento das correções menores — onde uma frase não está muito bem formulada, onde a alguém a fonte 14,5 não agrada, e prefere 15,7.
- Quando restam esse tipo de observações, então, o curso mais ou menos se abre, e começam as vendas oficiais.
E à primeira vista, a tarefa de criar um curso parece ser curta e simples, mas se revela bastante complexa e consome um tempo inacreditável.
E há outro ponto importante, que o trabalho com o curso não termina quando o curso é lançado. Primeiro, lemos atentamente os comentários deixados sobre determinadas partes. E mesmo com todo o esforço que aplicamos, ainda assim surgem algumas imperfeições, alguns erros que são corrigidos em tempo real, para que cada usuário subsequente receba um serviço de melhor qualidade.
Cada curso tem seu próprio product owner, que além de definir o conceito geral, verifica os prazos e faz anotações nas margens. Quando chegar o momento de reescrever completamente o curso — e esse momento certamente chegará, pois em dois anos, ou até em um ano, parte do que ensinamos se tornará irrelevante simplesmente porque estará moralmente ultrapassado. O product owner faz anotações sobre quais pontos as pessoas costumam questionar, quais tarefas parecem muito difíceis e quais parecem, ao contrário, muito fáceis. Tudo isso é considerado na regravação do curso, em alguma reformulação, para que cada iteração global do curso se torne melhor, mais conveniente e mais confortável.
É assim que surgem os cursos.
Como nasceu o curso de Docker
Este é um tema separado, e até incomum para nós. Porque, por um lado, não planejávamos fazer isso, já que muitas escolas online o oferecem. Mas, por outro lado, ele quis ser criado e encontrou um lugar lógico em nossa concepção de formação de especialistas em TI para Kubernetes.
Falando de forma muito ampla, tudo começou com o curso de Kubernetes, quando ele foi iniciado, se não me engano, após o primeiro Slurm. Coletamos feedbacks e percebemos que muitas pessoas queriam ler mais sobre Docker e, na verdade, muitos chegavam ao curso básico de Kubernetes sem saber o que era. .
Portanto, para o segundo Slurm, fizemos um curso — ou melhor, não exatamente um curso, mas criamos alguns capítulos sobre Docker. Onde explicamos algumas coisas mais básicas, para que as pessoas que participam do intensivo não se sentissem perdidas e entendessem o que estava acontecendo.
E então os eventos se desenrolaram mais ou menos assim. A quantidade de material cresceu e não cabia mais em 3 dias. E surgiu a ideia lógica e óbvia: por que não transformar o que estamos ensinando no Slurm Básico em um pequeno curso para o qual poderíamos enviar as pessoas que quisessem ver algo sobre Docker antes do intensivo de Kubernetes.
O Slurm Júnior é, na verdade, a união de vários desses cursos básicos. No final, o curso de Docker se tornou parte do Slurm Júnior. Ou seja, é um nível zero antes de e . E depois havia abstrações bem básicas.
Em algum momento, as pessoas começaram a perguntar: "Pessoal, isso é tudo ótimo, é suficiente para entender o que vocês falam nos intensivos. Mas onde posso ler mais sobre o que o Docker pode fazer, como usá-lo e o que exatamente ele é?" Assim, surgiu a ideia de criar um , para que, por um lado, pudéssemos enviar as pessoas que vêm para o Slurm sobre Kubernetes, e, por outro lado, para aqueles que, neste estágio de desenvolvimento, não estão interessados no Kubernetes. Para que um profissional de TI pudesse vir, ver nosso curso sobre Docker e começar seu caminho evolutivo simplesmente com o Docker puro. Para que tivéssemos um curso completo e finalizado — e muitos, depois de ver esse curso e trabalhar por algum tempo com o Docker puro, evoluíram para um nível em que já precisam do Kubernetes ou de outro sistema de orquestração. E vieram, em particular, até nós.
Às vezes, a pergunta surge: "Mas quais pessoas atualmente podem não precisar do Kubernetes?" Mas essa pergunta não é sobre pessoas, é mais sobre empresas. É preciso entender que o Kubernetes tem determinados casos em que ele se adapta bem e tarefas que ele resolve de forma eficaz, e, inversamente, há alguns cenários de uso do Kubernetes que acabam trazendo mais dor e sofrimento. Portanto, isso não depende das pessoas, mas do que e como as empresas desenvolvem.
Por exemplo, um terrível monólito legada — provavelmente, não vale a pena colocá-lo no Kubernetes, porque isso causaria mais problemas do que benefícios. Ou, por exemplo, se for um projeto pequeno — com baixa carga ou, em geral, não há muito dinheiro e recursos. Então, não faz sentido levar isso para o Kubernetes.
E, de modo geral, como muitos já disseram, se você está se perguntando: "Eu preciso do Kubernetes?", então provavelmente ele não é necessário para você. Eu não me lembro de quem foi o primeiro a pensar nisso, talvez Pasha Selivanov. Eu concordo com isso 100%. E é preciso amadurecer até o Kubernetes — e quando já há uma compreensão de que precisa realmente do Kubernetes e que ele ajudará a resolver determinadas questões, então, provavelmente, faz sentido ir estudar e entender como configurá-lo bem, para que o processo de migração para o Kubernetes não seja muito doloroso.
Existem algumas questões iniciais e algumas coisas simples, e até mesmo não tão simples, que podem ser aprendidas conosco, em vez de passar por nossas próprias armadilhas e dores.
Muitas empresas seguiram o caminho de inicialmente ter apenas alguma infraestrutura sem conteinerização. Depois, quando ficou difícil gerenciar tudo isso, elas migraram para o Docker e, em determinado momento, chegaram ao ponto em que, dentro do Docker e do que ele oferece, tornava-se restritivo. E começaram a explorar o que estava ao seu redor, quais sistemas resolviam esses problemas, e o Kubernetes é um desses sistemas que permitem resolver questões quando o Docker puro se torna insuficiente e falta funcionalidade. É um bom caso, onde as pessoas evoluem gradativamente, reconhecendo que essa tecnologia é limitada e avançam para o próximo nível. Usam algo, depois percebem que ainda é pouco — e então buscam mais.
É uma escolha consciente — e isso é muito legal.
Eu vejo que estamos construindo um sistema muito bonito, por exemplo, , até mesmo por meio de videoaulas. Depois do Docker, temos , depois , depois . Tudo se organiza de forma lógica — a pessoa avança e adquire uma profissão coesa.
O conjunto de cursos permite abordar muitos casos atuais. Há ainda áreas que permanecem em branco, espero que em breve possamos criar cursos que abordem essas áreas cinzas, especialmente no que diz respeito à segurança. Isso se torna muito relevante.
Resumindo, temos algumas áreas cinzas que seria ótimo fechar, para que a imagem seja coesa — e as pessoas possam vir, assim como o Kubernetes representa um construtor de Lego, a partir do qual é possível montar várias coisas; se ainda faltar algo — complementar, assim como com nossos cursos, para que as pessoas possam entender o que precisam e montar um quebra-cabeça, um conjunto a partir dos nossos cursos.
Se eu fizer a mim mesmo a pergunta correta e honesta: "Quem se beneficiaria agora de um curso ativo de Docker?", então:
- Estudantes que estão apenas começando a se aprofundar.
- Funcionários do departamento de testes.
- Na verdade, existem muitas empresas onde, não apenas não utilizam Docker, mas ninguém nunca ouviu falar dessa tecnologia e, na verdade, não sabe como usá-la. E conheço algumas grandes empresas em São Petersburgo que já trabalham há muitos anos com desenvolvimento, e elas continuam usando tecnologias antigas, sem avançar nesse sentido. Em particular, para essas empresas e engenheiros que nelas trabalham, este curso pode ser realmente interessante, pois, em primeiro lugar, permitirá uma rápida imersão nessa tecnologia, e em segundo lugar, assim que alguns engenheiros entenderem como tudo isso funciona, eles podem trazer isso para a empresa e, dentro dela, desenvolver essa cultura e esses conceitos.
- Na minha opinião, este curso também pode ser útil para aqueles que já trabalharam com Docker, mas de forma muito limitada, mais no estilo de 'faça isso, faça aquilo' — e agora eles pretendem, de alguma forma, interagir com o Kubernetes, e isso impõe algumas obrigações a eles. Se possuem apenas conhecimentos superficiais sobre o que é Docker, como executá-lo, mas não sabem como funciona internamente, ou o que é melhor fazer ou o que é melhor evitar, então este curso será uma boa opção para sistematizar e aprofundar seus conhecimentos.
Mas se o seu conhecimento é no nível: 'Eu não sei como escrever corretamente arquivos Docker, eu tenho uma noção do que são namespaces, como funcionam os containers, como eles são realmente implementados no nível do sistema operacional' — então definitivamente não faz sentido vir até nós, você não vai aprender nada de novo e ficará um pouco triste pelo dinheiro e tempo gastos.
Se formos resumir quais são as vantagens do nosso curso, seria:
- Este curso foi elaborad com uma quantidade suficiente de casos práticos que permitirão que você não apenas compreenda a parte teórica envolvida, mas também entenda por que isso é importante para você e como você usará isso no futuro;
- Existem algumas seções que são muito raras de encontrar em outros lugares — e, na verdade, sobre elas não há tantos materiais assim. Elas dizem respeito à interação do Docker com o sistema operacional, de uma forma até um pouco diferente. Quais mecanismos o Docker adotou do sistema operacional para implementar o sistema de contêineres — e isso proporciona uma compreensão mais profunda de toda a questão de execução de contêineres dentro do sistema operacional Linux. Como isso funciona, como interage entre si dentro do sistema operacional, do lado de fora, e assim por diante.
É uma visão bastante profunda, que ocorre raramente, e, na minha opinião, isso é muito importante. Se você quer realmente entender bem qualquer tecnologia e saber o que esperar dela, precisa ter ao menos uma ideia geral de como funciona em um nível mais básico.
Nosso curso mostra e relata como isso é estruturado do ponto de vista do sistema operacional. Por um lado, todos os sistemas de contêinerização utilizam os mesmos mecanismos do sistema operacional. Por outro lado, eles aproveitam o que já existe no Linux, como o Docker. Outros sistemas de contêinerização não inventaram nada novo — apenas usaram o que já existe no Linux e escreveram uma interface conveniente que permite chamar isso rapidamente, executá-lo ou interagir de alguma forma com isso. O próprio Docker é uma camada não muito grande entre o sistema operacional e a linha de comando; é uma ferramenta que permite não escrever toneladas de comandos ou algum código em C para criar um contêiner, mas fazer isso introduzindo apenas algumas linhas no terminal.
E, além disso, se estamos falando especificamente do Docker, o que realmente trouxe para o mundo da TI foi a padronização. Como um aplicativo deve ser iniciado, como deve funcionar, quais são os requisitos para logs, quais são os requisitos para escalabilidade, configuração do próprio aplicativo.
Em grande parte, o Docker diz respeito a padrões.
Os padrões também são transportados para o Kubernetes — e lá os mesmos padrões se aplicam; se você consegue executar seu aplicativo bem no Docker, há 99% de chances de que também funcione bem dentro do Kubernetes.
Se você se interessou não apenas em como o curso de Docker foi criado, mas também em outros cursos, e ainda ficou curioso sobre o curso sob uma perspectiva prática, então
Ficaremos felizes em vê-lo!
Fonte: habr.com
