Serverless: Permite a los desarrolladores concentrarse en su código, en lugar de en

la configuración del servidor, al eliminar la necesidad de administrar cualquier

infraestructura.

Cloud Run: Que permite a los clientes implementar su aplicación basada en

microservicios en contenedores en un entorno totalmente administrado.

La infraestructura de Google Cloud se basa en cinco ubicaciones geográficas

principales: América del Norte, América del Sur, Europa, Asia y Australia.

Tener múltiples ubicaciones de servicios es importante porque elegir dónde ubicar

las aplicaciones afecta cualidades como la disponibilidad, la durabilidad y la
latencia.

Cloud Spanner: Las configuraciones multirregionales se permiten replicar los datos

de la base de datos, Estas réplicas adicionales le permiten leer datos con baja
latencia desde múltiples ubicaciones cercanas o dentro de las regiones de la
configuración, como los Países Bajos y Bélgica.

centros de datos de Google fueron los primeros en lograr la certificación ISO 14001,
Estándar que traza un marco para que una organización mejore su desempeño
ambiental mediante la mejora de la eficiencia de los recursos y la reducción de
residuos.
Kubernetes y Google Kubernetes Engine brindan a los clientes la capacidad de
mezclar y combinar microservicios en ejecución.

4 niveles Estructura funcional de Google Cloud.

Los proyectos son la base para habilitar y utilizar los servicios de Google Cloud,
como administrar API, habilitar la facturación, agregar y eliminar colaboradores y
habilitar otros servicios de Google.
IAM: Los administradores pueden aplicar políticas que definen quién puede hacer
qué y en qué recursos.
https://cloud.google.com/security/products/iam?hl=es-419
Tres Roles de IAM:
Los roles básicos incluyen propietario, editor, espectador y administrador de
facturación.
Rol Predefinido: Ejemplo de puede aplicar a Compute Engine.
Rol Personalizado: Entonces, por ejemplo, tal vez quieras definir una función de
"Operador de instancia" para permitir que algunos usuarios detengan e inicien
máquinas virtuales de Compute Engine, pero no las reconfiguren.
Interactuando con Google:
Cloud Console, Cloud SDK y Cloud Shell, las API y la aplicación Google Cloud.

Cloud SDK es un conjunto de herramientas que puede utilizar para administrar

recursos y aplicaciones alojadas en Google Cloud.
Estos incluyen Google Cloud CLI, que proporciona la interfaz principal de línea de
comandos para los productos y servicios de Google Cloud, y bq, una herramienta de
línea de comandos para BigQuery.

Cloud Console incluye una herramienta llamada Google API Explorer que muestra
qué API están disponibles y en qué versiones.

VPC: Virtual Private Cloud

Características del VPC:

Las redes VPC conectan los recursos de Google Cloud entre sí y con Internet.
El tamaño de una subred se puede aumentar ampliando el rango de direcciones IP
asignadas a ella, y hacerlo no afectará a las máquinas virtuales que ya están
configuradas.
Esto incluye segmentar redes, usar reglas de firewall para restringir el acceso a
instancias y crear rutas estáticas para reenviar el tráfico a destinos específicos.
Hay algo que tiende a sorprender a muchos nuevos usuarios de Google Cloud: las
redes de Google VPC son globales.
También pueden tener subredes, que son una parte segmentada de la red más
grande, en cualquier región de Google Cloud en todo el mundo.
Las subredes pueden abarcar las zonas que conforman una región.
Esta arquitectura facilita la definición de diseños de red con alcance global.
Los recursos pueden incluso estar en diferentes zonas de la misma subred.
El tamaño de una subred se puede aumentar ampliando el rango de direcciones IP
asignadas a ella, y hacerlo no afectará a las máquinas virtuales que ya están
configuradas.
Por ejemplo, tomemos una red VPC llamada vpc1 que tiene dos subredes definidas
en las regiones asia-east1 y us-east1.

Si la VPC tiene tres máquinas virtuales de Compute Engine conectadas, significa

que son vecinas en la misma subred aunque estén en zonas diferentes.
Esta capacidad se puede utilizar para crear soluciones que sean resistentes a las
interrupciones y al mismo tiempo mantengan un diseño de red simple.
Solución Google Cloud IaaS: Compute Engine.
Se puede crear una instancia de máquina virtual a través de la consola de Google
Cloud, que es una instancia basada en web.

Herramienta para administrar proyectos y recursos de Google Cloud, la CLI de

Google Cloud o la API de Compute Engine.

La instancia puede ejecutar imágenes de Linux y Windows Server proporcionadas

por Google o cualquier versión personalizada de estas imágenes.

También puede crear y ejecutar imágenes de otros sistemas operativos y

reconfigurar máquinas virtuales de manera flexible.

Una forma rápida de comenzar con Google Cloud es a través de Cloud Marketplace,
que ofrece soluciones tanto de Google como de proveedores externos.
Algunas imágenes de Cloud Marketplace cobran tarifas de uso, particularmente
aquellas publicadas por terceros, con software con licencia comercial, pero todas
muestran estimaciones de sus cargos mensuales antes de su lanzamiento.
En este punto, es posible que te preguntes acerca de la estructura de precios y
facturación de Compute Engine.

Para el uso de máquinas virtuales, Compute Engine factura por segundo con un
mínimo de un minuto, y los descuentos por uso sostenido comienzan a aplicarse
automáticamente a las máquinas virtuales cuanto más tiempo funcionan.
Compute Engine también ofrece descuentos por uso comprometido.
Esto significa que para cargas de trabajo estables y predecibles, se puede comprar
una cantidad específica de vCPU y memoria por hasta un 57% de descuento sobre
los precios normales a cambio de comprometerse a un plazo de uso de uno o tres
años.

Spot:

Aunque es posible ahorrar con máquinas virtuales interrumpibles o puntuales,

deberá asegurarse de que su trabajo pueda detenerse y reiniciarse.
Las máquinas virtuales puntuales se diferencian de las máquinas virtuales
interrumpibles en que ofrecen más funciones.
Por ejemplo, las máquinas virtuales interrumpibles solo pueden ejecutarse durante
un máximo de 24 horas seguidas, pero las máquinas virtuales puntuales no tienen
un tiempo de ejecución máximo.

Opciones de Compute Engine:

