/ Autor: Theriam

Actualidad

09/02/2021

/ , , ,

Programar una Skill de Alexa. Parte 1

Cuando hablamos de un altavoz inteligente o asistente de voz, estamos haciendo referencia a un altavoz conectado a Internet a un servicio de voz basado en nube que recibe comandos a través de una interfaz de voz y, por lo tanto, permite hacer uso de servicios en línea basados en audio y permiten controlar dispositivos conectados a través de Wifi o Bluetooth.

El servicio de voz de Amazon (Alexa) ofrece ya de serie varias funciones básicas tales como la reproducción de música, escuchar noticias, recibir informes de tráfico, predicciones meteorológicas, etc. Además, pueden instalarse otras funciones extra, las llamadas Skills o funcionalidades de Alexa, disponibles en la Alexa Skills Store, la cual actúa como un marketplace de aplicaciones o funcionalidades extras para los usuarios.

¿Qué es una Skill de Alexa?

Las Skills de Alexa son programas que pueden instalarse en todo dispositivo inteligente que haga uso del servicio de voz de Alexa y que sirven para ampliar la gama de funciones básicas que este servicio ofrece. Más a bajo nivel, la arquitectura de una Skill de Alexa sigue un modelo cliente-servidor, donde cualquier dispositivo que soporte el servicio lingüístico de Alexa, (ya sea un altavoz inteligente Amazon Echo o un horno debidamente equipado), actúa como el cliente o frontend de la Skill, y donde el backend se ejecuta en su propio servidor o en AWS Lambda, un servicio de procesamiento de datos desarrollado por Amazon basado en arquitectura serverless ofrecido por AWS (Amazon Web Services).

Puedes desarrollar tus propias Skills de Alexa haciendo uso del Alexa Skills Kit y el AWS Lambda.


Alexa Skills Kit: Requisitos para el desarrollo

Las Skills de Alexa se desarrollan utilizando el Alexa Skills Kit (ASK), disponible gratuitamente una vez hayas creado tu cuenta de desarrolladores de Amazon.

El Alexa Skills Kit (ASK) es una colección de APIs, herramientas, documentación y ejemplos de código que te permite crear tus Skills de Alexa.

Por otro lado, si no deseas encargarte de alojar tú mismo la lógica del programa de tu Skill de Alexa en tu propio servidor, necesitarás una cuenta AWS que te proporcione acceso al servicio en la nube de AWS Lambda.

Después de estos conceptos pasa a segunda parte del artículo para realizar los 6 pasos que nos permitirán tener disponible nuestra Skill:

  • Paso 1. Creación de la Skill en la consola de desarrollo de Amazon
  • Paso 2. Definiendo el modelo de interacción de tu Skill
  • Paso 3. Creación de la función Lambda de AWS
  • Paso 4. Conectar la función Lambda de AWS a la Skill
  • Paso 5. Probar la Skill
  • Paso 6. Validación y publicación de la Skill

Actualidad

10/12/2020

/ , , , ,

Mejorando TDD con la premisa de la prioridad de transformación

¿Qué es la Premisa de la Prioridad de Transformación?

La mayoría de los programadores que han utilizado la práctica de desarrollo de software TDD (Rojo/Verde/Refactorización) en su ciclo de trabajo, deben estar ya acostumbrados a introducir pequeños cambios en el código en cada una de sus fases, y principalmente deben conocer los cambios asociados a las refactorizaciones que realizamos durante la última fase de TDD.

La refactorización, tal como fue definida por Martin Fowler en su libro Refactoring: Improving the Design of Existing Code (1999), “es el proceso de cambiar un sistema de software, de forma tal que no se altere el comportamiento externo del mismo pero que se mejore su estructura interna. Con el objetivo de hacerlo más sencillo de entender y barato de mantener, permitiendo que el diseño del programa mejore luego de haber sido escrito”.

Al igual que con la fase de Refactorización, durante la fase Verde también se realizan alteraciones en el código, mediante las cuales intentamos hacer que el software supere la prueba que se encuentra fallando, empleando el menor cambio posible. A estas operaciones Robert C. Martin (tío Bob) las denominó transformaciones.

Podemos pensar en estas transformaciones como la contraparte de las refactorizaciones, debido a que consisten en pequeñas variaciones en el código que permiten modificar el comportamiento externo del software pero que conservan significativamente su estructura interna. Dicho en otras palabras, las transformaciones generalizan el comportamiento del sistema sin cambiar su estructura.

Pensando en estas transformaciones, el tío Bob definió la “Premisa de Prioridad de Transformación” (sus siglas TPP del inglés Transformation Priority Premise) la cual afirma que las transformaciones poseen un orden inherente fundamental, y que al ser aplicadas en correcto orden se conduce a mejores algoritmos y se evitan interrupciones del ciclo de TDD.

Él describe esta premisa en algunas de sus charlas mediante un ejemplo de desarrollo de un algoritmo de ordenamiento, y hace notar que al violar dicho orden se conduce a un algoritmo de ordenamiento de burbuja, mientras que empleando un orden preestablecido se alcanza un algoritmo de ordenamiento rápido, el cual es mucho más eficiente que el anterior.

Basándose en sus experiencias y evaluando publicaciones de otras personas, el tío Bob llegó a la siguiente lista ordenada de transformaciones:

01{}–>nullDe no tener código alguno a código que retorna Null
02null->constantDe código que retorna Null a devolver un valor literal simple
03constant->constant+De un valor literal simple a un valor literal complejo
04constant->scalarDe un valor literal a una variable
05statement->statementsAgregar más sentencias
06unconditional->ifDividir el flujo de ejecución mediante condicionales
07scalar->arrayDe una variable a una colección
08array->containerDe una colección a un contenedor
09statement->tail-recursionDe una sentencia a recursión de cola
10if->whileDe un condicional a un bucle while
11statement->non-tail-recursionDe una sentencia a una iteración
12expression->functionDe una expresión a una función
13variable->assignmentReemplazar el valor de una variable
14case/elseAñadir una bifurcación a un condicional existente
Tabla 1. Orden de Transformaciones según su Prioridad


Este listado sugiere un grado de complejidad incremental en nuestras transformaciones a medida que avanzamos en él, de forma que es más sencillo cambiar una constante a una variable que el añadir una sentencia condicional. Debido a esto, se sustenta la idea de dar prioridad en su uso a las transformaciones más simples por encima de aquellas más complejas.

Como una guía para nuestro uso durante el ciclo de TDD se puede representar dicho listado con el siguiente diagrama:

Figura 2. Diagrama de la Premisa de Prioridad de las Transformaciones


Para propiciar el uso de las transformaciones más simples, cuando diseñamos una prueba, primero debemos pensar en desarrollar aquellos casos de uso que nos permitan emplear transformaciones más simples en vez de las transformaciones más complejas. Debido a que a mayor complejidad de la prueba, mayor será el riesgo que tomemos para lograr hacer que nuestra prueba pase.

Encontrarnos en una situación donde no sabemos cómo hacer que una prueba pase, es un problema que muchos hemos observado mientras realizamos TDD. Algunas veces, la causa de este tipo de impasses recae en nuestro proceso de toma de decisiones durante el ciclo de desarrollo de TDD.

