Migración a la nube y modernización

Jonathan Allen:
Bienvenido a Conversaciones con líderes. Mi nombre es Jonathan Allen, soy director del equipo de estrategia empresarial de Amazon Web Services. Hoy me acompaña mi colega, Jake Burns. Hablaremos sobre la migración a la nube y la modernización. Jake, ¿quieres presentarte?

Jake Burns:
Sí, gracias, Jonathan. Me llamo Jake Burns. Soy estratega empresarial en AWS y llevo en este puesto poco más de seis años. Durante ese tiempo, he tratado con más de mil clientes y muchas de esas conversaciones han girado en torno a la migración. Así que estoy muy emocionado por tener esta conversación contigo, Jonathan, y compartir algunas de las lecciones que he aprendido a lo largo de los años.

Jonathan Allen:
Estupendo, Jake. Y creo que, en conjunto, hemos tenido el privilegio de trabajar con más de 2300 clientes y sé que, obviamente, ambos éramos clientes que gestionaban grandes migraciones y modernizaciones antes de unirnos a Amazon Web Services. Ahora, tú y yo llevamos más de 10 años liderando este ámbito, y no quiero extenderme demasiado en las razones por las que los clientes migran sus recursos. Creo que eso ya ha quedado demostrado con los millones de clientes que utilizan AWS. Quiero pasar directamente a las lecciones de esta conversación, Jake.

Tú y yo tenemos el privilegio de tener esas charlas. La gente nos pregunta sobre esas lecciones todo el tiempo. Y si piensas en el pasado, tanto en tu época de cliente, como en el tiempo que has trabajado en Amazon Web Services durante varios años, ¿cuáles son las tres cosas que más te llaman la atención? Me gustaría hablar sobre eso. Y luego quiero pasar a los consejos prácticos sobre algunos de los mitos que la gente tiene en torno a la migración. Entonces ¿cuáles son las tres cosas principales que se te vienen a la mente?

Jake Burns:
Sí, si hablamos de migraciones y transformación en general, creo que esto también se aplica. Cuando recordamos lo que hice al frente de una migración exitosa en 2015 y 2016 y los clientes con los que he trabajado desde entonces que han tenido éxito, una de las cosas que me sorprendió al comenzar en este puesto fue la poca cantidad de interacciones que se necesitaron para ver emerger estos patrones claros. Dicho de otra manera, no son tan únicos como imaginaba y como la mayoría de los clientes piensan que son. Sus situaciones son todas bastante similares en cuanto a lo que funciona y lo que no. Yo diría que lo más importante, y es muy difícil elegir una número uno, es que hay que empezar antes de sentirte preparado. La mayoría de los clientes que han tenido mucho éxito no esperaron a tener un plan perfecto para empezar la migración, me incluyo en esto y creo que en tu caso también fue así.

Los clientes que lo hacen, terminan malgastando meses, a veces años, en esas fases de planificación. Y luego, una vez que comienzan, se dan cuenta de que tienen que descartar el plan de todos modos porque sus expectativas y sus planes se encuentran con la realidad y aprenden a lograr sus objetivos con la práctica. Así que mi sugerencia es saltarse esa planificación tanto como sea posible y empezar con el proceso. Hay formas en las que puedes hacerlo de una manera muy segura y espero que lo abordemos más adelante en la conversación. Yo diría que la segunda es invertir en el personal. Y eso incluye conseguir su apoyo. Los clientes que tienen más éxito son los que recurren a sus propios empleados y hacen que estos participen en la migración y la transformación. Luego, la número tres, diría que es la simplicidad. Se debe mantener el proceso lo más sencillo posible. También debe ser rápido, que es el tema más importante y el tipo de metodología que promuevo. Para ser ágil, es necesario simplificar las cosas porque la complejidad ralentiza la operación.

