Migrar a AWS: Guía del administrador

Capítulo 4. Construir tu caso empresarial

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Migra, luego itera.

Nate Gandert, Director de Tecnología/Director de Producto Getty Images

Ahora que has completado tu descubrimiento y realizado todos los ajustes manuales, es el momento de construir tu caso empresarial. Quizá te preguntes por qué necesitas un caso empresarial. Muy pocas empresas reciben un mandato del consejo de administración que les diga que se pasen a la nube. Ocurre, pero normalmente hay algún objetivo empresarial importante que deben abordar en esos casos. Para el resto de nosotros, tenemos que demostrar por qué debemos pasarnos a la nube. Por desgracia, la historia suele centrarse en los costes, aunque la agilidad sea el verdadero valor empresarial.

Cuando se trata de migrar, los costes son elevados. Debes operar en dos entornos durante algún tiempo, lo que supone la mayor parte de tus gastos. También tendrás gastos de formación, consultoría y, potencialmente, de software. La migración también causa un trastorno importante a tus unidades de negocio y a sus plazos. Para ser franco, seguir adelante con la migración sin contar con la aprobación de la alta dirección es una forma segura de que te echen por la puerta. El caso empresarial transmite la información que has recopilado sobre tu entorno y la transmite a la dirección en un formato digerible.

La mayor parte de este capítulo tratará de los costes duros de , porque son los más fáciles de conseguir la alineación empresarial y la aprobación para migrar. También hay que destacar algunas áreas en las que los costes pueden aumentar si los comparas con los locales. En estas situaciones, es esencial destacar los beneficios adicionales que tu empresa obtendrá de ellos. En realidad, la historia debería centrarse más en la agilidad y en las capacidades que tu empresa obtendrá al pasarse a AWS. La agilidad no siempre es cuantificable. Eso hace que sea difícil utilizarla en tu argumento empresarial, ya que no puedes vincular directamente el ahorro o el aumento de ingresos a esa agilidad. Sin embargo, no todo está perdido; hay algunos beneficios de la agilidad que puedes cuantificar, y los trataremos en este capítulo.

Un beneficio oculto del proceso del caso empresarial es que la alta dirección puede hacer algunas preguntas y exigir una investigación en las que no habías pensado antes. Este proceso garantiza que se cubren todas las bases y asegura un mayor nivel de éxito a largo plazo.

Calcular tu calendario

Para elaborar un caso empresarial adecuado, necesitas saber cuánto durará tu migración. La duración de tu migración tiene un efecto significativo en el coste de la misma. Afectará a tu doble gasto, a las herramientas y a los posibles honorarios de consultoría. Aún no hemos hablado de la planificación de la migración; lo haremos más adelante, en el Capítulo 7. Por ahora, estimaremos la duración basándonos en tres factores:

1. El número de servidores que tienes que migrar

2. El número de servidores que estimas que se pueden mover al día

3. Un amortiguador para retrasos imprevistos en los plazos para crear el plazo estimado.

Número de servidores

La mayor parte del esfuerzo en la migración proviene del número de servidores que tienes en las instalaciones. Se reduce a la logística de tocar esos servidores y trasladarlos. Tendrás que instalar agentes en la caja para migrarla a AWS, desactivar los adaptadores de red tras la migración en el servidor de origen, realizar una prueba de humo y llevar a cabo otras operaciones durante la migración. Incluso con automatización, seguirá siendo el mayor cubo de tiempo.

Número de servidores movidos al día

Calcular el número de servidores que se pueden migrar al día puede ser complicado. Depende del nivel de experiencia en AWS del personal que realiza la migración. También depende de los tipos de aplicaciones y de si el personal ha realizado migraciones en el pasado. Cuando era consultor y calculaba el nivel de esfuerzo de los proyectos, utilizaba dos servidores al día por ingeniero. Se trataba de ingenieros de AWS experimentados con múltiples migraciones en su haber. Sería seguro utilizar este número si utilizas consultores o contratistas. Si utilizas a tu personal, deberías utilizar entre medio y un servidor al día.

Puede que te preguntes cómo harán tus ingenieros para iniciar la migración y tener un servidor migrado cada día. Es una muy buena pregunta; estas cifras son promedios. Cuando migras servidores, lo haces en oleadas y normalmente tienes un corte por la noche o el fin de semana. Podrías migrar 10 servidores con 2 ingenieros el sábado, pero te llevaría toda la semana hacer el trabajo previo.

Tampón de retardo

Los retrasos ocurren. Creo que nunca he tenido un proyecto que no se haya retrasado. A los ojos de mi dirección, no pierdo ningún objetivo porque me empeño en incluir un margen. Al principio de mi carrera, solía mantener mis plazos ajustados porque pensaba que quedaría bien que propusiera un proyecto con un plazo corto y óptimo. La primera vez que tuve que ampliar un proyecto no fue para tanto. Pero la tercera, cuarta y quinta vez, empecé a acobardarme cada vez que tenía que decir a la dirección que tenía que ampliar el plazo. Este descuido fue una lección dolorosa de aprender.

Desde entonces, normalmente me gusta pecar de precavido, o como yo lo llamo, hacer como Scotty. Si recuerdas todos los episodios de Star Trek, siempre le pedían a Scotty que hiciera algo increíble. El plazo que le daban era siempre demasiado corto para llevar a cabo la tarea, y le daban uno más largo. Sin embargo, de algún modo Scotty lo conseguía y superaba el plazo estimado. Por sus esfuerzos, siempre veían a Scotty como el héroe. Me gusta ser Scotty cuando hago previsiones. Prefiero hacer una estimación un poco más alta y que me alaben cuando se asiente el polvo, que tirar por lo bajo y fallar. Es mejor tener un poco más de potencia de cohete para alcanzar la velocidad de salida y no necesitarla que quedarse corto.

Para las migraciones, yo añadiría normalmente un margen de error del 10-20% como amortiguador del plazo de migración. Si trabajo con un equipo de migración experimentado, me inclinaría por el 10%. Del mismo modo, me inclinaría por el 20% con un equipo menos experimentado. Además de las capacidades del equipo, el tipo de software del que dispongas también influye en el plazo de migración. Por ejemplo, si tienes muchas aplicaciones COTS, tu plazo tiene menos riesgo que si tienes mucho software desarrollado internamente. La razón de este cambio en el riesgo es que las aplicaciones COTS están muy documentadas y han sido trasladadas a AWS por otras empresas. Hay publicaciones en blogs y respuestas en foros disponibles para ayudar a tu equipo a resolver cualquier problema. Cuando tienes muchas aplicaciones desarrolladas internamente, lo más probable es que ocurra lo contrario. Normalmente, la documentación no es tan sólida, y con el tiempo se ha perdido un alto grado de conocimiento tribal. Como eres la única empresa que ejecuta el software, tampoco habrá recursos en la red a los que hacer referencia. Debido a estos factores, yo empujo el búfer hacia el 20% para las empresas con grandes patrimonios de software desarrollado internamente.

Antes de pasar a ver cómo incorporar el búfer de retraso, primero tenemos que tocar el tema de las vacaciones y festivos de los empleados. Son un componente importante del calendario de una migración.

Vacaciones y días festivos de los empleados

Un componente de la planificación temporal que a menudo se pasa por alto son las vacaciones y días festivos de los empleados. Las vacaciones de los empleados pueden tener un efecto significativo en tu cronograma, y he visto que se olvidan en bastantes presupuestos. Del mismo modo, las vacaciones también pueden afectar al calendario, pero potencialmente no como cabría esperar.

No quiero que caigas en la trampa de no pensar en las vacaciones de los empleados. Hacer esto retrasará tu migración. El efecto empeora cuanto mayor es tu empresa, y cuanto mayor es tu equipo, más vacaciones tienes que tener en cuenta. Cuanto mayor sea la empresa, más servidores y más largo el plazo, también. Cuanto más largo sea el plazo, más vacaciones tomará el personal. Las vacaciones tendrán menos efecto en las empresas pequeñas que no tienen muchos servidores, porque el plazo será mucho más corto. Veamos el siguiente escenario para poner de relieve cómo pueden afectar las vacaciones a tu calendario.

Escenario 4-1

Beth está preparando su calendario de migración y quiere compensar las vacaciones de su personal. Tiene un equipo de migración de seis personas. Su infraestructura es grande, y prevén que tardarán un año en migrarlo todo. La empresa de Beth también tiene una política de vacaciones decente y permite al personal cuatro semanas de vacaciones al año.

El impacto en el calendario de migración para la situación de Beth es considerable. Como tiene seis empleados en la migración y cada uno tiene un mes de vacaciones, tiene seis meses de vacaciones potenciales. Es decir, medio año de esfuerzo de una persona a tiempo completo. Como en un mes hay aproximadamente 20 días laborables multiplicados por seis meses, son 120 días de esfuerzo si su equipo puede migrar 1,25 servidores al día, lo que equivale a 150 servidores de esfuerzo perdido si Beth no lo compensa.

Las vacaciones también pueden causar estragos en tu calendario de migración. La mayoría de la gente piensa inmediatamente en los días libres y en que la gente no está para trabajar. Para ser sinceros, ese aspecto tiene poco efecto en tu calendario. Lo que realmente puede perjudicar son las posibles fechas de suspensión que acompañan a los días festivos. Esto es especialmente cierto en el sector minorista. Es habitual que una cadena de tiendas tenga fechas de cierre desde Acción de Gracias hasta después de Año Nuevo. Eso supone alrededor de un mes y medio de incapacidad para migrar. Una empresa para la que trabajé tenía fechas de bloqueo en torno a cada festividad. El Día de San Valentín, el Día de San Patricio, el 4 de julio y otros más, todos ellos con apagones de una semana. El impacto de los días festivos dependerá específicamente de las necesidades individuales de tu empresa.

Me gusta compensar las vacaciones y los días festivos disminuyendo el número total de ingenieros que se pone en la ecuación. En el "Escenario 4-1", Beth reduciría su plantilla de seis a cinco ingenieros y medio. Esto resolverá la discrepancia por el esfuerzo que falta durante sus vacaciones. Ahora que tenemos todos los componentes, podemos pasar a introducirlos en la ecuación del calendario.

Reunir la ecuación

Ahora que ya tienes en mente el número de servidores, el número de servidores por día, el tiempo libre de los empleados y el buffer, podemos juntarlo todo para obtener la duración total de la migración. Para ello, he creado una ecuación que calculará tu periodo total de migración. Toma una serie de datos de entrada, que son los elementos que acabamos de discutir.

Ecuación 4-1. Ecuación temporal

$${\displaystyle \mathrm{línea\; de\; tiempo}=\left(\frac{\mathrm{servidores}}{\mathrm{ingenieros}\times \mathrm{servidores\; al\; día}}\mathrm{búfer}\right)/\mathrm{días\; de\; trabajo}}$$

Veamos otro escenario para ver cómo podría ser una línea de tiempo con algunos puntos de datos reales.

