Una aplicación nativa de la nube es un sistema diseñado específicamente para una arquitectura de computación en la nube.
Las NCA, siglas del inglés Native Cloud Application, están diseñadas para aprovechar los marcos de computación en el cloud computing, que se componen de servicios acoplados en la nube. Eso significa que los desarrolladores deben dividir las tareas en servicios separados que pueden ejecutarse en varios servidores en diferentes ubicaciones. Debido a que la infraestructura que admite una aplicación nativa de la nube no se ejecuta localmente, las NCA se deben planificar teniendo en cuenta la redundancia para que la aplicación pueda soportar fallas del equipo y poder volver a mapear las direcciones IP automáticamente si fallara el hardware.
El paradigma de diseño es rentable, sin embargo, porque los servicios y recursos para cómputo y almacenamiento se pueden ampliar horizontalmente según sea necesario, lo que evita la necesidad de sobre aprovisionamiento de hardware y tener que planificar el equilibrio de carga.
Los servidores virtuales se pueden agregar rápidamente para realizar pruebas y, en teoría, una aplicación creada específicamente para implementarse en la nube se puede lanzar al mercado el mismo día de su creación.
Doce principios de una aplicación nativa de la nube
- Código: un único código trazable desde muchas implementaciones
- Dependencias: Declarar y aislar explícitamente dependencias
- Configuración: almacenar config en el entorno
- Servicios de respaldo: tratar los servicios de respaldo como recursos adjuntos
- Construir, liberar, ejecutar: Estrictamente separadas las etapas de compilación y ejecución
- Procesos: ejecutar la aplicación como uno o más procesos sin estado
- Unión de puertos: servicios de exportación a través de enlaces de puertos
- Concurrencia: escalar a través del modelo de proceso
- Desechabilidad: maximizar la solidez con un inicio rápido y un apagado correcto
- Paridad entre desarrollo y producción: mantener el desarrollo, la preparación y la producción lo más similar posible
- Registros: tratar los registros como flujos de eventos
- Procesos administrativos: ejecutar tareas de administración como procesos únicos
Muchos de estos principios no son nuevos y de hecho se aplican racionalmente. Si se los analiza con cuidado, parecen un guión cómico. Por ejemplo, el principio 9 dice “maximizar la solidez con un inicio rápido y un apagado correcto” implicaría que algunos equipos de desarrollo no eran conscientes de que los tiempos de inicio extendidos y programas que se colgaban en el cierre eran malos.
Rompiendo el irrompible
Honestamente, hay principios que ni siquiera sé cómo violar. El cuarto principio dice que los servicios de respaldo deben tratarse como recursos adjuntos. Ni siquiera sé cómo escribiría una aplicación nativa de la nube que no tratara los servicios de respaldo como un recurso adjunto. ¿No es tautológico ese enunciado solo por definición del hecho de que es un recurso de back-end que no está adjunto a su aplicación nativa de la nube?
El tercer principio instruye a los desarrolladores nativos de la nube para que almacenen los detalles de configuración en el entorno y no como un conjunto de constantes o declaraciones if-then-else salpicadas en una variedad de clases diferentes a lo largo de la base de códigos. No puedo ver a un profesional experimentado en Java EE añadiendo código Java que corchetee a cada clase con enunciados condicionales que cambian el comportamiento del tiempo de ejecución según el entorno que actualmente aloja el código.
Ideas a mitad de la cocción
La aplicación de los 12 principios proporciona algo de reflexión, y la mayor parte de lo que es intelectualmente digerible proviene de la insistencia en que usar el proceso, en lugar de enhebrar partes, es la mejor manera de escalar una aplicación.
Aunque afirmaría que esto es realmente solo un argumento semántico, en oposición a uno basado en la práctica. Si bien es cierto que los servidores de aplicaciones Java tradicionales ejecutaron un proceso con muchos subprocesos, los microservicios Java tienden a procesarse individualmente, e incluso dentro de un microservicio, habrá múltiples funciones que aprovecharán el enhebrado, por lo que no es un tipo de nada. En todo caso, los principios 6 y 8, ejecutar aplicaciones como procesos y escalar usando el modelo de proceso, realmente se reducen a la afirmación de que los desarrollos monolíticos son malos, y dividirlos en pedazos más pequeños es bueno.
Compartir por Facebook
El credo de los 12 principios me parece algo que pondrías en uno de esos posters molestos e inspiradores que encuentras colgando en las oficinas de cualquier empresa. Casi puedo visualizar un póster de un automóvil deportivo italiano con la palabra DESECHABILIDAD en la parte superior, y la frase “Maximizar la robustez con el inicio rápido y los cierres elegantes” en la parte inferior.
Vivimos en una época en la que cada mensaje, para ser consumido, debe ser entregado como un meme, o como algo que puede compartirse como una publicación de Facebook o entregado en un tweet de 140 caracteres. Tal vez sea el nuevo desarrollador, los minellians de las redes sociales, a quien apunte el mantra de los 12 principios.
Decirme que coma menos y que haga más ejercicio para perder peso es un consejo bastante inútil. Decirme que pague mis impuestos a tiempo y evitar intereses y multas también es un consejo inútil. Las afirmaciones son ciertas, pero no es algo que no sepa, lo que hace que estas afirmaciones tautológicas sean una pérdida de tiempo. Se pueden enmarcar estas declaraciones como un conjunto de consejos, pero en realidad no lo son si no proporcionan nada nuevo, nada de valor agregado y nada que sea particularmente procesable.
Autor: Cameron McKenzie, Techtarget.
Traducido y adaptado por la división consultoría de EvaluandoCloud.com