Webinar: Simplificando la migración de aplicaciones a la nube.

Bianca Grullón, Osvaldo Luna, and Daniela Blanco walk through AWS migration strategies and tools. They cover migration types, managed services like AuroraDB, and serverless architectures for businesses moving applications to the cloud.
Gracias a todos por asistir este día al webinar sobre Simplificando la migración de aplicaciones a la nube. Les pedimos, vamos a tener una sesión al finalizar de preguntas, si tienen alguna en específico lo pueden ir haciendo por medio del chat y cuando tengamos la sesión de preguntas las contestaremos. El día de hoy estaremos llevando a cabo este webinar, su servidora Bianca Grullón, quien soy la consultora comercial de Ciudad de México, Daniela Blanco del equipo de servicios profesionales y Osvaldo Luna, quien es el coordinador de servicios Profesionales. En este webinar llevaremos la siguiente agenda, primero presentando quiénes somos nosotros, quién es Comput Cloud, cuál, cuáles son los procesos de migración, tipos de migración, herramientas de migración, migración de Windows en AWS, migración de bases de datos en s a servicios administrados y migración de servidores tradicionales a servicios serverless, que es una nueva tecnología que estaríamos hablando ahora y Migración AuroraDB, quien es una base de datos de Amazon Web Services. Les pedimos por favor que en caso de que se enciendan sus micrófonos nos puedan apoyar a ponerlos en silencio para que el locutor que esté llevando a cabo el webinar todos lo podamos escuchar y ya en caso de que quieran hacer alguna pregunta lo pueden hacer por medio del chat. En caso de que nos dejen de escuchar o que no puedan ver la presentación, favor de hacérnosla llegar por medio de chat para poderlos apoyar. Pues ahora sí damos inicio al término de este, les vamos a llegar, les vamos a hacer llegar el link para que puedan ver el webinar y en caso tener la presentación de la que estaríamos dando el día de hoy. Pues bienvenidos a todos y gracias por asistir. Primero que nada, pues ¿Quiénes somos nosotros? ¿Quién es Compucla? Compucla es una empresa dedicada 100% tecnología en nube, principalmente de Amazon Web Services. Nosotros estamos desde el 2012 enfocados 100% entregarles a las empresas de ser un aliado estratégico para la adopción de la tecnología en nube en temas de planación, migración, implementación y sobre todo administración de esta nube. Nosotros contamos con las certificaciones tanto técnicas como la de Cloud Practitioner, que eso es parte de todo el equipo de CompuCloud y de igual manera somos partner directamente de Amazon Web Services, en el cual nos han premiado como el Partner Consulting del 2019 y actualmente contamos con la certificación de Service Delivery Program, en el cual nos enfocamos en temas de migraciones de Windows y demás y lo que está la competencia de Digital Customer Experience, la cual nos avala como un partner de conocimiento para poderles dar la mejor infraestructura para sus soluciones de páginas web o e commerce, en el cual nos enfocamos mucho a la experiencia del cliente final, no tanto a la infraestructura física, sino a darle la mejor experiencia a los clientes finales a través de las tecnologías en nube. También tenemos la certificación de Well Architecture, el cual es un programa basado en cinco principios que busca la optimización de tu infraestructura en temas de optimización de costo, seguridad, fiabilidad y excelencia operacional. Nosotros estamos enfocados en todo México, nuestras oficinas principales están en Guadalajara, pero tenemos clientes desde Monterrey hasta Cancún y toda la República y parte de Centroamérica, en el cual tenemos varios clientes. Nosotros buscamos ser un consultor especializado tecnología en nube para todos nuestros clientes, que sean nuestros aliados estratégicos para ayudarles a la transformación digital de su empresa, que sabemos que no solo es un punto de la parte de poderte migrar hacia la nube, sino también es todo un concepto que se puede integrar a la empresa. Buscamos ser los líderes digitales que les brinden una mejor experiencia a los clientes finales, alcanzar nuevos niveles de eficiencia, tener una alineación estratégica de sus metas empresariales para poderlos apoyar en lo que nos corresponde a nosotros en la parte de seguridad, infraestructura en nube y crear una fuerza laboral más ágil, es decir, en la manera que los podamos apoyar, que ustedes puedan dejar la administración y poderse enfocar en algunos temas más de desarrollo hacia sus empresas. Entonces, considerando que el primer paso para la transformación digital es migrarte hacia la nube, este es el tema principal que estaremos tratando y para esto es importante establecer algunos procesos. Cuando uno está pensando en migrarse, uno de los puntos principales es definir todo lo que vas si vas a querer mandarlo todo hacia la nube o si vas a presentar como un ambiente híbrido. De esta manera te da una mayor visibilidad de hacia qué información requieres o de qué manera podías estar cotizando cotizando esta nueva solución o servicio que estés buscando. Tener un listado de los aplicativos, de este modo tienes como una visión más amplia de qué es lo más importante para tu empresa y puedes crear como etapas para tu migración, si la quieres toda la nube, no es necesario migrarte de una vez, porque entendemos que es un tema de adaptación y por eso siempre establecemos que se tengan los aplicativos más importantes y de esta manera ir migrando palatinamente toda la información. Otro punto es establecer prioridad de la migración de los aplicativos, es decir, si primero lo más importante para ustedes es la parte productiva o la parte de RH, dependiendo de la necesidad de tu negocio, es la parte en la que se debería estar trabajando, de tener definido las características del sistema, de esta manera puedes dar una mayor información de qué es lo que necesitas para realmente funcionar al 100% la nube. Analizar las dependencias de los sistemas, esto es muy importante porque cuando quieres migrar un aplicativo y tienes que tener una conexión con algún otro, es necesario tener como esta información para poder incluirlo al plan de migración y sobre todo tener una visión del comportamiento al futuro, hacia dónde van, cuál es su meta y cuál es como el objetivo final que estén buscando al tener estas nuevas tecnologías. Obviamente muchos la parte más importante es optimización de costos, tener alta disponibilidad y una mayor seguridad o tener como ese respaldo nuevo ante alguna contingencia. Tener la parte tanto en tu empresa como parte física y en la parte de la nube como parte de complemento de las mejores prácticas. Y para poder hablarles un poquito más de la metodología de la migración, la palabra a mi compañero Osvaldo Luna, quien nos explica más.
Perfecto, muchas gracias Bianca. Muy buenos días a todos, nuevamente muchas gracias por acompañarnos. Y precisamente para aterrizar un poquito más técnicamente los puntos que mencionó anteriormente mi compañera Bianca, tiene que ver de una metodología de AWS que seguimos para los esquemas de migración de aplicaciones, que se compone de tres macrofases principales y cada una con dos subfases que va desde la planeación, la migración y hasta la ejecución. Como hemos hablado, un tema de una correcta metodología para migraciones planeares, eso es como muy importante o es una de las partes que ponemos mucho foco, ¿Por qué? Porque evaluamos o hacemos evaluación del perfil, la priorización, la clasificación de los requerimientos, lo que mencionaba mi compañera Blanca, de las dependencias que dices, OK, si voy a migrar, ¿Qué depende? ¿Cómo me conecto? ¿Cómo voy a conectar a mis usuarios? Depende alguna aplicación externa, depende con una aplicación que tenga internamente. Entonces al evaluar o generar toda esta priorización de clasificaciones, generamos un diseño en el diseño en el cual involucra generar una planeación de migración, una topología de red, servicios basados, es decir, sabes que en base a tus necesidades vamos a migrarte de esta forma y vamos a preparar tu infraestructura local y vamos a preparar todas aquellas metodologías de acceso como tal. Una vez que tengamos el plan y tengamos bien clara la estrategia o y bien comprendido el diseño, avanzamos a la siguiente etapa que es la etapa de migración. En la etapa de migración es donde empezamos y ahora sí ya, ahora sí la puesta a punto y por eso está como en cuadro, es donde empezamos ya a operar o empezar a generar los procesos de migración. ¿Qué quiere decir? No necesariamente una migración vamos a quedar horas fuera operando, va a durar este día sin que puedas tener acceso a esas aplicaciones. No, todo esto se planea y ahorita mi compañía va a hablar un poquito de la cerradura de migración, pero sobre todo la parte inicial es donde migramos, hacemos el despliegue, generamos la integración de la infraestructura y la integración de aplicaciones. Posteriormente se hace una fase de transición donde hacemos y va muy enfocado a las pruebas funcionales y generamos una migración piloto. ¿A qué me refiero? Muchas veces se comienza a migrar como buena práctica aquellas aplicaciones menos críticas y menos críticas y sobre todo que tengan menos dependencias. ¿Por qué? Porque esto nos va a ayudar a generar un tema de transición y muchas veces la transición, la migración puede llevar desde días, semanas y meses. No me refiero tanto al tema de que eso nos va a llevar migración, más bien la estrategia de TI, de la organización puede llevar, este puede ser un proyecto a muy largo plazo donde vamos migrando paulatinamente y es donde la transición hace sentido. Es decir, no es que vayamos decir esta semana vamos a migrar todo, vamos a mirar nuestro SAP, vamos a mirar nuestro CRM, vamos a mirar mi página web, No, no, es una correcta práctica y todo desde la estrategia lo vemos y lo ponemos en base en esta transición. Una vez que ya está la etapa, la ejecución, vienen los temas de las operaciones. En las operaciones tiene que ver como vamos, cómo estamos monitoreando, estar validando un tema de si lo que levanté está corriendo con el mejor performance, si no estamos sobrados, si no estamos como tal cortos en infraestructura, todo lo que podamos empezar a llegar a ver en las operaciones es donde se generan, los tiempos de monitoreo son diferentes o los tiempos de operaciones capacitación varía dependiendo la cantidad de cargas de trabajo. Una vez que ya estamos operando y tenemos métricas suficientes para poder generar un tema, viene un tema de mejora y optimización aplicaciones. ¿Por qué? Porque la parte de optimización de aplicaciones viene también en usar más servicios, que más adelante entraremos a detalle, que no solo es llevarnos los servidores que hoy tengo de manera local, ese es el primer paso como está en la parte de migración, una migración lift and she, el primer paso es, me llevo mis servidores que tengo local o de otra nube o desde cualquier parte, me los llevo hacia la nube, opero, estoy operando y posteriormente trabajamos en un tema de mejora, que la parte de mejoras tiene que ver con temas de ahorros de costo, temas de seguridad e inclusive temas de performance, que podamos estar llegando a trabajar de una manera mejor como lo hacíamos antes de la migración y sobre todo también a costos más accesibles. Estas son las tres etapas principales y ya dependiendo, existen diferentes tipos de migración que mi compañera Daniela es quien va a hablar a continuación para explicar los diferentes tipos de migración basados en las prácticas de AWS.
Hola muy buenos días, A continuación les voy a hablar de los tipos de migración. AWS tiene ciertas estrategias que son conocidas como el modelo de las R, recientemente las ha estado mejorando para adaptarse a los pilares con los que está trabajando de una buena arquitectura. El primer punto es el rehost, esta estrategia se llama o es conocida como Leave and Shift, es decir, en esta se trasladan las aplicaciones a la nube sin necesidad de un rediseño de ningún tipo. Por tal motivo, esto permite una migración relativamente más rápida, ya que existen herramientas para llevar a cabo este proceso de manera automática. La ventaja que ofrece es que un rediseño posterior será más sencillo de realizar, ya que la aplicación se va a estar ejecutando en la nube. El siguiente punto es Replatform, corresponde al escenario Leaf Tinker and Shift, es decir, es similar al rehost, en donde no cambia de forma fundamental la arquitectura de la aplicación en sí, pero en este se van introduciendo ciertas mejoras en el mismo aplicativo o servidores El siguiente punto es Repurch, esta estrategia consiste en un cambio a una plataforma SaaS o Software as a Service, es decir, se adopta una nueva aplicación que ya está en la nube, por ejemplo trasladar un CRM a un Salesforce. Com o bien un sistema de recursos humanos a un aplicativo tipo Monday. El siguiente es Refactor o rearchitect, consiste en un rediseño más profundo de la aplicación para que se pueda escalar a un rendimiento más óptimo a la nube y que a su vez se vuelva cloud nativa. Por ejemplo si se está buscando migrar una arquitectura digamos que monolítica a una arquitectura orientada a servicios o sin servidor para aumentar la agilidad o mejorar la continuidad de negocio, esta sería la estrategia más adecuada a seguir. El siguiente punto es Retained, básicamente consiste en decidir de manera consciente qué aplicaciones no migrar a la nube y esto se puede deber a aquellas aplicaciones digamos que han sido actualizadas recientemente, que quieran que acumulen alguna depreciación o bien que aún no estén dispuestos a migrar alguna de las mismas, es decir, que pueden ser aplicaciones un poco más críticas y que se requiera tomar un tiempo mayor para establecer la mejor estrategia o establecer cuándo migrarla. Y el último punto es Retire, esta estrategia se trata básicamente aprovechar el esfuerzo de análisis de la realidad de los sistemas disponibles con los que cuentan, esto para prescindir de algunos que realmente no aporten valor o cuya funcionalidad pueda ser absorbida por otro por otro aplicativo. También puede ser determinar cuáles aplicaciones ya no son útiles y esto puede impulsar una migración más rápida para la continuidad de su negocio. El siguiente punto son las herramientas de migración, estas son aquellas herramientas que facilitan el proceso de migración de las aplicaciones o sistemas y esto su vez facilita también el monitoreo de los procesos de migración, es decir, se pueden estar llevando un seguimiento continuo del proceso mismo. Entre los beneficios con los que se encuentran son las migraciones sencillas, control, minimizar tiempos de inactividad, configuración rápida y sencilla, reducción de costos y fiabilidad. En el primer caso las migraciones sencillas, esto significa que simplifican el proceso de migración de las aplicaciones desde la infraestructura, sea física, virtual o basadas en alguna otra nube, lo que asegura que estén en pleno funcionamiento en cualquier región de AWS sin ningún tipo de problema de compatibilidad luego el beneficio del control, esto se debe a que pueden crear y administrar programas de replicación personalizados para migraciones a gran escala y se puede llevar un monitoreo progresivo de cada migración para que puedan ir controlando el proceso en sí. El siguiente punto es minimizar tiempos de inactividad, esto se debe a que se lleva a cabo una replicación gradual del servidor o en tiempo real, lo que permite reducir significativamente el tiempo de inactividad de éste. Las configuraciones rápidas y sencillas, bueno, se pueden configurar ciertas tareas de migración en cuestión de minutos y una vez configuradas dichas tareas se pueden utilizar para realizar ejecuciones de pruebas, es decir, unos test de migración antes de realizar la migración real. Esto es para corroborar el estado o el funcionamiento de las migraciones y las cargas de trabajo. La reducción de costo, debido a que se pueden migrar aplicaciones o bases de datos desde cualquier infraestructura y no es necesario invertir en un desarrollo más especializado en la nube, tampoco hay que invertir en habilidades específicas de sistemas operativos o aplicaciones, ni en recursos de TI o capacitación para su personal, esto resulta en costos operativos más reducidos. El siguiente beneficio es la fiabilidad, presenta una alta resiliencia y recuperación automática, además de proporcionar un monitoreo constante del proceso de migración desde el origen hacia el destino, así como la conectividad de red, monitoreo del mismo. Migraciones de Windows en AWS Además de ayudar a reducir los costos, al realizar una migración de Microsoft se logra aumentar la agilidad y es más seguro. Cabe mencionar que AWS ofrece una amplia gama de servicios globales de informática, bases de datos, aplicaciones e implementaciones que utilizan tecnología de Microsoft o están diseñadas para poder trabajar en ellas. Entre los productos de Microsoft que se encuentran disponibles o compatibles es Microsoft Windows Server Exchange SharePoint, SQL Server System Center Ofrece la posibilidad de utilizar las licencias de las aplicaciones de Microsoft Server en Windows. Además en Compuclo contamos con el service de Libre Program que cabe mencionar esto nos avala como expertos o con experiencia en la implementación y migración de cargas de trabajo con Windows hacia la nube de AWS. A continuación va mi compañero con los servicios administrados de EC a estos mismos.
Perfecto, muchas gracias Daniela, como bien lo mencionó, digo a través de las diferentes herramientas de migración que les ayudaría a facilitar, es decir a eso me refería hace un momento, que no necesariamente debes de tener cortes de servicio, sino que podemos generar automatizarlo, automatizar diferentes cuestiones y una de ellas que también de las etapas o de las, una de las seis semanas de migración también es transformar y utilizar por ejemplo, servicios administrados. En AWS existen muchos de servicios, pero ahorita hablando particularmente de servicios de bases de datos administrados, podemos contar o podemos llegar a migrar desde infraestructura tradicional, decir sabes que yo tengo en un servidor, tengo una base de datos, un MySQL, tengo una SQL, tengo un MongoDB, ya dependiendo de tu base de datos podemos hacer esta migración a diferentes servicios. Por ejemplo, unos ejemplos de servicios administrados, RDS que significa Relational Database Services, tiene que ver donde ya se te entrega un motor totalmente administrado, es decir, tú ya no te preocupas por administrar el hardware, no te preocupas por administrar tal cual un servidor, aquellos parches que requieran un servidor, actualizaciones, etc. No, tú solo te preocupas por estar alimentando la base de datos y conectarla con tu aplicativo y Amazon se encarga el restante. Esto te facilitaría temas de failover, temas de bases de datos de réplica para mejorar performance, etcétera, que te podrían llegar a generar tener acceso a alta tecnología de base de datos a un costo bastante mucho menor. Por ejemplo, también está el tema de Redshift y DynamoDB, cada una tiene, funcionan con base de datos no relacionales, cada una con cierta funcionabilidad, pero eso, el motivo por qué mostrarle esta diapositiva es porque podemos llegar a generar dicha migración que ya que va un tema de no sólo quedarnos con lo tradicional, ese es el primer paso. En los temas de generar servicios administrados también viene lo siguiente que es tema de serverless, en el cual los servicios serverless es como otra manera de generar o poder estar mostrando la infraestructura, prácticamente es un servicio el cual te permite o puedes llegar a implementar temas aplicaciones core, aplicaciones web sin necesidad de administrar servidores, es decir, tú contratas servicio, pagas por un servicio, disculpen aquí unos problemas técnicos de desconexión. Perfecto, es una disculpa. Como les comentaba, el servicio serverless te permite, es como va evolucionando, inclusive la gráfica puede mostrar cómo podemos llevar de un tema monolítico hacia un tema de serverless. El monolítico es donde la estructura tradicional donde en un solo servidor tenemos bases de datos, tenemos como tal aplicaciones frontend, backend, o sea todo genera y evoluciona un tema de microservicios, contenedores es uno de ellos o simplemente generar arquitecturas distribuidas donde podamos separar bases de datos, aplicaciones en pequeños servicios y viene también la evolución serverless que regularmente también tiene que ver con un tipo de paso plataforma as a service, entonces la parte de los servicios serverless es lo que nos permite evolucionar como tal y también podemos hacer esta migración en lugar de irnos a un servidor, supongamos dices sabes que yo tengo un servidor donde simplemente corro una aplicación basada en PHP, basada en java, basada en Node JS, el lenguaje que genera dicha aplicación, pues bueno ya no necesariamente puede correr funciones muy específicas que pueden aplicar para un tema de serverless, le reitero desde el tema de análisis o de la que hacemos para la migración y propone propuesta de arquitectura hacemos este ejercicio porque también no todo aplica para un modelo serverless, de repente vas a decir si oye yo quiero mandar mi SAP a la nube para un modelo serverless, pues bueno hoy en día no es posible hacer eso sino simplemente analizamos bien cada tema y vamos viendo qué se puede hacer a través de configurar tu código, generar temas de recursos de cómputo solamente por lo que necesitas y lo más importante de un tema de serverless que te permite ajustar el tiempo y solamente ya te genera como pago por peticiones y por uso y por ejemplo un esquema también de migración en servicios tradicionales a serverless como bien lo mencioné ahí está los principales beneficios y cómo te pueden llevar a un tema desde un tema heredado por ejemplo a cómo hacerlo nativo nube, pero el tema de serverless te va a ayudar en pago por uso, si bien la nube dice oye yo escuchado que la nube es pago por uso, si efectivamente si tú tienes un servidor este prendido 10 horas al día pues vas a estar pagando el equivalente esas 10 horas al día, pero a qué se debe o como evoluciona un serverless es que diferencia va y un server les en pago por uso OK, que en caso contrario por ejemplo el servidor lo puedes tener prendido 10 horas al día porque es una aplicación interna y dices ese es el horario laboral y es cuando se van a poder conectar de ahí en la noche nadie se va a poder conectar, pero un servicio serverles no te cobra, ahí cobrarías, ahí te pagaría por horas sale tú tendrás que pagar por horas por un servicio serverless, pagas por las peticiones que hiciste en lugar de pagar 10 horas dices que hubo 15 peticiones y vos cierta transaccionalidad. Entonces es lo que lo que te lo que pagaría sería todo el modelo más económico, tienes un escalado totalmente más flexible para decir también oye he escuchado que también es flexible, si también puedes crecer, decrecer servidores en una infraestructura tradicional andube sin ningún problema, más sin embargo un tema de server estudiando te preocupas por ir aprovisionando más servidores, más servidores conforme la demanda vaya creciendo, sino simplemente por lo mismo que es un servicio que tú pagas y te despreocupas de la administración servidor en automático, este siempre vas a estar en las condiciones óptimas para estar atendido tu workload y esto pues tiene que ver con el tema de alta disponibilidad automatizada y por lo mismo que ya mencionamos no hay un tema de servidores que administrar como tal. Hablamos de diferentes estrategias de migración y también hemos hablado de cómo mi compañera Blanca habló también sobre el tema de decir oye sabes que se va a la nube, que no se va a la nube, que puede irse, pues bueno también una estrategia correcta también es trabajar bajo entornos híbridos y este es uno de los casos que puede ser híbridos y de los casos que hoy en día en la industria cada vez es más común encontrar, dices oye sabes que ya tengo mi infraestructura, tengo cierta infraestructura virtualizada, utilizo VMware, pues bueno podemos generar una interconexión en el cual se podrá mantener híbrida y poder estar teniendo ambientes que generen una coexistencia completa, coexistencia parcial, es decir, aplicaciones que dependan de un ambiente on premise con la nube y a través de VMware, por ejemplo VMware Cloud te permite estar haciendo ese movimiento donde puedas estar llevándote instancias que tienes de manera local, lo llevas hacia la nube, la regresas o inclusive voy a poner ejemplo que sabes que mi aplicación todos los días los cierres de mes tiene mucho, mucha, mucha demanda pero los demás días no llegan ni al 20% de uso, entonces es donde puedes decir sabes que todo el resto del mes que no tiene tanto uso lo mantengo en mi ambiente local y la finalización del mes lo puedo llevar hacia la nube y crezco diez veces el poder de cómputo, por mencionar un ejemplo, porque cuando estamos de manera local tenemos esa limitante que podemos crear las máquinas virtuales al máximo que nos dé el hardware disponible en la nube de AWS, tú podrías provisionar conforme tú lo vayas a necesitar. Entonces ese sería un ejemplo de cómo a través de VMware Cloud en AWS puedes estar administrando diferentes instancias, servidores, entornos virtuales y a través de una plataforma y poder estar moviendo escalas de la nube de AWS hacia VMware o de VMware hacia hacia AWS. Y por ejemplo, uno de los casos que sería también es hablar de un tema de servicios administrados que está dentro de RDS. ¿Que tiene que ver un tema de Aurora DB? ¿Donde le pasó los micrófonos a mi compañera Daniela?
Bueno, estamos ahora en uno de los últimos puntos. ¿Cuál es? Es una base de datos relacional compatible con MySQL y con Postgres, creada para la nube, la cual combina el rendimiento y la disponibilidad de las bases de datos de datos tradicionales con una simplicidad y rentabilidad de las bases de datos de código abierto. Esta Aurora DB se divide en una administrada y en una Aurora Serverless. En el caso de la Aurora Serverless, bueno, Amazon Aurora Serverless es una configuración de escalado automático bajo demanda para Amazon Aurora, en la que la base de datos se inicia, se cierra y se escala automáticamente. La capacidad en función de las necesidades de la aplicación, es decir, le permite ejecutar su base de datos en la nube sin necesidad de administrar ninguna instancia de base de datos, a su vez que ofrece una opción rentable y simple para las cargas de trabajo poco frecuentes, intermitentes o impredecibles. Los beneficios de migrar a AuroraDB son los La compatibilidad con migraciones. Debido a la compatibilidad con MySQL y con Postgres, Aurora es un destino interesante para las migraciones de base de datos a la nube, además de que permite la integración de herramientas para lograr un proceso seguro con tiempo de inactividad mínimo, alto rendimiento y escalabilidad. Esto se debe a que cuentan con un rendimiento 5 veces superior a MySQL SQL y 3 veces superior al de Postgres. Este rendimiento es equiparable a las bases de datos comerciales, pero con el costo de una décima parte. Además de lo anterior, Aurora permite ajustar el tamaño de las instancias según sus necesidades o bien permitir que Aurora Serverles se encargue del escalado automáticamente. Completamente administrado Aurora está completamente administrado por Amazon RDS y no tiene que preocuparse por las tareas de administración de bases de datos como el aprovisionamiento de hardware, parches de software, instalación, configuración y copias de seguridad. Alta disponibilidad y durabilidad Amazon Aurora está diseñado para ofrecer una disponibilidad superior al 99,99% dado que replica seis copias de datos en tres diferentes zonas de disponibilidad y realiza copias de seguridad constantemente, como bien mencionaba la compatibilidad con MySQL y con Postgres. El motor de base de datos Amazon Aurora es totalmente compatible con bases de datos de código abierto como son los antes mencionados, además de que incorpora compatibilidad con lanzamientos nuevos periódicamente. Y por último el alto nivel de seguridad Amazon Aurora ofrece varios niveles de seguridad para la base de datos, se incluye el aislamiento de red por medio de Amazon VPC, el cifrado en reposo mediante claves que se pueden crear y controlar a través de ciertos servicios de AWS y el cifrado de datos en tránsito como el certificado SSL.
Gracias Daniela, bueno en conclusión en cuanto a temas de migración como lo hemos venido platicando, podemos llegar a hacer la migración ya sea total, parcial o mantener una estrategia totalmente híbrida o 100% nativo a la nube, no importa en donde te encuentres, hoy en día si sabes que tengo mi servidor cubicado por una cubicación físico, podemos estar migrando pero tengo varias aplicaciones, no necesitas migrar todas las aplicaciones, podremos ir tema si hoy en día trabajas en hosting, si trabajas en alguna otra nube que también hoy en día se puede volver una estrategia este de tail, tener escenarios multinube que si sabes que ciertas aplicaciones la voy a tener en tal nube y quiero migrar otras, estas otras aplicaciones a la nube de AWS, se vuelve también una buena práctica tener estrategia multinivel nube en el cual nosotros podemos migrar las aplicaciones, bases de datos, tus worlos que corran en cualquier otra nube desde un tema on premise. El tema de on premise es importante también mencionar que no importa Si ahorita trabajas 100% con servidores físicos, tienes ambientes virtuales como VMware, Hyper V o algunos otros fabricantes, no importa si cualquiera de los dos es un ambiente virtual físico, podemos realizar la migración sin ningún inconveniente, así como la migración de tus bases de datos. Si hoy en día trabajas con servicios más sistemas operativos, Windows, Linux, en sus diferentes distribuciones, también podemos llegar a generar dicha migración y poder levantarte la infraestructura hacia la nube de AWS, dependiendo desde cualquier parte donde vengas. Lo importante es de que todo a través de conclusión, a través de la mejor práctica de las etapas de migración que manejamos, a través de tu estrategia de migración que estaremos generando y sobre todo utilizando la herramienta correcta, porque como lo comentaba mi compañera Daniela, tenemos diferentes herramientas para cada escenario. Mezclándose esos puntos, podemos llegar a generar una transición totalmente transparente hacia la nube de AWS como tal. Y que lleves tu camino hacia la nube, ya sea tanto paulatinamente a través de una estrategia, a través del tiempo, que reitero, no necesariamente tiene que ser ahorita 100% toda la nube, es un tema de ir poco a poco ir generando la nube. Y pues bueno, la tendencia está la migración para la nube.
Y bueno, complementando está ¿Qué estás haciendo tú? ¿Qué estás haciendo tú para apoyar a tu negocio con esta transformación digital? ¿Qué proceso estás llevando a cabo? ¿Qué nuevas tecnologías estás implementando? Esta es una manera de poder llevar como tu empresa, como una estrategia competitiva. ¿De qué manera puedo ahorrar que lo pueda implementar a otras cosas que me puedan ayudar a tener un mayor beneficio hacia la empresa o hacia el cliente final? Estas son algunas estadísticas que muestran que tener la nube de Adobe beneficia a las empresas de muchas maneras. Una es optimización de costos, otra es optimización de tiempo, ya que muchas veces los ingenieros en vez de estar en la administración de infraestructura, se pueden enfocar en otros temas. Ahora bien, pues agradezco a mis compañeros, espero que este tema haya sido de mucho interés para ustedes y quisiéramos saber si tienen alguna pregunta, alguna duda sobre lo ya aquí presentado o que ustedes tengan como que ya estén trabajando en algún proyecto, con todo gusto los podemos contestar. Por favor, si nos puedan mandar sus preguntas por medio del chat para poderles dar respuesta.
Cualquier duda, pregunta que tengan, con todo gusto pueden escribirla en el chat y le daremos.
Bueno, espero que todo haya quedado muy claro, les agradecemos a todos su asistencia. De igual manera nosotros le haremos llegar lo que es la presentación y la grabación del mismo. Y pues aquí quedan nuestros teléfonos, nuestros correos, por si tienen alguna duda o alguna solución en específico que quiera revisar. Estamos con todo gusto a sus órdenes y pues muchísimas gracias por estar el día de hoy.
More from Paulina

Todo sobre la Nueva Región de AWS en México | Beneficios, Infraestructura y Migración

DEMO: De VMware a AWS. Administración de ambientes dentro de la consola de AWS.








