Microservicios

[Carlos Admirador]

HOla grupo!!

Han trabajado real world con microservicios?

Desde mi gran ignorancia y torpreza al respecto, siendo muy simplista, veo que son servicios API REST (no WCF SOAP), cada uno con su base de datos y se comunican entre sí con un "Enterprise Service Bus" (ESB, NServiceBus, etc) ?

No aplica ni WCF SOAP, MSMQ, ...?


https://www.campusmvp.es/recursos/post/la-muerte-de-la-locura-de-los-microservicios-en-2018.aspx

La 'locura de los microservicios' viene a ser algo así:

Los de Netflix son buenísimos en devops. Netflix hace microservicios. Por lo tanto: si yo hago microservicios, seré buenísimo en devops.

qué son los microservicios, por qué el patrón es tan atractivo, y también cuáles son los desafíos fundamentales que conllevan.

¿Cuál es problema con los microservicios?

Comunicación
Versionado
Transacciones

...

 

Microsoft eBook gratuito en Español: “Microservicios .NET – Arquitectura para aplicaciones .NET contenerizadas” – Docker, .NET Core, Kubernetes, Service Fabric, Azure.

https://blogs.msdn.microsoft.com/cesardelatorre/2018/02/07/microsoft-ebook-gratuito-en-espanol-microservicios-net-arquitectura-para-aplicaciones-net-contenerizadas/

Alguna experiencia ?

REAL WORLD != HELLO WORLD

[Ariel Piñeiro]

No necesariamente tenés que usar un ESB.

Te dejo una buena guía como para arrancar.

Y si, estás en lo correcto, cada uno debería tener su propia Db. Te recomiendo pegarle una mirada al manifiesto de sistemas reactivos, muchos sites grandes (AMZ, Mercado Libre, Facebook, trabajan de esta forma.)

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/altnet-hispano.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Carlos Admirador]

Hay muchos conceptos con Microservicios, sistemas auto-contenidos (SCS), Sistemas Reactivos, ...

Falta aún más REAL WORLD

Algunas reflexiones que he recopilado:


Aquí un mini-book

https://dzone.com/articles/free-mini-book-about-reactive-microservices-1

Se lo podeis "cascar" a los amigos de Plataformas, Infraestructura, Arquitectura y Sistemas.. Seguro que alguno se pregunta cómo "migrar" o transitar de una plataforma monolitica acoplada que es tan típicas de la empresa cómun (tiene sus pros, pero muchas contras y dolor) a otra menos acoplada, flexible, escalable y distribuida (hay varias sol sobre la mesa que incluyen conceptos como Arqueitecturas Reactivas, Microservicios, Self-content Systems..) Dejad de usar  ... pero con cudadín 

https://theswissbay.ch/pdf/_to_sort/O%27Reilly/reactive-microservices-architecture-orm.pdf  Lo de antes pero en descarga directa

Mini-libro escrito por el CTO de Lightbend (2016) firmante del  Reactive Manifesto sobre arquitecturas: 

• Responsive
• Flexibles y Resilientes 
• Orientadas a Mensaje 
  

la vdd es q algun@ ya sabe de sobre esto pero ahí va:

Una de las claves diferenciadoras es que apuestan por arquitecturas Orientadas a Mensaje (Message-Driven) y no Orientadas a Evento (Event-Driven) es decir, es el mensaje el medio por el cual consiguen arquitecturasFlexibles (esto es, Escala o Reduce Escalado dinámicamente; se suele emplear una asignación automática de recursos) y Resilientes (Robustas, incluso Anti-fragile, no se deberían de caer así como así)  

Esta es tu arquitectura si necesitas un sitema que de respuesta y te permita el manejo temprano de errores (Responsive en ese sentido, no confundir con el Responsive de la Apps). Es decir si del teorema de CAP tu negocio aprecia la A y la P (sólo puedes elegir 2 según el teorema desarrollado por el ahora milmillonario Eric Brewer) esta es una posible solución arquitectónica que está de actualidad

Rompiendo Monolitos: Microservicios vs. Sistemas Autocontenidos