Compute Engine tiene una función llamada Autoscaling, donde se pueden agregar o
quitar VM de una aplicación en función de métricas de carga.
La otra parte para que eso funcione es equilibrar el tráfico entrante entre las
máquinas virtuales.
Características del VPC (Nube privada virtual)
Routing table:

Las tablas de enrutamiento de VPC están integradas para que no tenga que
aprovisionar ni administrar un enrutador.
Se utilizan para reenviar tráfico de una instancia a otra dentro de la misma red, a
través de subredes o incluso entre zonas de Google Cloud, sin requerir una dirección
IP externa.
Firewall:

Las VPC proporcionan un firewall distribuido global, que se puede controlar para
restringir el acceso a las instancias a través del tráfico entrante y saliente.
Las reglas de firewall se pueden definir a través de etiquetas de red en instancias
de Compute Engine, lo cual es realmente conveniente.
Se pueden manejar etiquetas en los firewalls de VPC por ejemplo:

Por ejemplo, puede etiquetar todos sus servidores web con, por ejemplo, "WEB" y
escribir una regla de firewall que indique que el tráfico en los puertos 80 o 443 están
permitidos en todas las máquinas virtuales con la etiqueta "WEB", sin importar cuál
sea su dirección IP.
Recordará que las VPC pertenecen a proyectos de Google Cloud, pero ¿qué pasa si
su empresa tiene varios proyectos de Google Cloud y las VPC necesitan
comunicarse entre sí?

Con VPC Peering se puede establecer una relación entre dos VPC para intercambiar
tráfico.

Alternativamente, utilizar todo el poder de Identity Access Management (IAM) para

controlar quién y qué en un proyecto puedes interactuar con una VPC, en otro,
puedes configurar una VPC compartida.
Cloud Load Balancing:

Y como los balanceadores de carga no se ejecutan en máquinas virtuales que usted

tenga que administrar, no tiene que preocuparse por escalarlos o administrarlos.
Puedes poner Cloud Load Balancing delante de todo tu tráfico: HTTP o HTTPS, otro
tráfico TCP y SSL, y también tráfico UDP.
Cloud Load Balancing proporciona equilibrio de carga entre regiones, incluida la
conmutación por error automática en varias regiones, que mueve suavemente el
tráfico en fracciones si los backends no funcionan correctamente.
Si necesita equilibrio de carga entre regiones para una aplicación web, utilice el
equilibrio de carga HTTP(S) global.

Para el tráfico de Secure Sockets Layer que no es HTTP, utilice el equilibrador de

carga de Global SSL Proxy.
Cloud Load Balancing reacciona rápidamente a los cambios en los usuarios, el
tráfico, la red, el estado del backend y otras condiciones relacionadas.

Opciones de Balanceo de carga:

Si necesita equilibrio de carga entre regiones para una aplicación web, utilice el
equilibrio de carga HTTP(S) global.
Para el tráfico de Secure Sockets Layer que no es HTTP, utilice el equilibrador de
carga de Global SSL Proxy.

Si se trata de otro tráfico TCP que no utiliza SSL, utilice el equilibrador de carga del
proxy TCP global.

Esos dos últimos servicios de proxy solo funcionan para números de puerto
específicos y solo funcionan para TCP.

Si desea equilibrar la carga del tráfico UDP o el tráfico en cualquier número de

puerto, puede aún equilibra la carga en una región de Google Cloud con el
balanceador de carga de la red regional de paso externo.
Además de eso, también puede implementar el balanceador de carga de
aplicaciones externas regionales y el balanceador de carga de red proxy.

Lo que todos esos servicios tienen en común es que están destinados al tráfico que
ingresa a la red de Google desde Internet.

Pero, ¿qué sucede si desea equilibrar la carga del tráfico dentro de su proyecto, por
ejemplo, entre la capa de presentación y la capa comercial de su aplicación?
Para ello, utilice el equilibrador de carga interno regional que admita el equilibrador
de carga de red proxy, el equilibrador de carga de red Passthrough y el equilibrador
de carga de aplicaciones.
Acepta tráfico en una dirección IP interna de Google Cloud y lo equilibra de carga
entre las máquinas virtuales de Compute Engine.

Por último, el balanceador de carga interno entre regiones de Google Cloud es un

balanceador de carga de capa 7 que le permite equilibrar la carga.

Tráfico a servicios backend distribuidos globalmente, incluida la gestión del tráfico

que garantiza que el tráfico se dirija al backend más cercano.
Google Cloud DNS:

Es un servicio DNS administrado que se ejecuta en la misma infraestructura que

Google.

Tiene baja latencia y alta disponibilidad, y es una forma rentable de poner sus
aplicaciones y servicios a disposición de sus usuarios.

La información de DNS que usted publica se proporciona desde ubicaciones

redundantes en todo el mundo.

Puedes publicar y administrar millones de zonas y registros DNS mediante Cloud

Console, la interfaz de línea de comandos o la API.
Google Cloud CDN:

Google también tiene un sistema global de cachés perimetrales.

El almacenamiento en caché perimetral se refiere al uso de servidores de

almacenamiento en caché para almacenar contenido más cerca de los usuarios
finales.

Puede utilizar este sistema para acelerar la entrega de contenido en su aplicación

mediante Cloud CDN - Content Delivery Network.

Esto significa que sus clientes experimentarán una latencia de red más baja, los
orígenes de su contenido experimentarán una carga reducida e incluso podrá
ahorrar dinero.

Una vez configurado el equilibrio de carga HTTP(S), Cloud CDN se puede habilitar
con una sola casilla de verificación.
Si ya estás usando uno, lo más probable es que sea parte del programa de socios
CDN Interconnect de Google Cloud y puedas continuar usándolo.

Esquema de conexión desde Google Cloud hacia Redes LAN en OMPREMISE O

Otras nubes Publicas:
Existen:
Cloud VPN para crear un túnel, que usa la tecnología de Cloud Router permite que
otras redes y Google VPC intercambien información de ruta a través de la VPN
utilizando el protocolo Border Gateway, también permite que la conexión sea
dinámica y para usar Internet para conectar redes no siempre es la mejor opción
para todos, ya sea por cuestiones de seguridad o por la confiabilidad del ancho de
banda.

Direct Peering: significa colocar un enrutador en el mismo centro de datos público

