GCP archivos - CloudArch

Deploy your first computing cloud service

joaquinjimenezgarcia — Tue, 09 Apr 2024 19:54:13 +0000

Have you already coded a service and you are not sure where to deploy it? You can use Google Cloud Platform to deploy your first computing cloud service!

Let’s imagine you have your service written in Python using Flask (this doesn’t really matter, is just an example and can actually be replicated for every other language).

from flask import Flask
 
app = Flask(__name__)
 

@app.route('/')
def hello_world():
    return 'Hello World'
 
if __name__ == '__main__':
    app.run()

Requirements

The next thing we would need is to create then a Dockerfile, but why? Well, dockerizing our service will help us to use any of the services available in GCP which can run Docker containers, mainly Cloud Run and Kubernetes. But in this case we will be using just Cloud Run since it will work out of the box and we won’t need to configure any subnetwork neither other services to expose externally our application.

FROM python:3.11

RUN pip install gunicorn
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
ENV PORT 8080

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 app:app

Once we have our Dockerfile ready, we will just need to create the image based on that definition containing our service:

$ docker build -t  .

Pushing to the Cloud

Next, make sure you have Compute and Artifact APIs in GCP enabled and create a repository in Artifact Registry where we would push our image that we just created from that Dockerfile.

When we already have the repository created in Artifact Registry, is time to push our image!

# Tagging the image so we can reference it
$ docker tag SOURCE-IMAGE LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

$ Pushing the image to the repository
docker push LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

Afterwards you should see your image in the repository:

Creating our service

Now we are ready to deploy our service! Go to Cloud Run section and create a new service. It’s very important that you give it a meaningful name, since the URL to access it will include that name. Mark the source as “Artifact Registry” and in the select box look for the docker image you just uploaded.

A few good recommendations will be:

Allocate the CPU only during requests.
Allowing invocations without autintication and expose it to everyone (in case you want to have an internet facing service, otherwise expose it only internally and requiring authentication).
Use first generation of CPU and disable the option to have boost CPU to save some money.
Declare the same port we declared on Dockerfile and assign optimized resources to not have to over pay at the end of the month.
Limit the number of instances to not have multiple CPU consuming money.

If we followed all the previous steps in order, most probably your new instance has already spined up and you have now your service in production! You will be given a dedicated URL using HTTPS and you will see some insightful dashboards to see the metrics of your service

If you want to learn more about Cloud Run and how to optimize your services, don’t hesitate to consult our section where I talk more deeply about this service.

Leave me your comment below!

La entrada Deploy your first computing cloud service se publicó primero en CloudArch.

Multidimensional Autoscaler in GKE

joaquinjimenezgarcia — Fri, 01 Mar 2024 16:21:07 +0000

In a previous post we saw the differences between horizontal scaling and vertical scaling in Kubernetes. But thanks to Google’s implementation of Kubernetes with GKE we can enjoy a third type of scaling: Multidimensional scaling in GKE.

To avoid having to configure two different types of scaling, Google offers us a new type of scaling for its multidimensional GKE applications; that is, you can use CPU-based horizontal scaling and memory-based vertical scaling at the same time. A MultidimPodAutoscaler object modifies memory requests and aggregates replicas so that the average CPU usage of each replica matches the target usage.

However, if we have a Standard cluster (and not Autopilot) we will also have to enable the automatic vertical scaling settings first; since in Standard clusters it is disabled by default.

An example implementation would look like this:

apiVersion: autoscaling.gke.io/v1beta1
kind: MultidimPodAutoscaler
metadata:
  name: php-apache-autoscaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  goals:
    metrics:
    - type: Resource
      resource:
      # Define the target CPU utilization request here
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  constraints:
    global:
      minReplicas: 1
      maxReplicas: 5
    containerControlledResources: [ memory ]
    container:
    - name: '*'
    # Define boundaries for the memory request here
      requests:
        minAllowed:
          memory: 1Gi
        maxAllowed:
          memory: 2Gi
  policy:
    updateMode: Auto

As can be seen, it introduces a new unique GKE object type (offered only by Google) called “MultidimPodAutoscaler” and allocates a minimum and maximum number of replicas; and a minimum and maximum memory to keep the average CPU usage at 60% usage.

If you want to know more about this kind of autoscaler, I invite you to take a look into official Google documentation.

