Busque en Google "nube nativa" y obtendrá más de 800 millones de resultados. Está claro que la nube nativa es un término importante.. y la gente no tiene muy claro lo que realmente significa. Hace un tiempo, en una conversación con otra persona "del negocio", le dije: "¡Pero si no es nativo de la nube!" Ella asintió sabiamente. Claramente, significa algo, ya que podríamos estar de acuerdo en algunas construcciones complejas usando esa abreviatura, "nativo de la nube" Profundicemos un poco más.
Para definir qué es la nube nativa, tenemos que empezar con una pregunta más sencilla:
¿Qué es la nube?
Todo es cuestión de desagregación
Hace casi 50 años, antes de que se creara Microsoft, los estudiantes de Harvard Bill Gates y Paul Allen escribieron un intérprete de BASIC para uno de los primeros microordenadores del mundo, el MITS Altair 8080. Pusieron todo el programa en una cinta de papel (una de las primeras formas de almacenamiento) y volaron a Nuevo México para mostrar a MITS lo que habían escrito.
En el descenso hacia Albuquerque, Allen se dio cuenta de que no tenía forma de leer la cinta de papel (necesaria para que el intérprete BASIC pudiera cargarla en el Altair 8080). Allen escribió rápidamente un programa para leer la cinta de papel. Funcionó, y el resto es historia.
Si quieres saber lo que significa "agregado", éste es un buen ejemplo. Todo lo necesario para ejecutar el intérprete BASIC de Gates y Allen tuvo que ser escrito por Gates y Allen - ¡incluyendo la rutina para leer el código de la cinta de papel a la memoria del sistema!
Avance rápido hasta la computación en nube, donde el objetivo es desagregar completamente. ¿Desagregar qué? Pues.. todo. La computación está desagregada de todo lo demás, por lo que puede adquirir la cantidad de computación que necesite independientemente de todo lo demás. Lo mismo ocurre con el almacenamiento y la red.
Pero eso es solo infraestructura. La nube también desagrega el software. Mientras que Gates y Allen tenían que escribir todas y cada una de las líneas de código de su aplicación, las aplicaciones en la nube aprovechan hoy los "servicios" para gestionar tareas específicas. En lugar de años de codificación de aplicaciones masivas y monolíticas, las aplicaciones en la nube de hoy se construyen con cientos de líneas de código que enlazan docenas (o cientos) de servicios en la nube.
Cloud es la extensión lógica de la filosofía Unix de componibilidad mejor articulada por Doug McElroy el inventor de la tubería Unix, "Escribe programas que hagan una cosa y la hagan bien. Escribe programas que trabajen juntos"
Esa es la esencia de la nube. Pero, ¿por qué desagregar? En el nivel más sencillo, la desagregación aporta elasticidad y agilidad.
Elasticidad
Los recursos que requiere cualquier carga de trabajo varían con el tiempo. Por ejemplo, James Cameron Avatar superó los límites de los efectos especiales. Para renderizar un solo fotograma se necesitó el equivalente a 3.000 vCPU en la nube durante una hora. Como Avatar se rodó a 48 fotogramas por segundo y duró 192 minutos, había que renderizar más de medio millón de fotogramas. Es decir, más de 1.600 millones de horas de ciclos de CPU virtuales.
La película estuvo en producción un total de 12 años, pero como ocurre con todas las películas, gran parte de la renderización final se produjo cerca del estreno. Cloud proporcionó la elasticidad que el proveedor de efectos especiales de Avatar necesitaba para realizar el trabajo. El productor ejecutivo de VFX David Conley señaló que no podrían haberlo hecho sin AWS.
La elasticidad se aplica a la informática, el almacenamiento, las redes y prácticamente cualquier recurso necesario. La nube facilita y agiliza el aumento y la reducción del uso en función de las necesidades.
Agilidad
El otro beneficio de la nube es la agilidad en todos los sentidos de la palabra. La nube permite:
Agilidad de desarrollo gracias a la mencionada arquitectura de servicios. Los desarrolladores recurren a una amplia gama de servicios y reducen la codificación de años y millones de líneas de código a semanas y miles de líneas.
Una nota al margen es que esta nueva "arquitectura de servicios" se beneficia del efecto red. Cuantas más cargas de trabajo utilicen servicios, más motivados estarán los terceros para desarrollar nuevos servicios. Y cuantos más servicios hay, más se motivan los desarrolladores para utilizar servicios de terceros. Este círculo virtuoso ha acelerado el paso de las prácticas de codificación monolíticas a las arquitecturas de servicios.
Agilidad de la infraestructura, porque en lugar de comprar, instalar y gestionar infraestructura, los usuarios simplemente solicitan lo que necesitan -cuando lo necesitan- mediante simples peticiones. El término "infraestructura como código" se refiere al uso de un simple "código" para aprovisionar toda la infraestructura que se necesita en cuestión de minutos en lugar de semanas o meses.
Agilidad económica, porque sólo juegas por lo que necesitas, cuando lo necesitas. Avatar no necesitó construir un enorme centro de datos de efectos especiales y gestionarlo durante 12 años. En lugar de eso, simplemente hicieron girar lo que necesitaban cuando lo necesitaban.
Así pues, ahora que sabemos qué es la nube, podemos hablar de lo que se necesita para ser verdaderamente nativo de la nube.
¿Qué es la nube nativa?
La respuesta fácil es que una aplicación nativa de la nube interactúa con la nube utilizando nube nativa primitivas. Por ejemplo, una aplicación nativa de la nube llamaría directamente a los servicios de almacenamiento nativos de Amazon AWS (S3, EBS, EFS, etc.). Este principio se aplica a todos los servicios en la nube: ordenador, almacén, red, etc.
Para las aplicaciones "nacidas en la nube" (es decir, diseñadas desde el primer día para ejecutarse en la nube y sólo en ella), esto es bastante fácil. Pero para las aplicaciones nacidas en un mundo on-premises, hay un doloroso ejercicio de refactorización que debe ocurrir. Tenga en cuenta que esto requiere que la aplicación esté totalmente desagregada de toda la infraestructura: computación, almacenamiento y redes.
El segundo requisito importante para ser verdaderamente nativo de la nube es ser gestionado "as-code" Esto significa poder poner en marcha la aplicación con unas pocas líneas de código, a diferencia del proceso tradicional en las instalaciones de instalar y configurar todo manualmente durante semanas.
Al igual que estar embarazada, no existe "parcialmente nativo en la nube" Una aplicación es o no es nativa de la nube. Si una aplicación no se desagrega por completo y adopta la metodología "as-code", pierde las ventajas de elasticidad y agilidad que promete la nube.
¿Existen soluciones de almacenamiento nativas de la nube?
Antes de hablar de las soluciones de almacenamiento nativas de la nube, repasemos las "primitivas" de la nube en lo que a "almacenamiento" se refiere.
Es el almacenamiento de objetos (Azure blob / AWS S3). Se trata de una capa de persistencia de datos asombrosamente asequible, escalable, disponible, duradera y con un rendimiento excelente, medido por el throughput. Su inconveniente es que se trata de una nueva interfaz que es RESTful y sólo eventualmente consistente.
Luego tenemos lo que yo llamaría una SAN de mala calidad, es decir, EBS en AWS y Managed Disk en Azure. Se presentan como un "disco local", son resistentes y, en general, se comportan como un disco normal en un servidor de almacenamiento antiguo. Estas primitivas actúan como el equivalente de un "disco local protegido" (excepto que no está conectado a la instancia de computación local). Estas primitivas tienen características de rendimiento moderadas y pueden soportar "lecturas / escrituras aleatorias", pero son caras.
Y, por último, tenemos las unidades SSD NVMe conectadas a la instancia, que son más como una extensión de la DRAM en el sentido de que los datos de estas "unidades" no persisten durante los reinicios de la instancia y, sin embargo, son mucho menos costosas que la DRAM o el "disco local protegido", al tiempo que tienen características de rendimiento entre estos dos.
Hasta la fecha, el sector del almacenamiento se ha resistido obstinadamente a la nube. Los proveedores heredados (Dell, NetApp) tienen demasiado código específico de hardware (gran dependencia de NVRAM, estrecho acoplamiento de las capas de resiliencia de datos y servicios de datos) para refactorizar sus ofertas y aprovechar las primitivas nativas de la nube.
Y entonces llegaron VAST y Pure, que también optaron por una pila de almacenamiento optimizada para hardware.
Pure's almacenamiento en bloque en la nube es relevante en el sentido de que utiliza primitivas nativas de la nube para ofrecer los servicios de datos en bloque tan deseados por los clientes de Pure, ¡y más allá de lo triste! ¿Quién demonios está ejecutando SAN en la nube? Esto me deja perplejo. Y ya que estamos en este tema, me cuesta entender quién utiliza VMWare en la nube. Esto también me deja perplejo
Entre los proveedores de almacenamiento de nueva generación, Weka.io es el que más impresiona. Tienen una arquitectura "nativa de la nube" y aprovechan el almacenamiento de objetos en la nube como capa de resistencia. Ahora bien, si no tuvieran la reputación de ser un actor de nicho de HPC y de ser un "Ferrari de cristal"..
Como director de tecnología de Qumulo, ¿qué tengo que decir sobre la oferta de Qumulo en la nube?
Permanezca atento.
Marquen la fecha en sus calendarios; jueves 9 de noviembre de 2023, y prepárense para que les vuele la cabeza 🙂