Escenario 4-2

Richard está migrando su parque de servidores a AWS; su empresa tiene 1.400 servidores que se migrarán, y 103 se dejarán en las instalaciones. El personal de Richard es nuevo en AWS, pero tiene dos miembros de su equipo de cuatro personas que han realizado migraciones a AWS anteriormente. La empresa ejecuta sobre todo software COTS, y sólo el 10% son aplicaciones desarrolladas internamente.

Richard acabará con una ecuación parecida a

$${\displaystyle \mathit{línea\; de\; tiempo}=\left(\frac{\mathrm{1,400}}{4\times 1.25}1.13\right)/5}$$

Tiene 1.400 servidores que serán migrados por cuatro ingenieros, que pueden mover un servidor y cuarto al día. Como la mitad de su personal está formado en AWS, se supone que un ingeniero puede mover algo más de un servidor al día. Por último, como la empresa de Richard tiene casi todo COTS y la mitad de su personal ha migrado antes, tiene sentido un colchón del 13%. El personal de Richard trabaja una semana laboral estándar, así que todo se divide por cinco para determinar cuántas semanas de esfuerzo total son necesarias. El calendario completo de migración de Richard es de 63,28 semanas, es decir, unos 14,5 meses. Teniendo en cuenta el número de servidores que tiene Richard, estas cifras parecen correctas según las normas del sector.

Ahora que la cronología está terminada, podemos empezar a trabajar en el caso empresarial. Quizá te preguntes por qué el calendario de migración se completó antes que el caso empresarial y no se incluyó como parte de él. El hecho es que es intrascendente en comparación con el resto de la información que se transmitirá a la dirección. Puedes simplemente anotarlo y cómo has llegado a él en las hipótesis, de las que hablaremos más adelante en este capítulo.

¿Qué aspecto tiene un caso empresarial?

Normalmente, he seguido el formato de iniciar un caso empresarial con una narración escrita sobre la migración y los beneficios que la migración a la nube aportará a la empresa. Después de la narración, sigo con una previsión financiera a cinco años que describe el ahorro que supondrá pasar a la nube. Por último, incluyo todos los detalles y resultados del descubrimiento en un apéndice para que la gente lo revise si quiere. Normalmente, la alta dirección no se preocupa de los detalles. Sin embargo, de vez en cuando, los miembros querrán validar los detalles de un área de la que son responsables. En los próximos apartados, entraremos en detalle en cada uno de los componentes de un caso empresarial.

La narración

La narrativa es la pieza más crítica del caso empresarial. Es tu oportunidad de comunicar los beneficios empresariales que tendrá la migración a AWS. Me gustan las narrativas porque te permiten elaborar una historia en torno al éxito futuro de tu empresa. La gente se involucra más con una historia que con un PowerPoint con un montón de viñetas. Leer una narración despierta la imaginación de la gente y contiene suficientes detalles como para que puedan imaginar el futuro. Otras formas de comunicación dejan más preguntas que respuestas. Hay un límite de información que puedes meter en una diapositiva antes de que resulte incomprensible.

Introducción

Pero, ¿por dónde empezar? Un punto de partida excelente y lógico es una introducción que incluya el estado actual de tu infraestructura. A mí me gusta centrarme en algunos aspectos positivos y negativos, sin ningún tipo de crítica a la infraestructura local. Lo mejor sería que parecieras imparcial, o al menos equilibrado. Si te pones a criticar el estado actual, corres el riesgo de alienar a los líderes a los que intentas hacer partícipes de tu plan. Tu empresa lleva un tiempo en el mercado, y las instalaciones han estado haciendo el trabajo. Estás intentando convencer a los mismos dirigentes que tú o tu predecesor hicisteis antes. Estos mismos dirigentes aprobaron la compra del equipo y las herramientas que actualmente funcionan en el centro de datos. Puede incluso que tu predecesor sea ahora el CIO, y no querrás llamar feo a su bebé. Si lo haces, no conseguirás que te aprueben, pero te ganarás un importante detractor que podría tener la influencia necesaria para paralizar todo el asunto. Si te ciñes a los hechos y mantienes los prejuicios al mínimo, conseguirás más apoyo.

PREGUNTAS FRECUENTES

Ya has escrito tu introducción sobre el estado actual. Ahora es el momento de empezar a profundizar en los beneficios que se conseguirán con la migración a la nube. El mejor lugar para empezar sería revisar las preguntas frecuentes que creaste en el Capítulo 1. Ya has dedicado mucho tiempo a desarrollar las preguntas que crees que te harán las unidades de negocio, los equipos de desarrollo y la dirección. Llegados a este punto, necesitas construir una historia convincente en torno a esas preguntas concretas. Echemos un vistazo a este ejemplo de FAQ y veamos cómo puedes elaborar una historia convincente.

FAQ Pregunta 1

Pregunta

¿Cómo va a afectar esta migración a nuestro personal y a los gastos operativos?

Historia narrativa

A lo largo de los últimos cinco años, hemos observado un aumento de los gastos operativos para mantener nuestra infraestructura. Este aumento se debe principalmente a nuestra migración de servidores bare metal a la virtualización. La facilidad de implementación y el nivel de consolidación de nuestra infraestructura nos han permitido aumentar rápidamente el número de máquinas virtuales (VM). Esta expansión no es negativa porque hemos podido dar soporte al negocio de formas nuevas que antes no eran posibles. Por desgracia, un efecto secundario de la expansión de las máquinas virtuales es que nuestros costes operativos han aumentado linealmente. Al migrar a AWS y utilizar el Servicio de Administración de Sistemas (SSM) y las herramientas CI/CD, podremos reducir nuestros gastos operativos. No sólo evitaremos el aumento lineal de los gastos, sino que veremos un descenso exponencial de los gastos de la infraestructura que hemos implementado.

SSM nos permitirá automatizar la corrección de parches, así como aplicar detalles de configuración a los servidores sin intervención manual. Esta automatización nos permitirá aplicar cambios de seguridad para cumplir las directrices normativas con el mínimo esfuerzo. Actualmente, utilizamos la política de grupo para la seguridad en Windows, pero no tenemos una solución para Linux. El uso de SSM nos proporcionará un único punto de gestión para ambos sistemas operativos.

Al realizar el descubrimiento de nuestra infraestructura, identificamos que nuestra aplicación más importante es una candidata ideal para la implementación automatizada mediante una canalización CI/CD. La automatización de la implementación nos ahorrará 45 horas de personal por lanzamiento y nos permitirá realizar lanzamientos más a menudo. Utilizando la canalización, podemos aumentar nuestras implementaciones de una vez al trimestre a todas las semanas con facilidad.

Como puedes ver en la "Pregunta 1 de las FAQ", no adoptamos una postura dura y negativa contra la infraestructura local. Afirmamos que la migración a AWS tendría algunas ventajas. La narración también les lleva por un camino que esperamos que complete los detalles que necesitan para formarse una opinión y limitar las preguntas. Veamos cómo no debes escribir una narración.

FAQ Pregunta 2

Pregunta

¿Qué hay de malo en la forma en que gestionamos actualmente nuestras infraestructuras?

Historia narrativa

Durante el análisis de nuestros equipos locales, descubrimos que la mayor parte del hardware era arcaico y había superado con creces su vida útil. El envejecimiento del hardware ha dado lugar a una experiencia de usuario horrible. Mucha gente se queja de que el sistema de procesamiento de pedidos "simplemente apesta". Muchos de los sistemas operativos ya no cuentan con el soporte del proveedor y están funcionando con tiempo prestado. Estamos contando los días hasta que nos veamos comprometidos.

También descubrimos que tu sistema de alimentación ininterrumpida está al final de su vida útil, y las baterías tienen fugas. No se sabe si el sistema mantendría siquiera nuestros servidores en línea en caso de fallo eléctrico. Nuestro sistema de climatización está sobrealimentado para el centro de datos ahora que lo hemos virtualizado todo. Como es demasiado grande, hemos tenido que activar el recalentador para calentar el aire antes de enfriarlo, de modo que podamos eliminar correctamente la humedad. El recalentador está añadiendo un gasto considerable a nuestra factura eléctrica. Nuestra infraestructura ya ha pasado su mejor momento y funciona de prestado.

Como puedes ver, esta FAQ adopta una postura muy diferente en la forma de contar una historia. La narrativa se muestra muy sesgada hacia la nube. También pinta un panorama bastante sombrío de la situación actual en las instalaciones. El problema con el que te toparás, utilizando esta postura, es que es tu trabajo asegurarte de que se abordan todas estas discrepancias. Escribir una narrativa como ésta podría ser firmar tu propia sentencia de muerte.

Puedes seguir avanzando por las FAQ y elegir las preguntas en las que puedas construir una historia convincente y emocionante. Algunos temas, como la conversión a SSD utilizando volúmenes EBS gp2, pueden ser una historia fascinante para alguien técnico. Sin embargo, probablemente no resonará muy bien en los niveles superiores de la dirección. Utilizar las preguntas equivocadas puede aburrir a tu audiencia y frenar la emoción.

Cerrar

La última parte de la narración debe ser el cierre. Debe incluir una breve recapitulación de los puntos esenciales que has tratado. En mis cierres, me gusta imaginar el futuro y destacar las capacidades que aún no han sido utilizadas por la empresa, pero que podrían serlo tras la migración a AWS. En el cierre puedes poner en juego tu pensamiento creativo y crear una visión de alguna nueva capacidad o valor añadido para el cliente. Una vez que la migración se haya completado y tus datos estén en AWS, habrá toda una serie de capacidades que podrás aprovechar. La inteligencia artificial y la realidad aumentada son dos tecnologías prevalentes que la gente está pensando en formas nuevas y creativas de utilizar en una gran cantidad de verticales de la industria.

Advertencia

Tiendo a mantenerme alejado de las tecnologías "bala de plata" para mi futuro imaginado. Serían tecnologías que, por una razón u otra, obtienen una tracción masiva para resolver todos los problemas del planeta. La más reciente es blockchain. No hace mucho, no podías leer ningún sitio web de tecnología sin que se mencionara el blockchain para resolver un problema. ¿Un codo de tenista? No hay problema; frótate un poco de blockchain dos veces al día. No existe la bala de plata. Según mi experiencia, cualquier tecnología que se anuncia como un cambio significativo rara vez llega a serlo. O muere o se convierte en un actor de nicho. La cadena de bloques, la computación en red, los cortafuegos de nueva generación y otras tecnologías se han subido al tren de la solución de los problemas del mundo, y todas han descarrilado. Las tecnologías que cambian el mundo tardan mucho en hacerlo. Fíjate en la virtualización, la inteligencia artificial, la realidad virtual e incluso AWS. Estas tecnologías tardaron al menos una década o más en alcanzar un nivel de madurez que les permitiera cambiar el mundo, y algunas apenas están empezando a ganar tracción. Quieres que tu imagen del futuro sea realizable y no fantasiosa.

El pronóstico