La entrada Multidimensional Autoscaler in GKE se publicó primero en CloudArch.

Escalado automático vertical y horizontal

joaquinjimenezgarcia — Wed, 21 Feb 2024 18:53:34 +0000

Ya hemos hablado en un artículo anterior de los beneficios del escalado automático en Kubernetes y en qué consisten exactamente. Sin embargo, no dijimos cuáles son los tipos existentes cuándo trabajamos con Kubernetes. Pueden ser escalado automático vertical y horizontal. Se puede usar uno o ambos a la vez, ya que ambos presentan funcionalidades diferentes.

Escalado automático vertical

El ecalado automático vertical nos permite poder usar en nuestros pods más CPU y memoria de los declarados originalmente cuándo sea necesario.

Este analizará los recursos de CPU y memoria que están siendo utilizados por los pods y podrá escalarlos para más o para menos en base a sus valores, siempre y cuándo estén dentro de los márgenes especificados en el fichero de configuración.

Sin embargo, por defecto Kubernetes no es capaz de asignar más memoria y CPU a un pod que ya está sirviendo tráfico. Por esto, para lograr este efecto, Kubernetes deberá terminar el pod que requiere una re-asignación de recursos y traer uno nuevo con los valores deseados.

Para más información, puedes visitar la web oficial de Google

Escalado automático horizontal

Aunque este también se base en los recursos de memoria o CPU utilizados para escalar, no añadirá más recursos a un pod existente. En su lugar, creará más pods para formar conjunto más grande y que las peticiones se puedan repartir mejor entre todos, asumiendo cada uno de ellos una carga mucho menor.

Este cambia la forma de tu carga de trabajo mendiante el auoento o la diminición automáticos de la cantidad de Pods. También se puede hacer en función de métricas personalixadas o métricas externas de fuentes fuera del clúster.

El valor de la CPU y memoria para saber si escalar se calcula mediante el uso promedio como un porcentaje de las solicitudes. De modo que si especificamos un valor de “80” para la CPU, el escalador automático analizará el uso de CPU de todos los Pods para que cuándo este uso promedio suba de 80% creará más pods hasta mantener la media según lo requerido.

Sin embargo, si ya tienes un escalador de carga automático vertical, se recomienda que uses otro tipo de métricas y no CPU y memoria ya que el vertical ya está usando estos valores.

Para más información, puedes visitar la web oficial de Google

La entrada Escalado automático vertical y horizontal se publicó primero en CloudArch.

Tags en CloudRun: por qué eliminar los que no se usen

joaquinjimenezgarcia — Mon, 12 Feb 2024 15:44:29 +0000

Acabas de desplegar tu una nueva revisión de tu servicio en CloudRun, le asignas los tags en CloudRun, miras las gráficas para asegurarte de que todo está bien y la aplicación responde eficientemente y, ¡qué sorpresa! Pese a que en el yaml de configuración indicas que deberían de provisionarse entre 2 y 3 pods, ves en la gráfica que hay 4 pods vivos.

Esperas un poco de tiempo, porque piensas que quizá aún la antigua revisión sigue reportando sus métricas pese a que la nueva ya ha sido desplegada. Pero después de varios minutos ves en la gráfica que siguen habiendo 4 pods vivos. ¿Cómo es posible esto si hemos indicado que queremos entre 2 y 3?

En la pestaña dónde podemos ver todas las revisiones, aparecerá un signo de tick verde en todas las revisiones que estén sirviendo tráfico.

En este caso, podemos ver como las dos revisiones están disponibles, entonces si cada una presenta un mínimo de dos pods disponibles, eso significa que podríamos tener desde 4 pods. Esto puede ser un problema ya que Google Cloud nos cobraría por cada pod, y nosotros solo deseamos tener 2 vivos con la última versión de nuestro servicio. Estaríamos pagando por 2 pods que no se van a usar.

Tráfico en CloudRun

A menudo podemos pensar que es por el tráfico configuardo, ya que podemos configurar un balanceo de la carga sobre nuestras diferentes revisiones. Por ejemplo, podemos asignar un 80% del tráfico a la revisión antigua y sólo un 20% a la última subida a producción. Sin embargo, en algunos casos podemos ver cómo el tráfico está configurado al 100% para una revisión y otra sigue apareciendo como disponible. ¿A qué se debe eso?

