Tecnologías de Azure para el proceso de compilación
En esta unidad, obtendrá información sobre la relación entre el proceso de innovación y algunas de las tecnologías del sector que pueden ayudarle a agregar funciones nuevas a las aplicaciones.
DevOps
Una vez que haya iniciado la fase de compilación para validar la hipótesis de innovación, los ciclos de desarrollo, integración e implementación necesarios deben simplificarse lo máximo posible. En esta fase es donde DevOps entra en juego. DevOps se puede definir como "procesos y herramientas para ofrecer características de software de forma rápida y confiable". A continuación se detalla 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 herramientas excelentes en torno a DevOps, pero no basta con comprar una licencia. Los procesos y la cultura de la organización deben evolucionar para adoptar el cambio y la innovación.
Entrega de características de software de forma rápida: los procesos y las herramientas de DevOps adoptan el concepto de fracasar y responder rápido a los errores. La creación de MVP o prototipos para validar rápidamente si una característica en la que se está trabajando va en la dirección correcta o no es fundamental para el concepto de DevOps.
Entrega fiable de características de software: las organizaciones con aversión al cambio suelen asociar cambios rápidos con tiempo de inactividad. Sin embargo, DevOps ofrece exactamente lo contrario: un ritmo de cambio rápido y un alto nivel de fiabilidad. Esta fiabilidad es posible gracias a la integración de pruebas en las primeras fases del ciclo de desarrollo, un proceso llamado "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. Después, un proceso de desarrollo heredado realizaría la validación del usuario y el control de calidad al final del ciclo de desarrollo. 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 incorpora los mismos conceptos básicos de una cultura de innovación saludable. La adopción de su metodología es clave para alcanzar 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 partes que no se pueden separar (a menudo denominada "monolítica"), las interdependencias estrechas de componentes 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, lo puede separar en subsistemas más pequeños que interactúen entre sí mediante interfaces bien definidas. La introducción de cambios en uno de estos subsistemas es más fácil, ya que mientras su interfaz con los demás 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 subdividen en componentes independientes y pequeños que se pueden desarrollar de forma independiente entre sí, incluso con lenguajes de programación diferentes. Cada componente, o microservicio, puede funcionar por sí solo. Puede escalarlo según sea necesario, solucionar sus problemas como una sola unidad y modificarlo 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 volver a diseñar la aplicación en una arquitectura de microservicios antes de introducir la innovación, o puede ejecutar los procesos de innovación y cambio de diseño en paralelo? No hay una respuesta única a esta pregunta. Depende de la complejidad y relevancia empresarial de la aplicación en cuestión.
Tailwind Traders se ha enfrentado a esta pregunta al buscar introducir la innovación en su plataforma de comercio electrónico. La empresa ha decidido iniciar un proyecto para volver a diseñ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 contar con una aplicación modular afectaría gravemente a la capacidad de Tailwind Traders para reaccionar a la evolución de las tendencias en el mercado en línea.
Pero Tailwind Traders ha tomado la decisión de abordar algunas de las principales carencias de su plataforma al mismo tiempo. Esperar a que finalice el proyecto de cambio de diseño de la aplicación significaría perder una cuota de mercado importante frente a las nuevas startups, que en estos momentos están transformando el mercado del comercio electrónico.
Los proyectos interactúan entre sí, guiados por el valor empresarial de las innovaciones. Los esfuerzos de cambio de diseñ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 mayor.
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 la aplicación y sus dependencias, por lo que se pueden implementar sin esfuerzo en cualquier plataforma.
Las implementaciones de aplicaciones tradicionales requieren que la organización instale primero el software, como el entorno de ejecución de la aplicación, las bibliotecas de programación o los componentes externos. Este enfoque suele derivar en el problema "funciona en mi máquina": es difícil replicar el mismo entorno en desarrollo, prueba, ensayo y producción. Las pequeñas diferencias en la forma en que se instalan las dependencias de la aplicación pueden provocar que la aplicación funcione correctamente mientras se prueba, pero que se produzca 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 llamada imagen de contenedor. Tanto si el contenedor de aplicaciones se implementa en un equipo portátil de un desarrollador como en un clúster de producción con cientos de nodos, el control de dependencias será el mismo. El contenedor funciona exactamente de la misma manera, por lo que las pruebas de la aplicación son más fiables.
Los contenedores han recorrido un largo camino desde que Docker publicó su código como código abierto en 2013. Los contenedores ahora admiten Linux y Windows, así como diferentes arquitecturas de CPU. Hay muchas ofertas en Azure que permiten la ejecución de cargas de trabajo basadas en contenedores. En esta unidad, obtendrá información sobre algunas de estas.
Kubernetes y Red Hat OpenShift
Un entorno de ejecución de contenedor es la tecnología que inicia contenedores en un equipo, pero en un entorno de producción se requiere más lógica. ¿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 cuál de ellos debe iniciarse en un determinado contenedor? Estas tareas, entre otras, 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 runtime de contenedor, por lo que puede ejecutar contenedores donde el plano de control de Kubernetes programa la implementación de aplicaciones contenedorizadas. Este plano de control normalmente se ejecuta en un conjunto de nodos principales. Se encarga de mantener la aplicación ejecutándose correctamente, escalando o reduciendo verticalmente la aplicación y llevando a cabo las actualizaciones necesarias.
Una de las razones principales de la popularidad de Kubernetes es la independencia del hardware que proporcionan los contenedores. Dado que las aplicaciones basadas en contenedores se pueden implementar de forma fiable en cualquier entorno de ejecución de contenedor, podrá ejecutar Kubernetes en nubes que usen 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 sencilla. Azure Kubernetes Service es fácil de implementar y rentable, ya que al cliente solo se le cobra el costo de los nodos de trabajo. Microsoft asume el costo y el funcionamiento del plano de control que contiene los componentes principales. Microsoft se ocupa de aplicar revisiones y actualizar 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 que desarrolla y respalda Red Hat. Incorpora muchas otras funciones. Algunas de las organizaciones que deciden ejecutar sus aplicaciones en OpenShift lo hacen debido a estas características adicionales y al soporte técnico que proporciona Red Hat. La ejecución de OpenShift en Azure también es 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 o sistema operativo subyacente. El único requisito es cargar el código de aplicación en el servicio mediante uno de los muchos métodos de implementación disponibles. Azure se ocupa del resto: escalar y reducir horizontalmente la aplicación, aplicar revisiones y mantener las máquinas virtuales subyacentes, entre otras cosas, sin necesidad de adoptar 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, así como 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 la utilización de la aplicación. No hay costos fijos.
El modelo sin servidor es interesante para innovar, ya que permite implementar microservicios nuevos sin incurrir en facturas mensuales elevadas en caso de que el mercado no los acepte. Este modelo es otro ejemplo de la estrategia con respuesta rápida a errores, donde la innovación no significa necesariamente gastos elevados.
Azure App Service también ofrece características que admiten implementaciones orientadas a DevOps, como ranuras de aplicaciones web. Las ranuras son áreas de ensayo donde puede implementar características nuevas 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. Después, puede validar si la hipótesis de innovación es correcta. Finalmente, si quiere promover el código nuevo a producción, puede "intercambiar" ranuras para que el entorno de ensayo se convierta en la versión de producción.
Resumen
En esta unidad ha descubierto cómo la tecnología puede ayudar a fomentar la innovación:
- Los procesos y las herramientas de DevOps aportan a los equipos de desarrollo y operaciones la capacidad máxima de ofrecer características nuevas de forma rápida y fiable.
- Puede convertir las aplicaciones en microservicios para permitir la innovación en sus componentes de forma individual, sin afectar al resto.
- Los contenedores permiten la implementación fiable de aplicaciones en varias plataformas y entornos.
- Kubernetes es una plataforma de orquestación independiente de la nube para ejecutar aplicaciones contenedorizadas.
- 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 sin servidor o de aplicación, para acelerar el ciclo de innovación.
Tailwind Traders ha decidido iniciar el cambio de diseño de su aplicación de comercio electrónico en una arquitectura de microservicios. El primer subsistema de aplicaciones que se separa del "monolito" es el servicio de pago, ya que la ha identificado como un área crítica en la que la competencia ofrece un mejor valor a los clientes.
Después del subsistema de pago, habrá más componentes de aplicación que se convertirán en microservicios independientes. Los microservicios se pueden comunicar mediante las API REST. El código de aplicación de cada microservicio se va a contenedorizar, y las organizaciones de desarrollo y operaciones van a adoptar los procedimientos recomendados de DevOps.
Como Tailwind Traders no quiere depender de ninguna nube pública específica, ha decidido acumular experiencia en Kubernetes de forma interna e implementar la aplicación en clústeres de Azure Kubernetes Service. Si se necesitan desarrollar microservicios nuevos, la empresa ha optado por plantear Azure Functions como una plataforma para la implementación de MVP con el fin de reducir los costos de desarrollo.
Qué hacer después
Muchos de los conceptos de esta unidad se articulan aún más en los artículos de Cloud Adoption Framework Capacitación de la adopción con invención digital y Kubernetes en Cloud Adoption Framework.