¿Qué haría falta para que una empresa cambie a Google Compute Engine desde AWS?

Depende de qué tan profunda esté integrada la aplicación con AWS. En mi experiencia, la mayoría de los clientes de AWS usan EC2 (Servidores), S3 (Almacenamiento) VPC (Redes) y RDS (Bases de datos). Muy pocos clientes van más allá de estos componentes básicos para utilizar servicios como SQS, SNS, SES y SWF. Si la aplicación no consume las API expuestas por estos servicios, es bastante fácil migrar a GCE.

Aquí hay una guía de alto nivel sobre la migración de una aplicación web típica de 3 niveles de AWS a GCE:

  • Primero, cree un diagrama de implementación lógica de su aplicación en AWS. Identifique todos los componentes, incluidos los equilibradores de carga, las distribuciones de CDN, los depósitos de almacenamiento de objetos, los grupos de seguridad, los dispositivos de almacenamiento en bloque, las alertas de CloudWatch, los tipos de instancias RDS y los tipos de instancias EC2 que ejecutan los servidores web, de aplicaciones y db. Asegúrese de que refleje la instantánea actual de su implementación.
  • Si está utilizando VPC, capture todos los detalles, incluidas las subredes públicas y privadas, instancias NAT, puertas de enlace, ACL de red e IP elásticas.
  • Identifique los bloques de construcción equivalentes de Google Cloud Platform (GCP) para su implementación. Por ejemplo, asigne los tipos de instancia EC2 con los tipos de instancia GCE más cercanos. Como GCE es bastante nuevo, carece de componentes como herramientas de monitoreo. Haga una lista de servicios que no se pueden asignar a GCP.
  • Identifique las herramientas de terceros que pueden reemplazar los servicios específicos de AWS. Por ejemplo, Nagios o Ganglia proporciona métricas mucho mejores que CloudWatch.
  • Ahora que tiene una lista de todos los componentes, comience creando las redes en GCE. La topología y arquitectura de VPC se pueden emular estrechamente con la pila de redes GCE. Asegúrese de replicar los grupos de seguridad, las ACL de red, los enrutadores y las puertas de enlace en GCE.
  • Inicie las instancias simples de vainilla basadas en los tipos de instancias identificadas. Asociarlos con la topología de red creada en el paso anterior. Adjunte direcciones IP persistentes a instancias que necesitan una dirección IP pública. Al final de este paso, debe tener una implementación que se parezca mucho a su aplicación existente en AWS.
  • Configure cada instancia con el software esperado. Esto incluye instalar el software apropiado en cada servidor, incluidos los servidores web, los servidores de aplicaciones, las bases de datos, el almacenamiento en caché y otras dependencias. Por ahora, debe tener una implementación totalmente configurada sin la aplicación.
  • En el siguiente paso, mueva los directorios y la configuración de la aplicación de cada instancia de EC2 a la instancia de GCE correspondiente. Esto se puede hacer usando SCP o se puede mover a través de Google Cloud Storage. Configure cada instancia y pruébelas de forma independiente.
  • Migre la base de datos de RDS utilizando las herramientas de base de datos patentadas que admiten copia masiva. Dependiendo del tipo de base de datos, hay bastantes opciones para hacerlo.
  • Mueva todo el contenido estático de Amazon S3 a Google Cloud Storage.
  • Pruebe la aplicación y la conectividad entre todas las instancias.
  • Finalmente, agregue los servidores web públicos al equilibrador de carga GCE y pruébelo
  • Si todo va bien, cambie el DNS de su dominio para que apunte al equilibrador de carga en GCE.

GCE solo admite distribuciones de Linux (CentOS, Debian, SUSE y RHEL) en este momento. Si su aplicación se ejecuta en Microsoft Windows Server, no puede pasar a GCE.

Si su base de datos ejecuta MySQL, puede considerar migrar a Google Cloud SQL. Tenga en cuenta que el máximo. El tamaño de la base de datos admitida es de 100 GB.

Esta no es una guía completa, pero intenta describir los pasos clave involucrados en la migración de AWS a GCE.

Consulte una serie que estoy escribiendo actualmente en Google Cloud Platform para profesionales de AWS.

¡Espero que esto ayude!

Como Google tiene la infraestructura global y los bolsillos necesarios para competir con AWS, es probable que GCE se convierta en una opción seria para los clientes de AWS. Sin embargo, comparar las dos ofertas puede ser un desafío tanto en términos de precios como de rendimiento.
Los principales problemas a considerar antes de cambiar las nubes son los precios, el rendimiento, la disponibilidad y las regiones atendidas. La gran cantidad de servicios y productos de soporte de AWS también juegan un gran factor para decidir dónde implementar.

Examinemos una comparación de precios para GCE y EC2.

