Servicios reactivos

points-1594747_640

Si buscas información sobre microservicios, te encontrarás con algo curioso el manifiesto de sistemas reactivos de 2014. Lo primero que llama la atención es este curioso nombre ¿Qué es un sistema reactivo? ¿a qué “reacciona”? todavía no he encontrado un sentido a ese nombre, si lo veis, me lo decís por favor.

Pero lo importante es el contenido y en este manifiesto hay mucho. Después de un pequeño preámbulo donde se habla que las aplicaciones de hoy en día no son como las de antes…, y tanto que no, sólo hay que pensar que la típica aplicación de hace unos años estaba destinada a unos cientos de usuarios como mucho en horario de oficina, mientras que las que hay ahora pueden llegar, literalmente, a cientos de millones de usuarios en todo el mundo con 24/7.

4 características que definen a los sistemas reactivos

Son cuatro, sólo cuatro, las características que definen este tipo de sistema:

  1. Responsivos
    “Responden de una manera oportuna en la medida de lo posible”.
    Lo primero que debe darnos un sistema es que nos de servicio, en un tiempo máximo predefinido cumpliendo así con la calidad del servicio comprometida.
    Esta característica proporciona confianza al usuario final y, como dice el manifiesto, simplifica el tratamiento de errores y favorece el uso de la aplicación.
  2. Resilientes
    En su segunda acepción, la RAE define la resiliencia como la capacidad de un sistema para recuperar su estado inicial cuando ha cesado la perturbaciónn a la que había estado sometido. Vamos, como diría el clásico, que el sistema debe ser como un junco que se dobla pero no se parte.
    Traducido a nuestros servicios quiere decir simple y llanamente que cuando se encuentra con un fallo, el sistema tiene que continuar y dar una respuesta válida.
  3. Elásticos
    El sistema debe escalar de manera lineal y soportar la carga de trabajo cuando aumenta usando más recursos pero también liberando estos mismos recursos a medida de que ya no se vayan necesitando cuando la carga disminuye.
  4. Orientados a mensajes
    Y cuando dice orientado a mensajes, dice que el sistema debe ser en lo posible asíncrono. Esta quizás sea una de las grandes asignaturas pendientes… no parece que abunden los servicios asíncronos y seguimos pensando en que un servicio debe ser síncrono por defecto.
    Si queremos que el sistema asegure un bajo acoplamiento, un gran rendimiento, tolerante a fallos, etc. etc. tiene que ser asíncronos.

En mi opinión estas características son deseables en todo sistema y deberíamos al menos, plantearnos en el diseño si las tendríamos que cumplir o no, y en caso afirmativo, como podríamos implementarlas. ¿Quien no quiere que su sistema sea tolerante a fallos, que respondan en un tiempo máximo preestablecido o que sean capaces de asumir una gran demanda de carga?. Por supuesto, nada es gratis, y para conseguir esto a buen seguro que tendremos que complicar nuestra implementación por lo que debemos ser conscientes si el beneficio a obtener compensa este coste suplementario.

Y tú ¿estás de acuerdo con que un sistema tiene que cumplir con estas características o esto no es necesario?

Nos vemos en Perú

banner-soaoct2016

Pues sí😉, el mes que viene impartiré un curso de SOA Analyst y SOA Governance en Lima. Será en concreto el 17 de octubre, con los amigos de CAC-TI.

Se trata de dos cursos oficiales de SOA School para los que me he preparado durante bastante tiempo. Primero certificándome yo mismo en SOA School, ya que para ser profesor hay que tener las certificaciones que se quieren impartir. Después, certificándome como trainer certificado, pero ha merecido la pena.

Para mí es un gran oportunidad profesional y agradezco a la gente de CAC-TI que haya confiando en mí para esta tarea. Más todavía, es una gran responsabilidad, espero que los que podáis asistir al curso quedéis satisfechos con el mismo y os sirva, y mucho, en vuestra carrera profesional. Yo estoy poniendo todo de mi parte para que así sea.

