Valoración de aplicaciones

  • Artículo

La racionalización de la nube es el proceso de evaluar los recursos para determinar la mejor manera de migrar o modernizar cada activo en la nube.

Entre los métodos de racionalización se incluyen:

  • Rehospedaje. También conocido como migración mediante lift-and-shift, el rehospedaje mueve una aplicación actual a la nube con un cambio mínimo.
  • Refactorización. Refactorizar ligeramente una aplicación para adaptarse a las opciones basadas en plataforma como servicio (PaaS) puede reducir los costos operativos.
  • Rediseño. Rediseñar aplicaciones antiguas que no son compatibles con componentes en la nube, o aplicaciones compatibles con la nube que mejorarían el costo y la eficiencia operativa si se rediseñaran en una solución nativa en la nube.
  • Recompilación. Si los cambios o costos para llevar una aplicación son demasiado grandes, considere la posibilidad de crear una nueva base de código nativa en la nube. La recompilación es adecuada especialmente en el caso de las aplicaciones que antes eran útiles para una empresa, pero que ya no son compatibles o no están en línea con los procesos empresariales actuales.

Antes de decidirse por una estrategia adecuada, analice la aplicación actual para determinar el riesgo y la complejidad de cada método. Tenga en cuenta el ciclo de vida de la aplicación, la tecnología, la infraestructura, el rendimiento, las operaciones y la supervisión. En el caso de las arquitecturas de varios niveles, evalúe el nivel de presentación, el nivel de servicio, el nivel de integraciones y la capa de datos.

Las siguientes listas de comprobación sirven para evaluar una aplicación para determinar la complejidad y el riesgo de rediseñar o de recompilar.

Complejidad y riesgo

Cada uno de estos factores se suma a la complejidad, el riesgo o ambos.

Architecture

Defina la arquitectura de alto nivel, como la aplicación web, los servicios web, el almacenamiento de datos o el almacenamiento en caché.

Factor Complejidad Riesgo
Los componentes de la aplicación no se convierten directamente en Azure. ✔ ✔
La aplicación necesita cambios de código para ejecutarse en Azure. ✔ ✔
La aplicación necesita cambios de código importantes y complejos para ejecutarse en Azure. ✔ ✔

Impulsores del negocio

Es posible que las aplicaciones más antiguas necesiten cambios importantes para llegar a la nube.

Factor Complejidad Riesgo
Esta aplicación está presente desde hace más de tres años. ✔
Esta aplicación es crítica para la empresa. ✔
Hay bloqueadores de tecnología para la migración. ✔
Hay bloqueadores de la empresa para la migración. ✔
Esta aplicación tiene requisitos de cumplimiento. ✔
La aplicación está sujeta a requisitos de datos específicos del país o región. ✔
La aplicación es de acceso público. ✔ ✔

Tecnología

Factor Complejidad Riesgo
No es una aplicación basada en web y no está hospedada en un servidor web. ✔
La aplicación no se hospeda en Windows IIS. ✔
La aplicación no se hospeda en Linux. ✔
La aplicación se hospeda en una granja de servidores web y necesita varios servidores para hospedar los componentes web. ✔ ✔
La aplicación necesita que se instale software de terceros en los servidores. ✔ ✔
La aplicación se hospeda en un solo centro de recursos y las operaciones se realizan en una sola ubicación. ✔
La aplicación tiene acceso al registro del servidor. ✔
La aplicación envía mensajes de correo electrónico y necesita acceso a un servidor SMTP. ✔
No es una aplicación .NET. ✔
La aplicación usa SQL Server como almacén de datos. ✔
La aplicación almacena datos en discos locales y necesita acceso a los discos para que funcionen correctamente. ✔
La aplicación usa los servicios de Windows para procesar las operaciones asincrónicas o necesita servicios externos para procesar datos u operaciones. ✔

Implementación

Al evaluar los requisitos de implementación, tenga en cuenta esto:

  • Número de usuarios diarios
  • Cantidad media de usuarios simultáneos
  • Tráfico esperado
  • Ancho de banda en Gbps
  • Solicitudes por segundo
  • Cantidad de memoria necesaria

Puede reducir el riesgo de implementación si almacena código bajo control de código fuente en un sistema de control de versiones como Git, Azure DevOps Server o SVN.

Factor Complejidad Riesgo
Usar el código y los datos existentes es la principal prioridad. ✔ ✔
El código de la aplicación no está bajo control de código fuente. ✔
No hay ningún proceso de compilación automatizado como Azure DevOps Server o Jenkins. ✔
No hay ningún proceso de lanzamiento automatizado para implementar la aplicación. ✔ ✔
La aplicación tiene un Acuerdo de Nivel de Servicio (SLA) que determina la cantidad de tiempo de inactividad esperado. ✔
La aplicación experimenta cargas o tiempos de uso máximo o variable. ✔
La aplicación web guarda su estado de sesión en proceso, en lugar de un almacén de datos externo. ✔

Operaciones

