Podemos usar balanceadores de carga para implementar service discovery?

Hemos repasado los beneficios del descubrimiento de servicios, pero ¿cuál es el problema? Después de todo, ¿no podemos usar métodos probados y verdaderos como DNS (Servicio de nombres de dominio) o un balanceador de carga para ayudar a facilitar el descubrimiento de servicios? Analicemos por qué eso no funciona con una aplicación basada en microservicios, particularmente una que se ejecuta en la nube.

Siempre que tenga una aplicación que llama a recursos repartidos en varios servidores, necesita ubicar la ubicación física de esos recursos. En el mundo normal (no clud), esta resolución de ubicación de servicio a menudo se resolvía y se resuelve mediante una combinación de DNS y un balanceador de carga. 

Una aplicación si necesita invocar un servicio intenta invocar el servicio utilizando un nombre genérico junto con una ruta que representa de forma única el servicio que la aplicación intentaba invocar. El nombre DNS se resolvería en un balanceador de carga. 

El balanceador de carga, al recibir la solicitud del consumidor del servicio, ubica la entrada de la dirección física en una tabla de enrutamiento según la ruta a la que el usuario intentaba acceder. Esta entrada de la tabla de enrutamiento contiene una lista de uno o más servidores que alojan el servicio. Luego, el balanceador de carga elige uno de los servidores de la lista y reenvía la solicitud a ese servidor.

Cada instancia de un servicio se implementa en uno o más servidores de aplicaciones. La cantidad de estos servidores de aplicaciones a menudo era estática (por ejemplo, la cantidad de servidores de aplicaciones que alojaban un servicio no aumentaba ni disminuía) y persistente (por ejemplo, si fallaba un servidor que ejecutaba un servidor de aplicaciones, se restauraría al estado actual). mismo estado que tenía en el momento del bloqueo, y tendría la misma IP y configuración que tenía anteriormente).

Para lograr una forma de alta disponibilidad, un balanceador de carga secundario está inactivo y hace ping al balanceador de carga principal para ver si está activo. Si no está activo, el balanceador de carga secundario se activa, asumiendo la dirección IP del balanceador de carga principal y comenzando a atender las solicitudes.

Si bien este tipo de modelo funciona bien con aplicaciones que se ejecutan dentro de las cuatro paredes de un centro de datos corporativo y con una cantidad relativamente pequeña de servicios que se ejecutan en un grupo de servidores estáticos, no funciona bien para aplicaciones de microservicio basadas en la nube. Las razones para esto incluyen :

• Punto único de falla: si bien el balanceador de carga puede tener una alta disponibilidad, es un punto único de falla para toda su infraestructura. Si el balanceador de carga se cae, todas las aplicaciones que dependen de él también se caen. Si bien puede hacer que un balanceador de carga esté altamente disponible, los balanceadores de carga tienden a ser cuellos de botella centralizados dentro de la infraestructura de la aplicación.
• Escalabilidad horizontal limitada: al centralizar sus servicios en un solo grupo de balanceadores de carga, tiene una capacidad limitada para escalar horizontalmente su infraestructura de balanceo de carga en varios servidores. Muchos balanceadores de carga comerciales están limitados por dos cosas: su modelo de redundancia y los costos de licencia. La mayoría de los balanceadores de carga comerciales usan un modelo de intercambio en caliente para la redundancia, por lo que solo tiene un único servidor para manejar la carga, mientras que el balanceador de carga secundario está allí solo para la conmutación por error en el caso de una interrupción del balanceador de carga principal. Estás, en esencia, limitado por tu hardware. En segundo lugar, los balanceadores de carga comerciales también tienen modelos de licencia restrictivos orientados a una capacidad fija en lugar de un modelo más variable.
• Gestionado estáticamente: la mayoría de los balanceadores de carga tradicionales no están diseñados para registrar y cancelar el registro de servicios rápidamente. Usan una base de datos centralizada para almacenar las rutas para las reglas y la única forma de agregar nuevas rutas es a menudo a través de la API (interfaz de programación de aplicaciones) propietaria del proveedor.
• Complejo: debido a que un balanceador de carga actúa como un proxy para los servicios, las solicitudes de los consumidores de servicios deben tener sus solicitudes asignadas a los servicios físicos. Esta capa de traducción a menudo agregaba una capa de complejidad a su infraestructura de servicio porque las reglas de mapeo para el servicio deben definirse e implementarse a mano. En un escenario de balanceador de carga tradicional, este registro de nuevas instancias de servicio se realizaba a mano y no en el momento del inicio de una nueva instancia de servicio.