En los enlaces de los cursos podéis ver toda la información. No obstante os resumo el contenido de los mismos.

SOA Analyst

Un Analista SOA se especializa en llevar a cabo el análisis y la definición de los planos del inventario de servicios, y el modelado y definición de los servicios, capacidad de servicios y composición servicios candidatos.

Un Analista SOA desempeña un papel esencial en los proyectos de SOA porque los planos y especificaciones resultantes de los esfuerzos del análisis orientadas a servicios establecen las bases para los servicios y soluciones orientadas a servicios que posteriormente son diseñados y creados.

Como parte de esta formación, los participantes aprenderán los conceptos fundamentales, objetivos y requisitos asociados con SOA y la orientación a servicios, con énfasis en la conceptualización de servicios y el impacto del gobierno de servicios.

Además, los participantes conocerán el ciclo de vida de la entrega del proyecto global de SOA, incluyendo las estrategias de entrega y su impacto en las fases de análisis y las consideraciones relacionadas con la gobernanza de los servicios.

SOA Governance

El curso SOA Governance Specialist Workshop es preparatorio para conseguir la certificación SOA Governance Specialist Certified. Un Especialista Certificado en SOA Governance demuestra competencia en la definición, establecimiento y evolución de los marcos de gobernanza, en los preceptos y procesos para soportar los requerimientos organizativos y tecnológicos del gobierno SOA.

Para ser considerado un experto en este campo se requiere de conocimiento probado de cómo se incorporan las reglas de gobierno, políticas y prácticas dentro de las iniciativas SOA y cómo se separan de aspectos como la gestión y la metodología.

Como campo práctico, el gobierno de SOA abarca y afecta a las consideraciones de planificación, tales como el alcance de adopción de SOA, definición de dominio, modelos de financiación, estructuras organizativas, y la creación de una oficina de gobierno independiente, así como consideraciones del proyecto en curso, incluyendo la evolución del ciclo de vida del servicio, los roles del proyecto, procesos de revisión y de apelación, control de versiones y gestión de la configuración, y selección de proveedores de tecnologías relacionadas con la gobernabilidad.

Un Especialista en SOA Governance tiene competencias para definir, ejecutar y mantener las estrategias y planes de gobernabilidad de SOA y asegurar su continuidad efectiva en apoyo del logro de los objetivos de las iniciativas SOA.

Muerte a la ventana de despliegue

Hace ya algunos años, recuerdo que en un banco en el que trabajé, teníamos una “ventana” de despliegue dos veces al mes (dos jueves). Es decir, únicamente había dos días al mes en los que podías desplegar algo en el entorno de Producción. No sólo eso, además tendrías que hacer la petición como una semana antes… es decir, si querías desplegar alguna nueva funcionalidad tendrías que tenerla lista como 10 días antes del paso a Producción. Todavía más, cada paso por el entorno previo tardaba una semana al menos, así que si tenías un cambio en el entorno de Integración o Desarrollo, podías contar aproximadamente con un mes para ver ese cambio en el entorno de Producción… todo muy ágil ¿no?.
Evidentemente se trataban de otros tiempos. Las aplicaciones eran aplicaciones silo que tenían una base de usuarios (en este caso empleados del propio banco), el ciclo de vida de la aplicación se contaba en años y se quería máxima estabilidad en un proceso crítico (el paso a producción) que era como un parto.

Nuevos tiempos

En mi opinión, si hacemos una nueva aplicación o un conjunto de nuevos servicios, y necesitamos una ventana de despliegue para ponerlos en producción, tenemos un problema. 

En primer lugar, si entendemos la ventana de despliegue como un periodo de pérdida de servicio para estos servicios, ¿que momento sería ese?. Es cierto que en el pasado, las aplicaciones estaban pensadas para un colectivo concreto (normalmente un colectivo interno) que trabajaba en horario de oficina y que, por suerte, nos dejaba el fin de semana libre para poder hacer y deshacer con el aplicativo en producción. O un cierto número de horas por las  noche, donde también se aprovechaba para ejecutar algunos batch necesarios para consolidar datos, importarlos, exportarlos, etc. etc.

