La gestión de la configuración en Microservicios parte 2

En el post anterior vimos como podemos mantener las configuraciones de nuestros microservicios y ahora veamos que productos hay en el mercado:

Etcd: Proyecto de código abierto escrito en Go. Se utiliza para el descubrimiento de servicios y la gestión de configuración. Utiliza el protocolo raft (https://raft.github.io/) para su modelo de computación distribuida. Como beneficios podemos nombrar: 

• Muy rápido y escalable
• Distribuible
• Impulsado por línea de comandos
• Fácil de usar y configurar

Eureka: Escrito por Netflix. Extremadamente probado en batalla. Se utiliza tanto para el descubrimiento de servicios como para la gestión de forma clave-valor. Como características podemos nombrar: 

• Almacén distribuido clave-valor.
• Flexible; requiere esfuerzo para configurar
• Ofrece actualización dinámica del cliente lista para usar

Cónsul: Escrito por Hashicorp. Similar a Etcd y Eureka en características, pero usa un algoritmo diferente para su modelo de computación distribuida (protocolo SWIM; https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf).

• Rápido
• Ofrece descubrimiento de servicios nativos con la opción de integrarse directamente con DNS
• No ofrece actualización dinámica para el cliente de inmediato.

ZooKeeper: un proyecto de Apache que ofrece capacidades de bloqueo distribuidas. A menudo se utiliza como una solución de gestión de la configuración para acceder a datos valor-clave.

• Las soluciones más antiguas y probadas en batalla
• El más complejo de usar
• Se puede utilizar para la gestión de la configuración, pero solo debe tenerse en cuenta si ya está utilizando ZooKeeper en otras piezas de su arquitectura.

Servidor de configuración de Spring Cloud: un proyecto de código abierto que ofrece una solución de administración de configuración general con diferentes backends. Puede integrarse con Git, Eureka y Consul como back-end.

• Almacén distribuido clave-valor no distribuido
• Ofrece una estrecha integración para los servicios Spring y no Spring 
• Puede usar múltiples backends para la creación de historias
• datos de configuración que incluyen sistema de archivos, Eureka, Consul y Git

El servidor de configuración Spring Cloud ofrece múltiples backends para almacenar datos de configuración. Si ya está utilizando herramientas como Eureka y Consul, puede conectarlas directamente al servidor de configuración de Spring Cloud.

De todas las soluciones, el servidor de configuración de Spring Cloud puede integrarse directamente con la plataforma de control de fuente Git. La integración de la configuración de Spring Cloud con Git elimina una dependencia adicional en sus soluciones y facilita el control de versiones de los datos de configuración de su aplicación.

Las otras herramientas (Etcd, Consul, Eureka) no ofrecen ningún tipo de control de versiones nativo y, si lo desea, debe crearlo usted mismo. Si su tienda usa Git, el uso del servidor de configuración Spring Cloud es una opción atractiva.

La gestión de la configuración en Microservicios parte 1

La administración de la configuración de la aplicación es fundamental para los microservicios que se ejecutan en la nube porque las instancias de microservicio deben iniciarse rápidamente con una mínima intervención humana. Cada vez que un ser humano necesita configurar o tocar manualmente un servicio para implementarlo, es una oportunidad para un cambio de configuración, una interrupción inesperada y un retraso en la respuesta a los desafíos de escalabilidad con la aplicación.

Comencemos nuestra discusión sobre la administración de la configuración de aplicaciones estableciendo cuatro principios que queremos seguir:

1. Segregar: queremos separar completamente la información de configuración de los servicios de la implementación física real de un servicio. La configuración de la aplicación no debe implementarse con la instancia de servicio. En cambio, la información de configuración debe pasarse al servicio inicial como variables de entorno o leerse desde un repositorio centralizado cuando se inicia el servicio.
2. Resumen: en lugar de escribir código que acceda directamente al repositorio de servicios (es decir, leer los datos de un archivo o una base de datos usando JDBC), debemos hacer que la aplicación use un servicio JSON basado en REST para recuperar los datos de configuración.
3. Centralizar: dado que una aplicación basada en la nube puede tener literalmente cientos de servicios, es fundamental minimizar la cantidad de repositorios diferentes que se utilizan para almacenar información de configuración. Centralice la configuración de su aplicación en el menor número posible de repositorios.
4. Solida: debido a que la información de configuración de la aplicación estará completamente segregada y centralizada, es fundamental que cualquier solución que utilice se pueda implementar para que sea altamente disponible y redundante.

Cuando separamos la información de configuración fuera de su código real, se está creando una dependencia externa que deberemos administrar y controlar. No puedo enfatizar lo suficiente que los datos de configuración de la aplicación deben ser rastreados y controlados por versiones porque la configuración de la aplicación mal administrada es un caldo de cultivo fértil para errores difíciles de detectar e interrupciones no planificadas.

La carga de la administración de la configuración para un microservicio ocurre durante la fase de arranque del microservicio. 

Tomemos los cuatro principios que presentamos anteriormente y veamos cómo se aplican estos cuatro principios cuando el servicio se está iniciando. 

Cuando aparece una instancia de microservicio, llamará a un end point de servicio para leer su información de configuración que es específica del entorno en el que está operando. La información de conexión para la gestión de la configuración (credenciales de conexión, end point del servicio, etc.) se pasará a el microservicio cuando se inicia.

La configuración real residirá en un repositorio. Según la implementación de su repositorio de configuración, puede optar por utilizar diferentes implementaciones para almacenar sus datos de configuración. Las opciones de implementación pueden incluir archivos bajo control de fuente, una base de datos relacional o un almacén de datos de valor clave.

La gestión real de los datos de configuración de la aplicación se produce independientemente de cómo se implemente la aplicación. Los cambios en la administración de la configuración generalmente se manejan a través de la canalización de construcción e implementación, donde los cambios de la configuración se pueden etiquetar con información de versión e implementar a través de los diferentes entornos.

Cuando se realiza un cambio en la gestión de la configuración, los servicios que utilizan esos datos de configuración de la aplicación deben ser notificados del cambio y actualizar su copia de los datos de la aplicación.

En este punto, hemos trabajado en la arquitectura conceptual que ilustra las diferentes piezas de un patrón de gestión de la configuración y cómo encajan estas piezas. Ahora pasaremos a analizar las diferentes soluciones para el patrón y luego veremos una implementación concreta. Pero como el post me quedo muy largo, esto va a sen analizado en el siguiente post. 

Dejo link : https://emanuelpeg.blogspot.com/2021/12/la-gestion-de-la-configuracion-en_22.html

Apache Geode, una base de datos en memoria, distribuida y open-source

Apache Geode es una base de datos en memoria, distribuida y open-source. Y se utiliza como cache distribuida normalmente. 

Apache Geode es una plataforma de gestión de datos que proporciona acceso constante y en tiempo real a aplicaciones de uso intensivo de datos en arquitecturas de nube ampliamente distribuidas.

Geode agrupa la memoria, la CPU, los recursos de red y, opcionalmente, el disco local en varios procesos para administrar los objetos y el comportamiento de la aplicación. Utiliza técnicas de partición de datos y replicación dinámica para implementar alta disponibilidad, rendimiento mejorado, escalabilidad y tolerancia a fallas. Además de ser un contenedor de datos distribuidos, Apache Geode es un sistema de gestión de datos en memoria que proporciona notificaciones de eventos asincrónicas fiables y entrega de mensajes garantizada.

Apache Geode es una tecnología sólida y madura desarrollada originalmente por GemStone Systems. Disponible comercialmente como GemFire ​​™, se implementó por primera vez en el sector financiero como el motor de datos transaccionales de baja latencia utilizado en las plataformas de negociación de Wall Street. En la actualidad, cientos de clientes empresariales utilizan la tecnología Apache Geode para aplicaciones comerciales de gran escala que deben cumplir con requisitos de baja latencia y disponibilidad 24x7.

Dentro de cada caché, define regiones de datos. Las regiones de datos son análogas a las tablas de una base de datos relacional y gestionan los datos de forma distribuida como pares de nombre / valor. Una región replicada almacena copias idénticas de los datos en cada miembro de la caché de un sistema distribuido. Una región particionada distribuye los datos entre los miembros de la caché. Una vez configurado el sistema, las aplicaciones cliente pueden acceder a los datos distribuidos en regiones sin conocer la arquitectura del sistema subyacente. Puede definir oyentes para recibir notificaciones cuando los datos hayan cambiado y puede definir criterios de vencimiento para eliminar datos obsoletos en una región.

Los localizadores proporcionan servicios de detección y equilibrio de carga. Configura los clientes con una lista de servicios de localización y los localizadores mantienen una lista dinámica de servidores miembro. De forma predeterminada, los clientes y servidores de Geode utilizan el puerto 40404 y la multidifusión para descubrirse entre sí.

Geode incluye las siguientes características:

• Combina redundancia, replicación y una arquitectura de persistencia de "nada compartido" para brindar confiabilidad y desempeño a prueba de fallas.
• Escalable horizontalmente a miles de miembros de caché, con múltiples topologías de caché para satisfacer diferentes necesidades empresariales. La caché se puede distribuir en varios equipos.
• Propagación de actualización de caché asíncrona y síncrona.
• La propagación delta distribuye solo la diferencia entre las versiones antiguas y nuevas de un objeto (delta) en lugar de todo el objeto, lo que genera importantes ahorros en los costos de distribución.
• Notificaciones de eventos asincrónicas confiables y entrega de mensajes garantizada a través de una capa de distribución de baja latencia optimizada.
• Conocimiento de datos e inteligencia empresarial en tiempo real. Si los datos cambian a medida que los recupera, verá los cambios inmediatamente.
• Integración con Spring Framework para acelerar y simplificar el desarrollo de aplicaciones empresariales transaccionales escalables.
• Soporte de transacciones compatible con JTA.
• Configuraciones de todo el clúster que se pueden conservar y exportar a otros clústeres.
• Gestión remota de clústeres a través de HTTP.
• API REST para el desarrollo de aplicaciones habilitadas para REST.
• Es posible que se realicen actualizaciones progresivas, pero estarán sujetas a las limitaciones impuestas por las nuevas funciones.

Como que me quedo muy teórico el post voy a hacer unas pruebitas de Geode y les comparto en próximos posts. 

Dejo link: https://geode.apache.org/

Comunicar el estado de un microservicio con Spring Boot Actuators

Un agente de descubrimiento de servicios o service discovery no actúa solo como un policía de tráfico que guía al cliente a la ubicación del servicio. En una aplicación de microservicio basada en la nube, a menudo tendremos varias instancias de un servicio en ejecución. Tarde o temprano, una de esas instancias de servicio fallará. El agente de descubrimiento de servicios supervisa el estado de cada instancia de servicio registrada con él y elimina cualquier instancia de servicio de sus tablas de enrutamiento para garantizar que no se envíe a los clientes una instancia de servicio que haya fallado.

Después de que haya surgido un microservicio, el agente de descubrimiento de servicios continuará monitoreando y haciendo ping a la interfaz de verificación de estado para asegurarse de que ese servicio esté disponible.

Al crear una interfaz de verificación de estado coherente, puede utilizar herramientas de supervisión basadas en la nube para detectar problemas y responder a ellos de forma adecuada.

Si el agente de descubrimiento de servicios descubre un problema con una instancia de servicio, puede tomar medidas correctivas, como cerrar la instancia con problemas o activar instancias de servicio adicionales.

En un entorno de microservicios que utiliza REST, la forma más sencilla de crear una interfaz de verificación de estado es exponer un end point HTTP que pueda devolver una carga útil JSON y código de estado HTTP. En un microservicio no basado en Spring-Boot, a menudo es responsabilidad del desarrollador escribir este end point pero en Spring boot tenemos Spring Actuator. Spring Actuator proporciona end points operativos listos para usar que lo ayudarán a comprender y administrar el estado de su servicio. Para usar Spring Actuator, debemos incluir las siguientes dependencias de Maven:

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

Y listo! 

Si vamos a http://localhost:8080/actuator/health, debería ver los datos de estado del microservicio.  Algo como esto: 

{"status":"UP"}

Dejo link: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html

[eBook] Get Kubernetes from Test to Production

 Me llego este mail de la gente de NGINX y les comparto : 

EBOOK

Kubernetes – the de facto container management platform – fuels business growth and innovation by reducing time to market for digital experiences. And while many organizations are prepared for the substantial architectural changes required by Kubernetes, they’re surprised by the organizational impacts of running modern app technologies at scale. Whether you’re just getting started or already running in production, you’ve probably encountered three business-critical barriers between you and the Kubernetes dream: complexity, security, and the differing priorities of your teams. Implementing Kubernetes doesn’t need to be complicated. In this eBook, we share how organizations can reduce the complexity and risks of running Kubernetes by using three production-grade traffic management tools: an Ingress controller, a web application firewall, and a service mesh. Real-life examples, strategies, and use cases will help you get ready to move from testing to production in no time. In this eBook you will learn: About advanced traffic management methods that improve the resilience of your apps and infrastructure How to use visibility techniques that help you solve two common problems About security use cases that enable your team to better protect cloud-native apps and APIs How to choose an Ingress controller and service mesh that will meet your needs today and as your Kubernetes deployment grows in the future Download eBook

This email was sent by: NGINX, Part of F5 Insurgentes sur 601 piso 15, CDMX, Mexico | +52 55 2789 0323 | nginx.com ©2021 F5, Inc. All rights reserved. Policies | Privacy | Trademarks | Preference Center | Unsubscribe

Cómo se comunican los clientes con los microservicios?

Desde la perspectiva del consumidor de microservicios, un microservicio debe ser transparente a la ubicación, porque en un entorno basado en la nube, los servidores son efímeros. Los servicios basados ​​en la nube se pueden iniciar y desmontar rápidamente con una dirección IP completamente nueva asignada al servidor en el que se ejecutan los servicios.

Como los servicios se tratan como objetos desechables de corta duración, las arquitecturas de microservicios pueden lograr un alto grado de escalabilidad y disponibilidad al tener varias instancias de un servicio en ejecución. La demanda de servicios y la capacidad de recuperación se pueden gestionar tan rápido como la situación lo requiera. Cada servicio tiene asignada una dirección IP única y no permanente. La desventaja de los servicios efímeros es que con los servicios subiendo y bajando constantemente, administrar un gran grupo de servicios efímeros de forma manual o a mano es una invitación a una interrupción.

Una instancia de microservicio debe registrarse con el agente de terceros. Este proceso de registro se denomina descubrimiento de servicios o service discovery. Cuando una instancia de microservicio se registra con un agente de service discovery, le indicará dos cosas al agente: la dirección IP física o la dirección de dominio de la instancia de servicio y un nombre lógico que una aplicación puede usar para buscar en un servicio. Ciertos agentes de descubrimiento de servicios también requerirán una URL de regreso al servicio de registro que el agente de descubrimiento de servicios puede utilizar para realizar verificaciones de estado.

Luego, el cliente del servicio se comunica con el agente de descubrimiento para buscar la ubicación del servicio.

Como desplegar y empaquetar nuestros microservicios?

Desde la perspectiva de DevOps, uno de los conceptos clave detrás de una arquitectura de microservicio es que se pueden implementar múltiples instancias de un microservicio rápidamente en respuesta a un cambio en el entorno de la aplicación  (por ejemplo, muchos pedidos de solicitudes de usuarios, problemas dentro de la infraestructura, etc.).

Para lograr esto, un microservicio debe empaquetarse e instalarse como un solo artefacto con todas sus dependencias definidas dentro de él. Este artefacto se puede implementar en cualquier servidor que tenga un Java JDK instalado (por ejemplo en java). Estas dependencias también incluirán el motor de tiempo de ejecución (por ejemplo, un servidor HTTP o un contenedor de aplicaciones) que albergará el microservicio.

Afortunadamente, casi todos los frameworks de microservicios de Java incluirán un motor de tiempo de ejecución que se puede empaquetar e implementar con el código. Por ejemplo, Spring Boot viene con tomcat  y maven integrado. Podemos crear nuestro proyecto con la linea de comandos :

mvn clean package && java –jar target/licensing-service-0.0.1-SNAPSHOT.jar

Para ciertos equipos de operaciones, el concepto de incrustar un entorno de ejecución directamente en el archivo JAR es un cambio importante en la forma en que piensan sobre la implementación de aplicaciones. En una organización empresarial tradicional J2EE, una aplicación se implementa en un servidor de aplicaciones. Este modelo implica que el servidor de aplicaciones es una entidad en sí mismo y, a menudo, sería administrado por un equipo de administradores de sistemas que administraron la configuración de los servidores independientemente de las aplicaciones que se implementan en ellos.

Esta separación de la configuración del servidor de aplicaciones de la aplicación introduce puntos de falla en el proceso de implementación, porque en muchas organizaciones la configuración de los servidores de aplicaciones no se mantiene bajo el control de la fuente y se administra a través de una combinación de la interfaz de usuario y la administración propia de scripts. Es demasiado fácil que se nos traspapele alguna configuración y los entorno de prueba no reflejen las configuraciones del entorno de producción.

El uso de un único artefacto desplegable con el motor de tiempo de ejecución integrado en el artefacto elimina muchas de estas oportunidades de desviación de la configuración. También le permite poner todo el artefacto bajo control de código fuente y permite que el equipo de la aplicación pueda razonar mejor a través de cómo se construye e implementa su aplicación.

Creación de aplicaciones basados en los 12 factores.

Una arquitectura de microservicio exitosa requiere un sólido desarrollo de aplicaciones y prácticas de DevOps. Uno de los resúmenes más sucintos de estas prácticas se puede encontrar en el manifiesto de la aplicación TwelveFactor de Heroku. Este documento proporciona 12 prácticas recomendadas que siempre debemos de tener en cuenta al crear microservicios.

1. Base de código: todo el código de la aplicación y la información de aprovisionamiento del servidor deben estar en control de versiones. Cada microservicio debe tener su propio repositorio de código independiente dentro de los sistemas de control de fuente. 
2. Dependencias: declara explícitamente las dependencias que usa tu aplicación mediante herramientas de compilación como Maven (Java). La dependencia de JAR de terceros debe declararse utilizando sus números de versión específicos. Esto permite que su microservicio siempre se compile utilizando la misma versión de bibliotecas.
3. Config: almacene la configuración de su aplicación (especialmente la configuración específica de su entorno) independientemente de su código. La configuración de su aplicación nunca debe estar en el mismo repositorio que su código fuente.
4. Servicios de respaldo: su microservicio a menudo se comunicará a través de una red con una base de datos o un sistema de mensajería. Cuando lo haga, debe asegurarse de que, en cualquier momento, pueda cambiar su implementación de la base de datos de un servicio administrado internamente a un servicio de terceros. 
5. Cree, publique, ejecute: mantenga las partes de la implementación de la aplicación, compiladas, publicadas y ejecutadas completamente separadas. Una vez que se crea el código, el desarrollador nunca debe realizar cambios en el código en tiempo de ejecución. Cualquier cambio debe volver al proceso de compilación y volver a implementarse. Un servicio construido es inmutable y no se puede cambiar.
6. Procesos: sus microservicios siempre deben ser sin estado. Se pueden eliminar y reemplazar en cualquier tiempo de espera sin temor a que una instancia de pérdida de un servicio provoque la pérdida de datos.
7. Enlace de puertos: un microservicio es completamente autónomo con el motor de tiempo de ejecución para el servicio empaquetado en el ejecutable del servicio. Debe ejecutar el servicio sin la necesidad de un servidor web o de aplicaciones separado. El servicio debe iniciarse por sí mismo en la línea de comando y se debe acceder a él inmediatamente a través de un puerto HTTP expuesto.
8. Simultaneidad: cuando necesite escalar, no confíe en un modelo de subprocesos dentro de un solo servicio. En su lugar, lance más instancias de microservicio y escale horizontalmente. Esto no excluye el uso de subprocesos dentro de su microservicio, pero no confíe en él como su único mecanismo para escalar. Escala horizontalmente, no hacia arriba.
9. Desechabilidad: los microservicios son desechables y se pueden iniciar y detener a pedido. El tiempo de inicio debe minimizarse y los procesos deben cerrarse correctamente cuando reciben una señal de interrupción del sistema operativo.
10. Paridad desarrollo / producción: minimice las brechas que existen entre todos los entornos en los que se ejecuta el servicio (incluido el escritorio del desarrollador). Un desarrollador debe usar la misma infraestructura localmente para el desarrollo del servicio en el que se ejecutará el servicio real. También significa que la cantidad de tiempo que se implementa un servicio entre entornos debe ser de horas, no de semanas. Tan pronto como se confirme el código, debe probarse y luego promoverse lo más rápido posible desde Dev hasta Prod.
11. Registros: los registros son una secuencia de eventos. A medida que se escriben los registros, deben poder transmitirse a herramientas, como Splunk (http://splunk.com) o Fluentd (http://fluentd.org), que recopilarán los registros y los escribirán en una ubicación central. El microservicio nunca debe preocuparse por la mecánica de cómo sucede esto y el desarrollador debe mirar visualmente los registros a través de STDOUT a medida que se escriben.
12. Procesos de administración: los desarrolladores a menudo tendrán que realizar tareas administrativas en sus servicios (migración o conversión de datos). Estas tareas nunca deben ser ad hoc y, en cambio, deben realizarse a través de scripts que se administran y mantienen a través del repositorio de código fuente. Estas secuencias de comandos deben ser repetibles y no cambiar (el código de la secuencia de comandos no se modifica para cada entorno) en cada entorno en el que se ejecutan.

Dejo link: https://12factor.net/

Cuando no usar Microservicios?

Creo que hay un post anterior similar, pero bueno, el publico se renueva :D

Tenemos 4 características de los microservicios que nos dejan inferir los escenarios que no estaría bueno usarlos :

Complejidad de la construcción de sistemas distribuidos: debido a que los microservicios están distribuidos y son pequeños, introducen un nivel de complejidad en las aplicaciones que no estaría en aplicaciones monolíticas. Las arquitecturas de microservicios requieren un alto grado de madurez operativa. No sé debe considerar el uso de microservicios a menos que la organización esté dispuesta a invertir en la automatización y el trabajo operativo (monitoreo, escalado) que una aplicación altamente distribuida necesita para tener éxito.

Expansión de servidores: uno de los modelos de implementación más comunes para microservicios es tener una instancia de microservicio implementada en un servidor. En una gran aplicación basada en microservicios, puede terminar con 50 a 100 servidores o contenedores (generalmente virtuales) que deben construirse y mantenerse solo en producción. Incluso con el menor costo de ejecutar estos servicios en la nube, la complejidad operativa de tener que administrar y monitorear estos servidores puede ser tremenda. 

Tipo de aplicación: los microservicios están orientados a la reutilización y son extremadamente útiles para crear aplicaciones de gran tamaño que deben ser altamente resilientes y escalables. Esta es una de las razones por las que tantas empresas basadas en la nube han adoptado microservicios. Si está construyendo aplicaciones pequeñas a nivel departamental o aplicaciones con una base de usuarios pequeña, la complejidad asociada con la construcción de un modelo distribuido como microservicios puede ser más costosa de lo que vale la pena.

Consistencia y transformaciones de datos: a medida que comienza a analizar los microservicios, debe pensar en los patrones de uso de datos de sus servicios y cómo los consumidores de servicios los usarán. Un microservicio envuelve y abstrae una pequeña cantidad de tablas y funciona bien como un mecanismo para realizar tareas "operativas" como crear, agregar y realizar consultas simples (no complejas) en una tienda.

Si sus aplicaciones necesitan realizar una agregación o transformación de datos complejos a través de múltiples fuentes de datos, la naturaleza distribuida de los microservicios dificultará este trabajo. Sus microservicios invariablemente asumirán demasiada responsabilidad y también pueden volverse vulnerables a problemas de rendimiento.

También tenga en cuenta que no existe un estándar para realizar transacciones entre microservicios. Si necesita la gestión de transacciones, deberá crear esa lógica. La mensajería introduce latencia en las actualizaciones de datos. Sus aplicaciones deben manejar la coherencia eventual donde las actualizaciones que se aplican a sus datos pueden no aparecer de inmediato.

[eBook] Continuous API Management, 2nd Edition

  Me llego este mail de la gente de NGINX y les comparto : 

EBOOK

The second edition of this O’Reilly eBook, sponsored by NGINX, provides maturity models for individual APIs and multi-API landscapes to help you invest the right human and company resources for the right maturity level at the right time. How do you balance the desire for agility and speed with the need for robust and scalable operations? Four API experts show software architects, program directors, and product owners how to maximize the value of their APIs by managing them as products through a continuous lifecycle. In this eBook you will learn: Which API decisions you need to govern How the continuous improvement model governs change throughout an API’s lifetime About the five stages of the complete API product lifecycle How to manage APIs published by your organization Download eBook

This email was sent by: NGINX, Part of F5 Insurgentes sur 601 piso 15, CDMX, Mexico | +52 55 2789 0323 | nginx.com ©2021 F5, Inc. All rights reserved. Policies | Privacy | Trademarks | Preference Center | Unsubscribe

Free Serverless App Development O'Reilly Book

 Me llego este mail de la gente de infoQ y O'Reilly y les comparto : 

December 2021

Sent on behalf of Cockroach Labs to InfoQ Industry Email Notice Subscribers

In this hands-on guide, developers will learn to build production-ready serverless apps and services on Google Cloud Run.

Download Book

The 10-chapter book includes tutorials for building and deploying a variety of serverless applications across Google Cloud. Ultimately, developers will learn how serverless development can dramatically simplify the building and scaling of applications. This guide, authored by Wietse Venema, covers: How to build serverless apps on Google Cloud Run How to use HTTP to create unique experiences for your users How identity and access management (IAM) work in serverless environments How to deploy applications across a variety of Google Cloud services CockroachDB is an official partner of Google Cloud Run and Google. Here's our solution to integrating CockroachDB with Google Cloud Run. Download it for free and start building! Cheers, The Cockroach Labs Team

You have received this email because you opted-in to the "InfoQ Industry Email Notices" box when you registered to InfoQ.com, where we send infrequent notices on behalf of our partners, user groups, conferences, etc. To unsubscribe to the InfoQ Industry Email Notices, please click the following link: Unsubscribe - - - C4Media Inc. (InfoQ.com), 2275 Lake Shore Boulevard West, Suite #325, Toronto, Ontario, Canada, M8V 3Y3

Pants, un sistema de construcción de software multilenguaje

Pants es un sistema de construcción de software escalable. Es útil para repositorios de código de todos los tamaños, pero es particularmente valioso para aquellos que contienen múltiples piezas distintas pero interdependientes.

Pants organiza las diversas herramientas y pasos que procesan su código fuente en software implementable, que incluyen:

• Resolución de dependencia
• Generación de código
• Verificación de tipos y compilación
• Pruebas
• Linting
• Formateo
• packaging
• Introspección del proyecto

Pants es similar a herramientas como make, ant, maven, gradle, sbt, bazel y otras. Su diseño se basa en ideas e inspiración de estas herramientas anteriores, al tiempo que optimiza la velocidad, la corrección y la ergonomía en los casos de uso del mundo real de hoy.

Lo que me llamo la atención es que soporta, Python, Shell, Docker, Go, Java y Scala. Esta bueno para equipos que tengan que trabajar con varios lenguajes y tecnología y pueden compilar con una sola herramienta.  

Dejo link: https://www.pantsbuild.org/