Autor

Abraham Rodríguez actualmente desarrolla funciones de ingeniero backend J2EE en Paradigma donde ya ha realizado diversos proyectos enfocados a arquitecturas de microservicios. Especializado en sistemas Cloud, ha trabajado con AWS y Openshift y es Certified Google Cloud Platform Developer. Cuenta con experiencia en diversos sectores como banca, telefonía, puntocom... Y es un gran defensor de las metodologías ágiles y el software libre.

Ponente en

[Meetup] Have you met Istio?

  • 15 de enero del 2019
  • Ponente Abraham Rodríguez
  • KSchool

En esta nueva entrega sobre service-mesh veremos el que probablemente se convertirá en el producto de referencia: Istio. Analizaremos las funcionalidades que a... sigue leyendo

Ponente en

Ponente en

Redactor en

Development GP: la carrera del desarrollo

Hoy en día, en este mundo de la mal llamada consultoría, en el que vivimos la mayoría de los expertos en TI, existe una clásica obsesión entre los ‘clientes’, jefes de proyecto, gerentes y, a veces, incluso entre los Scrum Masters.

Se da sobre todo en los equipos que utilizan metodologías de trabajo más modernas, alejados del clásico Waterfall. Esa obsesión es la velocidad, entendiendo velocidad como la cantidad de funcionalidades de negocio desarrolladas (que no necesariamente testeadas) en un periodo de tiempo.

Si hablamos de velocidad seguro que se nos vienen, por lo menos, un par de conceptos a la cabeza y uno de ellos serán las carreras, por ejemplo, de Moto GP. En este tipo de competiciones la velocidad y el tiempo, al igual que en el software, son algunos de los factores cruciales.

sigue leyendo…

Serverless: llevando Cloud y microservicios a la máxima potencia (2/2)

En la anterior parte de nuestro post sobre serverless situamos a esta arquitectura en el roadmap del sector TI como la principal referencia a largo plazo de la industria. También analizamos diversos patrones y soluciones de la misma que ya se están utilizando en las más exitosas arquitecturas actuales.

Además, empezamos a visualizar algunos de los problemas que aún están por solventar, como son los arranques en frío.

En esta segunda parte analizaremos los demás retos que aún quedan por abordar como, por ejemplo, las conexiones de base de datos y veremos los casos de uso típicos para este tipo de arquitecturas. ¡Vamos allá!

sigue leyendo…

Serverless: llevando Cloud y Microservicios a la máxima potencia (1/2)

Todavía recuerdo, cuando a comienzos de 2018 leí un post identificando las que iban a ser las principales tendencias del año en lo que respecta a microservicios. Allí estaba Serverless, un concepto que conocía ligeramente, pero en el que no había profundizado.

Dentro de estas tendencias, Serverless no era el titular de un apartado, sino que ocupaba la sección dedicada a Event Driven Architectures (EDA).

Durante los últimos 4 años que llevamos trabajado con arquitecturas de microservicios (al menos cuando empezaron a llegar a España) los modelos de comunicación síncronos se han probado cuanto menos insuficientes para gestionar el abanico de situaciones de comunicación que tenemos en una arquitectura de microservicios. Problemas de latencias, gestión de circuit breaking anidados, patrones de orquestación…

En este contexto es donde surgen las, probablemente, dos más importantes tendencias actuales en el mundo de microservicios.

sigue leyendo…

Envoy (2/2): buceando en el plano de datos de service-mesh

Volvemos para terminar nuestro curso de buceo en Envoy. En el anterior post pusimos las bases necesarias para empezar a juguetear con funcionalidades más avanzadas: analizamos la interfaz de administración, creamos nuestras primeras configuraciones y creamos un servicio de descubrimiento que atacaba el API de Kubernetes.

Hoy bajaremos a mayor profundidad para crear un Ingress, evaluar las capacidades de gestión del fallo y configurar la trazabilidad distribuida. ¡Vamos a ello!

sigue leyendo…

Envoy (1/2): buceando en el plano de datos de service-mesh

En artículos anteriores hablamos del futuro de las arquitecturas de microservicios y de cómo service-mesh sería la tendencia clave en las mismas.

También analizamos a fondo Istio, la solución de service-mesh con plano de control más madura. En este post profundizaremos en Envoy, la solución de plano de datos y que además es internamente utilizada por Istio como sidecar-proxy.

sigue leyendo…

Jugando con Istio: ‘The next big thing’ en microservicios (1/2)