¿Que ventana de inactividad podríamos tener ahora con servicios globales (ya no hay noche) y que pueden ser usadas por todo tipo de colectivos (ya se nos acabó el fin de semana)?.

¿Hace falta realmente una ventana de inactividad o una ventana para el despliegue de PRO? si los servicios están bien hechos creo que no.

¿Por qué digo esto?

  1. Estamos hablando de unos servicios cuya dirección física no conocen sus clientes. Gracias al registro de servicios podemos logar la transparencia en la ubicación de estos. 
  2. También, a buen seguro, tendremos un componente que hace de balanceador para las varias instancias de estos servicios. Servicios que estarán desplegados en varios nodos de un servidor de aplicaciones. 
  3. ¿No se podrían coordinar el balanceador y los nodos para ir apagando uno a uno, actualizando el desplegable de los servicios y volver a ponerlos online uno a uno sin que el cliente se ni siquiera se entere?.

¿Para qué queremos entonces una ventana de despliegue? Si tenemos una, tendremos que hacernoslo mirar, seguramente hay algo que no funcione como debería.

La insoportable levedad del REST

spring-657483_640

Después de la lectura de este artículo, me he quedado un poco sorprendido por la tesis que él se plantea. Tanto que no he podido evitar reseñarlo en el blog.

Dejando aparte que el autor  dice que las APIs REST le parecen desagradables, lo que es un poco subjetivo, vamos a recapitular por qué dice que esta forma de diseñar APIs es mala:

  1. Hay poco acuerdo en lo que significa REST.
    Mi opinión aquí es que no es así exactamente. Dejando aparte que como todo en esto siempre hay un punto de ambigüedad, creo que hay un consenso bastante generalizado de lo que es REST. Incluso creo que hay unas reglas muy sencillas para hacer un API REST (o al menos bastante REST).
  2. El vocabulario REST no está totalmente soportado.
    Esto puede ser así en los browsers como comenta, pero también podemos tener clientes REST que son aplicaciones, como las apps móviles, en los que se puede usar todo el vocabulario.
    En lo que respecta a usar el truco en los navegadores de mandar el verdadero verbo de HTTP (como DELETE) escondido en otro campo, digamos que no queda muy bonito, pero yo lo he usado y es práctico.
  3. El vocabulario no es lo suficientemente rico para las APIs.
    Está claro que no tiene todo el vocabulario, ni podemos expresar toda la semántica de un caso de negocio con los verbos de HTTP, pero yo diría que se aproxima bastante. En definitiva, creo que lo que perdemos en riqueza de vocabulario lo ganamos en sencillez.
  4. Son muy difíciles de depurar.
    Este punto no lo entiendo la verdad, ¿por qué dice que es difícil depurar? ¿Por que hay que saber la URI, el JSON, el código de retorno para poder invocarlo? no lo veo tan complicado.
  5. Están muy acopladas al HTTP.
    Esto es indiscutible, pero lo que hay que preguntarse es ¿Hay algún problema con esto? Me parece que no. El protocolo HTTP está por todos lados, es bien conocido y muy usado. Precisamente por eso es fiable y robusto.

En lugar de REST… JSON-Pure APIs

¿Y que es lo que propone para sustituir a REST?. Su propuesta es un concepto que denomina JSON-Pure APIs, que entre otras, tiene las siguientes características:

  1. Sólo usa un método de transmisión para mandar un request, normalmente un HTTP POST
  2. Separa completamente el contenido del mecanismo de transmisión
  3. Usa un sólo código de respuesta para confirmar la recepción del mensaje, normalmente HTTP Code 200
  4. Separa completamente la respuesta del mecanismo de transmisión.
  5. Es fácil de depurar porque toda la información está contenida en un mensaje JSON fácil de leer, con un vocabulario específico del dominio de negocio
  6. Puede ser fácilmente adaptado a diferentes canales de transmisión, como HTTP/S, Websockets, XMPP, etc.