como punto de presencia de Google y usarlo para intercambiar tráfico entre redes.
Google tiene más de 100 puntos de presencia en todo el mundo.
Programa Carrier Peering: Los clientes que aún no se encuentran en un punto de
presencia pueden trabajar con un socio en este programa para conectarse.
El peering de operador le brinda acceso directo desde su red local a través de la red
de un proveedor de servicios a Google.

Workspace y a los productos de Google Cloud que pueden exponerse a través de

una o más direcciones IP públicas.

Sin embargo, una desventaja del peering es que no está cubierto por un Acuerdo de
nivel de servicio de Google.

Interconexión dedicada: Esta opción permite una o más conexiones privadas

directas a Google.
Si estas conexiones tienen topologías que cumplen con las especificaciones de
Google, pueden estar cubiertas por un SLA de hasta el 99,99%.
Además, estas conexiones pueden estar respaldadas por una VPN para una
confiabilidad aún mayor.

Partner Interconnect: que proporciona conectividad entre una red local y una red
VPC a través de un proveedor de servicios compatible.
Una conexión de Partner Interconnect es útil si un centro de datos se encuentra en
una ubicación física a la que no se puede acceder una instalación de colocación de
interconexión dedicada, o si las necesidades de datos no garantizan una conexión
completa de 10 GigaBytes por segundo.
Dependiendo de las necesidades de disponibilidad, Partner Interconnect se puede
configurar para admitir servicios o aplicaciones de misión crítica que puedan tolerar
algún tiempo de inactividad.

Al igual que ocurre con la Interconexión Dedicada, si estas conexiones tienen

topologías que cumplen con las especificaciones de Google, pueden estar cubiertas
por un SLA de hasta el 99,99%.

Pero tenga en cuenta que Google no es responsable de ningún aspecto de Partner

Interconnect proporcionado por el proveedor de servicios externo, ni de ningún
problema fuera de la red de Google.
Cross-Cloud Interconnect te ayuda a establecer una conectividad dedicada de gran
ancho de banda entre Google Cloud y otro proveedor de servicios en la nube.
Google proporciona una conexión física dedicada entre la red de Google y la de otro
proveedor de servicios en la nube.
Puede utilizar esta conexión para conectar su red de nube privada virtual de Google
con su red alojada en un proveedor de servicios de nube compatible.

Cross-Cloud Interconnect respalda la adopción de una estrategia multinube

integrada.

Además de admitir varios proveedores de servicios en la nube, Cross-Cloud

Interconnect ofrece complejidad reducida, transferencia de datos de sitio a sitio y
cifrado.

Las conexiones Cross-Cloud Interconnect están disponibles en dos tamaños: 10

Gbps o 100 Gbps.
Cinco productos de almacenamiento principales de Google Cloud: Cloud Storage, Cloud
SQL, Cloud Spanner, Firestore y Cloud Bigtable.

Cloud Storage: es un servicio que ofrece a los desarrolladores y organizaciones de TI

almacenamiento de objetos duradero y de alta disponibilidad.

Pero ¿qué es el almacenamiento de objetos?

El almacenamiento de objetos es una arquitectura de almacenamiento de datos
informáticos que gestiona datos como "objetos" y no como una jerarquía de
archivos y carpetas (almacenamiento de archivos) o como fragmentos de un disco
(almacenamiento en bloques).
Estos objetos se almacenan en un formato empaquetado que contiene la forma
binaria de los datos reales, como, así como metadatos asociados relevantes (como
fecha de creación, autor, tipo de recurso y permisos) y un identificador único a nivel
mundial.

Estas claves únicas tienen forma de URL, lo que significa que el almacenamiento de
objetos interactúa bien con las tecnologías web.
Los datos comúnmente almacenados como objetos incluyen videos, imágenes y
grabaciones de audio.

Cloud Storage: Es el producto de almacenamiento de objetos de Google.

Permite a los clientes almacenar cualquier cantidad de datos y recuperarlos con
tanta frecuencia como sea necesario.
Es un servicio escalable totalmente administrado que tiene una amplia variedad de
usos.

Algunos ejemplos incluyen servir contenido de sitios web, almacenar datos para
archivo y recuperación ante desastres y distribuir objetos de datos de gran tamaño
a usuarios finales mediante descarga directa.
El uso principal de Cloud Storage es cuando se necesita almacenamiento binario de
objetos grandes (también conocido como "BLOB") para contenido en línea como:
- Vídeos y fotografías,
- Para realizar copias de seguridad y datos archivados
- Para almacenar resultados intermedios en flujos de trabajo de
procesamiento.

Organización de Cloud STORAGE

Los archivos de Cloud Storage están organizados en depósitos.

Un depósito necesita un nombre global único y una ubicación geográfica específica
donde debe almacenarse, y una ubicación ideal para un depósito es donde se
minimiza la latencia.
Por ejemplo, si la mayoría de sus usuarios se encuentran en Europa, probablemente
desee elegir un Ubicación europea, es decir, una región específica de Google Cloud
en Europa o la multirregión de la UE.

Los objetos de almacenamiento que ofrece Cloud Storage son inmutables, lo que
significa que no los editas, sino que se crea una nueva versión con cada cambio
realizado.
Los administradores tienen la opción de permitir que cada nueva versión
sobrescriba completamente la anterior o para realizar un seguimiento de cada
cambio realizado en un objeto en particular habilitando el "control de versiones"
dentro de un depósito.

Si elige utilizar el control de versiones, Cloud Storage mantendrá un historial

detallado de modificaciones (es decir, sobrescrituras o eliminaciones) de todos los
objetos contenidos en ese depósito.
Si no activa el control de versiones de objetos, de forma predeterminada, las nuevas
versiones siempre sobrescribirán las versiones anteriores.

Con el control de versiones de objetos habilitado, puede enumerar las versiones

archivadas de un objeto, restaurar un objeto a un estado anterior o eliminar
permanentemente una versión de un objeto, según sea necesario.
En muchos casos, los objetos de datos pueden contener información de
identificación personal, por lo que controlar el acceso a los datos almacenados es
esencial para garantizar que se mantengan la seguridad y la privacidad.