Tags en CloudRun

Pues bien, cómo buena práctica estás asignando tags a cada una de tus revisiones que vas subiendo para poder identificarlas más tardes por versión (por ejemplo). Sin embargo, no has eliminado los tags de las revisiones que no estabas usando.

Por defecto, Google Cloud mantiene vivas las instancias o pods que tengas en CloudRun con un tag o más asignados. De modo que aunque no reciba tráfico, siempre estará lista para empezar a recibir tráfico si se la configura y conseguir minimizar el tiempo de puesta a punto de un pod.

Si estamos seguros de que no queremos volver a usar una revisión antigua o no nos importa más tiempo de inicio en caso de necesitarla, deberíamos siempre eliminar los tags para asegurarnos de que Google Cloud apaga correctamente ese tag. De ese modo, no seremos facturados por esos recursos que realmente no estamos consumiendo.

¿Alguna vez te has topado con un problema similar? Te leo en los comentarios.

¿Quieres leer más sobre CloudRun? CloudRun

La entrada Tags en CloudRun: por qué eliminar los que no se usen se publicó primero en CloudArch.

¿Kubernetes o CloudRun?

joaquinjimenezgarcia — Wed, 31 Jan 2024 22:27:50 +0000

Ya hemos hablado en artículos anteriores sobre por qué Kubernetes es una gran opción para orquestar tus contenedores y lanzar tus servicios y aplicaciones a producción. También hemos hablado de las ventajas de CloudRun en GCP y cómo al fin de cuentas es una especie de Kubernetes customizado por Google con una capa de KNative encima para facilitar la gestión y la manutención de tus cargas de trabajo. Sin embargo, cuándo estamos diseñando la arquitectura en la nube para nuestros servicios, ¿cómo sabemos cuál de las opciones es verdaderamente la mejor opción computacional? ¿Kubernetes o CloudRun?

Pues bien, en este artículo os traigo que premisas sigo yo para saber cuál es la mejor opción dependiendo de cada caso en particulas, pues aquí como en todo “no existen balas de plata”.

Disponibilidad

La disponibilidad de nuestra carga de trabajo es una parte muy importante; ya que dependiendo desde dónde se realicen las peticiones podremos tener mayor o menor latencia, llegando a poder perjudicar a nuestros usuarios finales.

Mientras que Kubernetes, GKE en Google Cloud, nos permite tener el cluster con nodos en diferentes regiones y zonas, cuándo desplegamos un servicio en CloudRun sólo podemos hacerlo en una región en particular. Este problema podría resolverse desplegando dos veces el mismo servicio en dos regiones diferentes y luego balanceando el tráfico con un balanceador de carga, pero esto ya nos presupone un gasto adicional además de más configuración y mantenimiento por nuestra parte.

Kubernetes, definitivamente es la mejor opción para tener gran disponibilidad por múltiples zonas.

Otro punto a tener en cuenta es el número de contenedores vivos, mientras que Kubernetes garantiza que al menos habrá un pod de nuestra aplicación, CloudRun puede escalar a 0 contenedores por falta de tráfico. Esto puede ser perjudicial, pues la siguiente petición que tenga que proveer una respuesta, tardará más tiempo mientras el nodo se provee y se sirve la aplicación.

Escalabilidad

Ambas opciones ofrecen fuertes sistemas de escalados para garantizar la salud de tu aplicación; sin embargo, en Kubernetes nosotros tenemos que configurar los sitemas de autoescalado mediante Escalados Horizontales o Escalados Verticale, mientras que en CloudRun el escalado es automático en base al tráfico recibido y uso de CPU. Tan sólo tendríamos que indicar cuáles son el mínimo y el máximo de contenedores que deseamos.

CloudRun de manera automática siempre nos garantiza el número de instancias acorde a las demandas del contenedor.

Precio

Mientras que Kubernetes siempre tiene un costo mínimo garantizado por el cluster y sus nodos, el precio de CloudRun puede disminuir drásticamente si tenemos poco tráfico y los contenedores minimizan en número hasta 0. Incluso podemos contar con un par de configuraciones que nos permitan ahorrar mucho más dinero como puede ser:

