En Cloud Run, App Engine, GKE y Compute Engine, tienes varias opciones para los servidores web y de apps. Echa un vistazo a dónde deberías ejecutar tus creaciones para obtener más detalles.
Sin servidores: Si tienes un equipo de desarrolladores, te conviene que se concentren en la codificación y no en las tareas de infraestructura y escalamiento. Cloud Run y App Engine serían excelentes elecciones. Ambas opciones funcionan sin servidores y escalan de bajo a alto tráfico según sea necesario. Si quieres ejecutar contenedores sin servidores para arquitecturas de microservicios web y basadas en eventos, te recomendamos usar Cloud Run. Cloud Run debería funcionar bien en la mayoría de los casos de uso, pero puedes echarle un vistazo a App Engine si estás desarrollando sitios web con hosting de archivos estáticos integrado.
Google Kubernetes Engine (GKE): Si quieres ejecutar apps en contenedores con más opciones de configuración y flexibilidad, puedes usar GKE. Ayuda a implementar apps en contenedores de manera sencilla con Kubernetes, y te brinda control de la configuración de los nodos. Escalar también es fácil: puedes definir el número de nodos a los que escalar a medida que aumenta el tráfico. A su vez, GKE ofrece autopiloto si necesitas flexibilidad y control, pero tienes operaciones y soporte de ingeniería limitados.
Compute Engine: Compute Engine es otra opción de máximo control. Se trata de máquinas virtuales (MV), por lo que puedes definir la configuración de tus máquinas con precisión dependiendo de la cantidad de memoria y CPU que necesites. Sin embargo, este nivel de control implica una mayor responsabilidad de tu parte a la hora de escalar, administrar, corregir y mantener las MV según sea necesario. Compute Engine funciona bien para apps antiguas con necesidades específicas y en situaciones en las que es absolutamente necesario tener un control total.
Base de datos
Por supuesto, foo.com necesita una o más bases de datos para almacenar información. Puede tratarse de una base de datos relacional o no relacional, según el tipo de datos y el caso de uso. (Para obtener lineamientos más detallados sobre cómo elegir la base de datos correcta para tu caso de uso, echa un vistazo a Tus opciones de bases de datos de Google Cloud.)
Las bases de datos relacionales de Google Cloud incluyen Cloud SQL y Cloud Spanner, y ambas son administradas.
Cloud SQL es ideal para cubrir necesidades genéricas de SQL (MySQL, PostgreSQL y servidor SQL).
Spanner es mejor para bases de datos relacionales gigantescas que necesitan escalabilidad horizontal. (Con “gigantesco”, nos referimos a miles de escrituras por segundo y cientos de miles de lecturas por segundo, a la vez que se brinda soporte a transacciones ACID.)
Para bases de datos no relacionales, Google Cloud cuenta con tres opciones principales: Firestore, Bigtable y Memorystore.
Firestore es una base de datos de documentos sin servidores que brinda coherencia sólida, es compatible con transacciones ACID y ofrece resultados rápidos a consultas complejas. También es compatible con datos y sincronizaciones sin conexión, por lo que es una gran opción para casos de uso móviles, así como aquellos vinculados con la Web, la IoT y los videojuegos.
Bigtable es una base de datos NoSQL de columnas anchas, compatible con lecturas y escrituras pesadas con una latencia extremadamente baja. Es la opción ideal para eventos, datos de serie temporal de dispositivos de IoT, datos de flujo de clics, eventos de anuncios, detección de fraude, recomendaciones y otros casos de uso relacionados con la personalización.
Memorystore es un servicio de almacenamiento de datos en una memoria, completamente administrado para Redis y Memcached. Es ideal para almacenamiento temporal y en caché de base de datos.
Balanceo de cargas and escalamiento
A medida que aumente el tráfico, deberás escalar los servidores web y de apps. Y a medida que aumente el número de servidores, necesitarás un balanceador de cargas para guiar al tráfico a los servidores web y de apps. Cloud Load Balancing es un sistema definido por software y completamente distribuido que se basa en direcciones IP anycast. Esto implica que puedes configurar tu frontend con una sola dirección IP. También es global, por lo que puede brindar contenido a tus usuarios tan cerca de ellos como sea posible y responder a un millón de consultas por segundo. Puedes configurar decisiones de enrutamiento basadas en contenido según atributos como el encabezado HTTP y el identificador de recursos uniforme. A su vez, ofrece balanceo de cargas integral para los servidores de apps internos, de manera que puedas dirigir el tráfico a cada uno de ellos según sea necesario.
Red de distribución de contenidos (CDN)
Los archivos estáticos no suelen cambiar, por lo que se utiliza la CDN para almacenar esos archivos en caché y ponerlos a disposición desde la ubicación más cercana al usuario, lo que ayuda a disminuir la latencia. Con el balanceador de cargas, tienes la opción de habilitar Cloud CDN para almacenar en caché aquellos medios solicitados con mucha frecuencia y el contenido web en la periferia de la ubicación más cercana al usuario. Esto reduce la latencia y optimiza el rendimiento en las últimas etapas. También ayuda a ahorrar en costos, ya que se atienden las solicitudes en la periferia para que no sea necesario que las administre el backend.
Almacén de objetos
Todos los archivos estáticos de foo.com, como los archivos de medios y las imágenes, así como CSS y JavaScript, pueden almacenarse en un almacén de objetos. En Google Cloud, Cloud Storage es el almacén de objetos indicado para cubrir tus necesidades a corto y largo plazo.
Funciones sin servidores
Digamos, por ejemplo, que foo.com también está disponible en dispositivos móviles, donde se necesita que las imágenes se muestren en formato más pequeño. Puedes separar estas funcionalidades del servidor web y convertirlas en funciones como servicio con Cloud Functions. Este abordaje también te permite aplicar tu lógica de redimensionamiento de imágenes a otras apps. Puedes activar la función sin servidor tan pronto como se agregue un archivo Cloud Storage y convertir el archivo a múltiples formatos, para luego guardarlos de nuevo en el almacenamiento, donde los utiliza el servidor web. También puedes usar funciones sin servidores para otros casos de uso, como la búsqueda de direcciones, los chatbots y el aprendizaje automático, entre otros.
Eventos
Es posible que en ciertas situaciones foo.com necesite enviar mensajes, notificaciones al usuario o eventos entre varios microservicios. En esos casos, se puede utilizar un servicio de mensajería asíncrono, como Cloud Pub/Sub, para enviar notificaciones a un tema y hacer que otros servicios suscriban a ese tema y tomen las medidas apropiadas de manera asíncrona.
Análisis de datos
Las apps como foo.com generan datos en tiempo real (por ejemplo, los datos sobre el flujo de clics) y datos en lote (por ejemplo, los registros). Es necesario ingerir, procesar y preparar esos datos para los sistemas descendentes en el almacén de datos. Desde allí, los analistas de datos, científicos de datos e ingenieros de AA pueden analizarlos para obtener información y hacer predicciones. Puedes ingerir lotes de datos con Cloud Storage o BigQuery y datos en tiempo real de la app con Pub/Sub, así como escalar a la ingesta de millones de eventos por segundo. Dataflow, basado en el modelo de código abierto Apache Beam, se puede usar para procesar y enriquecer los datos en lote y de transmisión. Si te encuentras en el ecosistema Hadoop, puedes usar Dataproc para tareas de procesamiento. Es una plataforma administrad de Hadoop y Spark que te permite concentrarte en el análisis de datos, en lugar de preocuparte por administrar y poner en marcha tu clúster de Hadoop.
Para almacenar los datos procesados, se necesita un almacén de datos. BigQuery es un almacén de datos sin servidores que es compatible con consultas SQL y puede alcanzar hasta un petabyte de almacenamiento. También funciona como un almacenamiento y data lake a largo plazo junto con Cloud Storage. Puedes usar datos de BigQuery para crear un panel de control en Looker y Data Studio. Con BigQuery ML puedes crear modelos de AA y hacer predicciones con consultas estándar de SQL.
Aprendizaje automático
Puedes utilizar BigQuery en tus proyectos de AA/IA para entrenar modelos en Vertex AI. Tus conjuntos de datos multimedia, imágenes y otros archivos estáticos de Cloud Storage pueden importarse directo a Vertex IA. Puedes crear tu propio modelo personalizado o utilizar modelos preentrenados. Es una buena idea comenzar con un modelo preentrenado y ver si funciona. Los casos de uso más comunes están cubiertos (imágenes, texto, video y datos tabulares). Si un modelo preentrenado no funciona para tu caso de uso, puedes usar el modelo de AutoML en Vertex AI para entrenar un modelo personalizado con tu propio conjunto de datos. AutoML es compatible con los casos de uso más comunes y no necesita código. Si tienes mucha experiencia interna en AA y ciencia de datos, tal vez decidas escribir el código de tu propio modelo personalizado en el framework que prefieras. Hablaremos más sobre este tema en la próxima entrada.
Operaciones
En foo.com necesitamos un seguimiento integral para asegurarnos de que los servidores y cada elemento de la arquitectura funcionan correctamente. La suite de operaciones de Google Cloud cuenta con todas las herramientas necesarias para registras, supervisar, depurar y solucionar problemas en tu app e infraestructura.
DevOps
También debes asegurarte de que los equipos de desarrollo y operaciones de foo.com tengan el acceso y las herramientas indicados para desarrollar e implementar la app. A medida que los desarrolladores escriben el código de la app, pueden utilizar Cloud Code dentro del IDE para enviar el código a Cloud Build, que luego lo empaqueta y lo prueba, ejecuta escaneos de vulnerabilidad en el código, invoca autorización binaria para comprobar si hay imágenes de contenedor de confianza y, una vez superadas las pruebas, implementa el paquete para la etapa de pruebas. A partir de allí, puedes crear un proceso de revisión y pasar a la producción. Las imágenes del contenedor se almacenan en Artifact Registry, desde donde se las puede implementar en GKE o Cloud Run. Las imágenes de Compute Engine se almacenan en tu proyecto.
Seguridad
foo.com necesita seguridad en torno a los datos, la app, los usuarios e identidades, la infraestructura y el cumplimiento. Hablaremos en detalle sobre este tema en otra entrada.
Conclusiones
Esta es una de las maneras de desarrollar una app web como foo.com en Google Cloud. Es un punto de partida, pero las posibilidades a partir de allí son infinitas. ¿Quieres dar tus primeros pasos en el desarrollo de sitios web en Google Cloud? Echa un vistazo a estos recursos. Para obtener más contenido sobre #GCPSketchnote y la nube, sígueme en Twitter @pvergadia y no dejes de ver thecloudgirl.dev.