https://elastic.io/breaking-down-monolith-microservices-and-self-contained-systems/ ... y así te empiezas a cepillar el acoplamiento (lo cual facilitará tu agilidad enfocada en la Entrega Continua y eliminará dolores ante la Evolución del Sistema   -por cambio y/o extensión-), aunq  con SCS sin tener q llegar al "Gran Rediseño" o incluso sin caer en los  temible nano-servicios (demasiada granularidad)...  Como todo, si se va a hacer hay q aplicar trade-offs (balancear pros & cons). De todas formas un legacy no lo haces desaparecer x la güenas ni de blas (Michael Feathers)

pa Fowler hay que tener cuidadín y no transitar asín a lo "furro" Monolito->µServicios.. SCS puede ser 1 güena alternativa (aplicaciones web con IU autónoma, su lógica de negocio y su almacenamiento de datos) 

... podrías qdarte en SCS o incluso transitar SCS->µServicios o sencillamente pensar la Lógica de Negocio del SCS xa ser descompuesta en µServicios q resuelvan problemas concretos del Domino 

saludos

Cloud y microservicios. Y las "falacias de la computación distribuida

No soy ningún arquitecto sw  ni administro redes -me dedico a otras cosas que  me gusta pensar que tienen que ver con el (buen) desarrollo- pero es que es normal que puedan llegar a tener cierta relación. Esta arquitectura de microservicios habilita para tener un Continuos de todo. En el fondo el cloud permite lidiar con recursos que estén disponibles, y la gestión de la organización se centra en el desarrollo, eso no quita de que si se quiere se tenga cierto control de la infraestructura (IaaS) pero aún así se da un ahorro en costes considerable. La Admon Americana ya ha hecho cosas y se que la Española está en ello. Netflix p.ej es la empresa que trabaja conmicroservicios (tienen pura cultura DevOps) y tiene nube con Amazon.. que yo sepa se están forrando, creciendo y ahorrando en costes. La misma Amazon hace lo propio consigo misma. Más adaptativo y escalable sin gastarte una pastizal en recursos que eso no conozco

Pero ojo, que como todo en esta vida la computación distribuida tiene también sus puntos a vigilar. Gente de Sun Microsystem (Bill Joy, co-fundador, Gosling el creador Java, etc) las llamó las falacias del la computación distribuida (traducidos los voy a intentar comentar según me parece y relacionarlos con microservicios viendo como afronta esos problemas :-)

1. La red es siempre fiable. Obviamente el tráfico hay que vigilarlo más que nunca; hay una serie de patrones recogidos  (los 4 primeros son de lo mejor para eso en concreto) en el peazo libro Release it! para el que quiera saber como implementar y en lo que se baso Netflix
2. Tiempo de latencia cero. Pues claro que no, y se pueden producir perdidas de paquete a nivel de Transporte. Pero ya digo, minimícese empleando patrones de diseño como los del libro
3. Ancho de banda infinito. Cuellos de botella. Cuentan por ahí en un video que había unos robots que a base de transacciones se cepillaron el ancho de banda de un sistema. La solución fue aplicar el patrón Circuit Breakers (Disyuntor como cuando tienes corriente) Muy relacionado con el patrón Time Out y si bien no soluciona problemas, permite que el sistema no caiga, por lo que ta da tiempo a concentrarte en identificar y solucionar el problema.
4. La red es segura. Jaja, es un chiste, no existe una red 100% segura, como no existe un polvo 100% seguro 
5. La Topología no cambia. De hecho pueden desembocar en los problemas 2. y 3 Ahí losmicroservicios, no son lo peor, al contrario son arquitecturas evolutivas y políglotas (o sea menos rígidas que otras). Hombre no va a convertirse de pronto en  una arquitectura con topología que tenga un ESB típico (que no obligatorio) en SOA, pero quien cojones quiere Orquestación si se puede tener Coreografía. En SOA se decía que tenía las 2 modalidades pero mucho me temo que el WS-BPEL que suele usar como estándar de facto está muy orientado a la Orquestación. Lo sé porque lo usan también en BPMs. Mueeerte al director de orquesta que además de acoplar puede tirar el sistema como caiga 
6. Hay un administrador. Obviamente cuando una red crece suele haber subredes, y si lo hace mucho, más de un Admón. Pudiendo haber conflictos de intereses, Pero esto es un problema de política de empresa, es más de cultura empresarial, de la arquitectura per sé 
7. Coste de transporte cero. Ya estamos con el budget (presupuesto) y los costes ocultos. Pero joe pues como siempre sea cual sea la arquitectura, me remito al punto anterior. Y una observación, una arquitectura evolutiva donde en algún momento se pueden desactivar, reemplazar o eliminar servicios bajamente acoplados sin que afecte al resto del sistema es más barato que otra monolítica o débilmente acoplada (caso SOA)
8. La red es homogénea. Lo que desembocaría en los problemas 1, 2 y 3. Pues ese es el pto fuerte de microservicios, accede a interfaces independientemente de los lenguajes empleados y los recursos utilizados, incluso la persistencia es políglota, es decir, puedes tener una NoSQL, una RDBMS, una BD orientada a Objetos, un Almacén de Datos... 