Usar la primera generación de CPU
Asignar 0 al número mínimo de instancias
Usar los mínimos recursos posibles (CPU y RAM)
No dejar la CPU siempre asignada

Incluso, debido a la rápida puesta en marcha de CloudRun y la poca configuración que necesita, se podría llegar a automatizar alguna acción que borrase los servicios cuándo no se usasen (por ejemplo, borrar el entorno de desarrollo durante los fines de semana y festivos) y los re-desplegase una vez se necesiten.

Sin embargo, si vamos a hacer un uso extenso computacionalmente hablando, GKE podría llegar a ser una mejor opción a nivel económico.

Para más información sobre los precios, consulta los siguientes enlaces

Integración con otros recursos de GCP

Aunque es totalmente posible esto en ambos recuros, una vez más con CloudRun es muchísimo más sencillo. Con CloudRun todo es por y para Google Cloud.

En CloudRun bastaría con asignar los permisos y roles necesarios a la Service Account que nuestro servicio de CloudRun está usando, y eso sería todo. Es decir, si queremos acceder a CloudSQL desde nuestra instancia, sólo tendríamos que darle esos permisos, nada más.

Sin embargo, en GKE tendríamos que hacer un binding de la Service Account usada en el cluster con la Service Account en GCP con los permisos necesarios. Esto es un simple paso y se podría automatizar con Helm, pero hay que hacerlo. De lo contrario, nuestras cargas de trabajo no tendrán permisos. Además tenemos que asegurarnos de que nuestros pods están detrás del NAT y accediendo con la IP del cluster, de lo contrario tendríamos que estar añadiendo permisos y excepciones a nivel de firewall por cada IP de cada pod, por no hablar de que estás cambiarían con el tiempo. Una tarea tediosa si no se tiene en cuenta.

Acceso a los pods.

En el caso de que algo no funcione bien en nuestras aplicaciones, tanto Kubernetes como CloudRun se encargarán de terminar los pods problemáticos y proporcionar nuevos automáticamente. En el caso de que queramos ver los logs, en ambos recursos podemos tener acceso a todos los logs con Cloud Logging. Pero en el caso de que queramos entrar en algún pod a ver qué está sucediendo, con CloudRun será imposible. No hay modo de acceder a un pod de CloudRun. Con Kubernetes siempre podremos acceder a un pod para su análisis.

Configuración de las redes y seguridad

De nuevo, CloudRun vuelve a poner muchas más facilidades para exponer un servicio público a internet o para mantenerlo en nuestra red VPC privada. Al desplegar un servicio en CloudRun, este automáticamente tiene asignada una URL con un certificado TLS para poder acceder por HTTPS. Además, la fácil configuración nos permite exigir autenticación para mandar peticiones o incluso exponerla solamente internamente en nuestra VPC. No necesitariamos nada más. La misma URL redirigirá a nuestra instancia de CloudRun y el tráfico se puede dividir entre todas las revisiones de manera sencilla.

Para Kubernetes requerimos cambiar la configuración. Por defecto el servicio asignado es ClusterIP, con lo que no nos permitirá acceder a nuestras cargas de trabajo desde internet. Sin embargo, podemos cambiarlo (e incluso automatizarlo con Helm) para que use otro tipo de servicio y exponer nuestras aplicaciones. O incluso usar un balanceador de carga que redirija el trafíco a los puntos de acceso deseados, aunque en este caso los balanceadores de carga suponen un coste adicional.

Kubernetes o CloudRun

¿Y a ti se te ocurre alguna pauta más a tener en cuenta antes de decidir cuál usar? Déjame en los comentarios tu opinión, te leo.

La entrada ¿Kubernetes o CloudRun? se publicó primero en CloudArch.

Cloud(ernetes)Run

joaquinjimenezgarcia — Sun, 28 Jan 2024 18:45:06 +0000

CloudRun. En el vasto panorama de la computación en la nube, la gestión eficiente de contenedores es fundamental para la entrega rápida y confiable de servicios. Google Cloud Platform (GCP) ha presentado una solución innovadora que combina la simplicidad de Kubernetes con la potencia de Knative: Cloud Run. En este artículo, exploraremos cómo Cloud Run proporciona una experiencia similar a Kubernetes con Knative, pero con una curva de aprendizaje más suave y una gestión simplificada.

1. Abstracción de Infraestructura:

