Bienvenido al primero de una serie de cuatro artículos que analizan la contenedorización y el movimiento nativo de la nube liderado por Docker, Google y un ecosistema floreciente de jugadores tradicionales y nuevos. En esta serie nos aventuramos a definir y discutir este espacio emergente y emocionante en un esfuerzo por ayudar a las organizaciones a navegarlo mejor. Si bien este primer artículo se centrará en definir "nube nativa" y algunas partes móviles relacionadas, en artículos futuros exploraremos las capas importantes y los desafíos relacionados con las redes, el almacenamiento y la orquestación de contenedores para brindarle una visión más completa... pero primero comencemos en el principio.
Bienvenido al primero de una serie de cuatro artículos que analizan la contenedorización y el movimiento nativo de la nube liderado por Docker, Google y un ecosistema floreciente de jugadores tradicionales y nuevos. En esta serie nos aventuramos a definir y discutir este espacio emergente y emocionante en un esfuerzo por ayudar a las organizaciones a navegarlo mejor. Si bien este primer artículo se centrará en definir "nube nativa" y algunas partes móviles relacionadas, en artículos futuros exploraremos las capas importantes y los desafíos relacionados con las redes, el almacenamiento y la orquestación de contenedores para brindarle una visión más completa... pero primero comencemos en el principio.
Al principio, estaban Free BSD y Solaris, que sentaron las bases de manera magistral para lo que ahora se considera tecnologías modernas de contenedorización con capacidades llamadas FreeBSD Jails y Solaris Zones, respectivamente. Google ayudó a traer contenedores a Linux al agregar cgroups al Kernel de Linux. Combinado con espacios de nombres y chroot, se sentaron las bases técnicas. Además, Docker hizo que los contenedores fueran más accesibles al crear un flujo de trabajo sencillo en torno a las imágenes de contenedores y al centrarse en una experiencia fácil para los desarrolladores.
Probablemente la mejor forma de definir el espacio sea respondiendo algunas preguntas fundamentales y haciendo que algunos expertos invitados las respondan. (¿Ves cómo descargo trabajo a otras personas que están más calificadas?)
¿Qué es un contenedor?
Colaborador invitado Cameron Brunner, arquitecto jefe Navops
Los contenedores permiten que las aplicaciones se muevan de forma fiable de un entorno informático a otro. Esto podría ser desde la computadora portátil de un desarrollador, el entorno de control de calidad hasta la producción local o en la nube. Las dependencias de la pila de software de la aplicación que se ejecuta en el contenedor, como el sistema operativo u otros componentes y bibliotecas de software, pueden integrarse en gran medida dentro de un contenedor, lo que le permite ejecutarse desacoplado de los detalles del entorno de TI subyacente. Los contenedores se diseñaron originalmente para proporcionar aislamiento entre las aplicaciones que se ejecutan en un sistema operativo. Proporcionan una combinación de controles de recursos y separación de límites que ayuda a aislar la ejecución de código dentro del contenedor de otras actividades y otros contenedores que se ejecutan en esa máquina/sistema operativo. Los contenedores logran este aislamiento aprovechando funciones del sistema operativo como cgroups y espacios de nombres.
¿Qué es Docker?
Docker es tanto una empresa como una implementación comercial/de código abierto de contenedores. Los contenedores han existido durante mucho tiempo antes de Docker con implementaciones tempranas como FreeBSD Jails (2000) y Solaris Zones (2004) y Docker ha hecho un trabajo fabuloso al hacer que los contenedores sean útiles para las masas al simplificar enormemente el proceso de creación y ejecución. Si bien Docker se está convirtiendo rápidamente en el formato de contenedor estándar de facto, la compañía ha avanzado más hacia la apertura y la colaboración mediante la creación de Open Container Initiative (OCI) bajo la Fundación Linux. OCI involucra a varios participantes de la industria y está trabajando para lograr estándares de la industria para formatos de contenedores y tiempos de ejecución. (Ver www.opencontainers.org/)
Entonces, ¿qué es la computación nativa en la nube?
Colaborador invitado Joe Beda, fundador y colaborador de Google Compute Engine y Kubernetes
Cloud Native es una de las muchas formas nuevas de pensar en la creación y administración de aplicaciones a escala. En su raíz, Cloud Native está estructurando equipos, cultura y tecnología para utilizar la automatización y las arquitecturas para administrar la complejidad y desbloquear la velocidad.
Si bien los contenedores y la administración de contenedores a menudo forman parte del pensamiento "nativo de la nube", organizaciones como Netflix han aplicado este pensamiento con máquinas virtuales e imágenes de máquinas virtuales. Además, no tiene que ejecutar en la nube para comenzar a obtener algunos beneficios de este cambio de mentalidad. Las aplicaciones y los equipos pueden ser más manejables al implementar aplicaciones en las instalaciones.
No hay reglas estrictas y rápidas para lo que es Cloud Native. Sin embargo, hay algunos temas que están surgiendo.
- Automatización de DevOps y Ops: los ingenieros que usan el sombrero de desarrollador de aplicaciones desempeñan un papel activo para garantizar que las aplicaciones puedan ejecutarse de manera confiable en producción. Del mismo modo, quienes cumplen la función de operaciones se aseguran de que las experiencias retroalimenten el desarrollo. La automatización es clave para gestionar muchas piezas en movimiento.
- Contenedores: los contenedores brindan una forma conveniente de crear un artefacto de compilación desplegable que se puede probar y validar. Esto garantiza que las implementaciones sean predecibles.
- Clústeres de cómputo: un clúster de cómputo y un sistema de programación controlados por API permiten que una pequeña cantidad de ingenieros administre una gran cantidad de cargas de trabajo. Más allá de eso, permite que esas cargas de trabajo se empaqueten de manera eficiente en los nodos para impulsar las tasas de utilización. Finalmente, un clúster bien administrado reduce la carga de operaciones para los equipos de aplicaciones.
- Microservicios: los microservicios dividen las aplicaciones en unidades implementables más pequeñas para que los equipos de desarrollo puedan ser rápidos y ágiles. Estas ideas no son necesariamente nuevas, pero se están aplicando junto con herramientas para permitir una gestión escalable. Hablaremos más sobre esto a continuación.
- Visibilidad profunda: Cloud Native implica conocimientos más profundos sobre cómo se ejecutan los servicios. El seguimiento distribuido, la recopilación y la indexación de registros y la supervisión profunda de las aplicaciones ayudan a arrojar luz sobre lo que realmente sucede dentro de una aplicación.
¿Qué es una arquitectura basada en microservicios?
Colaborador invitado Joe Beda, fundador y colaborador de Google Compute Engine y Kubernetes
Los microservicios son un nuevo nombre para un concepto que existe desde hace mucho tiempo. Básicamente, es una forma de dividir una aplicación grande en partes más pequeñas para que puedan desarrollarse y administrarse de forma independiente. Veamos algunos de los aspectos clave aquí:
- Interfaces fuertes y claras. Se debe evitar el acoplamiento estrecho entre los servicios. Las interfaces documentadas y versionadas ayudan a solidificar ese contrato y conservar un cierto grado de libertad tanto para los consumidores como para los productores de estos servicios.
- Implementado y administrado de forma independiente. Debería ser posible actualizar un solo microservicio sin sincronizar con todos los demás servicios. También es deseable poder revertir fácilmente una versión de un microservicio. Esto significa que los archivos binarios que se implementan deben ser compatibles hacia adelante y hacia atrás tanto en términos de API como de cualquier esquema de datos. Esto puede poner a prueba los mecanismos de cooperación y comunicación entre los equipos de operaciones y desarrollo apropiados.
- Resiliencia incorporada. Los microservicios deben construirse y probarse para que sean resistentes de forma independiente. El código que consume un servicio debe esforzarse por seguir funcionando y hacer algo razonable en caso de que el servicio consumido esté inactivo o se comporte mal. Del mismo modo, cualquier servicio que se ofrezca debe tener algunas defensas con respecto a la carga no anticipada y la mala entrada.
- Los microservicios tienen más que ver con las personas que con la tecnología. Los equipos pequeños son más ágiles. Jeff Bezos es famoso por sugerir que las reuniones y los equipos sean lo suficientemente pequeños para que puedan alimentarse con 2 pizzas. Al estructurar un gran proyecto como una serie de equipos más pequeños y luego quitarse de en medio, esos equipos pueden fusionarse mentalmente y apropiarse de esa parte del proyecto.
Esperamos con ansias los próximos artículos en los que analizaremos algunas de las capas importantes de la pila nativa de la nube.
Rob Lalonde es vicepresidente y gerente general de Navops. Es un participante activo en varias fundaciones de código abierto, incluidas Cloud Native Computing Foundation (CNCF), Open Container Initiative (OCI) y Linux Foundation. Rob ha ocupado puestos ejecutivos en múltiples y exitosas empresas de alta tecnología y nuevas empresas. Ha completado estudios de MBA en la Escuela de Negocios Schulich de la Universidad de York y tiene una licenciatura en informática de la Universidad Laurentian.
Suscríbase al boletín de StorageReview