La transformación más simple suele ser la mejor opción que incurrirá en el menor riesgo para crear una situación de bloqueo. Debido a que mientras mayor sea el cambio en el código, más tiempo nos tomará antes de que nuestra prueba vuelva a pasar, por lo que se produce un riesgo mayor de romper el ciclo de TDD.

Por todo lo antes expuesto, el tío Bob plantea como premisa que si se eligen las pruebas e implementaciones que empleen transformaciones que están más arriba en la lista, se podrán evitar las situaciones de impasse o interrupciones prolongadas en el ciclo rojo / verde / refactorización.

Aplicando la TPP al Kata de los Números Primos

Aplicando la TPP al Kata de los Números Primos

Podemos practicar y dominar estos conceptos aplicando esta premisa de la prioridad de las transformaciones en un problema conocido como lo es la kata de los números primos.

El objetivo de esta kata es determinar el listado de factores primos un número. Un número primo sólo puede ser dividido exactamente por sí mismo y por 1.

A continuación, realizaremos la kata de los factores primos:

1. Añadimos un Test Fallido para 1 (Caso más simple)

Nos detenemos al fallar la compilación de la prueba

1.1 Transformando para Compilar

La forma más fácil de tener éxito (compilar ahora) es crear un método con valor de retorno nulo. Esta es la primera transformación o transformación nula ({} -> null).

1.1 Transformando para Pasar el Test

Esta prueba falla porque el método primeFactorsOf devuelve null, y no una lista vacía. Para que esta prueba sea exitosa, transformaremos el valor nulo en una lista vacía.

Nuestra segunda transformación es null -> constant.

¿Acaso null no es una constante? Null también es una constante, pero Null es una constante muy especial. Es una constante sin tipo definido y sin valor. Por lo tanto, es diferente de una constante que tiene un tipo y un valor.

La transformación realizada con null -> constant hace que el código sea más general. Null es un caso muy especial, inmutable, pero una lista vacía tiene el potencial de ser general. Ser general significa que puede manejar una variedad más amplia de casos.

2. Añadimos un Test Fallido para 2

Como segunda prueba, agregamos:

assertThat(primeFactorsOf(2), is(Arrays.asList(2)));

Con lo que esta nueva prueba fallará.

2.1 Transformación – Constante a Variable

Para que esta prueba sea exitosa, generalizamos la constante new ArrayList()

Para hacer esto, transformamos la constante en una variable llamada factors. La tercera transformación es constant -> variable.

Lo que hemos hecho es una refactorización (extracción de una variable), con la cual no hemos cambiado el comportamiento en un sentido estricto. Debido a que reemplazar una constante por una variable con su valor original no altera el comportamiento del sistema. Sin embargo, nos abre la posibilidad de poder cambiar ese comportamiento. En otras palabras, cambiar una constante por una variable no es una transformación independiente, pero es una parte necesaria del proceso de transformación.

2.2 Transformación – Flujo Dividido

Una transformación que modifica una constante en una variable permite que realicemos una cuarta transformación llamada división de flujo. En la transformación de flujo dividido, una sentencia if es empleada para dividir el flujo de control del programa. Esta transformación fue habilitada por la transformación anterior. La sentencia if hizo de nuestro código algo más específico. Por lo que nos toca ahora generalizarlo.

2.2 Refactorización – Generalizando

La condición if(number == 2) fue un caso muy específico (coincidiendo con la intención de la prueba). Debemos refactorizar para manejar casos más generales.

if(number > 1) es más general debido a que está abierto a posibilidades.

3. Añadimos un Test Fallido para 3

Al incluir la tercera prueba assertThat(primeFactorsOf(3), isListOf(3)); dicha prueba fallará.

3.1 Transformación – Constante a Variable

Para lograr hacer pasar la prueba con la transformación más simple, aplicamos la transformación constant -> variable en la cual modificaremos el 2 que añadimos a la lista de factores por la variable de entrada number.

4. Añadimos un Test Fallido para 4

Para la cuarta prueba incluimos la siguiente sentencia:

assertThat(primeFactorsOf(4), is(Arrays.asList(2,2)));

4.1 Transformación – Flujo Dividido

De forma que logremos pasar esta prueba, debemos volver a hacer una división en el flujo, dependiendo si la entrada number es divisible por 2.

4.2 Transformación – Flujo Dividido Nuevamente

Aún con este cambio, otra de nuestras pruebas continúa fallando. Esto se debe a que el caso de los factores primos de 4 es exitoso, pero el caso de los factores primos de 2 debe incluir a un solo valor y no dos. Por lo que tendremos que dividir el flujo nuevamente para evitarlo.

Y con esto podremos pasar todas las pruebas.

4.3 Refactorización

En el caso de number > 1, la división es realizada dos veces. No debemos preocuparnos de ello en este momento debido a que pronto desaparecerá. No generamos ningún inconveniente si movemos la parte del segundo condicional number > 1 fuera de la primera cláusula condicional.

4.4 Refactorización

Al igual que con el código productivo, el código que compone nuestras pruebas también debe ser mantenido. Por lo que podemos refactorizar para mejorar su legibilidad al eliminar duplicación en el código.

5. Añadimos más pruebas

En los casos de 5, 6 y 7, estas pruebas funcionan correctamente si son incluidas debido a que su comportamiento se encuentra incluido en nuestro algoritmo.

6. Añadimos prueba fallida para el 8

assertThat(primeFactorsOf(8), isListOf(2, 2, 2));

La cual falla.

6.1 Transformación – If a While

Podemos aplicar la transformación If -> while de forma que pasemos la nueva prueba.

El bucle while es simplemente una forma generalizada del condicional if, por lo que if es una forma especial de la estructura while.

6.2 Refactorización

Se mejora la legibilidad del código al refactorizar el bucle while a un bucle for como se muestra a continuación.

7. Añadimos un Test Fallido para 9

Añadimos la prueba assertThat(primeFactorsOf(9), isListOf(3, 3));

7.1 Hacemos pasar con Duplicación

Añadimos la condición de división por 3 como se muestra a continuación para hacer que nuestra prueba pase.

7.2 Transformación para remover la duplicidad – Bucle más general

Hemos introducido una duplicidad en nuestro código. Podemos incurrir en estas mientras estemos trabajando en un ciclo de TDD, pero las mismas no deben registrarse en el repositorio de origen como código repetido. Esta redundancia no es una transformación, debido a que nada ha sido generalizado. Simplemente es un experimento que nos permite imaginar como debe ser la solución general.

Nuestra tarea ahora es aplicar un ciclo más generalizado para eliminar la duplicación. El código duplicado siempre es inusual y específico.

7.3 Refactorización

Mejoramos nuevamente la legibilidad al refactorizar el bucle while por un bucle for y eliminamos el condicional restante, para obtener el resultado final compuesto por dos bucles for fáciles de entender.

Conclusión

Las siguientes transformaciones fueron observadas en este ejercicio de ejemplo:

  • {} -> null (1)
  • null -> constant (2)
  • constant -> variable (4)
  • split flow (6)
  • if -> while (10)

Pudimos ver mediante la kata de ejemplo una ilustración del proceso descrito por el tío Bob, y ver que al aplicar las transformaciones que propone TPP conseguimos garantizar:

  • Menor tiempo en rojo (evitar el impasse)
  • Descubrimiento de los puntos principales del problema
  • Desarrollo de una solución genérica y con menos duplicación