Y a las 8  falacias clásicas añado 2 problemas

 9. El testing y la depuración es jodida. Si, claro, siempre ha habido problemas con las dependencias y ahora el sistema es distribuido, pero existen técnicas, como algunas que involucran usar Contenedores tipo Docker y además herramientas de gestión de la configuración para replicar entornos tipo Puppet, Chef, Ansible, etc

10. Trasladas la complejidad del desarrollo a la red. Pues claro, el desarrollo no debe de hacer lo que la infraestructura debe hacer. La complejidad requerirá monitorización pero no olvidemos que a ese nivel trata elementos comunes; la heterogeneidad está en la implementación (que es responsabilidad del desarrollador, desde que que nace hasta su mantenimiento). El tío de infraestructura está monitorizando que aquello fluya y sea resiliente, antifragil, con disponibilidad de servicio continuado... De hecho microservicios ayuda a aislar e identificar los problemas  

Agile->DevOps->C Deployment->Dark Launching->Decisiones de Negocio

Parece el ciclo completo de ing. moderna + negocio moderno. El Dark Launching me parece esencial para probar hipótesis y basar la toma de decisiones en datos del mercado. Este ciclo es lo "más científico" que se puede llevar un negocio (basado en hechos). Luego podemos usar técnicas específicas de Evidence-Based Management en la toma de decisiones y completar con otras fuentes para tener más perspectivas. 

A nivel técnico  para su implementación serán útiles sistemas distribuidos que permitan el Continuos Deployment (por tanto la Integración Continua) y en general que ayude a  todo el proceso incluso a un tipo de desarrollo ágil (p.ej arquitecturas de Microservicios) y para  hacer más fiable las hipótesis de negocio lo suyo es complentarlo con otras fuentes que suelen encontrarse distribuidas habiend para ello ya herramimientas de Big Data (como Hadoop, Spark) que prermite un posterior un análisis que sireva de fundamento para crear nuestras hipótesis (p.je empleando herramientas de Learning Machine que encuentre patrones y se le puedan añadir variables dependientes de modo que se crean "predcciones" plausibles para diferentes escenarios que por cierto se irán refinando más a medida que el sistema "aprenda". Y todo servido de manera inteligible más allá de los ESI, Balance Score Card y los Panelrd de Control del BI al uso)  

No hay balas de plata ni panaceas, pero esto es de lo más parecido ahora mismo a asegurarse un proceso cíclico semi-automático o al menos sistematizado con cierta adaptación a los cambios del mercado, del sector, de la demanda etc.siempre  atendiendo a hechos. Habrá quien diga con sano escepticismo que es una utopía claro, y la verdad que tiene razón si no es porque está equivocado, lo cierto es que las más avanzadas Facebook, Google, eBay, Amazon.. usan esto, es más en las industrias más manufactureras, pongamos Apple, tienden a esto prescindiendo de lo que no encaje.. pero la dirección y el sentido es este mismo, evolucionar el negocio mediante la adaptación (a no ser que tengas la fortuna de ser un monopolio)

Programación Reactiva: Streamming vs CRUD

No se trata de un dev que se rebota cuando le pides algo o del ataque q le da a un gerente que quiere alguna cosa echando leches 

Qué tal si  pensamos que no siempre necesitamos una BD (almacenando, extrayendo info,etc nada de CRUD) y que en realidad solo queremos directamente el Dataflow (digamos en tiempo más bien real e incluso asíncrono, como en la bolsa, los puestos de peaje automáticos, los chats, el tiempo meteorológico cambiante, los vuelos de llegada y partida, congestiones de tráfico o incluso detectar que hace un tío con el ratón en cada click) y más hoy en día con los smartphones, wearables, tablets, etc.. 

