
- Descompusimos una aplicación monolítica masiva respaldada por Oracle 11g/12c en 25 esquemas alineados con microservicios y migramos todo a Oracle 19c en RDS, dando a cada servicio su propio límite de rendimiento y escalabilidad.
- Lo que más me gusta de RDS es que ya no necesitamos dedicar mucho tiempo a tareas manuales pesadas: parches, copias de seguridad automatizadas, restauraciones en un punto en el tiempo (hasta el segundo) e incluso aprovisionamiento. Tareas como estas solían llevar semanas, involucrar múltiples reuniones y requerir ciclos de aprobación, pero ahora están completamente automatizadas y ocurren en segundo plano con solo una configuración simple.
- Los desafíos de recuperación y conmutación por error que enfrentábamos anteriormente con nuestro monolito han sido completamente eliminados. Al aprovechar la replicación automática y sincrónica de Amazon RDS y las capacidades de conmutación por error Multi-AZ, hemos ganado un nivel de resiliencia que promete que nuestra aplicación se mantenga en línea incluso durante una interrupción completa de la Zona de Disponibilidad. Con un tiempo de actividad del 99.95%, somos mucho más que solo resilientes (en un escenario de conmutación por error en el peor de los casos, la transición ocurre en aproximadamente 2 minutos, lo cual está bien dentro de nuestro RTO aceptable).
- Gestionar 25 microservicios y sus conjuntos de datos en rápida expansión no parece ser un desafío para nosotros, y nuestras operaciones se han simplificado con su implementación basada en configuración. Con RDS, tenemos la opción de escalar almacenamiento sin problemas, actualizar tipos de instancia y aprovechar réplicas de lectura para descargar tráfico. Esta flexibilidad ha sido una piedra angular de nuestro viaje de migración, brindando ahorros significativos en costos y eficiencia operativa.
- Tenemos la opción de detener instancias de RDS de entornos inferiores durante los fines de semana o cuando no están en uso, ahorrando costos adicionales.
- AWS, como siempre, tiene un soporte al cliente de primera clase para RDS. Reseña recopilada por y alojada en G2.com.
- Pasar de on-prem a RDS rompió nuestra integración profunda con New Relic; debido a que ya no tenemos acceso a nivel del sistema operativo para instalar agentes personalizados, perdimos la capacidad de realizar un monitoreo granular a nivel de tabla del que dependíamos para la optimización del rendimiento heredado.
- Observamos que la base de datos se queda atascada en el estado de Actualización/Modificación durante las modificaciones y realmente no tenemos ninguna forma de verificar el problema real más que esperar. A veces, nos quedamos solo con reiniciar lo mismo, lo cual es bastante tedioso a veces. Esto realmente necesita algo de atención por parte de AWS; nosotros, los usuarios, necesitamos visibilidad sobre el progreso.
- Los permisos SYSDBA están restringidos, pero eso no es un obstáculo. Reseña recopilada por y alojada en G2.com.
Nuestra red de Iconos son miembros de G2 reconocidos por sus destacadas contribuciones y compromiso para ayudar a otros a través de su experiencia.
El revisor subió una captura de pantalla o envió la reseña en la aplicación, verificándolos como usuario actual.
Validado a través de LinkedIn
A este revisor se le ofreció una tarjeta de regalo nominal como agradecimiento por completar esta reseña.
Invitación de G2. A este revisor se le ofreció una tarjeta de regalo nominal como agradecimiento por completar esta reseña.
Esta reseña ha sido traducida de English usando IA.