Cloud Run abstrae la infraestructura subyacente de manera similar a Kubernetes con Knative. Los desarrolladores pueden centrarse en la construcción y despliegue de aplicaciones sin preocuparse por la gestión de servidores o clusters. Esta abstracción permite una mayor portabilidad y flexibilidad, ya que las aplicaciones pueden ejecutarse tanto en entornos locales como en la nube de forma transparente.

2. Escalabilidad Automática:

Al igual que con Knative en Kubernetes, Cloud Run ofrece escalabilidad automática basada en la demanda del tráfico. Las aplicaciones se ejecutan en contenedores y se escalan horizontalmente según el número de solicitudes entrantes. Esto garantiza que las aplicaciones siempre tengan los recursos adecuados para manejar la carga de trabajo, sin necesidad de intervención manual.

3. Gestión de Tráfico Avanzada:

Cloud Run proporciona funcionalidades avanzadas de gestión de tráfico, permitiendo la implementación de versiones múltiples de una aplicación y el enrutamiento flexible del tráfico entre ellas. Esta característica, similar a los canales de tráfico en Knative, facilita la implementación de actualizaciones gradualmente y la realización de pruebas A/B sin interrumpir el servicio principal.

4. Pago por Uso:

Una de las ventajas clave de Cloud Run es su modelo de precios basado en el uso. Los usuarios solo pagan por el tiempo que sus aplicaciones están en ejecución y los recursos que consumen. Esto permite una mayor eficiencia económica, especialmente para aplicaciones con fluctuaciones en la demanda, ya que no se desperdician recursos subutilizados. Mientras que en Kubernetes siempre pagamos por el cluster aunque no esté siendo utilizado.

5. Integración con Ecosistema de GCP:

Cloud Run se integra perfectamente con el ecosistema de servicios de Google Cloud Platform, lo que permite aprovechar funcionalidades adicionales como Cloud Logging, Cloud Monitoring y Cloud IAM. Esto simplifica la gestión operativa y proporciona una visibilidad completa del rendimiento y la salud de las aplicaciones desplegadas en Cloud Run.

Conclusión:

Cloud Run en Google Cloud Platform ofrece una experiencia similar a Kubernetes con Knative, pero con una capa adicional de simplicidad y facilidad de uso. La abstracción de infraestructura, la escalabilidad automática, la gestión de tráfico avanzada, el modelo de precios basado en el uso y la integración con el ecosistema de GCP hacen de Cloud Run una opción atractiva para desarrolladores y equipos de operaciones que buscan una plataforma eficiente y poderosa para ejecutar aplicaciones en la nube. Prácticamente podríamos decir que CloudRun es Kubernetes con una capa de Knative por encima para hacer de un serivicio incluso más sencillo que Kubernetes.

¿Aún necesitas más información? No dudes y visita la documentación oficial de CloudRun proporcionada por Google Clound Platform en https://cloud.google.com/run?hl=es

Si además te has quedado con ganas de indagar también un poco más sobre por qué usar Kubernetes en lugar de CloudRun, no olvides en leerte este artículo dónde explicamos las mayores ventajas de este tipo de componente en sistemas de producción! Desmitificando Kubernetes: Las Ventajas que Hacen Brillar a tus Servicios en Producción

La entrada Cloud(ernetes)Run se publicó primero en CloudArch.

Qué tipo de disco usar en GCP

joaquinjimenezgarcia — Tue, 23 Jan 2024 10:22:17 +0000

Cuando estamos diseñando la arquitectura de nuestros servicios en la nube, a menudo podemos encontrarnos con la pregunta de qué tipo de disco o almacenamiento usar. Google Cloud (GCP) nos ofrece diferente tipos dependiendo de nuestras necesidades. Es muy importante analizarlo y escoger el correcto, para evitar gastos innecesarios, pérdidas de datos y otros problemas relacionados con un mal almacenamiento.

Almacenamiento en Disco Persistente

Puede adjuntar bloques de almacenamiento HDD o SDD a instancias individuales de Compute Engine.
Dos características interesantes del almacenamiento en disco persistente son: Escalabilidad sin tiempo de inactividad. Cifrado automático.
Obtiene la tranquilidad de saber que sus datos están seguros en reposo, y puede agregar fácilmente más almacenamiento, si es necesario, sin interrumpir nada.

