Alle aziende si chiede una innovazione continua, grazie in particolare alla flessibilità data dalle piattaforme infrastrutturali cloud di cui possono fare uso. Ma nessuna azienda può mettere a rischio l'affidabilità dei servizi che eroga in nome dell'innovazione. È un dilemma non certo nuovo, che con il boom del cloud e soprattutto delle potenzialità dello sviluppo cloud-nativo si è certamente intensificato. E che ha spinto diverse aziende ad operare, nella loro parte di sviluppo, a diverse velocità. Con rilasci più innovativi e frequenti là dove è possibile, con un occhio più attento alla stabilità là dove è richiesto.

Una strada del genere viene seguita anche in Docebo: la software house propone un Learning Management System in cloud che le aziende utenti possono gestire per la propria formazione. Logicamente, una piattaforma del genere trae un notevole vantaggio dall'incorporare eventuali nuove componenti infrastrutturali. Ma l'innovazione può essere spinta nello sviluppo di nuove funzioni, non deve destabilizzare quelle che già ci sono e che supportano gli ambienti formativi delle imprese utenti.

Per questo la software house si è organizzata in maniera mirata. I team Innovation possono sperimentare più liberamente le nuove tecnologie messe a disposizione dall'hyperscaler di riferimento (Docebo è partner di AWS), con rilasci più rapidi ed in particolare nello sviluppo di nuove funzioni o soluzioni. Parallelamente, i team Architecture seguono un percorso più graduale nel far evolvere quello che già esiste e che deve intrinsecamente restare una piattaforma solida per gli utenti. Ovviamente le due strategie di sviluppo non sono slegate: esiste una roadmap generale che le coordina e soprattutto c'è un percorso definito di confluenza del "nuovo" nel "tradizionale". A chiudere un ciclo in realtà continuo di innovazione.

Innovare con stabilità

In questo modo è possibile per Docebo seguire due direttrici apparentemente contrastanti: innovazione e stabilità. Nello sviluppo delle nuove componenti e dei nuovi prodotti del LMS - spiega infatti Andrea La Scola, Cloud architect e Senior Software Engineer di Docebo - il team di sviluppo ha un po' più di autonomia "nell'adottare tecnologie cloud-native e nel dare un time-to-market più rapido. Ci possiamo permettere di andare velocemente e seguire strade nuove anche perché si parte in un certo senso da zero: la base clienti dei nuovi prodotti deve ancora crescere. Tutto poi comunque va a confluire verso la parte Architecture. È un approccio sensato perché permette di adottare strade diverse per prodotti che hanno all'inizio necessità diverse: da un lato solidità e performance, dall'altro velocità e adozione di tecnologie innovative".

La parte Innovation di Docebo può in particolare spingere l'acceleratore negli approcci DevOps e infrastructure as code, nello specifico puntando su Terraform e su AWS Cloud Development Kit (AWS CDK) via TypeScript che, sottolinea La Scola, "mette già i software engineer a loro agio nella scrittura di codice di infrastruttura, il che a sua volta facilita la diffusione dello strumento all'interno del team".

ImpresaCity, Par-Tec e One Identity hanno organizzato un webinar incentrato su DevSecOps e secrets management: visita questa pagina per saperne di più

Alla confluenza tra più nuovo e meno nuovo, le velocità dei team Innovation ed Architecture si armonizzano. Un passo che ha implicazioni non solo ma tecniche ma soprattutto di approccio ed organizzative, perché il punto di partenza operativo è diverso. I team Innovation possono puntare su un DevOps magari spinto e sull'implementazione di nuove funzioni direttamente in produzione. I team Architecture no: "Sviluppano i loro servizi - spiega Raffaele Quitadamo, Head Of Software Development & Architecture di Docebo - e li passano al team architect per la validazione, la scrittura del codice Terraform e poi il deploy in produzione".

Attenzione e sicurezza

Quando nuove funzioni o componenti diventano parte del "core" del LMS, spiega Quitadamo, "I team di Innovation che le hanno sviluppate rimangono i detentori della conoscenza e dei servizi infrastrutturali. Il lavoro fatto con AWS CDK viene mantenuto, il team architect si occupa semplicemente del monitoraggio e non interviene direttamente nel ciclo di rilascio. I micro-team restano responsabili del deploy".
"Dare la responsabilità ai team anche del rilascio - spiega Andrea La Scola - dovrebbe aiutare ad alleggerire il lavoro delle figure di governance e responsabilizzare chi è più 'vicino' al prodotto, che dovrebbe quindi conoscerlo meglio e sapere come e dove intervenire quando necessario... Certo ci vogliono seniority e metodologie ben definite, per fare quello che in altri casi viene demandato alla parte di architettura".

Trasversale a tutto questo c'è un controllo costante della cyber security, per evitare qualsiasi problema correlato allo sviluppo "veloce" e alla gestione dinamica ed elastica di risorse in cloud. "C'è una governance ben precisa - mette in evidenza La Scola - con figure che seguono la parte di sviluppo, la definizione di policy IAM corrette e tool automatici mirati, ad esempio per l'analisi del codice e dell'infrastruttura rilasciata, in modo da evidenziare punti potenzialmente deboli come policy troppo ampie e bucket pubblici". "Il team security - sottolinea Raffaele Quitadamo - interviene sia prima sia dopo lo sviluppo. Prima, attraverso l'approvazione delle soluzioni e dei servizi. Dopo, con un controllo costante che prevede ad esempio il penetration testing delle API e l'uso di tool mirati".