Microservicios (I)

Durante esta serie de post vamos a introducir un ejemplo para el uso de arquitecturas orientadas a microservicios.

La idea de estos posts es disponer de un quick reference guide al libro .NET Microservices: Architecture for Containerized .NET Applications, en el que hemos colaborado diversos arquitectos y que ha sido realizada por Microsoft Corporation.

Descargar libro

¿Qué es un servicio?

Es una pieza de software que provee funcionalidad a otras piezas de software. La comunicación entre estas piezas de software se realiza a través de una red de comunicaciones utilizando distintos protocolos.  Un servicio puede estar presente en varias ubicaciones (servidores) lo que permite que mediante un balanceador de carga poder utilizar varias instancias de ese servicio incrementando la capacidad de proceso y la reutilización de funcionalidad en aproximaciones del tipo SOA (Service Oriented Architecture) en las cuales los servicios exponen su funcionalidad mediante un contrato (Service Contract). Una de las principales características que debe presentar un servicio es que sea stateless, es decir que no sea necesario recordar la anterior petición de un cliente y que cualquier instancia del servicio pueda manejar una nueva petición de manera independiente.

Arquitectura orientada a Microservicios

Una arquitectura orienta a microservicios suele incorporar muchas de las ideas que se introdujeron en arquitecturas SOA, podríamos decir que es una evolución adaptada a las nuevas tecnologías, protocolos y clientes (mobile, JSON, …) que han surgido durante los últimos años.

Las principales características que presenta una arquitectura orientada a microservicios son:

  • En un plano de performance: La facilidad para crear aplicaciones que ofrezcan un High Performance. La posibilidad de realizar una escalabilidad eficiente de las aplicaciones
  • A nivel de diseño de aplicaciones. La posibilidad de creación de aplicaciones flexibles con un alto grado de reaprovechamiento funcional, la creación de aplicaciones basadas en servicios pequeños con un foco único.
  • A nivel de interoperabilidad: API agnóstica de la tecnología, independencia del almacenamiento de datos, capacidad de actualizar un servicio sin afectar al resto, despliegue independiente, transacciones distribuidas, herramientas centralizadas para el management de los servicios, …

Monolithic Applications vs Microservicios

Una de las características que presentan las arquitecturas de microservicios es la gran cantidad de ventajas que tienen sobre las clásicas arquitecturas de aplicaciones monolíticas.

Las típicas arquitecturas empresariales monolíticas suelen tener en común la no restricción al tamaño de la aplicación, una codebase grande, largos tiempos de desarrollo, stack tecnológico fijo, altos niveles de acoplamiento entre módulos y servicios pese al uso de patrones de desarrollo para minimizarlos, un fallo suele afectar al sistema completo, el escalado suele afectar al sistema completo.

Fuente de la imagen Martin Fowler

Una definición y una descripción completa de microservicios la podemos encontrar como siempre suele ocurrir recurriendo a Martin Fowler en el siguiente artículo: https://martinfowler.com/articles/microservices.html

Martin hace referencia a los nuevos paradigmas de desarrollo en los que las metodologías ágiles y la orientación a la construcción de productos no tanto ya de proyectos, requieren de elementos de desarrollo tales como los microservicios.

También en el caso de que hayamos trabajado con diseños orientados a dominio (DDD) podamos entender un microservicio o un conjunto de microservicios como la representación de un Bounded Context, en el que cada unidad funcional de microservicios disponen de sus propios datos y como ya hemos comentado pueden ser desplegados de manera independiente.

Fuente de la imagen Martin Fowler

Durante los artículos que publicaremos podremos ver la capacidad de los Microservicios y sus distintas formas de implementación y despliegue tanto en Azure como en Docker.

Autor: Javier Valero | COO Chief Operating Officer | Grupo Solutio

Referencias y agradecimientos:

Comparte

Definition Of Done

Una de las principales causas de tensión en los proyectos es la diferencia entre lo que un developer entiende por la finalización de una tarea, lo que entiende un jefe de proyecto o lo que entiende el propio cliente. Así es común que la diferencia entre lo que un developer entiende por finalizado al respecto de una funcionalidad diste mucho de lo que espera el cliente a la hora de enseñarle esa funcionalidad.
Este hecho está recogido y solventado por las metodologías ágiles, en lo que se denomina como Definition of Done (DoD). El DoD normalmente se aplica a dos conceptos fundamentales, la historia de usuario (User Story) y a la iteración o Sprint.
El DoD constituye la lista de elementos que deben cumplirse para que algo se pueda dar por Done (Hecho). El DoD es variable y dependerá de lo que usemos en el proyecto en cuestión, en cualquier caso deberá estar consensuado con todo el equipo y aprobado por el cliente (Product Owner).
El DoD además es vital para la estimación de tareas, ya que si por ejemplo el DoD incluye que se deben haber superado pruebas de integración, estamos diciendo que deben existir pruebas de integración y que además deben haberse superado, lo cual implicará el tiempo de su programación, mantenimiento y realización.

 


Unos ejemplos de DoD pueden ser los siguientes:

Definition Of Done. User Story

  • La historia de usuario ha sido revisada por el Product Owner.
  • La historia de usuario ha sido aprobada por el Product Owner.
  • Todo el código asociado a una User Story debe estar escrito y subido al Source Control incluyendo sus test asociados
  • Se deben haber seguido todas las convenciones de código establecidas por el equipo
  • Todos los test unitarios se deben haber pasado y deben haber sido correctos (Green) antes de hacer checkin.
  • Todo el código deber haber sido revisado por al menos dos personas bien en Pair Programming o en Peer Review.
  • La User Story ha debido ser incluida en las distintas Build que existan en el proyecto.
  • La User story debe haberse incluido en la Build Deploy o proceso de despliegue que exista, incluyendo los scripts que sean necesarios.
  • Test de aceptación:
    • Deben existir criterios de aceptación por cada historia de usuario
    • Debe haberse implementado todos los test de aceptación.
    • Deben haberse pasado y superado todos los test de aceptación.
  • El backlog del proyecto debe haberse actualizado:
    • El remaining time es 0 de todas las tareas asociadas a la user story.
    • El estado de la historia de usuario es Done.
    • Las horas empleadas en la realización de la historia de usuario han sido actualizadas.
    • Todas las tareas están en estado Done.
  • La documentación establecida a realizar en el proyecto ha sido actualizada con lo que haya supuesto la realización de la historia de usuario.

Definition Of Done. Sprint

  • Todas las User Stories cumplen el DoD para una User Story.
  • El incremento de producto ha supuesto una nueva versión de producto, generando los artefactos, ramas, etc que supone una nueva versión.
  • Todos los bugs que han sido detectados durante la iteración sobre el product backlog que se estaba desarrollando han sido corregidos.
  • Los test cubren un 80% de la cobertura del código.
  • Todos los test de integración se han pasado y se han superado correctamente.
  • El Sprint retrospective ha tenido lugar y se han tomado todas las acciones de mejora que se han identificado.
  • El Sprint review ha tenido lugary el Product Owner ha estado presente.
  • Todos los test de Performance se han completado y las acciones de mejora detectadas han sido incluidas como nuevos elementos del product backlog.

Autor: Javier Valero | COO Chief Operating Officer | Grupo Solutio

Comparte