Trascrizione:
Azat Khadiyev: Buongiorno. Mi chiamo Azat Khadiyev e sono uno sviluppatore nell'area PaaS di Mail.ru Cloud Solutions. Qui con me c'è Pavel Selivanov di Southbridge. Ci troviamo alla conferenza DevOpsDays. Qui presenterà una relazione su come con Kubernetes si possa costruire DevOps, ma probabilmente non ci riuscirete. Perché un argomento così cupo?
Pavel Selivanov: In realtà, non è affatto cupa. Parla del fatto che stiamo cercando di risolvere molti problemi nella nostra comunità attraverso la tecnologia. E stiamo cercando di farlo in modo piuttosto unilaterale. Kubernetes, ad esempio, è una cosa di cui si occupano, si può dire, gli Ops. Ma abbiamo una bellissima figura, l'ingegnere DevOps. È l'ingegnere DevOps a occuparsi di Kubernetes. E… tipo, fate Kubernetes, ma i ragazzi Dev non sono affatto al corrente di tutti questi Kubernetes, non sanno cosa permette di fare — e tutto per loro funziona allo stesso modo. E questo nonostante Kubernetes contenga soluzioni pronte, strumenti pronti per estendere questo approccio DevOps, rendere più fluida la comunicazione tra Dev e Ops. Utilizziamo molto poco questa possibilità. Trasformando anche le strutture attuali in tutti questi strumenti DevOps — Docker, Kubernetes, cloud e così via — stiamo solo peggiorando la situazione. E i tool iniziamo a usarli in modo diverso da come erano stati concepiti. E attorno a tutte queste tecnologie si costruiscono veri e propri mostruosi ripieghi.
Azat Khadiev: Chiaro. Si percepisce che l'argomento è ampio. Qual è, secondo te, il problema più comune che le aziende affrontano attualmente? Con Kubernetes.
Pavel Selivanov: Il problema più comune con Kubernetes è la mancanza di competenze. Questo è un problema diffuso nell'IT. C'è sempre carenza di specialisti. C'è sempre carenza di competenze. E adesso con Kubernetes, le competenze sono scarse. Inoltre, le soluzioni pronte all'uso sul mercato che consentono di ottenere Kubernetes senza le competenze necessarie sono davvero poche. E tra quelle che ci sono, molte sollevano dubbi. Siamo sempre in cerca di persone che se ne intendano. Stiamo cercando di allineare lo sviluppo a questo.
Azat Khadiev: E considerando la attuale scarsità di personale nell'IT. Che è sempre esistita. E c'è ancora. Come pensi si possa vivere in queste condizioni? Quali sono alcuni suggerimenti pratici?
Pavel Selivanov: Life Hack. In the realm of cloud computing, the life hack goes like this — let’s hand over some of your competencies to us. We will take them on and handle everything internally. This sounds fine. Except it’s crucial for users to understand… There’s a truly valuable point here… But it’s essential to realize that when you give some of your competencies to a cloud provider, you’re essentially getting a one-size-fits-all solution in return. To put it bluntly, we have a database that does very specific things and has been tailored accordingly. By moving this database to the cloud, we can indeed let go of the admin who used to manage the database clusters — Amazon or Google can take care of that for us. However, those same providers won’t allow us to finely tune our database settings. Large projects and major companies inevitably find themselves using cloud solutions at some stage, but they often revert to reclaiming their competencies because more specific requirements arise.
Azat Khadiev: Le soluzioni universali sono negative o possono costituire una base per sviluppare di più?
Pavel Selivanov: No, le soluzioni universali non sono affatto negative. Le soluzioni universali sono positive. È importante capire che sono... universali. È come prendere uno script comune... Se riesci a costruire tutto l'intero sistema dell'azienda attorno a quello script comune e alla sua applicazione, allora è fantastico. Ma se il sistema è diverso e prendi quella soluzione universale, quello script universale, e inizi a forzarlo come un gufo su un globo, allora è negativo. Non c'è nulla di sbagliato nell'universalismo.
Azat Khadiev: Se quell'amministratore sta già lavorando per te, il problema non è il suo licenziamento. Potrà semplicemente fare di più.
Pavel Selivanov: Sì, allontana da lui le routine e affidale a qualcun altro affinché vengano gestite altrove. Questo è sicuramente un buon approccio. Importante è verificare se quella soluzione standard si adatta al caso specifico.
Azat Khadiev: Semplicemente, sulla base della mia esperienza, vedo che molte aziende fanno le stesse cose. Configurano un cluster Kubernetes, pensano alla sua scalabilità. E tutte queste operazioni sono molto ripetitive.
Pavel Selivanov: Certamente. Inoltre, se consideriamo specificamente Kubernetes, c'è un punto da tenere presente: attualmente ci sono davvero poche persone sul mercato con conoscenze profonde e solide su Kubernetes. È un costruttore gigante, quindi se decidi di adottarlo in azienda, preparati a dover assumere anche un ingegnere che si occupi di tutto questo a tempo pieno. E questo può essere costoso. Inoltre, trovare un ingegnere così non è semplice. Parlando per esperienza personale, non amo molto le soluzioni in cloud, perché ho una comprensione piuttosto buona e approfondita di come funzioni Kubernetes. Spesso nei cloud mi manca una funzionalità che richiedo e mi sento dire: 'No, non è possibile'. In tal caso, mi dispiace, ma credo che io possa fare meglio del cloud. Tuttavia, se non hai un ingegnere a tempo pieno e non desideri pagarlo per gestire Kubernetes, mentre continui a spendere molti soldi per farlo semplicemente sperimentare, allora il cloud è una buona soluzione eccellente. Perché lì ci sono ragazzi che il provider ha già selezionato. E sanno davvero cosa stanno facendo. E quelle cose di base che ti servono quotidianamente sono disponibili.
Azat Khadiev: Cosa ne pensi dello stato attuale di Kubernetes? Cosa succederà nei prossimi cinque e dieci anni?
Pavel Selivanov: Buona domanda. So solo che cosa sta succedendo nella nostra comunità a riguardo. Alcune persone credono che, tranne Kubernetes, non ci sarà nient'altro. È simile alla situazione che si è verificata con Linux. Cioè, al di fuori di Linux ci sono persone che vivono su BSD, probabilmente hanno compiti molto specifici. Ci sono persone che lavorano su Windows — server Windows — e anch'essi hanno compiti specifici, oppure hanno semplicemente competenza in questo campo e non sono pronti a lasciare. In ogni caso, lo standard nel nostro settore è Linux. C'è l'opinione che Kubernetes diventerà lo standard de facto, e non ci sarà null'altro oltre a Kubernetes. Kubernetes gestirà non solo le applicazioni, il loro deployment e scaling, ma tutto in generale. Già ora ci si chiede: «Posso inserire un database in Kubernetes?». Di solito dico che la questione non è tanto Kubernetes, quanto Docker. Se si è pronti a far funzionare il database nei container, come funzionerà. Mi rispondono: «No, no, no, aspetta. Non serve nei container. Serve in Kubernetes. Lo collegheremo al nodo. Cioè, sarà tutto come abbiamo adesso, solo che sarà gestito da Kubernetes.» E questa è, in effetti, una buona idea. Cioè, Kubernetes è qualcosa che, se entrate in una azienda che utilizza Kubernetes e ha i processi costruiti su di esso, una persona che sa come funziona basta che guardi per un paio di giorni e può dire: «Sono pronto a supportarvi. Completamente. In toto. Ho capito come funziona il vostro sistema». A differenza degli approcci senza Kubernetes — qui ci sono solo costrutti messi insieme, e qui altri costrutti. Qui Ansible, qui Terraform. È tutto scritto da qualcuno e ci vogliono sei mesi per capirlo. Quindi, se Kubernetes diventerà lo standard de facto, non lo so. Oggi appare molto più ambizioso e sicuro rispetto alle soluzioni che lo circondano.
Azat Khadiev: Beh, il confronto con Linux è piuttosto audace. Funziona su una sola macchina, tutto qui. Kubernetes funziona su molte macchine. Emergeranno subito un milione di variazioni e motivi. Sì, è audace. Solo che ci sono concorrenti a questa parudigma. Ad esempio, Serverless. Kubernetes è in pericolo con tali concorrenti?
Pavel Selivanov: Da Serverless... (risate) Serverless — dobbiamo comunque considerare che server ci sono. Di recente ho sentito una presentazione a riguardo. Lì una persona ha detto che i server esistono — ed è il cloud. Ma dobbiamo sempre capire che nel cloud ci sono anche server. Ci sono server fisici reali, rack, e sono installati da qualche parte. Questo è il cloud. Sopra di esso esiste Serverless, dove server «no». Quindi, la domanda è se Kubernetes Serverless avrà successo? Penso che Serverless si integrerà in Kubernetes. Per i fornitori che offrono Serverless, Kubernetes è una piattaforma molto comoda per fornire questo servizio. Sì, è possibile che a un certo punto smetteremo di parlare di Kubernetes in generale come di un'applicazione di business ordinaria. Ma in profondità, per i fornitori e gli ingegneri, ci sarà sempre Kubernetes, dove tutto questo sarà realizzato.
Azat Khadiev: Un tema leggermente diverso. Esiste un concetto chiamato ingegnere fullstack. Cosa ne pensi? Esistono davvero?
Pavel Selivanov: Em... Ingegnere Fullstack... Beh, credo che sia importante separare queste cose… Sai, c'è una cosa chiamata persone a forma di T. Servono persone del genere nell'industria di oggi? Sì, assolutamente. Abbiamo bisogno di persone che abbiano una visione ampia, ma allo stesso tempo siano esperti in un'area specifica. E qui l'ingegnere Fullstack è lo stesso: una persona che fa tutto. Cominciando dallo sviluppo frontend, test, backend, server e tutto il resto. Non credo che in una grande azienda possa occuparsene una sola persona, senza avere specializzazioni specifiche in ciascuno di questi aspetti. Ma avere solo una specializzazione ristretta, dicendo “intorno a questo non so cosa succede” — questo non funziona nemmeno nel mondo moderno. Quindi, qui direi… la parola Fullstack la scarterei. Abbiamo davvero bisogno di ingegneri. Abbiamo bisogno di DevOps. Sento che presto rivedremo questo aspetto. E non saranno più necessari.
Azat Khadiev: Puoi approfondire?
Pavel Selivanov: Mi sembra che nel settore arriveremo a un punto in cui i ruoli Dev e Ops saranno superati. Se abbiamo bisogno di specialisti e stiamo cercando… Abbiamo bisogno di un certo tipo di sviluppatore, di amministratori specifici, ora che abbiamo ingegneri DevOps — e adesso arriveranno anche ingegneri di produzione e SRE. Tuttavia, ciò di cui abbiamo realmente bisogno sono ingegneri che vogliamo assumere. Il background, in gran parte, non è importante. Perché… Ad esempio, un SRE afferma che i problemi di infrastruttura sono sempre di natura software. E quindi… Dovremmo assoldare sviluppatori — considerando che uno sviluppatore è un ingegnere — farli integrare nel team di supporto e risolveranno questi problemi proprio come affrontano le problematiche aziendali attraverso il codice, usando l'ingegneria in generale.
Azat Khadiev: E da questo punto di vista… Come si colloquia con questi ingegneri?
Pavel Selivanov: Oh, bella domanda. Probabilmente è già oltre ciò che riesco a capire in questa vita. Ma potrei fare un esempio. Non ha nulla a che fare con il colloquio. Riguarda il nostro sistema educativo in Russia. Nell'IT sappiamo che il nostro sistema educativo è molto obsoleto, non è come dovrebbe essere. Parlo in media della vastissima Russia — e di cosa sta succedendo lì. Le persone che si laureano non sono affatto pronte a entrare immediatamente nel mondo dello sviluppo web, in aziende tecnologiche. E questo è un problema. Li stiamo formando su cose strane, mentre dovremmo insegnare a sviluppare per Android, per iOS, come utilizzare Git e tutte queste cose. In realtà sembra che non sia così. L'università è un periodo in cui per la maggior parte pagano i genitori. Per tutta la tua vita. E puoi dedicare cinque anni della tua vita ad apprendere in modo approfondito. E studiare tutto questo concetto T-shaped. Quando puoi studiare all'università cos'è un sistema di controllo versione, quali sono i modelli di sviluppo, come testare tutto questo, quali sono i database, i bilanciatori. E quando inizi a lavorare, inizia a specializzarti in un'area specifica. E in questo modo otteniamo ingegneri. E il nostro sistema educativo in Russia è molto più vicino alla verità di quanto pensiamo. Ci viene fornita una buona preparazione matematica, una buona preparazione algoritmica, ci viene dato un'idea sui linguaggi di programmazione. E riguardo ai colloqui, mi sembra che ci si avvicini a questo. Dobbiamo effettuare colloqui agli ingegneri. Abbiamo bisogno della parte superiore della lettera T del concetto T-shaped. Perché la linea verticale della lettera T la acquisirà.
Azat Kadiyev: Sì, interessante. Dopo cinque anni dall'università, mi sembrava che la mia istruzione fosse strana e inadeguata. Poi, con il progredire del lavoro, quando i compiti sono diventati più complessi e i progetti più ampi, mi sono reso conto che no, mi hanno insegnato cose molto importanti. Pavel, grazie. È stato molto interessante ascoltare le tue risposte. Ascoltiamo il tuo intervento.
Pavel Selivanov: Grazie a voi.
Fonte: habr.com
