miércoles, 21 de agosto de 2019

IOT la red de Sigfox y Google Cloud por fin en marcha.



¡Sigfox une fuerzas con el equipo del Programa Google Cloud for Startups para que sus miembros del Programa STARTER se beneficien del paquete Google Spark!

Si cumple con los requisitos de GCP * y ya está registrado en el Programa STARTER, recibirá $ 20,000 en Google Cloud Platform y Firebase Credits, válidos por 12 meses.

Más información sobre la activación de beneficios aquí.


¿Cómo empezar a usarlo?

¡Unase  a la próxima conferencia en línea de Sigfox Explore para descubrir cómo usar Sigfox con GCP!

Conocerá a Markku Lepisto, (Arquitecto de soluciones - APAC y Japón, Google Cloud Platform) que le dará una demostración en directo (on-line) de un caso de uso de seguimiento de activos utilizando:
Pycom + Atlas Geoloc + GCP + Maps.

Agenda:

  • ¿Cuál es la integración de Sigfox GCP y su valor?
  • Demostración en vivo de la configuración de integración con Sigfox Backend y Google Cloud
  • Ejemplo de dispositivo de extremo a extremo con Sigfox Sens'it
  • Demostración de Live Sens'it en GCP que incluye análisis de carga útil binaria, análisis en tiempo real y administración de la configuración del dispositivo
  • Diseño de ejemplo de seguimiento de activos con Pycom / Pytrack GPS, Sigfox Atlas Geolocation, Google BigQuery-GIS y Maps
  • Demostración de seguimiento de activos en vivo.
Link para unirse a la conferencia aqui.

miércoles, 14 de agosto de 2019

Cloud Run VS Cloud Functions: ¿Cuál es el más barato?

Autor: https://twitter.com/gblaquiere
Enlace original 




Elegir una solución desde un punto de vista técnico es importante, pero el coste de un servicio no debe olvidarse porque, en un entorno de escala automática, puede explotar sin previo aviso.
La comparación se realizó sólo en función de los precios y las cuotas y límites de cada producto. El rendimiento del procesamiento se supone igual en ambos

Cloud functions


El precio de las funciones en la nube se basa en la vCPU en GHz / sy la memoria en Gb / s, redondeada a los 100 ms más cercanos. La especificidad de las funciones es que puede ajustar la memoria y la velocidad de la CPU, pero no por separado. Ambos están vinculados, aumente la memoria si desea más MHz y viceversa.


El precio de salida de la red es una tarifa plana de $ 0,12 / Gb
Finalmente, las solicitudes se facturan a $ 0,40 el millón de solicitudes después de los primeros 2 millones de cuota gratuita.

Cloud Run (administrado)


El precio de Cloud Run se basa en vCPU / sy la memoria en Gb / s, redondeada a los 100 ms más cercanos. No es posible usar vCPU parcial por instancia. Su instancia siempre tiene 1 vCPU asignada. La memoria se puede ajustar de 128Mb a 2Gb

Una instancia puede manejar hasta 80 solicitudes concurrentes. Por lo tanto, para una instancia determinada, solo se le cobra cuando la instancia procesa al menos una solicitud.




La salida de la red se basa en el precio del Nivel Premium de la red después de 1 Gb de nivel gratuito.
Finalmente, las solicitudes se facturan a $ 0.40 cada millón de solicitudes después de los primeros 2 millones de solicitudes de cuota gratuita


En resumen


El costo de la red es ligeramente diferente con 5 Gb de nivel libre de salida para Cloud Functions y solo 1 para Cloud Run -> alrededor de $ 0.50 de diferencia. Pero el precio de salida de GB no es el mismo, y es más complejo en Cloud Run, basado en el Nivel Premium de red. En Europa y América del Norte, es notablemente más barato con Cloud Run comparado con Asia.

Las Cloud Functions permiten ajustar la velocidad de vCPU de acuerdo con la memoria utilizada. Pero solo puede manejar 1 solicitud por instancia.

Cloud Run siempre usa 1 vCPU; solo puedes ajustar la memoria. Pero Cloud Run puede procesar solicitudes concurrentes en la misma instancia.

