Que es una REST API?

REpresentational State Transfer (REST) es un estilo arquitectónico que maneja la relación entre cliente y servidor, con el propósito de obtener velocidad y rendimiento utilizando componentes reutilizables.

REST cómo tecnología fue introducida en 2000 en la tesis doctoral de Roy Fielding. Hoy en día se ha implantado de tal forma que es preferida a la tecnología SOAP (Simple Object Access Protocol) ya que usa menos ancho de banda y es más simple y flexible para su uso en internet. Podemos usarlo para recoger o suministrar información desde un web service y se hace vía petición HTTP al API REST.

Qué es un API REST?

Un API REST es una forma de acceder a un servicio web sin tener exceso de procesamiento. Cada vez que se llama a un API REST, el servidor transfiere al cliente una representación del estado de recurso solicitado.

¡De hecho usamos API REST todos los días! Cuando buscamos videos sobre ciclismo en youtube. Tecleas "ciclismo" en el campo de búsqueda de youtube, al presionar enter y se ve una lista de videos sobre ciclismo. Esta es la forma en que trabaja un API REST. Buscamos algo y obtenemos una lista desde el servicion web con los resultados de la busqueda solicitada.

Un API(application programming interface) es un conjunto de reglas que permite a un programa comunicarse con otro. Un desarrollador crea un API en un servidor y permite a otros programas hablar con ella.
REST determina el aspecto del API. Esto es, las reglas que los desarrolladores siguen cuando crean el API y cuando lo utilizan. Una de estas reglas establece que deberías obtener unos datos determinados cuando enlazas con una URL. A esta URL se le llama punto de entrada.
La URL es llamada request (petición) y los datos devueltos se llaman response (respuesta).

Arquitectura RESTful

Las características fundamentales de un API REST, son:

• Sin estado: Ningún dato del cliente se almacena en el servidor. Lo necesario para mantener la sesión entre cliente y servidor se almacena en el cliente, típicamente en sessión storage.
• Client<->eServidor: Hay clara separación de lo que hace el cliente(front-end) y lo que hace el servidor(back-end). Estos operan independientemente y son reemplazables.
• Cache: Los datos provenientes del servidor se cachean en el cliente, esto mejora la velocidad de obtención de datos.
• Composición de la URL: Se usa un enfoque estándar para la composición de las URLs. Por ejemplo, una petición con método GET "http://servidor/ciudades" devuelve una lista de ciudades mientras que "http://servidor/ciudades/burgos" desvuelve los datos de la ciudad de Burgos. Las APIS REST también ejecutan acciones para añadir, modificar o borrar datos como se explica a continuación.

REST en acción

La petición se envía desde el cliente al servidor vía HTTP como una URL que enlaza con una web. Está petición usa los métodos http GET, POST, PUT o DELETE. Entonces la respuesta es enviada desde el servidor en forma de recurso que puede ser HTML, XML, imagen o JSON. JSON es el más popular.

HTTP tiene entre otros los métodos: POST, GET, PUT, y DELETE. Estos métodos corresponden con las operaciones crear(create), leer(read), actualizar (update) y borrar (delete). Estas son llamadas las operaciones CRUD y son muy habituales en los aplicativos. Cada uno de estos métodos opera de la siguiente manera:

• POST: Este método se usa para crear un nuevo recurso. Si todo va bien devuelve un código 201 con una cabecera conteniendo el enlace al nuevo recurso.
• GET: Este método se usa para recuperar un recurso. Si todo va bien GET devuelve por ejemplo un XML o JSON con los datos solicitados y un código de respuesta 200. Si algo va mal devuelve un código de error, por ejemplo 404 Not Found o 400 Bad Request.
• PUT: Se usa principalmente para actualizar un recurso o en casos especiales para crearlo. Un update que se ejecuta con éxito retorna un 200 o 204 sino devuelve ningún contenido en el body. Si se usa para creación y acaba bien devuelve un 201.
• DELETE: Borra un recurso, normalmente se suministra el identificador. Después de un borrado con éxito devuelve 200.

Las operaciones CRUD se envían desde el cliente al servidor escribiendo una URI en un browser o haciendo un fetch en un programa. En los servidores se instalan servicios que responden a estas peticiones mediante distintos puntos de entrada. Un ejemplo de como son habitualmente estos puntos de entrada es:

GET  /device-management/devices      : recupera todos los devices
POST  /device-management/devices      : crea un nuevo device
GET  /device-management/devices/{id} : recupera el device con identificador id
PUT  /device-management/devices/{id} : actualiza el device con identificador id
DELETE /device-management/devices/{id} : borra el device con identificador id

Trabajando con los datos del API REST

También es una práctica habitual que el API REST devuelva datos en formato JSON. El formato  JSON (JavaScript Object Notation), cuando se reciben datos de un API Rest tienen el siguiente aspecto:

{

    title: "Hola, Soy JSON",
    content: [
        chapter: "1",
        page: "100",
        firstParagraph: "Soy JSON, este es mi aspecto cuando me devuelve el API."
    ],
    author: "Bruce Smithesson"
}

¿Dónde se pueden encontrar APIs REST? ¡¡¡Por todos los lados!!! Twitter. Google. Open Weather Map. YouTube.  La mayoría de los servicios más populares que se usan actualmente utilizan una arquitectura RESTful. Así que ¡adelante!, explorad el mundo de añadir funcionalidad de API a vuestros sitios WEB.

Conclusión

Hemos echado un vistazo a lo que es un API REST e indagado en lo que es arquitectura RESTful. Hemos visto como funciona un API REST a través de puntos de entrada y visto como es un fichero en formato JSON.

Este Post es una traducción e interpretación a mi entender del POST
https://itnext.io/javascript-fundamentals-an-introduction-to-rest-apis-7cbe8a809d3b

Qué es el "Chaos Monkey"

Chaos Monkey es una herramienta software que de forma aleatoria detiene instancias y contenedores que están ejecutándose en el entorno de producción. El objetivo es exponer a los sistemas a fallos para ayudar a los ingenieros a proveer servicios que sean capaces de reaccionar a caídas y otros problemas inesperados.

La herramienta es de uso libre y se puede descargar en https://github.com/Netflix/chaosmonkey

Gareth Bowles, antiguo empleado de Netflix, en su presentación de 2015  "I Don't Test Often ... But When I Do, I Test in Production" que se puede consultar en https://www.youtube.com/watch?v=xkP70Zhhix4 explica los motivos que condujeron a Netflix a desarrollar una herramienta basada en la ingeniería del caos.

Gareth explica que debido a las características del servicio que proporciona Netflix, se hacía muy difícil probar en un entorno que no fuese el de producción. A veces la cuota de internet que ocupan los clientes de Netflix supone hasta un 34% del total del tráfico de Internet. Simular esto en un entorno de pruebas era imposible.

Entonces se les ocurrió que podían hacer varias cosas:

1. Chaos Monkey
2. Coverage en producción
3. Canary deployment

1. Chaos Monkey 

Es una herramienta software que provoca la caída de servicios en producción. De esta forma los ingenieros pueden experimentar las consecuencias de la caída y aprender a que hacer para preveer los efectos no deseados de la caída. Las caídas provocadas se hacen a horas de trabajo, donde todos los ingenieros están en la oficina y pueden ponerse manos a la obra para arreglar los problemas inmediatamente. Esto es una ventaja frente a caídas fuera de horas, que hacen que los desarrolladores y operadores tengan que salir corriendo y trabajar a deshoras o en jornadas interminables.

Cómo Chaos Monkey funcionó bien, se decidieron a desarrollar otros monkeys: Chaos Gorilla simula la caida de una zona completa de servidores y Chos Kong de una región que agrupa zonas. 

También idearon otros monkeys que por ejemplo degradan el tiempo de respuesta Latency Monkey o simulan que un servidor no cumple los estándares de configuración Conformity Monkey.

2. Coverage en producción

Es una forma de telemetría, en la que se mide que líneas de código se ejecutan en producción y cuantas veces se ejecutan.
Estas mediciones permiten saber cúal es la parte de código que se debe de probar más porque se ejercita más veces. Es decir, se pueden planificar, construir y ejecutar pruebas más efectivas.

3. Canary deployment

