Tecnologías de Azure para el proceso de compilación
En esta unidad, aprenderá la relación entre el proceso de innovación y algunas de las tecnologías del sector que pueden ayudarle a crear nuevas funcionalidades en aplicaciones.
DevOps
Una vez iniciada la fase de compilación para validar la hipótesis de innovación, los ciclos de desarrollo, integración e implementación necesarios deben ser lo más optimizados posible. Esta fase es donde entra en marcha DevOps. Puede definir DevOps como "procesos y herramientas para ofrecer características de software de forma rápida y confiable". Estos son los detalles sobre esta definición:
Procesos y herramientas: DevOps y el proceso de innovación en su conjunto se basa en patrones culturales que fomentan el cambio. Azure y GitHub ofrecen excelentes herramientas en torno a DevOps, pero la compra de una licencia no es suficiente. Los procesos y la cultura de la organización deben evolucionar para adoptar el cambio y la innovación.
Entrega rápida de características de software: los procesos y las herramientas de DevOps adoptan el concepto de error rápido. La creación de MMV o prototipos para validar rápidamente si la característica en la que está trabajando va en la dirección correcta es fundamental para el concepto de DevOps.
Entrega confiable de las características de software: las organizaciones adversas al cambio a menudo asocian modificaciones rápidas con tiempo de inactividad. Sin embargo, DevOps promete exactamente lo contrario: una tasa de cambio rápida y un alto nivel de confiabilidad. Esta confiabilidad se hace posible mediante la integración de pruebas en las primeras fases del ciclo de desarrollo, en un proceso denominado "desplazamiento a la izquierda".
Si el desarrollo de una característica a lo largo del tiempo se ve como una línea de izquierda a derecha, un proceso de desarrollo heredado realizaría la validación del usuario y el control de calidad al final del ciclo de desarrollo. Esto está en el extremo "derecho" de esa línea. DevOps le aconseja que pruebe y valide lo antes posible, a la "izquierda" de esa línea de tiempo.
DevOps encarna los mismos conceptos básicos de una cultura de innovación saludable. La adopción de su metodología es clave para llegar a un ciclo de innovación ágil.
Arquitecturas de microservicios
La modularidad es una técnica conocida para reducir la complejidad en la arquitectura de sistemas complejos. Si un sistema es una interacción compleja de muchas piezas que no se pueden separar (a menudo denominadas "monolíticas"), las interdependencias de componentes estrechos dificultan las mejoras del sistema. Cada cambio debe validarse con el resto del sistema, por lo que el proceso de prueba es complejo.
Si el sistema es modular, puede separarlo en subsistemas más pequeños que interactúan entre sí a través de interfaces bien definidas. La introducción de cambios en uno de estos subsistemas es más fácil, ya que siempre que su interfaz con los otros módulos permanezca constante, el sistema general sigue funcionando.
Las arquitecturas de microservicios son patrones de aplicación que aprovechan la modularidad. Las aplicaciones se subdividirán en componentes pequeños independientes que se pueden desarrollar de forma independiente entre sí, incluso mediante diferentes lenguajes de programación. Cada componente o microservicio puede funcionar por sí mismo. Puede escalarla según sea necesario, puede solucionar problemas como una sola unidad y modificarla independientemente de los otros microservicios.
Una pregunta que las organizaciones suelen plantear es qué hacer si una aplicación es monolítica. ¿La organización debe rediseñar la aplicación en una arquitectura de microservicios antes de introducir la innovación o puede ejecutarse en paralelo los procesos de innovación y rediseño? No hay respuesta única a esta pregunta. Depende de la complejidad y la relevancia empresarial de la aplicación en consideración.
Tailwind Traders se enfrentó a esta pregunta al examinar la introducción de la innovación en su plataforma de comercio electrónico. La empresa decidió iniciar un proyecto para rediseñar la aplicación de comercio electrónico en una arquitectura de microservicios, ya que la importancia empresarial de la aplicación justificaba este esfuerzo. No tener una aplicación modular afectaría gravemente la capacidad de Tailwind Traders para reaccionar a las tendencias cambiantes en el mercado en línea.
Sin embargo, Tailwind Traders tomó la decisión de abordar algunas de las principales brechas en su plataforma al mismo tiempo. Esperar a que el proyecto de rediseño de la aplicación finalice significaría perder una cuota de mercado significativa a las nuevas startups que están interrumpiendo el mercado de comercio electrónico en este momento.
Los proyectos deben interactuar entre sí, guiados por el valor empresarial de las innovaciones. Los esfuerzos de rediseño se centran en las áreas de aplicación más críticas, donde la necesidad de modificación para mejorar la experiencia del cliente es más alta.
Contenedores
La tecnología de la contenedorización no es exclusiva de las arquitecturas de microservicios, pero los conceptos funcionan juntos. Los contenedores son una manera de encapsular el código de aplicación y sus dependencias para que se puedan implementar sin esfuerzo en cualquier plataforma.
Las implementaciones de aplicaciones tradicionales requieren que la organización instale primero software, como el entorno de ejecución de la aplicación, las bibliotecas de programación o los componentes externos. Este enfoque suele dar lugar al problema "funciona en mi máquina", ya que es difícil replicar el mismo entorno en el desarrollo, la prueba, el almacenamiento provisional y la producción. Las pequeñas diferencias en la forma en que se instalan las dependencias de la aplicación pueden hacer que la aplicación funcione correctamente mientras se prueba, pero se produce un error cuando se implementa en producción.
Los contenedores cambian las reglas del juego. Las dependencias de la aplicación se empaquetan junto con el código de la aplicación en una unidad de implementación autónoma denominada imagen de contenedor. Tanto si el contenedor de aplicaciones se implementa en el portátil de un desarrollador como en un clúster de producción con cientos de nodos, el control de dependencias es el mismo. El contenedor funciona exactamente de la misma manera, por lo que las pruebas de aplicaciones son más confiables y fidedignas.
Los contenedores han llegado un largo camino desde que Docker lanzó su código como código abierto en 2013. Los contenedores ahora admiten Tanto Linux como Windows y diferentes arquitecturas de CPU. Hay muchas ofertas en Azure que permiten ejecutar cargas de trabajo basadas en contenedores. En esta unidad, obtendrá información sobre algunos de ellos.
Kubernetes y Red Hat OpenShift
Un entorno de ejecución de contenedor es la tecnología que inicia contenedores en un ordenador, pero se necesita una lógica adicional en un entorno de producción. ¿Quién implementa más contenedores si se requiere más rendimiento? ¿Quién reinicia los contenedores si tienen un problema? Si hay varios equipos disponibles, ¿quién decide en cuál de ellos debe iniciarse el contenedor determinado? Estas y otras tareas son responsabilidad de una plataforma de orquestación de contenedores.
La primera versión de Kubernetes se publicó en 2015 y pronto se convirtió en el estándar de facto para la orquestación de contenedores. Los clústeres de Kubernetes constan de varios nodos de trabajo. Cada nodo de trabajo tiene un entorno de ejecución de contenedor, por lo que puede ejecutar contenedores donde el plano de control de Kubernetes programa la implementación de aplicaciones en contenedor. Este plano de control normalmente se ejecuta en un conjunto de nodos principales. Es responsable de mantener la aplicación funcionando correctamente, escalar la aplicación hacia arriba o hacia abajo, y realizar las actualizaciones necesarias.
Una de las principales razones de popularidad de Kubernetes es la independencia de hardware que proporcionan los contenedores. Dado que las aplicaciones basadas en contenedores se pueden implementar de forma confiable en cualquier entorno de ejecución de contenedor, puede ejecutar Kubernetes en nubes que usan varios hipervisores. Las aplicaciones implementadas deben comportarse de forma similar (suponiendo que los recursos de hardware subyacentes también sean similares). Muchas organizaciones han adoptado Kubernetes como una capa de abstracción que permite procesos de implementación de aplicaciones coherentes tanto locales como en nubes públicas.
La ejecución de Kubernetes en Azure es fácil. Azure Kubernetes Service es fácil de implementar y rentable, ya que el cliente solo se cobra por el costo de los nodos de trabajo. Microsoft asume el costo y la operación del plano de control que contiene los componentes principales. Microsoft aplica revisiones y actualiza el sistema operativo de los nodos de trabajo, lo que reduce aún más la complejidad operativa de administrar un clúster de Kubernetes para ejecutar contenedores de Linux y Windows.
OpenShift es una plataforma de implementación de aplicaciones basada en Kubernetes, desarrollada y compatible con Red Hat. Incorpora muchas otras funcionalidades. Algunas de las organizaciones que eligen ejecutar sus aplicaciones en OpenShift lo hacen debido a estas características adicionales y la compatibilidad que proporciona Red Hat. La ejecución de OpenShift en Azure es más sencilla. Red Hat OpenShift en Azure consta de un clúster de OpenShift en el que Microsoft administra muchos de sus aspectos, incluido todo el ciclo de vida del clúster.
Azure App Service
Azure App Service es una plataforma en la que las organizaciones pueden ejecutar sus cargas de trabajo basadas en web sin tener que administrar ningún orquestador ni sistema operativo subyacente. El único requisito es cargar el código de aplicación en el servicio a través de uno de los muchos métodos de implementación disponibles. Azure realiza el resto para incluir el escalado de la aplicación dentro y fuera, la aplicación de revisiones y el mantenimiento de las máquinas virtuales subyacentes y mucho más. Todo esto sin necesidad de la curva de aprendizaje de Kubernetes.
Azure App Service admite cargas de trabajo basadas en contenedores, por lo que puede cargar la imagen de contenedor en lugar del código de la aplicación. También admite cargas de trabajo de Linux y Windows y muchos entornos de ejecución de aplicaciones diferentes.
Azure App Service admite varios modelos de precios, incluida una opción sin servidor denominada Azure Functions. En Azure Functions, solo se cobra el uso de la aplicación. No hay ningún costo fijo.
El modelo sin servidor es interesante para innovar, ya que le permite implementar nuevos microservicios sin incurrir en facturas mensuales elevadas si el mercado no los acepta. Este modelo es otro ejemplo de la estrategia de falla rápida, donde la innovación no implica necesariamente gastos elevados.
Azure App Service también ofrece características que admiten implementaciones orientadas a DevOps, como ranuras de aplicación web. Las slots son áreas de ensayo en las que puede desplegar nuevas funciones sin afectar al entorno de producción. Las ranuras son excelente desde una perspectiva de innovación, ya que puede redirigir una pequeña selección de sus clientes a esta versión nueva de la aplicación. A continuación, puede validar si la hipótesis de innovación es correcta. Finalmente, si desea migrar el nuevo código a producción, puede "intercambiar" slots para que el entorno de pruebas pase a ser la versión de producción.
Resumen
En esta unidad, ha aprendido cómo la tecnología puede apoyar la innovación:
- Los procesos y herramientas de DevOps proporcionan a los equipos de desarrollo y operaciones la superpotencia de ofrecer nuevas características de forma rápida y confiable.
- Puede rediseñar las aplicaciones en microservicios para permitir la innovación en sus componentes individualmente, sin afectar al resto.
- Los contenedores permiten la implementación confiable de aplicaciones en varias plataformas y entornos.
- Kubernetes es una plataforma de orquestación independiente de la nube para ejecutar aplicaciones en contenedores.
- Azure App Service puede ejecutar cargas de trabajo basadas en web con una sobrecarga de administración mínima. Ofrece muchas características, como ranuras de aplicación o sin servidor, para acelerar el ciclo de innovación.
Tailwind Traders ha decidido iniciar el rediseño de su aplicación de comercio electrónico en una arquitectura de microservicios. El primer subsistema de aplicaciones que separa del "monolito" es el servicio de pago, ya que lo ha identificado como un área crítica donde la competencia ofrece un mejor valor a los clientes.
Después del subsistema de pago, se convertirán más componentes de aplicación en microservicios independientes. Los microservicios pueden comunicarse a través de las API REST. El código de aplicación de cada microservicio se va a incluir en contenedores y las organizaciones de desarrollo y operaciones deben adoptar procedimientos recomendados de DevOps.
Dado que Tailwind Traders no quiere depender de ninguna nube pública específica, se decide crear conocimientos internos de Kubernetes e implementar la aplicación en clústeres de Azure Kubernetes Service. Si es necesario desarrollar nuevos microservicios, la empresa ha optado por considerar Azure Functions como plataforma para la implementación de MVP para reducir los costos de desarrollo.
Dónde buscar a continuación
Muchos de los conceptos de esta unidad se articulan aún más en los artículos de Cloud Adoption Framework Habilitación de la adopción con la invención digital y Kubernetes en Cloud Adoption Framework.