martes, 29 de agosto de 2017

Niveles de servicio de red [Tiers]

Introducción a los "Niveles de Servicio de red" [Tiers].

Desde Google Cloud Networking nos anuncian Network Service Tiers Alpha, convirtiendo Google Cloud Platform (GCP) en la primera nube pública principal en ofrecer una red con políticas de servicio "Tiers". Para optimizar el rendimiento eligiendo Premium Tier, que utiliza la red global de Google con una calidad de servicio sin precedentes y optimiza el coste, utilizando el nuevo nivel , ademas nos han ajustado el precios con un rendimiento comparable al de otras nubes públicas.

"En los últimos 18 años, en Google han  construido la red más grande del mundo, que en algunos casos ofrece el 25-30% de todo el tráfico de Internet", dijo Urs Hölzle, SVP Technical Infrastructure de Google. "Ponemos a su disposición de la misma infraestructura que Premium Tier. Puede elegir, es posible que prefiera una alternativa más barata y de menor rendimiento.Con las políticas de servicio de red, puede elegir la red adecuada para cada aplicación ".

Potencia del nivel superior

Si utiliza Google Cloud  ya utiliza el potente nivel superior. Premium Tier ofrece tráfico a través de la red global altamente confiable de Google, bien provista y de baja latencia. Esta red consta de una extensa red privada global de fibra con más de 100 puntos de presencia (POPs) en todo el mundo. Mediante esta medida, la red de Google es la más grande de cualquier proveedor de cloud público.





En la opción Premium Tier, el tráfico entrante de tu usuario final a tu aplicación en Google Cloud entra en la red privada de alto rendimiento de Google en el POP más cercano a tu usuario final y GCP entrega este tráfico a tu aplicación a través de su red privada.


Envío de tráfico entrante y saliente

Del mismo modo, GCP entrega tráfico saliente de su aplicación a los usuarios finales en la red de Google y sale al POP más cercano a ellos, dondequiera que los usuarios finales estén en todo el mundo. Por lo tanto, la mayor parte de este tráfico llega a su destino con un solo salto al ISP del usuario final, por lo que goza de la congestión mínima y el máximo rendimiento.

El Diseño de red de Google se creo para que sea altamente redundante, para garantizar la alta disponibilidad de sus aplicaciones. Existen al menos tres rutas independientes (redundancia N + 2) entre dos ubicaciones de la red de Google, lo que ayuda a garantizar que el tráfico continúe fluyendo entre estas dos ubicaciones incluso en caso de una interrupción. Como resultado, con Premium Tier, su tráfico no se ve afectado por un solo corte de fibra. En muchas situaciones, el tráfico puede fluir hacia y desde su aplicación sin interrupción incluso con dos cortes simultáneos de fibra.

Los clientes de GCP utilizan Global Load Balancing, otra característica Premium Tier. El Cliente de Google Cloud no sólo obtiene la simplicidad de administración de un único IP virtual IPv4 o IPv6 IP virtual (VIP), sino que también puede expandirse de manera transparente entre regiones y desbordarse o saltar si falla en otras regiones.
Con Premium Tier, utiliza la misma red que ofrece Google Search, Gmail, YouTube y otros servicios, así como los servicios de clientes como The Home Depot, Spotify y Evernote.

    "El 75% de homedepot.com ya está disponible desde Google Cloud, y desde el principio, queríamos correr en varias regiones para una tener alta disponibilidad." La red global de Google es una de las características más fuertes para elegir Google Cloud.

    - Ravi Yeddula, Director Senior de Arquitectura de Plataformas y Desarrollo de Aplicaciones, The Home Depot.

Introducción al Nivel Estándar

Nuestro nuevo nivel estándar ofrece una calidad de red comparable a la de otras grandes nubes públicas, y a un precio inferior a nuestro Nivel Premium. ¿Por qué Standard Tier es menos costoso? Debido a que entregamos su tráfico de salida de GCP a Internet a través de redes de tránsito (ISP) en lugar de la red de Google.
Envío de tráfico entrante y saliente