Finalmente, el coste de la cantidad de solicitudes es estrictamente el mismo.

Por cierto, podemos considerar 2 casos principales de comparación: con solo 1 solicitud concurrente y con varias solicitudes simultáneas.

Para este caso se crea una GSheet para jugar con memoria, concurrencia y valores de requisitos de proceso.

Un caso de solicitud concurrente


En este caso, solo se compara el procesamiento de 1 solicitud. En este caso, Cloud Run y ​​Cloud Functions tienen exactamente 1 instancia para procesar esta solicitud única y, por lo tanto, solo se cobra esta instancia.

Este caso puede ocurrir si configura para una sola concurrencia en Cloud Run, o si tiene solicitudes dispersas y secuenciales a su servicio

Por lo tanto, en la misma condición, con 1 vCPU (2.4Ghz) y 2Gb de memoria, el precio y el rendimiento son estrictamente los mismos entre Cloud Run y ​​Cloud Functions.


Caso de varias solicitudes concurrentes

La mayoría de las veces, un servicio maneja varias solicitudes al mismo tiempo. Cloud Run tiene la capacidad de manejar hasta 80 solicitudes concurrentes con la misma instancia.

Por el contrario, Cloud Functions crea tantas instancias como las solicitudes concurrentes.
De este modo, más puede procesar la solicitud simultáneamente con Cloud Run, más barato es el servicio.




Que podemos valorar


La mejor opción depende de lo que desee optimizar, sus casos de uso y sus necesidades específicas.

Latencia más baja


Si su objetivo es la latencia más baja, elija Cloud Run.
De hecho, Cloud Run usa siempre 1 vCPU (al menos 2.4Ghz) y puede elegir el tamaño de memoria de 128Mb a 2Gb.

Con Cloud Functions, si se necesita el mejor rendimiento de procesamiento (2,4 Ghz de CPU), debe pagar 2 Gb de memoria. Si su necesidad de memoria es baja, las cloud function con 2 Gb de memoria son excesivas y cuestan nada.

Menor costo


Reducir los costos no siempre es la mejor estrategia para la satisfacción del cliente, pero la realidad empresarial puede requerirlo. De todos modos, depende mucho de su caso de uso.

Tanto Cloud Run como Cloud Function se redondean a los 100 ms más cercanos. Como podría jugar con la GSheet, las funciones en la nube son más baratas cuando el tiempo de procesamiento de 1 solicitud es inferior a los primeros 100 ms.

De hecho, puede ralentizar la vCPU de Cloud Functions, lo que tiene como consecuencia aumentar la duración del procesamiento, pero mientras se mantiene por debajo de 100 ms si lo ajusta bien. Por lo tanto, se utilizan menos Ghz / s y, por lo tanto, paga menos.

Por ejemplo, con un bajo requerimiento de procesamiento (se requieren 20Mhz) que requirió solo 128Mb de memoria, tiene:


  • Cloud Functions: 100 ms de procesamiento por un costo de $ 0.23e-6
  • Cloud Run: 8 ms de procesamiento por un costo de $ 2.4e-6





Claro, Cloud Functions es 10 veces más barato, pero sus clientes esperan 10 veces más. Y esta comparación de precios es cierta SOLO si tiene solicitudes secuenciales.

En este ejemplo, con más de 10 solicitudes simultáneas, ¡Cloud Run es más barato! De hecho, Cloud Run maneja hasta 80 solicitudes concurrentes en la misma instancia antes de crear (y facturar) una nueva.


Por el contrario, Cloud Functions maneja las solicitudes concurrentes en diferentes instancias y, por lo tanto, debe pagar cada instancia en ejecución además del sobrecoste de arranque en frío para cada
instancia creada.

Hay otro caso en el que las Cloud Functions son más baratas y es una buena idea ralentizar la vCPU: cuando una aplicación llama a las API y espera las respuestas. Tener una función con 200Mhz es suficiente y una vCPU completa de Cloud Run es exagerada (para ninguno o pocos procesos) y, por lo tanto, es costosa.

Limitación de instancia