Jonathan Allen:
Bien dicho. La idea de comenzar antes de estar preparado es algo que entiendo particularmente. Creo que una de las cosas que sí pregunto a los clientes de acuerdo con mi experiencia es si su equipo de liderazgo entiende por qué llevan a cabo esa tarea. Considero que, si hay un equipo relativamente joven que simplemente piense: “Hagamos esto”, y no se ha conversado el asunto con el equipo ejecutivo, entonces se van a presentar algunos problemas. Por eso, creo que me encanta la idea de empezar antes de estar preparado. Me encanta la simplicidad, pero también ¿entienden realmente el motivo de la tarea? Dijimos al principio que no íbamos a profundizar en ello, pero hay muchos buenos motivos.

¿Cuál es el principal motivo? ¿Llegar al mercado más rápido? ¿Reducir los costos? ¿La disponibilidad? ¿La fiabilidad? ¿Se quiere ajustar el tamaño del centro de contacto? Para mí, ese motivo imperioso es realmente importante. Además, en segundo lugar, me encanta tu idea de empezar sin rodeos, pero ¿no te estás guiando por el miedo, la incertidumbre y las dudas normales entre los ingenieros que tal vez no estén involucrados directamente en esa fase de puesta en marcha? ¿Cómo vas a hacer que sea accesible, amigable y atractivo para ellos sin asustarlos en ese momento? ¿Qué opinas?

Jake Burns:
Sí, estoy totalmente de acuerdo. Creo que eso se relaciona mucho con mi segunda respuesta: involucrar a los empleados y, específicamente, lograr que acepten el proyecto. Tengo una técnica muy particular para abogar por la aceptación y gran parte de eso, de hecho, la parte más importante de eso es que entiendan ese gran por qué. Y, de acuerdo con tu punto de vista, no puede deberse a que nos traslademos a la nube ni a que nos estemos modernizando, ni siquiera porque el director ejecutivo lo haya indicado. No pueden ser razones vagas como esas. Debe ser algo que realmente entiendan para comprender por qué se les pide que cambien y por qué deben hacer este esfuerzo y trabajo adicionales. Pero también debe ser algo de lo que puedan enorgullecerse. No es fácil enorgullecerse de una migración a la nube para ahorrar costos o nos estamos mudando… Eso puede impulsarte mucho a ti, pero es mejor si el motivo es a revolucionar la experiencia de los fanáticos.

Vamos a… Los fanáticos que asistan a conciertos o eventos en vivo tendrán una experiencia mucho mejor. Les va a resultar más fácil conseguir entradas. Van a conseguir el asiento que realmente quieren. Van a poder disfrutar de todos estos beneficios que la tecnología puede ofrecer. Esas son razones de las que podrías enorgullecerte. Y, si se puede vincular el trabajo de migración en la mente de los empleados con esos resultados, que no son una invención, son reales, solo hay que comunicarlos, pero rara vez se comunican… Con esa información, harán el trabajo con orgullo. Y cuando surjan las complicaciones, lo cual siempre ocurre, tendrán una razón adicional para superarlas porque el trabajo que están realizando tiene un propósito y un significado para ellos.

Jonathan Allen:
Una de las cosas que siempre les digo a los ingenieros es que, en lugar de estar en el centro de datos a las tres de la mañana ocupados en algún control de cambios peculiar o haciendo algún tipo de mantenimiento, ¿no preferirían acercarse mucho más a los resultados reales que ofrecen, hacer realidad esa experiencia para los clientes?

Jonathan Allen:
Pasemos a algunos de los mitos que existen sobre la migración y la modernización en particular. Creo que en verdad se ha desarrollado un mundo de mitología a su alrededor. Por buenas y malas razones, hay una serie de aspectos que giran en torno a ello. Tú y yo tenemos el privilegio de ver lo que funciona. ¿Cuáles son algunos de los mitos que crees que existen y que debemos desmentir?