Del mismo modo, entregamos su tráfico de entrada, desde el usuario final a GCP, en la red de Google sólo en la región donde reside su destino GCP. Si su tráfico de usuario se origina en una región diferente, su tráfico viajará primero por redes de transporte (ISP) hasta que llegue a la región del destino de GCP.

Standard Tier proporciona un rendimiento y una disponibilidad de red más bajos en comparación con Premium Tier. Dado que entregamos su tráfico entrante y saliente en la red de Google sólo en el salto corto entre GCP y el POP más cercano, las características de rendimiento, disponibilidad y redundancia de Standard Tier dependen del proveedor de tránsito que transporta su tráfico. Su tráfico puede experimentar congestión o interrupciones más frecuentes en relación con Premium Tier, pero a un nivel comparable a otras nubes públicas importantes.

También proporcionamos servicios de red regionales en Nivel estándar, como el nuevo servicio regional de Balanceo de carga de la nube. En este nivel, su IP virtual de equilibrio de carga (VIP) es regional, similar a otras ofertas de nube pública y agrega complejidad de administración en comparación con el Balanceo de carga global Premium Tier, si requiere una implementación de varias regiones.

Comparar el rendimiento de los niveles

Google gestino y permitió a Cedexis,  con herramientas de monitorización y de rendimiento de Internet y herramientas de optimización Empresa, para poder tomar mediciones de rendimiento preliminares para ambos niveles de servicio de red. Como se esperaba, Premium Tier ofrece un rendimiento más alto y una latencia más baja que Standard Tier. Puede ver los cuadros de resumen en vivo en www.cedexis.com/google-reports/ en la sección "Red Tiers".Cedexis también detalla su metodología de pruebas en su sitio web.

El siguiente gráfico de Cedexis muestra el rendimiento para Premium y Standard Tier para el tráfico de balanceo de carga HTTP en el percentil 50. El rendimiento estándar (línea azul) es de 3,223 kbps mientras que Premium (línea verde) es 5,401 kbps, lo que hace que el rendimiento Premium sea 1,7x veces el estándar. Vea el gráfico de Cedexis a continuación:

 
En general, Premium Tier muestra un rendimiento considerablemente mayor, en cada percentil, que en el nivel estándar.

Comparar los precios de los niveles

En Google están introduciendo nuevos precios para Premium y Standard Tiers. Puede consultar los precios detallados de ambos niveles aquí. Este pago de precios entrará en vigor cuando los niveles de servicio de red se hagan disponibles en forma genérica (GA). Mientras que en alfa y beta, se aplica el precio de salida de Internet existente.

Con el nuevo precio de Network Tiers (efectivo en GA), el tráfico de salida (GCP a Internet) tiene un precio 24-33% más bajo en Nivel estándar que en Nivel Premium para Norteamérica y Europa. El nivel estándar es menos costoso que las opciones de salida de Internet ofrecidas por otros proveedores de nube públicos importantes (basados ​​en los precios publicados típicos para julio de 2017). El tráfico entrante permanece libre para Premium y Standard Tiers. También cambiaremos nuestros precios basados ​​en destinos actuales para Premium Tier y para que se basen tanto en el origen como en el destino del tráfico, ya que el costo del tráfico de red varía con la distancia que recorre su tráfico en la red de Google. En contraste, el tráfico de Nivel Estándar se basará en su origen, ya que no viaja mucho por la red de Google.

Elija el nivel correcto

El potente nivel superior sigue siendo el nivel predeterminado para sus cargas de trabajo. Aquí hay un árbol de decisiones para ayudarle a elegir el nivel que mejor se adapte a sus necesidades.

Configure el nivel para su (s) aplicación (es)