Ya has escrito tu relato y pintado un cuadro maravilloso de todas las ventajas y problemas que se resolverán con el paso a la nube. Ahora es el momento de ir al grano. Tendrás que demostrar cuánto costará la migración a AWS. Nada es gratis, especialmente cuando se trata de la migración. El doble gasto durante la migración es un gran obstáculo. Sin embargo, el gasto no será exactamente el doble. Deberías ver una diferencia de costes entre las instalaciones y la nube. Además, a medida que migras, deberías ver una cierta reducción de los costes de tus equipos locales. En lo que respecta a la reducción de costes, existe cierta complejidad, que trataremos con más detalle más adelante, en "Reducción de costes".

Lo importante que hay que captar en la previsión es cuándo empezarás a ahorrar dinero migrando a AWS. Cualquier buen directivo o consejo de administración reconocerá que el ahorro no será instantáneo. Es seguro decir que una junta típica considerará un rendimiento de tres a cinco años en una inversión importante como la migración a AWS. Normalmente, he visto un retorno de la inversión en tan sólo 18 meses, dependiendo de la situación de la empresa. Sin embargo, diría que de dos a tres años es probablemente lo más habitual. Existe la posibilidad de que las empresas no ahorren dinero migrando a AWS. Veamos un escenario que detalla cómo podría ocurrir esto.

Escenario 4-3

La empresa de Stefan ha decidido trasladarse a AWS desde su actual centro de datos situado en la oficina corporativa principal. La empresa de Stefan ejecuta unos cuantos servidores SQL, unos cuantos servidores de archivos, el servidor de contabilidad y el sitio web corporativo. En las instalaciones, la empresa de Stefan ejecuta todo virtualizado en un único host VMware con almacenamiento local adjunto. El predecesor de Stefan sustituyó el servidor hace cuatro años. La empresa no tiene otros centros de datos. Centro de datos no es probablemente la palabra que Stefan usaría para describir su armario informático.

Afortunadamente, puedes ver algunos problemas importantes en la forma en que la empresa de Stefan ha implementado la infraestructura. El mayor problema es que no hay redundancia en nada de lo que está haciendo in situ. Es probable que la empresa no disponga de extinción de incendios, generadores ni seguridad física. Desde un punto de vista técnico, no hay redundancia para el servidor ni para su almacenamiento. El predecesor de Stefan redujo el entorno todo lo que pudo. Si comparas este tipo de implementación local con AWS, podría costar fácilmente el doble ejecutarla en AWS. AWS tiene todas estas capacidades incorporadas, y sería imposible alinear los costes. En este escenario, es de vital importancia centrarse en los beneficios de disponibilidad que AWS aporta sobre el entorno local, en lugar de en los costes.

La previsión debe incluir varios elementos a lo largo de un periodo de al menos cinco años. Una buena previsión incluirá:

• Tasa de ejecución estimada

• Costes de migración, como herramientas y honorarios de consultores

• Modificadores de la tasa de ejecución, como instancias reservadas

• Ahorro de agilidad

Algunas de estas partidas, como la tasa de ejecución, procederán de tu descubrimiento, y otras, como el ahorro en agilidad, tendrás que calcularlas a mano basándote en la situación de tu empresa. Querrás pintar un cuadro utilizando costes de muy alto nivel para que sea fácil de digerir y comprender. La previsión debe caber en una sola página y no debe tener más de 10 ó 15 filas de datos. Si añades más, corres el riesgo de confundir a tu audiencia. Proporcionar una hoja de cálculo tras otra de listas de servidores no ayudará a nadie a comprender el panorama general. Esa información puede guardarse para la sección de detalles al final. Además, algunos elementos, que yo llamo modificadores de la tasa de ejecución, ajustarán tus cifras globales a los costes aproximados, como las instancias reservadas.

La Figura 4-1 muestra un ejemplo de una previsión típica que yo crearía. Incluye todos los detalles esenciales, pero los hace lo más digeribles posible. También puedes ver que incluyo una lista de supuestos en la parte inferior que detalla dónde se hicieron esos supuestos. Puedes hacer del formato lo que quieras, pero la sencillez es la clave. No quieres sobrecargar al consumidor con detalles innecesarios.

Figura 4-1. Ejemplo de previsión

La última pieza que tenemos que cubrir es eliminar las aplicaciones que no vas a migrar a la nube o, mejor dicho, recortar la grasa. Al igual que el entrecot en un restaurante de carnes con clase, tienes que eliminar los elementos de los perímetros que hacen que la migración sea menos atractiva.

Recortar la grasa

Antes de poder realizar con precisión el modelado de la tasa de ejecución, tenemos que eliminar algo de grasa. La grasa de la que hablo son las aplicaciones que no vas a trasladar a AWS. Amazon ha creado una metodología denominada los siete factores R (Refactorizar, Redistribuir, Reubicar, Recomprar, Retirar, Replatear, Conservar). Originalmente eran seis, pero la Redistribución se convirtió en un nuevo factor R a medida que más empresas disponían de contenedores o canalizaciones de implementación en las instalaciones. Los factores existen para ayudarte a categorizar tus aplicaciones y determinar si debes migrarlas a la nube y cómo.

Tu herramienta de descubrimiento encontró todo lo que tienes en las instalaciones y puede proporcionarte las instancias del tamaño adecuado. Lo que la herramienta de descubrimiento no puede hacer es decirte si debes trasladar una aplicación. Esta clasificación será un proceso manual que habrá que completar antes de poder hacer un modelado preciso de la tasa de ejecución. Tú, por supuesto, no quieres tener en cuenta los costes en AWS que no se moverán o se retirarán. Eso inflaría tus cifras y haría tu caso empresarial menos atractivo e inexacto. Ahora vamos a tocar los siete factores R, lo que significan, el porcentaje estimado de tu migración para cada R y cómo debes aplicarlos.

Refactoriza

La refactorización es la forma más compleja de migrar a AWS y debería ser el porcentaje más bajo de tu migración global. Refactorizar significa convertir una aplicación existente monolítica y anticuada en una arquitectura nueva, altamente desacoplada y nativa de la nube. El problema de refactorizar aplicaciones es que a menudo se tarda un largo periodo en completar el trabajo. Este plazo prolongado significa que estás gastando más en tu migración global ejecutando la aplicación en dos lugares o ampliando la huella de tu centro de datos durante períodos más largos. Sin embargo, el mayor beneficio de la refactorización es que tus aplicaciones funcionarán con más fluidez, tendrán un mayor grado de disponibilidad, se reducirán los gastos generales de gestión y ahorrarás costes. En este punto, la refactorización supondrá probablemente un 5% o menos de tu migración. En el Capítulo 8, hablaremos de algunos frutos maduros que puedes recoger en la migración inicial.

Redistribuye

El uso principal de Redeploy es cuando ya tienes una canalización de implementación o contenedores en las instalaciones. Si ya tienes una canalización de implementación y vas a migrar, básicamente estás cambiando el punto final de esa implementación. La mayoría de las herramientas ya tienen plugins para AWS. En lugar de hacer ningún trabajo de migración, dirigirás la canalización a AWS en lugar de a VMware o Hyper-V en las instalaciones.

Lo mismo ocurre si utilizas contenedores. Como los contenedores son cargas de trabajo autónomas, puedes trasladar ese contenedor a AWS en lugar de al hardware local. Por supuesto, hay algo más de trabajo en torno a la migración de este tipo de cargas de trabajo, como cambios de DNS y demás, pero el esfuerzo global es menor que, por ejemplo, un lifting and shift o un rehost. Es difícil decir qué parte de tu migración será redistribuida, porque depende mucho de tus aplicaciones.

Rehost

El realojamiento de constituirá la mayor parte de tu migración, principalmente por motivos de velocidad. Cuando realojas, elevas y trasladas la carga de trabajo a la nube. Cuanto más rápido llegue a la nube, más rápido podrás empezar a desconectar recursos en las instalaciones. La velocidad aumenta utilizando la herramienta de replicación CloudEndure a nivel de bloque. Rehost es el método de migración menos sexy, pero a menudo el más eficaz. Obtienes una copia bloque a bloque de tu servidor en AWS. Tu migración consistirá probablemente en un 80% de cargas de trabajo rehost.

Recompra

A veces el software envejece en tu infraestructura informática. Estas aplicaciones suelen ser pequeñas y descuidadas, que cumplen una función importante pero no reciben mucha atención. Esta falta de atención hace que envejezcan y se vuelvan decrépitas, pero siguen funcionando, por lo que nunca se sustituyen. Cuando migras a AWS, es un buen momento para envejecer definitivamente estas aplicaciones y sustituirlas por algo más nuevo. Me he encontrado con bastantes programas antiguos de Visual Basic en esta categoría. Si es posible, yo consideraría sustituir cualquier aplicación por una herramienta SaaS, para que no tengas que preocuparte de mantenerla en el futuro. Según mi experiencia, la recompra representará probablemente en torno al 5% de tu migración.

Retira

A veces ya no necesitas software una vez que te mudas a AWS. Normalmente, este software se reduce a herramientas de gestión de infraestructuras que existían para mantener las cargas de trabajo en las instalaciones. Cosas como la agregación de registros, el monitoreo del Protocolo Simple de Gestión de Redes (SNMP) y otras herramientas de monitoreo dejan de ser necesarias una vez que te mudas a AWS y utilizas la funcionalidad nativa. Esta reducción te ahorra tanto costes duros como costes blandos de gestión. El factor R de retirada no se utiliza mucho y probablemente supondrá menos del 5% de tu migración.

Re-plataforma

Cuando re-platform algo, cambias un pequeño aspecto de la aplicación, sin hacer grandes cambios en la arquitectura. Este cambio sería como pasar de un servidor de base de datos a RDS. Otro cambio potencial sería actualizar un sistema operativo Windows antiguo a una versión más reciente y compatible. La clave que hay que recordar aquí es que no estás haciendo ningún cambio importante, como pasar de Microsoft SQL a MySQL. La replanificación suele ser más frecuente que muchos otros factores R en las migraciones en las que he participado. Hay bastantes sistemas operativos antiguos por ahí que podría sorprenderte ver que siguen funcionando. Además, si quieres utilizar RDS por tranquilidad y para ahorrarte algo de gestión, podrías ver fácilmente que el 20% de tu migración se clasifica como re-plataforma.

Conserva

El último factor R es retener. Cuando retienes una carga de trabajo, la dejas tal cual en las instalaciones. Aparecerán varios elementos en la columna retener, pero la mayoría serán aplicaciones que deben permanecer en las instalaciones para que tus oficinas sigan funcionando. Active Directory sería una buena opción para conservar en las instalaciones, porque quieres que los usuarios se autentiquen localmente. Otros sistemas podrían ser los de seguridad, los servidores del Protocolo de Configuración Dinámica de Host (DHCP), y otras instalaciones de gestión de red.