Al utilizar roles de IAM y, cuando sea necesario, listas de control de acceso (ACL),
las organizaciones pueden cumplir con las mejores prácticas de seguridad, que
requieren cada usuario tenga acceso y permisos solo a los recursos que necesita
para realizar su trabajo, y nada más que eso.
Hay un par de opciones para controlar el acceso de los usuarios a objetos y
depósitos.
Para la mayoría de los propósitos, IAM es suficiente.
Los roles se heredan del proyecto al depósito y al objeto.
Si necesita un control más preciso, puede crear listas de control de acceso.
Cada lista de control de acceso consta de dos piezas de información.
El primero es un alcance, que define quién puede acceder y realizar una acción.
Puede ser un usuario específico o un grupo de usuarios.
El segundo es un permiso, que define qué acciones se pueden realizar, como leer o
escribir.
Debido a que almacenar y recuperar grandes cantidades de datos de objetos puede
volverse costoso rápidamente, Cloud Storage también ofrece políticas de
administración del ciclo de vida.
Por ejemplo, podría indicarle a Cloud Storage que elimine objetos que tengan más
de 365 días; o para eliminar objetos creados antes de enero 1, 2013; o para
mantener solo las 3 versiones más recientes de cada objeto en un depósito que
tenga habilitado el control de versiones.
Tener este control garantiza que no pagará más de lo que realmente necesita.

Hay cuatro clases de almacenamiento principales en Cloud Storage.

El almacenamiento estándar: Se considera mejor para los datos a los que se accede
con frecuencia o "calientes".
También es excelente para datos que se almacenan solo por breves períodos de
tiempo.
Nearline Storage: Esto es mejor para almacenar datos a los que se accede con poca
frecuencia, como leer o modificar datos en promedio una vez al mes o menos.
Los ejemplos podrían incluir copias de seguridad de datos, contenido multimedia de
cola larga o archivo de datos.

Coldline Storage: Esta también es una opción de bajo costo para almacenar datos
a los que se accede con poca frecuencia.
Sin embargo, en comparación con Nearline Storage, Coldline Storage está diseñado
para leer o modificar datos, como máximo, una vez cada 90 días.

Almacenamiento de archivos:
Esta es la opción de menor costo y se utiliza idealmente para archivar datos, realizar
copias de seguridad en línea y recuperación ante desastres.
porque tiene mayores costos de acceso a datos y operaciones y una duración
mínima de almacenamiento de 365 días.

Aunque cada una de estas cuatro clases tiene diferencias, vale la pena señalar que
existen varias características que se aplican a todas estas clases de
almacenamiento.
Estos incluyen:
- Almacenamiento ilimitado sin requisito de tamaño mínimo de objeto.
- Accesibilidad y ubicaciones en todo el mundo.
- Baja latencia y alta durabilidad, A experiencia uniforme, que se extiende a la
seguridad, las herramientas y las API.
- Redundancia geográfica si los datos se almacenan en una región múltiple o
dual.
Esto significa colocar servidores físicos en centros de datos geográficamente
diversos para protegerlos contra eventos catastróficos y desastres naturales, y
equilibrar la carga del tráfico para lograr un rendimiento óptimo.

Cloud Storage no tiene una tarifa mínima porque solo paga por lo que usa y no es
necesario el aprovisionamiento previo de capacidad.
Y desde una perspectiva de seguridad, Cloud Storage siempre cifra los datos en el
lado del servidor, antes de escribirlos en el disco, sin costo adicional.

Los datos que viajan entre el dispositivo de un cliente y Google se cifran de forma
predeterminada mediante HTTPS/TLS (Seguridad de la capa de transporte).
Independientemente de la clase de almacenamiento que elija, existen varias
formas de incorporar datos a Cloud Storage.
Muchos clientes simplemente realizan su propia transferencia en línea utilizando el
almacenamiento gcloud, que es el comando Cloud Storage del SDK de Cloud.
Los datos también se pueden mover usando una opción de arrastrar y soltar en
Cloud Console, si se accede a través del navegador web Google Chrome.

Pero ¿qué pasa si tienes que cargar terabytes o incluso petabytes de datos?

El servicio de transferencia de almacenamiento: le permite importar grandes

cantidades de datos en línea a Cloud Storage de forma rápida y rentable.
El servicio de transferencia de almacenamiento: le permite programar y administrar
transferencias por lotes a Cloud Storage desde otro proveedor de nube, desde una
región de Cloud Storage diferente o desde un punto final HTTP(S).

Y luego está:
Transfer Appliance: Que es un servidor de almacenamiento en rack de alta
capacidad que se alquila a Google Cloud.
Lo conecta a su red, lo carga con datos y luego lo envía a una instalación de carga
donde los datos se cargan en Cloud Storage.
La estrecha integración de Cloud Storage con otros productos y servicios de Google
Cloud significa que existen muchas formas adicionales de transferir datos al
servicio.
Por ejemplo, puedes importar y exportar tablas desde y hacia BigQuery y Cloud SQL.
También puede acceder a registros de App Engine, copias de seguridad de Firestore
y objetos utilizados por las aplicaciones de App Engine, como imágenes.
Cloud Storage también puede almacenar scripts de inicio de instancias, imágenes
de Compute Engine y objetos utilizados por las aplicaciones de Compute Engine.
La segunda opción de almacenamiento principal de Google Cloud es:

Cloud SQL:

Está diseñado para traspasar a Google tareas mundanas, pero necesarias y que a
menudo consumen mucho tiempo, como solicitar parches y actualizaciones,
gestión de copias de seguridad y configuración de replicaciones, para que pueda
centrarse en crear excelentes aplicaciones.

- Cloud SQL no requiere ninguna instalación ni mantenimiento de software.

 - Puede escalar hasta 128 núcleos de procesador, 864 GB de RAM y 64 TB de
almacenamiento.
- Admite escenarios de replicación automática, como desde una instancia
primaria de Cloud SQL, una instancia primaria externa e instancias externas
de MySQL.
- Cloud SQL admite copias de seguridad administradas, por lo que los datos
respaldados se almacenan de forma segura y se puede acceder a ellos si se
requiere una restauración.
- El costo de una instancia cubre siete copias de seguridad.
- Cloud SQL cifra los datos de los clientes cuando se encuentran en las redes
internas de Google y cuando se almacenan en tablas de bases de datos,
archivos temporales y copias de seguridad.
- E incluye un firewall de red, que controla el acceso de la red a cada
instancia de base de datos.