Jake Burns:
Sí. Considero que uno de los mitos es que esto tiene que ser difícil, va a ser complicado o tiene que llevar mucho tiempo. Creo que todas esas son creencias autocumplidas. Si crees que tiene que ser complicado, lo complicarás. Y si crees que tiene que llevar mucho tiempo, así será, pero en realidad no necesariamente. De acuerdo con mi experiencia, cuanto más exitosa es una migración, más rápido se completa. Por lo tanto, yo diría que la velocidad en realidad reduce el riesgo siempre y cuando hagas bien todas las demás tareas. Aumenta las probabilidades de éxito y nos obliga a eliminar complejidades en todo el proceso. En otras palabras, te obliga a simplificar procesos. Me gusta empezar por lo básico, volver atrás y, en lugar de hacer lo que yo llamo la danza de la lluvia migratoria o el culto a la carga, en los que uno marca un montón de casillas como: “La empresa A hizo todo esto y tuvo éxito, así que tengo que hacer todas esas tareas y no necesariamente tengo que entender por qué, pero si marco todas esas casillas, tendré éxito”. Eso rara vez funciona. Realmente no hay ningún tipo de atajo para entender los pasos necesarios para tener éxito con la migración. Pero la buena noticia es que es muy sencillo si vuelves a esos principios básicos y piensas en lo que se está haciendo realmente. En el nivel más básico, una migración consiste en sacar los servidores de las instalaciones y reconstruirlos en un entorno virtual en la nube. También pueden llevarse a un entorno virtual local.

Por eso, si lo piensas en esos términos, no es algo muy difícil de hacer. No es un concepto muy difícil de entender. Y, si uno trabaja a partir de ese concepto tan simple y básico de lo que estamos haciendo y se plantea: “¿Qué no puede faltar para que tengamos éxito en esta tarea?”, todo se vuelve mucho más sencillo. Es más fácil que si se siguen las directrices sobre migración de personas que tal vez no lo hayan hecho antes o que tal vez se ven incentivadas a hacerlo más complicado porque ganan más dinero al complicar y alargar el proceso.

Creo que se puede tener más éxito si realmente se entiende lo que es y se comienza desde ahí. Luego, tal vez se incorpora a alguien que ayude cuando sea necesario. Puede sorprender la poca ayuda que realmente se necesita.

Jonathan Allen:
Sí, estoy de acuerdo. Creo que definitivamente es sorprendente. Sin embargo, creo que lo interesante es que algunos clientes sí necesitan un poco más de ayuda. Además, creo que se ha generado definitivamente el mito de que cualquier proveedor puede ayudar con la migración, y eso no es cierto en absoluto según mi experiencia. Es interesante, AWS tiene miles de socios, pero en realidad son muy pocos los que cuentan con certificación en programas de aceleración de la migración para ayudar a los clientes. Hemos establecido un estándar muy alto en esta área porque se deben aprender las lecciones de esta tarea, tener conocimiento sobre cómo migrar recursos y estar ahí para ayudar. Ahora tenemos cientos de organizaciones en el rubro.

Si se me permite añadir, creo que la otra falacia es que tenemos que pasar por este enorme programa de capacitación para que todos sepan cómo completar esta tarea. Y, a medida que se avanza, simplemente no es así, ¿verdad? Eso va a llegar. Creo que se debe desarrollar un mecanismo propio sobre lo correcto para los ingenieros, en materia de actualizar sus capacidades. ¿Programación en pareja? ¿Capacitaciones en línea? ¿Incentivos para aprobar los exámenes? He visto a muchos clientes usar el examen de asociado de soluciones de AWS, que es como una licencia de conducir para usar la nube. Aquí hay muchos mitos que podemos desmentir.

Creo que otro mito importante es que todos están muy ocupados con sus tareas en este momento. No tienen tiempo para ayudar con la migración. ¿Qué opinas sobre eso?

Jake Burns:
Hay tanto de lo que has dicho que comparto. Permíteme volver al asunto de la capacitación porque hay mucho para analizar allí. Soy un gran defensor de la capacitación, en primer lugar. De hecho, atribuyo mi éxito en gran parte al uso de las capacitaciones de AWS, que creo que no se aprecian lo suficiente. Creo que, con el calibre de los instructores y las capacitaciones, además de su eficacia, cuando el cliente las realiza correctamente, es decir, en el contexto adecuado, se puede marcar la diferencia. Y sin duda fue mi caso.