Se trata de desplegar software inicialmente en solo algunos servidores. Con este despliegue se comprueba si el nuevo software responde a las expectativas: funciona bien, no degrada el servicio, los usuarios lo encuentran útil, etc. El nombre de este tipo de despliegue proviene del uso de canarios en las minas para controlar la calidad del aire. En el caso de que el canario se viese afectado por la calidad del aire, las personas tenían tiempo de escapar antes de que la mala calidad del aire les afectase a ellos.

Una vez comprobado que el software cumple con las expectativas se procede a desplegarlo en el resto de los servidores. O no desplegarlo si no cumplió las expectativas.

Conclusión

Estas iniciativas han contribuido al éxito de Netflix que sin duda es una plataforma ampliamente utilizada. Por lo tanto aprendamos de ellos y quizás en otros ámbitos algunas de estas técnicas puedan usarse para ayudar a mejorar.

¿Qué es un doble de pruebas?

Las apps, las webs y otros tipos de aplicativos, están compuestos por un conjunto de módulos que funcionando todos de forma armoniosa nos ofrecen las funcionalidades que tan útiles nos resultan para realizar múltiples operaciones. Me refiero a aplicaciones cómo por ejemplo las de los bancos. Hoy en día gracias a ellas somos capaces de resolver muchas gestiones sin movernos de donde estemos.

Los distintos módulos que componen estas aplicaciones se han de probar antes de ponerlos a disposición de los clientes. No nos haría ninguna gracia perder dinero de nuestras cuentas por errores informáticos, Verdad?. Los módulos se pueden probar de forma manual o de forma automática. Para probar módulos de forma automática lo que se hace es escribir un módulo que es capaz de probar. Es decir, hacemos programas que prueban programas.

El automatizar las pruebas de los programas es una tendencia actual. Múltiples organizaciones han demostrado las múltiples ventajas que supone tener automatizadas las pruebas. Con pruebas automatizadas las aplicaciones se:

• Desarrollan mejor
• Cambian y actualizan mejor
• Funcionan mejor

Para escribir programas de pruebas existen múltiples librerías que ayudan al programador. Hay librerías tanto de pago cómo gratuitas para casi todos los lenguajes de programación.

Desde hace mucho tiempo el tema de las pruebas ha sido una preocupación para los profesionales de la informática. Para abordar su ejecución hay un estándar de facto sobre los tipos de pruebas a las que se debe someter a un aplicativo. En primera instancia se diferencias la pruebas funcionales de las no funcionales. Las pruebas funcionales se dividen en:

• Pruebas unitarias
• Pruebas de integración
• Pruebas del sistema
• Pruebas de aceptación 

Una vez establecido este escenario, se puede entender lo que es un doble de prueba. Primero se centra el discurso en la pruebas unitarias.

Las pruebas unitarias tienen el objetivo de asegurar el buen funcionamiento de cada uno de los módulos que componen el aplicativo de forma aislada, es decir no se quieren probar las interacciones con otros módulos. Es aquí donde los dobles de prueba son necesarios. Si se quiere probar un módulo que para funcionar necesita de otros pero se quiere probar de forma aislada, una solución es dotar a la prueba de suplantadores de los módulos necesarios para que el módulo bajo prueba pueda llevar a cabo su función. Estos suplantadores son los dobles de prueba. Es decir, son simulacros de módulos que implementan funcionalidades diversas.

Por ejemplo en el aplicativo del banco, podemos estar probando un módulo que recoge de una base de datos la información sobre la cuenta corriente de un cliente dado y los envía a un fichero de log. Suponiendo que el módulo bajo prueba para recoger esos datos hace uso de otro módulo que es el que accede a los datos, para la prueba unitaria se crea un doble de prueba que suplanta al módulo que accede a los datos. Esto independiza la prueba del módulo bajo prueba del módulo con el que interacciona. Aunque el módulo de acceso a datos auténtico deje de funcionar, la prueba del módulo que escribe en el fichero de log seguirá funcionando correctamente.

Los dobles de prueba son imprescindibles para conseguir hacer pruebas unitarias ya que consiguen aislar la prueba de cada modulo ciñiendose a probar solo ese módulo. Sin ellos esta sería una labor imposible.