Una ventaja de las instancias de Cloud SQL es que otros servicios de Google Cloud
e incluso servicios externos pueden acceder a ellas.
Cloud SQL se puede usar con App Engine usando controladores estándar como
Connector/J para Java o MySQLdb para Python.
Las instancias de Compute Engine pueden recibir autorización para acceder a
instancias de Cloud SQL y configurar la instancia de Cloud SQL para que esté en la
misma zona que su máquina virtual.
Cloud SQL también admite otras aplicaciones y herramientas que podrías usar,
como SQL Workbench, Toad y otras aplicaciones externas que usan controladores
MySQL estándar.

La tercera opción de almacenamiento principal que ofrece Google Cloud es:

Cloud Spanner:

Cloud Spanner es un servicio de base de datos relacional totalmente administrado

que se escala horizontalmente, es muy consistente y habla SQL.
Spanner, probado en batalla por las propias aplicaciones y servicios de misión
crítica de Google, es el servicio que impulsa el negocio de Google de 80 mil
millones de dólares.

Cloud Spanner es especialmente adecuado para aplicaciones que requieren: Un

sistema de gestión de bases de datos relacionales SQL con uniones y índices
secundarios Alta disponibilidad incorporada Fuerte consistencia global y un gran
número de operaciones de entrada y salida por segundo.
Estamos hablando de decenas de miles de lecturas y escrituras por segundo o más.
La cuarta opción de almacenamiento principal de Google Cloud es:

Firestore:

Firestore es una base de datos en la nube NoSQL flexible y escalable

horizontalmente para desarrollo móvil, web y de servidores.
Con Firestore, los datos se almacenan en documentos y luego se organizan en
colecciones.
Los documentos pueden contener objetos anidados complejos además de
subcolecciones.
Cada documento contiene un conjunto de pares clave-valor.
Por ejemplo, un documento para representar a un usuario tiene las claves para el
nombre y apellido con los valores asociados.

Las consultas NoSQL de Firestore se pueden usar para recuperar documentos

individuales y específicos o para recuperar todos los documentos de una
colección que coincidan con sus parámetros de consulta.
Las consultas pueden incluir múltiples filtros encadenados y combinar opciones
de filtrado y clasificación.
También están indexados de forma predeterminada, por lo que el rendimiento de
la consulta es proporcional al tamaño del conjunto de resultados, no al conjunto de
datos.

Firestore utiliza la sincronización de datos para actualizar los datos en cualquier

dispositivo conectado.
Sin embargo, también está diseñado para realizar consultas de recuperación
simples y únicas de manera eficiente.
Almacena en caché los datos que una aplicación utiliza activamente, por lo que la
aplicación puede escribir, leer, escuchar y consultar datos incluso si el dispositivo
está fuera de línea.
Cuando el dispositivo vuelve a estar en línea, Firestore sincroniza cualquier cambio
local con Firestore.

Firestore aprovecha la potente infraestructura de Google Cloud:

- Replicación automática de datos en varias regiones.

- Sólidas garantías de coherencia.
 - Operaciones por lotes atómicos.
- Soporte para transacciones reales.

Desde una perspectiva de precios:

- Se le cobra por cada documento leído, escrito y eliminado que realice con
Firestore.
- Las consultas también se cobran a razón de un "documento leído" por
consulta, ya sea que la consulta devuelva datos o no.
- También se le cobra por la cantidad de almacenamiento que consumen sus
datos y por ciertos tipos de ancho de banda de red utilizados para acceder a
sus datos.
- Actualmente, la entrada es gratuita y, en muchos casos, también lo es la
salida.

Consulte la página de precios de Firestore para obtener más detalles o puede

utilizar la Calculadora de facturación de Google para estimar los precios para su
caso de uso particular.
Además de los 10 GiB de salida de red gratuita por mes entre regiones de EE. UU.,
Firestore tiene una conexión gratuita.
Cuota por día de:
- 50 000 lecturas de documentos.
- 20 000 escrituras de documentos.
- 20 000 eliminaciones de documentos.
- 1 GB de datos almacenados.
Los cargos solo comienzan una vez que se ha superado la cuota diaria gratuita.
Esto le permite comenzar a desarrollar con Firestore por muy poco o incluso
gratis.

La última de las opciones de almacenamiento principales de Google Cloud que

exploraremos es:

Cloud Bigtable:

Cloud Bigtable: es el servicio de base de datos de big data NoSQL de Google.

Es la misma base de datos que impulsa muchos de los servicios principales de
Google, incluidos Search, Analytics, Maps y Gmail.

Bigtable está diseñado para manejar cargas de trabajo masivas con una latencia
baja constante y un alto rendimiento, por lo que es una excelente opción para
aplicaciones operativas y analíticas, incluido Internet de las cosas, análisis de
usuarios y análisis de datos financieros.
Al decidir qué opción de almacenamiento es mejor, los clientes suelen elegir
Bigtable si:
- Trabajan con más de 1 TB de datos estructurados o semiestructurados.
- Los datos son rápidos y tienen un alto rendimiento, o cambian rápidamente.
- Están trabajando con datos NoSQL.
- Esto suele significar transacciones en las que no se requiere una semántica
relacional sólida.
- Los datos son una serie de tiempo o tienen un orden semántico natural.
- Están trabajando con big data, ejecutando procesamiento por lotes
asíncrono o sincrónico en tiempo real de los datos.
- O están ejecutando algoritmos de aprendizaje automático con los datos.
Cloud Bigtable puede interactuar con otros servicios de Google Cloud y clientes de
terceros.
Al utilizar API, los datos se pueden leer y escribir en Cloud Bigtable a través de un
servicio de datos.
Capa como máquinas virtuales administradas, el servidor REST de HBase o un
servidor Java que utiliza el cliente HBase.
Normalmente, esto se utiliza para enviar datos a aplicaciones, paneles y servicios
de datos.

Los datos también se pueden transmitir a través de una variedad de marcos de

procesamiento de transmisiones populares, como Dataflow Streaming, Spark
Streaming y Storm.
Y si la transmisión no es una opción, los datos también se pueden leer y escribir en
Cloud Bigtable mediante procesos por lotes como Hadoop MapReduce, Dataflow o
Spark.
A menudo, los datos resumidos o recién calculados se vuelven a escribir en Cloud
Bigtable o en una base de datos posterior.

