Intervista sull'eccellenza dei microservizi: parliamo di .NET

Immagina di avere tra le mani un sistema molto complesso, suddiviso in diversi microservizi. Il codice che scrivo va bene, ma ogni volta che vado a fare un colloquio di lavoro sorge una domanda: come faccio a chiedere se l'altra persona lo capisce davvero? Chiunque può memorizzare questi concetti teorici, ma quando si tratta dell'implementazione specifica in .NET, i dettagli diventano confusi.

Abbiamo parlato con molte squadre e abbiamo scoperto che tutti hanno gli stessi grattacapi. Alcune persone chiedono in modo troppo superficiale e si limitano a chiedere "Cosa sono i microservizi?"; alcune persone scavano troppo in profondità e rimangono invischiate in un certo elemento di configurazione impopolare. L’intervistatore potrebbe aver appena iniziato a lavorarci su da solo e, dopo aver posto molte domande, si sente ancora come se non conoscesse i trucchi del mestiere.

In effetti, intervistare è un po’ come eseguire il debug del codice. È necessario sapere dove si trovano i punti di interruzione critici.

Dalla teoria all'implementazione: cosa stai chiedendo esattamente in .NET?

I microservizi sembrano nobili, ma quando si tratta di progetti .NET si tratta solo di una serie di scelte specifiche e operazioni pratiche. Ad esempio, per la containerizzazione utilizzate Docker o direttamente Kubernetes? Come progettare il gateway API? Devo guidarlo da solo se trovo il servizio? Dietro queste domande c’è una profonda comprensione dell’architettura.

C’è un malinteso comune: molte persone conoscono a memoria lo stack tecnologico, ma non sanno spiegare perché hanno scelto questo invece di quello. Nell'ecosistema .NET sono disponibili numerosi strumenti e framework e ogni scelta ha il suo prezzo. Durante l'intervista, vogliamo sentire il pensiero che sta dietro invece di elencare i sostantivi.

"Se la comunicazione tra i servizi rallentasse improvvisamente, da dove inizieresti?" Non esiste una risposta standard a questa domanda, ma può dire se una persona ha davvero lavorato molto o ha letto solo qualche blog.

Come scopri le tue vere capacità?

Non concentrarti solo sui concetti. Passando direttamente allo scenario: "Supponiamo ora di avere un servizio di ordine e un servizio di inventario e che l'inventario venga detratto quando viene creato l'ordine. Come garantite che i dati non vengano confusi?"

A questo punto, la risposta potrebbe coinvolgere code di messaggi, transazioni distribuite o eventualmente progetti coerenti. In .NET è possibile utilizzare MassTransit o NServiceBus oppure utilizzare direttamente RabbitMQ. Ma il punto non è il nome dello strumento, ma la scelta: perché viene utilizzato in questo modo? Qual è il costo?

Parla dell'esperienza del fallimento. Chi non ha inciampato in una trappola sulla strada verso i microservizi? Timeout della rete, gestione confusa della configurazione, monitoraggio inadeguato... Ascolta quali problemi specifici ha riscontrato l'altra parte e come li ha risolti. Questo è molto più utile di una teoria perfetta.

L'ambiente .NET ha una caratteristica: è allo stesso tempo tradizionale e moderno. Molte squadre sono state separate dai vecchi sistemi singoli e portano con sé un pesante bagaglio storico. Le buone domande dell'intervista dovrebbero rivelare la capacità dell'altra persona di gestire questa complessità.

Mantienilo semplice, ma non troppo semplice

Quando si progettano i problemi, è facile arrivare a due estremi: troppo astratto o troppo banale. Le buone domande per un colloquio dovrebbero essere come scrivere un codice, con moduli chiari ma spazio per l'espansione.

Ad esempio, quando chiedi informazioni su log e monitoraggio, puoi dire: "I microservizi sono sparsi e anche i log sono sparsi. Come si mettono insieme gli indizi?" Ciò può portare allo stack ELK, Seq o direttamente ad Azure Application Insights. Ma più in profondità, come si definiscono i livelli di log? Come evitare di avere troppi log e di non riuscire a trovare i punti chiave?

Oppure chiedere alla sicurezza: "Con così tanti servizi, come gestire l'autenticazione?" Al momento potremmo parlare di OAuth2, JWT o rotazione della chiave API. In .NET, IdentityServer è una scelta comune, ma non è l'unica risposta.

La chiave non è se l’altra parte conosce un determinato strumento, ma se comprende la natura del problema.

la nostra esperienza

Ad essere onesti, non sapevamo come chiedere fin dall'inizio. All'inizio, l'elenco delle domande sembrava l'indice di un libro di testo e dopo l'intervista mi sentivo ancora insicuro.

Successivamente abbiamo gradualmente capito che il colloquio non è un esame, ma una conversazione. Vuoi capire come pensa l'altra persona e anche l'altra persona sente l'atmosfera tecnica della tua squadra. Quindi ora preferiamo elaborare uno scenario di vita reale semplificato e discutere insieme le possibili soluzioni. Ciò che può essere esposto in questo processo è molto più della risposta standard.

L'ecosistema dei microservizi .NET è in continua evoluzione e emergono costantemente nuovi strumenti e modelli. Devi adattarti alle domande del colloquio e non puoi sempre restare fedele alla stessa routine di qualche anno fa. Ma gli aspetti fondamentali non sono cambiati: solide basi di programmazione, chiaro pensiero progettuale e volontà di risolvere problemi pratici.

Qualche parola di conversazione

In ultima analisi, i colloqui riguardano la ricerca di persone con cui è possibile risolvere insieme i problemi. L'architettura dei microservizi in sé è abbastanza complessa e ciò di cui il team ha bisogno è un partner in grado di semplificare la complessità.

Quindi, quando ti prepari per un colloquio la prossima volta, pensa meno alle "domande standard" e più a "quali problemi abbiamo effettivamente incontrato". Parla di quelle piccole lotte e grovigli reali e le risposte spesso si trovano lì.

I dettagli tecnici diventeranno obsoleti, ma il modo in cui li pensi no. Trovare qualcuno con cui puoi pensare di andare è probabilmente la cosa più importante da fare durante un colloquio.

Fondata nel 2005,kpowerè dedicata a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare,kpowerintegra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate.kpowerha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.