Al igual que para construir pruebas unitarias para los otros tipos de pruebas los dobles también tienen utilidad. Un ejemplo en las pruebas de integración un conjunto de módulos se invoca a otro sistema para solicitar las coordenadas de una ubicación. Se puede hacer un doble de prueba que suplante al sistema de ubicaciones, de esta forma aunque el sistema de ubicaciones no esté disponible podemos ejecutar la prueba de nuestro conjunto de módulos.

Un doble de prueba es un módulo que suplanta a otro y simula su funcionalidad con el objetivo de poder hacer una prueba de otro que interacciona con él.

Para información más detallada y con ejemplos de código, ver el post "Pruebas software. Dobles de prueba con ejemplos (Java, Junit y Mockito)" publicado en este mismo blog el 29/9/2019.

Qué es Mocha para javascript en 2 minutos

Mocha es un framework para construir pruebas automatizadas de módulos javascript. Mocha se puede utilizar tanto para módulos que se ejecutan en NodeJS cómo los que se ejecutan en un browser.

Preparando un ejemplo de 2 minutos 

Este ejemplo se ha preparado en un equipo con Windows y NodeJS previamente instalados. 

Para instalar NodeJs en Windows ir a https://nodejs.org/en/ descargar el fichero y seguir los pasos de instalación. 

Pasos a seguir:

1. Crear un directorio PruebaMocha. Desde el directorio creado, para instalar Mocha usar el comando:

npm install mocha

cómo resultado del comando aparece un directorio node_modules que contiene las librerías del framework Mocha.

2. Para construir la prueba crear el fichero miprimermochatest.js con el siguiente contenido: 

    Var assert = require('assert'); 
    describe('Array', function() { 
      describe('#indexOf()', function() { 
        it('should return -1 when the value is not present',
            function(){
          assert.equal([1, 2, 3].indexOf(4), -1);
        });
        it('should return 0 when value 1 is present on position 0', 
            function() {
          assert.equal([1, 2, 3].indexOf(1), 0);
        });
      });
    }); 

3. Para ejecutar la prueba usar desde el directorio PruebaMocha el comando:

node_modules\.bin\mocha miprimermochatest.js 

Se obtiene el resultado: 

    Array
     #indexOf()
     √ should return -1 when the value is not present
     √ should return 0 when value 1 is present on position 0
    2 passing (12ms) 

Conclusión

Este código es un ejemplo muy sencillo para mostrar cómo se automatizan las pruebas. Aquí, el código probado está incluido en el propio módulo de prueba, sin embargo normalmente el código probado está en módulos aparte que constituyen el código del aplicativo que se está probando.

En definitiva se trata de hacer programas que prueban programas. Aprender a hacer programas que tienen pruebas automatizadas, no es baladí. Para que las pruebas sean funcionales y operativas, no solo se deben preparar pruebas bien diseñadas sino que los módulos a probar también tienen que estar diseñados de manera que sean testables. Pero esa, es otra historia.

Qué es SAFE Scaled Agile Framework

SAFe® for Lean Enterprises es una base de conocimiento que incluye principios, prácticas y competencias cuya utilidad está basada en la experiencia. El objetivo de una empresa Lean es llegar a ser un negocio próspero de la era digital y entregar sistemas y soluciones competitivas a sus clientes en el tiempo más breve posible. El Scaled Agile Framework combina el poder de “Agile”, con el conocimiento de “system thinking” y el desarrollo “Lean” de productos para ayudar a los negocios a abordar los retos de desarrollar y entregar soluciones empresariales basadas en tecnología de alta calidad. Es una base de conocimiento de patrones de éxito probados en el mundo real, para conseguir la agilidad de negocio.

Los beneficios de SAFe: “Con un framework ya probado, podemos entregar soluciones mucho más rápido y con menos esfuerzo. SAFe define roles, equipos, actividades y artefactos para aplicar principios Lean y Agile a nivel empresarial y proporciona extraordinarios materiales de aprendizaje y entrenamiento para incrementar tus posibilidades de éxito” .” —Peter Vollmer, Hewlett Packard Enterprise.

