Vai al contenuto principale
BlogLa vostra strategia di sviluppo del cloud è sbagliata?

La vostra strategia di sviluppo del cloud è sbagliata?

La vostra strategia di sviluppo del cloud è sbagliata? Blog Post Immagine di testata in evidenza.

Ho iniziato la mia carriera 20 anni fa come ingegnere del software. Molti di noi - e so di non essere il solo - hanno assistito alla crescita senza precedenti del cloud pubblico e continuano a farlo oggi.

Ci sono fornitori di cloud che hanno un'opinione precisa su come si debba costruire con loro. Noi chiamiamo questo approccio " platform native". Vogliono che si costruisca in modo da utilizzare i loro servizi e i loro strumenti, all'interno del loro ecosistema. Ma i fornitori di cloud non dovrebbero imporre il modo in cui si costruisce e si distribuisce. Al contrario, i vostri carichi di lavoro dovrebbero essere trasportabili, utilizzando strumenti aperti e basati su standard che vi consentano di distribuirli e spostarli ovunque sia opportuno per trovare il miglior adattamento geografico, economico o di prestazioni per il vostro carico di lavoro.

Il percorso di acquisto degli sviluppatori di oggi

Ho commesso degli errori nella scelta del giusto cloud provider. È capitato a molti di noi. Ma queste esperienze, positive e negative, mi hanno permesso di vedere gli schemi del processo di selezione. E ho scoperto cinque fasi nel percorso di acquisto del cloud da parte di uno sviluppatore.

1. Scoprire. Se si viene a conoscenza di qualcosa di nuovo durante un evento, leggendo Stack Overflow o una discussione su Reddit, guardando YouTube o altro, un servizio cloud susciterà il vostro interesse perché non ne avete mai sentito parlare prima. E all'improvviso si pensa: "Che cos'è? In che modo è applicabile a me? Come può aiutarmi?

Ci sono molte altre domande da porre durante la scoperta. L'obiettivo dovrebbe essere quello di ottenere risposte su ciò che rende unica un'offerta cloud, su cosa la differenzia da qualcosa di simile e sulla specifica proposta di valore che presenta al cliente. Che si tratti di un impegno al servizio o di qualcos'altro, è qui che si chiede "Perché?".

2. Valutazione. In questa fase, abbiamo superato le domande e siamo abbastanza sicuri che ci sia qualcosa. È giunto il momento di impegnarsi e di valutare ciò che abbiamo scoperto. Non prevedete un grande impegno di tempo. Di solito bastano 15-20 minuti per immergersi nella documentazione. Ma dovrete approfondire la conoscenza del servizio o dello strumento e valutare le differenze rispetto a ciò che già conoscete.

Anche se è utile capire esattamente quali servizi si stanno valutando, non preoccupatevi se la vostra conoscenza di altri fornitori di cloud è piuttosto limitata. Ad esempio, prendiamo la nostra offerta Kubernetes gestita. Se avete familiarità con le offerte della concorrenza, potete fare alcuni confronti tra queste e Linode Kubernetes Engine.

Ecco un estratto di un caso d'uso valutato da Elliot Graebert, direttore dell'ingegneria del produttore di droni Skydio.

"Le interfacce sono abbastanza identiche, il che rende impossibile dichiararne una migliore. Il loro design è nitido e pulito, senza l'abbondanza di funzionalità prevalente in AWS e Azure. A mio parere, questa semplicità aiuta molto ad entrare, a distribuire la propria applicazione e a tornare a scrivere codice". Aggiunge: "L'incredibile velocità di Linode nell'avviare nuovi cluster k8s piacerà ad alcuni utenti, e il tempo complessivo di distribuzione dei nodi è stato solido".

3. Imparare. Ora siamo pronti a passare alla fase più cruciale. Il motivo è che, durante la fase di valutazione, investirete un po' di tempo, ma è qui che investirete la maggior parte del vostro tempo. Come sviluppatori, abbiamo un milione di progetti che ci passano per la testa. Ora stiamo facendo un po' di esercizio di adattamento per capire se questa offerta cloud vale la pena. Preparatevi a investire ore di apprendimento. La domanda più importante a cui rispondere è: Questo fornitore di cloud e la sua soluzione funzioneranno per il mio prossimo progetto?

4. Costruire. Quale ingegnere non ama mettere le mani su una tastiera? Ma è in questa fase che spesso le cose vanno storte. Ci siamo condizionati a costruire MVP (minimal viable products) quando in realtà abbiamo bisogno di costruire MLP, "minimal lovable products".

Gli MVP sono il minimo indispensabile e non è detto che vi piacciano. Di tutti gli MVP che ho costruito nel corso della mia carriera, non riesco a citarne uno che fosse adatto alla produzione. Oggi, nel mio ruolo, amo mostrare agli sviluppatori come creare un MLP. Il risultato è qualcosa che permette loro di valutare onestamente se l'impegno profuso per realizzarlo valeva o meno il risultato.

5. Scala. Sono tante le domande che vi porrete in questa fase. Nel comprendere la scala, vorrete sapere come sfruttare più regioni, sia per replicare i dati da un punto all'altro per il disaster recovery, sia per esistere in più di una regione. Pensate alla scala non solo dal punto di vista dei processi, ma anche da quello del personale. Se avete bisogno di inserire più persone in questo processo, che cosa significa? 

È inoltre necessario comprendere il processo di integrazione. Che sia attraverso un CLI o API, scoprite cosa è disponibile per aiutarvi ad automatizzare. Siamo in un'ondata di automazione con l'Infrastructure as code (IAC) in testa. Facciamo di più con meno, perché sappiamo che i processi sono scalabili e le persone no. Valutate lo sforzo necessario per creare l'infrastruttura e scalare.

Piattaforma nativa contro cloud nativo

La scelta del cloud continuerà a essere un viaggio evolutivo. Dobbiamo iniziare a considerarlo in modo più oggettivo. Quando mi sono avventurato per la prima volta nel cloud, ho costruito esclusivamente con queste piattaforme e strumenti. Tutta la letteratura tecnica disponibile all'epoca riguardava una particolare piattaforma. Ma man mano che crescevo come ingegnere, ho iniziato a costruire in modo nativo per il cloud, in modo da poter prendere il mio carico di lavoro e spostarlo ovunque, dandomi un maggiore controllo sulle cose che costruivo. E l'ho fatto con l'aiuto di strumenti open source, che mi hanno permesso di adottare standard unificati come CI/CD, IaC e containerizzazione

Se tutto questo è in linea con il vostro modo di pensare e volete costruire in questo modo nativo del cloud, saremo lieti di parlare con voi. Contattate me o qualsiasi membro del team per discutere del vostro percorso di acquisto nel cloud.


Commenti

Lascia una risposta

Il vostro indirizzo e-mail non sarà pubblicato. I campi obbligatori sono contrassegnati da *