En artículos anteriores hablamos de cómo service-mesh será el nuevo paradigma para la gestión de las funcionalidades estructurales de red en las nuevas arquitecturas de microservicios.

También hablamos de Istio, la solución de service-mesh creada en conjunto por Google, IBM y Lyft basada en la experiencia de Google ejecutando aplicaciones de gran tamaño durante años en producción.

Ahora que sabemos de la importancia de Istio, nos preguntamos ¿cómo es su arquitectura? ¿Cuáles son sus funcionalidades más importantes? ¿Cómo podemos llevar a cabo su configuración? Vamos a responder a estas y otras muchas preguntas más.

sigue leyendo…

Microservicios, ¿por qué llevamos años apostando por esta arquitectura?

Las arquitecturas basadas en microservicios son uno de los componentes fundamentales a la hora de llevar a cabo el proceso de transformación digital.

Pero, ¿qué es un microservicio? Es un estilo de desarrollo por el cual aplicaciones complejas se desglosan funcionalmente en aplicaciones más sencillas, que se pueden desplegar y escalar con relativa facilidad e independencia.

Las ventajas que aporta este tipo de arquitectura: es políglota, tiene un principio de responsabilidad única; permite un escalado eficiente, elástico y horizontal en función de la demanda… han hecho que en Paradigma llevemos años apostando por esta tecnología.

Recopilamos nuestro mejor contenido sobre microservicios para ponerte al día y para darte razones de sobra para que apuestes sin miedo por esta arquitectura.

sigue leyendo…

Microservicios 2.0: Spring Cloud Netflix vs Kubernetes & Istio

Hace ya casi tres años que comenzó el boom de las arquitecturas de microservicios. Todavía recuerdo, allá por 2015, cuando redacté el que fue mi primer post sobre los componentes de la arquitectura de microservicios de Spring Cloud Netflix.

Con el paso del tiempo, la arquitectura ha ido madurando y se han ido incorporando por parte de Spring Cloud a la misma nuevas soluciones que solventan problemáticas típicamente cloud. Es el caso, por ejemplo, de Sleuth, Zipkin, Contract

Pero hoy en día la arquitectura está tendiendo a evolucionar hacia algo diferente. En este post vamos a analizar cuál ha sido el recorrido de la arquitectura de microservicios hasta ahora y cuáles son las herramientas y tecnologías que nos acompañarán en el futuro.

sigue leyendo…

Cómo optimizar tu aplicación Java en Docker (2/2)

En nuestro anterior post hablamos de las diferentes memorias que componen la JVM y de la problemática de Java 8 y los cgroups.

Al final de nuestro viaje habíamos acotado todas las memorias, pero nos seguíamos encontrando en la situación en que después de cierto tiempo los consumos seguían excediendo los límites establecidos.

Habíamos llegado a una situación que empezaba a tomar matices de Expediente X. El proceso Java seguía consumiendo más memoria de la que reportaban tanto jConsole como jcmd. ¿Cómo era eso posible? Fue entonces cuando tocó adentrarse en lo desconocido…

sigue leyendo…

Cómo optimizar tu aplicación Java en Docker (1/2)

Seguro que alguna vez has tenido que desplegar una aplicación java en un docker. Si lo has hecho en cualquier tipo de infraestructura cloud que utilice esta tecnología, te habrás encontrado con la sorpresa de la cantidad de memoria que consume.

Incluso, muchas veces, con una gran cantidad de memoria, al cabo de un tiempo (días o semanas) el docker termina cayéndose como consecuencia de la solicitud de más memoria: el temido OOM Killed (Out of Memory Management).

Antes de meternos en harina con la parte técnica, pongámonos en contexto. Durante mi experiencia profesional he trabajado en diversos proyectos construidos con la arquitectura de microservicios de Spring Cloud Netflix, desplegando en algún cloud basado en Docker (generalmente Openshift). En todos ellos ha existido siempre el problema con el consumo de memoria que hacía la aplicación.

Por si fuera poco, no es una situación que se produzca solo con microservicios funcionales (que se podría achacar a un mal desarrollo o una mala gestión de la memoria que hace el equipo), sino que incluso aplicaciones como eureka-server o config-server elevan sus consumos por encima de lo esperado para aplicaciones de tan pequeño tamaño.

Este post trata todo el proceso llevado a cabo, desde las herramientas que utilizamos para el diagnóstico hasta las diversas soluciones aplicadas. ¡Empecemos!