La Premisa de la Prioridad de Transformación (TPP) es una de las herramientas con las que contamos para garantizar el cumplimiento de las reglas del desarrollo guiado por tests. Este listado de transformaciones no implica reglas inalterables, sino una guía para evitar los bloqueos en el ciclo de TDD, especialmente al hacer el cambio de rojo a verde.

Si te interesa conocer más sobre TPP puedes buscar el siguiente material:

Actualidad

26/10/2020

/ , , , ,

Diferencias entre DDD, Event Sourcing y CQRS

Hace unas semanas mi compañero Gustavo Caro hacía un repaso de cómo han ido evolucionando las arquitecturas de aplicaciones y en este artículo voy a intentar resolver algunas dudas que surgen cuando nos enfrentamos a arquitecturas orientadas a eventos.

Las arquitecturas orientadas a eventos han crecido en popularidad en los últimos años, y aunque no son un concepto nuevo ya que existen referencias a la programación dirigida por eventos que se remontan a los 70s, sí que están ganando importancia debido a las últimas tendencias en ingeniería del software.

Empecemos por el principio, una arquitectura orientada a eventos (EDA del inglés Event-Driven Architecture) es un patrón distribuido de arquitectura donde diferentes actores se comunican mediante eventos en base a roles: productores y consumidores.

Utilizando este tipo de arquitecturas, las empresas implementan sistemas flexibles que se pueden adaptar a toma decisiones y cambios en tiempo real. Los eventos se capturan a medida que ocurren y permite que productores y consumidores de eventos compartan información sobre el estado y la respuesta en tiempo real.

Los componentes en este tipo de arquitectura están altamente desacoplados lo que facilita escalar horizontalmente. También hay que remarcar el hecho de que añadir nuevos consumidores es sencillo, ya que las integraciones no son punto a punto. En la parte negativa está el hecho de que, debido a la propia naturaleza desacoplada de la arquitectura, hay que ser cuidadoso con los componentes que formen parte y las dependencias entre ellos.

Existen múltiples conceptos alrededor de este tipo de arquitecturas que a simple vista pueden parecer similares, pero te das cuenta de que no lo son cuando indagas un poco más: eventos de dominio, Event Sourcing, CQRS…

En este artículo voy a intentar aclarar las diferencias entre esos conceptos. ¡Empecemos!

Eventos de dominio

En DDD (del inglés Domain-Driven Design), los eventos de dominio se usan para describir hechos de negocio que ocurren dentro del dominio. Estos eventos son relevantes dentro del bounded context pero también para otros bounded context, permitiendo integración entre diferentes dominios.

Una importante característica de estos eventos es que deben contener un alto valor semántico expresado en el lenguaje que hablen los expertos de dominio.

Si quieres profundizar en DDD te recomiendo el siguiente artículo.

Event Sourcing

Event Sourcing hace referencia a sistemas donde el estado de la aplicación completa es almacenado como una secuencia de eventos. Aquí, el termino evento se refiere al “cambio de estado”, no es solamente una “notificación”.

Las aplicaciones persisten los eventos en un Event Store, que es una base de datos de eventos. En lugar de almacenar el estado actual de la aplicación directamente campos de una tabla en la base de datos, los eventos son almacenados cronológicamente y pueden ser usados para reconstruir el estado actual en memoria si fuera necesario.

Como ya nos decía Martin Fowler en un post original del año 2005: “Event Sourcing ensures that all changes to application state are stored as a sequence of events”

CQRS

Command Query Responsability Segregation (CQRS) es un patrón por el cual se tienen estructuras de datos separadas para leer y escribir información. CQRS no tiene que ver estrictamente con eventos, ya que se puede implementar sin hacer uso de ellos, pero es bastante común que se combine CQRS con Event Sourcing.

CQRS Diagram by Martin Fowler

La justificación de usar CQRS es que, en dominios complejos, un modelo único de lectura y escritura puede resultar muy complicado y se puede simplificar separando los modelos. Este hecho puede resultar determinante si los patrones de accesos difieren de manera considerable, como por ejemplo muchas lecturas y muy pocas escrituras.

Conclusiones

Como hemos revisado en este artículo , las arquitecturas orientadas a eventos ofrecen numerosas ventajas, pero en contrapartida los patrones a seguir son algo más complejos que en otras arquitecturas y por tanto hay que pensar bien cuándo conviene hacer uso.

Una herramienta que nos puede ser de gran ayuda en este tipo de arquitecturas es un catálogo de eventos. A medida que la aplicación crece y el número de componentes es mayor, el flujo entre los componentes se hace más difícil de seguir, así como sus interacciones. En este punto es donde un catálogo de eventos cobra importancia.

En relación al tipo de eventos (domino / event sourcing), es importante tener una idea clara del propósito y semántica que cada uno lleva, y aunque no son exclusivos y en algún punto pueden tener la misma información, es una buena practica mantenerlos separados.

En general este tipo de arquitectura puede resultar muy útil y aunque quizás sea complicado implementarlo en un sistema completo, sí que su uso en partes específicas del sistema puede ofrecernos la flexibilidad y desacoplamiento que podemos necesitar.

Actualidad

04/08/2020

/ , , , ,

La evolución de las aplicaciones: camino a los microservicios

La evolución de las aplicaciones siempre ha estado estrechamente relacionada con la evolución tecnológica y las necesidades de los usuarios y las empresas.

Del mismo modo que las organizaciones empresariales evolucionan en la forma de hacer las cosas, las aplicaciones informáticas deben seguir el mismo camino para lograr su único objetivo, satisfacer dichas necesidades y servir al usuario de la forma más eficiente. Es como un ciclo que se retroalimenta constantemente:

Esta evolución ha obligado a un cambio en los sistemas, adaptando las infraestructuras que ofrecen la disponibilidad de dichos servicios y aplicaciones, de tal forma que los usuarios que los consumen lo puedan hacer de una forma más eficiente, segura y además en remoto, es decir, disponible en internet.

Un ejemplo sencillo para mostrar que adaptarse en esta evolución es obligatorio, sería una aplicación de mensajería que tiene un éxito inesperado. Es cierto que el aumento de demanda no es sino el principio del éxito, pero también puede ser el principio del fracaso si la infraestructura que soporta dicha aplicación de mensajería no está preparada para soportar tanta demanda. En este caso, la aplicación está condenada al fracaso.


Aplicación monolítica

La característica principal de estas aplicaciones es que hacen uso de una base de código única para sus servicios y funcionalidades. Es decir, la aplicación es «responsable» de todas las tareas necesarias para realizar una determinada función.

Este tipo de aplicaciones se destacan por combinar la interfaz del usuario y la capa de acceso a los datos en el mismo programa y alojarlos en la misma máquina (o nodo).

Una de las características para tener en cuenta es el llamado escalado vertical. Si el servidor que aloja la aplicación recibe un aumento en las peticiones de usuario, es posible que los recursos existentes en la máquina sean insuficientes. La única posibilidad es aumentar los recursos en dicha máquina (RAM, espacio en disco, etc.) dentro de sus límites.

Goza de una arquitectura sencilla, puesto que toda la aplicación se aloja en el mismo nodo, donde las comunicaciones entre las distintas partes de la aplicación siempre son de forma local.