Para agregar a tu idea de las capacitaciones, creo que el momento en que se imparten es muy importante. Hago esta broma y digo: “Si quieres acabar con la moral de tu organización, envía a toda tu organización a capacitarse y, luego, subcontrata la migración”. Están listos para hacer la migración y después no tienen la oportunidad de realizarla. El mejor de los casos es que reciban la capacitación; formes a las personas adecuadas en el momento adecuado. Y acuden a la capacitación con conocimientos y habiendo aceptado esta transformación y esta migración, por lo que saben por qué tienen que prestar atención. Es algo que les importa. Forman parte de este proyecto. Saben que van a dirigir las tareas, que van a estar en el asiento del conductor, que van a ser ellos quienes realmente realicen la migración, así que prestan atención y, luego, dejas que pongan en práctica lo aprendido de inmediato.

Y según tu punto de vista, tiene que ser teoría y práctica en partes iguales. Debes permitir que se pongan manos a la obra y no puede ser todo teoría, ¿verdad? De hecho, tienen que probarlo. Y cuando lo hagas, creo que podría ser sumamente eficaz.

Jonathan Allen:
Sí, hay estudios reconocidos que afirman que si uno asiste a un curso de formación y no lo aplica de inmediato, solo retendrá el 10 % de lo aprendido. Mientras que si asistes a un curso de formación y lo usas de inmediato, aprovecharás el 100 % de esa formación. Es una cifra que asusta. Lo he visto muchas veces.

Jake Burns:
Por supuesto. Para saber cómo abordar el “Están demasiado ocupados”. Creo que es una pregunta fantástica, porque cuando uno consigue la aceptación de los empleados o incluso antes, normalmente diría que casi sin falta, la primera excusa que nos dan es: “Estamos demasiado ocupados. Tenemos un trabajo diurno. Estamos ocupados manteniendo todos estos sistemas y haciendo estas tareas. ¿De dónde vamos a sacar tiempo para hacer esto?”

Así que creo que se debe a un par de causas fundamentales. Una es que, de hecho, están demasiado ocupados. Creo que deberías observar lo que están haciendo actualmente y ver cuánto de ese trabajo es realmente necesario. Y, en muchos casos, gran parte de eso no es necesario. Gran parte es solo hacer el trabajo, a falta de un término mejor. Pero va a haber trabajo legítimo que les demandará mucho tiempo. Analicemos eso y veamos en qué medida ayuda a su crecimiento. ¿En qué medida está contribuyendo realmente al avance de su migración y transformación global? Y, por lo general, muy poco, si es que contribuye en algo, sirve realmente para construir el futuro. La mayor parte consiste en mantener el pasado, mantener los sistemas locales que tienen allí o simplemente hacer trabajos que podrían subcontratarse fácilmente.

Por eso tengo la reputación de estar en contra de la subcontratación, porque soy un firme defensor de utilizar a los empleados propios para hacer una migración, pero no estoy en contra de la subcontratación. De hecho, creo que debería hacerlo al revés de lo que la mayoría de nosotros haríamos, siguiendo nuestro primer instinto. Entonces, en lugar de subcontratar personas para la migración, lo que puede ser una mala idea en muchos casos, subcontrata todo lo ajeno a la migración, es decir, el trabajo genérico, el trabajo que hacen sus empleados y ocupa gran parte de su tiempo y les impide participar en la migración.

Eso brinda un montón de beneficios, incluidos: primero, que de hecho, les deja tiempo libre para que puedan participar en la migración. Y segundo, especialmente si lo comunicas como líder, la intención detrás de esto, el mensaje es: “Estoy liberando su tiempo porque quiero invertir en ustedes, porque quiero que aprendan a usar esta nueva tecnología y construyan el futuro de esta organización”. Y, por lo tanto, también podría ser una gran inyección de ánimo.

Jonathan Allen:
Sí, son muy buenas ideas. Algo que siempre les enseño a los líderes e ingenieros son dos lecciones sobre mi propia experiencia práctica con la tecnología. Y la primera es... El peor error que cometí como ingeniero, y la trampa en la que sigo cayendo hoy en día, es optimizar algo que no debería existir. Así que sigo manteniendo eso en el centro de datos. Estoy intentando mejorarlo un poco. ¿Sabes qué? Esa cosa ya no tiene por qué existir y, de hecho, debería trabajar para reducirla activamente y así poder dedicarme a algo, francamente, mucho más interesante.

