Il partecipante arriva al corso o all'intensivo. Vede file ordinate di supporto tecnico, cavi di alimentazione perfettamente sistemati, disposizione a scacchiera dell'aula, immagini vivaci e schemi delle diapositive. I relatori offrono informazioni con battute e sorrisi talmente coinvolgenti che è impossibile non seguirli. Gli stand sono impostati, e i compiti pratici vengono eseguiti con facilità, a meno che non serva un aiuto da parte del supporto tecnico.
Inoltre, ci sono coffee break con persone affini, un'atmosfera vivace e dinamica, condivisione di esperienze e le domande più inaspettate ai relatori. E le risposte, e informazioni che non troverai mai nei manuali, ma solo nella pratica.
Cosa ne pensate, quanto tempo, energia e nervi sono stati necessari per arrivare a questo punto?
Un ringraziamento a Volodya Guryanov, amministratore certificato di Kubernetes e ingegnere/team leader in Southbridge, che è stato fin dall'inizio testimone e attivo partecipante alla creazione di molti corsi di Slёrm.
Ha visto il dietro le quinte della creazione dei corsi — le difficoltà e le insidie, le intuizioni e le soluzioni inaspettate. E i corsi intensivi già noti di Kubernetes, come Slёrm Base e Slёrm Mega. E il nuovo corso, in gran parte rielaborato. , che si avvicina inesorabilmente e inizierà il 19 agosto.
Ma basta con la poesia, passiamo alla storia. Come da una coppia di temi del workshop è gradualmente nato un corso ben strutturato e poliedrico. . Inizierò quindi a raccontare come nascono e si sviluppano i corsi — proprio come in un "Tanto tempo fa in una galassia lontana lontana..."
E cosa c'è dietro le quinte?
Se mi chiedi come creiamo i corsi e da dove iniziamo, ti risponderò semplicemente: "Tutto inizia da un'idea".
Di solito l'idea arriva da qualche parte — non siamo incatenati a un tavolo in cantina mentre pensiamo: «Quale tema dovremmo scegliere per il corso?». Le idee vengono spontaneamente da fonti esterne. A volte le persone iniziano a chiedere attivamente: «Che cosa sapete di una tecnologia specifica?». Oppure, come nel caso di Docker, che non riuscivamo ad inserire nei tempi del workshop — era chiaro che dovevamo portarlo all'esterno per avere il tempo di raccontare qualcosa durante il workshop.
Ecco come nasce un'idea.
Una volta che si è presentata, inizia, a mio avviso, il momento più difficile: capire cosa includere in questo corso. È molto simile a come si preparano i relatori per le conferenze.
C'è un problema principale: sembra di aver scelto un argomento e pensi: «E di cosa devo parlare? Questo è troppo semplice, è ovvio, anche questo lo sanno tutti».
Ma in realtà non è affatto così. E personalmente dico spesso che ciò che ti sembra ovvio a chi verrà ad ascoltarti o a seguire il corso non è affatto scontato. Qui sorge un grande lavoro e un conflitto interiore: cosa includere nel corso. Di conseguenza, si ottiene un elenco di capitoli con ampi tratti, indicando di cosa tratterà il corso.
E poi inizia il semplice lavoro di routine:
- Selezione dei materiali
- Leggere attentamente la documentazione della versione attuale, poiché il mondo IT si sviluppa a velocità vertiginosa. Anche se stai lavorando su qualcosa e stai creando un corso su di esso, devi consultare la documentazione per scoprire le novità, ciò che è interessante da raccontare e ciò che potrebbe essere particolarmente utile da menzionare.
- Ecco che emerge una sorta di scheletro del corso, dove la maggior parte degli argomenti è generalmente già delineata e sembra che ci sia solo da registrare i video e lanciarli in produzione.
- Ma in realtà non è così, inizia un lavoro intenso, ma non per gli autori del corso, bensì per coloro che effettuano i test. Di solito, i nostri beta tester sono il supporto tecnico, che, prima di tutto, rivede i corsi alla ricerca di errori sintattici e grammaticali. In secondo luogo, ci criticano severamente quando ci sono punti particolarmente poco chiari o vaghi. Quando nei testi emergono frasi complesse che si estendono su una pagina o si manifestano ovvietà insensate. Loro leggono e scrutano tutto questo.
- Poi inizia la fase di testing pratico, dove vengono rilevati alcuni aspetti evidenti che non funzionano e vengono evidenziati alcuni punti che possono essere complicati, poiché diventa poco interessante semplicemente copiare. Si identificano anche aree dove è davvero difficile e noi abbiamo molte aspettative dalle persone che parteciperanno a questo corso. E da lì arrivano le raccomandazioni: «Ragazzi, semplificate qui, sarà più facile da comprendere e ci sarà un maggiore beneficio».
- Dopo aver completato questo lavoro, è stata scritta la parte relativa al video e tutto sembra andare bene. Possiamo già procedere con il rilascio e la promozione di questo corso. Ma, ancora una volta, è troppo presto — poiché ultimamente abbiamo smesso di fidarci completamente di noi stessi e abbiamo iniziato a prestare maggiore attenzione ai feedback. È stata introdotta una pratica chiamata beta testing – in cui arrivano persone esterne, non collegate alla nostra azienda, e per alcune piccole ricompense vengono mostrate tutte le parti del corso, video, testi, esercizi pratici, in modo che possano valutare la qualità del materiale, la sua accessibilità e aiutarci a migliorare il corso al meglio delle nostre possibilità.
- E quando passano diverse di queste iterazioni, con oratori, test alfa sotto forma di supporto tecnico, beta testing e miglioramenti. E poi tutto ricomincia — supporto tecnico, beta testing, miglioramenti.
- E in un certo momento arriva la comprensione che o smettiamo di apportare modifiche, perché è impossibile accontentare tutti, oppure si prendono decisioni radicali. Quando molte delle osservazioni su determinati punti sono critiche, bisogna rifarle a livello globale, perché qualcosa non ha funzionato.
- Poi arriva il momento delle piccole correzioni: in qualche caso una frase non è formulata in modo molto elegante, in altri qualcuno non gradisce il carattere, magari 14,5, mentre preferirebbe 15,7.
- Quando rimangono solo questo tipo di osservazioni, allora si, il corso si apre più o meno, e iniziano le vendite ufficiali.
E a prima vista sembra un compito breve e semplice creare il corso, ma si rivela tutt'altro che semplice e richiede un incredibile quantità di tempo.
C'è anche un altro aspetto importante: il lavoro sul corso non si conclude al momento del suo rilascio. Innanzitutto, esaminiamo attentamente i commenti che vengono lasciati su diverse parti. E anche se abbiamo già fatto molti sforzi, ci sono comunque delle imperfezioni e degli errori che vengono corretti e perfezionati in tempo reale, affinché ogni utente successivo riceva un servizio di qualità superiore.
Ogni corso ha un proprio product owner, che oltre a definire il concetto generale, verifica le scadenze e prende appunti a margine. Quando arriverà il momento di riscrivere completamente il corso, e quel momento arriverà sicuramente, perché tra un paio d'anni, se non prima, parte di ciò che stiamo insegnando diventerà obsoleto semplicemente perché sarà moralmente superato. Il product owner annota quali sono le domande più comuni, quali aspetti risultano poco chiari, quali compiti appaiono molto difficili e quali, al contrario, sembrano molto semplici. Tutto ciò viene preso in considerazione durante la riscrittura del corso e in eventuali interventi di refactoring, affinché ogni iterazione del corso globale diventi migliore, più comoda e più fruibile.
Ecco come nascono i corsi.
Come è nato il corso su Docker
Si tratta di un tema a parte, e persino insolito per noi. Da un lato, non avevamo in programma di crearlo, poiché molte scuole online lo offrono. Dall'altro, si è imposto da solo e ha trovato un posto logico nella nostra concezione di preparazione degli specialisti IT su Kubernetes.
Parlando in termini molto generali, tutto è iniziato con un corso su Kubernetes, quando è stato appena lanciato, credo, dopo il primo Slёrm. Abbiamo raccolto feedback e abbiamo visto che molte persone volevano leggere qualcosa di aggiuntivo su Docker e, in generale, molti arrivano al corso base di Kubernetes senza sapere cosa sia. .
Così, per il secondo Slёrm, abbiamo creato un corso — o meglio, non un corso, ma abbiamo realizzato alcuni capitoli su Docker. In cui spiegavamo alcune cose molto basilari, affinché le persone che partecipano all'intensivo non si sentissero trascurate e comprendessero cosa stesse succedendo.
E poi gli eventi si sono sviluppati più o meno in questo modo. La quantità di materiale è aumentata e non riusciva più a stare in 3 giorni. È nata quindi l'idea logica e ovvia: perché non creare da ciò che raccontiamo nel corso base di Slёrm un piccolo corso, al quale poter inviare le persone che vogliono vedere qualcosa su Docker prima dell'intensivo su Kubernetes.
Slёrm Junior è, di fatto, un'unione di diversi corsi di base. Alla fine, il corso su Docker è diventato parte di Slёrm Junior. Quindi è come se fosse un primo livello antesignano. e . E poi c'erano delle astrazioni molto basilari.
A un certo punto, le persone hanno iniziato a chiedere: «Ragazzi, tutto questo è fantastico, ma è sufficiente per capire cosa state spiegando nei corsi intensivi. Dove posso leggere di più su cosa può fare Docker, come utilizzarlo e che cos'è?». Così è nata l'idea di creare un , in modo che, da un lato, si potesse indirizzare le persone che partecipano ai corsi su Kubernetes, e dall'altro, per coloro che non sono nemmeno interessati a Kubernetes in questa fase della loro carriera. Affinché un professionista IT possa venire a vedere il nostro corso su Docker e iniziare il suo percorso evolutivo semplicemente con Docker. Volevamo avere un corso completo e finito — e molti, dopo aver visto questo corso e aver lavorato un po' con Docker, sono cresciuti fino a raggiungere un livello in cui hanno già bisogno di Kubernetes o di un altro sistema di orchestrazione. E in particolare, sono venuti da noi.
Spesso si pone la domanda: "Chi ha realmente bisogno di Kubernetes al giorno d'oggi?" Ma la questione non riguarda tanto le persone, quanto piuttosto le aziende. È importante capire che Kubernetes ha casi specifici in cui si adatta bene e compiti che gestisce efficacemente, mentre ci sono scenari in cui può creare più problemi e difficoltà. Quindi, non si tratta neppure di chi, ma di cosa e di come le aziende stanno sviluppando.
Ad esempio, un terribile monolite legacy — probabilmente non ha senso migrarlo su Kubernetes, perché causerebbe più problemi che benefici. Oppure, se si tratta di un progetto piccolo — con carichi leggeri o con risorse finanziarie e materiali limitate — non ha alcun senso portarlo su Kubernetes.
E in generale, probabilmente, come già molti hanno detto, se ti chiedi: "Ho bisogno di Kubernetes?", allora probabilmente non ne hai bisogno. Non ricordo chi l'abbia detto per primo, credo sia stato Pasha Selivanov. Sono completamente d'accordo. Prima di arrivare a Kubernetes, bisogna maturare — e quando si realizza che ho proprio bisogno di Kubernetes e che è necessario per la nostra azienda, ecco che può aiutare a risolvere determinati problemi, allora ha senso andare a studiare e capire come configurarlo bene, affinché il passaggio a Kubernetes non sia troppo doloroso.
Alcune semplici questioni e anche alcune cose non così semplici possono essere apprese in particolare da noi, invece di passare attraverso i propri ostacoli e dolori.
Molte aziende hanno iniziato con un'infrastruttura semplicemente senza containerizzazione. Poi, quando è diventato difficile gestire tutto ciò, sono passate ai Docker e, a un certo punto, si sono ritrovate nella situazione in cui, all'interno di un Docker e delle sue offerte, c'era un po' di spazio ristretto. Hanno iniziato a esplorare ciò che c'era intorno e quali sistemi risolvessero questi problemi; in particolare, Kubernetes è uno di quei sistemi che permette di affrontare le problematiche quando un Docker puro diventa limitato e manca di funzionalità. È un esempio interessante di come le persone avanzino gradualmente, capendo che questa tecnologia non basta e si spostano verso il livello successivo. Usano qualcosa e, quando non basta più, continuano a cercare soluzioni.
È una scelta consapevole — ed è davvero fantastico.
Vedo che stiamo costruendo un sistema molto interessante, ad esempio, , anche video corsi. Poi, dopo Docker, c'è , poi , poi . Tutto si costruisce in modo logico — la persona progredisce e ottiene una professione coerente.
In linea di principio, l'insieme di corsi consente di coprire un gran numero di casi, molto attuali. Ci sono ancora aree che rimangono grigie, e spero che presto svilupperemo dei corsi che possano affrontare queste aree grigie, in particolare qualcosa sulla sicurezza. Perché sta diventando molto attuale.
In breve, abbiamo alcune aree grigie che sarebbe molto utile affrontare, in modo che si possa avere un quadro completo — così che le persone possano arrivare, e come Kubernetes rappresenta un costruttore di Lego, si possono assemblare diverse cose; se manca ancora qualcosa, completare, così come nei nostri corsi, affinché le persone possano capire cosa serve loro, assemblando un puzzle, un costruttore dai nostri corsi.
Se mi faccio la giusta e sincera domanda: "A chi può essere utile attualmente un corso attivo su Docker?", allora:
- Agli studenti che stanno appena iniziando a immergersi nel tema.
- Agli operatori del reparto testing.
- In realtà ci sono molte aziende in cui, non solo non usano Docker, ma nessuno ha mai sentito parlare di questa tecnologia e non sanno nemmeno come utilizzarla. E conosco direttamente diverse grandi aziende a San Pietroburgo che da molti anni si occupano di sviluppo e continuano a utilizzare vecchie tecnologie. In particolare, per queste aziende, per gli ingegneri che lavorano in esse, questo corso potrebbe essere davvero molto interessante, poiché, da un lato, permette di immergersi rapidamente in questa tecnologia e, dall'altro, non appena ci sono alcuni ingegneri che comprendono come funziona, possono introdurlo in azienda e all'interno dell'azienda sviluppare questa cultura e questi ambiti.
- A mio avviso, questo corso può essere utile per coloro che hanno già lavorato con Docker, ma molto poco e in stile "fai una cosa, fai l'altra" — e ora intendono interagire in qualche modo con Kubernetes. Ciò comporta alcune responsabilità, soprattutto se si hanno solo conoscenze superficiali riguardo Docker, come avviarlo, ma non si sa come funziona internamente, cosa sia meglio fare o evitare con esso. Allora questo corso è ideale per sistematizzare e approfondire le conoscenze.
Ma se le tue conoscenze sono a livello: "Non so come scrivere correttamente i file Docker, ho un'idea di cosa siano i namespace, come funzionano i contenitori e come siano realmente implementati a livello di sistema operativo" — allora non ha senso venire da noi. Non imparerai nulla di nuovo e potrebbe essere un po' triste per i soldi e il tempo spesi.
Se si desidera esporre i vantaggi del nostro corso, allora:
- Abbiamo cercato di realizzare questo corso con un numero sufficiente di casi pratici, che vi permetteranno non solo di capire la parte teorica esistente, ma anche di comprendere perché è importante per voi e come lo utilizzerete in futuro;
- Ci sono alcune sezioni che si trovano molto raramente — e di cui in generale ci sono pochi materiali. Riguardano l'interazione di Docker con il sistema operativo, anche se in modo leggermente diverso. Quali meccanismi Docker ha preso dal sistema operativo per realizzare il sistema di containerizzazione — e questo fornisce una comprensione più profonda della questione del lancio dei contenitori nel sistema operativo Linux. Come funziona, come interagisce all'interno del sistema operativo, all'esterno e così via.
È un'analisi davvero approfondita, che è abbastanza rara, e secondo me è molto importante. Se volete capire bene qualsiasi tecnologia e sapere cosa aspettarvi da essa, è fondamentale avere almeno un'idea generale di come funziona a un livello basso.
Il nostro corso mostra e spiega come funziona dal punto di vista del sistema operativo. Da un lato, tutti i sistemi di containerizzazione utilizzano gli stessi meccanismi del sistema operativo. Dall'altro lato, prendono ciò che è già presente nel sistema operativo Linux, come Docker. Altri sistemi di containerizzazione non hanno inventato nulla di nuovo: hanno preso quanto già esiste in Linux e hanno semplicemente scritto un'interfaccia comoda che consente di richiamarlo rapidamente, avviarlo o interagirci in un modo qualunque. Lo stesso Docker è un'interfaccia piuttosto sottile tra il sistema operativo e la riga di comando; è un'utilità che permette di non dover scrivere chilotoni di comandi o codice C per creare un container, ma di farlo semplicemente inserendo alcune righe nel terminale.
Inoltre, se parliamo specificamente di Docker, ciò che ha realmente portato nel mondo IT sono gli standard. Come deve essere avviata un'applicazione, come deve funzionare, quali sono i requisiti per i log, quali sono le esigenze per la scalabilità e la configurazione dell'applicazione stessa.
In larga misura, Docker è tutto incentrato sugli standard.
Gli standard si trasferiscono anche su Kubernetes — e qui ci sono esattamente gli stessi standard; se sei in grado di eseguire bene la tua applicazione in Docker, al 99% funzionerà altrettanto bene anche su Kubernetes.
Se sei interessato non solo a come è stato creato il corso Docker, ma anche ad altri corsi, e vuoi scoprire il corso dal punto di vista pratico, allora
Saremo lieti di accoglierti!
Fonte: habr.com