En la página de Limitación y Cuota de cada producto, el número de instancias paralelas está limitado a 1000.

Sin embargo, con las Cloud Functions, es posible establecer un límite superior personalizado para limitar el número de instancias paralelas. Inicialmente lanzado para limitar el uso de recursos (por ejemplo, conexión de base de datos), también es una gran funcionalidad para limitar los gastos y establecer el límite superior del costo de su servicio. Pero siempre con un impacto negativo en la satisfacción del usuario en caso de saturación.

Cloud run aún no ofrece este tipo de limitación personalizable

Manejo de eventos


Las funciones en la nube se pueden activar mediante solicitudes HTTP (llamadas funciones HTTP) pero también por eventos activados en el entorno Google Cloud (llamadas funciones en segundo plano)

Por el contrario, los contenedores de Cloud Run solo pueden ser llamados por solicitudes HTTP. Sin embargo, es posible usar la suscripción de inserción de PubSub para impulsar los eventos de PubSub para que Cloud Run los procese. Además, también es posible publicar eventos de almacenamiento en el tema de PubSub y, por lo tanto, procesar eventos de almacenamiento con Cloud Run nuevamente a través de una suscripción push de PubSub. Pero no más.

Por lo tanto, a excepción de los eventos PubSub y Storage, las Cloud Functions son inevitables para todos los demás tipos de eventos. No hay elección posible.

Requisito de conexión VPC


Su aplicación sin servidor puede requerir algunos recursos privados solo disponibles en su VPC. Por ejemplo, un almacén de memoria para almacenamiento de clave-valor de baja latencia, o un acceso VPN / conexión directa para alcanzar recursos externos (OnPremise o en otra nube).

Las cloud Function permiten configurar un conector VPC para conectar sus funciones sin servidor a su VPC, y así enrutar el tráfico según sea necesario.
Hasta ahora, no era posible con Cloud Run administrado, pero podría cambiar a fines de 2019.

Que elegir

Antes de mi conclusión, me gustaría agregar algunas consideraciones adicionales, no directamente vinculadas al precio de la plataforma, sino también en todo el proceso de desarrollo, servicio y monitoreo.

A tener en cuenta sobre el costo

Las nubes públicas vienen con una nueva capacidad: el verdadero conocimiento del coste. En mi empresa, el coste de la nube generó miedos: ¡Woah, es caro! No, no lo es, pero es conocido, visible.

En un entorno local, es muy difícil saber el costo real por servicio, especialmente el costo humano o los recursos mutualizados (red, almacenamiento, alojamiento, ...).

Cuando elige una solución técnica, es importante tener en cuenta todas las piezas del proyecto y, en primer lugar, sus recursos humanos. Las funciones en el cloud parecen más baratas porque su caso de uso les queda bien. Pero, ¿su equipo puede desarrollar funciones en los idiomas disponibles?

En mi empresa, nuestra pila heredada (y experiencia) era PHP y C ++ y esto no se ajustaba a la capacidad de Cloud Functions. Por eso, los Docker fueron nuestra elección, incluso antes de que existiera el producto Cloud Run.

¿Realmente sabes el coste de tu equipo?

  • Riesgo de renuncia porque las personas no están bien con una nueva pila
  • Coste de la sesión de aprendizaje además de la ausencia de productividad durante el tiempo de aprendizaje.
  • La falta de calidad de código, fiabilidad, rendimiento y productividad debido a la nueva implementación de código.
Todas estas razones son, la mayoría de las veces, mucho más caras que el costo del proveedor de la nube.

Además de este aspecto humano, ¿cuál será el costo de la refactorización en caso de portabilidad? ¿Cuál será el costo de X% más de errores debido a las dificultades de las pruebas o la falta de experiencia en un nuevo idioma?

Aplicación crítica

Hoy, Cloud Run está en beta. En Google Cloud Platform, las versiones beta son realmente estables y se pueden usar en producción. Sin embargo, no existe un compromiso de Google con el servicio y el soporte puede ser menos eficiente.

Las funciones en la nube están en GA para Python 3, Node 8 y Go 1.11