Ahora que hemos cubierto las opciones de almacenamiento principal de Google

Cloud, hagamos una comparación para ayudar a resaltar el servicio más adecuado
para una aplicación o flujo de trabajo específico.

Considere usar Cloud Storage si necesita almacenar blobs inmutables de más de

10 megabytes, como imágenes o películas de gran tamaño.
Este servicio de almacenamiento proporciona petabytes de capacidad con un
tamaño unitario máximo de 5 terabytes por objeto.
Considere usar Cloud SQL o Cloud Spanner si necesita soporte completo de SQL
para un sistema de procesamiento de transacciones en línea.
Cloud SQL proporciona hasta 64 terabytes, según el tipo de máquina, y Cloud
Spanner proporciona petabytes.
Cloud SQL es mejor para marcos web y aplicaciones existentes, como almacenar
credenciales de usuario y pedidos de clientes.
Si Cloud SQL no se ajusta a tus requisitos porque necesitas escalabilidad horizontal,
no solo a través de réplicas de lectura, considera usar Cloud Spanner.
Considere Firestore si necesita escalabilidad y previsibilidad masivas junto con
resultados de consultas en tiempo real y soporte para consultas sin conexión.
Este servicio de almacenamiento proporciona terabytes de capacidad con un
tamaño de unidad máximo de 1 megabyte por entidad.
Firestore es mejor para almacenar, sincronizar y consultar datos para aplicaciones
web y móviles.
Finalmente, considere usar Cloud Bigtable si necesita almacenar una gran cantidad
de objetos estructurados.
Cloud Bigtable no admite consultas SQL ni transacciones de varias filas.
Este servicio de almacenamiento proporciona petabytes de capacidad con un
tamaño de unidad máximo de 10 megabytes por celda y 100 megabytes por fila.
Bigtable es mejor para datos analíticos con muchos eventos de lectura y escritura,
como datos de AdTech, financieros o de IoT.
Dependiendo de su aplicación, es posible que utilice uno o varios de estos servicios
para realizar el trabajo.

Es posible que hayas notado que BigQuery no se menciona en esta sección del
curso.
Esto se debe a que se encuentra en el límite entre el almacenamiento y el
procesamiento de datos, y se trata con más profundidad en otros cursos.
La razón habitual para almacenar datos en BigQuery es poder utilizar sus
capacidades de análisis de big data y consultas interactivas, pero no es puramente
un producto de almacenamiento de datos.

Contenedores:

La infraestructura como servicio o IaaS le permite compartir recursos informáticos

con otros desarrolladores mediante el uso de máquinas virtuales para virtualizar el
hardware.

Esto permite a cada desarrollador implementar su propio sistema operativo,

sistema operativo, acceder al hardware y crear sus aplicaciones en un entorno
autónomo con acceso a RAM, sistemas de archivos, interfaces de red, etc.
La idea de un contenedor es brindar escalabilidad independiente de las cargas de
trabajo en proceso y una capa de abstracción del sistema operativo y el hardware
en IaaS.

- Un sistema configurable que le permite instalar su tiempo de ejecución,

servidor web, base de datos o middleware favorito.

- Configure los recursos subyacentes del sistema, como el espacio en disco,

la E/S de disco o la red, y compílelos como desee.

- Pero la flexibilidad tiene un costo.

- La unidad de cálculo más pequeña es una aplicación con su VM.

- El sistema operativo invitado puede ser grande, incluso de gigabytes, y

tardar unos minutos en iniciarse.
 - A medida que aumenta la demanda de su aplicación, debe copiar una
máquina virtual completa e iniciar el sistema operativo invitado para cada
instancia de su aplicación, lo que puede resultar lento y costoso.

Un contenedor es una caja invisible alrededor de su código y sus dependencias

con acceso limitado a su propia partición del sistema de archivos y hardware.

- Solo requiere unas pocas llamadas al sistema para su creación y comienza

tan rápido como un proceso.
- Todo lo que se necesita en cada host es un kernel del sistema operativo
que admita contenedores y un tiempo de ejecución de contenedores.
- Básicamente, el sistema operativo se está virtualizando.
- Se escala como un pase, pero le brinda casi la misma flexibilidad que IS.
- Puede pasar del desarrollo a la puesta en escena, a la producción o de su
computadora portátil a la nube sin cambiar ni reconstruir nada.
Como ejemplo, digamos que desea escalar un servidor web, con un contenedor
puede hacer esto:

en segundos e implemente docenas o cientos de ellos según el tamaño de su

carga de trabajo en un solo host.
Este es solo un ejemplo simple de cómo escalar un contenedor y ejecutar toda la
aplicación en un solo host.

Sin embargo, probablemente querrás crear tus aplicaciones utilizando muchos

contenedores, cada uno de los cuales realiza su propia función, como
microservicios.
Si los construye de esta manera y los conecta con conexiones de red, puede
hacerlos modulares, implementarlos fácilmente y escalarlos de forma
independiente en un grupo de hosts.
Los hosts pueden escalar hacia arriba y hacia abajo e iniciar y detener contenedores
a medida que cambia la demanda de su aplicación o cuando fallan los hosts.
Kubernetes: Un producto que ayuda a gestionar y escalar aplicaciones en
contenedores es Kubernetes.

Entonces, para ahorrar tiempo y esfuerzo al escalar aplicaciones y cargas de

trabajo, Kubernetes se puede iniciar utilizando el motor de Google Kubernetes,
GKE.

Entonces, ¿qué es Kubernetes?

Kubernetes es una plataforma de código abierto para gestionar cargas de trabajo y
servicios en contenedores.

- Facilita la organización de muchos contenedores en muchos hosts,

escalarlos como microservicios e implementar, implementar y revertir
fácilmente.
 - En el nivel más alto, Kubernetes es un conjunto de API que puede utilizar
para implementar contenedores en un conjunto de nodos llamado clúster.
- El sistema se divide en un conjunto de componentes primarios que se
ejecutan como plano de control y un conjunto de nodos que ejecutan
contenedores.
- En Kubernetes, un nodo representa una instancia informática como una
máquina.
- Tenga en cuenta que esto es diferente a un nodo en Google Cloud, que es
una máquina virtual que se ejecuta en un motor de computadora.
- Puede describir un conjunto de aplicaciones y cómo deben interactuar entre
sí, y Kubernetes determina cómo hacer que eso suceda.