sigue leyendo…

Implementando test de integración entre Microservicios con Spring Cloud Contract

En artículos anteriores hablamos de cómo el patrón Consumer-driven Contracts nos proporciona un marco de trabajo para el desarrollo de acuerdos de interfaz de forma que nos permite un modelo de trabajo ágil, independiente y mantenible.

También analizamos, a alto nivel, cómo Spring Cloud Contract nos ofrece las herramientas necesarias para implementar dicho marco de trabajo.

En este post iremos un paso más allá y recorreremos todo el proceso: desde la generación del contrato hasta su uso en consumidor y productor, detallando los comandos y el código utilizado para implementar un acuerdo de interfaz con Spring Cloud Contract. ¡Empecemos!

sigue leyendo…

Consumer-Driven Contracts en Arquitecturas de Microservicios con Spring Cloud Contract

Con la expansión de las nuevas arquitecturas distribuidas (como la de microservicios) nos encontramos con una serie de problemáticas de mayor complejidad y que requieren de otro tipo de soluciones.

En el caso de las arquitecturas de microservicios uno de los nuevos retos que se nos presentan es probar la integración entre los diferentes microservicios que componen nuestro ecosistema.

Además, la existencia de nuevas tendencias y patrones en el mundo del testing, como Consumer Driven Contracts (CDC), se entrelaza con las nuevas arquitecturas para proporcionarnos un nuevo marco de trabajo en lo que a testeo se refiere.

En este post analizaremos las situaciones que nos han llevado hasta CDC y cómo este patrón nos permite llevar a cabo pruebas de integración entre microservicios basándonos en la extensibilidad y mantenibilidad de las interfaces.

sigue leyendo…

¿Eres un programador Java o un Hipster?

JHipster es un generador de código que nos permite a través de Yeoman generar una aplicación spring-boot con un front-end en angularJS. JHipster es Open Source, su código fuente se puede encontrar en GitHub, la capa back-end está construida con Java y Spring-boot, el front-end es responsive y está implementado con angularJS y Bootstrap. Para la construcción del proyecto se utilizan varias herramientas como son Yeoman, Bower, Grunt, Maven, Gradle…

En este post vamos a ver cómo se crea una aplicación con JHipster, cuáles son las ventajas y los inconvenientes de utilizar este generador de código.

logo-jhipster-drink-coffee

sigue leyendo…

Cómo monitorizar microservicios con Spring-Boot-Admin

La mayoría de vosotros ya habréis oído hablar de Spring Boot (y los que no deberíais plantearos seriamente por qué no lo habéis hecho aún). Muchos ya habréis desplegado también alguna que otra aplicación hecha con el mismo en producción. Cualquier proyecto que tengamos en producción deberá tener una monitorización para conocer el estado de nuestra aplicación, los recursos que consume…

En este post hablaremos de Spring-boot-actuator y Spring-boot-admin, que nos proporcionarán una amplia cantidad de funcionalidades de cara a gestionar y monitorizar nuestras aplicaciones Spring-boot.

aws-spring

sigue leyendo…

Cómo generar Dockers de forma sencilla con S2I

En este post se pretende realizar una introducción al framework S2I (source to image) de Openshift para la generación automática de contenedores a partir de código fuente. Si bien es un framework desarrollado para Openshift, al utilizar este la tecnología Docker, nos servirá también para generar contenedores válidos para cualquier tipo de sistema que pueda ejecutar Docker. Actualmente ya existe soporte para generar contenedores para gran variedad de lenguajes y plataformas.

docker

sigue leyendo…

Arquitectura de microservicios: trazabilidad de peticiones

Con el éxito y la expansión de las arquitecturas de microservicios se dan una serie de situaciones tecnológicas y funcionalmente nuevas, que no eran necesario solventar en las arquitecturas clásicas. Algunas de ellas  se deben principalmente a la característica distribuida de estas arquitecturas. Actualmente existen medios para solventar algunas de estas casuísticas como los proporcionados por spring-cloud-netflix para el registro de instancias, comprobación de estado, balanceo de carga, gestión de fallos en cascada…

Una de estas nuevas situaciones a las que nos tenemos que enfrentar es la trazabilidad de las peticiones. En las arquitecturas clásicas una petición que llegaba a la aplicación era resuelta funcionalmente dentro de la propia aplicación, salvo alguna interacción con base de datos o con algún servicio para funcionalidades de autenticación o similares. Pero en las arquitecturas de microservicios basados en el principio de responsabilidad única, nos encontramos un ecosistema compuesto por varias aplicaciones (cientos incluso en el caso de la arquitectura de Netflix).