Los sistemas heredados podrían ser otro elemento de esta categoría. No migrarás tu mainframe a AWS porque no es compatible con el hardware. Sin embargo, como este tipo de cargas de trabajo no se detectaron a través de tus herramientas de descubrimiento, no afectarán a tu tasa de ejecución y probablemente ni siquiera figuren en la lista.

Probablemente conservarás menos del 5% de tu infraestructura.

Ahora que sabes cómo clasificar todas tus aplicaciones, es hora de revisar y aplicar tus factores R. Cuando hayas terminado, tendrás que capturar la tasa de ejecución para las decisiones de realojar, volver a poner en plataforma, volver a desplegar y refactorizar. Éstas son las tasas de ejecución que se introducirán en tu previsión. No las introducirás individualmente. En su lugar, deberás sumar esas cifras para obtener un total combinado.

Ahora que ya tienes una comprensión de alto nivel de lo que se incluye en una previsión, vamos a entrar en detalle en los elementos individuales. Trataremos qué es cada elemento, por qué es importante incluirlo, cómo calcularlo y qué supuestos hay que enumerar. Se necesitará Microsoft Excel, Google Sheets o un programa de hojas de cálculo similar para crear la previsión y realizar los cálculos necesarios. Hay disponible un archivo de muestra como contenido adicional para este libro. Puedes acceder al archivo en Previsión AWS.

Modelización del porcentaje de carreras

La tasa de ejecución resultante de tu proceso de descubrimiento es uno de los elementos más importantes que debes incluir en tu previsión. Lo que queremos utilizar aquí es la cifra modificada que generó tu herramienta de descubrimiento, que luego ajustaste basándote en los elementos de descubrimiento manual que tu equipo revisó y recortó utilizando los factores R. Cuando inicies este proceso, deberás poner la tasa de ejecución completa que hayas obtenido en las celdas de entrada para EC2 (C3), Almacenamiento (C4) y Almacenamiento S3 (C5). Más adelante, aplicarás fórmulas para ajustar los números en función de tus entradas, pero por ahora, empieza con la tasa de ejecución completa. A partir de ahora, tu previsión debería parecerse a la Figura 4-2.

Figura 4-2. Previsión paso 1

Desglosar los costes de almacenamiento y computación como se muestra en la Figura 4-2 facilitará el cálculo de los costes adicionales. En "Ancho de banda global saliente" y "Cargos por servicios auxiliares de AWS", como recordarás, recomiendo añadir un incremento al gasto de EC2 por estos conceptos. Desglosar los costes de computación y almacenamiento permite ver y ajustar más fácilmente esos porcentajes.

Una vez que hayas introducido tus tasas de ejecución en la previsión, puedes introducir tus porcentajes de subida en las celdas F3 y F4 para el ancho de banda y los servicios auxiliares, respectivamente. Estos porcentajes son personalizables, por lo que puedes ajustarlos manualmente si las cifras de salida no se ajustan a tus expectativas. A veces puede que necesites ajustar tus parámetros hacia arriba o hacia abajo unos pocos puntos porcentuales para llegar a un número que refleje tu uso estimado. Cuando hagas ajustes, recuerda ser como Scotty de Star Trek y añadir un búfer. Una vez introducidos estos datos, tu previsión debería parecerse a la Figura 4-3.

Figura 4-3. Previsión paso 2

Costes de migración

El coste de la migración no es sólo el doble de gastos entre las instalaciones y la nube. El coste está asociado al tiempo del personal, las herramientas, la consultoría y los costes de transferencia de datos. Cuando combinas todos estos gastos, obtienes una imagen precisa de cuánto costará la migración. No incluir alguno de ellos puede sesgar significativamente el coste de la migración a favor de la nube. Si no los incluyes, le das a cualquier oposición la capacidad de desacreditar tu caso empresarial y puede hacer descarrilar potencialmente tu iniciativa. Creo firmemente en pintar el cuadro más exacto que pueda. La mayoría de las veces, es completamente evidente cómo la nube beneficiará a la empresa y tiene un gran potencial para reducir costes.

Aunque mi objetivo es ofrecer una imagen precisa, no me centro en proporcionar detalles mundanos y monótonos. Tampoco pierdo demasiado tiempo intentando obtener cifras de "aterrizaje en la luna" cuando bastan las de "lanzamiento al espacio" para muchas de estas categorías. En las próximas secciones, nos sumergiremos en estas categorías de gastos adicionales y en cómo contabilizarlas. También trataremos los posibles escollos de su cálculo y cómo evitar perder el tiempo.

Costes de utillaje

AWS dispone de toda una serie de herramientas para ayudarte a migrar a la nube; algunas de ellas son gratuitas y otras son de pago. Aunque las herramientas de AWS son estupendas, no siempre tienen las características que tu empresa necesita para hacer el trabajo. Cuando te encuentres con esta circunstancia, tendrás que seleccionar una herramienta adicional que te costará más.

Repasemos las herramientas que ofrece AWS. Estas herramientas ayudan en la migración, y necesitas saber cómo contabilizar esas tarifas. La Tabla 4-1 muestra una lista de las herramientas actuales disponibles en AWS y sus casos de uso.

Tabla 4-1. Herramientas de migración de AWS

Herramienta	Propósito
CloudEndure	Herramienta de replicación de servidores a nivel de bloque
Bola de nieve	Dispositivo de almacenamiento físico para "transferencia por correo".
Servicio de Migración de Servidores (SMS)	Importación de máquinas virtuales locales
DataSync	Transferencia de archivos a AWS
Herramientas de línea de comandos	Transferir archivos a S3
Herramienta de conversión de esquemas	Convierte esquemas de BD de un motor a otro
Servicio de Migración de Bases de Datos (DMS)	Migra datos entre servidores de bases de datos

Como puedes ver, AWS tiene una cartera saludable para migrar tus sistemas y datos a la nube. Estas herramientas específicas cumplen muy bien su función, pero, por desgracia, todas tienen diferentes modelos de consumo y coste. Estos diferentes modelos de consumo pueden parecer desalentadores cuando intentas calcularlos por primera vez. No es tan difícil porque vamos a hacer estimaciones para muchos de ellos:

CloudEndure

la herramienta de AWS para migrar servidores es ahora gratuita después de que Amazon la comprara en 2019. Aunque el uso de la herramienta es gratuito, hay que pagar por las instancias necesarias para gestionar la replicación. CloudEndure despliega una instancia de replicación por cada 15 discos de origen que repliques. Para calcular el coste de utilizar CloudEndure, tienes que averiguar el número máximo de servidores que replicarás durante cualquiera de tus oleadas de migración. Deberás tomar el número de servidores semanales que calculaste tras leer "Estimación de tu cronología". En el "Escenario 4-1", la estimación semanal era de 5 servidores. Como 5 está muy por debajo de los 15 permitidos, Richard sólo necesitaría una instancia de replicación. En el momento de escribir esto, una instancia t3.medium en us-east-1 cuesta 0,0416$ por hora. Multiplicando este precio por 730 horas se obtiene un coste de 30,368 $ al mes. El coste total de CloudEndure para Richard por su migración de 14,5 meses es de 440,336 $.

Bola de nieve

AWS Snowball es un dispositivo físico que se envía a tu oficina. A continuación, cargas este dispositivo con datos y lo envías a AWS. AWS cargará todos los datos que contenga en S3. En todas las migraciones que he realizado, nunca he utilizado Snowball. Esto se debe a que los datos que necesitas mover tienen que ser relativamente estáticos. Se tardan días en cargar los datos, enviar el dispositivo y cargarlo más tarde. Al final, las empresas con las que trabajé decidieron enviarlo todo por la red en lugar de utilizar Snowball. Utilizar la red les permitió eludir la sincronización que sería necesaria después de que AWS cargara los datos. Si tienes datos que funcionarían bien con Snowball, como datos antiguos de copias de seguridad, Snowball cuesta 200 $ por un dispositivo de 50 TB o 250 $ por 80 TB de almacenamiento en el momento de escribir estas líneas. Con esa tarifa, tienes incluidos 10 días de tiempo in situ. Si necesitas el dispositivo más de 10 días, pagas 15 $ por día. Si vas a utilizar Snowball, te sugiero que prepares tus datos y tengas todo listo antes de solicitar el dispositivo a través de la consola de AWS.

Servicio de migración de servidores

Normalmente, no aconsejo utilizar SMS. Sólo funciona con máquinas virtuales y no es compatible con dispositivos físicos. Para la mayoría de las empresas, esto significa que tendrías que utilizar dos herramientas en lugar de una. Como CloudEndure es gratuita y sirve tanto para máquinas físicas como virtuales, te sugiero que utilices esa herramienta en su lugar. SMS funciona subiendo instantáneas de las máquinas virtuales a S3 y luego creando instantáneas de EBS. Por último, SMS crea una imagen de máquina de Amazon (AMI) para su consumo final e implementación en AWS. Una AMI es como una plantilla en la terminología de VMware. El servicio SMS en sí es gratuito. Sin embargo, debido a su diseño, hay que pagar un pequeño número de instantáneas EBS y cuotas de almacenamiento S3. En general, estas cuotas son modestas y debes considerarlas parte del aumento por cargos varios de AWS que comentamos en "Modelado de la tasa de ejecución".

DataSync

DataSync es un servicio más reciente de AWS que facilita el traslado de datos desde las instalaciones a S3 o EFS a nivel de archivo en lugar de a nivel de servidor. Este servicio te permite transferir datos desde un dispositivo SAN o de almacenamiento conectado a red (NAS) con recursos compartidos de archivos Windows o NFS a AWS. DataSync es una herramienta bienvenida. Antes de DataSync, la mayor parte de este tipo de trabajo de migración se realizaba con scripts y la CLI de AWS, que no era la solución más sólida. DataSync en sí tiene una tarifa de 0,04 $ por GB en la región us-east-1 en el momento de escribir estas líneas. Este servicio es fácil de prever, en función de la cantidad de datos que necesites transferir. Por ejemplo, si tuvieras un dispositivo NAS con 1 TB en un recurso compartido NFS, multiplicarías 1.024 GB por 0,04 $ para un total de 40,96 $. Los 40,96 $ no cubren el coste del propio almacenamiento, por lo que también habrá que tenerlo en cuenta. Si se trata de una pequeña cantidad de datos, las cifras de aumento que has puesto probablemente lo cubrirán, pero si tienes docenas o cientos de terabytes, probablemente querrás incluir esos costes como una partida separada.

Herramientas de línea de comandos

Si tienes un pequeño número de archivos que mover a S3, entonces utilizar las herramientas de línea de comandos de AWS sería la opción más cómoda. Ninguna de estas herramientas tiene coste, pero pagarás por los recursos que consuman. Dado que el uso de las herramientas de línea de comandos no es aconsejable para transferir grandes cantidades de datos, el aumento debería cubrir los costes de consumo de datos en la previsión.

Herramienta de conversión de esquemas

