Errores comunes que se deben evitar al migrar

Para las empresas, poder migrar miles de aplicaciones es una parte inevitable de su competitividad. Descubrir cómo lograr una migración exitosa da miedo, así que profundicemos en las trampas que hay que evitar.

COVID-19 ha creado una escasez de talento técnico combinada con un aumento en la demanda de plazos técnicos acelerados. Muchas empresas están comenzando a enfrentar un efecto de " Reina Roja ", donde las empresas tienen que redefinir cómo y dónde compiten en el mercado para garantizar que sigan siendo relevantes. Hoy en día, las empresas que se mantienen complacientes son recompensadas con una gran desventaja y un ciclo perpetuo de recuperación. Las migraciones de las tecnologías existentes a soluciones más receptivas y rentables son una parte importante de la metamorfosis de cualquier empresa; sin embargo, puede estar plagado de trampas para los que no están preparados.

Según un estudio realizado por Boston Consulting Group en 2020, que incluyó a 825 altos ejecutivos en 70 empresas que involucraron 895 transformaciones digitales, solo el 30 % de las transformaciones cumplieron sus objetivos de transformación.

Esos no son números para inspirar confianza. Afortunadamente, empresas como Stark & Wayne han trabajado para permitir múltiples migraciones empresariales para que otros puedan evitarlas. Stark & Wayne es un experto en la migración de infraestructuras a escala empresarial. Los proyectos anteriores han incluido implementaciones de Cloud Foundry Foundation que administran 45 000 instancias de aplicaciones.

Documentar una línea de base de rendimiento

¡Es un mandato! Todas las empresas exigen un mejor rendimiento, pero muchas carecen de métricas de rendimiento de referencia o formas de medir lo que significa un mejor rendimiento. ¿El rendimiento está relacionado con la experiencia del usuario final? ¿El rendimiento se basa en la ampliación y reducción de las cargas de trabajo para reducir el consumo? ¿Se mide el rendimiento en tiempo reducido para implementar o actualizar? Una vez que establezca cómo medirá el rendimiento, puede vincularlo a sus aplicaciones, clientes y negocios.

Esto le permitirá evaluar si las aplicaciones tienen un bajo rendimiento durante y después de la migración. También ayuda a gestionar las percepciones durante un cambio significativo y ayuda a cuantificar el éxito. Deberá comparar sus plataformas anteriores y posteriores a la migración con cargas de trabajo similares. Lo que mida depende de los requisitos comerciales, pero algunas medidas genéricas son:

• Tiempos de funcionamiento de los componentes
• Tiempos de respuesta de la aplicación
• Tiempos generales de ejecución de la aplicación
• Pruebe las aplicaciones para validar la conectividad de los componentes y la accesibilidad de los servicios
• Métricas de API (carga de página, uso de memoria, CPU, rendimiento del servidor)
• Carga de salida de registro
• Carga de informes de incidencias a lo largo del tiempo
• Automatización (y trate la automatización como un ciudadano de primera clase porque mejorará el rendimiento general)
• Cambios en los costos operativos debido a la migración y la automatización de tareas
• Pruebe con tipos de aplicaciones que modelen su entorno.

Buenos paneles: no puede migrar lo que no puede encontrar

La mayoría de las organizaciones saben lo que admiten ahora, pero necesitan identificar lo que quieren admitir después de la migración. Conocer la cantidad de instancias de la aplicación es fácil, ya que es probable que su proveedor le facture en función de esta métrica. Aún así, también necesitará saber la cantidad de aplicaciones, qué equipos admiten las aplicaciones, qué aplicaciones tienen interdependencias y qué tipos de servicios consume cada aplicación. La identificación de estas variables ayudará a determinar cómo puede migrar y admitir el nuevo entorno.

Al mapear los propietarios de cada aplicación, es esencial identificar cuáles tienen scripts de prueba automatizados para validar que la aplicación funciona. Idealmente, cada aplicación tiene scripts de prueba automatizados, pero como mínimo, debe tener un mapeo de los propietarios de la aplicación. Además, deberá buscar aplicaciones no utilizadas y sin mantenimiento. Lo último que desea hacer es migrar una aplicación no funcional (hemos visto que esto sucede) cuando la aplicación necesita eliminarse o repararse antes de la migración. Un sorprendente número de veces, encontrará que no existe un mapeo maestro de propietarios de aplicaciones, lo que plantea problemas durante y después de la migración.

Por lo tanto, el enfoque es "inventario, inventario, inventario" ya que muchas empresas no tienen un lugar central que catalogue quién posee cada aplicación, qué tiene o hace cada aplicación y cuál es el impacto comercial de la aplicación. La capacidad de consultar y encontrar rápidamente información relevante es vital para las operaciones, la eficiencia y la toma de decisiones comerciales.

¿Donde empezar? Primero, responda las preguntas más amplias:

• ¿En qué regiones estás corriendo y por qué?
• ¿Qué aplicaciones se ejecutan en cada región?
• ¿Qué servicios utiliza cada aplicación en cada región?
• ¿Qué versión de Linux está en uso?
• ¿Qué aplicaciones se comunican con otras aplicaciones en una región?
• ¿Qué aplicaciones están orientadas al cliente frente a las internas?

La recopilación de estos puntos de datos iniciales no responderá a todas las incógnitas, pero comenzarán a brindarle la información que necesita.

Audite lo que pueda: y acepte lo desconocido

No importa qué tan bien audite o documente cada detalle, habrá variables desconocidas que afectarán el tiempo de inactividad, los clientes, los compañeros de trabajo, los gastos y el cronograma. Estas incógnitas solo se pueden encontrar cuando el equipo técnico se ensucia las manos con el proceso de migración. Así es como puedes apoyarlos:

• Agregar una línea de tiempo para incógnitas
• Tener más recursos disponibles para ayudar cuando un elemento desconocido crea un problema
• Sea flexible con las políticas de la empresa, las reuniones internas y los lanzamientos de nuevas funciones
• Tenga planes de respaldo, como reversiones si las pruebas fallan
• Concéntrese primero en las pequeñas victorias para ganar impulso mientras planifica las grandes. Recuerde, las ganancias rápidas tangibles pueden ayudar a mejorar la moral siempre que no causen más gastos generales operativos.

El método preferido es realizar una auditoría completa y documentar las estructuras y relaciones organizacionales y usar esto como referencia a lo largo del trabajo. Una vez que comience el proyecto, esta documentación se convertirá en su mapa y le ayudará a evitar perder prioridades o poner elementos en espera. Es posible que descubra que es necesario escalar a la gerencia superior para priorizar las acciones que necesita impulsar. Aún así, la preferencia debe ser comprender cómo funcionan los equipos individuales y establecer una buena comunicación con ellos en lugar de pasar por alto sus cabezas.

Seguridad: lleve al equipo de SecOps a almorzar

No queremos decir esto en el estilo de Tony Soprano "Llévalos a dar un paseo"; realmente nos referimos a llevar al equipo de seguridad a almorzar para establecer una relación cara a cara. El equipo de seguridad es vital para que el proceso de migración restrinja, afloje o proporcione soluciones alternativas para los bloqueadores que surjan. También necesita su revisión expedita de cualquier nuevo software necesario para que su migración sea un éxito. Un equipo de seguridad que se descuide será un bloqueador. Enfrentémoslo con otra terrible analogía de película, la seguridad nunca quiere ser el Caballero Negro de Monty Python gritando: "¡Ninguno pasará!" pero realmente quieren cumplir el papel vital de mantener todo a salvo. Al final, la seguridad quiere habilitar a todos dentro de la organización, siempre que existan las pautas adecuadas. Si los involucra temprano, evitará dolores de cabeza cuando se detenga la seguridad en el último minuto.

Resistir el avance del alcance: Esa es una idea realmente genial... para el próximo año

El desplazamiento del alcance debe manejarse con cuidado. Todas las organizaciones quieren resolver sus problemas simultáneamente, pero usted debe concentrarse en resolver un problema muy específico. Tomando como ejemplo el cambio de Pivotal Cloud a Cloud Foundry de código abierto, las fortalezas clave de Cloud Foundry son las muchas funciones que se pueden agregar y el potencial de personalización. Por ejemplo, mejorar la postura de recuperación ante desastres y las copias de seguridad puede ser tentador, pero crear un alcance adicional crea puntos débiles adicionales.

El desplazamiento del alcance también crea un problema en el que algo puede romperse y no puede estar seguro de si la rotura fue causada por el objetivo general del proyecto o por el alcance adicional.

Mirroring: Coincidiendo con el mundo que quieres dejar atrás

Una vez que haya establecido los parámetros para su proyecto y los resultados deseados, debe asegurarse de haber reflejado todos los entornos que se migrarán. Esto incluye su entorno de operaciones o "patio de recreo", donde probará todo antes, pasando a la no producción y, finalmente, a la producción.

Cuando construya el entorno de juegos, querrá asegurarse de que la tecnología actual, en nuestro ejemplo Pivotal, sea similar a su entorno de no producción. Esto le permitirá estar más seguro de que se encontrará con menos problemas.

La gestión importa: hacer amigos en las altas esferas

Necesitará el apoyo de la gerencia, así que no pinte una imagen completamente optimista. Las migraciones tienen un largo camino por delante. Mover la plataforma es una cosa, pero también hay que lidiar con todos los servicios. La gerencia necesita conocer su enfoque de la migración y su plan para mitigar el riesgo comercial. La gerencia estará nerviosa ya que las migraciones podrían afectar el resultado final, por lo que debe discutir todas sus medidas para evitar eso.

Fracasar bien: convertirlo en un éxito

El fracaso es bueno, el fracaso es grandioso y se debe esperar el fracaso siempre que implemente las lecciones aprendidas la próxima vez. No se puede dar cuenta de todo, y las fallas percibidas ocurren cuando las incógnitas se convierten en un bloqueador. Permitir que la gerencia sepa que habrá fallas evitará las connotaciones negativas y mejorará la moral general. De hecho, debe celebrar los aprendizajes del fracaso porque está progresando. Para vender que la falla es aceptable, necesita un plan de respaldo claro. Tenga esto como parte de la planificación de su día de migración con puntos de decisión de ir/no ir para retroceder.

Las tarifas de licencia y el riesgo son los principales impulsores para migrar a Open Source Cloud Foundry o Kubernetes. Para las grandes organizaciones que ejecutan miles de aplicaciones, lo que está en juego es de misión crítica. Con la creciente demanda de escala y la escasez de desarrolladores, las migraciones parecen arriesgadas. La principal preocupación es evitar el impacto en los equipos de aplicación y evitar el tiempo de inactividad. La buena noticia es que Stark & Wayne ha realizado muchas migraciones exitosas a escala empresarial que se adhirieron al impacto mínimo del desarrollador y tiempos de inactividad limitados a las ventanas de control de cambios.

Al descartar estos errores comunes que hemos encontrado, es menos probable que su próximo proyecto se convierta en parte de ese 70% que Boston Consulting Group sugiere que no obtiene lo que espera.

También publicado aquí .