Una misma  opción no se ajusta a todos, y sus aplicaciones en Google Cloud suelen tener diferentes requisitos de disponibilidad, rendimiento, huella y costo. Configure el nivel en el nivel del recurso (por instancia, plantilla de instancia, equilibrador de carga) si desea un control granular o en el nivel general del proyecto si desea utilizar el mismo nivel en todos los recursos.

 

Pruebe los niveles de servicio de red hoy


    "Los clientes de Cloud quieren opciones en cuanto a niveles de servicio y costo. Hacer coincidir el servicio adecuado con los requisitos empresariales adecuados proporciona la alineación necesaria para los clientes. Google es el primer proveedor de cloud público que reconoce que en la versión alpha de Network Service Tiers. Premium Tier atiende a aquellos que necesitan una calidad garantizada y Nivel Estándar a aquellos que necesitan costos más bajos o tienen una necesidad limitada de redes globales ".

    - Dan Conde, Analista de ESG

Para obtener más información, visite el sitio web de Network Service Tiers y conceda a los niveles de servicios de red un giro al inscribirse en alfa.

lunes, 28 de agosto de 2017

Puppet para Google Cloud Platform

 Puppet en Google Cloud.


La capacidad de controlar programando las maquinas virtuales con herramientas que conocen y ofrecen y entregan una gran diferencia para los desarrolladores que crean aplicaciones nativas de la nube. Es por eso que hoy se lanzan  y abren un conjunto de módulos integrales para mejorar la capacidad de los usuarios para administrar los recursos de Google Cloud Platform (GCP) utilizando Puppet o DSL. Los nuevos módulos siguen el modelo de convergencia de objetos de Puppet, lo que le permite definir el estado deseado de sus recursos de GCP que nuestros proveedores aplicarán directamente usando el estandar de Puppet.

Los nuevos módulos soportan los siguientes productos:


Estos nuevos módulos son Puppet Approved, que han pasado la rigurosa calidad y la certificación de revisión del equipo de Puppet Engineering, y son de código abierto bajo la licencia Apache-2.0, disponible en el repositorio Github de GCP.

También publicamos un módulo de autenticación unificado que proporciona un solo mecanismo de autenticación para todos los módulos.

Los módulos han sido probados en CentOS, Debian, Ubuntu, Windows y otros sistemas operativos. Consulte la matriz de soporte de sistema operativos para conocer los detalles de compatibilidad. Trabajan con Puppet Open Source y Puppet Enterprise.

Para obtener más información y verlos en acción, regístrese para el seminario web con Cody Herriges y con Puppet el 13 de septiembre de 2017.

El poder de Puppet 

Es importante tener en cuenta que Puppet no es un lenguaje de scripting. Más bien, sigue un modelo de convergencia de objetos, lo que le permite definir un estado deseado para su recurso, que nuestros proveedores lo hacen aplicando los cambios necesarios.

En otras palabras, con Puppet, no dices "ejecuta esta lista de comandos para instalar Apache en mi máquina", dices que "Apache debería estar instalado y configurado." Hay algunos matices aquí, pero con este último,Puppet analiza instala y configura y certifca si Apache está instalado, verifica las dependencias correctas, lo actualiza si no está en la versión correcta y, lo más importante, no hace nada si todo es bueno. Puppet ya entiende las diferencias de implementación a través del sistema operativo y se encargará de hacer lo correcto para su distribución elegida.

Seguir un modelo de convergencia de objetos tiene varios beneficios: Hace que su recurso manifieste la declaración, abstrayendo varios detalles (por ejemplo, acciones específicas del sistema operativo); Y hace que las definiciones sean más fáciles de leer, modificar y auditar. El siguiente manifiesto crea un clúster completo de Google Container Engine, en sólo 15 líneas de código.

gauth_credential { 'mycred':
  provider => serviceaccount,
  path     => '/home/nelsona/my_account.json',
  scopes   => ['https://www.googleapis.com/auth/cloud-platform'],
}