Debido a su arquitectura, las interferencias entre los componentes de la aplicación son más delicadas, y un fallo en una de sus partes puede poner en evidencia toda la aplicación.

Otra desventaja, la tenemos en la complejidad de las actualizaciones, que pueden afectar a la disponibilidad de todo el sistema durante un período de tiempo durante su despliegue.

Por el simple hecho de tener una infraestructura estática y fija por años, el mantenimiento es más costoso y es más difícil evolucionar de forma eficiente a las nuevas necesidades del mercado.

En definitiva, aunque son fáciles de desarrollar, una aplicación que aglutina toda su funcionalidad no es la mejor opción si queremos aspiraciones crecimiento complejas, más usuarios, más desarrolladores, etc.


Aplicación distribuida

Su principal cometido es tener la aplicación disgregada en múltiples nodos, dando la posibilidad de que en cada nodo exista un componente de la aplicación o un mismo componente replicado en varios nodos.

Esta arquitectura es bastante más compleja y difícil de gestionar y administrar que una aplicación monolítica. De hecho, se deben utilizar numerosas herramientas que antes no eran en absoluto necesarias. Pero esta idea de tener la aplicación distribuida en varios nodos fue un punto de inflexión, que dio lugar a conceptos muy importantes y ha favorecido de forma incuestionable la existencia de aplicaciones mucho más robustas, escalables, eficientes y seguras.

Uno de los grandes conceptos que introduce este tipo de aplicaciones es el escalado horizontal. Es decir, cuando por cuestiones de demanda los recursos actuales ya no son suficientes, en vez de aumentar los recursos de un nodo (escalado vertical), lo que se hace es incrementar el número de nodos dedicados al procesamiento de ese componente demandado. Esto es una gran ventaja ya que el límite de recursos ya no será el soportado por un nodo, sino el soportado por tantos nodos como tengamos en nuestra arquitectura.

Otro gran concepto que surge, aunque todavía no de forma automática y madura, es la llamada elasticidad. Es decir, al igual que se aumentan el número de nodos dedicados para soportar un aumento de demanda, se pueden reducir si la demanda disminuye y dejarlos disponibles para otros procesos. Este concepto contribuye a un reparto de recursos más eficiente.

La seguridad y la robustez mejoran notablemente, ya que es más probable que los problemas de seguridad de un nodo sean cercados en ese nodo, no poniendo en riesgo toda la aplicación si alguno de ellos se pone en evidencia.

Otra gran ventaja con respecto a las aplicaciones monolíticas es que las actualizaciones no conllevan desplegar toda la aplicación ya que, en este caso el despliegue será a nivel de nodo. El mantenimiento es mucho más fácil y la durabilidad de la aplicación será mayor por la facilidad de adaptación a los cambios.

Todas estas características hacen que las aplicaciones distribuidas sean ideales cuando adecuar los recursos que se deben utilizar en función de la demanda sea clave.


Arquitectura SOA

Esta arquitectura fue la que insistió en la utilización de aplicaciones distribuidas y orientadas a servicios.

La idea fue hacer que esos servicios fueran independientes, y las interacciones entre ellos se hicieran bajo ciertos protocolos estandarizados de comunicación, como WSDL y SOAP.

Esta independencia hacía posible que servicios desarrollados por diferentes tecnologías, pudiesen comunicarse entre sí, sin ningún problema.

Debido a que los servicios son más independientes, cambios en ciertos componentes de la aplicación no alteraban al resto, simplemente debían seguir cumpliendo los criterios de comunicación establecidos.


Cloud Native (Cloud Computing)

La arquitectura SOA está más enfocada a la arquitectura de la aplicación. Cloud Native se enfoca más en la arquitectura del sistema que alberga, distribuye y ofrece las aplicaciones.

Este punto de vista, lo que ofrece es básicamente el uso de recursos en la nube bajo demanda automatizada. Es decir, va a existir una elasticidad gestionada de forma automática por el sistema en la infraestructura dedicada a cada una de las aplicaciones que distribuyen. Consiguiendo que el uso de los recursos sea lo más eficiente posible.

Estas infraestructuras dinámicas dedicadas hacen posible que las aplicaciones sean resilientes antes situaciones adversas, por ejemplo, por demanda extrema, errores hardware, etc.


Arquitectura de microservicios

No existe una definición formal pero básicamente es una evolución de SOA y está orientada al trabajo con servicios muy pequeños e independientes.

El objetivo es aislar los distintos componentes de una aplicación con el fin de que cada uno sea una aplicación por sí misma.

Otra de las diferencias con SOA es la comunicación entre los servicios; Ya no sería con servicios web WSDL o SOAP, sino vía HTTP con API-REST.

Muchos beneficios suelen asociarse a los Microservicios, pero tres de los más importantes son: una entrega más rápida, escalabilidad mejorada y una mayor autonomía.

Los microservicios son el facilitador de una mayor agilidad en términos de adaptación a los cambios del mercado. Su filosofía es compatible y está directamente relacionada con procesos ágiles de desarrollo: entrega continua. Es decir, el mantenimiento de la aplicación conlleva modificaciones en los microservicios, pudiendo llevar a cabo muchas subidas a producción en un corto período de tiempo de forma independiente (continuous delivery, deployment, improvement).

Esto aumenta la agilidad del software porque cada microservicio se convierte en una unidad independiente de desarrollo, implementación, operaciones, versiones, y escalamiento.

En realidad, aquí el término escalabilidad es algo ambiguo. Podría referirse, por ejemplo, a la escalabilidad del tiempo de ejecución del sistema, a su adaptabilidad (a un costo razonable), o a los cambios en el número de usuarios que acceden a él. O también podría referirse a poder aumentar el número de microservicios sin interferencias con los otros o a la capacidad del proceso de desarrollo para acomodar a muchos desarrolladores trabajando en paralelo.

Lo que está claro es que, con los microservicios la unidad a escalar es el servicio. Por tanto, cada uno de ellos son una unidad autónoma que pueden ser desarrollados, desplegados y operados por un equipo diferente. Por eso, suelen implementarse sobre contenedores: un microservicio en un nodo.

En estos casos, es de máxima importancia sincronizar una responsabilidad compartida entre el desarrollador y el sistema que lo alberga. Esta es la base de la filosofía DevOps.

La antigua filosofía introducida hace décadas por el principio «Divide y vencerás» ha sido puesta en práctica en innumerables ocasiones: en los algoritmos informáticos, en el envío de pequeños paquetes de datos en el protocolo IP, en la agrupación de las tareas en 7 capas en la arquitectura de red OSI, etc.

Es curioso como la misma filosofía se sigue adoptando en las infraestructuras tecnológicas actuales. Divide and win my friend 🙂



Nota. Los diagramas de las arquitecturas monolítica y de microservicios pertenecen al blog de Chris Richardson. Te animo a que lo visites para leer sus interesantes artículos.

Actualidad

08/07/2020

/ , , , , ,

Cuatro formas de automatizar con estilo usando PowerShell

PowerShell es la línea de comandos ubicua de Microsoft. Con los años, este lenguaje lanzado en 2006 se ha convertido en mi principal herramienta para moverme por el “Universo Microsoft”.