Estas cuatro razones no son una acusación general de los balanceadores de carga. Funcionan bien en un entorno corporativo donde el tamaño y la escala de la mayoría de las aplicaciones pueden manejarse a través de una infraestructura de red centralizada. Además, los balanceadores de carga aún tienen un papel que desempeñar en términos de centralizar la terminación SSL y administrar la seguridad del puerto del servicio. Un balanceador de carga puede bloquear el acceso al puerto de entrada (entrada) y salida (salida) a todos los servidores que se encuentran detrás de él. Este concepto de acceso mínimo a la red suele ser un componente crítico cuando se trata de cumplir con los requisitos de certificación estándar de la industria, como el cumplimiento de PCI (industria de tarjetas de pago).

Sin embargo, en la nube, donde tiene que lidiar con cantidades masivas de transacciones y redundancia, una pieza centralizada de infraestructura de red no funciona tan bien en última instancia porque no se escala de manera efectiva y no es rentable. 

Deploying NGINX as an Api Gateway

 Me llego este mail con un libro gratuito y se los comparto: 

EBOOK Enterprises use NGINX load‑balancing features to complement existing hardware ADCs, or even to replace them, and while converting applications from monoliths to microservices. Among the many use cases for NGINX, the API gateway use case is becoming increasingly widespread, especially when consolidating load balancers and API gateways into a single solution. We show you how to extend NGINX to manage API traffic in a comprehensive set of use cases. We start off with information about configuring the API gateway for single-service and microservices APIs, rewriting client requests, responding to errors, and authenticating users. Then you learn how to secure the gateway with rate limiting, access controls, limits on request methods and size, and other techniques. Finally, we explain how to publish gRPC services. With NGINX for API management, you tap into the high performance, reliability, robust community support, and advanced functionality and professional support (for NGINX Plus customers) that NGINX is famous for. In this eBook you will learn: About using NGINX as a complement and replacement for existing API gateway and API management approaches How to extend the configuration of an existing NGINX instance to also manage API traffic About a range of safeguards for protecting and securing backend API services in production How to deploy NGINX as an API gateway for gRPC services Download eBook This email was sent by: F5 NGINX 801 5th Ave, Seattle, WA 98119 | (206) 272-5555 | nginx.com ©2022 F5, Inc. All rights reserved. Policies | Privacy | Trademarks | Preference Center | Unsubscribe

Que es service discovery?

En cualquier arquitectura distribuida, necesitamos encontrar la dirección física de donde se encuentra una máquina. Este concepto ha existido desde el comienzo de la computación distribuida y se conoce formalmente como descubrimiento de servicios. El descubrimiento de servicios puede ser algo tan simple como mantener un archivo de propiedades con las direcciones de todos los servicios remotos utilizados por una aplicación, o algo tan formalizado (y complicado) como un repositorio UDDI (Descripción Universal, Descubrimiento e Integración) El descubrimiento de servicios es crítico a aplicaciones de microservicio basadas en la nube por dos razones claves:

Ofrece al equipo de aplicaciones la capacidad de escalar horizontalmente rápidamente la cantidad de instancias de servicio que se ejecutan en un entorno. Los consumidores del servicio se abstraen de la ubicación física del servicio a través del descubrimiento del servicio. Debido a que los consumidores del servicio no conocen la ubicación física de las instancias de servicio reales, se pueden agregar o eliminar nuevas instancias de servicio del grupo de servicios disponibles. 

Esta capacidad de escalar rápidamente los servicios sin interrumpir a los consumidores del servicio es un concepto extremadamente poderoso, porque hace que un equipo de desarrollo acostumbrado a crear aplicaciones monolíticas deje de pensar en escalar solo en términos de agregar mayores , mejor hardware (escalado vertical) al enfoque más potente de escalado mediante la adición de más servidores (escalado horizontal). 

Un enfoque monolítico suele llevar a los equipos de desarrollo por el camino de sobrecomprar sus necesidades de capacidad. Los aumentos de capacidad vienen en grupos y picos y rara vez son un camino suave y constante. Los microservicios nos permiten escalar hacia arriba o hacia abajo nuevas instancias de servicio. El descubrimiento de servicios ayuda a abstraer que estas implementaciones ocurren lejos del consumidor del servicio.