Y digo yo, que si a todas estas características que propone para esta forma de diseñar APIs, sustituyes JSON por XML, tendremos a un viejo amigo… el SOAP. Precisamente el SOAP es independiente del protocolo de transmisión, usa sólo 200 o 500 como códigos de retorno, está autocontenido en el mensaje (estilo document), etc. etc. Todo eso está muy bien, pero si quieres todas estas características, ¿porque no usar SOAP y la pila WS-*en lugar de inventarse un nuevo estilo de diseñar las API?s.

Precisamente el éxito de las APIs tipo REST (uno de ellos) viene de su sencillez, su ligereza, su levedad… y de utilizar lo que viene de caja en el HTTP. No hace falta inventarse nada (cuanto más se invente más cuesta transmitirlo al resto del equipo y posibles usuarios del API). Todo ya está predefinido, ya se saben los verbos que hay, incluso los códigos de retorno. ¿Por otra parte, queda hoy en día algo que tenga chip y que no soporte le protocolo HTTP? Yo diría que no.

En definitiva, creo que no utilizaré el JSON-Pure APIs😉 ¿y tú?

Serverless, la nueva tendencia

less-is-more-791109_640

Hacía ya tiempo que no aparecería un nuevo concepto, un nuevo palabro, en el ámbito de la arquitectura T.I., del estilo de BaaS (Backend as a Service) o de Microservicios… pues bien, ya tenemos aquí uno: Serverless

Como en muchos de estos conceptos, el nombre no es muy afortunado, ya que si nos hablan de una aplicación del tipo serverless (sin servidor), lo primero que podemos pensar es que se trata de una app web o móvil que se ejecuta totalmente en el lado del cliente, en el dispositivo, y que obviamente, no tiene servidor. Pues bien, esto no es tan sencillo, ya que una aplicación de este tipo, si bien no tiene un servidor como el que estamos a acostumbrados a ver, sí que tiene una parte servidora en definitiva.

Concepto de Serverless

Este artículo del site de Martin Fowler ofrece una explicación del concepto y de sus orígenes, que básicamente se empezó a usar para definir a aquellas aplicaciones que dependen en servidor de terceras aplicaciones o servicios de terceros para manejar el estado y la lógica de negocio en el lado del servidor.

En lugar de tener una aplicación en el servidor, un conjunto de servicios, empaquetados en uno o varios artefactos (no tiene que por qué ser una aplicación monolítica). Un servidor de larga duración, es decir, pensado para arrancarlo y mantenerse vivo indefinidamente para responder a las peticiones de la parte cliente, tendremos otra “cosa”. Y esta cosa en realidad son varios servicios de terceros y algunas lógicas de negocio de vida efímera que sólo se “levantan” en respuesta a un evento y luego se vuelven a destruir… estaremos hablando de lo que se conoce como serverless.

sketch

En el ejemplo que se pone en el mencionado artículo tenemos una aplicación, que en la parte servidora, se compone de lo que llama “lógica de infraestructura” como un repositorio de autenticación que está manejado por terceras partes, en la nube, como por ejemplo un servicio de autenticación en Microsoft Azure. También se muestran bases de datos de sólo lectura que pueden estar en base de datos hosted en cloud….

Hasta este punto, yo no vi ningún problema en el planteamiento, pero la siguiente pregunta que cabe hacerse es “¿y qué pasa con la lógica de negocio de la aplicación?”. Para eso, sí que se necesita un servidor propio de la aplicación ¿no? ¿dónde está en un planteamiento serverless?

