design-patterns - orientada - diferencia entre soa y microservicios

Diferencia entre la arquitectura de microservicios y SOA (7)

He estado leyendo en Microservice Architecture y estoy tratando de ver una diferencia entre él y SOA regular (aparte de los servicios que se implementan individualmente). ¿Alguien puede decirme la diferencia y tal vez los pro y los contras de Microservice Architecture?

Directamente de la publicación de Oracle , acerca de las diferencias entre SOA y microservicios, una breve descripción de la diferencia se puede resumir en palabras de Torsten Winterberg (Director de Oracle ACE):

Los microservicios son el tipo de SOA del que hemos estado hablando durante la última década. Los microservicios deben ser implementables independientemente, mientras que los servicios SOA a menudo se implementan en monolitos de despliegue. Classic SOA está más orientado a la plataforma, por lo que los microservicios ofrecen más opciones en todas las dimensiones.

Entonces, SOA es un patrón arquitectónico en el que los componentes de la aplicación brindan servicios a otros componentes. Sin embargo, en SOA, esos componentes pueden pertenecer a la misma aplicación . Por otro lado, en microservicios, estos componentes son conjuntos de servicios de implementación independiente .

Microservicios es la especialización arquitectónica de SOA, impulsada por las prácticas de DevOps. Los servicios desplegables individualmente hicieron más fácil aplicar Integración Continua / Despliegue Continuo

Francamente, después de haber pasado más de una década escribiendo arquitecturas orientadas a servicios, no veo la verdadera diferencia conceptual. El concepto (y la utilidad) de un servicio siempre ha sido, en mi opinión, atómico. Al escribir servicios atómicos, usted permite la "composición" de servicios macro más grandes, lo que le permite orquestarlos en algún tipo de procesos comerciales.

No hay nada en la receta original de SOA que haya impedido que uno escriba servicios en diferentes lenguajes de programación y permita su interacción a través de una interfaz contractual. Tampoco hay nada en la receta original de SOA que haya impedido que uno implemente sus servicios de manera independiente. La elección de implementar todos los servicios en un solo proceso Tomcat o dividirlos en procesos Tomcat / Nginx individuales y desplegarlos en diferentes nodos de su clúster es solo cuestión de semántica. Así que, fundamentalmente, personalmente no encuentro diferencia entre SOA y microservicios. Acuñar un nuevo término no lo convierte en una invención, francamente.

La diferencia entre SOA y Microservicios también depende de su visión de lo que es SOA. Para algunas personas, Microservices es lo mismo que SOA que ya están haciendo. Microservicios a menudo se ve como un subconjunto de los métodos utilizados por SOA.

Martin Fowler brinda una descripción útil sobre las diferencias aquí: https://www.youtube.com/watch?v=wgdBVIX9ifA

Microservicios, en resumen, se puede pensar en servicios web que se ejecutan de forma independiente en un servidor web.
Algunas de las características clave son las siguientes:

Ejecutar independientemente de los otros servicios web ayudando a desacoplar aplicaciones grandes.
Comuníquese con otros microservicios.

Entonces el microservicio es:

Un dominio de problema más pequeño.
Construido y desplegado por sí mismo, funcionando por sí mismo.
Se ejecuta en su propio proceso.
Se integra a través de interfaces conocidas.
Posee su propio almacenamiento de datos.

No hay diferencia. El tamaño o el enfoque de implementación utilizado no se especifica con SOA. Los microservicios son un tipo de patrón SOA cuando se toman ciertas decisiones arquitectónicas normales. Las decisiones incluyen la granularidad del servicio y el enfoque de despliegue / operación. La gente solía tomar estas decisiones en SOA antes de que Martin Fowler creara un nuevo nombre para lo que solía ser una arquitectura SOA normal. De hecho, Sun en 2000 definió los servicios como Autónomos en todos los aspectos, y gestionados de forma independiente. Entonces, los servicios de Micro no son nuevos, solo un nuevo término de marketing para crear nuevos ingresos de consultoría. Sí, los grandes proveedores de software con sus productos sobreinflados crearon el enfoque monolítico, que nunca fue representativo de los principios de SOA. Es como cambiar el nombre de un servicio por una API, todo se trata de marketing.

Supongo que se podría pensar en el estilo arquitectónico de microservicios como una especialización de SOA. No olvide que una de las opiniones aceptadas es que todo lo que SOA realmente es, son cuatro oraciones:

Los límites son explícitos
Los servicios son autónomos
Los servicios comparten esquema y contrato, no clase
La compatibilidad del servicio se basa en la política
^{-Don Box, Microsoft (pre.Net 3.0)}

Esto nos lleva a Fowler , de Lewis / Fowler:

En resumen, el estilo arquitectónico de microservicios es un enfoque para desarrollar una única aplicación como un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y comunicándose con mecanismos livianos, a menudo una API de recursos HTTP. Estos servicios se basan en las capacidades empresariales y se pueden implementar de forma independiente mediante una maquinaria de implementación completamente automatizada. Existe un mínimo de administración centralizada de estos servicios, que puede escribirse en diferentes lenguajes de programación y utilizar diferentes tecnologías de almacenamiento de datos.

A partir de esta definición, está claro que los microservicios cumplen al menos los dos primeros principios (con un énfasis real en el segundo), pero es cuestionable si cumplen el tercero (realmente no entiendo el principio 4, por lo que no comentaré).

La razón por la cual el tercer principio puede no ser válido para microservicios es que una de las características de los microservicios es que generalmente están expuestos a través de una API RESTful, que, podría argumentarse, no expone el contrato y el esquema (más allá del HTTP normal). verborrea), como vemos en Fowler:

un conjunto de pequeños servicios, cada ... comunicación con mecanismos livianos, a menudo una API de recursos HTTP

Otra forma en que un estilo de microservicios se desvía de SOA es con esta prescripción:

Estos servicios son ... implementables independientemente por maquinaria de despliegue totalmente automatizada

Seguir los principios originales de SOA no me impide copiar manualmente mis archivos binarios de servicios en mi entorno de producción, pero con el enfoque de microservicios, la implementación y la administración del servicio deben estar completamente automatizadas.

La diferencia principal entre SOA y microservicios radica en el tamaño y el alcance. Como sugiere la palabra "micro", tiene que ser significativamente más pequeño que lo que SOA tiende a ser. Microservicio es una unidad pequeña (independiente) que se puede instalar de forma independiente. Tenga cuidado con antipattern microservicio muy pequeño - nanoservicio. Un SOA puede ser un monolito o puede estar compuesto por múltiples microservicios. Martin Fowler dice que le gusta pensar que SOA es un superconjunto de microservicios.

Martin Fowler: https://youtu.be/2yko4TbC8cI?t=15m53s

Editar: Aquí hay otro video de Martin Fowler, hablando sobre la diferencia entre Microservicios y SOA. https://youtu.be/wgdBVIX9ifA?t=13m10s

El término microservicios pone mucho énfasis en el tamaño de los servicios, un punto que la mayoría de los profesionales considera bastante desafortunado. Stefan Tilkov argumenta que debe partir de la aplicación general y calcular cómo se puede dividir con sensatez. La charla de Sam Newman enfatiza que debe derivar sus microservicios basados en la noción DDD de Contexto acotado

Puede encontrar esto interesante: Resumen del libro "Building Microservices"