El segundo beneficio del descubrimiento de servicios es que ayuda a aumentar la resistencia de las aplicaciones. Cuando una instancia de microservicio no está en buen estado o no está disponible, la mayoría de los motores de detección de servicios eliminarán esa instancia de su lista interna de servicios disponibles.

El daño causado por un servicio inactivo se minimizará porque el motor de descubrimiento de servicios enrutará los servicios alrededor del servicio no disponible.

Consumir configuraciones de un servidor de configuración con Spring Cloud

Se acuerdan que en un post anterior hicimos un servidor de configuración con Spring Cloud. Ahora vamos a utilizarlo. 

Cuando el cliente se inicia por primera vez, pasará el perfil de Spring y el end point para comunicarse con el servicio de configuración de Spring Cloud. El valor del perfil Spring se asigna al entorno de las propiedades que se recuperan para el servicio Spring. El servicio Spring Cloud Config luego usará el repositorio de configuración de back-end configurado (sistema de archivos, Git, Consul, Eureka) para recuperar la información de configuración específica para el valor del perfil de Spring pasado en el URI. Spring Boot luego inyectará estos valores en las partes apropiadas de la aplicación.

Lo primero que debe hacer es agregar un par de entradas más al archivo Maven :

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-config-client</artifactId>

</dependency>

La dependencia, spring-cloud-config-client, contiene todas las clases necesarias para interactuar con el servidor de configuración de Spring Cloud.

Una vez definidas las dependencias de Maven, debe indicarle al servicio dónde ponerse en contacto con el servidor de configuración de Spring Cloud. En un servicio Spring Boot que usa Spring Cloud Config, la información de configuración se puede establecer en uno de dos archivos de configuración: bootstrap.yml y application.yml.

El archivo bootstrap.yml lee las propiedades de la aplicación antes de utilizar cualquier otra información de configuración. En general, el archivo bootstrap.yml contiene el nombre de la aplicación para el servicio, el perfil de la aplicación y el URI para conectarse a un servidor Spring Cloud Config.

Cualquier otra información de configuración que desee mantener local para el servicio (y no almacenada en Spring Cloud Config) se puede configurar localmente en los servicios en el archivo application.yml. Por lo general, la información que almacena en el archivo application.yml son datos de configuración que quizás desee tener disponibles para un servicio, incluso si el servicio Spring Cloud Config no está disponible. Los archivos bootstrap.yml y application.yml se almacenan en un directorio de proyectos src/main/resources.

Para que el cliente se comunique con su servicio Spring Cloud Config, debe agregar un archivo /src/main/resources/bootstrap.yml y configurar tres propiedades: spring.application.name, spring.profiles.active y spring.cloud.config.uri.

El archivo bootstrap.yml de los servicios de licencias se muestra en la siguiente lista.

spring.application.name es el nombre de su aplicación y debe asignarse directamente al nombre del directorio dentro de su servidor de configuración de Spring Cloud. Para el servicio de licencias, desea un directorio en el servidor de configuración de Spring Cloud llamado licenseservice.

La segunda propiedad, spring.profiles.active, se usa para decirle a Spring Boot con qué perfil debe ejecutarse la aplicación. Un perfil es un mecanismo para diferenciar los datos de configuración consumidos por la aplicación Spring Boot. Para el perfil del cliente, admitirá el entorno al que se asignará el servicio directamente en su entorno de configuración de la nube. Por ejemplo, al pasar dev como nuestro perfil, el servidor de configuración de Spring Cloud usará las propiedades dev. Si establece un perfil, el servicio de licencias utilizará el perfil predeterminado.

La tercera y última propiedad, spring.cloud.config.uri, es la ubicación donde el servicio de licencias debe buscar el servidor de configuración de Spring Cloud.

punto final. De forma predeterminada, el servicio de licencias buscará el servidor de configuración en http://localhost:8888. Más adelante en el capítulo, verá cómo anular las diferentes propiedades definidas en los archivos boostrap.yml y application.yml al iniciar la aplicación. Esto le permitirá decirle al microservicio de licencias en qué entorno se debe ejecutar.

Ahora, si abre el servicio de configuración de Spring Cloud, con la base de datos de Postgres correspondiente ejecutándose en su máquina local, puede iniciar el servicio de licencias utilizando su perfil predeterminado. Esto se hace cambiando al directorio de servicios de licencias y emitiendo los siguientes comandos:

 

 mvn spring-boot: ejecutar

