Permitir que sus aplicaciones empresariales “pre-nube” existentes aprovechen al máximo la computación en la nube está plagado de obstáculos técnicos, como versiones no compatibles de sistemas operativos (SO), arquitecturas monolíticas que están estrechamente integradas con almacenes de datos o almacenamiento de archivos empresariales, y dificultades. en el cumplimiento de las expectativas de las partes interesadas (incluidas las reducciones de costos). Cuando las aplicaciones “nuevas” adoptan una arquitectura nativa de la nube, sufren mucho menos la carga de estos desafíos, pero estas nuevas aplicaciones solo representan un pequeño porcentaje del portafolio de aplicaciones de una organización. Una aplicación heredada típica realojada en una infraestructura como servicio (IaaS) y migrada mediante un enfoque de “levantamiento y cambio” no puede aprovechar al máximo todas las características de la nube. Las organizaciones que siguen este enfoque de realojamiento a menudo descubren que el equipo de migración tomó atajos e ideó soluciones alternativas sólo para que las aplicaciones se ejecutaran. Estos atajos y soluciones surgen porque el objetivo del realojamiento era mover la aplicación de manera urgente y admitir otras aplicaciones modificadas de manera más significativa que ya se están ejecutando en la nube. La evaluación integral de la preparación nativa de la nube nunca se realizó en la aplicación heredada, lo que generó resultados deficientes. Una de las áreas a considerar es que una aplicación heredada típica se basa en sistemas tradicionales de administración de bases de datos relacionales (RDBMS) y transacciones de atomicidad, consistencia, aislamiento y durabilidad (ACID) para una sólida integridad de los datos. Estas bases de datos tradicionales dependen de que la infraestructura subyacente sea sólida y confiable. No están diseñados para entornos donde la infraestructura es fluida o propensa a fallar. Estas bases de datos también están diseñadas para escalar, no hacia afuera, lo que impide su capacidad para utilizar la abundancia de recursos de la nube y escalar elásticamente su aplicación. Sin embargo, el diseño de aplicaciones contemporáneo aprovecha la persistencia políglota para optimizar el comportamiento de la base de datos para casos de uso específicos. Este concepto permite a los desarrolladores elegir el almacenamiento de datos que mejor se adapte a los datos y su enfoque de programación en lugar de forzar que los datos encajen en un modelo tradicional de lenguaje de consulta estructurado (SQL). El uso de RDBMS para todo el almacenamiento de datos puede generar inflexibilidad en el diseño y costos significativos para escalar la base de datos. La adopción de la computación en la nube requiere una planificación cuidadosa y una comprensión profunda de cómo sus aplicaciones existentes podrían impedir la migración a una arquitectura nativa de la nube. Los clientes de Gartner a menudo citan una mala planificación y estrategias de migración inapropiadas como razones para la adopción de la nube por debajo del estándar. Sin planificación ni estructura, las decisiones se tomarán durante el vuelo sólo para que la aplicación funcione. Esto conducirá a una desalineación con los objetivos establecidos del proyecto. Establecer objetivos Las migraciones a la nube generalmente abarcan una combinación de aplicaciones, algunas de las cuales deben revisarse o actualizarse y pueden beneficiarse de lo que ofrece la nube. Estas iniciativas tienen diferentes objetivos comerciales de una organización a otra. Las decisiones, los procesos y las personas detrás de las iniciativas son específicos de cada organización. Sin embargo, Gartner ha identificado y esbozado varios objetivos técnicos recurrentes. Es fundamental que objetivos comerciales específicos guíen los esfuerzos de modernización de la nube de una organización y que las partes interesadas de toda la organización estén alineadas con esos objetivos. Por ejemplo, no todas las modernizaciones de aplicaciones requerirán reconstrucción. Es posible que no necesite cambiar la forma en que se particiona su base de datos para mejorar la escalabilidad de una aplicación determinada si ese no es uno de sus objetivos de migración a la nube. Creación de un cuadro de mando del esfuerzo Gartner propone un marco para la modernización de aplicaciones, que representa una evaluación de la arquitectura con puntos críticos específicos. El esfuerzo necesario para modernizar una aplicación debe establecerse evaluando cómo cada punto de acceso inhibe los objetivos comerciales de la migración. Cuanto más fácilmente se pueda cambiar su aplicación, menos trabajo, esfuerzo y recursos necesitará para adoptar patrones y principios de arquitectura nativa de la nube. Este paso requiere que cree un cuadro de mando de esfuerzo que se completará mientras se analiza cada punto crítico durante el resto de la evaluación. Inhibidores de la modernización Dos inhibidores principales aumentan el esfuerzo de modernización de sus aplicaciones: el acoplamiento y la complejidad. El acoplamiento puede verse como la cantidad de interdependencias dentro y fuera de su aplicación. Por ejemplo, desde la perspectiva del código, examinaría cómo interactúan los bloques de código entre sí y con el gráfico de llamadas, incluido cómo se componen los métodos, clases y funciones. Un script o bloque de código que depende de diferentes bloques de código se considera acoplamiento. Para agravar el problema del acoplamiento está la complejidad de su arquitectura y código. Los componentes de la aplicación que están estrechamente acoplados y dependen en gran medida de las características específicas del software y hardware subyacentes pueden generar complejidad. Esta complejidad limita sus opciones de implementación, tiempo de ejecución y alojamiento cuando se dirige a plataformas nativas de la nube. Es importante implementar abstracciones y encapsulación de aquellas dependencias y componentes subyacentes que son similares y cambian al mismo tiempo. En este sentido, la complejidad significa tener dependencias que son difíciles de cumplir. Las dependencias a nivel de aplicación (por ejemplo, las dependencias entre componentes de la aplicación) también pueden desempeñar un papel. Una evaluación de su aplicación revelará la profundidad del acoplamiento y la complejidad dentro de la aplicación. Le permitirá determinar el esfuerzo general necesario para modernizar cada uno de estos puntos de acceso dentro de su aplicación. Dependiendo de estos distintos grados de modernización, puede elegir diferentes estrategias para diferentes partes de su código. El nivel de modernización está directamente relacionado con los objetivos comerciales. Si la aplicación es lo suficientemente modificable para cumplir esos objetivos, refactorizar el código y modernizar la aplicación a una plataforma nativa de la nube puede ser suficiente. Si el nivel de esfuerzo para modernizar es alto en todos los ámbitos, es posible que no tenga más remedio que reconstruir toda la aplicación. Sin embargo, también puede rediseñar y reconstruir componentes individuales si, por ejemplo, su nivel de modernización es bajo desde el punto de vista de la arquitectura de la aplicación y alto desde el punto de vista de la persistencia de los datos. Otros desafíos En un entorno de nube, se intenta crear una aplicación confiable utilizando una gran cantidad de componentes no confiables que tienen el potencial de fallar, a menudo de maneras diferentes a los tipos de fallas de componentes de la aplicación que se pueden ver en una sola máquina. La computación en la nube requiere una arquitectura que funcione en un entorno con recursos efímeros que favorezcan la escalabilidad horizontal sobre la vertical. Las arquitecturas nativas de la nube equilibrarán los beneficios que la nube tiene para ofrecer, junto con las áreas que son diferentes y subcontratadas al proveedor, limitando así su control sobre ellas. Las motivaciones de su organización para migrar a la nube son la escalabilidad adicional, la expansión del negocio para adoptar nuevos canales y la reducción de los recursos cuando la demanda disminuye. Esto puede generar una carga impredecible que varía de las operaciones normales del día a día. El uso de servicios nativos administrados en su proveedor de nube también introducirá latencia en su aplicación porque los componentes de su aplicación ahora están distribuidos a través de una red. Los arquitectos nativos de la nube también deben tener en cuenta que algunas fallas de los servicios de la nube, fallas sistemáticas y violaciones de seguridad están completamente fuera de su control. Debe haber un cambio general de mentalidad desde el nivel de liderazgo para comprender cuándo y dónde se aplican los principios nativos de la nube en la cartera de aplicaciones. El liderazgo debe capacitar a las personas para que aprendan y mejoren continuamente estas lecciones en el contexto de su organización. Haga de la modernización nativa de la nube una parte inherente de los ciclos de mantenimiento de sus aplicaciones. Se necesita una gran inversión en procesos de cambio organizacional porque la innovación en la nube supera los procesos y la cultura organizacionales existentes y rompe los procesos existentes. Este artículo se basa en el informe de Gartner «Cómo modernizar su aplicación para utilizar una arquitectura nativa de la nube» de Eklove Mohan, director analista senior de Gartner.

Source link