Pues bien, la respuesta a esta pregunta, es que se tienen lógicas de negocio o “funciones” propias de la aplicación en el servidor, pero no tenemos un servidor como tal… como podríamos imaginar un servidor Tomcat con una aplicación web Java en él…sino que  tendremos únicamente contenedores muy ligeros para esta lógica… una lógica como servicio o más bien “Function as a Service” (FaaS).

Un ejemplo de este contenedor de funciones o de lógicas de negocio es Amazon AWS Lambda que se describe precisamente como “ejecuta código sin pensar en servidores. Paga sólo por el tiempo que consumes”.

Captura de pantalla 2016-07-25 a las 17.06.40

Conclusión

En definitiva, Serverless es una vuelta más de tuerca al concepto de la nube y del “X as a service” llevado al extremo. Si en realidad sólo quiero ejecutar unas lógicas de negocio ¿para qué quiero gestionar un servidor?… dime dónde puedo “alojar” estas lógicas y se ejecutarán cuando se necesite, y cuando no las necesito, permanecerán “apagadas” y no me costarán un céntimo…. muy interesante.

 

 

Dominando la asincronía

clock-1392328_640

Llevo ya bastantes años programando, casi una eternidad, sobre todo en Java, pero también en php últimamente, y al principio, en la carrera, en todo tipo de lenguajes como C, Pascal, LISP, PROLOG, etc.

Hasta ahora me había encontrado con el uso de la asincronía muy de pasada, sobre todo cuando programé en java para el escritorio, con la librería Swing. Lo típico de crear un hilo nuevo para hacer un trabajo pesado y no detener el hilo de trabajo del primer plano para que el usuario no percibiera lags en la aplicación. Alguna llamada a un servicio asíncrono con un callback… en el servidor no se es muy amigo de crear hilos… en fin, ni de lejos nada con lo que he visto en los últimos días…

Renovarse o morir

Si amigos míos😉, he caído en el reverso tenebroso y me he puesto en serio a aprender node.js y de pasada el javascript… despúes del subidón inicial al comprobar que era capaz de hacer algún bot con el framework de Microsoft ha venido la gran depresión al encontrarme con un hecho que al principio parece anecdótico.. programar en node.js no tiene nada que ver respecto a hacerlo en aplicaciones Java de servidor. En java estamos a acostumbrados a que el servidor te asigne un hilo de ejecución (un thread) y en él puedes ejecutar el código que quieras de manera secuencial, todo muy “natural”, todo como siempre ha sido…

Sin embargo, node.js no es multihilo, sólo tiene un hilo de ejecución en realidad, pero casi todo lo que hace lo hace en modo asíncrono. Eso significa que cuando llamas a una función normalmente le pasas como parámetro otra función de callback para que te llamen una que se acaba el trabajo de la primera función… hasta ahí bien, pero que pasa cuando tienes que llamar a un servicio que te da una lista de elementos y después tienes que llamar a un servicio de detalle por cada elemento de la lista? pues que se desatan los infiernos… o como llaman los entendidos el callback hell.

Un ejemplo… ¿sencillo?

Para ilustrar un poco lo que quiero decir, os pondré el ejemplo de una prueba que hecho. La prueba consiste básicamente en llamar al API de Wunderlist (el gestor de tareas) para que liste las tareas que ya han alcanzado su fecha de fin.

Como en Wunderlist las tareas se agrupan en carpetas, lo que hay que hacer es obtener la lista de carpetas y luego en un bucle, para cada carpeta pedir sus tareas y ver si la fecha de fin es menor que la fecha actual. Desde el punto de vista de la programación secuencial tradicional ningún problema al respecto, únicamente hay que conocer el API de wunderlist y prácticamente ya está listo.

En cuanto se pasa a node.js, empiezan las cosas a complicarse, y mucho… se desatan los infiernos…. y es que como todo es asíncrono, la pedir el listado de carpetas, y empezar con la petición de las tareas, te encuentras que empieza una invocación cuando no ha acabado la anterior…. un desastre.

