En tant que CTO d'une agence technologique, j'évalue constamment de nouveaux outils, processus et services.

Récemment, j'ai examiné la plateforme DigitalOcean dans le cadre d'une stratégie de haute disponibilité que nous développons pour les moments où AWS/S3 n'est pas suffisant : lorsque vous souhaitez résister à une panne massive d'un fournisseur de cloud entier.

Tous les déploiements de Dojo4 commencent par AWS pour une raison évidente : c'est la norme à laquelle tous les autres services cloud sont comparés. Il a l'avantage supplémentaire pour une agence de pouvoir désigner AWS comme une « option par défaut saine » pour les logiciels que nous livrons aux clients ; en tant que gorille de 800 livres, son utilisation est défendable. Cependant, certains rares clients ont exprimé des inquiétudes concernant les pannes d'AWS affectant leurs sites et applications, en particulier les applications de surveillance qui sont censées signaler les erreurs concernant de telles pannes : un problème récursif. Pour ces cas, nous avons examiné des déploiements statiques équilibrés entre les fournisseurs de cloud avec DNS, et DigitalOcean figurait sur la liste restreinte des concurrents pour créer et déployer des sites statiques simples hébergés par Apache à cette fin comme solution de secours pour nos sites habituellement hébergés sur AWS.

Récemment, DigitalOcean (DO) a eu un petit problème lié à ses pratiques de sécurité : https://github.com/fog/fog/issues/2525.

On pourrait résumer ce problème ainsi : lorsque vous démarrez une nouvelle machine cloud, il peut y avoir ou non des données sensibles d'un utilisateur précédent sur le disque et, lorsque vous arrêtez votre propre machine cloud, vous pouvez exposer vos propres données sensibles à un tiers aléatoire. Leur service offre un moyen de nettoyer tout cela, mais ce n'est pas le paramètre par défaut - le paramètre par défaut est de laisser ce qui était sur le disque exposé pour que le prochain client puisse fouiller.

C'est une très mauvaise stratégie par défaut.

Sur Twitter, j'ai suggéré que je n'étais pas surpris par cette stratégie laxiste, mais que j'étais déçu de la manière dont DO s'était comporté pendant la divulgation. Pendant un bref échange sur Twitter, on m'a demandé de résumer la source de ma non-surprise :

@drawohara Si vous vouliez prendre le temps de le mettre dans un e-mail, je le lirais et le partagerais avec toute l'équipe, et je l'apprécierais beaucoup. :)

— John Edgar (@jedgar) 30 décembre 2013

Donc, avec le recul et en essayant vraiment d'être utile, je tiens ma promesse et j'explique pourquoi j'ai traîné les pieds pour déplacer quoi que ce soit vers la plateforme de DigitalOcean. (Veuillez noter que cette liste compromet des sentiments et des impressions uniquement, mais qu'ils ont été quelque peu validés et renforcés par le récent fiasco de nettoyage de disque) :

• En visitant la page d'accueil de DO, on est accueilli par un message marketing criard qui hurle « bon marché et rapide »

étant donné que la plateforme est « conçue pour les développeurs », je trouve personnellement étrange que l'équipe n'ait apparemment pas anticipé que les développeurs recevraient le message clair de « bon, rapide et bon marché » en choisissant les deux derniers avec DO.

• Ensuite, on reçoit un joli message de confirmation indiquant qu'en tant que start-up, DO est motivé à démontrer une croissance très, très rapide

cela devrait donner la nausée à tout ingénieur d'exploitation.

• En parcourant le site, on trouve une référence constante au tambour « rapide et bon marché », par exemple dans le programme de parrainage

qui martèle le message et suggère aux développeurs de vendre à leurs amis le rapide et le bon marché sans même un soupçon d'information sur la robustesse, la cohérence ou la sécurité.

• En lisant le blog, il était très clair que DO suit un cycle de développement maigre, axé sur l'utilisateur :

https://www.digitalocean.com/blog_posts/a-lean-start-for-digital-ocean

et bien que j'admire, approuve et recommande ce type d'approche pour les logiciels en général, construire la sécurité et la robustesse de manière itérative ne semble pas être le point fort de ce type d'entreprise - malgré ce que les VC (qui n'ont jamais combattu une faille de sécurité dans la nature) doivent penser que c'est génial. Certaines choses nécessitent une expérience massive et une planification descendante : une pile qui permet à ses utilisateurs de stocker des données et d'exécuter du code, qu'il s'agisse d'un navigateur ou d'un cloud, entrent dans la catégorie « je veux que quelqu'un extraie un code réel de systèmes réels avec une histoire d'attaques » et non « nous écoutons les utilisateurs et itérons rapidement, en apprenant en cours de route. »

Donc, ne vous méprenez pas, j'évalue toujours DigitalOcean comme une pile programmable agréable sur laquelle déployer des sites statiques simples et je veux certainement les voir réussir, mais j'ai des inquiétudes concernant leur culture et si c'est le type de culture qui pratique des pratiques de sécurité défensives plutôt que réactives et s'ils pourront maintenir leur croissance, leur prix et, en fin de compte, leur financement lorsqu'ils rattraperont les autres acteurs du cloud à cet égard. La lecture de leurs attitudes et croyances dans le contexte du récent débâcle (https://github.com/fog/fog/issues/2525) me donne quelques raisons d'en douter.