La Herramienta de Conversión de Esquemas te permite cambiar el motor de tu base de datos. Esta herramienta te permitirá cambiar de un motor de base de datos a otro, por ejemplo, de Oracle a MySQL. Sin embargo, la herramienta es sólo una pieza del puzzle. Para cambiar con éxito tu motor de base de datos, tendrás que actualizar tu software para abordar los cambios necesarios en los matices de SQL, triggers y procedimientos almacenados. Afortunadamente, el SCT es gratuito y no hay que tenerlo en cuenta en ninguna previsión.

Servicio de migración de bases de datos

DMS te permite transferir datos de las instalaciones a la nube utilizando la réplica asíncrona. Este servicio te permite transferir datos de un servidor independiente a AWS RDS. La ventaja de utilizar DMS es que reduce drásticamente la ventana de interrupción para la transición al mover bases de datos, porque el servicio mantiene el origen y el destino en sincronía. Si utilizaras un método de copia de seguridad y restauración para transferir tu base de datos a RDS, experimentarías una ventana de interrupción mucho mayor. El servicio DMS utiliza una instancia de AWS para realizar el trabajo pesado de tu base de datos. Se sitúa entre tu origen y tu destino. Esta instancia gestiona las comunicaciones y la sincronización de las bases de datos y es donde se origina el coste de DMS. Para DMS, yo recomendaría un tamaño de instancia de r4.large o superior. Se permiten algunas instancias más pequeñas, como T2/3, pero yo no las utilizaría para transferir cargas de trabajo de producción. En el momento de escribir esto, una instancia r4.large en us-east-1 cuesta 0,21 $ por hora. Hacer funcionar esta instancia durante un mes sale a 153,30 $. Cada instancia de replicación está limitada a 20 fuentes y destinos. Este límite significa que sólo puedes tener 10 pares de servidores en replicación por instancia. Si necesitas más, tendrás que contratar otra instancia de replicación DMS.

Nota

Si no vas a cambiar de motor de base de datos ni a pasar a RDS, yo utilizaría CloudEndure para transferir el servidor en lugar de la base de datos.

En la Figura 4-4, puedes ver que he incluido el utillaje en la celda C6 de la hoja de cálculo de previsiones. El total de utillaje debe insertarse aquí. La hoja de cálculo rellenará automáticamente el utillaje de la fila 14 basándose en los porcentajes de migración de la fila 10. Hablaremos de los "porcentajes de migración " y de su uso más adelante. Si tienes previsto utilizar alguna herramienta que no sea de AWS para tu migración, tendrás que obtener el precio del proveedor y añadirlo al coste de cualquier herramienta de AWS.

Figura 4-4. Previsión paso 3

Honorarios de consultoría

En el Capítulo 2, hablamos de "Contratistas y consultoría" y de cómo pueden reducir los riesgos de tu empresa gracias a su experiencia. Muchas veces, los consultores y contratistas se consideran gastos durante una migración. Sin embargo, es importante demostrar que su experiencia y capacidades probablemente reducirán tus plazos. También reducirán el riesgo general durante la migración. Recurrir a consultores no es algo que deba evitarse, sino más bien una decisión táctica para ayudar a la empresa y reducir la duración de la migración. En general, el importe en dólares de los consultores no será pequeño. Las personas suelen ser el mayor gasto de la empresa. A menos que dispongas de un presupuesto que pueda cubrir los gastos de consultoría, es importante incluirlos en la previsión de migración.

Los honorarios de consultoría deberían ser bastante fáciles de obtener. Al recurrir a consultores, estás descargando en un tercero la gestión de tu migración, junto con el esfuerzo de trasladar tus recursos. Esta abstracción permite a la empresa consultora presupuestar la totalidad del proyecto por ti. La empresa consultora te proporcionará una declaración de trabajo (SOW) basada en los elementos que deseas que complete. El SOW te dará el importe total junto con una serie de criterios de éxito y el trabajo que se espera que se realice. Esta información puede registrarse en la previsión de la fila 8. Desgraciadamente, no hay una forma estándar de repartir los honorarios de consultoría a lo largo de toda la migración, así que tendrás que repartir estos honorarios a lo largo de los años de migración como mejor te parezca. No hay modificadores en la hoja para ayudarte.

En cuanto a los honorarios de los contratistas, no son tan fáciles de obtener, porque tienes que calcularlos manualmente. Como mantienes la gestión con los contratistas, tienes que determinar el nivel de esfuerzo para tu migración. Ahora mismo, en Chicago, sé que los contratistas pueden obtener normalmente entre 100 y 150 dólares por hora. Muchos contratistas trabajan también a través de una empresa de colocación, por lo que tendrás que añadir un 35% a esos honorarios si utilizas una empresa de colocación. Si no subcontratas a tu contratista, tendrás que pagar entre 135 y 195 dólares la hora, con los gastos generales añadidos. Los contratistas de alto nivel que trabajan con grandes empresas pueden llegar a cobrar hasta 300 $ la hora. La experiencia desempeña un papel importante en el precio de los contratistas. Yo me aseguraría de obtener los números de validación de las certificaciones que afirmen tener y de comprobar que realmente las poseen en el sitio de certificación de AWS. Cuantas más certificaciones tenga un contratista, más cobrará. Querrás asegurarte de que tu dinero merece la pena.

Otra opción para contratistas que se lanzará próximamente es AWS IQ, un servicio que permite a las personas certificadas por AWS registrarse y ofrecer sus servicios a las empresas que utilicen la plataforma. El servicio valida automáticamente sus certificaciones cuando registran su cuenta, ahorrándote ese paso. El servicio también facilita el pago a través del sistema de mercado de AWS existente. El sistema permite que los honorarios de tus contratistas aparezcan como parte de tu factura de AWS, reduciendo la carga de tu departamento financiero. AWS IQ cobra una cuota mínima del 3% además de la cuota de los contratistas por el uso del servicio.

Si recurres a una empresa de búsqueda, a AWS IQ o directamente a un contratista, tendrás que calcular el número de horas que necesitarás esos servicios. Por desgracia, la cantidad de tiempo que necesitarás los servicios de un contratista depende de las necesidades de tu empresa, del calendario de migración y de las capacidades actuales del personal. Tendrás que evaluar todos estos elementos para determinar cuánto tiempo y cuántos contratistas necesitarás. Una vez que llegues a esa duración, podrás calcular cuánto te costará emplearlos durante ese periodo. Veamos el siguiente escenario para ver cómo podría ser el cálculo de un contratista.

Escenario 4-4

En la empresa de Becca, su equipo se está preparando para migrar a AWS. Ha calculado que su migración durará unos 15 meses, basándose en su plantilla actual. Necesita reducir el plazo de migración a nueve meses y ha decidido recurrir a contratistas. Ha buscado en su zona, Charlotte, Carolina del Norte, y ha descubierto que los contratistas de AWS cuestan entre 145 y 188 dólares por hora. Cuando Becca calculó su plazo utilizando su personal interno, descubrió que su personal podía migrar aproximadamente 1,5 servidores al día cada uno, y la empresa tiene 1.365 servidores en total. Becca tiene tres empleados internos, por lo que su cálculo es 1.365 servidores / 1,5 servidores al día / 3 ingenieros / 20 días laborables al mes = 15,16 meses. Becca tiene que calcular cuántos contratistas necesita para cumplir su plazo revisado de 9 meses.

Trabajando hacia atrás, el equipo de Becca puede migrar aproximadamente 90 servidores al mes. Actualmente, su plazo es seis meses demasiado largo. Si multiplicamos 90 por 5, acabamos con 450 servidores que no se habrían migrado en el noveno mes. Si volvemos a dividir el exceso en nueve meses, su objetivo previsto, acabamos con 50. Becca necesitará suficiente personal contratado para cubrir 50 servidores más al mes para cumplir su plazo revisado. Si Becca se dirigiera a contratistas con experiencia en AWS y que hubieran realizado migraciones anteriormente, podría obtener de ellos una tasa de migración de dos servidores al día. Con 20 días laborables al mes, un contratista con mucha experiencia podría mover 40 servidores. Becca necesita dos para cubrir su exceso y disminuirá su riesgo global de migración, porque un segundo contratista eleva la capacidad mensual a 80 servidores adicionales al mes. Son 30 servidores más de los que necesita, lo que reduce aún más el riesgo.

Según las necesidades de Becca, tendrá que contabilizar 2.880 horas de gastos de contratista. Yo sugeriría hacer una estimación con una tarifa más alta, de 188 $ por hora, para garantizar una mayor flexibilidad. Becca introduciría 541.440 $ en la celda C15 para el año uno, como se muestra en la Figura 4-5. Sabemos que es el primer año porque su plazo óptimo de migración es de nueve meses.

Figura 4-5. Previsión de Becca

Tras calcular los honorarios de consultoría y contratistas, tendrás una idea exacta de cuánto te costará realizar la migración. La hoja de previsión también te mostrará a cuánto ascenderán tus costes corrientes tras la migración, que podrás comparar con los costes operativos de tu infraestructura actual. Dudo a la hora de decir el rendimiento de la inversión en comparación con la infraestructura local, porque a menudo es comparar manzanas con naranjas. Pero yo diría que, para la mayoría de las empresas, verás una reducción de costes cuando compares la tasa de ejecución de AWS con los costes on-premise. Tras introducir tus honorarios de consultoría y contratistas, tu previsión debería parecerse a la Figura 4-6.

Figura 4-6. Previsión paso 4

Modificadores del porcentaje de carreras

Ahora que sabes cuánto costará todo, es el momento de aplicar modificadores de la tasa de ejecución para que puedas ajustar el gasto en función de variables que dependen en gran medida de las circunstancias de una empresa. Una multitud de opciones pueden afectar a tu tasa de ejecución; ésa es una de las cosas bellas de AWS. Sin embargo, me centraré en las palancas más grandes y más comúnmente aplicables disponibles. Estas palancas son las instancias reservadas, los planes de ahorro, los porcentajes de migración, el ahorro en agilidad y el ahorro en gestión.

Instancias reservadas

Las instancias reservadas (IR) son probablemente la forma más fácil de ahorrar una cantidad significativa de dinero funcionando en AWS. Una instancia reservada es cuando aceptas utilizar una instancia de un tipo y sistema operativo específicos durante un periodo de uno o tres años. Al acordar el uso de la instancia durante un periodo más largo, se te ofrece un descuento en la tarifa total de ejecución de esa instancia. El descuento que recibes se basa en la duración de tu RI y en la cantidad que pagues por adelantado. Hay opciones para pagar por adelantado todo el coste de la instancia, lo que se denomina RI todo por adelantado, hasta sin pago por adelantado. Por supuesto, el mayor descuento se ofrece en la compra de RI de tres años todo por adelantado. Las compras de RI pueden ahorrarte una media del 40% durante un año y del 60% durante tres años. Sin embargo, no soy partidario de las RI a tres años por estas cuatro razones:

Contrario a la agilidad