gcontainer_cluster { 'myapp-netes':
  ensure             => present,
  initial_node_count => 2,
  node_config        => {
    machine_type => 'n1-standard-4', # we want a 4-core machine for our cluster
    disk_size_gb => 500,             # ... and a lot of disk space
  },
  zone               => 'us-central1-f',
  project            => 'google.com:graphite-playground',
  credential         => 'mycred',
}

Para obtener ejemplos específicos de cómo utilizar Puppet con los módulos GCP individuales, visite sus respectivas páginas de Forge.

Empezando con Puppet en GCP

Para empezar con  Puppet y GCP, siga estos pasos básicos:

Instale los módulos apropiados.
  1. Obtenga una cuenta de servicio con privilegios en los recursos GCP que desee administrar y habilite las API para cada uno de los servicios GCP que desea utilizar.
  2. Describa su infraestructura de GCP en Puppet.
    1. Defina un recurso gauth_credential.
    2. Defina los recursos de GCP.
  3. Aplique su manifiesto.
Vamos a seguir estos pasos con más detalle.

1. Instale sus módulos

Todos los módulos de Google para Puppet están disponibles en Puppet Forge. También se entrega un módulo de "bundle" que instala cada módulo GCP a la vez, para que pueda elegir la granularidad del código que extrae de su infraestructura.

Nota: los módulos de Google no requieren privilegios de administrador ni privilegios / alcances especiales en las máquinas que se están ejecutando. Es seguro instalar los módulos como un usuario regular o en su maestro de Puppet. Instalar en el maestro si lo desea distribuido a todos los clientes. 

El módulo de autenticación depende de algunas gemas publicadas por Google. Al igual que con todo lo relacionado con la configuración del sistema, puede instalar las gemas de Puppet a si mismo.


$ puppet apply <<EOF
package { [
    'googleauth',
    'google-api-client',
  ]:
    ensure   =< present,
    provider =< gem,
}
EOF


Este es el comando para Instalar todos los módulos Puppet con un solo comando:


puppet module install google/cloud


O bien, tambien puede instalar los módulos para productos seleccionados:


puppet module install google/gcompute    # Google Compute Engine
puppet module install google/gcontainer  # Google Container Engine
puppet module install google/gdns        # Google Cloud DNS
puppet module install google/gsql        # Google Cloud SQL
puppet module install google/gstorage    # Google Cloud Storage
Una vez instalado, verifique la integridad de los módulos ejecutando:


puppet module list


Debería ver una salida similar a:


$ puppet module list
/home/nelsona/.puppetlabs/etc/code/modules
├── google-cloud (v0.1.0)
├── google-gauth (v0.1.0)
├── google-gcompute (v0.1.0)
├── google-gcontainer (v0.1.0)
├── google-gdns (v0.1.0)
├── google-gsql (v0.1.0)
└── google-gstorage (v0.1.0)
/opt/puppetlabs/puppet/modules (no modules installed)



2. Obtenga las credenciales de su cuenta de servicio y active las API

Para garantizar la máxima flexibilidad y portabilidad, toda autenticación y autorización a los recursos de GCP se debe realizar a través de credenciales de cuenta de servicio. El uso de cuentas de servicio le permite restringir los privilegios al mínimo necesario para realizar el trabajo.

Nota: Como las cuentas de servicio son transferibles, no es necesario ejecutar Puppet dentro de GCP. Nuestros módulos se ejecutan en cualquier ordenador con acceso a Internet, incluso en otros proveedores de la nube. Por ejemplo, puede ejecutar despliegues desde una gestión de sistema CI / CD, como Travis o Jenkins, o desde su propia máquina de desarrollo. 

Haga clic aquí para obtener más información sobre las cuentas de servicio y sobre cómo crearlas y habilitarlas.

También asegúrese de haber habilitado las API para cada uno de los servicios GCP que desea utilizar.