En la aplicación de misión crítica con SLA restrictivo, esta puede ser la primera opción de criterio, por encima del costo mismo.

Límites y cuotas

Existen pocas diferencias entre los 2 servicios, pero pueden implicar un cambio organizacional o un rediseño de diseño de solución técnica. Este es un costo indirecto, pero a tener en cuenta si planea implementar cientos de funciones en el cloud con una alta velocidad de implementación.

De hecho, las cloud Function están limitadas a 1000 funciones por proyecto y a 120 minutos de compilación por día y por proyecto.

En Cloud Run, no hay límite en la compilación porque se realiza fuera de la plataforma, y ​​existe el mismo límite de 1000 servicios por proyecto. PERO un servicio puede servir a varios endpointss.

Otro aspecto es el tamaño de cada solicitud / respuesta 3 veces mayor con Cloud Run que con Cloud Functions. ¿Su caso de uso se ve afectado por esto?
Otros límites son difíciles de comparar o no son relevantes para una gran mayoría de proyectos.


Conclusión

Como se puede ver, la comparación de costos entre Cloud Functions y Cloud Run va más allá de simplemente comparar una lista de precios. Además, en sus proyectos, a menudo tendrá que usar las 2 soluciones para aprovechar sus fortalezas y capacidades.

La primera opción para el desarrollo es Cloud Run. Su portabilidad, su capacidad de prueba, su apertura en las bibliotecas, los idiomas y los archivos binarios le confieren demasiadas ventajas para, al menos, un precio similar, y a menudo con una ventaja real en el costo pero también en el rendimiento, en particular para solicitudes concurrentes. Incluso si necesita el mismo nivel de aislamiento de las funciones de la nube (1 instancia por solicitud), ¡simplemente configure el parámetro de concurrencia en 1!

Sin embargo, algunas razones, como el soporte de GA, la capacidad de VPC o los eventos, pueden obligarlo a elegir Cloud Functions, pero, la mayoría de las veces, no será por una razón de precios.

Finalmente, la variedad de casos de uso, las diferencias en la organización y la complejidad de los recursos humanos (habilidades, deseos, motivaciones) generan demasiadas combinaciones y solo puedo proporcionar consejos y cosas que no olvidar en su proceso de decisión. No es posible proporcionar una respuesta única.

En cualquier caso, asegúrese de elegir el socio adecuado, con un punto de vista externo, que lo ayude en este viaje, hable con sus equipos y trate de encontrar la mejor respuesta a sus casos de uso.

jueves, 1 de agosto de 2019

Cómo programar un script de Python en GCP


Tal vez estés ejecutando una consulta en BigQuery y descargando los resultados en BigTable cada mañana para realizar un análisis. O quizás necesite actualizar los datos en una tabla dinámica en Google Sheets para crear un histograma  para mostrar sus datos de facturación. En cualquier caso, a nadie le gusta hacer lo mismo todos los días si la tecnología puede hacerlo por ti. ¡Contempla la magia de Cloud Scheduler, Cloud Functions y PubSub!

Cloud Scheduler es un producto administrado de Google Cloud Platform (GCP) que te permite especificar una frecuencia para programar un trabajo recurrente. En pocas palabras, es un planificador de tareas gestionado ligero. Esta tarea puede ser un trabajo por lotes ad hoc, un trabajo de procesamiento de big data, herramientas de automatización de infraestructura, lo que sea. Lo bueno es que Cloud Scheduler se encarga de todo el trabajo ademas  se reintenta en caso de fallo e incluso le permite ejecutar algo a las 4 AM, para que no tenga que despertarse en medio de la noche para correr una carga de trabajo en otro momento fuera de hora punta.


Al configurar el trabajo, puedes determinar qué exactamente "disparará" en un momento concreto Puede tratarse de un publicación en un  PubSub,  o un end-point de  HTTP o una aplicación App Engine. En este ejemplo, publicaremos un mensaje a un tema de PubSub.