Todo lo puede, para todo sirve y siempre está a mano, como el destornillador del Doctor Who. Y aunque es cierto que en los últimos tiempos Microsoft ha abierto el abanico a otras líneas de comandos, como Azure CLI (AZ) para Azure o Bash para Azure y WSL, PowerShell aún sigue teniendo una posición muy sólida en el ecosistema, e incluso mejor desde el lanzamiento en 2016 de la versión multiplataforma (Mac OS, Linux): PowerShell Core.

Pero vayamos al grano. Puede que tu día a día sea una sucesión de scripts, probablemente rápidos, pero ¿qué pasa cuando son largos? ¿Qué haces si tienes que esperar a completar una o varias tareas que pueden llevar 10, 20 o 60 minutos?

Para estos casos, he depurado estrategias de notificación para ignorar el script hasta que algo relevante suceda. Esto es particularmente útil cuando tienes varios scripts pendientes, u otros proyectos, o una video llamada en curso. 😉

Las comparto en este artículo, sin un orden en particular, para que puedes aprovecharlas en tu día a día, por utilidad, o por mera diversión: 3 estrategias de notificación y 1 sorpresa.


8 bits

En PowerShell puedes implementar avisos sonoros como los de las videoconsolas de 8 bits de los años 80. Así identificas de oído si tu script ha llegado a alguna etapa importante.

Es como un Write-Host sónico. Además, la implementación es super sencilla:

[console]::beep(500,300)

El ejemplo muestra cómo reproducir un sonido de 500 hertzios y 300 milisegundos. Más hertzios, más agudo. Más milisegundos, más duración.

Fun Fact: ¿Sabías que 440 hertzios es la frecuencia que se emplea como sonido de referencia para afinar de instrumentos como el piano o el violín? ¡Puedes afinar tu guitarra o violín usando cualquier PC con Windows!

Por supuesto puedes jugar con las duraciones y frecuencias (aunque no del todo con el ritmo) para formar diferentes «códigos» o incluso melodías famosas. Por ejemplo:

Star Wars – Imperial March, de John Williams

[console]::beep(440,500)
[console]::beep(440,500)
[console]::beep(440,500)
[console]::beep(349,350)
[console]::beep(523,150)
[console]::beep(440,500)
[console]::beep(349,350)
[console]::beep(523,150)
[console]::beep(440,1000)
[console]::beep(659,500)
[console]::beep(659,500)
[console]::beep(659,500)
[console]::beep(698,350)
[console]::beep(523,150)
[console]::beep(415,500)
[console]::beep(349,350)
[console]::beep(523,150)
[console]::beep(440,1000)

Visto en: Music from the Command Line:Performed by Powershell

Los Vengadores – Assemble, de Alan Silvestri

[console]::beep(440,1800) [console]::beep(440,200) [console]::beep(440,600) [console]::beep(660,100) [console]::beep(580,1200) [console]::beep(520,800) [console]::beep(490,800) [console]::beep(440,1200)

[Nota: Melodía sacada de oído por mí]

Juegos de Guerra (1983)

Los veteranos del software como yo, recordareis la película «Juegos de Guerra» protagonizada por Matthew Broderick. En ella una IA llamada WOPR trataba de iniciar una guerra termonuclear por culpa de una red mal segmentada y un hacker. Hay muchas lecciones sobre ciberseguridad e IA en esa película.

Una de las cosas que recuerdo es la voz de la WOPR. Pero desde hace décadas, con el API de voz de Windows (si lo tienes configurado) puedes tener algo parecido en tus scripts usando estos comandos:

$text = "Extraño juego, la única manera de ganar es no jugar."
$object = New-Object -ComObject SAPI.SpVoice
$object.Speak($text) | Out-Null