Y lo segundo es cuando juntamos equipos, y he visto equipos fenomenales de seis o siete personas con una participación fenomenal, y normalmente cuatro o cinco de esas personas están concentrados en algo y la sexta y la séptima persona de ese equipo están pensando: “Eh, ¿qué estoy haciendo ahora mismo? Ya sé, voy a empezar un nuevo proyecto o una nueva optimización para esto”, en lugar de decir: “De hecho, vamos a declarar que nuestra prioridad es la nube”. Volviendo al por qué de la lección aprendida, permitamos que las personas aprendan nuevas habilidades y trabajen en ello. Y hay dos cosas rápidas que pueden reducir en el acto la carga de trabajo cognitiva que los ingenieros, en mi opinión, tienen la costumbre de asumir. ¿Qué opinas al respecto?

Jake Burns:
Por supuesto. No podría estar más de acuerdo. Y, de hecho, también vi que sucedía a menudo en ese escenario específico. Creo que es el deber, y considero que los líderes deben comunicarlo claramente, es el deber de las personas más experimentadas del equipo y de las personas que aceptaron primero la transformación y la migración, guiar a los demás miembros del equipo para que no se distraigan con proyectos y tareas diferentes. O bien, como dices, optimizar el statu quo actual, lo cual estoy de acuerdo, es un gran error y una pérdida de tiempo.

Es como si habláramos de pasar de economías de escala a economías de velocidad. El pensamiento de las economías de escala es el statu quo del estado estacionario, es decir, creemos que seguimos optimizando e intentando abaratar nuestros costos unitarios, mientras que las economías de velocidad son más disruptivas. Es, ¿cómo nos transformamos realmente y pensamos en cosas mejores para dedicarles nuestro tiempo?

Jonathan Allen:
Exacto.

Jake Burns:
Por eso me agrada tu forma de pensar en economías rápidas. Pero, con respecto a esa pregunta específica, si esas personas forman parte de sus operaciones diarias normales y de aquello en lo que se las incentiva y evalúa, su desempeño se evalúa con respecto a la tutoría de nuevas personas en el equipo o incluso al reclutamiento de nuevas personas para que se unan al equipo y a su tutoría e incorporación. En primer lugar, ayuda, crea esa sensación de trabajo en equipo y esa inyección de ánimo, de que estamos todos juntos en esto y ese componente de inclusión y meritocracia que es muy importante. Pero también ayuda a evitar la trampa que describiste, se distraen con otras tareas.

Jonathan Allen:
Genial. Voy a pasar a algunos de los aspectos más técnicos. Ambos vimos cómo las herramientas experimentaron, yo diría, la evolución de sus mejoras en múltiples ocasiones durante los últimos 10 años. Sin duda alguna, desde que trasladaba las cargas de trabajo hasta donde estamos ahora con el Servicio de migración de bases de datos. Se migraron más de 1 millón de bases de datos con la herramienta de conversión de esquemas. Pudimos ver cómo AWS MGM hace copias cifradas de cargas de trabajo a nivel de bits, lo que mejora considerablemente el ecosistema de socios. ¿Qué opinas sobre romper algunos de los mitos que existen actualmente en el ámbito de las herramientas?

Jake Burns:
Mi postura sobre el tema es que creo que uno de los mitos es que existe una herramienta para resolver el problema. Las herramientas rara vez van a resolver el problema, si es que alguna vez lo hacen. Las herramientas son multiplicadores de fuerza, por lo que ya debería tener una solución para el problema y está usando la herramienta para hacer que esa solución sea más eficiente.

No van a ser la panacea. No van a ser una llave maestra que abra todas las puertas. Por lo general, las herramientas que tienes hoy en día son suficientes para hacer el trabajo. Deberías buscar las herramientas existentes para optimizar y acelerar las cosas. Y evita caer en la trampa de depender demasiado de las herramientas, porque, en cierto modo, muchas veces es una especie de procrastinación donde solo buscamos la herramienta adecuada para optimizar los costos u otra migración de una carga de trabajo específica cuando, de hecho, a la mitad de la evaluación de esa herramienta, ya podrías haber terminado de migrar esa carga de trabajo o podrías haber optimizado los costos con herramientas gratuitas como Cost Explorer, lo que es increíble.

