¿Por qué algunas personas son reticentes o no quieren implementar sus aplicaciones en Google Cloud Platform incluso si es más conveniente y los datos involucrados no son confidenciales?

No creo que pueda “convencerlos”, per se. A los programadores les lleva tiempo adoptar una plataforma en particular. Observe la cantidad de programadores que escriben C # y el Objetivo C. Estos dos lenguajes son completamente específicos de la plataforma y el argumento es que cuando se casa con la plataforma, habla el idioma de la plataforma. Para mí, un viejo, C ++ y C funcionan bien. Para que Google Cloud Platform sea popular, tiene que haber una demanda del consumidor para las aplicaciones. El soporte para desarrolladores nunca ha sido un punto fuerte de Google. De hecho, el soporte de cualquier tipo nunca ha sido fuerte … La única forma en que los desarrolladores acudirán a la nube de Google será una demanda de sus clientes … no contenga la respiración.

Desde una perspectiva de Google Fan boy, aquí están mis puntos clave:

Hosting + Compute Categoría:

1. GAE (Google App Engine): restricciones para el sistema de archivos, ancho de banda, CPU y memoria. Todas las transacciones finalizan si tardan más de 60 segundos o si tienen más de 128 o 256 MB de cuota de memoria. Debe usar el almacén de datos, que no es una base de datos relacional y no admite la declaración de unión.

Si un desarrollador invierte su tiempo y esfuerzo con GAE, será muy costoso debido a la curva de aprendizaje que tiene que lidiar con la restricción y modelar sus datos. Requeriría una razón sólida por la cual uno se sometería a GAE.

2. GCE (Google Compute Engine): si compara GCE con AWS (Amazon Web Service) en términos de simplicidad y configuración, GCE es, con mucho, el mejor debido a gcloud sdk (terminal + inicio de sesión de Chrome) y velocidad.

No importa cuán impresionante sea su nube si la factura que le cobran por sus dos redes de ingreso a Internet vale “$ 1,128.12 y $ 105.65” por mes. No veo ninguna razón por la que deba quedarse.

Entonces, en 2008, apareció Google App Engine (GAE), que fue el comienzo de Google al alojar su código en su nube (o como a Google le gusta llamarlo ahora Google Cloud Platform)

GAE ha estado fuera durante 76 meses, la mayor parte del tiempo fue un Python & java PaaS con una base de datos (Google Datastore). Eso es una gran cantidad de bloqueo y límites para la mayor parte de la vida de GAE. Muchos desarrolladores alcanzarían límites muy rápidamente tratando de construir algo o no entenderían por qué Google lo diseñó de la manera en que lo hicieron. Después de aproximadamente 2013, Google Cloud Platform podría hacer muchas más cosas y tiene muchas bases de datos y formas de construir cosas. Pero eso es solo 22 meses.

Podemos decir que Google solo tenía un producto para cubrir cualquier tipo de producto que intenta construir desde 2013, y solo se ha vuelto súper agresivo con los precios desde 2014.

En este momento, muchos desarrolladores ya podrían haber creado un producto Amazon o Azure. Entonces, si lo harían nuevamente, ¿por qué elegirían Google Cloud Platform?

Elegí Google App Engine para FOOD en mi inicio, ya que quiero centrarme en construir nuestro producto y no en tratar con deudas técnicas, cuidar parches / servidores y crear solo cosas complejas de DevOps. Me encanta que Google App Engine elimine un proceso después de 60 segundos y todos los demás patrones que nos permiten escalar y lidiar con el diseño del código por adelantado y no más tarde.

Creo que Google tiene que pasar más tiempo hablando y mostrando a los desarrolladores y gerentes de desarrollo por qué deberían construir en Google App Engine, pero parece que en este momento pasan la mayor parte del tiempo hablando de Google Compute Engine. #GDE

Creo que uno de los conceptos de miedo es el bloqueo. Escribe código específico de la plataforma y le preocupa que se ejecute en otros entornos. Esta es una preocupación común y muy real.

Estamos tratando de abordar esto abrazando de todo corazón a Docker. Nos traes una imagen de Docker y simplemente se ejecuta. Esto le permite ejecutar una imagen de Docker localmente, en control de calidad y en nuestra plataforma de manera consistente. Luego puede elegir esa imagen y ponerla en AWS o Azure (suponiendo que sean compatibles con Docker para lo que parecen estar en camino).

Esto todavía te deja con bloqueo de datos. Es un problema. Pero nuestra esperanza sería que la escalabilidad y la amabilidad del desarrollador superaran esa preocupación.

¿Por qué no les preguntas y luego abordas sus preocupaciones?