Por qué existe la computación en la nube

Una fecha de lanzamiento que no se puede adivinar bien

Imagina un equipo que prepara el lanzamiento de un producto nuevo en 6 meses. Antes de escribir una sola línea de código, alguien tiene que responder una pregunta que nadie puede contestar con precisión: ¿cuántos servidores van a necesitar el día del lanzamiento? Si calculan bajo, el sitio se cae en cuanto llega tráfico real. Si calculan alto, la empresa acaba de gastar decenas de miles de dólares en máquinas que van a pasar la mayor parte de su vida ociosas, zumbando en un rack, consumiendo electricidad, esperando un pico de tráfico que tal vez nunca llegue.

Ese cálculo antes era inevitable. Comprar un servidor no era una decisión del mismo día. Una orden de compra, una cadena de aprobaciones, el envío del proveedor, la instalación en el rack y la configuración de red fácilmente sumaban semanas antes de que el hardware sirviera para algo. Una vez que llegaba, alguien del equipo tenía que mantenerlo funcionando: aplicar parches de seguridad, reemplazar discos que fallaban, mantener el cuarto frío, y con los años retirarlo y reemplazarlo hubiera o no crecido el negocio hacia esa capacidad.

Este es el mundo que la computación en la nube vino a resolver: una compra grande por adelantado (un gasto de capital, o CapEx) hecha meses antes de necesitar realmente esa capacidad, basada en un cálculo que muchas veces sale mal en un sentido o en otro. Más adelante en este dominio vas a ver este modelo de costo comparado en detalle con la alternativa de pago por uso de la nube.

Una idea más vieja que la computadora personal

Es tentador pensar en la nube como un invento nuevo de los 2000. No lo es. La idea central, dejar que varios usuarios compartan una computadora grande y costosa en vez de que cada uno tenga la suya, viene desde los años 60. Las computadoras mainframe de esa época costaban más de lo que la mayoría de las empresas podía justificar comprar por su cuenta, así que proveedores y universidades construyeron sistemas de tiempo compartido: decenas de personas conectadas a la misma mainframe física a través de terminales remotas, cada una convencida de que tenía la máquina para sí sola. Para mediados de los 60, cientos de empresas vendían acceso a tiempo de cómputo compartido de esta forma.

El tiempo compartido no sobrevivió los 70 ni los 80. Las minicomputadoras, y después las computadoras personales, se volvieron lo bastante baratas para que las empresas simplemente compraran su propio cómputo en vez de rentar una porción del de alguien más. El mercado de mainframes compartidas colapsó, pero la idea de fondo, que muchos usuarios podían compartir un mismo bloque grande de poder de cómputo, nunca desapareció. Solo necesitaba mejor tecnología para volver.

Las 3 piezas que tuvieron que encajar

La computación en la nube moderna necesitó 3 avances separados que convergieran antes de poder funcionar a la escala que ves hoy.

El primero fue la virtualización: software que deja que una máquina física corra varios sistemas independientes y aislados a la vez, de forma segura. IBM ya había probado que esto era posible en mainframes desde los 70, pero se quedó como un truco exclusivo de mainframes durante décadas. Eso cambió en 1999, cuando VMware llevó la virtualización práctica a los servidores x86 comunes que usaba la mayoría de las empresas, convirtiendo una especialidad de mainframes en algo que cualquier centro de datos podía correr. La próxima lección explica exactamente cómo funciona esto.

El segundo fue el acceso a internet confiable y barato. El tiempo compartido de los 60 significaba marcar a una máquina específica a través de una línea dedicada. Una nube tiene que poder alcanzarse desde cualquier lugar, con conexiones de internet ordinarias, algo que solo se volvió realista cuando la banda ancha se extendió durante los 90 y los 2000.

El tercero fue una empresa dispuesta a rentar su capacidad sobrante a gran escala. Amazon ya había construido centros de datos enormes para manejar sus propios picos de tráfico de venta al público, como la temporada navideña, y se dio cuenta de que esa capacidad quedaba casi sin usar el resto del año. En 2006 abrió esa infraestructura al público como Amazon Web Services, con Amazon EC2 para cómputo y Amazon S3 para almacenamiento. Google siguió en 2008 con Google App Engine, y Microsoft lanzó Microsoft Azure en 2010. En apenas 4 años, los 3 proveedores que hoy siguen dominando el mercado ya estaban en línea.

Lo que la nube realmente elimina

Junta las piezas y vas a ver exactamente qué cambió. El juego de adivinar la capacidad casi desaparece, porque puedes agregar o quitar servidores en minutos en vez de semanas. La espera de varias semanas para que el hardware llegue y se instale desaparece, porque no hay hardware que te envíen. La compra grande por adelantado desaparece, porque pagas por lo que usas mientras lo usas en vez de comprar equipo antes de necesitarlo. Y el trabajo de mantenimiento constante, parchar, enfriar, reemplazar discos que fallan, pasa al proveedor, cuyo negocio entero consiste en hacer eso a una escala que ninguna empresa por sí sola podría igualar.

Nada de esto hace nueva otra vez a la idea de los 60. La hace, por primera vez, práctica: segura para correr a escala, alcanzable desde cualquier lugar, y ofrecida como un servicio al que simplemente te suscribes en vez de construirlo tú mismo.

Hacia dónde te lleva esto

Los problemas de esta lección, el cálculo costoso, la compra lenta y el mantenimiento constante, son el "por qué". La próxima lección te da el "qué" formal: la definición exacta que la computación en la nube tiene que cumplir para ganarse ese nombre, para que puedas distinguir un servicio de nube real de un centro de datos que alguien simplemente llama así.