En el documento S-1 de Cloudflare hay una sección que comienza así: "Internet no se concibió para lo que se ha convertido".
Esta frase expresa la idea de que Internet, que empezó como un experimento, se ha convertido en una herramienta indispensable en nuestro día a día y en nuestro trabajo, pero además de para lo que se diseñó, necesitamos seguridad, rendimiento y privacidad.
Podemos decir algo parecido de la nube. La nube no se creó para lo que debe llegar a ser.
La incorporación de servicios como Amazon EC2 fue, sin duda, una enorme mejora respecto a la antigua forma de comprar e instalar bastidores de servidores y sistemas de almacenamiento, que luego había que mantener.
Pero, por su naturaleza, la nube era una virtualización de la antigua infraestructura del mundo real y no un replanteamiento radical de cómo debe ser la informática para responder a las demandas de las empresas basadas en Internet. Es como si las locomotoras de vapor se sustituyeran por eficientes locomotoras eléctricas, pero siguieran necesitando una chimenea en la parte superior y tuvieran que parar para llenar el depósito de agua cada trescientos kilómetros.
La nube sustituyó los rituales de compra de servidores e instalación de sistemas operativos por nuevos y ahora conocidos rituales que consisten en la selección de regiones, dotación de máquinas virtuales, y mantenimiento de código artificialmente activo.
Pero, en el camino, se vislumbran destellos de luz a través de la nube en forma de lambdas, perímetros, funciones o tecnología sin servidor. Todos intentan poner nombre a un modelo de informática en la nube destinado a Internet que promete mejorar la productividad de los desarrolladores. Es un modelo que, en lugar de virtualizar máquinas o discos, o encapsular cosas en contenedores, dice: "Escribe código, nosotros lo ejecutaremos, no te preocupes por los detalles como el escalado o la ubicación".
Lo llamamos la supernube.
Las bases de la supernube son los servicios de procesos y datos que garantizan la eficiencia y la escalabilidad ilimitada de la ejecución de aplicaciones de cualquier tamaño sin la pesada carga de la nube tal y como es hoy día.
Las bases de la supernube
Hace algunos años, un movimiento llamado NoSQL desarrolló nuevas formas de almacenar y procesar datos que no dependían de las bases de datos. Se desarrollaron almacenes clave-valor y almacenes de documentos porque, en lugar de pensar en los datos con la granularidad de las bases de datos o las tablas o incluso las filas, establecían una conexión directa entre el código y los datos a un nivel sencillo.
Puedes pensar en NoSQL como una iniciativa hacia la granularidad. Y funcionó. Los almacenes NoSQL, los almacenes clave-valor y los almacenes de objetos (como R2) han proliferado. El auge de MapReduce para el procesamiento de datos también tiene que ver con la granularidad. Gracias a la división del procesamiento de datos en unidades fácilmente escalables (funciones Map y Reduce) fue posible gestionar enormes cantidades de datos de forma eficiente y escalar código en función de las necesidades.
Lo mismo ocurre con el código de la nube. Al igual que los programadores no siempre querían pensar en segmentos del tamaño de una base de datos, no deberían tener que pensar en segmentos del tamaño de una máquina virtual o de un contenedor. Es un proceso ineficiente y no tiene nada que ver con el trabajo real de escribir código para crear un servicio. Es innecesario y aparta la atención del valor real de programar algo para que se haga realidad.
En la teoría de la programación distribuida, la granularidad existe desde hace mucho tiempo. El modelo de comunicación de procesos secuenciales (CSP) consiste en procesos diminutos que realizan tareas y transfieren datos (ayudó a inspirar el lenguaje Go). En el modelo de actor, los mensajes pasan entre varios actores que cambian el estado interno, incluso el cálculo lambda trata de funciones discretas que actúan sobre los datos.
La programación orientada a objetos hace que los desarrolladores razonen sobre objetos (no sobre máquinas o discos virtuales). En CORBA, y otros sistemas similares, existe el concepto de un gestor de solicitudes de objetos que permite que los objetos se ejecuten y se acceda a ellos de forma remota en un sistema distribuido sin conocer los detalles de dónde o cómo se ejecuta el objeto.
La teoría de la computación se aleja de las máquinas dedicadas (virtuales o reales) y apunta a la ejecución del código y los datos en la supernube, tratando los detalles de la ejecución del código y la localización de los datos de forma automática y eficiente.
Así que, tanto si escribes tu código dividiéndolo en funciones como si creas funciones o programas enteros, las bases de la supernube permiten a tu código beneficiarse de su eficiencia. Y hay más.
La ventaja de la supernube
La supernube facilita el escalado porque nadie tiene que pensar en cuántas máquinas virtuales hay que proveer, y tampoco hay que mantener máquinas virtuales de espera activa por si hay una avalancha de visitantes. Al igual que MapReduce (que tiene su origen en el cálculo lambda) escala según las necesidades, también debería hacerlo la informática dedicada a una finalidad general.
Pero no se trata solo de escalar. En la supernube, tanto el código como los datos son móviles y se desplacen por la red. Une los datos al código (como con Durable Objects; hola modelo de actor) y tendrás una base para aplicaciones que se puede adaptar a cualquier tamaño y moverse cerca de los usuarios según sea necesario para proporcionar el mejor rendimiento.
Como alternativa, si tus datos no son movibles, les acercamos tu código, sin importar cuántas veces necesites acceder a ellos.
No solo eso. Trabajar a este nivel de flexibilidad significa que el código que aplica una ley de privacidad o alojamiento de datos sobre dónde se pueden procesar o almacenar los datos puede operar a nivel de usuarios u objetos individuales. El mismo código se puede comportar de forma diferente e incluso se puede ejecutar en un país completamente distinto en función de dónde se almacenen sus datos asociados.
Una supernube tiene dos efectos interesantes en el coste de ejecución de un programa. En primer lugar, lo abarata porque solo ejecutas lo que necesitas. No se necesitan máquinas virtuales asignadas a la espera de recibir trabajo, ni máquinas inactivas por las que pagas por si acaso. El código se ejecuta o no se ejecuta. Escala según sea necesario. Solo pagas por lo que necesitas.
En segundo lugar, crea una plataforma de procesos más eficiente que es mejor para todos. Obliga a la plataforma de procesos (p. ej. nosotros) a ser lo más eficiente posible. Tenemos que ser capaces de iniciar el código rápidamente por razones de rendimiento y escalabilidad. Tenemos que utilizar las CPU de forma eficaz porque ningún cliente nos paga por tener CPU inactivas. Además, es mejor para el medio ambiente porque las máquinas de la nube funcionan a niveles muy altos de utilización. Este nivel de eficiencia es lo que permite a nuestra plataforma escalar hasta las 10 millones de solicitudes que Cloudflare Workers ha procesado mientras has acabado de leer esta frase.
Además, esta plataforma de procesos escala mucho más allá de un equipo, de un centro de datos, o de un país. Con el software adecuado (que hemos desarrollado) se adapta a la escala de Internet. El software asigna los recursos automáticamente en todo el mundo, moviendo las conexiones, los datos y el procesamiento para conseguir alta eficiencia y experiencias óptimas para los usuarios finales.
Procesos y almacenamiento eficientes, una red global que está en todas partes, unidos por un software que convierte el mundo en una sola nube. La supernube.
Bienvenidos a la supernube
La supernube es eficaz, escalable, accesible, privada y rentable. La elección de una región para tu aplicación, la dotación de máquinas virtuales, o el trabajo de averiguar cómo escalar automáticamente contenedores o preocuparse por los arranques en frío parecerá absurdo, difícil, anacrónico, una pérdida de tiempo, inflexible y caro.
Afortunadamente, Cloudflare lleva años desarrollando la alternativa a esa nube tradicional en nuestra red y en nuestra plataforma para desarrolladores. La supernube. El término puede ser nuevo, pero no significa que no sea real. Hoy día, más de un millón de programadores están desarrollando en la supernube.
Todos quieren ejecutar código en un solo equipo y mejorarlo. Es mucho más fácil trabajar así. Resulta que tenemos un equipo que se adapta a la escala de Internet: un superordenador global y distribuido. Es la supernube y desarrollamos nuestros productos en ella. Tú también puedes unirte a ese millón de programadores y empezar a desarrollar en ella.
Llevamos doce años desarrollando la supernube, y hace cinco años la pusimos a disposición de los desarrolladores a través de Cloudflare Workers. Cloudflare Workers se creó para mejorar la escala y el rendimiento desde el primer día, ya que se ejecuta en nuestra red global.
Y así es como te damos la bienvenida a la supernube y a la Semana del desarrollador de Cloudflare 2022.
Como ocurre con todas nuestras Semanas de la innovación, estamos encantados de empezar otra semana más anunciando novedades que permiten desarrollar más casos de uso en la supernube. De hecho, se basa en la plataforma para desarrolladores de Workers, que es lo que nos da la capacidad para seguir ofreciendo nuevos bloques de creación a nuestros usuarios. Esta semana, no solo vamos a hablarte de todas las nuevas herramientas con las que puedes jugar, sino también de cómo desarrollamos muchas de ellas, cómo puedes utilizarlas y lo que nuestros clientes están diseñando hoy con ellas en producción.
Ver en Cloudflare TV
Puedes ver la retransmisión completa de nuestro programa semanal This Week in Net aquí, o escucharlo en formato audio/podcast.