El beneficio número uno de AWS es la agilidad empresarial, así que ¿por qué ibas a encerrarte en una instancia de tres años? En tres años, podría salir un nuevo servicio sin servidor o bajo demanda que podría ahorrarte miles de euros.

Mejoran las instancias

AWS lanza continuamente nuevos tipos de instancias; algunas de ellas son significativamente más rápidas que sus predecesoras. Te has encerrado en un Ford cuando podrías tener un Tesla.

Desembolso en efectivo

Tienes que pagar tus servidores por adelantado para obtener el mayor beneficio, por lo que tienes un gran desembolso de efectivo como en las operaciones in situ (aunque utilizas la amortización en lugar de la depreciación).

Disminución de los precios

AWS baja el precio de las instancias de vez en cuando. Con una reserva de tres años, ya la has comprado y no puedes aprovecharte de la bajada.

Puedes revender instancias reservadas en un mercado y comprar instancias reservadas convertibles. Estas dos capacidades te permiten cambiar tu RI, como con las instancias reservadas convertibles, o venderlas, utilizando el mercado, pero tienes que preguntarte si realmente quieres que tu personal pierda el tiempo con estos niveles de gestión mundana. ¿O quieres que añadan valor empresarial?

Hay muchas razones y metodologías para comprar instancias reservadas, y podría escribir fácilmente medio libro sobre el tema. En su lugar, me centraré en una forma sencilla de ajustar tu previsión para compensar la compra de RI. Incluir información sobre las instancias en la previsión reduciría su vida útil y aumentaría su complejidad. En última instancia, no necesitamos ese nivel de precisión. En su lugar, trabajaremos con descuentos genéricos basados en el tipo de RI y su duración.

Para ajustar la huella de RI en la previsión, cambia el porcentaje en la celda H3. El porcentaje representa la cantidad del patrimonio que no se reserva. Normalmente, recomiendo dejar un 10-20% como bajo demanda. Este búfer bajo demanda garantiza que tus RI se utilicen siempre. Como la RI se basa en el SO y en el tamaño de la instancia, si no estás ejecutando una instancia con esa configuración, la RI quedará sin utilizar. Por tanto, dejar un porcentaje como bajo demanda garantiza que se utilicen todas tus RI. El porcentaje bajo demanda también te permite cambiar tu entorno. Por ejemplo, después de migrar, puedes actualizar una aplicación para que admita el autoescalado. Al cambiar la aplicación para que utilice el autoescalado, las instancias reservadas que se compraron para la aplicación quedarán disponibles cuando la aplicación vuelva a escalar durante los periodos bajos.

Si tu infraestructura tiene mucho autoescalado, quizá quieras ajustar el porcentaje al alza, y si utilizas muchas aplicaciones COTS sin autoescalado, y no cambias a menudo, querrás ajustar el porcentaje de bajo demanda a la baja. Si tu empresa es pequeña y no tienes muchos servidores, probablemente tendrás una idea excelente de tu patrimonio y de su crecimiento. Cuando éste sea el caso, querrás tener un porcentaje de bajo demanda muy bajo.

Planes de ahorro

En 2019, AWS lanzó una nueva capacidad para comprar recursos informáticos llamada Planes de Ahorro. Los Planes de Ahorro ofrecen un descuento cuando garantizas el uso de recursos, igual que las instancias reservadas. La principal diferencia entre los Planes de Ahorro y las instancias reservadas es que los Planes de Ahorro ofrecen una gran flexibilidad. Los Planes de Ahorro se adquieren en función de la cantidad de cómputo que pretendías ejecutar por familia de instancias. Consulta la Tabla 3-1 para refrescar la información. Además, los Planes de Ahorro no están vinculados a ninguna región como las IR. Esto significa que puedes reducir significativamente el riesgo y los gastos generales de gestión utilizando Planes de Ahorro.

Por supuesto, el uso de Planes de Ahorro tiene un posible inconveniente. El nivel de ahorro de un Plan de Ahorro es aproximadamente un 10% inferior al de la compra de RI. Si tienes una empresa mediana, te sugiero que utilices Planes de Ahorro. Si eres una empresa muy grande, la disminución del 10% en el ahorro podría justificar el aumento de los gastos generales de los empleados para gestionar las compras de RI. Para una pequeña empresa, me quedaría con los RI, porque probablemente conoces íntimamente el uso de tu infraestructura informática. No hay celdas específicas para acomodar los Planes de Ahorro en la plantilla de previsiones. Si piensas utilizar Planes de Ahorro en lugar de RI, debes cambiar el porcentaje de la celda H4 del 40%, que es el ahorro medio de RI, al 27%. Haces este cambio porque la reducción media de costes de un plan de ahorro de un año es del 27%. En esta fase del proceso, la Figura 4-7 debería ser una representación similar de tus entradas.

Figura 4-7. Previsión paso 5

Nota

Puedes utilizar una combinación de Plan de Ahorro y RI. Sin embargo, te desaconsejaría hacerlo a menos que comprendas realmente las ramificaciones de utilizar ambos.

Porcentajes de migración

Migrar a AWS no es un proceso instantáneo. Ninguna forma de migración es un proceso instantáneo. Si piensas en la historia reciente, verás los mismos plazos migrando de servidores físicos a máquinas virtuales, incluso por VMware de un centro de datos a otro. En este sentido, migrar a AWS no es nada nuevo. Sólo han cambiado las capacidades.

Ya has pasado por la detección. Sabes cuántos servidores tienes. Has calculado cuánto trabajo puede realizar tu equipo, y has tenido en cuenta a los contratistas y consultores. Has introducido todos estos valores en la previsión de Microsoft Excel. Tal y como está ahora, tienes cinco años de gastos y cada año es el mismo, la tasa de ejecución migrada completa.

Como estamos hablando de modificadores de la tasa de ejecución, ajustaremos los porcentajes de migración que están en la fila 10. La hoja comienza con el valor de 100% en los cinco años. Es como si un hada mágica hubiera migrado todos tus servidores por ti. Ahora quieres volver atrás y ajustarlos en función de tu cronología. Por ejemplo, si tienes un plazo de dos años, tienes aproximadamente el 50% en el año uno, y los años dos a cinco seguirán siendo el 100%. Si tienes una migración de tres años, sería un 33% para el año uno, seguido de un 66% para el año dos, y un 100% para los años tres a cinco.

Una gran empresa debería prever un plazo de migración de tres años. Una pequeña empresa debería estimar en menos de un año su migración, y las medianas empresas rondarían los dos años. Una vez introduzcas toda la información, calculará automáticamente la tasa de ejecución basándose en esos porcentajes.

Te habrás dado cuenta de que aquí sólo trabajamos con porcentajes, y esto se remonta a mi analogía del lanzamiento al espacio. No hemos hecho la planificación de la migración y, por tanto, no tenemos los detalles minuciosos. Como en muchos procesos anteriores, no queremos quedarnos atascados en el alquitrán de más información ahora mismo y que eso ralentice tu proceso de migración. Trataremos la planificación de la migración más adelante, en el Capítulo 7, y cubriremos el calendario con más detalle. En esta fase del proceso, la Figura 4-8 debería parecerse a tus entradas.

Figura 4-8. Previsión paso 6

Agilidad Ahorro

Cuando ayudo a las empresas a migrar a AWS, siempre hago hincapié en la importancia de hacer el mayor lifting and shift posible: copiar los servidores bloque por bloque a AWS, sin centrarse en refactorizar o hacer cambios significativos en la aplicación o la infraestructura. Hago esta sugerencia porque mientras estás migrando, estás gastando el doble. Me centro todo lo posible en reducir los plazos y disminuir esos costes. Hay un par de áreas en las que sí recomiendo capturar la fruta madura para ahorrar en agilidad y gestión. Yo no clasificaría estos cambios como refactorización, sino más bien como aumento. Son cambios que recomiendo que las empresas aprovechen y que son fáciles de obtener.

Después de todo, la agilidad y la reducción de la carga de trabajo son las principales razones por las que la gente quiere migrar a AWS. Tiene sentido aprovechar algunas de esas capacidades desde el principio. Hablaré principalmente de las canalizaciones de implementación y del Catálogo de Servicios de AWS. Estos servicios son las capacidades más fáciles de consumir. Incluso pueden funcionar con aplicaciones COTS, lo que las hace aplicables a casi cualquier carga de trabajo y empresa.

Implementación automatizada

Las canalizaciones de implementación son lo que muchos asocian con las aplicaciones creadas internamente, pero no siempre es así. Las canalizaciones también pueden utilizarse para la implementación de aplicaciones COTS. Normalmente, veo canalizaciones de implementación para aplicaciones COTS en entornos de alta seguridad. En un entorno de alta seguridad, querrías rehidratar tus servidores cada semana. La rehidratación es el proceso de destruir las máquinas antiguas y crear máquinas nuevas con los últimos parches y aplicaciones instalados. Harías esto en un entorno de alta seguridad porque garantiza la eliminación de cualquier malware, virus o troyano potencial. La rehidratación ayuda a reducir la huella de ataque de los servidores COTS y puede ser una herramienta vital para los administradores en entornos regulados, como los servicios financieros. Sin embargo, la mayoría de la gente quiere un canal de implementación para sus aplicaciones internas.

Las canalizaciones de implementación ayudan a reducir significativamente la sobrecarga manual asociada a la implementación y las pruebas. En las instalaciones, lo más probable es que una persona del equipo de ingeniería o del equipo de operaciones reciba la aplicación una vez creada y la despliegue. Esto no sólo le cuesta a tu empresa mucho dinero con el esfuerzo manual, sino que es una tarea tediosa y mundana que puede desmoralizar a los empleados. La implementación manual también es propensa al error humano, lo que provoca problemas de seguridad y cortes de servicio a los clientes. Empleando un canal de implementación, reduces todos estos riesgos y sus costes asociados.

El servicio que Amazon tiene para pipelines se llama CodePipeline. Puede ser activado manualmente por una persona o automáticamente en función de varios desencadenantes, como cuando se despliega un nuevo archivo en S3 o cuando se hace un nuevo check-in en tu repositorio de código, o puedes programarlo con un evento de CloudWatch. De estas opciones, he visto que la mayoría de las empresas realizan la implementación automáticamente tras un registro de código. También podrías crear una canalización que tuviera que activarse manualmente, aunque no lo he visto en la práctica. Sin embargo, sí he visto comprobaciones manuales implementadas en un pipeline automático, como las aprobaciones antes de la liberación de producción.

CodePipeline tiene muchas capacidades. Sin embargo, nos fijaremos en algunas capacidades clave, como las pruebas unitarias automatizadas, las pruebas de carga y otras funciones que ayudan a reducir aún más los gastos generales de los empleados. CodePipeline cobra por su uso. Sin embargo, el coste es muy bajo a menos que tengas algunos casos de uso muy específicos. Estos podrían ser cuando utilizas muchas pruebas unitarias o pruebas de carga que aumentarían el coste. Yo diría que el aumento por servicios varios de AWS que ya tienes en tu previsión es suficiente para cubrir CodePipeline.

