Como CTO de una agencia de tecnología, constantemente estoy evaluando nuevas herramientas, procesos y servicios.

Recientemente he estado mirando la plataforma DigitalOcean como parte de una estrategia de ultra-alta disponibilidad que hemos estado desarrollando para aquellos momentos en los que AWS/S3 no es suficiente: cuando quieres resistir una falla masiva de un proveedor de servicios en la nube completa.

Todos los despliegues de Dojo4 comienzan como despliegues de AWS por la razón obvia: es el estándar por el cual se juzgan todos los demás servicios en la nube. Tiene el beneficio adicional para una agencia en que podemos señalarlo como una 'opción predeterminada sensata' para el software que entregamos a los clientes; como el gorila de 800 libras, su uso es defendible. Sin embargo, algunos clientes raros han expresado su preocupación de que las fallas de AWS afecten sus sitios y aplicaciones, en particular las aplicaciones de monitoreo que se supone que deben reportar errores sobre dichas fallas: un problema recursivo. Para estos casos, hemos estado mirando despliegues estáticos equilibrados entre proveedores de nube con DNS, y DigitalOcean ha estado en la lista corta de contendientes para crear y desplegar sitios estáticos simples alojados por Apache con este propósito como una medida de seguridad para nuestros sitios alojados normalmente en AWS.

Recientemente DigitalOcean (DO) tuvo un pequeño problema relacionado con sus prácticas de seguridad: https://github.com/fog/fog/issues/2525.

Se podría resumir este problema como: cuando inicias una nueva caja en la nube, puede o no tener datos sensibles de algún usuario anterior en el disco y, cuando apagas tu propia caja en la nube, puedes exponer tus propios datos sensibles a algún tercero aleatorio. Su servicio proporciona una forma de limpiar todo, pero no es la opción predeterminada - la opción predeterminada es dejar cualquier cosa que estuviera en el disco expuesta para que el próximo cliente la explore.

Esta es una estrategia predeterminada realmente mala.

En Twitter sugerí que no me sorprendió esta estrategia laxa, pero que me decepcionó la forma en que DO manejó la situación durante la revelación. Durante un breve intercambio en Twitter, me preguntaron que resumiera la fuente de mi falta de sorpresa:

@drawohara Si quisieras tomarte el tiempo de ponerlo en un correo electrónico, lo leería y lo compartiría con todo el equipo, y lo apreciaría mucho. :)

— John Edgar (@jedgar) 30 de diciembre de 2013

Entonces, con una visión retrospectiva de 20/20 y tratando de ser útil, estoy cumpliendo mi promesa y explicando por qué he estado retrasando el traslado de cualquiera de nuestras cosas a la plataforma de DigitalOcean. (Tenga en cuenta que esta lista compromete sentimientos e impresiones solamente, pero que han sido validados y fortalecidos en cierta medida por el reciente fiasco de limpieza de discos):

• Al visitar la página de inicio de DO, uno se encuentra con un claro mensaje de marketing que grita 'barato y rápido'

dado que la plataforma está 'construida para desarrolladores', personalmente encuentro extraño que el equipo aparentemente no anticipara que los desarrolladores recibieran el claro mensaje de 'bueno, rápido y barato' uno está eligiendo los últimos dos con DO.

• Luego, uno recibe un bonito mensaje de confirmación de que, como startup, DO está motivado para demostrar un crecimiento muy, muy rápido

esto debería darle a cualquier ingeniero de operaciones una sensación de enfermedad en el estómago.

• Al explorar el sitio, uno encuentra un constante golpeteo del tambor 'rápido y barato', por ejemplo, en el programa de referidos

que martilla el mensaje y sugiere a los desarrolladores que vendan a sus amigos lo rápido y barato sin siquiera un ápice de información sobre la robustez, consistencia o seguridad.

• Al leer el blog, quedó muy claro que DO sigue un ciclo de desarrollo ágil, impulsado por el usuario:

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

y aunque admiro, apruebo y recomiendo este tipo de enfoque para el software en general, construir la seguridad y la robustez de manera iterativa no parece ser el punto ideal para este tipo de negocio, a pesar de lo genial que deben pensar que es para los VC (que nunca han luchado contra una violación de seguridad en la naturaleza). Algunas cosas requieren una experiencia masiva y una planificación de arriba hacia abajo: una pila que permite a sus usuarios almacenar datos y ejecutar código, ya sea un navegador o una nube, entran en la categoría de 'Quiero que alguien extraiga código real de sistemas reales con un historial de ataques' y no 'Escuchamos a los usuarios e iteramos rápidamente, aprendiendo sobre la marcha.'

Entonces, no me malinterpreten, todavía estoy evaluando DigitalOcean como una buena pila programable en la que desplegar sitios estáticos simples y, por supuesto, quiero verlos triunfar, pero tengo preocupaciones sobre su cultura y si es el tipo de cultura que practica prácticas de seguridad defensivas frente a reactivas y si podrán mantener su crecimiento, punto de precio y, en última instancia, financiación cuando, y si, alcanzan a los otros actores de la nube en este aspecto. Leer sus actitudes y creencias en el contexto del reciente debacle (https://github.com/fog/fog/issues/2525) me da alguna razón para dudarlo.