Todo esto provoca que una sola petición del cliente pueda pasar por diversas aplicaciones hasta ser respondida. Y aquí surge el problema, ¿cómo podemos seguir el recorrido de esa petición?, es decir ¿como la trazamos?

imagen

sigue leyendo…

Openshift Enterprise 3: la estrella de los PaaS (2/2)

En el primer post analizamos la arquitectura de OSE, sus recursos y los comandos más habituales. Ahora que ya conocemos sus posibilidades, en esta segunda entrega vamos a enfocarnos en un caso de uso real: el despliegue de una arquitectura de microservicios. Analizaremos la problemática técnica que ha surgido y las situaciones a las que nos hemos tenido que enfrentar, así como la duplicidad de responsabilidad que existe entre OSE y dicha arquitectura software. Finalmente se incluye una s...

Openshift Enterprise 3: la estrella de los PaaS (1/2)

En la siguiente serie de posts pretendo explicar brevemente mi experiencia con Openshift Enterprise 3 en un proyecto con el que he colaborado recientemente. En concreto voy a  presentar una serie de conceptos básicos de Openshift, analizar la solución utilizada en dicho proyecto, repasar una serie de comandos básicos y evaluar la problemática encontrada al desplegar una arquitectura de microservicios. Se suponen, por parte del lector, unos conocimientos mínimos sobre Docker, Kubernetes ...

Ribbon, el equilibrador de cargas y peticiones de Eureka

Eureka se adorna con la cinta de RibbonMicroS4 ribbon logo 300

Previamente, en posts anteriores hemos identificado los componentes clave de la arquitectura de microservicios de Spring Cloud y Netflix y hemos profundizado en las posibilidades que Eureka como microservicio de descubrimiento nos proporciona. En este post analizaremos a fondo Ribbon, la librería encargada de realizar el balanceo de carga en cliente.

 

Como hemos hecho en entradas anteriores, analizaremos Ribbon integrado con Eureka para el hallazgo de las instancias que componen un microservicio, conformando así una arquitectura de microservicios como la mencionada.

sigue leyendo…

Ribbon: el balanceador de carga de spring-cloud-netflix (3/3)

Balanceador y filtros de balanceo

Como se ha comentado en secciones previas, las reglas de balanceo son las encargadas de escoger la instancia a la que se enviará la petición, pero entre qué instancias se aplicará la regla está determinado previamente por el balanceador y los filtros de balanceo.

Este balanceador y sus filtros implementan lógica de zonas, es decir, su función es determinar qué zona o zonas son válidas para enviar las peticiones. Una vez escogidas las zonas se aplicará las reglas de balanceo entre todas las instancias que componen dichas zonas. La lógica de selección de zonas, en la que profundizaremos más adelante, se basa en descartar zonas que no cumplan unas condiciones mínimas (carga, número de instancias…) y en intentar fomentar la afinidad de zona, esto es, escoger la zona en la que se encuentra la instancia que va a realizar la petición.

sigue leyendo…

Eureka: Registro de microservicios (1/2)

En artículos anteriores se han identificado los principales componentes de la arquitectura de microservicios de Spring Cloud enumerando las ventajas que cada uno aporta (El ‘who is who‘). En el siguiente post, y otros que se publicarán próximamente, se pretende profundizar en dichas ventajas metiéndonos en harina con uno de los componentes: Eureka. Para ello se han configurado y probado las diferentes funcionalidades que se pueden ver a continuación.

sigue leyendo…

Microservicios Spring Cloud: Arquitectura (1/2)

Desde un tiempo a esta parte se ha empezado a escuchar conceptos como la arquitectura de microservicios, una especie de versión 2.0 de una arquitectura distribuida. Este tipo de arquitecturas se han visto espoleadas por el gran auge de las tecnologías Cloud, las cuales le vienen “como anillo al dedo”.

En este post, y en una segunda parte que publicaremos próximamente, se pretende identificar quienes son los “new kid in town” en esta arquitectura y qué papel juegan en ella.

sigue leyendo…

Spring Cloud Microservices: Architecture (1/2)

For a while now we have started to hear about concepts like microservices architecture, some sort of version 2.0 of a distributed architecture. This type of architecture has been spurred on by the great boom in Cloud technologies, which fit perfectly with it.

sigue leyendo…