Traduzione:
Azat Khadiev: Buongiorno. Mi chiamo Azat Khadiev. Sono uno sviluppatore nel settore PaaS di Mail.ru Cloud Solutions. Qui con me c'è Pavel Selivanov della società Southbridge. Siamo presenti alla conferenza DevOpsDays. Lui presenterà una relazione su come con Kubernetes sia possibile costruire DevOps, ma probabilmente non ci riuscirete. Perché un tema così cupo?
Pavel Selivanov: In realtà non è cupo. Riguarda il fatto che stiamo cercando di risolvere molti problemi nella nostra comunità attraverso la tecnologia. E, inoltre, tendiamo a farlo in modo piuttosto unilaterale. Kubernetes è esattamente questa cosa di cui si occupano, possiamo dire, gli Ops. Ma abbiamo un concetto magnifico di ingegnere DevOps. Qui il responsabile di Kubernetes è un ingegnere DevOps. Tuttavia... Dovete implementare Kubernetes, ma i ragazzi Dev non sanno nulla di tutti questi kubernetes, non hanno idea di cosa possa fare — e per loro tutto continua a vivere allo stesso modo. E questo nonostante il fatto che Kubernetes contenga soluzioni pronte e strumenti progettati per estendere questo approccio DevOps, il dialogo tra Dev e Ops. Utilizziamo molto poco questa possibilità. A causa del fatto che stiamo adattando le strutture attuali a tutti questi strumenti DevOps — Docker, Kubernetes, cloud e così via — stiamo aggravando ulteriormente la situazione. E gli strumenti iniziamo a utilizzarli non come erano stati concepiti. E attorno a tutte queste tecnologie si stanno costruendo semplicemente delle terrificanti soluzioni di emergenza.
Azat Khadiev: Chiaro. Si percepisce che il tema è ampio. Cosa pensi sia il problema più comune per le aziende in questo momento? Con Kubernetes.
Pavel Selivanov: Con Kubernetes il problema più comune è la mancanza di competenze. In IT è un problema comune. C'è sempre carenza di specialisti. C'è sempre carenza di competenze. E ora con Kubernetes c'è carenza di competenze. Inoltre, ci sono pochissime soluzioni pronte sul mercato che consentano di ottenere Kubernetes senza possedere le competenze necessarie. Quelle che ci sono sollevano sempre qualche interrogativo. Siamo sempre alla ricerca di persone che capiscono Kubernetes. Stiamo cercando di questo adattamento.
Azat Khadiev: E considerando l'attuale carenza di personale nell'IT. Che è sempre esistita. E che c'è anche adesso. Cosa ne pensi, come si vive in queste condizioni? Ci sono dei suggerimenti?
Pavel Selivanov: Suggerimenti. Prima di tutto, dal punto di vista delle nuvole, il suggerimento è questo: perché non ci cedete una parte delle vostre competenze? E noi ce le prendiamo e ci occupiamo di esse internamente. Va tutto bene. A parte il fatto che è importante capire per chi lo usa... In realtà è un momento ottimo... Ma è importante capire che cedendo parte delle proprie competenze a una nuvola o a un fornitore, riceviamo in cambio una soluzione standardizzata. Grosso modo, abbiamo un database che esegue cose molto specifiche, ed è stato configurato in modo molto specifico. Cedendo questo database alla nuvola, possiamo certamente licenziare l'amministratore che prima si occupava dei cluster di database: lo stesso Amazon o Google lo faranno per noi. Ma nel contempo, né Amazon né Google ci permetteranno di configurare il nostro database in modo preciso. Grandi progetti, grandi aziende - prima o poi arrivano al punto in cui utilizzano soluzioni cloud, ma poi in ogni caso tornano indietro per riprendere le competenze, perché è richiesta qualcosa di più specifico.
Azat Khadiev: Le soluzioni standardizzate sono negative o su di esse si può costruire di più?
Pavel Selivanov: No, le soluzioni standardizzate non sono affatto negative. Le soluzioni standardizzate sono buone. Semplicemente, le soluzioni standardizzate... sono standardizzate. Qui è importante capire. È come prendere uno script generale... Se riesci a costruire attorno a questo script generale, a questo uso generale, tutta la logica operativa dell'azienda - allora è fantastico. Ma se la logica operativa è diversa, e prendi questa soluzione standardizzata, questo script standardizzato - e inizi, come un gufo che si tira su un globo, è negativo. Ma nel concetto stesso di standardizzazione non c'è nulla di sbagliato.
Azat Khadiev: Se quell'amministratore è già in servizio, il punto non è il suo licenziamento. Semplicemente, potrà fare di più.
Pavel Selivanov: Sì, allontanargli la routine e cederla a qualcuno, così che venga svolta da un'altra parte. È senza dubbio un buon approccio. È importante che questa soluzione standardizzata si adatti al caso specifico.
Azat Khadiev: Semplicemente, basandomi sulla mia esperienza, vedo che molte aziende si occupano della stessa cosa. Configurano un cluster Kubernetes, pensano alla sua scalabilità. E tutte queste operazioni sono molto ripetitive.
Pavel Selivanov: Sì, senza dubbio. Inoltre, se diciamo specificamente di Kubernetes, c'è il fatto che ci sono attualmente pochi conoscitori approfonditi e competenti di Kubernetes sul mercato. Kubernetes è un costruttore gigantesco, quindi se lo introduci nella tua azienda, preparati a dover assumere insieme a esso un ingegnere che si occupi di ogni aspetto a tempo pieno. E questo è costoso. E trovare un ingegnere del genere non è semplice. Parlando di me stesso, non amo molto le soluzioni cloud, perché comprendo abbastanza bene e in profondità come funziona Kubernetes. Spesso mi manca in cloud qualche funzionalità che richiedo – e mi dicono "No, non è possibile". Beh, in tal caso scusate, ma posso fare meglio io rispetto al cloud. Tuttavia, se nella tua azienda non hai un ingegnere a tempo pieno, non hai voglia di pagare per quell'ingegnere che gestisce Kubernetes, e gli stai sempre pagando molte somme di denaro per semplicemente sperimentare, allora il cloud è davvero una buona soluzione. Perché almeno lì ci sono persone che il provider ha già reclutato. E sanno cosa stanno facendo. E quelle funzioni di base che ti servono quotidianamente, sono lì.
Azat Khadiev: Cosa ne pensi dello stato attuale di Kubernetes? Cosa ne sarà tra cinque o dieci anni?
Pavel Selivanov: Bella domanda. So solo che cosa sta succedendo nella nostra comunità riguardo a questo tema. Alcune persone credono che oltre a Kubernetes non ci sarà nulla. È la stessa situazione che è successa con Linux. Cioè, ci sono persone che vivono su BSD, probabilmente hanno compiti molto specifici. Ci sono persone che lavorano su Windows - server Windows - probabilmente anche loro hanno compiti specifici, oppure hanno semplicemente competenze in questo campo e non sono pronti a andarsene. In ogni caso, lo standard nel nostro campo è Linux. Si dice che Kubernetes diventerà un tale standard de facto e che non ci sarà nient'altro oltre a Kubernetes. Kubernetes gestirà non solo le applicazioni, il loro deployment, la loro scalabilità. Gestirà praticamente tutto. Già adesso si chiedono: "È possibile farci stare un database in Kubernetes?" Di solito dico che qui la questione non è Kubernetes, ma Docker. Se siete pronti a far funzionare il vostro database nei container, come funzionerà. Mi rispondono: "No, no, no, aspetta. Non serve nei container. Abbiamo bisogno di Kubernetes. È così che lo collegheremo al nodo. Cioè, tutto sarà come abbiamo adesso, solo che Kubernetes gestirà tutto questo." E in realtà è una buona idea. Cioè, Kubernetes è uno strumento che permette di entrare in un'azienda e, se nell'azienda c'è Kubernetes e i processi costruiti su di esso, per una persona che se ne intende, basta guardare per un paio di giorni per dire: "Sono pronto a supportarvi. Completamente. In toto. Ho capito come funziona tutto." A differenza degli approcci senza Kubernetes, dove qui abbiamo messo un po' di supporti, qui altri supporti. Qui Ansible, qui Terraform. È tutto scritto da qualcuno e ci vogliono sei mesi per capire. Quindi, se Kubernetes diventerà uno standard de facto, non lo so. Oggi sembra molto più ambizioso e sicuro rispetto alle soluzioni che ci sono intorno.
Azat Khadiev: Beh, il confronto con Linux è piuttosto audace. Quest'ultimo funziona su una sola macchina - e basta. Ma Kubernetes funziona su molte macchine. Subito sorgono milioni di variazioni, di motivi. Sì, questo è audace. Basterebbe considerare che ci sono concorrenti per questa paradigma. Ad esempio, il Serverless. Kubernetes è in pericolo con tali concorrenti?
Pavel Selivanov: Da Serverless... (risata) Serverless — dobbiamo comunque capire che server esiste. Recentemente ho sentito una conferenza a riguardo. Una persona ha detto che i server esistono ancora — ed è il cloud. Ma dobbiamo sempre comprendere che nel cloud — ci sono anche server. Lì ci sono server fisici reali, in rack, e sono installati da qualche parte. Questo è il cloud. Sopra di esso esiste Serverless, dove server «non». Quindi, la domanda è: Serverless vincerà su Kubernetes? Mi sembra che Serverless si trasferirà in Kubernetes. Per i provider che offrono Serverless, Kubernetes è una piattaforma molto conveniente per fornire questi servizi. Sì, è possibile che a un certo punto smetteremo di parlare di Kubernetes in generale, come di sviluppo di applicazioni aziendali standard. Ma in fondo, i provider e gli ingegneri utilizzeranno Kubernetes, dove tutto questo sarà implementato.
Azat Khadiyev: Un tema leggermente diverso. C'è un concetto chiamato ingegnere fullstack. Cosa ne pensi? Esistono davvero?
Pavel Selivanov: Eh... Ingegnere fullstack... Beh, mi sembra che valga la pena distinguere tra queste cose... Sai, c'è una cosa chiamata persone a forma di T. Sono necessarie persone del genere nell'industria odierna? Sì, senza dubbio. Abbiamo bisogno di persone che abbiano una visione ampia, ma che siano anche esperte in un'area specifica. E qui l'ingegnere fullstack è lo stesso — una persona che fa tutto. A partire dallo sviluppo del front-end, test, back-end, server e tutto il resto. Non credo che in una grande azienda possa farlo una sola persona, senza specializzazioni specifiche in ognuno di questi parametri. Ma avere solo una specializzazione ristretta, dicendo che non so nulla di ciò che accade attorno a questo — non funziona nemmeno nel mondo moderno. Quindi direi... il termine Fullstack lo eliminerei. Abbiamo bisogno di ingegneri molto. Abbiamo bisogno di DevOps. Sento che presto rivedremo questo aspetto. E non saranno più necessari.
Azat Khadiyev: Puoi approfondire?
Pavel Selivanov: Mi sembra che nel settore arriveremo al punto in cui questi ruoli di Dev e Ops diventeranno superflui. Se abbiamo bisogno di specialisti e stiamo cercando… Ci vuole un certo tipo di sviluppatore, servono amministratori specifici, ci vogliono ingegneri DevOps — ora li abbiamo, presto ci saranno anche ingegneri di produzione e ingegneri SRE. Anche se in realtà ciò di cui abbiamo bisogno sono ingegneri che vogliamo assumere. Il background, in sostanza, non è importante. Perché… Ad esempio, un SRE dice che i problemi dell'infrastruttura sono sempre problemi software. E allora… Dobbiamo assumere sviluppatori — considerando che uno sviluppatore è un ingegnere — metterli nel reparto supporto e loro risolveranno questi problemi esattamente come risolvono i problemi aziendali con il codice, con l'ingegneria.
Azat Khadiev: E da questo punto di vista… Come possiamo intervistare ingegneri del genere?
Pavel Selivanov: Oh, bella domanda. Probabilmente si trova già oltre la mia comprensione in questa vita. Ma potrei fare un esempio. Non ha a che fare con i colloqui. Riguarda il nostro sistema educativo in Russia. Nell'IT sappiamo che il nostro sistema educativo in Russia per il mondo IT è molto obsoleto, non è come dovrebbe essere. Parlo in generale della vasta Russia — e di cosa sta succedendo lì. Vengono formate persone che non sono affatto pronte a entrare domani nella programmazione web, in una compagnia tecnologica. E questo è un problema. Li stiamo istruendo su cose strane, mentre dovremmo insegnarli a sviluppare per Android, per iOS, come usare Git e tutte queste cose. In realtà sembra di no. L'università è un periodo in cui, per la maggior parte, i genitori pagano per te. Per tutta la tua vita. E puoi dedicare cinque anni della tua vita a studiare in profondità. E studiare tutto questo T-shaped. Quando all'università puoi studiare cosa sia un sistema di controllo versione, quali sono i vari pattern di sviluppo, come testare tutto questo, quali database esistono, bilanciatori. E quando vai a lavorare, inizi a specializzarti in un'area specifica. E così otteniamo ingegneri. E il nostro sistema educativo in Russia è molto più vicino a questa verità di quanto pensiamo. Otteniamo una buona preparazione matematica, una buona preparazione algoritmica, ci forniscono una certa comprensione dei linguaggi di programmazione. E riguardo ai colloqui, mi sembra che ci sia qualcosa di simile. Dobbiamo colloquiare gli ingegneri. Ci serve la parte superiore della lettera T nel T-shaped. Perché la linea verticale della lettera T la acquisirà.
Azat Khadiyev: Sì, interessante. Dopo l'università, per cinque anni pensavo che la mia educazione fosse strana e inadeguata. Ma poi, man mano che il lavoro progrediva, quando le sfide diventavano più profonde e i progetti più ampi, mi sono reso conto che in realtà mi avevano insegnato cose molto importanti. Pavel, grazie. È stato molto interessante ascoltare le tue risposte. Ascoltiamo la tua relazione.
Pavel Selivanov: Grazie a voi.
Fonte: habr.com