En este momento, estamos hablando de previsiones y queremos reconocer el ahorro potencial al utilizar CodePipeline en tu entorno. Para ello, necesitaremos averiguar algunos datos para calcular ese ahorro. El primer dato será el coste medio por hora del personal que realiza tus Implementaciones. Es esencial calcular la carga real del empleado, no sólo el salario base. Querrás asegurarte de que tu tarifa por hora incluye también vacaciones, prestaciones y gastos generales de nómina para obtener una representación real. Para este ejercicio, utilizaremos 100 $ por hora como tarifa de empleado. El siguiente dato que necesitamos es cuánto tiempo se tarda en realizar una implementación de tu software. Esta cifra sería el tiempo que tarda un ingeniero en obtener el software, conectarse al servidor, realizar las copias de seguridad, instalar las actualizaciones y realizar las pruebas de humo y cualquier otra prueba funcional. Utilicemos cuatro horas por entorno para nuestro ejercicio. El último dato que necesitamos es la frecuencia con que se aplican las actualizaciones. Normalmente, las actualizaciones son más frecuentes en los entornos de desarrollo, menos frecuentes en los entornos de prueba y bastante menos frecuentes en los entornos de producción. Querrás averiguar la frecuencia de despliegue en cada uno de esos entornos para calcular con precisión cuánto te ahorrará una implementación automatizada. Para este ejercicio, utilizaremos una implementación para desarrollo a la semana, una implementación al mes en pruebas y una implementación cada tres meses para producción. Estas cifras son una media típica que veo en la mayoría de las empresas.

Empecemos a hacer cuentas. Tomaremos las 4 veces de 4 horas, para un total de 16 horas al mes dedicadas a la implementación del entorno de desarrollo. Eso son 2 días de esfuerzo al mes en un año que equivalen a 24 días, o más que un mes entero de trabajo. Los 24 días son sólo para los entornos de desarrollo. A continuación, queremos calcular cuánto cuesta eso. Hemos dicho que utilizaremos 100 $ la hora, así que multipliquemos 100 por 8 horas, con lo que el total diario asciende a 800 $. Ahora multiplicamos esos 800 $ por los 24 días de esfuerzo del año. Eso eleva el total a 19.200 $. Como ves, se trata de un gasto importante para tu empresa. Ahora que tenemos el coste de desarrollo, queremos repetir el proceso para los entornos de prueba y producción.

Para el entorno de prueba, será una cuarta parte del coste de desarrollo, porque sólo se implementa una vez al mes. La prueba llevará cuatro horas al mes o un día cada dos meses, lo que equivale a seis días al año. Multiplicamos seis días por 800 $ para obtener un coste total de la prueba de 4.800 $ al año.

La producción sólo se implementa una vez cada trimestre. La producción supondrá dos días al año o 1.600 $ de esfuerzo de los empleados. Puedes ver que esta empresa está gastando decenas de miles de dólares (25.600 $) en desplegar la aplicación, por lo que automatizar la implementación de aplicaciones puede ahorrar a tu empresa una cantidad significativa de dólares. Este coste representa sólo una aplicación. La mayoría de las empresas despliegan varias aplicaciones o varias partes de una aplicación grande. Esta proliferación de aplicaciones conduce a un número significativo de recursos de la empresa desperdiciados y, potencialmente, a múltiples contrataciones de personal.

Quieres repetir esta operación para cualquier aplicación que puedas implementar automáticamente y actualizar tu ahorro total en la celda C7. No quieres hacerlo para una aplicación que actualmente requiera un número significativo de cambios y configuraciones manuales. Éstos tendrían que automatizarse. Eso llevará más tiempo de configuración, y alargará tu plazo de migración, reduciendo cualquier ahorro que hubieras conseguido.

Lo maravilloso de implantar la implementación automatizada de CodePipeline es que puedes aumentar significativamente la agilidad de tu empresa. Probablemente tu empresa no está desplegando tantas actualizaciones de tu producto como te gustaría. No es porque los desarrolladores no hagan cambios. Es porque el coste de la implementación es considerable, y los riesgos que conlleva contrarrestan los beneficios. Una vez creado tu pipeline, puedes aumentar significativamente el número de actualizaciones de producción que realizas y ofrecer valor a tus clientes más rápidamente. No es raro oír a empresas que han adoptado un proceso de implementación ágil y automatizado enviar hasta 10 actualizaciones de producción al día. Esta velocidad supone una gran mejora del tiempo de comercialización con respecto a la mayoría de las empresas que sólo lanzan actualizaciones cada trimestre o más tiempo. Las Implementaciones de desarrollo podrían hacerse diariamente o varias veces al día. Las pruebas y la producción podrían seguir el ejemplo hasta alcanzar múltiples actualizaciones de producción al día. Para obtener este nivel de agilidad, tu empresa tendrá que invertir en algo más que un simple canal de implementación y aumentar las pruebas automatizadas para garantizar un lanzamiento de calidad.

Catálogo de servicios

El Catálogo de servicios de AWS es un servicio que te permite crear productos con plantillas de CloudFormation, que despliegan la infraestructura de AWS como código (IaC). CloudFormation te permite automatizar la mayor parte de la implementación de tu infraestructura de AWS. Por ejemplo, mira el siguiente fragmento de código:

InstanceSecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
     GroupDescription: Allow http from the internet
     VpcId:
        Ref: myVPC
     SecurityGroupIngress:
     - IpProtocol: tcp
       FromPort: 80
       ToPort: 80
       CidrIp: 0.0.0.0/0
     SecurityGroupEgress:
     - IpProtocol: tcp
       FromPort: 80
       ToPort: 80
       CidrIp: 0.0.0.0/0

A continuación, tu equipo de operaciones puede permitir que el personal semitécnico acceda a estos productos para implementar la infraestructura necesaria para sus cargas de trabajo. Service Catalog es una forma excelente de ahorrar dinero tras la migración a AWS. He visto a muchas empresas reducir significativamente la carga de su departamento de operaciones mediante la implementación de Catálogo de Servicios.

En muchas empresas, el equipo de operaciones o de gestión de la nube es un punto de estrangulamiento y un único punto de fallo en la implementación de la infraestructura. Al implantar el Catálogo de Servicios, permites que tus unidades de negocio implanten su infraestructura, reduciendo así la dependencia de tu equipo de operaciones. Esta habilitación elimina el punto de estrangulamiento, reduce los retrasos y, en general, aumenta la calidad del servicio.

Cuando estés planeando migrar a AWS, te recomiendo abordar el Catálogo de Servicios buscando patrones repetitivos en tus aplicaciones actuales. La identificación de estos patrones repetitivos te permite maximizar el impacto del Catálogo de Servicios. A continuación, tu equipo puede traducir esos patrones repetitivos en infraestructura como código y en un producto de Catálogo de Servicios. Una vez que los productos estén completos y añadidos al catálogo, se pueden asignar derechos de acceso para que los empleados puedan implementarlos.

Averiguar cuánto has ahorrado con el Catálogo de Servicios es diferente para cada empresa. Para ayudarte a evaluar tu ahorro, analizaremos dos escenarios. El siguiente escenario se centra en la implementación automatizada de instancias EC2, y el "Escenario 4-6" aborda los buckets S3 con endurecimiento corporativo aplicado.

Escenario 4-5

La empresa de Bridget migró a AWS hace unos cuatro meses; en ese momento, no se planteó desplegar Catálogo de Servicios. Antes de que Bridget comprometa los recursos para desplegar los productos del catálogo, quiere averiguar cuánto le costará el esfuerzo. A continuación, lo comparará con lo que ahorrará permitiendo al personal de la empresa el autoservicio.

La organización de Bridget tiene 14.026 servidores y ha identificado 403 aplicaciones durante la fase de descubrimiento de la migración. Se trata de una mezcla de COTS y software desarrollado internamente. Muchos patrones de diseño y software se adquirieron a lo largo de un periodo de 25 años. Uno de los problemas a los que se enfrenta la empresa de Bridget es pertenecer a un sector regulado. Sus normativas exigen que muchos sistemas se validen tras su implementación. Este requisito impone una carga importante al equipo de Bridget. No sólo tienen que crear el sistema y desplegar el software, sino que un segundo miembro de su equipo debe volver y validar que todas las configuraciones son correctas.

Durante los últimos meses, el equipo de Bridget ha estado creando, reforzando y validando manualmente nuevas imágenes del sistema. Crean estas imágenes para su implementación cada vez que AWS publica una imagen actualizada del sistema operativo. A Bridget le gustaría automatizar este proceso y permitir que el personal despliegue sus propios sistemas. Actualmente, el equipo de Bridgette despliega, de media, 80 sistemas al mes, y tarda tres horas y media en aplicar el endurecimiento y la validación.

Al revisar tu infraestructura en busca de patrones, a menudo ingerirás mucho ruido. Si tu empresa es como la de Bridget, probablemente tenga muchos servidores, aplicaciones y patrones de diseño. Sin embargo, a veces la respuesta te está mirando directamente a la cara, y debes limpiar el forraje para verla. He añadido a propósito mucha información extraña en este escenario para demostrar este hecho. Buscamos patrones repetitivos para optimizar el impacto del Catálogo de Servicios. No importa cuántos servidores o aplicaciones tenga Bridget. Puede que hayas empezado a pensar en la parte de la infraestructura: cómo se dispusieron los servidores, los equilibradores de carga, los grupos de autoescalado y elementos similares. Para tu infraestructura, éstas podrían ser opciones viables. En el caso de Bridget, el hecho de que su empresa esté regulada y tenga que dedicar tres horas y media de esfuerzo a la implementación de cada sistema es una enorme cantidad de energía.

Si utilizamos 100 $ la hora para su equipo de operaciones para facilitar los cálculos, vemos que a la empresa le cuesta 28.000 $ al mes la implementación de estos servidores,¹ o 336.000 $ al año. No sé tú, pero yo no quiero esa cifra en mi presupuesto, y estoy seguro de que mi personal preferiría hacer algo más interesante.

Para calcular cuánto ahorrará Bridget en última instancia, también tenemos que calcular el tiempo que tardará su equipo en crear el producto Catálogo de Servicios. Basándome en la descripción de su entorno, creo que sería excesivamente seguro decir que tres semanas de esfuerzo para realizar el trabajo. Este plazo incluiría la creación de los scripts de CloudFormation y automatización necesarios, y la prueba del producto una vez completado. Basándonos en el coste por hora, a la empresa de Bridget le costará 12.000 $ crear el producto.² A continuación, necesitamos saber cuánto costará la implementación del producto. Supongamos que se tarda 10 minutos en iniciar sesión en la consola de AWS, seleccionar el producto, configurar sus opciones e implementarlo. Eso significa que a la empresa de Bridget le costaría 16.000 $ de esfuerzo de sus empleados desplegar los mismos servidores durante un año.³ La empresa de Bridget ahorrará un total de 308.000 $ en el primer año al implantar este producto.⁴ Se trata de un importante retorno de la inversión y a la empresa le merecería mucho la pena implantarlo.