3a. Definir mecanismo de autenticación

Una vez que tenga su cuenta de servicio, añada este bloque a su manifiesto para comenzar a autenticar con él. El título del recurso, aquí 'mycred' se hace referencia en los objetos en el parámetro credencial.

gauth_credential { 'mycred':
  provider => serviceaccount,
  path     => '/home/nelsona/my_account.json',
  scopes   => ['https://www.googleapis.com/auth/cloud-platform'],
}


Para obtener más información sobre cómo configurar o personalizar la autenticación, visite la documentación de autenticación de Google.

3b. Define tus recursos

Se puede administrar cualquier recurso para el que se proporcionamos un "type". El siguiente ejemplo crea un clúster Kubernetes en Google Container Engine. Para obtener la lista completa de recursos que puede administrar, consulte el vínculo correspondiente de la documentación del módulo o mire este sumario.

gcontainer_cluster { 'myapp-netes':
  ensure             => present,
  initial_node_count => 2,
  node_config        => {
    machine_type => 'n1-standard-4', # we want a 4-core machine for our cluster
    disk_size_gb => 500,             # ... and a lot of disk space
  },
  project            => 'google.com:graphite-playground',
  credential         => 'mycred',
}

4. Aplique el manifiesto

A continuación, dígale a Puppet que haga cumplir y lleve sus recursos al estado descrito en el manifiesto. Por ejemplo:

puppet apply <your-file.pp>

Tenga en cuenta que puede aplicar el manifiesto independiente, una vez o periódicamente en segundo plano mediante el agente de puppet.

Próximos pasos

Ahora ya está listo para comenzar a administrar sus recursos de GCP con Puppet y comenzar a aprovechar los beneficios de la gestión de la configuración de nube. Se seguiran mejorando los módulos y añadiendo cobertura a más productos de Google. También estan en Google en el proceso de preparación de la tecnología utilizada para crear estos módulos para su lanzamiento como código abierto. Si tiene preguntas sobre este trabajo, visite el foro Puppet on GCP Discussions o comuníquese con nosotros en puppet-on-gcp@google.com.

Recomendaciones

viernes, 25 de agosto de 2017

Introducción App Engine Firewall para tu APP

 App Engine firewall en tu app.

Una característica clave de seguridad para los desarrolladores y administradores de aplicaciones es poder permitir o denegar las solicitudes entrantes basadas en direcciones IP de origen. Esta capacidad le puede ayudar a realizar pruebas de producción sin exponer su aplicación al mundo, bloquear el acceso a su aplicación desde geografías específicas o bloquear solicitudes de un usuario malintencionado.

Hoy, google  anuncia la versión beta del firewall de Google App Engine. Con el firewall de App Engine, simplemente proporciona un conjunto de reglas, ordénelas por prioridad y especifique una dirección IP, o un conjunto de direcciones IP, para bloquear o permitir y nos encargaremos del resto.

Cuando el firewall de App Engine recibe una solicitud que ha configurado para que se le niegue, devuelve una respuesta HTTP 403 Prohibida sin golpear su aplicación. Si su aplicación está inactiva, esto evita que se generen nuevas instancias y si recibe tráfico pesado, la solicitud denegada no se agregará a su carga, ni le costará dinero.

El firewall de App Engine reemplaza la necesidad de una solución basada en código dentro de la aplicación que gestione solicitudes, pero que puede costarle recursos y aún así exponer su aplicación.

Introducción al firewall de App Engine

Puedes configurar las reglas de firewall de App Engine en Google Cloud Console, así como con la API de administración de App Engine o la herramienta de línea de comandos gcloud.

Digamos que le gustaría probar su aplicación y dar acceso sólo a los navegadores de la red privada de su empresa. Abra las reglas de firewall en la consola de Cloud y verá una regla predeterminada que permite todo el tráfico a su aplicación.