Distinguidas empresas tecnológicas deben aprender cómo adaptarse a las cambiantes condiciones tecnológicas y económicas o se extinguirán, no importa su tamaño, su fuerza o lo inteligentes que sean. La agilidad no es una opción, es una necesidad. Incluso los negocios que no se consideran compañías de software – Servicios profesionales, financieros, fabricantes, instituciones sanitarias, agencias del gobierno y más – son actualmente muy dependientes de su habilidad de producir nuevos productos y servicios basados en tecnología innovadores y de alta calidad.

Es la mision de Scaled Agile Inc. ayudar a estas empresas con el crecimiento de su negocio digital mediante el desarrollo y la publicación de la base de conocimiento SAFe, así cómo proporcionar certificaciones, formación, cursos, comunidades y una red global de más de 280 socios que subministran herramientas y servicios.

Partiendo de más de una década de experiencia mejorando los logros del desarrollo de sistemas, SAFe parte de 4 cuerpos de conocimiento: desarrollo agile, systems thinking, desarrollo Lean de productos y DevOps. De esta forma ayuda a las empresas en las siguientes cuestiones:

•  ¿Cómo alinear el desarrollo tecnológico con los objetivos estratégicos?
•  ¿Cómo realizar la entrega de valor en el momento preciso?
•  ¿Cómo mejoramos la calidad de nuestras soluciones y deleitamos a nuestros clientes?
•  ¿Cómo escalamos las prácticas ágiles desde los equipos a toda la empresa para entregar mejores resultados?
• ¿Cómo organizamos a la gente para entregar valor de forma eficiente y evitar los retrasos inherentes a las tradicionales estructuras funcionales?
• ¿Cómo creamos un entorno que incentive la colaboración, la innovación y la mejora continua?
• ¿ Cómo animamos a la gente a aceptar los riesgos, pensar creativamente y adoptar el aprendizaje continuo?
• ¿Cómo podemos ayudar a los equipos que aprendan a mejorar de forma autónoma?

Adoptando SAFe y aplicando sus valores, principios y prácticas – la empresa puede abordar estas cuestiones y mejorar el negocio y los beneficios de los individuos. SAFe 5.0 permite la agilidad del negocio y mejora los logros de organizaciones de todos los tamaños. SAFe ha producido mejoras dramáticas en reducción de time-to-market, compromiso de los empleados, mejoras en la calidad, satisfacción del cliente y el logro de mejores resultados económicos. También ayuda a crear culturas que son más productivas, gratificantes y frescas.

Antes de que una empresa pueda obtener estos beneficios, debe transformarse en una empresa Lean. Esta transformación requiere desarrollo de “competencias empresariales” que permitan un nuevo estilo de liderazgo, nuevas formas de pensar y trabajar y una cultura centrada en la entrega de valor y la mejora continua.