[Referencia friki obligada: https://www.youtube.com/watch?v=FboBAFiLDbI]

Por supuesto puedes jugar con bastantes parámetros como la velocidad, otras voces e idiomas. Pero eso añade complejidad al script.

En resumen, puedes emitir información compleja y descriptiva de lo que va sucediendo durante la ejecución de tus scripts sin tener que prestarle atención. O leer archivos de texto de forma automática. O gastar bromas.

Este API tiene muchas posibilidades y PowerShell lo pone fácil. ¿Podrá integrarse con Alexa o Siri?


Alertas en Windows 10

En Windows 10 hay dos formas típicas de notificar algo al usuario: mediante un cuadro de diálogo y mediante el centro de notificaciones.

Para lanzar un molesto, pero efectivo cuadro de diálogo, no tenemos más que poner:

Add-Type -AssemblyName PresentationFramework #Ensamblado para la sesión.
[System.Windows.MessageBox]::Show('CPE1704TKS ?')

Esto nos permite explorar nuevas opciones de control de nuestros scripts, como por ejemplo recibir una notificación sobre si continuar una acción, o no, en lugar de solamente notificar algo.

Para ello tenemos una amplia gama de opciones de MessageBox como:

$msgBoxInput = [System.Windows.MessageBox]::Show('¿Una partidita de ajedrez?','WOPR','YesNoCancel','Error')
Write-host "Profesor Falken dijo:"$msgBoxInput

Pero también podemos emplear elementos de consola más avanzados como el Out-GridView con la opción -PassThru:

$myList = @("Tic, tac, toe","Chess","Global thermonuclear war")
$selection = $myList | Out-GridView -Title "Select a game" -PassThru
Write-host "Lets play:"$selection

Por último, en Windows tenemos algo más moderno y algo menos intrusivo como el centro de notificaciones, que funciona como el de un móvil y que no interrumpirá nuestro flujo de trabajo o reunión en curso. Aunque parece una buena opción, la generación de notificaciones es bastante más compleja y requiere de procesos adicionales para no acabar llenando de basura la barra de tareas.

Add-Type -AssemblyName System.Windows.Forms #Ensamblado para la sesión.

$global:balloon = New-Object System.Windows.Forms.NotifyIcon
$path = (Get-Process -id $pid).Path
$balloon.Icon = [System.Drawing.Icon]::ExtractAssociatedIcon($path)
$balloon.BalloonTipIcon = [System.Windows.Forms.ToolTipIcon]::Info
$balloon.BalloonTipTitle = "General Kenobi says..."
$balloon.BalloonTipText = 'Hello there!'
$balloon.Visible = $true
$balloon.ShowBalloonTip(5000)

Resumiendo, Windows y PowerShell nos ofrecen muchas opciones para gestionar notificaciones nativas, con relativa facilidad.


Epílogo: Like a boss

Como hemos podido comprobar, los scripts largos no tienen por qué ser aburridos, ni consumir tu atención y tu valioso tiempo. Basta con echarle algo de imaginación y emplear la vasta lista de posibilidades que ofrece PowerShell para facilitar nuestro trabajo.

Por mucho hype que haya con C#, JavaScript o Go, a menudo PowerShell puede ser la solución más rápida, compatible y con mejor TCO, para resolver problemas o automatizar procesos.

Y hasta aquí este artículo. Me despido con un meme en PowerShell: Never gonna give you up, de Rick Ashley.

Que por supuesto puedes incluir en tus scripts. Pero ojo con el volumen del audio al ejecutar esto:

iex (New-Object Net.WebClient).DownloadString("http://bit.ly/e0Mw9w")

Actualidad

01/07/2020

/ , , , , ,

API testing con REST Client para VS Code

En los proyectos ágiles, a la vez que se acortan los ciclos de desarrollo se vuelven todavía más importantes las pruebas de nuestro API (Application Programming Interface) y se convierte en obligatoria la ejecución de pruebas automáticas.

En API testing utilizamos herramientas de software para enviar llamadas a la API, obtener resultados y registrar la respuesta del sistema. Existen muchos artículos para conocer las principales recomendaciones para este tipo de testing así como diferentes herramientas, tanto libres como de pago: Postman, Insomnia, Ping ApI, HP QTP, vREST, JMeter…

Este tipo de herramientas son de gran utilidad para poder interactuar con APIs y, como desarrolladora front-end que soy, poder hacer pruebas de los servicios que se tienen que implementar.

Probablemente las más usada o conocida sea Postman, pero en este artículo me gustaría hablaros un poco de REST Client que nos permite realizar llamadas HTTP desde el propio editor Visual Studio Code (VS Code) de una forma muy sencilla.

Algunas de las características y ventajas que se pueden destacar de REST Client son:

  • Ejecutar solicitudes HTTP y ver la respuesta directamente en el panel
  • Tener todas las solicitudes en un mismo fichero
  • Soporta los tipos de autenticación más comunes
  • Definición de variables de entorno
  • Generar code snippets

Voy a ir explicando paso a paso como empezar a utilizar esta herramienta.


Instalación

La instalación es muy sencilla puesto podemos acceder a la extensión desde el mismo VS Code:


Fichero

Una vez instalado REST Client, crearemos un fichero cuya extensión debe ser .http o .rest para que nuestro código sea compatible con las solicitudes HTTP que vayamos a realizar.


Entornos y variables

Hay diferentes formas de definir variables. Aquí vamos a explicar dos de ellas:

1. Variables de entornos
Se pueden definir variables de entorno en el propio settings de VS Code. En la siguiente imagen se muestra un ejemplo de cómo se configuraría un entorno para local y otro para producción.

Una vez configurado el fichero de settings, tenemos que seleccionar el entorno con el que queremos trabajar. Para ello abrimos nuestro fichero .rest, pulsamos F1, elegimos la opción: Rest Client: Switch Environment y seleccionamos el entorno.

2. Variables en el mismo fichero
Se pueden definir variables en el mismo fichero con la siguiente sintaxis:

@nombreVariable = valor

En la siguiente imagen se muestra un ejemplo con algunas variables y una llamada a un servicio GET haciendo uso de ellas.


Peticiones

REST Client nos permite realizar peticiones GET, POST, PUT y DELETE de una forma muy sencilla.

En la siguiente imagen vemos algunos ejemplos de peticiones, variables y de como se muestra el resultado de una petición.

Empezamos definiendo algunas variables como el host o el puerto la base de nuestro proyecto para poder reutilizarlas en todo nuestro código.

Seguimos escribiendo nuestras peticiones separadas entre ellas con un comentario que debe empezar por tres o más almohadillas (###) . Esto es importante ya que, sin ello, no podremos realizar las siguientes peticiones.

Después de cada una de estas líneas, tendremos el encabezado de nuestra solicitud, el cual podremos llamar situándonos encima de la petición y pulsando sobre Send Request

El resultado se mostrará en un panel que se abrirá a la derecha automáticamente.


Autorización

Además, como ya apuntaba al principio, Rest Client soporta los tipos de autenticación más comunes como: Basic Auth, Digest Auth, SSL Client Certificates. etc.

Aquí te muestro un ejemplo de cómo se añadiría una cabecera de «Authorization»:


Code Snippet

Una vez tengamos nuestras peticiones, podemos generar estas peticiones en el lenguaje que queramos.

Para poder generar este código nos situamos sobre la petición y con el botón derecho del ratón nos aparecerá un menú. Seleccionamos: «Generate Code Snippet»

Una vez seleccionado nos muestra un listado con los diferentes lenguajes y seleccionamos uno de ellos:

En mi caso selecciono JavaScript y automáticamente se abre un panel a la derecha con el código generado.

Esto nos puede ahorrar tiempo y ayudar bastante a la hora de realizar las llamadas a estas peticiones desde nuestra aplicación.

Como podemos ver, REST Cient nos permite realizar peticiones de una forma muy sencilla. Una de las cosas que más me gusta es que podemos tener todas nuestras peticiones de nuestro proyecto en el mismo directorio y hacer pruebas sin necesidad de abrir otros programas.

Si te interesa profundizar más, te recomiendo que sigas leyendo en la página de REST Client en GitHub.

Actualidad

15/06/2020

/ , , , ,

Videoconsulta: un gran salto en la atención sanitaria

Hasta hace relativamente poco tiempo disponer de asistencia médica en todo momento y lugar a través de nuestro dispositivo móvil no era una quimera, pero quizás sí, mucho más un deseo del sector de la tecnología para ponerse al servicio del paciente.

El uso era bastante residual y siempre se prefería el contacto entre el médico y el paciente. Considerábamos imprescindible esa cercanía como cuando hace años teníamos que hacer una transferencia bancaria y acudíamos puntuales a la ventanilla de la sucursal del banco porque “nos fiábamos más”.

Los excepcionales momentos que hemos vivido en los últimos meses han obligado a minimizar esa relación presencial y han permitido a la videoconsulta acelerar su proceso de implantación e incrementar su uso de una forma vertiginosa.

Según datos de la Universidad de la Rioja (UNIR), más de 800.000 personas no acudieron en 2019 a su puesto de trabajo cada día en España por motivos médicos. En general un trabajador tarda de 1 a 3 horas en ser atendido por un médico o especialista y emplea, de media, 90 minutos en acudir a la consulta médica y regresar a su puesto de trabajo

El avance en prestaciones y nivel de utilización de los dispositivos móviles nos da la posibilidad de tener disponible en todo momento y lugar la información sanitaria de un individuo, o de los individuos de una unidad familiar:

  • La posibilidad de ser atendido por un especialista desde nuestro salón y que ese especialista tenga acceso a nuestra Historia Clínica Electrónica (HCE) disponiendo así de toda la información necesaria para la consulta es un avance a nivel de sociedad y optimización de recursos que permitirá dar pasos más ambiciosos para mejorar la relación entre médico y paciente.
  • Las acciones de los profesionales sanitarios que fomenten el uso de las nuevas tecnologías van a tener un respaldo mayoritario por parte de los pacientes, ya acostumbrados a disponer de servicios electrónicos avanzados en otros sectores de como banca o retail.
  • Existe una buena receptividad por ambas partes a nuevas formas de tratamiento, fundamentalmente por lo que suponen en la mejora de la calidad de vida, especialmente en casos de dolencias que limiten la movilidad o que implican una menor dependencia.
  • Los pacientes anhelan una mayor implantación de servicios como la teleasistencia y telerehabilitación, cuya utilidad es clara y supone una mejora de la gestión de la actividad sanitaria y de su propia situación médica.

Por su parte, un estudio de la Comisión Europea del año 2019 acerca de la oferta de servicios tecnológicos en España testifica que los servicios relacionados con la salud resultaron básicos para los ciudadanos. Por ejemplo destacan la información interactiva de servicios disponibles en hospitales o la gestión on-line de las citas médicas.

Volviendo al caso concreto de la videoconsulta, podríamos definirlo de forma sencilla como un servicio que permite una conexión medico-paciente a través de una plataforma virtual para ofrecer una consulta o un diagnostico médico.

Los beneficios de esta forma de prestar el servicio serían:

  • Disponer de la consulta médica en casa, sin tener que realizar desplazamientos al centro médico, con el consecuente ahorro de tiempo y dinero, disponiendo siempre de un especialista.
  • Relacionado con el tiempo y el dinero, reducirá las ausencias laborales, pues no será necesario acudir físicamente al especialista.
  • Reducción de las esperas en los centros médicos y consultas, puesto que habrá muchas consultas en las que no será necesario un estudio físico previo.
  • Evitar el posible contagio de enfermedades puesto que en una consulta presencial tenemos que pasar la espera en salas donde compartimos el espacio con otros pacientes que pudieran tener otras patologías.
  • Mejora en la calidad de vida ara muchos pacientes con problemas de movilidad reducida.

Pero no son solo beneficios para el paciente, sino que el profesional también podrá:

  • Conciliar la vida laboral y profesional, pudiendo atender a los pacientes desde su propio domicilio.
  • Evitar el contacto físico que podría implicarle contagios de cualquier enfermedad que tenga el paciente.
  • Disponer fácilmente del registro de la consulta y todos los datos clínicos relacionados, con acceso a los mismo en todo momento y lugar.
  • Optimización de costes.

Servicios digitales que ponen la tecnología al servicio del paciente y de los profesionales sanitarios para una mejor atención no presencial obteniendo claros beneficios para ambos

Podríamos concluir que los pacientes anhelan una mayor implantación de servicios avanzados, perciben su utilidad como evidente y asumen que pueden suponer una mejora importante en la gestión de la actividad sanitaria.

Estamos viviendo como se están cambiando los papeles y comienza a ser este paciente el que empieza a demandar más servicios basados en tecnología que faciliten su día a día y le ofrezcan más fiabilidad, flexibilidad y calidad en la asistencia médica.

Caso de éxito

Cabe destacar dentro de este ámbito la plataforma de videoconsulta de Sanitas – en la que colabora ITERIAM – y que es un proyecto referencia de este tipo de servicio en el que la compañía aseguradora lleva trabajando desde 2016.

Sanitas ha desarrollado una solución web multiplataforma propia que integra los principales portales donde trabajan los profesionales de la compañía y desde donde acceden para poder realizar las consultas digitales, bien sea a través de videoconsulta, chat o teléfono.

Por otra parte, los asegurados de Sanitas disponen de la plataforma MiSanitas – tanto el sitio web como de la app correspondiente – desde donde accederán a todos los servicios digitales, incluyendo la videoconsulta.

Disponer de una plataforma tan completa y madura desde hace tiempo, le ha permitido a Sanitas convertir de un día para otro un servicio “premium” en un servicio para todos sus asegurados, viendo cómo se multiplica por 5 el número de consultas diarias, llegando a las 5.000.

Actualidad

28/05/2020

/ , , , , , ,

Temas para reflexionar… con pensamiento positivo

En esta red profesional nos esforzamos por transmitir positividad pero no hay que obviar que podemos tener momentos complicados. No es malo compartir que nos toca luchar cada día por mantenernos ocupados para conseguir alejarnos de pensamientos negativos y superar la ansiedad producida por la situación actual. Asumir abiertamente que estamos obligados a redoblar esfuerzos y reinventarnos – en muchos casos a empezar desde cero – porque se han producido cambios que se quedarán con nosotros de forma definitiva afectando de lleno a paradigmas que teníamos establecidos y totalmente interiorizados.

Hace unas semanas veía una conversación de Rafael Nadal donde afirmada “No quiero nueva normalidad, quiero la normalidad de antes”.

Me sentí optimista ante la posibilidad de recuperar algo tan lejano en estos días como esa “normalidad de antes”. Y frente a ese anhelo, un entorno que nos habla de un futuro incierto y difícil en muchos ámbitos.

Tengo la fortuna de estar rodeado de un equipo increíble, en un proyecto profesional apasionante que consigue mantener mi motivación muy alta. Podemos decir orgullosos que estamos teniendo la agilidad y la pizca de suerte necesarias para afrontar estos meses con el mínimo impacto en nuestros proyectos.

En tiempos de cambio es cuando más se crece, cuando más se aprende

A pesar de ello, la incertidumbre que nos rodea nos exige más porque en tiempos de cambio es cuando más se crece, cuando más se aprende. Un aprendizaje forzado que afecta a una serie de temas sobre los que reflexionar y construir una nueva versión mejorada de nosotros mismos. Unos ejes que considerábamos diferenciales en el modelo de empresa de ITERIAM – tanto en nuestra cultura interna como de cara a nuestros clientes – pero que de forma general debemos replantearnos.

El primer eje y el más cercano desde mi posición de responsabilidad es el liderazgo: ¿cómo ejercer un liderazgo cercano en momentos de lejanía? ¿qué modelo de liderazgo necesitamos ahora? ¿cómo hacemos partícipes a nuestros equipos de la necesidad de cambios? ¿y cómo lo trasladamos a nuestros clientes?

Como comentaba con anterioridad, aquellas empresas que han demostrado agilidad para adaptarse han sido capaces de afrontar los retos de este nuevo escenario. En nuestro caso somos nativos digitales y tenemos definido un marco de trabajo que nos permite acompañar a nuestros clientes en sus proyectos de transformación digital de forma ágil, pero ¿somos ágiles también en todos nuestros procesos internos? ¿seríamos capaces de cambiar nuestro porfolio de productos y servicios de la noche a la mañana? ¿tienen nuestros ejecutivos mentalidad de startup? ¿y nuestros empleados?

Y hablando de empleados y talento, ¿seremos capaces de sostener en el tiempo esta necesidad autoimpuesta de completar nuestros conocimientos? Aunque ya teníamos una cultura de aprendizaje online y una amplia oferta formativa digital, soportada entre otras opciones en OpenWebinars, ¿seguiremos todos tan concienciados en la necesidad de estar siempre actualizados? ¿cómo tutelamos esa adquisición de nuevas capacidades en la dirección correcta? Y de nuevo, ¿cómo hacemos partícipe a todo el talento disponible en nuestros equipos ante esa necesidad de cambios?

Por último el teletrabajo como quinto eje. En ITERIAM ya teníamos implementada esta posibilidad en la mayoría de proyectos en los que participamos, pero su aplicación intensiva por la pandemia impacta en todos los ejes antes mencionados de forma evidente y nos obliga también a repensar el concepto de oficinas y puestos de trabajo.

Cinco temas sobre los que reflexionar para construir una versión mejorada de nosotros mismos

Temas sobre los que todas las empresas y organizaciones públicas, independientemente del sector de actividad, deberíamos estar actuando ya. Temas que nos mantienen ocupados, que muchas veces nos crean más dudas que certezas, sobre los que vamos sacando conclusiones parciales y que suponen un reto continuado que debemos afrontar con pensamiento positivo para encontrar de nuevo una forma diferente de hacer las cosas.

Actualidad

25/05/2020

/ , , , ,

Recomendaciones para desarrollo de código seguro

Actualmente, tanto los clientes como los desarrolladores de software estamos muy preocupados por la calidad del código, pero parece que se sigue pesando más el cumplimiento de las fechas de entrega y el ajuste en el presupuesto.

Tan evidente es que en el documento de cumplimiento del servicio (ANS) que se firma en muchas colaboraciones se recogen todo tipo de variables, KPIs y sus correspondientes penalizaciones en el caso de incumplimiento, pero pocas veces se miden o se cuantifican criterios de seguridad.

En el mundo Agile en el que se definen las historias de usuario, se establecen los sprints y se hacen las fases más difusas y menos largas, en ningún momento se tiene en consideración la securización de las aplicaciones de forma explícita. Se diseña, construye, prueba y se entrega, pero ¿y la seguridad?, ¿en qué fase entra? ¿se considera incluida en la parte de construcción? ¿no debería ser una parte de cada una de las fases?

El diseño de aplicaciones debería abordarse siempre bajo criterios de seguridad, siguiendo unos estándares de construcción seguros y finalmente se debería probar la seguridad de cada una de las funcionalidades desarrolladas en el sprint correspondiente.

En este punto debemos reflexionar si en nuestro caso tenemos en cuenta la seguridad: ¿existe un checklist al respecto que validamos antes de entregar y/o recepcionar los desarrollos o mientras que cumplan con las funcionalidades definidas y se entregue en los plazos establecidos entendemos que es un buen trabajo?

No se necesita ser un experto ni tener un equipo de hacking ético para definir una línea base y poder testar la seguridad de nuestros desarrollos. Mi recomendación para definir correctamente esos mínimos debemos tomar como referencia OWASP – Open Web Application Security Project.

OWASP es una fundación sin ánimo de lucro cuyos miembros trabajan a favor de la seguridad del software en general. Cada año analizan los 10 principales riesgos que se producen en las aplicaciones.

El informe de 2020 nos recomienda tener en cuenta los siguientes aspectos:

1. Inyección – Injection

Consiste en la ejecución de comandos o querys directamente desde la propia aplicación. Supongamos que tenemos el típico método de acceso a una aplicación con los campos usuario y contraseña ¿Qué ocurriría si la consulta a la base de datos no tuviese mecanismos de validación o estuviese mal construida y permitiese meter en el campo usuario el siguiente texto?

' or "=';

La consulta siempre saldría positiva y accederíamos a la base de datos.

2. Pérdida de autenticación – Broken Authentication

Englobaría a todo lo referido en el tratamiento y técnicas de protección de credenciales y cómo las implementan las aplicaciones. Es decir, la utilización de canales no cifrados para transmitir credenciales (https), no proteger debidamente las credenciales de usuarios, mala gestión en la recuperación de credenciales, exposición de los ID de sesión (Cookies de sesión).
Un ejemplo de esto podría ser

xxxx.es/url/control?action=profile&ID=vH]OzN8F8_==

en el que el ID va directamente en la URL.

3. Exposición de datos sensibles – Sensitive Data Exposure

Se produce cuando un usuario puede comprometer los datos debido a una mala u obsoleta encriptación de los mismos. Tiene puntos de conexión con el reglamento general de protección de datos (RDPD). Un ejemplo claro puede ser guardar en un archivo de configuración el usuario y contraseña en “texto plano”.

4. Entidades externas XML – XML External Entities (XXE)

Antiguos procesadores de XML permiten la especificación de una entidad externa, una URI sin referencia y evaluada durante el procesamiento del XML. Es decir, que al parseador de XML se le envía un XML con funcionalidades añadidas. Ejemplo de esto podría ser:

]>&entidad;

