Algunos informáticos todavía encuentran consuelo en ver lucecitas parpadeando en el cuartito del servidor.

Por eso abrazar la nube sigue yendo a contracorriente de los contratos estándar. Y la verdad es que esos informáticos no van del todo desencaminados. Confías tus datos a una corporación sin cara. No puedes ver dónde están. No puedes estar seguro de que no los estén compartiendo con la CIA. A veces toda esa abstracción tan elegante tiene goteras y algo sale mal. Y cuando pasa, no hay nada a lo que echarle mano con la llave inglesa. La manía por el control es una cualidad inusualmente bienvenida en un administrador de sistemas, y la nube te quita el control.

Cuando hablamos de abrazar la nube de verdad, muchas veces el informático de toda la vida no tiene del todo claro qué significa eso. Lleva tiempo familiarizado con la virtualización de servidores, pero puede que no le resulte cómoda la idea de que esos servidores virtuales son clones efímeros. Como el personaje Sam Bell en Moon, su disco podría borrarse en cualquier momento, y eso no debería importar, porque el siguiente clon siempre está listo para entrar en escena.

Ahora los contenedores de nuestra granja de servidores virtuales tienen nombres como 050487d5cab85820e. Así es más difícil encariñarse.

La primera regla de la ganadería es no ponerle nombre a los animales. Por eso abandonamos los esquemas de nomenclatura de servidores hace mucho tiempo. Ahora los contenedores de nuestra granja de servidores virtuales tienen nombres como 050487d5cab85820e. Así es más difícil encariñarse.

En eso consiste abrazar la nube de verdad. No es solo tener unos servidores virtuales. Significa desarrollar aplicaciones sin estado con escalado horizontal, que pueden instalarse, arrancarse y eliminarse como parte de un conjunto orquestado de servidores. Significa mantener los activos estáticos fuera de la aplicación principal. Significa confiar en servicios bajo demanda para bases de datos, cachés, enrutamiento y almacenamiento. En algún lugar, debajo de todo, hay servidores, pero nunca sabrás cómo se llaman. Están desapareciendo en un mar eléctrico de «infraestructura». Pronto solo quedará el código, y servicios como AWS Lambda y Google AppEngine nos empujan cada vez más en esa dirección. Lo cual es bueno.

Los servidores están desapareciendo en un mar eléctrico de infraestructura.

Y a veces algo saldrá mal. Por mucho que los proveedores de nube hablen de redundancia y de eliminar puntos únicos de fallo, en última instancia, eso es imposible. Solo el ingenuo confía en que los servicios distribuidos con failover, multisona y clústeres de base de datos son verdaderamente infalibles. Los propios sistemas que coordinan la redundancia se convierten en puntos únicos de fallo. Es como una ley inmutable de la física: diseñar para eliminar fallos arquitectónicos introduce otros distintos, más complejos.

Cloud

Aun así. Cuando miras el tiempo de actividad del sistema, valoras los beneficios en comodidad y consideras el nivel de expertise que hay detrás de la infraestructura —todo ello a precio de ciclo de procesador—, sigue siendo mejor que depender de aquel servidor en el armario. Y además, el informático que busca controlarlo todo suele tener un enorme punto ciego sobre el mayor punto único de fallo del sistema: él mismo.

Lecturas recomendadas:

El mes que viene: Caché primero (las preguntas después)