Nuestro tema de PubSub existe únicamente para conectar los dos extremos de nuestra canalización: es un mecanismo intermediario para conectar el trabajo de Cloud Scheduler y la función en cloud que contiene la secuencia de comandos de Python real que ejecutaremos. Esencialmente, el tema de PubSub actúa como una línea telefónica, proporcionando la conexión que permite que el trabajo del Programador del cloud  hable y la Función de la Nube para escuche. Esto se debe a que el trabajo de Cloud Scheduler publica un mensaje al tema. La función de nube se suscribe a este tema. Esto significa que se alerta cuando se publica un nuevo mensaje. Cuando recibe una alerta, ejecuta el script de Python.

The Code

SQL

Para este ejemplo,  mostraré un script de Python simple que quiero ejecutar diariamente a las 8 AM  y las 8 PM . El script es básico: ejecuta una consulta SQL en BigQuery para encontrar los repositorios populares de Github. Buscaremos específicamente qué propietarios crearon repositorios con la mayor cantidad de contenedores y en qué año se crearon. Usaremos datos del conjunto de datos público bigquery-public-data: sample, que contiene datos sobre los repositorios creados entre 2007 y 2012.

Nuestra consulta SQL tiene este aspecto:

SELECT
  SUM(repository.forks) AS sum_forks,
  repository.owner,
  EXTRACT(YEAR FROM PARSE_TIMESTAMP('%Y/%m/%d %H:%M:%S %z', repository.created_at)) AS year_created
FROM
  `bigquery-public-data.samples.github_nested`
WHERE
  repository.created_at IS NOT NULL
GROUP BY
  2,
  3
ORDER BY
  3 DESC

Python

Pronto pegaremos esta consulta en nuestro archivo github_query.sql. Esto se llamará en nuestro archivo main.py, que llama a una función principal que ejecuta la consulta en Python mediante el uso de Python Client Library para BigQuery.

Paso 1: asegúrese de tener Python 3 e instale e inicialice el SDK de google cloud. Lo siguiente les una guia a través de cómo crear el entorno GCP. Si desea probarlo localmente, asegúrese de haber seguido primero las instrucciones para configurar Python 3 en GCP.

Paso 2: crea un archivo llamado requirements.txt y copia y pega lo siguiente:

  google-cloud-bigquery
Paso 3: Crea un archivo llamado github_query.sql y pega en la consulta SQL desde arriba.

Paso 4: Cree un archivo llamado config.py y edítelo con sus valores para las siguientes variables.

Puede usar un conjunto de datos existente para esto o elegir un ID de un nuevo conjunto de datos que creará, solo recuerde el ID ya que lo necesitará para otorgar permisos más adelante.

  config_vars = {
    'project_id': [ENTER YOUR PROJECT ID HERE],
    'output_dataset_id': '[ENTER OUTPUT DATASET HERE]',
    'output_table_name': '[ENTER OUTPUT TABLE NAME HERE]',
    'sql_file_path': 'github_query.sql'
}
Paso 4: Cree un archivo llamado main.py que haga referencia a los dos archivos anteriores.

"""Function called by PubSub trigger to execute cron job tasks."""
import datetime
import logging
from string import Template
import config
from google.cloud import bigquery

def file_to_string(sql_path):
    """Converts a SQL file holding a SQL query to a string.
    Args:
        sql_path: String containing a file path
    Returns:
        String representation of a file's contents
    """
    with open(sql_path, 'r') as sql_file:
        return sql_file.read()


def execute_query(bq_client):
    """Executes transformation query to a new destination table.
    Args:
        bq_client: Object representing a reference to a BigQuery Client
    """
    dataset_ref = bq_client.get_dataset(bigquery.DatasetReference(
        project=config.config_vars['project_id'],
        dataset_id=config.config_vars['output_dataset_id']))
    table_ref = dataset_ref.table(config.config_vars['output_table_name'])
    job_config = bigquery.QueryJobConfig()
    job_config.destination = table_ref
    job_config.write_disposition = bigquery.WriteDisposition().WRITE_TRUNCATE
    sql = file_to_string(config.config_vars['sql_file_path'])
    logging.info('Attempting query on all dates...')
    # Execute Query
    query_job = bq_client.query(
        sql,
        job_config=job_config)

    query_job.result()  # Waits for the query to finish
    logging.info('Query complete. The table is updated.')

