Come CTO di un'agenzia tecnologica, sto costantemente valutando nuovi strumenti, processi e servizi.
Recentemente ho esaminato la piattaforma DigitalOcean come parte di una strategia di alta disponibilità che stiamo sviluppando per quei momenti in cui AWS/S3 non è sufficiente: quando si vuole superare un'interruzione massiccia di un intero fornitore di servizi cloud.
Tutti i deploy di Dojo4 iniziano come deploy AWS per il motivo ovvio: è lo standard con cui vengono giudicati tutti gli altri servizi cloud. Ha il vantaggio aggiuntivo per un'agenzia nel fatto che possiamo indicarlo come una 'scelta sensata' per il software che consegniamo ai clienti; come gorilla da 800 libbre, il suo uso è difendibile. Tuttavia, alcuni rari clienti hanno espresso preoccupazioni sul fatto che le interruzioni di AWS influiscano sui loro siti e applicazioni, in particolare le applicazioni di monitoraggio che dovrebbero segnalare errori su tali interruzioni: un problema ricorsivo. Per questi casi, abbiamo studiato deploy statici bilanciati sui fornitori di servizi cloud con DNS, e DigitalOcean è stato nella lista dei contendenti per creare e distribuire semplici siti statici ospitati da Apache per questo scopo come soluzione di riserva per i nostri normali siti ospitati su AWS.
Recentemente DigitalOcean (DO) ha avuto un piccolo problema legato alle sue pratiche di sicurezza: https://github.com/fog/fog/issues/2525.
Si potrebbe riassumere questo problema come: quando si avvia una nuova macchina cloud, potrebbero esserci dati sensibili di un utente precedente sul disco e, quando si spegne la propria macchina cloud, si potrebbero esporre i propri dati sensibili a terzi casuali. Il loro servizio offre un modo per pulire tutto, ma non è di default - il default è lasciare qualsiasi cosa fosse sul disco esposta per il prossimo cliente da esplorare.
Questa è una strategia di default davvero pessima.
Su Twitter ho suggerito che non ero sorpreso da questa strategia lassista, ma che ero deluso dal modo in cui DO ha gestito la situazione durante la divulgazione. Durante un breve scambio su Twitter, mi è stato chiesto di riassumere la fonte della mia non sorpresa:
@drawohara Se volessi prenderti il tempo di metterlo in un'email, lo leggerei e lo condividerei con tutto il team, e lo apprezzerei molto. :)
— John Edgar (@jedgar)
30 dicembre 2013
Quindi, con il senno di poi e cercando di essere d'aiuto, sto mantenendo la mia promessa e spiego perché ho esitato a spostare qualcosa sulla piattaforma di DigitalOcean. (Si noti che questo elenco compromette solo sentimenti e impressioni, ma che sono stati in qualche modo validati e rafforzati dal recente fiasco della pulizia del disco):
- Visitando la home page di DO si viene accolti da un messaggio di marketing che urla 'economico e veloce'
dato che la piattaforma è 'costruita per sviluppatori', trovo personalmente strano che il team non abbia apparentemente anticipato che gli sviluppatori ricevessero il chiaro messaggio di 'buono, veloce ed economico' si sta scegliendo gli ultimi due con DO.
- Poi si riceve un bel messaggio di conferma che, come start-up, DO è motivata a dimostrare una crescita molto, molto rapida
questo dovrebbe dare a qualsiasi ingegnere operativo una sensazione di malessere.
- Girando per il sito si trova un battito costante del tamburo 'veloce ed economico', ad esempio nel programma di referral
che martella il messaggio a casa e suggerisce agli sviluppatori di vendere ai loro amici veloci ed economici senza nemmeno un brandello di informazioni su robustezza, coerenza o sicurezza.
- Leggendo il blog è stato molto chiaro che DO segue un ciclo di sviluppo lean, guidato dall'utente:
https://www.digitalocean.com/blog_posts/a-lean-start-for-digital-ocean
e sebbene io ammiri, approvi e raccomandi questo tipo di approccio al software in generale, costruire sicurezza e robustezza in modo iterativo non sembra il punto dolce per questo tipo di attività - nonostante quanto sia fantastico per i VC (che non hanno mai combattuto una violazione della sicurezza sul campo) deve pensare che lo sia. Alcune cose richiedono un'enorme esperienza e una pianificazione dall'alto verso il basso: uno stack che consente ai suoi utenti di memorizzare dati ed eseguire codice, sia un browser che un cloud, rientrano nella categoria 'Voglio che qualcuno estragga codice reale da sistemi reali con una storia di attacchi' e non 'Ascoltiamo gli utenti e iteriamo rapidamente, imparando strada facendo.'
Quindi, non fraintendermi, sto ancora valutando DigitalOcean come una bella pila programmabile su cui distribuire semplici siti statici e certamente voglio vederli avere successo, ma ho delle preoccupazioni sulla loro cultura e se è il tipo di cultura che pratica pratiche di sicurezza difensive rispetto a quelle reattive e se saranno in grado di mantenere la loro crescita, il punto di prezzo e, in definitiva, il finanziamento quando e se riusciranno a tenere il passo con gli altri giocatori del cloud in questo senso. Leggere i loro atteggiamenti e convinzioni nel contesto del recente disastro (https://github.com/fog/fog/issues/2525) mi dà qualche motivo per dubitarne.