SSD Locales en GCP

Los SSD locales están conectados de manera física al servidor que aloja tu instancia de VM. Este acoplamiento alto ofrece un rendimiento superior, operaciones muy grandes de entrada y salida por segundo (IOPS) y una latencia muy baja en comparación con otras opciones de almacenamiento en bloque.

Los SSD locales se diseñaron para casos de uso de almacenamiento temporal, como almacenamiento en caché o espacio provisorio para el procesamiento. Por eso, son ideales para cargas de trabajo como renderización de contenido multimedia, análisis de datos o computación de alto rendimiento.

Es un almacenamiento efímero pero de muy alto rendimiento. En esta opción los datos siempre permanecen encriptados mediante una clave de cifrado efímera y solamente son los SSDs quiénes manejan y protegen las claves a nivel de dispositivo.

Cloud Storage

Almacenamiento en objetos para empresas de todos los tamaños. Almacena cualquier cantidad de datos y puedes recuperarlos las veces que quieras. Equivalente al S3 que ofrece AWS.

Se pueden almacenar los datos con varias opciones de redundancia, se puede personalizar dónde y cómo quieres almacenar tus datos.

Estos funcionan como buckets que se pueden crear desde la consola de GCP o desde la línea de comandos.

Se ofrecen diferentes clases de almacenamiento:

Standard Storage: ideal para datos activos a los que se accede con frecuencia.
Nearline Storage: de bajo costo e ideal para datos que se pueden almacenar por lo menos por 30 días, como copias de seguridad de datos y contenido multimedia.
Coldline Storage: almacenamiento de muy bajo costo e ideal para datos que se pueden almacenar por al menos 90 días como una recuperación de desastre, se podría comparar con la clase de almacenamiento Glacer de AWS.
Archive Storage: es el almacenamiento con costo más bajo en el que los datos tienen que estar al menos 1 año y sirve para guardar datos y conservación digital cuándo no se accede mucho a ellos.

Además ofrece todo tipo de configuración de seguridad; se puede integrar con las aplicaciones, se pueden crear de modo público, se pueden crear reglas complejas, etc.

Cloud Filestore

Este es un almacenamiento de archivos completamente administrado y de alto rendimiento.

Este es un tipo de almacenamiento conectado a la red (NAS).
Totalmente gestionado para instancias de Compute Engine y GKE.
Lo fundamental a considerar aquí es la latencia.
Filestore ofrece dos niveles de rendimiento distintos: Standard (HDD) Premium (SSD)
El nivel premium ofrece un rendimiento de lectura/escritura sustancialmente mayor.
Admite hasta 320TB de capacidad.

Cloud Storage para Firebase

Cloud Storage para Firebase es un servicio de almacenamiento de objetos potente, simple y rentable construido para el escalamiento de Google. Los SDKs de Firebase para Cloud Storage agregan la seguridad de Google a las operaciones de carga y descarga de archivos de tus apps de Firebase, sin importar la calidad de la red.

Cloud Storage para Firebase almacena tus archivos en un bucket de Google Cloud Storage y los hace accesibles a través de Firebase y Google Cloud, lo cual brinda flexibilidad para subir y descargar archivos a clientes móviles a través de los SDKs de Firebase para Cloud Storage.

Servicio de transferencia de almacenamiento a GCP

Servicios seguros y de bajo costo para transferir datos desde fuentes locales o en la nube de estos proveedores como AWS o Azure.

En el Servicio de transferencia de almacenamiento es posible importar datos en línea con rapidez en Cloud Storage desde otras fuentes externas a Google Cloud. También puedes configurar un programa de repetición para la transferencia de datos, además de transferir datos de un bucket a otro dentro de Cloud Storage. Te permite mover grandes cantidades de datos periódicamente como parte de una canalización de procesamiento de datos o de un flujo de trabajo analítico. El servicio de transferencia de almacenamiento proporciona opciones que facilitan la transferencia y sincronización de datos.

Si quieres leer más acerca de los tipos de discos, visita la documentación oficial en https://cloud.google.com/storage

Para más artículos relacionados con GCP, visita todos los posts de este apartado en nuestro blog GCP

La entrada Qué tipo de disco usar en GCP se publicó primero en CloudArch.