En primer lugar, agregue una nueva regla que permita el tráfico sólo desde el rango de direcciones IP procedentes de su red privada. A continuación, actualice la regla predeterminada para denegar todo el tráfico.




Al igual que con la semántica típica de firewall, el firewall de App Engine evalúa primero las reglas con un valor de prioridad inferior, seguido por las reglas con un valor más alto. En el ejemplo anterior, la regla Permitir con una prioridad de 100 se evalúa primero, seguida por la regla predeterminada.

Para asegurarse de que su conjunto de reglas de firewall está funcionando según lo previsto, puede probar una dirección IP para ver si una solicitud procedente de esta dirección se permitiría o denegaría.

Desde la consola de nube, haga clic en el link test ip address en la opción Reglas del cortafuegos.

La respuesta indica si la solicitud puede continuar e indica la regla de firewall específica que coincide con la dirección IP proporcionada.



Con el firewall de App Engine, es fácil configurar el acceso de red a tu aplicación y enfocarte en lo que más importa: tu aplicación, sin preocuparte por el control de acceso dentro de tu código. Consulte la documentación aquí.


El firewall de App Engine está en versión beta, así que evita usar esta funcionalidad en entornos de producción. Si tiene alguna pregunta, inquietud o si algo no funciona como era de esperar, puede publicar en el foro de Google App Engine,  o ponerse en contacto en el canal de aplicación de App Engine slack (# app-engine).

miércoles, 23 de agosto de 2017

Procesando grandes cantidades de datos con Google Cloud IoT y BigQuery

Cuando hablamos del internet de las cosas, posiblemente se nos venga a la cabeza un dispositivo, Arduino por ejemplo, conectado con algunos sensores que le suministran pequeñas cantidades de información. Sin embargo, si esto lo multiplicamos por cientos, miles o incluso millones, se convierte en un problema estructural tanto a nivel de gestión de dispositivos como de almacenamiento de datos.

Junto a esto, se suma la necesidad de tener acceso inmediato y consistente a la información que recogen los dispositivos, con el fin de satisfacer las demandas de los usuarios: paneles de información de metro actualizados, tráfico en las carreteras o la posición del coche que acabas de solicitar, por poner unos ejemplos.


Por lo tanto, para poder trabajar con gran cantidad de dispositivos y a su vez explotar la información que estos generan, la mejor opción es utilizar soluciones en la nube.

En BEEVA Labs hemos creado desde cero la infraestructura necesaria en Google Cloud para gestionar dispositivos IoT, procesando la información generada por éstos dentro de una base de datos BigQuery y en este articulo te contamos como hacerlo paso a paso.

IoT Core

La plataforma cloud de Google nos permite gestionar de forma fácil y segura nuestra infraestructura de dispositivos; proporcionándonos un sistema de gestión de credenciales basado en clave pública/privada RS256 o ES256.

La comunicación entre los dispositivos y la nube se realiza exclusivamente a través del protocolo de mensajería MQTT, utilizando el servicio Pub/Sub como puente. Es por ello, que todos los dispositivos deben estar suscritos a un tema MQTT por donde envían y reciben mensajes.

Arquitectura básica de Google Cloud IoT

A continuación se detallan los pasos a seguir para registrar un dispositivo en Cloud IoT y crear un tema en Pub/Sub:
  1. Activar las APIs de IoT y Pub/Sub.
  2. En Pub/Sub: crea un nuevo tema, quedando con el siguiente formato:
    projects/[nombre del proyecto]/topics/[nombre del tema]
  3. En IoT Core: crea un nuevo registro de dispositivos seleccionando nombre, región y el tema que hemos creado en el punto anterior.
  4. Aceptar la concesión de permisos que solicita Cloud IoT de editor de Pub/Sub.
  5. Creamos una clave pública/privada desde línea de comandos:
    RS256 openssl req -x509 -newkey rsa:2048 -keyout rsa_private.pem -nodes -out rsa_cert.pem -subj “/CN=unused”
    ES256openssl ecparam -genkey -name prime256v1 -noout -out ec_private.pem openssl ec -in ec_private.pem -pubout -out ec_public.pem
  6. Nuevo dispositivo: añade un dispositivo introduciendo nombre, marcando como “enable” el dispositivo, eligiendo el tipo de clave que hemos creado en el punto anterior (RS256 o ES256) y copiando la clave pública en el cuadro de texto. Por último, opcionalmente podemos definir la fecha de caducidad del dispositivo.

Dataflow & BigQuery

Google Cloud Dataflow es un servicio autoadministrado de procesamiento de datos por canalizaciones, capaz de tomarlos vía streaming o por lotes.

En este caso de estudio, la ventaja de Dataflow frente a otras soluciones como Cloud Functions es la completa integración que tiene con los servicios Pub/Sub y BigQuery; permitiendo realizar una comunicación entre ambos servicios sin tener que escribir ni una sola línea de código.

Por otra parte, BigQuery es la mejor solución si se plantea una explotación intensiva de grandes cantidades de datos (a nivel de terabytes) y almacenamiento casi ilimitado.

Arquitectura de comunicación entre Google Cloud IoT y BigQuery

A continuación se detallan los pasos a seguir para crear una tarea de Cloud Dataflow y una base de datos BigQuery:
  1. Activar las APIs de Dataflow y BigQuery.
  2. En BigQuery: crea un nuevo dataset especificando nombre y localización. Dentro de este dataset crea una tabla vacía, definiendo el nombre de la tabla y el nombre de los campos junto con el tipo (string, integer, date,…).
  3. Es importante que el nombre de los campos de la tabla coincidan con los nombres de los parámetros que se pasen por JSON desde el dispositivo.
  4. En Dataflow: crea una nueva tarea a partir de plantilla seleccionando “Pub/Sub de Cloud a BigQuery”; como parámetros introduce el tema creado al registrar el dispositivo “projects/[nombre del proyecto]/topics/[nombre del tema]” y los datos de la tabla creada en el punto anterior “[nombre del proyecto]:[nombre del dataset].[nombre de la tabla]”.
Una vez terminados estos pasos, podremos comenzar a publicar mensajes desde el dispositivo sobre el tema MQTT y veremos como en tiempo real se van haciendo inserts automáticamente sobre la base de datos.
La principal ventaja de utilizar un sistema autoadministrado como Dataflow o BigQuery, es que aunque el número de dispositivos crezca y el flujo de mensajes se incremente, no tenemos que realizar ninguna acción, como configurar un grupo de instancias con balanceo automático o ampliar cuotas de disco en la base de datos.

Fuente imagen principal: Massachusetts Bay Transit Authority by Barco
Artículo original publicado en BEEVA Labs por Javier López Martínez.

jueves, 17 de agosto de 2017

Curso de Google Cloud Platform (GCP) - IAM

Introducción a Google Cloud Platform usando IAM 
[by Miguel Arranz]

Esta vez y de la mano de  Miguel Arranz  en su canal de youtube os explica como funciona en Google cloud con la autenticación con IAM.


Parte AIM I



Parte AIM II

Si os gusta lo que hace se lo podeis  agradecédlo con un cafe virtual: https://ko-fi.com/mijack. :-).

martes, 15 de agosto de 2017

Empezar de 0 en Google Cloud y activar los 300$

Empezar de  0 en Google cloud y activar los 300$.

Partimos de  0  y entramos en Google Cloud en la consola y activamos los 300$ para usar en TODA la plataforma de google cloud.

Ademas vemos como ver que están activados esto 300$ y creamos y proyecto que se añade a esta consumo de demo.





Es una introducción muy sencilla y facíl Google Cloud permite el uso de 300$ durante un año o hasta que se terminen estos 300$.