Eso es tratable con Reactive Programming que permite tener una arquitectura Escalable, Message-Driven, Resilente (tolerante) y es Responsive dando además una mayor velocidad de respuesta al usuario (cualquier PM medio sabe que la eficiencia no se obtiene de hacer tareas más rápidas sino de NO hacer aquellas que no se debían hacer desde un principio) Se trabaja a un nivel mayor de abstracción que en la OOP empleandose a modo de "Continuos Service" elementos Streams ya sea de forma síncrona o asíncrona y tratando volúmenes en vez de los ineficientes clásicos multi-threads (u objetos menos clásicos tipo Future en Python, Java etc) Además usarlo resuelve el callback hell (situaciones de callbacks anidados) de los Webservices y sus facilidades de escalabilidad casa muy bien con las arquitecturas de Microservicios muy apreciable pe. paraaplicaciones/servicios en Cloud y la respuesta ante eventos

Viene a ser el siguiente paso lógico más allá a la Programación Funcional (que x cierto es lo q se va a ir demandando xa aprovechar los procesadores multinúcleo de ahora y es limpísimo; no soy programador en absoluto -me dedico a otras cosas q creo necesarias no técnicas- pero a menos código menos errores) -En el video se pone además un ej. en Java8 concreto y algo de Elm de cómo se trabaja y hay tutoriales pj en Git (en gral hay proyectos no solo sw muy güenos xa echar un ojo e incluso participar a lo OpenSource) - . 

En fín, es todo un nuevo (y viejo) paradigma,se usa ya en sitios con Netflix y hasta tiene un manifesto 

Manifiesto

Firmado entre otros por el mismo Fowler, cada vez más metido en temas "arquitectónicos" http://www.reactivemanifesto.org/ Aunque no conozco bien, personalmente como lo explican nada que objetar, entiendo que viene de una sufrida experiencia y una reflexión profunda. El mismo Fowler no se muestra siempre 100% a favor de todo, p. ej le he leido comentar sobre los hoy populares Microservicios que a él le gustan pero como todo, tiene "sus cosas".. no parecen existir balas de plata ni panaceas para todos los escenarios.. bueno por eso somos necesarios en esto de IT cada uno a lo que se dedique

microservicios, posible si se tiene experiencia en continuos delivery

y creo que para hacer entrega continua debe de haber arquitectos de infraestructura sw ya trillados. Esto se va de la mano de un grupo de desarrolladores o de un o unos responsable de proyecto/producto. Es muy de política de empresa, es un tema con incidencia estratégica y ahí el CTO debe de venderlo al CIO y éste al CEO y al resto del órgano de gobierno de la organización (empresa, admon, pública, ONG, kiosquillo.. ;-)

Bueno, x enterarse y tener cierta cultura tecnológica no pasa nada http://martinfowler.com/articles/microservices.html (marco en negrita lo que dice M. Fowler)

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storagetechnologies.

[Carlos Admirador]

Istio, a Service Mesh

https://goo.gl/hgEu1q cada vez habrá más de éstos (Mallas, Meshes); está claro q hoy en día el problema no es tanto crear µservicios, sino conectar, monitorear y asegurar cientos/miles de estos µcroservicios. Esta Malla en concreto está hecha por Google y la participación de IBM, Pivotal, Cisco, Red Hat and VMware; realmente no creo que estén esos "monstruos" x tirar el dinero en algo que no funcione (bien implementado), pero bueno como hacen otras compañías millonarias, no sé p.e Verizon que ha migrado su monolito que les impedía escalar, crecer y ser ágiles (Entrega Continua) a la arquitectura propuesta x Lightbend, una plataforma con "microservicios reactive"  

Lo dicho, parece que este tipo de sistemas han venido para quedarse hasta que no haya nada mejor (estaría guay clro) si es que se quiere hoy evolucionar (igual no se necesita pero mira que escraro.. hasta las BPOs están en ello y doy fe ) Eso si, aunque cada vez hay más facilidades la cosa no es trivial yes necesariov"estudiarselo" bien un poquito (sobre todo aprebdiendo de los que + saben claro, como esa gente mencionada) que para eso además pagan a los arquitectos, etcetc.... Señores estamos en tecnología  y aqui (y cada vez más otras  profesiones) la cosa de actualizarse (o al meno de enterarse) se nota más (si en tu entorno "dejan" porque no se mueve ni media pues mira que bien...pero sinceramente, que mantengan good luck  )