Diferentes cargas de trabajo para diferentes nubes.
La facturación por minuto de Google desempeña un papel importante en los precios más bajos de GCE para sus instancias bajo demanda. Sin embargo, no todas las cargas de trabajo se beneficiarán de la facturación de menos de una hora de GCE y, de hecho, pueden mejorar con EC2.
Aquí en Cloudyn echamos un vistazo a cómo funcionarían dos implementaciones de clientes en cualquier plataforma:
Cliente A
El cliente A normalmente ejecuta alrededor de 1000 m1.gran instancias, con un tiempo de ejecución promedio de ~ 40 minutos por instancia. Como estas instancias de EMR se están ejecutando con los precios bajo demanda de EC2, la facturación por minuto de GCE le ahorraría a la compañía ~ 40%.
Cliente B
La carga de trabajo del cliente B es muy similar. Su trabajo típico está en el rango de 80 minutos, y hay ~ 800 m1.gran instancias por trabajo. Pero usa el precio Spot de AWS, que es mucho más barato que GCE. En su caso, GCE en realidad será ~ 10% más caro, a pesar de la facturación de Google en menos de una hora. Un precio spot típico para m1.large instancia es ~ $ 0.12 / hora, que es mucho más bajo que $ 0.28 / instancia de GCE.
De los estudios de caso anteriores se desprende que para las cargas de trabajo que pueden usar el precio Spot, AWS es significativamente más barato. Además, AWS ofrece precios de instancias reservadas. Si bien esto requiere que se comprometa por adelantado a un año (como mínimo), las tarifas de precios reservados para EC2 son mucho más bajas que las tarifas de GCE.

¿Son suficientes las tarifas RI y Spot para mantener a los clientes con AWS?
El enfoque de Google en ofrecer precios a pedido más baratos es un ataque brillante a AWS en dos niveles. En primer lugar, las instancias reservadas y las instancias puntuales no son atractivas para los nuevos clientes que no están completamente familiarizados con los entresijos de AWS. Estos clientes no están preparados para comprometerse a largo plazo con AWS. Podría ser por esta razón que RI cayó un 9,4% en el mes de enero. Además, muchas compañías actuales ven los costos de RI como CapEx, lo que debilita la razón principal para pasar a la nube en primer lugar. Del mismo modo, las instancias Spot, aunque súper baratas, tienen limitaciones significativas ya que AWS puede desconectarse en cualquier momento.
Además, Google podría ofrecer su propia versión de precios reservados e instantáneos, eliminando totalmente la ventaja de AWS.

En Cloudyn, creamos estudios de comparación en la nube para nuestros clientes todo el tiempo. Te invitamos a visitar nuestro blog.

Lo simplificaré: eche un vistazo a Cloud Decision Engine (url: falta traducción: es. Tome la decisión correcta para su infraestructura de nube) e importe su rol de IAM desde AWS.

Verá directamente cuánto ahorrará al cambiar de AWS a GCP con la misma configuración exacta. Simplemente échale un vistazo:

  1. Tire de su inventario

2. Ver la infraestructura correspondiente en otros proveedores competidores

Fácil verdad?

No pierda el tiempo para comparar todas las ofertas y características técnicas a mano cuando pueda encontrar una herramienta gratuita para hacerlo por usted.

Asana funciona con AWS por ahora. Las cosas más importantes que me harían querer cambiar:

  • Mayor confiabilidad. Hay interrupciones ocasionales con AWS (como el mes pasado), y con el tiempo queda claro que Google tiene un mejor tiempo de actividad que AWS, eso valdrá mucho.
  • Mejor rendimiento, por ejemplo, a través de servidores colocados para reducir la latencia de la red. (Esto probablemente solo sea práctico para clientes muy grandes que hacen negocios a granel, pero una vez que haya un cliente de AWS o Compute Engine del tamaño de Facebook, los “colos virtuales” podrían convertirse en algo real).

Los mayores bloqueadores:

  • Amazon tiene muchos servicios administrados además de EC2, por ejemplo, RDS, Cloudwatch y ElasticCache. ComputeEngine tiene un largo camino por recorrer en términos de solo reducir la complejidad operativa de ejecutar un sitio web sofisticado, eficiente y confiable. (Y, de hecho, “ComputeEngine” incluso suena como si lo estuvieran comercializando más hacia big data que hacia sitios web orientados al usuario).
  • Tiempo / ejemplares de confianza. Cuanto más básica y “arraigada” sea una pieza de infraestructura, más sentido tendrá ser cauteloso al saltar sobre lo nuevo y caliente. Esto es lo más básico posible, por lo que llevará tiempo hacer que la gente se sienta cómoda. Afortunadamente, la marca de Google ayuda aquí.

Cosas como un menor costo y un mejor soporte podrían ser útiles para obtener nuevos clientes, pero dados los costos de cambio monetario e informativo de ir a un sistema totalmente nuevo, es poco probable que esas sean motivaciones para cambiar.