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

¿Qué lenguaje aprender para Data Science?

En la era de la transformación digital donde muchas compañías se plantean ser una compañía ‘data driven’ como centro de su propia transformación, muchas de las desarrolladoras se proponen transformar su propio perfil para surfear la increíble ola que está provocando Big Data, aunque más específicamente en este caso el Data Science (Machine Learning).

Mientras cientos de colegas se debaten sobre lo real o lo irreal de la ola (diagnóstico: rechazo al cambio), intentamos dar una visión con datos de las distintas alternativas para convertirte en un Data Scientist.

Si USA es un indicador avanzado en tecnología de miles de negocios (no todos),  es inevitable mirar qué está ocurriendo más allá de los mares. Para dibujar el camino lo haré desde una visión objetiva con datos, antes de aportar opiniones propias, que ya se sabe que cuando se habla de lenguajes de programación, sale el forofismo intrínseco del developer como si de un Madrid-Barça se tratara.

 

 

Es obvio que existe una creciente demanda en Machine Learning como antesala de lo que vendrá de Inteligencia artificial.

Algunos datos que nos aporten perspectiva :

  • C, C++, Java, Javascript se suben a la inercia de Machine Learning.
  • Julia recién llega a la batalla, veremos como se desarrolla en un futuro.
  • Scala muy minoritario hace tres años, toma su protagonismo porque Spark está desarrollado con Scala. Siendo Spark una de las tendencias más pujante.
  • R nace en 1993 en la Universidad Auckland dentro del departamento de estadística, toda una declaración de intenciones.
  • Python creado a finales de los 80 en un centro para las matemáticas e informática en los Países Bajos, una buena muestra de su ADN.

Una observación antes de continuar (la cuña publicitaria del matemático), si existe un rasgo característico del Machine Learning es la implementación de algoritmos matemáticos que tanto su uso como su interpretación requiere de conocimientos de estadística y probabilidad, aspecto que explica la pujanza en este ranking tanto de Python como R que nativamente fueron construidos para un fin cercano al que hoy ocupan dentro del ecosistema de Machine Learning.

Podríamos afirmar aquello de Nativo Data Science para R y Python.

Cada uno de los lenguajes están llevando a cabo planes para paliar sus respectivos talones de Aquiles, en unos su performance comparado, en otros la disponibilidad de recursos de valor dentro de la comunidad (algoritmos, gráficos, librerías, etc).

Algunos datos de contexto aportarán datos a la contienda, lo podemos ver en decisiones de alguno de los ‘Big Players’ del mundo IT, por ejemplo:

  • Microsoft dentro de su plataforma Machine Learning se integra con R y Python como lenguajes para desarrollar scripts o programas dentro de su modelo de ML Studio.
  • Oracle: pendiente.
  • IBM: pendiente.
  • Apache Fundation crea Spark como una de las iniciativas más pujante dentro del ecosistema Big Data open source, sobre todo en entornos que requieran un elevado performance y/o con clusters de múltiples nodos. Su concepto RDD de procesamiento distribuido, es inspiración a futuras apariciones por su flexibilidad y performance. Dentro Spark, podemos implementar ML con R, Python, Scala o Java. Pros y contras:
    • Java aporta madurez y una población de developers expertos amplio, aterrizado en España podríamos decir que es la mayor comunidad de desarrolladores.
    • Scala es lenguaje nativo con el que se crea y desarrolla Spark, por lo tanto es profundamente amigable, y su performance saca varios puestos al resto.
    • Tanto Python, como R aportan mucho más recursos a la comunidad que el resto de lenguajes, por razones ya explicadas.

¿Qué está pasando en España?

Ofertas publicadas en Infojobs y LinkedIn por lenguaje para los términos Data Sciences / Data Scientist / Machine Learning

  • Mayor comunidad de developers es Java.
  • Oferta mayor para R que para Python, tiene cierta lógica si vamos a ver que están enseñando nuestras Universidades o nuestras escuelas de negocio especializadas en Big Data/Data Science (pujante crecimiento, ¿Por qué será?).
    • R es lenguaje mayoritario para el perfil Data Scientist.
    • Seguido de Python.
  • Los perfiles expertos con C / C++ son perfiles en vías de extinción para otras aventuras y en esta se hace complejo que vayan a crecer, cuando se ha desterrado de los centros de conocimiento ambos lenguajes y la oferta formativa es minoritaria. Este párrafo lo escribí antes de ver el gráfico, y he de reconocer que sorpresa mayúscula el % de C, aunque no me aleja de mi comentario inicial, me ha hecho reflexionar, desempolvando estoy mi libro de Kernighan and Ritchie que tantas alegrías me dió.

¿Qué nos está ocurriendo a nosotros?

Mayoritariamente R 85% y Python 15%.

¿Algo más de luz?

  • R es elegido mayoritariamente por aquellos perfiles que tienen un background más orientado a la estadística y menos developers.
  • Python es elegido preferiblemente por aquellos que tienen un perfil más Developer y que puede entender los desafíos del performance de procesos de data mining o data science.
  • Java por aquellos que su background viene del propio lenguaje.
  • Scala por aquellos cuya apuesta en el ecosistema es Spark. Aquellos que busquen nuevas emociones con ejecuciones distribuidas y necesiten un alto performance en clusters con multiples nodos, se requiere un perfil Developer experto.

Autor: Javier García Paredes | Strategy Director/CEO Latam | Grupo Solutio

Fuentes:

Comparte