VIII. Abrazar la nube

Algunos informáticos todavía se consuelan viendo luces parpadeantes en el armario de las escobas.

Por este motivo, la adopción de la nube sigue siendo contraria a los acuerdos contractuales estándar. A decir verdad, los informáticos tienen razón. Confías tus datos a una empresa sin rostro. 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 de lujo se filtra, y algo va mal. Y cuando lo hace, no queda nada que golpear con la llave inglesa. La obsesión por el control es un atributo inusualmente bienvenido en un administrador de sistemas, y la nube le quita el control.

Cuando hablamos de adoptar plenamente la nube, a menudo el informático habitual no está totalmente familiarizado con lo que eso significa. Hace tiempo que están de acuerdo con la virtualización de servidores, pero puede que no se sientan cómodos con la idea de que estos servidores virtuales son clones efímeros. Como el personaje de Sam Bell en Moon, su disco duro podría borrarse en cualquier momento, y no debería importar, porque el siguiente clon siempre está listo para salir. 

Ahora los contenedores de nuestra granja de servidores virtuales tienen nombres como 050487d5cab85820e. De esta manera es más difícil de conseguir unido.

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

Eso es lo que significa adoptar plenamente la nube. No es sólo ejecutar algunos servidores virtuales. Significa desarrollar aplicaciones sin estado de escalabilidad horizontal, que puedan instalarse, arrancarse y eliminarse como parte de un coro orquestado de servidores. Significa mantener los activos estáticos fuera del núcleo de la aplicación. Significa confiar en servicios bajo demanda para bases de datos, cachés, enrutamiento y almacenamiento. En algún lugar, debajo de todo esto, hay servidores, pero nunca sabrás sus nombres. Están desapareciendo en un mar eléctrico de "infraestructura". Pronto solo habrá código, y servicios como AWS Lambda y Google AppEngine nos están empujando más en esa dirección. Lo cual es bueno.

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

Y a veces saldrá mal. Por mucho que los proveedores de la nube hablen de redundancia y de eliminar los puntos únicos de fallo, en última instancia, esto es imposible. Sólo los ingenuos confían en que los servicios distribuidos de conmutación por error, multizona y agrupados en bases de datos estén realmente libres de fallos. Los propios sistemas que coordinan la redundancia se convierten en puntos únicos de fallo. Es como una ley inmutable de la física que el diseño para eliminar fallos arquitectónicos introducirá otros diferentes y más complejos.

Aun así. Si se tiene en cuenta el tiempo de actividad de todo el sistema, se sopesan las ventajas de comodidad y se considera el nivel de experiencia subyacente a la infraestructura, todo ello a pagar por ciclo de procesador, sigue siendo mejor que confiar en ese servidor del armario. Y, además, el informático que pretende controlarlo todo suele tener un gran punto ciego que cubre el punto único de fallo de mayor riesgo del sistema: Ellos mismos.

Lecturas obligatorias:

• Luna 2009 drama de ciencia ficción dirigido por Duncan Jones y escrito por Duncan Jones y Nathan Parker
• Service Statelessness Principle principio de diseño aplicado para diseñar servicios escalables
• La ley de las abstracciones con fugas

Próximo mes: Cachear primero (preguntar después)