Migración AWS / Well Architected Framework

Las migraciones de AWS implican el proceso de traslado de cualquier carga de trabajo
desde un entorno local, instalación de alojamiento u otra nube pública, con el objetivo
de generar ahorro de costos de TI y mejoras en los aspectos de productividad, agilidad
empresarial y resiliencia operativa.
Este proceso de migración, se conforma de 5 fases: 1) Evaluación de oportunidades, 2)
Descubrimiento del portafolio de cargas de trabajo y planificación, 3) Diseño de las
aplicaciones, 4) Migración y validación, y finalmente 5) Operación.
Una vez evaluadas las oportunidades e identificado el portafolio de aplicaciones,
existe una serie de estrategias, así como un conjunto de mejores prácticas y
consideraciones que que nos pueden ayudar a llevar a cabo una migración exitosa a la
nube de AWS.

En lo que se refiere a estrategias de migración, AWS sigue una serie de
recomendaciones basadas en los lineamientos de Gartner, en particular las 5 R’s,
Rehosting, Refactor, Revise, Rebuild y Replace. Las mismas fueron luego rebautizadas
como: Rehosting (lift & shift), Replatforming, Repurchasing, Refactoring /
Re-architecting y Retire.

1) Rehosting (lift & shift)
Esta estrategia busca llevar a la nube aplicaciones legacy que no se pueden migrar o
sacar provecho de las funcionalidades de la nube. Por ejemplo, cargas de trabajo que
corren tal cual como están y que no se han tocado en años y que incluso puede darse el
caso que la organización no tenga documentación actualizada o que el equipo o
proveedor que la desarrolló no se encuentre más vinculados a la empresa. Para este tipo
de cargas de trabajo aún se puede puede aprovechar el hecho de migrar a la nube de
AWS, ya que en términos de costos puede significar ahorros de hasta 30%.
Una de las ventajas que se tiene con esta estrategia es que una vez que las carga de
trabajo está en la nube se puede aprovechar muchos de los servicios de AWS, como
respaldos de volúmenes o creación de AMIs, además se puede luego emplear una
estrategia de refactoring que permita modernizarlas.
2) Replatforming
Otra estrategia a considerar es la de llevar las cargas de trabajo con la arquitectura
actual on-premise pero reemplazando la plataforma subyacente por las provistas por
AWS. Por ejemplo, una base de datos migrarla a AWS RDS.
Esto tiene como ventaja que algunas de las operaciones que se tenían que realizar para
mantener la plataforma en on-premise se le estaría relegando a AWS, como la
actualización de software del motor de base de datos o la implementación de la
seguridad de la infraestructura.
Es recomendable identificar estos servicios de los cuales se pueden tomar ventaja.
Algunos de ellos son AWS RDS, AWS ElasticSearch, AWS AWS DynamoDB -
Document DB, entre otros.

3) Repurchasing
También es factible plantearse la posibilidad de cambiar a otros productos, por ejemplo
llevando funcionalidades a plataformas SaaS. Vale la pena evaluar los costos de
mantenimiento de sistemas (ingenieros, licencias, etc) y la necesidad de enfocar los
recursos al negocio.
Por ejemplo, tiene sentido mantener la infraestructura de una suite como la de
Atlassian (Bitbucket, Confluence, Jira, etc). si no se tiene requerimientos especiales
provenientes del lado del negocio? No. Es preferible enfocarse a la lógica del negocio
y consumir este tipo de herramientas como SaaS.
4) Refactoring / Re-architecting
Esta estrategia está orientada en sacar provecho de las funcionalidades que ofrece
AWS, ya que busca rediseñar las cargas de trabajo tomando en cuenta las tecnologías
nativas de la nube.
Esta quizás es la que puede implicar mayores cambios pero es las más beneficial. Por
ejemplo, desacoplar una aplicación monolítica en microservicios permite que cada
servicio escale de forma independiente, que tenga su propio ciclo de desarrollo, y
tecnología de implementación independiente.
También permite incluir mejoras sobre las cargas de trabajo para, por ejemplo,
aprovechar otros recursos proporcionados por AWS, balanceadores (AWS Application
Load Balancers), web application firewalls (AWS WAF), Content Delivery Networks
(AWS CloudFront), entre otros de la amplia gama de productos de AWS.

5) Retire
En el proceso de descubrimiento surgirán algunas cargas de trabajo que probablemente
no se había identificado hasta el momento en que se decide hacer la migración. Muchas
de estas cargas de trabajo puede que ya no sean útiles para el negocio, por ejemplo,
aplicaciones no inventariadas y que no están siendo usadas.
Estas cargas de trabajo simplemente se pueden apagar del lado on-premise sin
necesidad de migrar a la nube.
Estas cargas de trabajo que se desincorporan pueden representar un ahorro (por lo
general de 10%, o a veces hasta 20%), ya que se dejaría de invertir en infraestructura
on-premise, licencias, y mantenimiento de las mismas.
6) Retain
En la etapa de descubrimiento surgirán cargas de trabajo que no encajen en alguna de
las estrategias anteriores. Por ejemplo, con algunas puede existir la duda que se deba
desincorporar, o migrar. Estas aplicaciones se pueden poner en “pausa” para la
migración, y analizarlas nuevamente en una siguiente iteración.
De esta manera se puede priorizar la migración de aquellas aplicaciones que tengan
más sentido para el negocio.

