Para una migración completa, esto es lo que haría. Tenga en cuenta que esto solo cubre los datos de análisis y no otras características como las notificaciones push.
1. Decida si va a utilizar una base de datos relacional (es decir, mysql. MSSQL, etc. o una base de datos de documentos (es decir, MongoDB). Debe comprender los pros y los contras de ambas opciones. Si está utilizando objetos json, probablemente quiera mongo.
2. Hágase las siguientes preguntas:
A. ¿Cuántas solicitudes por segundo debo manejar?
B. ¿Quiero la capacidad de ampliar o ampliar?
C. ¿Deseo redundancia en los centros de datos?
D. ¿Cómo manejo las copias de seguridad?
E. ¿Cómo debo monitorear la carga y los errores? ¿Debo habilitar el escalado automático?
F. ¿Necesito almacenamiento de blobs?
- Cómo establecer un límite mensual en Amazon Web Services
- ¿Cuál es la mejor empresa de alojamiento en la nube en la India?
- ¿Cuál es la importancia de que AWS ofrezca directamente servicios gestionados?
- ¿F5 está en la nube? ¿O debería ir con ALB / ELB?
- Cómo elegir el mejor plan de alojamiento web para mi sitio web
3. Cree su nueva arquitectura de hardware utilizando proveedores en la nube como Azure, Amazon, Rackspace o quizás digitalocean si quiere ensuciarse las manos. O coloque sus propios servidores, firewall, equilibrador de carga y discos redundantes. La arquitectura del software debe incluir una api json de descanso seguro que solo permita el acceso a nivel de usuario. No puede enviar una contraseña a través de texto sin formato, incluso a través de SSL, por lo que debe leer sobre las mejores prácticas para proteger sus datos de usuario. Probablemente también desee integrarse con SSO para Facebook y Twitter.
4. Desarrolle su administrador de datos en sus plataformas móviles. Esto se comunicará con su nueva API REST json. Intente imitar la API existente que usa para mantener los cambios de código al mínimo.
5. Haga que funcione de extremo a extremo desde su aplicación móvil localmente.
6. Pruebe su arquitectura de carga para asegurarse de que esté a la altura de sus requisitos de solicitudes por segundo.
7. Intente escalar y escalar para detectar posibles problemas.
8. Pruebe la restauración desde la copia de seguridad.
9. Asegúrese de tener una manera de monitorear su nueva arquitectura en busca de problemas y estadísticas.
10. En su nuevo backend, desarrolle una función que se conecte para analizar, tome los datos de los usuarios y los migre a su nueva infraestructura. Realice un seguimiento de los usuarios que han migrado.
11. En su dispositivo móvil, en su nuevo administrador de datos, debe haber una función para determinar si el usuario que ejecuta su aplicación ha migrado. Cuando su aplicación se inicia por primera vez, debe verificar si el usuario ha migrado. Puedes decidir si forzarlo o no. Al migrar, la aplicación debe volver a llamar a su servicio REST para solicitarle que migre al usuario. El servicio de backend debe realizar las llamadas nesassary para analizar para obtener los datos de los usuarios, llenarlos en la nueva base de datos que creó y marcar al usuario como migrado para que la aplicación no moleste al usuario en el futuro.
12. Empuje su nueva aplicación móvil a la tienda de aplicaciones.
13. Monitorear el progreso de la migración.
14. Después de unos meses, decida qué hacer con los usuarios que no han migrado. Si puede degradar a la cuenta gratuita en análisis en este punto, probablemente dejaría los datos allí. Si tiene habilitadas las notificaciones automáticas en su aplicación o ha incorporado un interruptor de apagado para forzar a un usuario a actualizar, ahora es el momento de encenderlo.
Como puede ver, es mucho trabajo y costará más. También hay ciertamente problemas desconocidos con los que te enfrentarás y que no he enumerado aquí. Siempre es más fácil construir algo como esto al principio en lugar de cambiar. La migración de usuarios nunca es fácil y en el mundo de las aplicaciones, a diferencia de la web, no hay garantía de que sus usuarios actualicen a la última versión de su aplicación. ¡Buena suerte!
