Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La racionalización de la nube es el proceso de evaluación de recursos para determinar el mejor enfoque para hospedarlos en la nube. Una vez que haya determinado un enfoque y agregado un inventario, puede comenzar la racionalización de la nube. La racionalización de la nube describe las opciones de racionalización más comunes.
Vea el vídeo siguiente para obtener una visión general rápida sobre cómo completar una evaluación completa que le ayudará a planear y priorizar los esfuerzos de migración.
Vista tradicional de la racionalización
Es fácil entender la racionalización al visualizar el proceso tradicional de racionalización como un árbol de decisión complejo. Cada recurso del patrimonio digital se alimenta a través de un proceso que da como resultado una de las cinco respuestas (las cinco R de racionalización). Para pequeñas fincas, este proceso funciona bien. En el caso de los patrimonios más grandes, es ineficaz y puede provocar retrasos significativos. Examinemos el proceso para ver por qué. A continuación, presentaremos un modelo más eficaz.
Inventario: Se requiere un inventario exhaustivo de recursos, incluidas aplicaciones, software, hardware, sistemas operativos y métricas de rendimiento del sistema, para completar una racionalización completa mediante modelos tradicionales.
Análisis cuantitativo: En el árbol de decisión, las preguntas cuantitativas impulsan la primera capa de decisiones. Entre las preguntas comunes se incluyen las siguientes:
- ¿El recurso está en uso hoy?
- Si es así, ¿está optimizado y se ajusta correctamente?
- ¿Qué dependencias existen entre los recursos? Estas preguntas son fundamentales para la clasificación del inventario.
Análisis cualitativo: El siguiente conjunto de decisiones requiere inteligencia humana en forma de análisis cualitativo. A menudo, las preguntas que aparecen aquí son únicas para la solución y solo las partes interesadas empresariales y los usuarios avanzados pueden responderlas. Estas decisiones suelen retrasar el proceso, lo que ralentiza considerablemente las cosas. Este análisis generalmente consume de 40 a 80 horas de FTE por aplicación.
Para obtener instrucciones sobre cómo crear una lista de preguntas de análisis cualitativos, consulte Enfoques para el planeamiento del patrimonio digital.
Decisión de racionalización: En manos de un equipo de racionalización experimentado, los datos cualitativos y cuantitativos crean decisiones claras. Desafortunadamente, los equipos con un alto grado de experiencia de racionalización son costosos de contratar o tardar meses en entrenarse.
Racionalización a escala empresarial
Si este esfuerzo consume mucho tiempo y es abrumador para un patrimonio digital de 50 máquinas virtuales, imagine el esfuerzo necesario para impulsar la transformación empresarial en un entorno con miles de máquinas virtuales y cientos de aplicaciones. El esfuerzo humano necesario puede superar fácilmente 1500 horas FTE y nueve meses de planificación.
Aunque la racionalización completa es el estado final y una excelente dirección para moverse, rara vez produce un alto ROI (rentabilidad de la inversión) en relación con el tiempo y la energía que se requiere.
Cuando la racionalización es esencial para las decisiones financieras, merece la pena considerar una organización de servicios profesionales especializada en la racionalización de la nube para acelerar el proceso. Incluso entonces, la racionalización completa puede ser un esfuerzo costoso y lento que retrasa la transformación o los resultados empresariales.
En el resto de este artículo se describe un enfoque alternativo, conocido como racionalización incremental.
Racionalización incremental
La racionalización completa de un patrimonio digital grande es propensa a riesgos y puede sufrir retrasos debido a su complejidad. La suposición detrás del enfoque incremental es que las decisiones retrasadas escalonan la carga en la empresa para reducir el riesgo de obstáculos. Con el tiempo, este enfoque crea un modelo orgánico para desarrollar los procesos y la experiencia necesarios para tomar decisiones de racionalización calificadas de forma más eficaz.
Inventario: reducción de los puntos de datos de detección
Pocas organizaciones invierten el tiempo, la energía y los gastos en mantener un inventario preciso en tiempo real del patrimonio digital completo. La pérdida, el robo, los ciclos de actualización y la incorporación de empleados a menudo justifican el seguimiento detallado de recursos de los dispositivos del usuario final. El ROI de mantener un inventario preciso de aplicaciones y servidores en un centro de datos local tradicional suele ser bajo. La mayoría de las organizaciones de TI tienen problemas más urgentes que el seguimiento del uso de recursos fijos en un centro de datos.
En una transformación en la nube, el inventario se correlaciona directamente con los costos operativos. Se requieren datos de inventario precisos para planear correctamente. Desafortunadamente, las opciones actuales de examen ambiental pueden retrasar las decisiones por semanas o meses. Afortunadamente, algunos trucos pueden acelerar la recopilación de datos.
El análisis basado en agente es el retraso citado con más frecuencia. Los datos sólidos que se requieren para una racionalización tradicional a menudo solo pueden recopilarse con un agente que se ejecuta en cada recurso. Esta dependencia de los agentes a menudo ralentiza el progreso, ya que puede requerir comentarios de las funciones de seguridad, operaciones y administración.
En un proceso de racionalización incremental, se podría usar una solución sin agente para una detección inicial para acelerar las decisiones tempranas. Dependiendo del nivel de complejidad del entorno, se puede necesitar una solución basada en agentes, pero puede eliminarse de la ruta crítica al cambio de negocio.
Análisis cuantitativo: Simplificación de las decisiones
Independientemente del enfoque para la detección de inventario, el análisis cuantitativo puede impulsar las decisiones iniciales y las suposiciones. Esto es especialmente cierto al intentar identificar la primera carga de trabajo o cuando el objetivo de la racionalización es una comparación de costos de alto nivel. En un proceso de racionalización incremental, el equipo de estrategia en la nube y los equipos de adopción de la nube limitan las cinco R de racionalización a dos decisiones concisas y solo aplican esos factores cuantitativos. Esto simplifica el análisis y reduce la cantidad de datos iniciales necesarios para impulsar el cambio.
Por ejemplo, si una organización está en medio de una migración de IaaS a la nube, puede suponer que la mayoría de las cargas de trabajo se retirarán o se volverán a hospedar.
Análisis cualitativo: suposiciones temporales
Al reducir el número de resultados potenciales, es más fácil llegar a una decisión inicial sobre el estado futuro de un recurso. Al reducir las opciones, también se reduce el número de preguntas que se plantean al negocio en esta fase temprana.
Por ejemplo, si las opciones se limitan a rehospedar o retirar, la empresa solo debe responder a una pregunta durante la racionalización inicial, que es si se va a retirar el recurso.
"El análisis sugiere que ningún usuario está usando activamente este recurso. ¿Es tan preciso o hemos pasado por alto algo?" Este tipo de pregunta binaria suele ser mucho más fácil de ejecutar a través del análisis cualitativo.
Este enfoque simplificado genera líneas base, planes financieros, estrategia y dirección. En actividades posteriores, cada recurso pasa por una mayor racionalización y análisis cualitativo para evaluar otras opciones. Todas las suposiciones que realice en esta racionalización inicial se prueban antes de migrar cargas de trabajo individuales.
Suposiciones de desafío
El resultado de la sección anterior es una racionalización aproximada que está llena de suposiciones. A continuación, es hora de desafiar algunas de esas suposiciones.
Retirar activos
En un entorno local tradicional, el hospedaje de recursos pequeños y sin usar rara vez provoca un impacto significativo en los costos anuales. Con algunas excepciones, el ahorro de costos derivado de la limpieza y retirada de estos recursos se compensa por el tiempo de empleados a tiempo completo requerido para analizar y retirar el recurso.
Al pasar a un modelo de contabilidad en la nube, la retirada de recursos puede producir ahorros significativos en los costos operativos anuales y los esfuerzos de migración por adelantado.
No es raro que las organizaciones retiren el 20 % o más de su patrimonio digital después de completar un análisis cuantitativo. Se recomienda realizar un análisis cualitativo adicional antes de tomar medidas. Una vez confirmado, retirar esos recursos puede producir la primera victoria de ROI de la migración a la nube. Esto suele ser uno de los factores de ahorro de costos más importantes. Por lo tanto, el equipo de estrategia en la nube debe supervisar la validación y retirada de los recursos, en paralelo con la ejecución de la metodología de migración, para lograr una ganancia financiera temprana.
Ajustes del programa
Una empresa rara vez se embarca en un solo recorrido de transformación. La elección entre la reducción de costos, el crecimiento del mercado y los nuevos flujos de ingresos rara vez es una decisión binaria. Por lo tanto, se recomienda que el equipo de estrategia en la nube trabaje con TI para identificar los recursos en los esfuerzos de transformación paralelos que están fuera del ámbito del recorrido de transformación principal.
En el ejemplo de migración de IaaS que se proporciona en este artículo:
Pida al equipo de DevOps que identifique los recursos que ya forman parte de una automatización de implementación y quite esos recursos del plan de migración principal.
Pida a los equipos de datos e I+D que identifiquen los recursos que impulsan nuevos flujos de ingresos y los quiten del plan de migración principal.
Este análisis cualitativo centrado en el programa se puede ejecutar rápidamente y crea una alineación entre varios trabajos pendientes de migración.
Tal vez tenga que considerar algunos recursos para rehospedaje durante un tiempo. Puede realizar una fase de racionalización posterior después de la migración inicial.
Selección de la primera carga de trabajo
La implementación de la primera carga de trabajo es clave para probar y aprender. Es la primera oportunidad de demostrar y crear una mentalidad de crecimiento.
Criterios empresariales
Para garantizar la transparencia empresarial, identifique una carga de trabajo respaldada por un miembro de la unidad de negocio del equipo de estrategia en la nube. Preferiblemente elija uno en el que el equipo tenga una participación y una fuerte motivación para pasar a la nube.
Criterios técnicos
Seleccione una carga de trabajo que tenga dependencias mínimas y que se pueda mover como un pequeño grupo de recursos. Se recomienda seleccionar una carga de trabajo con una ruta de prueba definida para facilitar la validación.
La primera carga de trabajo se implementa a menudo en un entorno experimental sin capacidad operativa o de gobernanza. Es importante seleccionar una carga de trabajo que no interactúe con datos seguros.
Análisis cualitativo
Los equipos de adopción de la nube y el equipo de estrategia en la nube pueden trabajar juntos para analizar esta pequeña carga de trabajo. Esta colaboración crea una oportunidad controlada para crear y probar criterios de análisis cualitativos. La población más pequeña crea una oportunidad para encuestar a los usuarios afectados y para completar un análisis cualitativo detallado en una semana o menos. Para conocer los factores de análisis cualitativos comunes, vea el objetivo de racionalización específica en las cinco R de racionalización.
Migración
En paralelo con la racionalización continua, el equipo de adopción de la nube puede empezar a migrar la pequeña carga de trabajo para expandir el aprendizaje en las siguientes áreas clave:
- Reforzar las aptitudes con la plataforma del proveedor de nube.
- Defina los servicios principales y los estándares de Azure necesarios para adaptarse a la visión a largo plazo.
- Comprenda mejor cómo las operaciones pueden necesitar cambiar más adelante en la transformación.
- Comprenda los riesgos empresariales inherentes y la tolerancia de la empresa a esos riesgos.
- Establezca una base de referencia o un producto mínimo viable (MVP) para la gobernanza en función de la tolerancia al riesgo de la empresa.
Planificación de lanzamientos
Aunque el equipo de adopción de la nube está ejecutando la migración o implementación de la primera carga de trabajo, el equipo de estrategia en la nube puede comenzar a priorizar las aplicaciones y cargas de trabajo restantes.
La potencia de 10
El enfoque tradicional de racionalización intenta satisfacer todas las necesidades previsibles. Afortunadamente, a menudo no es necesario un plan para cada aplicación para iniciar un recorrido de transformación. En un modelo incremental, el enfoque Power of 10 proporciona un buen punto de partida. En este modelo, el equipo de estrategia en la nube selecciona las primeras 10 aplicaciones que se van a migrar. Esas diez cargas de trabajo deben contener una combinación de cargas de trabajo simples y complejas.
Creación de los primeros trabajos pendientes
Los equipos de adopción de la nube y el equipo de estrategia en la nube pueden trabajar juntos en el análisis cualitativo de las primeras 10 cargas de trabajo. Este esfuerzo crea la primera lista de pendientes de migración priorizada y la primera lista de pendientes de lanzamiento priorizada. Este método permite a los equipos iterar en el enfoque y proporciona tiempo suficiente para crear un proceso adecuado para el análisis cualitativo.
Madurar el proceso
Después de que los dos equipos acepten los criterios de análisis cualitativos, la evaluación puede convertirse en una tarea dentro de cada iteración. Alcanzar el consenso sobre los criterios de evaluación normalmente requiere dos a tres versiones.
Una vez que la evaluación se ha movido al proceso de ejecución incremental de la migración, el equipo de adopción de la nube puede acelerar la iteración sobre la evaluación y la arquitectura. En esta fase, el equipo de estrategia en la nube también se libera de ciertas tareas, lo que reduce el consumo de su tiempo. Esto también permite al equipo de estrategia en la nube centrarse en priorizar las aplicaciones que aún no están en una versión específica, lo que garantiza una alineación estrecha con las condiciones cambiantes del mercado.
No todas las aplicaciones prioritarias estarán listas para la migración. Es probable que la secuenciación cambie, ya que el equipo realiza un análisis cualitativo más profundo y detecta eventos empresariales y dependencias que podrían solicitar la repetición del trabajo pendiente. Algunas versiones pueden agrupar un pequeño número de cargas de trabajo. Otras podrían contener una única carga de trabajo.
Es probable que el equipo de adopción de la nube ejecute iteraciones que no produzcan una migración completa de la carga de trabajo. Cuanto menor sea la carga de trabajo y menos dependencias, más probable es que una carga de trabajo se ajuste a un solo sprint o iteración. Por este motivo, se recomienda que las primeras aplicaciones del trabajo pendiente de versión sean pequeñas y contengan pocas dependencias externas.
Finalización del estado
Con el tiempo, el equipo de adopción de la nube y el equipo de estrategia en la nube completan una racionalización completa del inventario. Este enfoque incremental permite a los equipos obtener continuamente más rapidez en el proceso de racionalización. También ayuda al recorrido de transformación a producir resultados empresariales tangibles antes, sin tanto esfuerzo inicial de análisis.
En algunos casos, el modelo financiero podría ser demasiado estricto para tomar una decisión sin racionalización adicional. En tales casos, es posible que necesite un enfoque más tradicional para la racionalización.
Pasos siguientes
La salida de un esfuerzo de racionalización es una lista de tareas pendientes priorizada de todos los recursos que son afectados por la transformación elegida. Este trabajo pendiente ya está listo para servir como base para los modelos de costos de los servicios en la nube.