Al ejecutar este comando sin establecer ninguna propiedad, el servidor de licencias intentará conectarse automáticamente al servidor de configuración de Spring Cloud utilizando el punto final (http://localhost:8888) y el perfil activo (predeterminado) definido en bootstrap.yml archivo del servicio de licencias.

Si desea anular estos valores predeterminados y apuntar a otro entorno, puede hacerlo compilando el proyecto de servicio de licencias en un JAR y luego ejecutar

el JAR con una anulación de propiedad del sistema -D. La siguiente llamada de línea de comando demuestra cómo iniciar el servicio de licencias con un perfil no predeterminado:

java -Dspring.cloud.config.uri=http://localhost:8888 \

-Dspring.profiles.active=dev \

-jar destino/servicio de licencias-0.0.1-SNAPSHOT.jar

Con la línea de comando anterior, está anulando los dos parámetros:

spring.cloud.config.uri y spring.profiles.active. Con la propiedad del sistema -Dspring.cloud.config.uri=http://localhost:8888, está apuntando a un servidor de configuración que se está ejecutando fuera de su caja local.

Con la propiedad del sistema –Dspring.profiles.active=dev, le indica al cliente que use el perfil de desarrollo (leído del servidor de configuración) 

Construyendo nuestro servidor de configuración con Spring Cloud

El servidor de configuración de Spring Cloud es una aplicación basada en REST que está construida sobre Spring Boot. No viene como un servidor independiente. En su lugar, puede elegir embeberlo en una aplicación Spring Boot existente o iniciar un nuevo proyecto Spring Boot con el servidor embebido.

Vamos a hacer una nueva aplicación string boot como servidor de configuraciones. Yo voy a utilizar spring initializr pero podemos agregar estas dependencias en un nuevo proyecto o uno existente. 

<dependencies>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-config</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-config-server</artifactId>

</dependency>

</dependencies>

O con gradle sería así : 

implementation 'org.springframework.cloud:spring-cloud-starter-config'

implementation 'org.springframework.cloud:spring-cloud-config-server'

La primera dependencia es la dependencia spring-cloud-starter-config que utilizan todos los proyectos de Spring Cloud. La segunda dependencia es el proyecto de inicio spring-cloud-config-server. Esto contiene las bibliotecas centrales para spring-cloud-config-server.

Necesitamos configurar un archivo más para que el servidor de configuración central esté en funcionamiento. Este archivo es el archivo application.yml y lo debemos generar en el directorio src/main/resources. El archivo application.yml le dirá a su servicio de configuración de Spring Cloud qué puerto escuchar y dónde ubicar el back-end que entregará los datos de configuración. En mi caso el appication.yml es así : 

server:
  port: 8888
spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
          searchLocations: file:///{projectPath}/resources

Ojo que {projectPath} es donde esta el proyecto, la dirección por ejemplo el mio esta en /home/emanuel/misProyectos/application. 

En la configuración de Spring Cloud, todo funciona con una jerarquía. La configuración de la aplicación está representada por el nombre de la aplicación y luego un archivo de propiedades para cada entorno para el que se desea tener información de configuración. En cada uno de estos entornos, configurará dos propiedades de configuración. 

Vamos a suponer que tenemos 3 entornos uno de dev, otro de uat y otro de prod. Vamos a crear directorios para cada uno de los entornos en src/main/resources una carpeta por cada entorno. 

El mapeo de las carpetas y los archivos va a ser de la siguiente manera : 

/{application}/{profile}[/{label}]

/{application}-{profile}.yml

/{label}/{application}-{profile}.yml

/{application}-{profile}.properties

/{label}/{application}-{profile}.properties

Noten que el label es opcional. Por lo tanto si hacemos archivos application-dev.properties o application-uat.properties esto debería andar. 

Y por ultimo le decimos a spring que vamos a utilizar spring config con esta anotación : 

@SpringBootApplication
@EnableConfigServer
public class SettingsApplication {

Ahora levantamos el servidor y si necesitamos las configuraciones de uat deberíamos hacer : 

http://localhots:8888/application/uat

Tendremos este resultado : 

{"name":"demo","profiles":["uat"],"label":null,"version":null,"state":null,"propertySources":[{"name":"file:/home/emanuel/Projects/spring-cloud/settings/src/main/resources/demo-uat.yml","source":{"env":"dev"}},{"name":"file:/home/emanuel/Projects/spring-cloud/settings/src/main/resources/application.yml","source":{"server.port":8888,"spring.profiles.active":"native","spring.cloud.config.server.native.searchLocations":"file:///home/emanuel/Projects/spring-cloud/settings/src/main/resources"}}]}

Y listo, nos queda ver como podemos consumir estos settings. (pero eso es para otro post) 

Dejo link: https://cloud.spring.io/spring-cloud-config

Concurrencia en Clojure

Clojure proporciona un estilo híbrido de programación funcional y estado mutable para resolver problemas de forma concurrente; el "Clojure Way" aprovecha las fortalezas de ambos para brindar un enfoque particularmente poderoso para la programación concurrente.

Si bien la programación funcional funciona increíblemente bien para algunos problemas, algunos tienen la modificación del estado como un elemento fundamental de la solución. Aunque puede ser posible crear una solución funcional a tales problemas, es más fácil pensar en ellos de una manera más tradicional. 

Un lenguaje funcional puro no proporciona soporte para datos mutables en absoluto. Clojure, por el contrario, es impuro: proporciona varios tipos diferentes de variables mutables conscientes de la concurrencia, cada una de las cuales es adecuada para diferentes casos de uso. Estos, en conjunto con las estructuras de datos persistentes de Clojure (vamos a cubriremos lo que significa persistente en este contexto más adelante) nos permiten evitar muchos de los problemas que tradicionalmente afligen a los programas concurrentes con estado mutable compartido.

La diferencia entre un lenguaje funcional impuro y un lenguaje imperativo es de énfasis. En un lenguaje imperativo, las variables son mutables por defecto y el código idiomático las modifica con frecuencia. En un lenguaje funcional impuro, las variables son inmutables por defecto y el código idiomático modifica aquellas que no lo son solo cuando es absolutamente necesario. Como veremos, las variables mutables de Clojure nos permiten manejar los efectos secundarios del mundo real sin dejar de ser seguros y consistentes.

Veremos cómo las variables mutables de Clojure funcionan en conjunto con las estructuras de datos persistentes para separar la identidad del estado. Esto permite que varios subprocesos accedan a variables mutables simultáneamente sin bloqueos (y el peligro asociado de interbloqueo) y sin ninguno de los problemas de estado mutable escapado u oculto. Comenzaremos por lo que podría decirse que es el más simple de los tipos de variables mutables de Clojure, el átomo.

Un átomo es una variable atómica  (los átomos de Clojure están construidos sobre java.util.concurrent.atomic). A continuación, se muestra un ejemplo de cómo crear y recuperar el valor de un átomo:

user=> (def my-atom (atom 42))

#'user/my-atom

user=> (deref my-atom)

42

user=> @my-atom

42

Un átomo se crea con átomo, que toma un valor inicial. Podemos encontrar el valor actual de un átomo con deref o @.

Si desea actualizar un átomo a un nuevo valor, se usa swap !:

user=> (swap! my-atom inc)

43

user=> @my-atom

43

Esto toma una función y le pasa el valor actual del átomo. El nuevo valor del átomo se convierte en el valor de retorno de la función. También podemos pasar argumentos adicionales a la función, como en este ejemplo:

user=> (swap! my-atom + 2)

45

El primer argumento pasado a la función será el valor actual del átomo, y luego cualquier argumento adicional dado para intercambiar. Entonces, en este caso, el nuevo valor se convierte en el resultado de (+ 43 2).

En raras ocasiones, es posible que desee establecer un átomo en un valor que no dependa de su valor actual, en cuyo caso puede usar reset !:

user=> (reset! my-atom 0)

0

user=> @my-atom

0

Los átomos pueden ser de cualquier tipo; muchas aplicaciones web utilizan un mapa atómico para almacenar datos de sesión, como en este ejemplo:

user=> (def session (atom {}))

#'user/session

user=> (swap! session assoc :username "paul")

{:username "paul"}

user=> (swap! session assoc :session-id 1234)

{:session-id 1234, :username "paul"}

Ya se que no vimos nada de concurrencia aun, pero paciencia, como me queda largo el post seguimos en otro... 

Hagamos un proyecto con scalatra como en los viejos tiempos

 Hace mucho mucho que no hago un proyecto con scalatra y me dio añoranza, así que vamos a hacer un "hola mundo" para rememorar buenos tiempos. 

Primero tenemos que tener instalado sbt, yo lo instale con sdkman (que si no lo conocen dejo el post acá) 

sdk i sbt 

y listo, luego creemos nuestro proyecto : 

sbt new scalatra/scalatra.g8

ahí nos va a pedir unos datos, complete nomas ...

Y bueno, ya esta... Porque scalatra nos trae un ejemplo el cual esta en el paquete com.example.app

ackage com.example.app

import org.scalatra._

class MyScalatraServlet extends ScalatraServlet {

  get("/") {
    views.html.hello()
  }

}

Que lo que hace es mostrar lo que esta en la vista es decir en src/main/twirl/views/hello.scala.html : 

@()
@layouts.html.default("Scalatra: a tiny, Sinatra-like web framework for Scala", "Welcome to Scalatra"){
  <p>Hello, Twirl!</p>
}

Que es una mezcla de scala con Html. 

Ahora vamos a ver el ejemplo, en marcha, en el directorio del proyecto, escribimos sbt y luego 

> jetty:start

Y la aplicación se verá en http://localhost:8080

Y ya esta!! 

Dejo link: https://scalatra.org

Transforme su empresa con el Machine Learning

Me llego un mail de la gente de AWS, el cual tiene un link a un libro digital que trata sobre la transformación de las empresas con el Machine Learning y me gustaría compartirlo: 

Impulse la transformación empresarial con el Machine Learning

Descubra en "Cómo conseguir resultados empresariales transformadores gracias al Machine Learning" cómo los clientes de AWS resuelven los desafíos empresariales con las soluciones de ML de AWS, entre los que se incluyen: Mejorar la experiencia del cliente Optimizar las operaciones empresariales y aumentar la productividad Acelerar la innovación Lea el libro electrónico »

Mi cuenta | Introducción | Productos | Soluciones | Precios | Socios | Documentación | Formación técnica | Eventos y seminarios web | AWS Activate | Marketplace | Novedades | Blog | Informes de analistas Ver online

Apache CloudStack

Apache CloudStack es un proyecto de código abierto diseñado para implementar y administrar grandes redes de máquinas virtuales, como una plataforma de computación en la nube de infraestructura como servicio (IaaS) altamente disponible y escalable. Varios proveedores de servicios utilizan CloudStack para ofrecer servicios de nube pública y muchas empresas para proporcionar una oferta de nube local (privada) o como parte de una solución de nube híbrida.

CloudStack es una solución llave en mano que incluye un stack completo con características que la mayoría de las organizaciones desean de una nube IaaS: orquestación informática, red como servicio, administración de cuentas y usuarios, una API nativa completa y abierta, contabilidad de recursos y un Interfaz de usuario (UI) 

CloudStack actualmente admite los hipervisores más populares: VMware, KVM, Citrix XenServer, Xen Cloud Platform (XCP), Oracle VM Server y Microsoft Hyper-V.

Los usuarios pueden administrar su nube con una interfaz web fácil de usar, herramientas de línea de comandos y/o una API RESTful con todas las funciones. Además, CloudStack proporciona una API que es compatible con AWS EC2 y S3 para organizaciones que desean implementar nubes híbridas.

Apache CloudStack es un proyecto basado en Java que proporciona un servidor de administración y agentes (si es necesario) para hosts de hipervisor para que pueda ejecutar una nube IaaS. Algunas de las características y funcionalidades proporcionadas por CloudStack:

• Funciona con hosts que ejecutan XenServer / XCP, KVM, Hyper-V y/o VMware ESXi con vSphere
• Proporciona una interfaz de usuario amigable basada en web para administrar la nube
• Proporciona una API nativa
• Puede proporcionar una API compatible con Amazon S3 / EC2 (opcional)
• Administra el almacenamiento para instancias que se ejecutan en los hipervisores (almacenamiento primario), así como plantillas, instantáneas e imágenes ISO (almacenamiento secundario).
• Orquesta los servicios de red desde la capa de enlace de datos (L2) a algunos servicios de la capa de aplicación (L7), como DHCP, NAT, firewall, VPN, etc.
• Contabilidad de recursos de red, computación y almacenamiento
• Multitenance y separación de cuentas
• Gestión de usuarios

En resumen, las organizaciones pueden usar Apache CloudStack para implementar una nube IaaS pública o privada con todas las funciones.

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

Feliz Navidad y buen año para todos!!

Como todos los años les deseo una feliz navidad y un buen 2022. Ojo me quedaron unos post por terminar, así que vengan antes de enero... No me voy de vacaciones :D

Fue un año duro, pero que trajo buenos cambios... 

Gracias por leerme! 

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