Escenario 4-6

El director de ingeniería de la nube de Kurt ha acudido a él con la propuesta de crear un producto de Catálogo de Servicios para la implementación de cubos S3 para la empresa. Actualmente, el equipo de la nube realiza esta implementación. El proceso no es totalmente manual; han creado plantillas CloudFormation que despliegan la infraestructura. El coste no está en la implementación del cubo S3, sino en la gestión del proceso global. El equipo de ingeniería de la nube da soporte a toda la empresa global, con varios cientos de miles de empleados y docenas de unidades de negocio. El equipo de ingeniería realiza miles de implementaciones al año. Aunque sólo se tarda unos cinco minutos en desplegar el cubo de S3, se necesita aproximadamente una hora de esfuerzo total debido al proceso de documentación y creación de tickets. Al director de ingeniería le gustaría crear el producto Catálogo de Servicios y que se implementara directamente desde el sistema de tickets y flujo de trabajo de ServiceNow, lo que eliminaría toda la carga de trabajo del equipo.

En total, el equipo de ingeniería de la nube implementó 3.546 cubos el año pasado por un total de 1,7 años-persona de esfuerzo (3.546 / 2.080 = 1,7), con lo que el coste total para la empresa ascendió a 354.600 $ al año, basándose en un coste medio por hora de ingeniero de 100 $.

Me encantaría decir que es un escenario absurdo que nunca ocurriría. Sin embargo, ésta es una de esas situaciones en las que la vida es más extraña que la ficción. No es en absoluto extraño ver una tarea técnica mundana sobrecargada con una carga administrativa. Kurt quiere ahorrarse los 354.600 $ que su empresa gasta actualmente en una tarea mundana y de poco valor. ServiceNow tiene un conector que la empresa de Kurt puede aprovechar y que permitiría a los empleados implementar la infraestructura de AWS directamente sin necesidad de iniciar sesión en AWS. El uso del conector permite a su empresa aprovechar las capacidades existentes de flujo de trabajo y aprobación de ServiceNow sin la intervención manual del equipo de ingeniería de la nube. Aunque Kurt tenga que pagar servicios de consultoría para configurar el conector para que interactúe con el Catálogo de Servicios de AWS, conseguirá un importante retorno de la inversión (ROI) en el primer año.

El Catálogo de Servicios puede suponer un ahorro importante para tu empresa, dependiendo del tamaño de tu organización. Obviamente, si tu empresa sólo tiene unas pocas docenas de personas, el retorno de la inversión probablemente no justificaría el coste de la implantación. El catálogo de servicios también te permite ayudar a mantener los gastos financieros aprobando sólo los tamaños de infraestructura adecuados para tu organización. A menudo, los usuarios también tendrán una experiencia de usuario mejorada. El Catálogo de Servicios les permitirá ver fácilmente los productos que ya han implementado, y cuando se publique una actualización, se les notificará automáticamente.

Ahora que ves un par de formas en las que el Catálogo de Servicios y las canalizaciones pueden ahorrar importantes cantidades de dinero a tu organización, es el momento de introducirlo en la hoja de cálculo de previsiones. Estos ahorros están diseñados para introducirse en la celda C7, Ahorros de Agilidad. En este punto del proceso, tu previsión debería parecerse a la Figura 4-9.

Figura 4-9. Previsión paso 7

Supuestos

Ahora que hemos cubierto todo lo relativo a la previsión, es importante discutir los supuestos en torno a la tecnología, las capacidades y los costes. A lo largo de este libro, hemos hecho numerosas suposiciones. Hemos hablado de porcentajes de migración y ahorro de agilidad y de aproximación de los cargos por ancho de banda, por nombrar algunos. En total, probablemente hayas hecho docenas de suposiciones a lo largo del proceso. Por desgracia, la naturaleza humana dicta que cuando escribes algo, lo pones por escrito. Inevitablemente, alguien lo leerá y esperará que sea 100% exacto. Por eso es tan importante documentar tus suposiciones.

Quizá te preguntes qué supuestos debes documentar. No es raro que registre 30 supuestos, aunque los extraigo de una lista bastante más extensa. Normalmente, no documento supuestos obvios. Por ejemplo, no indicaría que el calendario de migración es una estimación; es una verdad innegable, porque no tienes una bola de cristal. Lo que recomendaría documentar son cosas como los gastos generales por hora de los empleados del equipo de ingeniería de la nube que utilizaste en una evaluación del ahorro en agilidad. Para ayudarte a generar tus supuestos y hacer que fluya el jugo creativo, he incluido una lista de posibles supuestos en la Tabla 4-2. Estos supuestos no pueden utilizarse al pie de la letra, pero deberían ser utilizables con algunos retoques y ajustes menores. También puede darte otras ideas que sean relevantes para tu entorno.

Tabla 4-2. Ejemplos de supuestos

Suposición	Suposición
Los costes del ancho de banda saliente se asumen al 10% de la tasa de ejecución de EC2	Los servicios AWS varios se asumen como el 10% de la tasa de ejecución de EC2
Los gastos generales de los empleados del equipo de ingeniería de la nube son de 100$ por hora	Los ingenieros pueden migrar una media de dos servidores al día
La aplicación WidgetWidow tarda cuatro horas en implementarse	Las vacaciones se han incluido en el calendario de migración
Las vacaciones de tres semanas por ingeniero están incluidas en el calendario	Los grupos de autoescalado tienen un mínimo de tres instancias base
Los servidores Microsoft SQL se migrarán a RDS	Las bases de datos Oracle se migrarán a MySQL en Aurora
Las instancias de desarrollo sólo funcionarán en horario de oficina	Valores utilizados en el cálculo del calendario de migración
Las Implementaciones RDS se ejecutarán en modo múltiple-AZ para redundancia	El 80% de la infraestructura utilizará instancias reservadas por un año

El libro de Excel tiene una sección llamada "Supuestos" para documentar tus supuestos. Esto permite que permanezcan con la previsión y elimina un número importante de preguntas. Según mi experiencia, lo mejor es documentarlas directamente con la previsión en lugar de como un apéndice o documento adicional. Esta proximidad permite alternar fácilmente entre los supuestos y la previsión para facilitar el análisis, y garantiza su visibilidad. Con tus supuestos documentados, tu previsión debería parecerse ahora a la Figura 4-10.

Figura 4-10. Previsión paso 8

Coste Burn-Up/Burn-Down

El burn-down rate y el burn-up rate se refieren a la disminución y el aumento incrementales del gasto a medida que migras tu infraestructura. Cuando migras servidores a AWS, te quemas, es decir, añades más coste a tu tasa de ejecución en Amazon. La otra mitad de la ecuación es el desgaste: al migrar fuera, recuperas algunos costes en el equipo local. Sin embargo, estas dos tasas no son iguales. La tasa de burn-up suele ser una trayectoria lineal con un pequeño escalonamiento a medida que migras las aplicaciones. En la Figura 4-11 puedes ver un ejemplo de burn-up.

Figura 4-11. Ejemplo de quemado

La Figura 4-11 muestra una empresa que migra de on-premises a AWS. Como puedes ver, la tendencia general es bastante lineal, pero tiene escalones a medida que se completa cada una de las oleadas de migración significativas. Algunas de las oleadas tenían aplicaciones con más servidores, por lo que algunos de los pasos son mayores que otros. En la Figura 4-12, puedes ver un gráfico de burn-down, que es significativamente diferente del burn-up.

Figura 4-12. Ejemplo de quemado

Cuando migras desde las instalaciones, la retirada de un servidor no indica necesariamente la retirada de toda la infraestructura subyacente. Esta eliminación latente no es cierta en el caso de servidores físicos, como un gran servidor de base de datos, donde el equipo se retira inmediatamente. Sin embargo, la mayoría de las empresas tienen una infraestructura altamente virtualizada. En una infraestructura de este tipo, la mayoría de los componentes se comparten entre docenas y potencialmente cientos de miles de servidores. En el caso típico, tendrás que eliminar muchos servidores in situ para ver una reducción de costes. Por lo tanto, los pasos de la Figura 4-12 son significativamente más largos en duración y más cortos en disminución del gasto en comparación con el burn-up. La mayor parte de la reducción de costes en el burn-down no se produce hasta el final de la migración. Esta reducción se produce cuando se pueden apagar los componentes más significativos de la infraestructura local, como las SAN y las propias instalaciones.

Normalmente, no incluyo un análisis de burn-down en las migraciones en las que he trabajado, sobre todo por la cantidad de esfuerzo que requeriría calcularlo. Para calcular el burn-down, necesitas saber qué servidores son físicos y virtuales, y si son estos últimos, a qué host y SAN están conectados. Lo mejor sería que luego asignaras los costes adecuados de esos activos a esos servidores y en qué punto de la migración se encuentran para crear un burn-down. Los cálculos de burn-down añaden varias semanas al plazo total de migración y aportan un valor muy bajo a la empresa. El análisis del burn-down tampoco puede realizarse hasta después de la fase de planificación de la migración y no se incluye en la previsión. La razón por la que lo he incluido en este capítulo es que, para mucha gente, tiene sentido incluir el burn-down como parte de la previsión financiera. A primera vista, esto tiene sentido, pero una vez que comprendas lo que se necesita para completar un burn-down correctamente, verás cómo no es práctico incluirlo en la previsión.

Para terminar

En el gran esquema de las cosas, construir tu caso empresarial es probablemente uno de los esfuerzos menores del proceso de migración. La mayor parte de la información ya está disponible en los procesos anteriores, y se trata más bien de ajustar y transmitir adecuadamente el material que es importante para el caso empresarial. Construir la narrativa es probablemente el proceso más largo. Sin embargo, afortunadamente, deberías disponer de una buena fuente de información gracias a las FAQ que se construyeron como parte del Capítulo 1.

El caso empresarial es un punto crucial en tu migración a AWS; es la pieza final que transmite tu intención, costes y valor empresarial. En este punto, estarás en una encrucijada; un camino te lleva hacia adelante en tu migración, y el otro te deja en las instalaciones. No puedo expresar lo suficiente lo importante que es el caso empresarial para hacer avanzar a tu empresa en sus capacidades competitivas mediante la migración. Merece atención y no debe considerarse oneroso. Esperemos que tu caso empresarial muestre el valor que has descubierto, y que se aprueben tus esfuerzos de migración. Para prepararte mejor para iniciar la migración, el Capítulo 5 tratará sobre cómo abordar las operaciones de tu empresa para preparar la migración, y cómo construir una historia de éxito que puedas transmitir a otros departamentos para conseguir su adopción.

¹ $100 × 3.5 × 80 = $28,000.

² $100 × 15 × 8 = $12,000.

³ $(100/6) × 80 × 12 = $16,000.

⁴ $336,000 - 12,000 - 16,000 = $308,000