5. Pérdida de control de acceso – Broken Access Control

El control de acceso determina qué usuarios se comunican con qué sistemas y recursos. Esto implica que los usuarios no pueden actuar fuera de los permisos previstos.

Un ejemplo de esto es la configuración incorrecta de CORS que permite el acceso no autorizado a una API, o acceder a una API sin control de acceso mediante el uso de POST, PUT o DELETE.

6. Errores de configuración de seguridad – Security Misconfiguration

En este apartado se incluiría todo aquello que se relaciona con el despliegue de una aplicación y su entorno. Es decir, permisos, configuraciones por defecto, actualizaciones librerías, sistema operativo, servidores de aplicaciones, puertos, servicios, cuentas de usuarios, manejo de errores, etc.

7. Cross-Site Scripting – Cross-Site Scripting (XSS)

Este ítem considera la posibilidad de modificar valores que la aplicación web usa para pasar variables entre dos páginas.Los ataques XSS se basan en la inyección de scripts maliciosos que se ejecutan en el navegador del usuario. En muchos casos, el usuario ni siquiera es consciente de lo que está ocurriendo. Los tipos principales de ataques XSS son:

  • Reflected: Normalmente se basan en conseguir que el usuario siga un link o complete un formulario malicioso, aunque aparentemente normal. (ejemplo: Phising)
  • Stored: El código malicioso se inyecta en algún elemento persistente, como una base de datos, de manera que se consigue que se ejecute en el navegador del cliente al recuperar la información almacenada.