La implementación de contenedores en nodos mediante el uso de un contenedor

alrededor de uno o más contenedores es lo que define un pod.
Un pod es la unidad más pequeña de Kubernetes que puede crear o implementar.
Representa un proceso en ejecución en su clúster como un componente de su
aplicación o como una aplicación completa.

Generalmente, solo tiene un contenedor por cápsula, pero si tiene varios

contenedores con una base dura dependencia, puede empaquetarlos en un solo pod
y compartir recursos de red y almacenamiento entre ellos.

El pod proporciona una IP de red única y un conjunto de puertos para sus

contenedores, y opciones configurables que rigen cómo deben ejecutarse sus
contenedores.
Una forma de ejecutar un contenedor en un pod en Kubernetes es usar el comando
kubectl run, que inicia una implementación con un contenedor ejecutándose
dentro de un pod.

Una implementación representa un grupo de réplicas del mismo pod y mantiene

sus pods en ejecución incluso cuando fallan los nodos en los que se ejecutan.

Una implementación podría representar un componente de una aplicación o

incluso una aplicación completa.
Para ver una lista de los pods en ejecución en su proyecto, ejecute el comando
kubectl get pods.

Kubernetes crea un servicio con una dirección IP fija para sus pods.

Y un controlador dice: necesito conectar un equilibrador de carga externo con una

dirección IP pública a ese servicio para que otras personas fuera del clúster
puedan acceder a él.

En GKE, el balanceador de carga se crea como balanceador de carga de red.

Un servicio es una abstracción que define un conjunto lógico de pods y una
política para acceder a ellos.

A medida que las implementaciones crean y destruyen pods, a los pods se les
asignarán sus propias direcciones IP, pero esas direcciones no permanecen
estables con el tiempo.

Un grupo de servicios es un conjunto de pods y les proporciona un punto final

estable o una dirección IP fija.

Por ejemplo, si crea dos conjuntos de pods llamados frontend y backend, y los
coloca detrás de sus propios servicios, los pods de backend pueden cambiar, pero
los pods de frontend no son conscientes de ello.
Simplemente se refieren al servicio backend.
Para escalar una implementación, ejecute el comando kubectl scale.

En este ejemplo, se crean tres pods en su implementación, se colocan detrás del

servicio y comparten una dirección IP fija.

También puedes usar el escalado automático con otros tipos de parámetros.

Por ejemplo, puede especificar que la cantidad de pods debe aumentar cuando la
utilización de la CPU alcanza un límite determinado.
Hasta ahora, hemos visto cómo ejecutar comandos imperativos como exponer y
escalar.
Esto funciona bien para aprender y probar Kubernetes paso a paso.
Pero la verdadera fortaleza de Kubernetes surge cuando se trabaja de forma
declarativa.
En lugar de emitir comandos, usted proporciona un archivo de configuración que le
indica a Kubernetes cómo desea que se vea el estado deseado, y Kubernetes
determina cómo hacerlo.
Esto se logra utilizando un archivo de configuración de implementación.

Puede verificar su implementación para asegurarse de que se esté ejecutando la

cantidad adecuada de réplicas, utilizando kubectl get implementaciones o kubectl
describe implementaciones.
Para ejecutar cinco réplicas en lugar de tres, todo lo que debe hacer es actualizar
el archivo de configuración de implementación y ejecutar el comando kubectl
apply para usar el archivo de configuración actualizado.
Aún puede llegar a su punto final como antes utilizando los servicios kubectl get
para obtener la IP externa del servicio y llegar a la dirección IP pública de un
cliente.

La última pregunta es, ¿qué sucede cuando deseas actualizar una nueva versión
de tu aplicación?
Bueno, desea actualizar su contenedor para mostrar código nuevo a los usuarios,
pero implementar todos esos cambios al mismo tiempo sería arriesgado.
Entonces, en este caso, usaría kubectl rollout o cambiaría su archivo de
configuración de implementación y luego aplicaría el cambio usando kubectl
apply.
Luego se crearán nuevos pods de acuerdo con su nueva estrategia de
actualización.
A continuación se muestra una configuración de ejemplo que creará nuevos pods
de versión individualmente y esperará a que haya un nuevo pod disponible antes
de destruir uno de los pods antiguos.

Ahora que tenemos un conocimiento básico de los contenedores y Kubernetes,

hablemos de Google Kubernetes Engine o GKE.

GKE:

GKE: Es un servicio de Kubernetes administrado y alojado en Google en la nube.

 - El entorno de GKE consta de varias máquinas, específicamente instancias
de motores de cómputo, agrupadas para formar un clúster.
- Puede crear un clúster de Kubernetes con el motor de Kubernetes mediante
Google Cloud Console o el comando gcloud proporcionado por el kit de
desarrollo de software en la nube.
- Los clústeres de GKE se pueden personalizar y admiten diferentes tipos de
máquinas, cantidad de nodos y configuraciones de red.

Kubernetes proporciona los mecanismos a través de los cuales interactúa con su

clúster.

Los comandos y recursos de Kubernetes se utilizan para:

- Implementar y administrar aplicaciones

- Realizar tareas de administración
- Establecer políticas
- Monitorear el estado de las cargas de trabajo implementadas.

Estos incluyen:
 - El equilibrio de carga de Google Cloud para instancias de motores de
computación.
- Grupos de nodos para designar subconjuntos de nodos dentro de un clúster
para mayor flexibilidad.
- Escalado automático de la instancia de nodo de su clúster.
- Recuento, actualizaciones automáticas para el software de nodos de su
clúster.
- Reparación automática de nodos para mantener su salud y disponibilidad,
- Registro y monitoreo con el paquete de operaciones de Google Cloud para
obtener visibilidad de su clúster.

Para iniciar Kubernetes en un clúster en GKE, ejecuta este comando: gcloud

container clusters create k1.
Desarrollo de aplicaciones en la nube (Cloud Run):

Empezaremos con Cloud Run, una plataforma de procesamiento administrada que

ejecuta contenedores sin estado a través de solicitudes web o eventos de
Pub/Sub.

- Cloud Run funciona sin servidores.