def main(data, context):
    """Triggered from a message on a Cloud Pub/Sub topic.
    Args:
        data (dict): Event payload.
        context (google.cloud.functions.Context): Metadata for the event.
    """
    bq_client = bigquery.Client()

    try:
        current_time = datetime.datetime.utcnow()
        log_message = Template('Cloud Function was triggered on $time')
        logging.info(log_message.safe_substitute(time=current_time))

        try:
            execute_query(bq_client)

        except Exception as error:
            log_message = Template('Query failed due to '
                                   '$message.')
            logging.error(log_message.safe_substitute(message=error))

    except Exception as error:
        log_message = Template('$error').substitute(error=error)
        logging.error(log_message)

if __name__ == '__main__':
    main('data', 'context')
Para implementar la función en GCP, puede ejecutar los siguientes comandos de gcloud. Esto especifica el uso de un tiempo de ejecución de Python 3.7,
La creación de un tema de PubSub con un nombre de su elección y la especificación de que esta función se activa cada vez que se publica un nuevo mensaje sobre este tema. También esta establecido el tiempo de espera al máximo que GCP ofrece de 540 segundos o nueve minutos.

gcloud functions deploy [FUNCTION_NAME] --entry-point main --runtime python37 --trigger-resource [TOPIC_NAME] --trigger-event google.pubsub.topic.publish --timeout 540s
Asegúrese de que primero cd en el directorio donde se encuentran los archivos antes de la implementación, de lo contrario no funcionará lo siguiente.

Especifica la frecuencia con la que se ejecutará la función de la nube en el tiempo cron de UNIX al configurar el programador del Cloud  con el indicador de programación. Esto significa que publicará un mensaje al tema de PubSub cada 12 horas en la zona horaria UTC, como se ve a continuación:

gcloud scheduler jobs create pubsub [JOB_NAME] --schedule [SCHEDULE] --topic [TOPIC_NAME] --message-body [MESSAGE_BODY]
donde [JOB_NAME] es un nombre único para un trabajo, [SCHEDULE] es la frecuencia para el trabajo en UNIX cron, como "0 * / 12 * * *" para ejecutar cada 12 horas, [TOPIC_NAME] es el nombre del tema creado en el paso anterior cuando implementó la función de nube, y [MESSAGE_BODY] es cualquier cadena. Un ejemplo de comando sería:


gcloud scheduler jobs create pubsub daily_job --schedule "0 */12 * * *" --topic my-pubsub-topic --message-body "This is a job that I run twice per day!"

Nuestro código de Python no usa el mensaje real. ¡Este es un trabajo que ejecuto dos veces por día! "" Publicado en el tema porque solo estamos ejecutando una consulta en BigQuery, pero vale la pena señalar que puede recuperar este mensaje y actuar. tal, como para fines de registro o de otro tipo.

Conceder permisos
Finalmente, abra la interfaz de usuario de BigQuery y haga clic en "Crear conjunto de datos" en el proyecto al que hizo referencia anteriormente.

Al crear la Función de la nube, creó una cuenta de servicio con el correo electrónico en el formato [PROJECT_ID] @ appspot.gserviceaccount.com. Copia este correo electrónico para el siguiente paso.

Pase el cursor sobre el ícono Más para este nuevo conjunto de datos.

Haga clic en "Compartir conjunto de datos".

En la ventana emergente, ingrese el correo electrónico de la cuenta de servicio. Dale permiso "Can Edit".

Ejecutar el trabajo:
Puede probar el flujo de trabajo anterior ejecutando el proyecto ahora, en lugar de esperar la hora programada de UNIX. Para hacer esto:


  1. Abre la página de Cloud Scheduler en la consola.
  2. Haz clic en el botón "Ejecutar ahora".
  3. Abre BigQuery en la consola.
  4. Debajo de su conjunto de datos de salida, busque su [output_table_name], esto contendrá los datos.


Para obtener más información, lea nuestra documentación sobre la configuración de Cloud Scheduler con PubSub trigger y pruébelo utilizando uno de nuestros conjuntos de datos públicos de BigQuery.