Factor Complejidad Riesgo
La aplicación no tiene una estrategia de instrumentación bien establecida o un marco de instrumentación estándar. ✔
La aplicación no usa herramientas de supervisión y el equipo de operaciones no supervisa el rendimiento de la aplicación. ✔
La aplicación tiene un acuerdo de nivel de servicio medido y el equipo de operaciones supervisa el rendimiento de la aplicación. ✔
La aplicación escribe en un almacén de registros, un registro de eventos, un archivo de registro, una base de datos de registro o Application Insights. ✔
La aplicación no escribe en un almacén de registros, un registro de eventos, un archivo de registro, una base de datos de registro o Application Insights. ✔
La aplicación no forma parte del plan de recuperación ante desastres de la organización. ✔

Seguridad

Factor Complejidad Riesgo
La aplicación usa Active Directory para autenticar a los usuarios. ✔ ✔
La organización aún no ha configurado Microsoft Entra ID o no ha configurado Microsoft Entra Connect para sincronizar AD local con Microsoft Entra ID. ✔
La aplicación necesita acceso a los recursos locales, para lo que se necesitará conectividad VPN de Azure. ✔
La organización aún no ha configurado una conexión VPN entre Azure y su entorno local. ✔ ✔
La aplicación necesita un certificado SSL para ejecutarse. ✔ ✔

Results

A partir de las tablas anteriores, determine si cada factor se aplica a la aplicación. Cuente el número de marcas de verificación de complejidad y riesgo para los factores que se aplican a la aplicación.

  • El nivel de complejidad esperado para migrar o modernizar la aplicación en Azure es: Factores de complejidad coincidentes/factores de complejidad posibles totales.
  • El riesgo esperado implicado es: Factores de riesgo coincidentes/factores de riesgo posibles totales.

Factores de complejidad posibles totales = 28, Factores de riesgo posibles totales = 23

En cuanto a complejidad y riesgo, la puntuación obtenida del cálculo anterior de <0,3 = Bajo, <0,7 = Medio, >0,7 = Alto. Estas puntuaciones proporcionan una escala relativa de complejidad y riesgo.

Refactorizar, rediseñar o recompilar

Para racionalizar si se debe volver a hospedar, refactorizar, rediseñar o recompilar la aplicación, tenga en cuenta estos aspectos. Muchos de estos factores también contribuyen a la complejidad y el riesgo.

Determine si los componentes de la aplicación pueden traducirse directamente a Azure. Si es así, no es necesario realizar cambios en el código para trasladar la aplicación a Azure y podría usar estrategias de rehospedaje o refactorización. Si no es así, debe volver a escribir el código, para lo que necesita rediseñar o recompilar.

Si la aplicación necesita cambios en el código, determine la complejidad y el alcance de los cambios necesarios. Los cambios menores podrían permitir el rediseño, mientras que para los cambios más importantes puede ser necesario recompilar.

Rehospedar o refactorizar

  • Si la principal prioridad es usar el código y los datos existentes, considere la posibilidad de refactorizar en lugar de rediseñar o recompilar.

  • Si tiene escalas de tiempo que ejercen presión, como el cierre del centro de datos o la expiración del contrato, licencias para el final del ciclo de vida o fusiones o adquisiciones, la manera más rápida de llevar la aplicación a Azure sería rehospedar y después refactorizar para aprovechar las funciones de la nube.

Rediseñar o recompilar

  • Si dispone de aplicaciones que cubren necesidades similares, podría ser una oportunidad para rediseñar o recompilar la solución completa.

  • Si quiere implementar la arquitectura de varios niveles o microservicios para una aplicación monolítica, debe rediseñar o recompilar la aplicación. Si no le importa conservar la estructura monolítica, es posible que pueda rehospedar o refactorizar.

  • Rediseñe o recompile la aplicación para aprovechar las funciones de la nube si tiene previsto actualizar la aplicación con más frecuencia que la anual, si la aplicación tiene tiempos de uso máximo o variable, o si espera que la aplicación controle el tráfico elevado.

Para decidir entre rediseñar o recompilar, valore estos factores. La mayor puntuación indica que es la mejor estrategia.

Factor Rediseño Recompilación
Dispone de otras aplicaciones que cubren necesidades similares. ✔ ✔
La aplicación necesita pequeños cambios de código para ejecutarse en Azure. ✔
La aplicación necesita cambios de código importantes y complejos para ejecutarse en Azure. ✔
Es importante usar el código existente. ✔
Quiere trasladar una aplicación monolítica a una arquitectura de varios niveles. ✔
Quiere trasladar una aplicación monolítica a una arquitectura de microservicios. ✔ ✔
Espera que esta aplicación agregue funciones innovadoras como AI, IoT o bots. ✔
Entre las funciones, el costo, la infraestructura y los procesos, las funciones son el aspecto menos eficaz de esta aplicación. ✔
La aplicación necesita que se instale software de terceros en los servidores. ✔
La aplicación tiene acceso al registro del servidor. ✔
La aplicación envía mensajes de correo electrónico y necesita acceso a un servidor SMTP. ✔
La aplicación usa SQL Server como almacén de datos. ✔
La aplicación almacena datos en discos locales y necesita acceso a los discos para que se ejecuten correctamente. ✔
La aplicación usa los servicios de Windows para procesar las operaciones asincrónicas o necesita servicios externos para procesar datos u operaciones. ✔
La aplicación web guarda su estado de sesión en proceso, en lugar de un almacén de datos externo. ✔
La aplicación tiene cargas y tiempos de uso máximo y variable. ✔ ✔
Espera que la aplicación controle el tráfico elevado. ✔ ✔

Pasos siguientes