- Cloud Run funciona sin servidores.
- Se basa en Knative, una API abierta y un entorno de ejecución basado en
Kubernetes.
- Puede administrarse completamente en Google Cloud, en Google Kubernetes
Engine o en cualquier plataforma que ejecute Knative.
- Cloud Run es rápido.
- Puedes aumentar o reducir la escala automáticamente desde cero casi de
inmediato y solo se cobra por los recursos que se usan, calculados con una
precisión de 100 milisegundos, así que nunca pagarás por un aprovisionamiento
excesivo de los recursos.
El flujo de trabajo de desarrollador de Cloud Run es un proceso directo de tres
pasos.
- Primero, escribe la aplicación con tu lenguaje de programación favorito,
esta aplicación debe iniciar un servidor que escuche solicitudes web.
- Segundo, compila y empaqueta tu aplicación en una imagen de contenedor.
- Tercero, la imagen de contenedor se envía a Artifact Registry para que
Cloud Run pueda implementarla, cuando implementes tu imagen de
contenedor, obtendrás una URL HTTPS única.

Luego, Cloud Run inicia tu contenedor según demanda para atender las solicitudes
y asegura que todas las solicitudes entrantes se atiendan por medio de la adición y
sustracción dinámicas de contenedores.
Cloud Run funciona sin servidores, eso significa que tú, como desarrollador,
puedes enfocarte en compilar una aplicación y no en la construcción y el
mantenimiento de la infraestructura que la respalda.

En algunos casos de uso, un flujo de trabajo basado en contenedores es ideal

porque ofrece una gran transparencia y flexibilidad.

A veces, solo buscas una forma de convertir el código fuente en un extremo

HTTPS y deseas que tu proveedor se asegure de que tu imagen de contenedor sea
segura, esté bien configurada y se cree de forma coherente.
Puedes usar un flujo de trabajo basado en contenedores o uno basado en código
fuente.
El segundo enfoque implementará el código fuente en lugar de una imagen de
contenedor.
Luego, Cloud Run compila el código fuente y empaqueta la aplicación en una
imagen de contenedor.

Cloud Run logra esto con Buildpacks, un proyecto de código abierto.

Cloud Run controla la entrega HTTPS por ti, por lo que solo debes preocuparte de
controlar las solicitudes web y puedes dejar que Cloud Run se encargue de agregar
la encriptación.
El modelo de precios de Cloud Run es único, ya que solo pagas por los recursos
del sistema que usas mientras un contenedor controla las solicitudes web, con un
nivel de detalle de 100 milisegundos, y cuando se inicia o apaga.
No pagas por nada si tu contenedor no controla solicitudes.
Además, existe una pequeña tarifa por cada millón de solicitudes que entregas.
El precio del tiempo del contenedor aumenta con la CPU y la memoria.

Puedes usar Cloud Run para ejecutar objetos binarios compilados para Linux de 64
bits.
Esto significa que puedes usar Cloud Run para ejecutar aplicaciones web escritas
con lenguajes populares, como Java, Python, Node.js, PHP, Go y C++.

También puedes ejecutar código en lenguajes menos populares, como COBOL,

Haskell y Perl.
Mientras tu aplicación controle solicitudes web, no tendrás problemas.
Cloud Funtions:

Muchas aplicaciones contienen partes controladas por eventos, por ejemplo, una
aplicación que les permite a los usuarios subir imágenes.
Cuando esto sucede, es posible que la imagen deba procesarse de diferentes
formas; es decir, que se deba convertir en un formato estándar, se cambie el
tamaño de una miniatura y se almacene cada archivo nuevo en un repositorio.
Esta función podría integrarse en una aplicación, pero luego tendrías que
proporcionar recursos de procesamiento para ella, ya sea que ocurra una vez cada
milisegundo o una vez cada día.
Con Cloud Functions, puedes escribir una función de un solo propósito que
complete las manipulaciones de imagen necesarias y, luego, hacer que se ejecute
automáticamente cuando se suba una imagen nueva.
Cloud Functions Permite:
- Solución de procesamiento ligera, asíncrona y basada en eventos.
- Permite crear funciones pequeñas de un solo propósito que responden a
eventos, sin tener que administrar servidores ni entornos de ejecución.
- Estas funciones pueden usarse para crear flujos de trabajo de aplicaciones
desde tareas de lógica empresarial individuales.
- También puede conectar y extender los servicios de nube.
- Se te factura a los 100 milisegundos más cercanos, pero solo mientras se
ejecute tu código.
- Cloud Functions admite escribir código fuente en varios lenguajes de
programación, incluidos Node.js, Python, Go, Java, NET Core, Ruby y PHP.
-
Los eventos de Cloud Storage y Pub/Sub pueden activar Cloud Functions
asíncronamente, o bien puedes usar la invocación HTTP para una ejecución
síncrona.
Cloud Shell proporciona lo siguiente:

• VM temporal de Compute Engine

• Acceso mediante línea de comandos a la instancia a través de un
navegador
• 5 GB de almacenamiento en disco persistente ($HOME dir)
• SDK de Cloud preinstalado y otras herramientas
• gcloud: para trabajar con Compute Engine y muchos servicios de Google
Cloud
• gcloud storage: para trabajar con Cloud Storage
• kubectl: para trabajar con Google Kubernetes Engine y Kubernetes
• bq: para trabajar con BigQuery
• Compatibilidad con lenguajes Java, Go, Python, Node.js, PHP y Ruby
• Función de vista previa en la Web
• Autorización integrada para acceder a instancias y recursos

La consola de GCP permite hacer tareas no disponibles en Cloud Shell y

viceversa.

Por ejemplo, la consola de GCP puede hacer un seguimiento del contexto de tus
actividades de configuración usar la API de Cloud para determinar a partir del estado
del sistema actual qué opciones son válidas y realizar actividades repetitivas y más
provechosas por ti.
Cloud Shell, por el contrario, brinda un control detallado y preciso y sus comandos
permiten crear secuencias de comandos de actividades y automatizarlas.
Pero no consideres a la consola y Cloud Shell como herramientas alternativas velas
como una interfaz extremadamente flexible y potente.

Jenkins: Es un entorno de integracion continua de codigo abierto. En el, puedes definir los
trabajos para realizar tareas como la ejecucion de una compilacion programada de software y
crear una copia de seguridad de datos. Ten en cuenta que el software instalado como parte de
Jenkins se muestra a la izquierda de la descripcion.