¿Es una buena práctica poner su base de datos y sitios en servicios en la nube?

Depende. Ir a “la nube” no lo liberará por completo de la necesidad de desarrollar una estrategia de alta disponibilidad para su mundo de aplicaciones.

Incluso si su base de datos está alojada por AWS en algo como Aurora o Amazon RDS, es posible que su propia aplicación tenga que lidiar con problemas de conmutación por error y reinicio de sesión. No tendrá que abrir manualmente las instancias esclavas, y se encargarán de la plomería de red, pero su aplicación aún debe ser resistente para reiniciarse (o un humano debe estar listo para reiniciar su aplicación).

Además, ir a la nube es un ejercicio bastante complejo y algo costoso, y requerirá rehacer no trivialmente los procesos internos y esas cosas.

Parece que está ejecutando un mundo de aplicaciones de misión crítica en un solo servidor. Es posible que desee investigar la construcción de un segundo servidor “esclavo” para su base de datos y realizar al menos algo de trabajo en la conmutación por error a nivel de aplicación.

La mayoría de los mundos de producción que he visto tienen al menos dos instancias de esclavo DB de cada “maestro”, y a menudo más: una para la conmutación por error, una segunda en caso de que ocurra la conmutación por error (por lo que puede desactivar la conmutación por error mientras “repara” el maestro cuadro), y a menudo otro más para copia de seguridad. También puede haber “esclavos de lectura” para informar y otros fines.

Si eres lo suficientemente inteligente, puedes hacer que la conmutación por error sea fluida y que tu aplicación no se dé cuenta o la haga de modo que rara vez pierda datos o sesiones web. Pero su aplicación tiene que ser creada para hacer esto, ya que es bastante difícil agregarla después del hecho.

Si le preocupan las horas o los días, y su problema comercial puede tolerar unos minutos de tiempo de inactividad, puede dejar su aplicación tal como está, pero también puede agregar uno o dos esclavos db en diferentes máquinas físicas. como una instancia de aplicación de respaldo. Usaría cambios de red internos para cambiar a esclavos o la instancia de la aplicación de respaldo.

Es posible que desee hacer esto de todos modos, ya que puede implementarlo en unos días o semanas, probablemente con su personal actual. La implementación en la nube llevará más tiempo y habrá un “período de transición” en el que puede necesitar que ambos entornos funcionen.

Es una buena práctica utilizar la infraestructura como se pretendía.

Es una buena práctica elegir una infraestructura que satisfaga las necesidades de la solución y las habilidades de la organización.

Con el apoyo adecuado de talento y liderazgo que podría ser AWS. Tengo cero problemas al usar AWS. También tengo cero problemas al usar la infraestructura en el sitio.

No poder encontrar el talento adecuado es la razón principal de la mayoría de las organizaciones por las que luchan con la tecnología. AWS no resuelve este problema de recursos humanos y liderazgo. A veces, usar AWS resaltará que una organización tiene estos problemas.

Por ejemplo, encuentro que las organizaciones que tienen administradores de sistemas talentosos que protegen su infraestructura de ingenieros menos talentosos luchan cuando se mudan a la nube. Las organizaciones que tratan a los ingenieros como productos básicos también parecen tener dificultades con las migraciones en la nube. Para mí, estos son específicamente problemas de liderazgo y no sobre las mejores prácticas.

Si su organización tiene interrupciones en el servicio que considera inaceptables, sospecho que su problema tiene más que ver con el liderazgo técnico que si está utilizando o no infraestructura en el sitio o en la nube. Con el liderazgo correcto, pasar a AWS podría ser un gran catalizador para el cambio. Con el liderazgo equivocado, pasar a AWS solo va a barajar los problemas existentes.

La respuesta de Bill Karwin habla bien de algunas de las diferencias más importantes entre el uso de la infraestructura en la nube y en el sitio.

Es una buena práctica equilibrar el rendimiento, la fiabilidad y las finanzas al tomar una decisión como esta.

Cosas para considerar:

• Costo: ¿cómo le cobra el proveedor de la nube? ¿Cuánto necesitas? ¿Cuánto vas a crecer?

• ¿Es esto más barato que alojarlo localmente?

Algunas cosas que SON una buena práctica:

Múltiples ambientes:

• Desarrollo
• Pruebas
• QA
• Producción

Muchos lugares no tienen todos estos entornos y son más o menos esenciales cuando se desea tener un entorno de producción confiable y transparente.

Podría alojar los entornos de desarrollo en estaciones de trabajo, pruebas locales, control de calidad y producción en la nube.

No hay una sola forma de hacer las cosas, pero la nube tiende a ser barata y confiable, siempre que la aproveches adecuadamente.

Solo sé un poco sobre la nube nativa.

ZTE proporciona un servicio de arquitectura de red de núcleo 5G nativo en la nube .

En el diseño de la arquitectura del sistema, la red central 5G debe considerar tanto la estabilidad de las necesidades de las aplicaciones de telecomunicaciones, como también la introducción de una gran cantidad de aplicaciones en el campo de TI para lograr sus propias ideas para optimizar la transformación.
La solución ZTE NFV es Cloud Native. Puede ayudar al operador a construir una red en la nube innovadora basada en el marco de microservicio y proporcionar API abiertas para integrarse con terceros para desarrollar nuevos servicios.

Hay un par de formas de manejar esto. En primer lugar, puede activar sus propios servidores AWS, instalar su base de datos de elección y cargar sus datos en ellos. Depende de usted gestionar la disponibilidad, es decir. haga girar un maestro y un esclavo y asegúrese de que los datos se replican entre ambos. También puede ir un poco más allá y tener múltiples bases de datos en múltiples regiones para la redundancia geográfica.

Si desea que alguien administre la disponibilidad de su (s) base (s) de datos, querrá consultar un servicio de base de datos administrado como AWS RDS (Amazon Relational Database Service (RDS) – AWS) Pagará una prima, pero Amazon buscará aprovisionamiento después de la instancia, configuración de la base de datos, parches y copias de seguridad.