En la programación “tradicional”, se dispone de herramientas como la sincronización de métodos, los semáforos, etc. etc. para esperar a que un hilo acabe antes de continuar con la ejecución de otro… si embargo, la “manipulación” de hilos en el servidor no está permitida.

Al final, después de muchas pruebas, pensé en montar un sistema de pilas de trabajos, en la que se van apilando los “recursos” como las carpetas y las tareas según se vayan obteniendo y luego otro “hilo” que saca estos objetos de la pila y los trata. Cuando la pila se vacía, entonces todo el trabajo se ha acabado.

Este enfoque me parecía matar moscas a cañonazos para hacer algo tan simple como recuperar un listado de tareas de wunderlist… sin embargo, investigando un poco di con una librería de node.js que hacía precisamente esto, es esta async.

Captura de pantalla 2016-07-09 a las 10.24.39

En fin, como conclusión, tengo que decir que node.js me gusta mucho, a pesar de mis reticencias iniciales de programar en javascript (para un programador Java es poco menos que pasarse al lado oscuro😉 pero veo que tiene una gran potencia… y que es un lenguaje con futuro en el que se basan las “cosas nuevas” como los frameworks de desarrollo de bots. Así que no está nada mal salirse de la zona de confort y aprender no ya un nuevo lenguaje, si no una nueva plataforma y sobre todo una nueva forma de programar.

Buenas practicas en el desarrollo de servicios REST

Captura de pantalla 2016-06-05 a las 18.47.08

Siempre me ha gustado la documentación de WS2 (leído “güesos” para los amigos), el fabricante de Bus y API Gateway, en especial sus diagramas que encuentro tremendamente simples y autoexplicativos. Es por eso que no me he podido resistir a bajar su documento de buenas prácticas en servicios REST que puedes pedir aquí.

Antes de entrar en el contenido en sí del libro hay que recordar la definición de niveles de madurez de REST que puedes ver aquí, todo un must have que hay que tener cuenta cuando nos enfrentamos en el diseño de servicios REST. Esta clasificación del nivel de un API gateway nos ayuda a aprender el diseño del mismo y nos ayuda también a prevenir los errores más comunes en el diseño de servicios REST.

maturity

Sobre el documento de WS2, un poco largo, no todo es correcto a mi modo de ver. Me llama la atención la fijación que tienen sobre el data model, el que hay detrás del API. Y es que parece que consideran que el objetivo de todo API es acceder a un modelo de datos. ¿Dónde se quedó la orientación a objetos y la caja negra que todo servicio debe ser?. En mi opinión el modelo de datos es algo que debe permanecer oculto para el consumidor del API. Yo lo consideraría más bien como diagrama de clases.

Resource URIs

Especialmente importante es el apartado 5, sobre el diseño de las URIs de los recursos, que inexplicablemente parece que no se sigue demasiado.

{scheme}://{host}/{base-path}/{path}[?{query-string}]

Usa la barra “/” para indicar la relación jerárquica entre recursos. El nombre del padre debe preceder el nombre de sus hijos inmediatos.

El path base

/{feature-code}/[ {sub-code}/ ]/{version}

Propone la siguiente estructura para definir la base del path de la URI, agrupando los servicios por funcionalidad o feature. Dejando espacio también para una substructura (sub-code) si necesitamos hacer una subdivisión de los servicios por grupos de funcionalidad.

La versión del API es parte de su URI

Un documento útil y completo

También se trata el uso de los verbos de HTTP, las cabeceras de entrada y de respuesta y como no, lo que considero mi preferido, los códigos de status. ¿Por qué no se usan estos códigos en las APIs que veo en el día a día? es uno de esos misterios de la vida.

Temas como el filtro en las búsquedas, la paginación y el cacheo en la parte cliente también tienen cabida en este documento de buenas prácticas, sin olvidarse de la seguridad y de como reportar de errores.

Evidentemente no se puede estar al 100% de acuerdo con el documento pero casi. Una lectura muy recomendada si se quiere saber cómo diseñar servicios REST.