¿Hay herramientas que tengan más características que Cost Explorer? Por supuesto. ¿Podrían ser mejores? Por supuesto. Pero, ¿puede Cost Explorer cubrir el 99 % de las cosas que quiere hacer? Sí, normalmente lo hará. Y está justo delante de ti. Por eso, mi consejo es utilizar las herramientas que ofrece AWS, que de hecho son muy buenas, sobre todo hoy en día. Y luego, si hay brechas, evaluar siempre las nuevas herramientas y comprobar si hay algo mejor, pero no esperar que esas herramientas aceleren significativamente el progreso. Te ofrecerán mejoras graduales y deberías utilizarlas, pero creo que la mayor trampa es que los clientes confían demasiado en ellas y tienen expectativas demasiado altas en cuanto a lo que esas herramientas harán por ellos.

Jonathan Allen:
De acuerdo. Sin embargo, algo que vi en el último año que realmente aceleró el traspaso de los clientes, es el reconocimiento de que pasar demasiado tiempo desplegando nuevas herramientas para obtener información podría ser una de esas falacias, en las que, de hecho, gran parte de la información que ya tienen está en archivos .CSV, en CMDB, en algunas de esas cosas. De hecho, si pueden reunir todo eso, ponerlo en un data mart y consultarlo, dispondrán de mucha información para ponerse en marcha antes de lo que se imaginan.

Jake, quiero continuar e investigar un poco más desde el punto de vista técnico. Los dos tenemos diversas perspectivas sobre la migración y la modernización, eso me encanta. Me encanta la diversidad de opiniones. Ambos debatimos largo y tendido sobre las diferentes variantes, pero quiero profundizar un poco más en tu versión. Así que vamos a profundizar un poco más en el aspecto técnico. Te escuché mencionar una metodología de migración única que puede ayudar a simplificar el proceso. Háblanos sobre eso.

Jake Burns:
En resumen, dos partes. Una es lo que yo llamo una refactorización mínima viable, que es una alternativa al modelo de las 7 R.

Básicamente, lo que promuevo es no planificar con antelación la forma de refactorizar estas aplicaciones y adoptar un enfoque iterativo. En pocas palabras, lo que tienes que hacer es ordenar todas las aplicaciones según la sencillez de la migración. Las más sencillas irán al principio y deberás evaluar la importancia que suponen para la empresa. Las menos importantes también irán primeras en la lista.

Es mejor comenzar con las aplicaciones más sencillas de migrar y menos importantes, porque recuerda que estás utilizando a tus propios empleados a tiempo completo y probablemente no tengan los conocimientos necesarios. Lo conveniente es que el riesgo sea muy bajo y el proceso sea fácil. Es necesario generar y mantener el impulso durante toda la migración. Así que primero debes completar las tareas fáciles y alcanzar una serie de logros que te permitan ganarte la aprobación del público, por así decirlo, para obtener el impulso que necesita y generar confianza.

Por eso, comienza con la migración mediante lift-and-shift. En mi opinión, no se puede usar este método para migrar a la nube. Siempre tendrás que hacer algunos cambios, pero yo creo que no es necesario complicar demasiado el proceso, por lo que debes hacer la menor cantidad de modificaciones para no causar daños. Es una especie de juramento hipocrático sobre la TI. En las áreas comunes, no es conveniente causar daños, encarecer los costos, afectar la confiabilidad, reducir el rendimiento o la seguridad ni que se incumplan las normas.

Mientras no se complique nada de esto, podrás finalizar la refactorización y te limitarás a hacer lo mínimo posible para evitar obstaculizar el proceso. Luego continuarás con la migración a la nube lo antes posible. Ahora, seguro comenzarás inmediatamente a optimizar los recursos una vez que estén en la nube para mejorarlos, pero no conviene complicar demasiado el proceso.