La base de conocimiento de SAFe describe roles, responsabilidades, artefactos y actividades para implementar desarrollo Lean-Agile a nivel empresarial. SAFe sincroniza alineamiento, colaboración y entrega en organizaciones con un gran número de equipos agile tanto técnicos como de negocio. SAFe es escalable y configurable, dando soporte tanto a soluciones que implican de 50 hasta 125 profesionales así como entornos más complejos que requieren miles de personas. El website del framework (https://www.scaledagileframework.com/) dispone de la “Big-Picture”, este gráfico es una visión del marco completo y es  la interfaz de usuario con la base de conocimiento. Cada icono de la imagen es clicable y permite una entrada a la guía de SAFe que incluye: el núcleo de las 7 competencias de una empresa Lean, las 4 configuraciones que dan soporte a un amplio rango de entornos de desarrollo y negocio y los principios, valores, mentalidad, roles, artefactos y elementos que constituyen SAFe. 

Qué son las “The Three Ways” de DevOps.

Antecedentes

Uno de los conceptos fundamentales en Lean es el de “Value Stream”.  El “Value Stream” entendido cómo la secuencia de actividades requeridas para diseñar, producir, entregar un bien o dar servicio a un cliente; esto incluye los flujos de información y de materiales necesarios.

En Devops se define el “Value Stream”  de TI como el proceso requerido para convertir una hipótesis de negocio en un servicio proporcionado por la tecnología que entrega valor al cliente.

El tiempo de entrega es el tiempo que transcurre desde que el cliente hace una petición hasta que le es entregado el producto o servicio. El tiempo de proceso es el que transcurre desde que el trabajo se empieza a hacer hasta que se termina. Ver la siguiente figura:

El tiempo de entrega siempre es superior o igual al de proceso. Si se mejora cualquiera de estos tiempos la entrega de valor es más pronta y cuanto antes se entregue el valor más competitiva será la organización.

Particularizando en DevOps

En el caso de DevOps el “ Value Stream” de TI en muchas organizaciones está compuesto por múltiples actividades que llevan a cabo diversos profesionales con habilidades y conocimientos distintos. En “The DevOps HandBook” se muestra la siguiente figura:

 Aquí se representa el flujo de trabajo para poner en marcha un sistema en el entorno productivo, desde su concepción hasta su implantación. Al final de este flujo los clientes pueden utilizarlo y de esta forma recoger el valor que entrega el sistema.  La figura muestra un flujo de trabajo con muchas trasferencias, es decir en un paso el equipo correspondiente  hace un trabajo (por ejemplo:  desarrollar) a continuación se transfiere el trabajo al equipo que tiene que dar el siguiente paso (por ejemplo: Instalar el sistema en el entorno de pre-producción). Cada paso tiene sus propios tiempos de entrega y proceso. Mejorando estos tiempos entregaremos antes las aplicaciones, apps, webs, etc.

Además también hay que tener en cuenta el porcentaje de trabajo completado y asegurado. Este es el porcentaje de trabajo que en cada paso llega utilizable tal cual al siguiente paso, es decir se puede usar sin pedir más información o corregir la información suministrada.  Por ejemplo: para la instalación del sistema en preproducción, el equipo no tiene suficientes instrucciones para la creación de las tablas de la base de datos. Cuanto más elevado sea este porcentaje, habrá menos idas y venidas, no se re-trabajará y de nuevo se entregará el trabajo con más prontitud.

Las “Three ways”

En “The DevOps HandBook” los autores proponen una secuencia de mejora del “Value Stream” de DevOps. En la secuencia recomiendan abordar las mejoras en tres fases, que son las tres formas de mejorar. Estas son:

•  Primera forma: Mejorar el flujo.
•  Segunda forma: Hacer buen uso del feedback.
• Tercera forma: Establecer el aprendizaje y mejora continua.

Recomiendan abordar las mejoras de estas 3 formas y hacerlo una tras otra. Es decir, primero poner el foco en mejorar el flujo, luego agregar al objetivo usar el feedback y para terminar sistematizar la forma en que se aprende de los errores y los éxitos e incorporar ese aprendizaje a la  mejora.

Primera forma: Mejorar el flujo

Aquí se trata de conseguir que el flujo de actividades para llevar los sistemas al entorno productivo sea constante y sin sobresaltos. Para ello existen múltiples recomendaciones:

• Hacer el trabajo visible
• Reducir el tamaño de los paquetes de trabajo es decir entregar menos funcionalidades juntas, pero más a menudo.
• Automatizar los trabajos.
• Construir con calidad.
• Integración/entrega/despliegue continuos.
• Fácil creación de entornos.
• Prepararse para el cambio.

Segunda forma: Hacer buen uso del feedback

Se trata de establecer mecanismos para que en cada paso seamos capaces de hacer llegar información sobre el resultado de su trabajo a los pasos anteriores.  Cuando los equipos conocen el resultado de su trabajo corriente abajo, son capaces de aprender de sus éxitos y sus errores. Repitiendo lo que se hace bien y cambiando lo que hacen mal para intentar no repetir los errores.

Tercera forma: Establecer el aprendizaje y la mejora continua

Permitir un enfoque dinámico, disciplinado y científico hacía la experimentación y la aceptación de riesgos para aprender de los éxitos y los fracasos. Por ejemplo, estableciendo programas de uso de ataques a los propios sistemas como los recomendados por el Chaos Monkey. Esta es una iniciativa de Nexflix, donde periódicamente lanzan ataques contra sus propios servidores para observar las consecuencias y hacerse más resistentes a posibles problemas.

Bibliografía

The DevOps Handbook

 John Willis; Jez Humble; Gene Kim; Patrick Debois

 Publicado por IT Revolution Press, 2016