El AWS Well-Architected Framework es un conjunto de recomendaciones y
consideraciones que se deben tomar en cuenta a la hora de arquitectar soluciones en
AWS. Con este framework se pueden medir constantemente las arquitecturas de las
aplicaciones contra las mejores prácticas e identificar áreas de mejora.
El marco de buena arquitectura fue creado a partir de las experiencias aprendidas por
los ingenieros y arquitectos de AWS en miles de despliegues alrededor del mundo.
El mismo consta de cinco pilares (por sus nombres en inglés): Operational Excellence,
Security, Reliability, Performance Efficiency, y Cost Optimization.

PILAR DESCRIPCIÓN
Operational Excellence
Es la capacidad de ejecutar y monitorear sistemas para brindar valor comercial y
mejorar continuamente los procesos y procedimientos de soporte.
Security
Es la capacidad de proteger la información, los sistemas y los activos al tiempo que
ofrece valor comercial a través de evaluaciones de riesgos y estrategias de
mitigación.
Reliability
Es la capacidad de un sistema para recuperarse de la infraestructura o las
interrupciones del servicio, adquirir dinámicamente recursos informáticos para
satisfacer la demanda y mitigar interrupciones tales como configuraciones incorrectas
o problemas de red transitorios.
Performance Efficiency
Es la capacidad de utilizar los recursos informáticos de manera eficiente para cumplir
con los requisitos del sistema y mantener esa eficiencia a medida que la demanda
cambia y las tecnologías evolucionan.
Cost Optimization
Es la capacidad de ejecutar sistemas para entregar valor comercial all punto de
precio más bajo.

La importancia del AWS Welled-Architected Framework en el proceso de migración es
vital, incluso con cada una de las estrategias de las 6 R’s de migración, ya que cada uno
de los pilares tienen algún grado de participación en la toma de decisiones.
Por ejemplo, para Rehosting y Retire el pilar que mayor peso puede ser Cost
Optimization ya que con estas estrategias se pueden obtener ahorros significativos
respecto a on-premise.
Para la estrategia de Replatforming, habrán algunos pilares considerar sobre otros,
dando seguramente más ponderación a Operational Excellence, Reliability, y
Performance Efficiency.
Con la la estrategia de Repurchasing seguramente se estaría apuntando otros grupo de
pilares como Security, Reliability, y Performance Efficiency. Cabe mencionar que con
esta estrategia el pilar Cost Optimization puede parecer el menos adecuado a
apuntalar, pero los costos no solo se deben considerar en términos de licencias, sino
que también en términos de beneficios a obtener al enfocar recursos de negocio.
En la estrategia de Refactoring / Re-architecting todos los pilares deben ser
analizados a fondo, ya que permitirán evaluar la arquitectura actual y hacer las
preguntas adecuadas al momento de re-arquitectar una solución.

Por ejemplo, si queremos desacoplar un monolito con una una implementación
adecuada de microservicios, algunas de las preguntas que debemos hacernos ya se
encuentran cubiertas en el AWS Well-Architected Framework:
¿Cómo mitigar los riesgos de implementación? - Operational Excellence
¿Cómo monitoreamos el uso y el costo? - Cost Optimization
¿Estamos preparados soportar altas demandas? Podemos escalar hacia abajo
cuando la demanda sea baja demanda? - Reliability
¿La arquitectura que diseñamos es la que tiene el mejor rendimiento? -
Performance Efficiency
¿Cómo protegemos las redes? - Security
Las soluciones de AWS han sido diseñadas para ayudar a resolver los problemas más
comunes de manera eficiente, segura y rentable desde el punto de vista operativo.
Todas ellas incorporan una arquitectura detallada, una guía de implementación e
instrucciones para realizar los procesos de forma manual y automática.

Referencias
[1] Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace?
[2] The 5 R’s of Cloud Migration Strategy
[3] 6 Strategies for Migrating Applications to the Cloud
[4] Considering a Mass Migration to the Cloud?
[5] A Process for Mass Migrations to the Cloud
[6] The 5 Pillars of the AWS Well-Architected Framework
[7] The AWS Well-Architected Framework whitepaper

Somos una compañía boutique de tecnología con alcance
global, especializada en innovación y transformación digital
empresarial con enfoque en soluciones personalizadas y
servicios profesionales.
www.nubiral.com

Migración AWS / Well Architected Framework

Más contenido relacionado

La actualidad más candente (20)

Similar a Migración AWS / Well Architected Framework (20)

Más de Corina Castañeda (8)

Último (20)

Migración AWS / Well Architected Framework