Lo mejor de todo esto es que es muy sencillo. No vas a introducir cosas dentro de buckets arbitrarios con las 7 R. Solo determinarás el grado de refactorización necesario para trasladar la aplicación de forma segura. Podría hacerse de forma iterativa, por lo que hay muy poca planificación inicial, si es que se necesita. Puedes revisar todas sus aplicaciones y decidir, qué nivel de refactorización deseas realizar cuando lleves a cabo la migración. Luego, se llega al proceso de migración. Necesito encontrar un nombre mejor para esto, pero actualmente lo llamo migración de procesos múltiples sin bloqueo.

Básicamente, se interrumpe la migración. Como broma, siempre digo que esto es lo que ocurre cuando dejas que un ingeniero diseñe esta metodología. Empezamos a implementar lo que aprendemos. De hecho, se me ocurrió una idea en la capacitación para arquitectos de soluciones de AWS que realicé junto con mi equipo. Se trata de realizar un acoplamiento flexible de microservicios, áreas de infraestructura o código para reducir los obstáculos y hacer que los procesos sean asincrónicos en lugar de sincrónicos.

Dicho de otra manera, no queremos experimentar bloqueos esperando que algo suceda, porque sería una pérdida de tiempo. Tampoco queremos cambiar de contexto con más frecuencia de la necesaria, porque perderíamos el enfoque. Intentaré simplificar la explicación lo más posible para quien esté escuchando esto: la idea es dividir cada una de las etapas de la migración de cada aplicación a un microservicio separado durante el proceso, asignar a alguien a esa área de actividad y, luego, trasladar todas las aplicaciones a través de esa serie de elementos acoplados de manera flexible.

Esto también sirve para cuando surja algún obstáculo, porque seguro sucederá. Si estás esperando las aprobaciones, estás diseñando la aplicación, aún estás transfiriendo los datos o te encuentras en cualquier otra situación, ahí es cuando cambias de contexto y pasas a la siguiente aplicación. El objetivo es mantener a todos ocupados, hacer que todas las aplicaciones avancen durante el proceso de migración y completarlo de la manera más rápida y eficiente posible.

Jonathan Allen:
Sí. Me encanta eso. Según mi propia experiencia, recuerdo un trabajo con un cliente en el que una de las primeras cargas de trabajo que seleccionaron fue particularmente difícil. Pasaron seis semanas buscando la forma de trasladar millones de imágenes de escritura única y lectura múltiple y no sabían cómo hacerlo. Lo que hicieron fue invertir el proceso y comenzaron con las cargas de trabajo más sencillas y, cuando volvieron a las primeras, los ingenieros ya habían encontrado una solución para procesar esas cargas. Lograron ese impulso y, finalmente, pensaron: “Espera, ahora tenemos todos estos componentes básicos que podemos aprovechar”.

Jake Burns:
Por supuesto. Y otra cosa que no has mencionado es que has publicado una nueva edición de tu libro y, realmente, este es el mejor que he visto sobre este tema. Así que, en mi opinión, todo el mundo debería... No lo digo solo porque estás aquí, también lo digo cuando no estás. Se lo di a muchos directores de TI en persona cuando me reuní con ellos. En verdad, es muy sorprendente. ¿Podrías contarnos un poco sobre él y las novedades de esta nueva edición que acaba de publicarse?

Jonathan Allen:
Sí. Gracias, Jake. Sí, la segunda edición de Reaching Cloud Velocity ya está disponible. Básicamente, actualicé alrededor de siete u ocho capítulos, especialmente los que tratan sobre el modelo operativo, en particular la migración y la modernización, y algunos de los temas más desafiantes de los que a veces a nosotros nos cuesta hablar y también a los clientes, por eso quería aportar algo de claridad al respecto. Así que sí, léelo. Gracias, Jake.

Jake Burns:
Genial. Gracias, Jonathan.

Jonathan Allen:
Esa es una buena conversación. Gracias, Jake. Y a nuestros oyentes, muchas gracias por acompañarnos en Conversaciones con líderes. En 2025 contaremos con un destacado elenco de líderes mundiales de la tecnología que seguirán abordando temas fundamentales y compartiendo perspectivas únicas en la intersección de las empresas y la tecnología. Asegúrense de suscribirse para no perderse ningún episodio. Hasta la próxima, cuídense.

Escuche el pódcast ahora

Escuche el pódcast ahora

Escuche el pódcast ahora