8. Deserialización insegura – Insecure Deserialization

Estos defectos ocurren cuando una aplicación recibe objetos serializados dañinos y estos pueden ser manipulados por el atacante para realizar ataques de repetición, inyecciones o modificar sus privilegios de ejecución. En el peor de los casos, la deserialización insegura puede conducir a la ejecución remota de código en el servidor.

Los datos serializados (que el atacante envía al servidor de consumo de servicios) hacen que se ejecute, al momento de deserializar, un código arbitrario (malicioso).

Código con los datos originales:

a:4:{i:0;i:23;i:1;s:5:"Admin";i:2;s:4:"user";i:3;s:32:"fkg498ok32ñ5p0fw48";}

Código modificado en el que se le conceden permisos de administración a un usuario externo, siguiendo la misma serialización que el original

a:4:{i:0;i:12;i:1;s:7:"ITERIAM";i:2;s:5:"admin";i:3;s:32:"ufr53psm56115ld357";}

9. Utilización de componentes con vulnerabilidades – Using Components with Known Vulnerabilities

Este tipo de ataque ocurre cuando se emplean librerías o frameworks que contienen vulnerabilidades. Un ejemplo de esta vulnerabilidad es la no actualización de los plugins de WordPress.

10. Recolección de logs y monitorización insuficiente – Insufficient Logging Monitoring

No es en sí una vulnerabilidad de las aplicaciones, pero si hace que la detección y las acciones de mitigación sean más dificultosas y lleven más tiempo.

Con estos 10 puntos, podemos definir nuestra línea base de actuación en temas de seguridad, y a partir de ella, hacer un checklist e incorporarlo como tarea en nuestro desarrollo Agile.

¿Qué valor añadido le daría a un cliente el saber que el desarrollo que ha contratado o realizado, además de cumplir funcionalmente con las especificaciones, cumple unos mínimos de seguridad?

Y a partir de aquí, ¿cómo seguimos? Con nuestra línea base definida, con nuestros mínimos de seguridad implementados, ahora toca ir evolucionando y madurando de forma incremental como en cualquier otro sistema de calidad que tengamos en nuestra empresa.