UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

“ANÁLISIS COMPARATIVO ENTRE EL

DESARROLLO BASADO EN MODELOS DE LA
ARQUITECTURA ORIENTADA A SERVICIOS Y
MICROSERVICIOS”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN II
.

POSTULANTE: Medina Rodriguez Yamil Alexis

TUTOR : Ing. Edson Ariel Terceros Torrico

Cochabamba – Bolivia
2019
 Tabla de contenido
DEDICATORIA ................................................................................................................................ 1
AGRADECIMIENTOS ..................................................................................................................... 1
RESUMEN ....................................................................................................................................... 2
INTRODUCCIÓN ............................................................................................................................. 2
1 GENERALIDADES ....................................................................................................................... 3
1.1. Antecedentes Generales ...................................................................................................... 3
1.2. Antecedentes Específicos .................................................................................................... 3
2 METODOLOGIA ........................................................................................................................... 4
3 ARQUITECTURA ORIENTADA A SERVICIOS Y ARQUITECTURA ORIENTADA A
MICROSERVICIOS. ........................................................................................................................ 4
3.1.- Definición de servicio........................................................................................................... 5
3.1.1.- Servicio web .................................................................................................................. 5
3.1.2.- Componentes................................................................................................................ 6
3.2.- Arquitectura orientada a servicios(SOA)............................................................................. 7
3.2.1- Lenguaje de descripción de servicios web(WSDL)..................................................... 10
3.2.2- Enterprise Service Bus(ESB) ...................................................................................... 11
3.3.- Arquitectura orientada a los Microservicios ...................................................................... 13
3.3.1- Componentes básicos en una arquitectura de microservicios. .................................. 15
3.3.2- Coreografia .................................................................................................................. 17
3.3.3.- Despliegue .................................................................................................................. 17
3.3.4.- Escalabilidad y desacoplamiento ............................................................................... 18
4 SOA vs MSOA ANALISIS COMPARATIVO .............................................................................. 19
4.1.- Introducción ....................................................................................................................... 19
4.2.- Análisis............................................................................................................................... 19
4.3.- Comparación ..................................................................................................................... 21
4.3.1.- Costo de infraestructura ............................................................................................. 21
4.3.2.- Granularidad del servicio ............................................................................................ 21
4.3.3.- Abstracción de la interfaz ........................................................................................... 22
4.3.4.- Protocolos ................................................................................................................... 22
4.3.5.- Interacción entre servicios .......................................................................................... 22
4.3.6.- Interacción fuera del servicio ...................................................................................... 22
4.3.7.- Alcance de la aplicación ............................................................................................. 23
4.3.8.- Integración .................................................................................................................. 23
4.3.9.- Rendimiento y tiempo de respuesta ........................................................................... 24
4.3.10.- Desafíos, esfuerzo y adopción de la cultura ............................................................ 24
4.3.11.- Escalabilidad y entrega continua .............................................................................. 24
4.3.12.- Orientación practica .................................................................................................. 25
 4.3.13.- Procesos ................................................................................................................... 25
4.4.- Ventajas y desventajas en la arquitectura orientada a los Microservicios ....................... 26
4.5- Ventajas y desventajas de la arquitectura orientada a servicios....................................... 27
5 IMPLICACIONES Y BUENAS PRACTICAS .............................................................................. 29
5.1.1- mayor cohesión en los modelos de negocio internos del servicio.............................. 29
5.1.2- Fragmentación más explícita del modelo .................................................................... 29
5.1.3- Modelos de comportamiento menos complejos en modelos de arquitectura ............ 30
5.1.4- Diferentes controladores para la complejidad del modelo de arquitectura ................ 30
5.1.5- Modelado de integración menos complejo pero restringido ....................................... 30
5.1.6- Modelado de la operación del servicio dependiente del equipo de desarrollo........... 30
5.1.7- Modelo de gobernanza dependiente del equipo. ........................................................ 31
5.2.- Mejores practicas .............................................................................................................. 31
5.3.- Entrega rápida y Lógica del negocio ................................................................................. 31
5.4.- Un modelo de servicio para la arquitectura de diferentes velocidades ............................ 32
6 CONCLUCIONES....................................................................................................................... 35
7 Bibliografía .................................................................................................................................. 37
 Tabla de Cuadros, Gráficos y Figuras

FIGURA 1: Tipos de aplicaciones según su arquitectura. .............................................................. 2

FIGURA 2: Ciclo de sobreexpectación Gartner. ............................................................................. 4
FIGURA 3: Interacción de un servicio web. .................................................................................... 6
FIGURA 4: Modelo de servicio. ....................................................................................................... 9
FIGURA 5: Modelo de conectividad punto a punto y SOA. ............................................................ 9
FIGURA 6: Arquitectura orientada a Microservicios. .................................................................... 14
FIGURA 7: Ejemplo de un modelo de servicio. ............................................................................ 33
TABLA 1: Elementos del Lenguaje de Descripción de Servicios Web. ....................................... 11
TABLA 2: Comparación entre componentes de la arquitectura SOA y MSOA. .......................... 20
TABLA 3: Diferencias entre la arquitectura SOA y MSOA. .......................................................... 20
TABLA 4: Tipos de servicio según su funcionalidad. ................................................................... 34
DEDICATORIA
A Dios por permitirme llegar hasta este
momento tan importante de mi vida y a
todas aquellas personas que me dieron el
aliento para poder concluir esta etapa
importante, mediante la retroalimentación y
los conocimientos.
AGRADECIMIENTOS
Gracias a Dios por haberme otorgado la vida,
salud, sabiduría y la fortaleza necesaria para
seguir adelante y culminar este proyecto.

A las personas más importantes de mi vida,

mis padres Freddy Medina y Juana
Rodriguez, que siempre me brindaron su
apoyo incondicional en mi formación como
ser humano, por haber confiado en mí, por
estar siempre a mi lado en las buenas y en
las malas, a mis hermanos Adrian, Nadir,
Escarleth y Mateo quienes supieron
alentarme en cada momento de mi vida., y un
agradecimiento grande a Andrea Dania
Carvajal Palma por todo el apoyo, cariño que
me dio durante todo este tiempo.
 RESUMEN

Dentro del proceso de desarrollo de software de un sistema, uno de los temas importantes a tratar
es la arquitectura de software, es la parte de la ingeniería de software que se dedica al estudio,
análisis y descripción para formalizar el esquema global de un sistema, poniendo énfasis en el
estudio de las interacciones entre sus elementos básicos, denominados componentes.

A mediados de la década de 2000, la arquitectura orientada a servicios (SOA) llamó la atención

de la industria. Numerosas empresas adoptaron este nuevo estilo de arquitectura como una forma
de aportar una mejor reutilización de la funcionalidad empresarial a la organización y permitir que
la organización de TI y la empresa se comuniquen y colaboren mejor entre sí. Docenas de
mejores prácticas para implementar SOA surgieron en ese momento. Desafortunadamente, las
empresas aprendieron de la manera más difícil que SOA era un estilo de arquitectura grande,
costoso y complicado que demoró mucho en diseñar e implementar, lo que dio como resultado
proyectos fallidos.

Hoy en día, la arquitectura de microservicios está revolucionando a la industria de tecnologías de

información como el estilo de referencia para desarrollar aplicaciones altamente escalables y
modulares. La arquitectura de microservicios tiene la promesa de poder abordar algunos de los
problemas asociados con SOA, así como los problemas encontrados con aplicaciones
monolíticas grandes e infladas.

En este documento analizaremos ambas arquitecturas, se realizará una comparación de los

microservicios y los patrones de arquitectura SOA, se mencionan los conceptos básicos de cada
una de estas arquitecturas y las diferencias fundamentales entre ellas en términos del estilo de
la arquitectura, las características de la arquitectura, las características del servicio y se intentará
aclarar las diferencias que rodean a las mencionadas arquitecturas.
 INTRODUCCIÓN

Las empresas de hoy en día se enfrentan a muchos desafíos en un entorno global orientado a
los servicios, centrado en la experiencia del cliente y orientado a la demanda de los clientes,
donde las tecnologías de información se están convirtiendo en el principal facilitador y socio de
las empresas modernas. Cada vez más las organizaciones dependen de su infraestructura de IT
para alcanzar sus objetivos, pero en un entorno competitivo como el actual, aprovechar las
oportunidades de negocio exige moverse con rapidez.
La estrategia de orientación a servicios permite a IT conseguir una mayor productividad de los
recursos de IT existentes, como pueden ser las aplicaciones y sistemas ya instalados e incluso
los más antiguos. La orientación a servicios permite además el desarrollo de una nueva
generación de aplicaciones compuestas que ofrecen capacidades avanzadas y multifuncionales
para las organizaciones con independencia de las plataformas y lenguajes de programación que
soportan los procesos.
La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es la
estructura subyacente que permite la comunicación entre varios servicios. La SOA define la
interacción y conexión entre dos entidades, que pudieran ser simplemente el transferir datos, o
coordinar una actividad específica entre servicios. En éste proceso, las interacciones están auto
contenidas y ligeramente acopladas, y son por tanto independientes entre sí. La arquitectura más
simple para un SOA muestra un proveedor de servicios en un lado, y a un consumidor de servicios
en el otro lado, intercambiando las solicitudes y respuesta de servicios.
Desde 2014, los Microservicios han ganado una amplia atención por parte de profesionales como
arquitectos de software y desarrolladores, seguido de un aumento significativo de las actividades
de investigación a partir de 2015. Netflix una empresa comercial de entretenimiento fue una de
las pioneras que implementó la arquitectura de Microservicios. estos han ido ganando presencia
y hoy en día, se aceptan en la industria como un estilo arquitectónico establecido.
En esencia los Microservicios permiten tratar con varias plataformas y dispositivos web, móviles,
Internet de objetos, dispositivos y dispositivos de mano, vemos varios gurús, con un gran interés
por mantener vivo un debate de integración. Esta desafortunada tendencia es evidente en las
líneas del discurso actual sobre SOA y los microservicios que discuten el "mejor" estilo, con la
ideología, la moda y el interés creado que parecen vencer a la razón. En la figura 1 se puede
observar una la aplicación según estructura.
En el presente documento se realizará una análisis comparativo entre el desarrollo basado en
Modelos de la arquitectura orientada a servicios y microservicios, de los conceptos clave en torno
a SOA y Microservicios, identificando similitudes y diferencias entre ellos, disipando así la
confusión alrededor de ellos, presentando un conjunto de recomendaciones y mejoras prácticas
para la arquitectura, el diseño y el desarrollo de interfaces de programas de aplicaciones desde
la perspectiva del resultado deseados, para la administración efectiva de los componentes de
software empresarial, aprovechando los mejores conceptos y prácticas de SOA y Microservicios.

1
MONOLITICA
SOA MICROSERVICIOS

Aplicación Aplicación semi Aplicación

monolitica distribuida distribuida

FIGURA 1: Tipos de aplicaciones según su arquitectura.

Fuente: Elaboración propia

2
 1 GENERALIDADES

1.1. Antecedentes Generales

La integración moderna se remonta al documento de (Birrell & Nelson, 1984), en la llamada a
procedimiento remoto. Desde entonces, ha habido muchas arquitecturas, productos, estilos como
ser: DCE (entorno de computación distribuida), CORBA (Common Object Broker Architecture),
cliente / servidor de dos niveles, cliente / servidor de tres niveles, cliente / servidor de N niveles,
COM, DCOM, mensajería y middleware orientado a mensajes y arquitectura orientada a servicios.
El progreso ha sido lineal en un sentido, la integración se ha vuelto cada vez más fácil con el paso
del tiempo, lo que fue terriblemente difícil con las primeras implementaciones, ahora es
relativamente simple, con plataformas implícitas que presentan interfaces simples, mecanismos
como XML, JSON, que proporcionan formas simples de describir la interfaz, y los usos de HTTP
que presentan protocolos de transporte simples.
Sin embargo, la evolución de los estilos y la práctica de integración ha sido cíclica, con muchos
conceptos que han caído en desuso, pero reaparecen con el paso del tiempo bajo diferentes
formas. Por ejemplo, el concepto actual de "puntos finales inteligentes y tontos" son elementos
de las prácticas de CORBA y COM.
1.2. Antecedentes Específicos
SOA es una arquitectura que lleva tiempo en el mercado a partir de 2002-2010 aproximadamente
fue la que estuvo liderando el desarrollo e integración de aplicaciones empresariales. SOA es un
estilo arquitectónico que utiliza el componente empresarial como servicio y permite que otros
componentes de la aplicación accedan y utilicen. Está acoplado de forma flexible y su arquitectura
distribuida significa que se puede acceder al componente del servicio a través de algún tipo de
protocolo de acceso remoto.
La arquitectura de Microservicios que es la tendencia tecnológica en el apartado de arquitecturas
distribuidas, siendo actualmente usado con frecuencia, por ser una arquitectura de software para
desarrollar una colección de servicios que son pequeños y están interconectados entre sí.
Ganando por tanto popularidad en el mundo del software porque abordó muchos de los
problemas que se encuentran en el protocolo de arquitectura SOA.
Por tanto, es importante considerar el ciclo de sobreexpectación de Gartner (Gartner, Hype Cycle
for Application Architecture, 2010) que muestra que los Microservicios se encuentran actualmente
en la cima del ciclo de exageración, exactamente en el "Pico de expectativas
sobredimensionadas". La tendencia tecnológica intentará utilizar a los Microservicios como una
solución óptima de las tecnologías de información. Luego, la realidad se activará, lo que lleva al
"abismo de la desilusión", puesto que la madurez en torno al concepto crecerá y gradualmente
se mostrará lo que la tecnología puede y no puede lograr. Por ejemplo, la transición del estilo de
integración SOA, a través del ciclo de exageración a partir de 2002-2010 nos muestra que SOA
nunca alcanzó su potencial dentro de muchas organizaciones. los presupuestos para una
completa implementación eran inviables cuando los requerimientos no tenían una gran duración,
entonces las compañías tuvieron que conformarse con las implementaciones básicas. Las
limitaciones de integración costosas y riesgosas se volvieron aceptables en un clima de miedos
mayores y el concepto se dio por descartado.

3
 FIGURA 2: Ciclo de sobreexpectación Gartner.
Fuente: (Gartner, 2002).

2 METODOLOGIA

A continuación, se mencionan los métodos de investigación que serán utilizados en el presente

trabajo:
 Método Bibliográfico, debido a que se realizara la lectura y compilación de libros o páginas
web relacionados al tema de estudio.
 Método Analítico, debido a que se procederá a revisar y analizar ordenadamente
documentos relacionados al tema de estudio.

3 ARQUITECTURA ORIENTADA A SERVICIOS Y ARQUITECTURA ORIENTADA A

MICROSERVICIOS.

SOA intenta integrar las diferentes aplicaciones de una empresa, favoreciendo la interacción entre
estas. La interacción entre las aplicaciones se da a través de un canal en común, en este caso el
Enterprise Service Bus (ESB), que se encarga de recibir y enviar las diferentes peticiones de
servicios, transformándolos o guardando un registro de ejecución dependiendo lo requerido. SOA
utiliza el protocolo WSDL que está basado en XML para definir todos los detalles de la estructura
de los mensajes en la comunicación cliente servidor.
La arquitectura orientada a los microservicios (MSOA), está basada en servicios que son
pequeñas aplicaciones con su propia tecnología y plataforma, estas se comunican a través de
mecanismos, cada microservicio se basa en las necesidades del negocio. la necesidad de utilizar
microservicios es debido a que estas nos proporcionan una buena escalabilidad y bajo
acoplamiento, existen diferentes tipos de implementación de acuerdo a las tecnologías que se
estén utilizando. MSOA está conformada por los componentes: Servicio de enrutamiento,

4
balanceador de carga, circuit breaker y logs centralizados, para la integración de los servicios
MSOA se basa en un estilo coreográfico.
3.1.- Definición de servicio
Según la página (Microsoft, 2019) Un servicio es una vía de intercomunicación entre uno o varios
sistemas, esta interacción de máquina a máquina se realiza a través de una red, un servicio
contiene una función de negocio auto contenida con una interfaz definida y estable, recibiendo
solicitudes y entregando respuestas a los clientes.
El proceso de un servicio se inicia cuando el cliente solicita información, enviando a veces datos
al servidor para que pueda procesar su solicitud, el servidor genera una respuesta que envía de
vuelta al cliente, adjuntando otra serie de datos que forman parte de esa respuesta. Por tanto, un
servicio se puede definir como el tráfico de mensajes entre dos máquinas. Los servicios son
desplegados una única vez y permanecen disponibles, sin consumir recursos, hasta que son
invocados.
3.1.1.- Servicio web
Un servicio web es una tecnología que utiliza un conjunto de protocolos y estándares para el
intercambio de datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en
lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar
los servicios web para intercambiar datos en redes de ordenadores como Internet. La
interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones
OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios
Web (IBM, 2019).
Los servicios web permiten que aplicaciones web interactúen dinámicamente con otras
aplicaciones web, utilizando estándares abiertos como XML, UDDI y SOAP. Esto es posible
porque están basados en un protocolo simple y liviano para realizar las invocaciones, como
SOAP, un protocolo estándar creado por W3C, basado en XML (Gonzalez, 2009).
Los servicios web son mucho más que simplemente SOAP, éste último sólo define el protocolo
de invocación remota a los métodos, incorporan WSDL como un lenguaje basado en XML como
sistema de mensajes se utiliza XML estandarizado. El protocolo más simple para el intercambio
de información entre ordenadores es XML-RPC, que emplea XML para llevar a cabo RPCs. RPC,
Remote Procedure Call, es un protocolo de red que permite a un programa a ejecutar código en
una máquina remota. Los XML-RPC requests son una combinación entre contenido XML y
headers HTTP. La simpleza de los XML-RPC hizo que el estándar evolucionar a SOAP, uno de
los componentes básicos de los servicios Web que permite describir los contratos de cada
servicio. Este lenguaje fue desarrollado conjuntamente por Microsoft e IBM y sometido para su
aprobación como un estándar (Gonzalez, 2009).

5
 FIGURA 3: Interacción de un servicio web.
Fuente: (Wikipedia, 2019).

3.1.2.- Componentes
Los componentes de un servicio web definen el objetivo del servicio web y cómo se comunica el
cliente de servicio web con el servicio web.
Un servicio web posee los siguientes componentes:

 XML (Extensible Markup Language),

El cual es un lenguaje de marcas extensible que permite una mejor adaptación y
flexibilidad entre sistemas heterogéneos; su característica principal es la adopción
de etiquetas en un archivo de texto que permite la interpretación por sistemas en
diferentes plataformas, su principal debilidad es el tamaño que puede alcanzar
cualquier archivo creado con este estándar. (Gonzalez, 2009). Los servicios web
incluyen un protocolo que define el formato de un documento XML con la
información de descubrimiento y un protocolo para que un usuario pueda recibir
este documento, permitiendo descubrir servicios de una URL conocida.
 SOAP (Simple Object Access Protocol)
Es un protocolo escrito en XML (Extensible Markup Language, traducido como
“Lenguaje de Marcado Extensible”) para el intercambio de información entre
aplicaciones. SOAP está compuesto por cuatro componentes fundamentales: un
envoltorio que define un framework para describir los mensajes y cómo estos serán
procesados, un conjunto de reglas para codificar o serializar instancias de tipos de
datos definidos por las aplicaciones, una convención de cómo representar
invocaciones remotas y sus respuestas y una convención para vincular el
intercambio de mensajes con el protocolo de transporte.
 WSDL (Web Services Description Language)
Es un estándar XML utilizado para describir servicios web y como acceder a ellos,
gracias a los archivos descritos en este lenguaje se pueden descubrir los servicios
web y utilizarlos de acuerdo a sus características, es un contrato entre el proveedor
del servicio y el cliente mediante el cual el proveedor del servicio indica:

6
 • Qué funciones se pueden invocar

• Qué tipos de datos utilizan esas funciones

• Qué protocolo de transporte se utilizará para el envío y recepción de los mensajes

• Cómo acceder a los servicios

• Mediante que URL se utilizan los servicios.

 UDDI (Universal Description, Discovery and Integration)
Es un estándar XML para describir, publicar y encontrar servicios web. Es un
directorio de interfaces de servicios web descritos en WSDL que se comunican
mediante SOAP. A la hora de publicar los servicios web, existen muchas
posibilidades, la más común y más discutida es la de utilizar UDDI que no es más
que una especie de directorio en donde podemos encontrar un servicio web de
acuerdo a ciertas características funcionales; una gran debilidad a la hora de
descubrir un servicio web es localizarlo solamente por sus características
funcionales sin considerar las no funcionales como los tiempos estimados de
procesamiento, entre otros (J, 2009).

3.2.- Arquitectura orientada a servicios(SOA)

Antes de definir el SOA, es importante aclarar una arquitectura de software puede definirse como
la estructura de estructuras del sistema, que comprende elementos de software, las propiedades
externamente visibles de esos elementos y las relaciones entre estos. En este sentido es que la
arquitectura SOA supone una estrategia general de organización de los elementos de las
tecnologías de información, de forma que los sistemas distribuidos y aplicaciones complejas se
puedan relacionar a través de una red de recursos integrados, simplificada y sumamente flexible.
(Microsoft, 2019)
SOA Service Oriented Architecture (SOA) es una arquitectura un poco antigua, haciendo sentir
su presencia a principios de la década de 2000 y alcanzando un nivel de madurez a fines de la
primera década del milenio.
El enfoque y los productos de SOA surgieron a través de la necesidad de crear una arquitectura
distribuida basada en componentes que promueva la agilidad empresarial, es decir, poder
configurar rápidamente una solución para satisfacer una necesidad comercial particular y
proporcionar cambios a la solución a medida que las necesidades empresariales evolucionan
rápidamente. Las definiciones sobre SOA son muchas y muy diversas, algunas de las primeras
son:

 SOA, según (IBM, 2019): un marco de aplicación que toma las aplicaciones comerciales
diarias y las divide en funciones y procesos empresariales individuales, denominados
servicios.

 SOA, según (wikipedia, 2019): un patrón arquitectónico en el diseño de software de

computadora en el que los componentes de la aplicación prestan servicios a otros
7
 componentes a través de un protocolo de comunicaciones, generalmente a través de una
red. Los principios de orientación al servicio son independientes de cualquier proveedor,
producto o tecnología.

 SOA, según (Krafzig, 2005): es un estilo de Arquitectura de Software basado en la

definición de servicios reutilizables con interfaces públicas bien definidas, donde
proveedores y consumidores de servicios interactúan desacopladamente para realizar los
procesos del negocio, y donde los servicios se componen en secuencias definidas para
realizar los procesos de negocio (orquestación). SOA realiza la utilización de tecnologías
basadas en estándares que facilitan y permiten automatizar la publicación e integración
de aplicaciones y servicios, además SOA permite la creación de sistemas de información
altamente escalables.
La arquitectura orientada a servicios (SOA) es un estilo arquitectónico que aprovecha los servicios
en un sistema de software distribuido como un componente funcional, las características
esenciales de SOA fueron la creación de componentes (en servicios), el acoplamiento flexible, el
alto rendimiento y la gestión del ciclo de vida del servicio, es decir, la gestión de los servicios, la
custodia central, la promoción de la reutilización y la gestión de los eventos del ciclo de vida hasta
su posterior desaprobación y retiro. pero ninguno fue más importante que el diseño de estos
servicios: el mantra repetido fue que se trataba de servicios empresariales, y un requisito previo
clave para el éxito de SOA era su arquitectura y diseño adecuados. Cuando la aplicación
empresarial crecía, la nueva característica se integrará en el sistema en ejecución. Debido a la
funcionalidad estrechamente acoplada, en su mayoría las arquitecturas SOA sufren de entrega
tardía de nuevas funciones, esto debido a largos ciclos de lanzamiento y correcciones de errores.
Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización,
a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente
pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas
propios o de terceros. SOA define las siguientes capas de software:

 Aplicaciones básicas. - Sistemas desarrollados bajo cualquier arquitectura o

tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
 De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa
son expuestas en forma de servicios (servicios web);
 De integración de servicios - Facilitan el intercambio de datos entre elementos de
la capa aplicativa orientada a procesos empresariales internos o en colaboración;
 De composición de procesos - Que define el proceso en términos del negocio y
sus necesidades, y que varía en función del negocio;
 De entrega - donde los servicios son desplegados a los usuarios finales. SOA
proporciona una metodología y un marco de trabajo para documentar las
capacidades de negocio y puede dar soporte a las actividades de integración y
consolidación.

El uso de un modelo de servicio es un elemento clave en el diseño del servicio.

Desafortunadamente, no existe un modelo de servicio estándar comúnmente acordado, con la
mayoría de los proveedores de productos SOA e integradores de sistemas que promocionan sus
versiones de modelos de servicio que generalmente tienen una tipología básica común con

8
algunas variaciones en los "bordes". Un modelo de servicio que los autores han encontrado útil
se describe a continuación.

Registro de
servicios

Consumidor de Proveedor de
Asociacion e
Servicios invocacion Servicios

FIGURA 4: Modelo de servicio.

Fuente: (Arceo, 2006).

En la mayoría de las empresas, la proliferación de aplicaciones lleva al surgimiento espontáneo

de una arquitectura corporativa accidental, en estos entornos es usual la existencia de varios
proyectos de integración que intentan solucionar los problemas surgidos de la interacción
necesaria entre aplicaciones, SOA intenta ser un modelo sobre el cual las organizaciones puedan
construir una arquitectura que contemple y favorezca la interacción entre aplicaciones.
La integración tradicional punto a punto casi siempre redunda en costos muy altos, además de
ser poco escalables. SOA nos da alternativa de un modelo en que la integración se realiza por
medio de un canal común, basado en estándares que permitan una mayor interoperabilidad.

FIGURA 5: Modelo de conectividad punto a punto y SOA.

Fuente: (Arceo, 2006).

Se puede resumir que SOA es un enfoque para diseñar y construir soluciones de negocio, a partir
de componentes independientes que exponen funciones como servicios accesibles por otros
componentes a través de interfaces estándares. Está compuesto por diferentes tecnologías como
se puede visualizar en el siguiente ejemplo:

9
 SOA = XML+SOAP+WSDL+UDDI+Bus

Principios

 Contrato de servicios estandarizados.

 Acoplamiento débil de sistemas.
 Abstracción de servicios.
 Reutilización de servicios.
 Servicios sin estado.
 Composición de servicios
 La normalización de servicios
 Transparencia de ubicación de servicios

Según (J, 2009) los componentes centrales de una arquitectura SOA son:

 Servicios SOA: un servicio es una parte de la funcionalidad empresarial independiente: es

decir, un servicio en SOA está diseñado para encapsular alguna funcionalidad que sea
significativa para la empresa. La funcionalidad puede ser simple (como para recuperar
una dirección de cliente) o compleja (por ejemplo, encapsular el proceso de negocios para
cumplir con un pedido de un cliente).
 Bus de servicios empresariales (ESB): la infraestructura que permite una alta
interoperabilidad: media entre los proveedores de servicios y los consumidores,
proporciona servicios de valor agregado y ofrece una plataforma de alto rendimiento,
confiabilidad, escalabilidad (por supuesto, depende de la infraestructura) entre
proveedores y consumidores.
 Gestión y supervisión del servicio: la gestión del servicio a través de un registro /
repositorio de servicios proporciona el descubrimiento del servicio y la gestión del ciclo de
vida y funciones de gobierno; las funciones habilitadoras esenciales para gestionar
eficientemente un número significativo de servicios. Las facetas del desempeño en tiempo
de ejecución se monitorean y reportan a través de las capacidades de monitoreo.

Estos componentes y funciones se basan en el concepto clave de acoplamiento suelto. Este es

un principio fundamental en SOA: diseñar para minimizar las dependencias entre los
componentes de SOA en la mayor medida posible. Esto encuentra expresión en el
desacoplamiento de los proveedores de servicios y los consumidores a través de proxies de
servicio y el ESB; al resumir las descripciones de los servicios y, sobre todo, en el diseño de los
servicios SOA. Dichos componentes serán explicados con más detalle en los siguientes
apartados.
3.2.1- Lenguaje de descripción de servicios web(WSDL)
Lenguaje de Descripción de Servicios Web conocido normalmente como (WSDL) es donde se
detalla los protocolos que permite describir y localizar servicios web. Este lenguaje está basado
en XML y es utilizado por la tecnología de implementación SOAP para la conexión entre servicios
web. WSDL separa la funcionalidad ofrecida por el servicio de los detalles del mismo como el
enlace a un protocolo de red o el formato del mensaje como SOAP y HTTP.

10
Para comunicarse entre sí estos servicios se basan en una definición formal independiente de la
plataforma subyacente y del lenguaje de programación.
Ciertos autores la definen como una súper abstracción, esto debido a su estructura la cual tiene
los siguientes elementos.

Elemento WSDL Descripción

<?xml version=”1.0″> Etiqueta básica de Inicio del archivo

WSDL tal como es utilizado en los
archivos XML

<definitions> Inicio del documento y agrupa a todos

los demás elementos

<types> Tipos de datos de los mensajes

<message> Define los métodos y parámetros para

ejecutar la operación y puede estar
compuesto de cualquier <types>

<portType> Define las operaciones que pueden ser

ejecutadas. Esta es una parte muy
importante. Además los mensajes de
petición y el de respuesta.

<binding> Definen el formato del mensaje y

detalles del protocolo para cada
portType.

TABLA 1: Elementos del Lenguaje de Descripción de Servicios Web.

Fuente: (Czapski, 2009)

3.2.2- Enterprise Service Bus(ESB)

La infraestructura de comunicaciones, conocida como Enterprise Service Bus (ESB), debe ser la
que provee de servicios estándar, mediante los cuales se permite la publicación y la localización
de servicios. Adicionalmente, deberá ofrecer:
Independencia de lenguaje-plataforma: Debe permitir la conexión de servicios implementados
en cualquier tecnología. Al dar soporte a los métodos y mecanismos estándares para desarrollar
e interconectar aplicaciones a través de la empresa, tales como WSDL, SOAP, los ESB reducen

11
drásticamente el tiempo de implementación y el coste total de propiedad de los proyectos de
integración.

Arquitecturas dirigidas por eventos: Se basa en utilizar eventos como disparadores que inician
la distribución de un mensaje que informa a varios receptores acerca de un evento para que
realicen las acciones pertinentes. Estas arquitecturas tienen las siguientes características:

 Desacopladas: la aplicación o servicio que envía el mensaje no sabe quiénes están

suscritos a ese tipo de mensaje. La relación se establece por la información, es decir por
el mensaje, pero no entre las aplicaciones.
 Mensajería publicar/suscribir: ciertos sistemas publican información acerca de algún tipo
de evento en la red para que otros sistemas puedan recibir dicha información y actuar en
consecuencia.
 Asíncronas: Soporta interacciones asíncronas donde la información se envía sin que se
espere una respuesta inmediata o se necesite mantener una conexión activa entre los dos
sistemas mientras se espera la respuesta.

Un ESB debe permitir el soporte de diferentes tipos de mensajería (Czapski, 2009).

 Transformación de mensajes: Debe permitir la modificación de mensajes de modo que

puedan ser adaptados al formato esperado por el receptor.
 Direccionamiento inteligente: El bus debe ser capaz de determinar los destinatarios de un
mensaje, basándose en su contenido. En un ESB los datos se pasan entre los sistemas
conectados al bus utilizando mensajes. La coordinación de mensajes se realiza mediante
un concepto denominado enrutamiento basado en itinerarios. Un itinerario de un mensaje
es un metadato que viaja junto al mensaje y proporciona la lista de direcciones siguientes
a alcanzar por el mensaje. El itinerario es un conjunto de instrucciones que le dice al
framework de ejecución del ESB a qué sistemas se tiene que enviar el mensaje y este
viaja de sistema a sistema a través del bus.
 Orquestación de servicios: Debe otorgar facilidades para la coordinación de servicios. Los
ESB incluyen la capacidad de configurar, implementar y administrar los servicios. A
diferencia de un servidor de aplicaciones centralizado y monolítico o de las arquitecturas
intermediarias (broker) de integración, los ESB proporcionan una óptima flexibilidad y,
más aún, permiten una administración y escalabilidad de los servicios a nivel
independiente, con el fin de alcanzar la mayor eficiencia operativa posible. La
transparencia de ubicación permite que los servicios se actualicen, muevan o reemplacen
sin necesidad de modificar los códigos de las aplicaciones Establecimiento y monitoreo
de niveles de servicio: Debe permitir el establecimiento de niveles de servicio (Service
Level Agreement o SLA) y monitorear su cumplimiento.
 Auditoria: Debe permitir el seguimiento de los mensajes e invocaciones realizadas a través
del bus. Además, proporcionar capacidades de auditoria a nivel tecnológico del estado del
bus y de los servicios disponibles en el bus. Esto se logra mediante la implantación de
distintas políticas de autenticación y autorización.

12
3.3.- Arquitectura orientada a los Microservicios

La arquitectura de los Microservicios es un enfoque para desarrollar una aplicación conformada

por un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y
comunicándose con mecanismos ligeros, a menudo una API de recursos HTTP. Estos servicios
se basan en necesidades del negocio y se pueden implementar de forma independiente,
mediante una maquinaria de implementación totalmente automatizada. Hay un mínimo de
administración centralizada de estos servicios, que puede escribirse en diferentes lenguajes de
programación y usar distintas tecnologías de almacenamiento de datos (Techtaget.com, 2018).
Un Microservicio se describe como una aplicación (pequeña) en sí misma, capaz de evolucionar
independientemente y elegir su propia arquitectura, tecnología y plataforma, puede administrar,
implementar y escalar independientemente con su propio ciclo de vida de lanzamiento y
metodología de desarrollo. En consecuencia, una arquitectura basada en microservicio se define
como un patrón de arquitectura para aplicaciones distribuidas donde la aplicación está compuesta
por una serie de componentes "independientes" más pequeños que son aplicaciones pequeñas
en sí mismas.
Con el patrón de arquitectura de microservicio, se crean aplicaciones individuales para la
validación de direcciones, verificación de crédito del cliente y pedidos en línea; estas aplicaciones
se agrupan para crear la aplicación de pedido (que ahora es una aplicación compuesta). Este
enfoque para el desarrollo de aplicaciones desafía las aplicaciones y servicios "monolíticos"
tradicionales.
Por lo tanto, un microservicio se construye en torno al alcance del "contexto vinculado al negocio,
y sus preocupaciones se aplicarán a ese contexto. Como en el ejemplo anterior, un microservicio
puede asignarse a sistemas empresariales como la gestión de las relaciones con los clientes, la
nómina, etc. o funciones más pequeñas dentro de estos sistemas.
Una forma de mejor entender que son los Microservicios, es compararlo con el estilo monolítico:
una aplicación monolítica a menudo está integrada en tres partes principales: una interfaz de
usuario del lado del cliente (que consta de páginas HTML y javascript que se ejecutan en un
navegador en la máquina del usuario) una base de datos (que consta de muchas tablas
insertadas en una administración de bases de datos común, y generalmente relacional), y una
aplicación del lado del servidor. La aplicación del lado del servidor maneja las solicitudes HTTP,
ejecuta la lógica del dominio, recupera y actualiza los datos de la base de datos, y seleccionará
y completa las vistas HTML que se enviarán al navegador. Esta aplicación del lado del servidor
es un monolito, un único ejecutable lógico. Cualquier cambio en el sistema implica crear e
implementar una nueva versión de la aplicación del lado del servidor (Xabier Larrucea &
Santamaria, 2017).
Un componente es una unidad de software que es reemplazable y actualizable de forma
independiente. Las arquitecturas de Microservicios utilizarán bibliotecas (librerías), pero su
principal forma de crear un componente de su propio software es dividirse en servicios. Se definen
bibliotecas como componentes que están vinculados a un programa y que se llaman mediante
llamadas de función en memoria, mientras que los servicios son componentes fuera de proceso
que se comunican con un mecanismo como una solicitud de servicio web o una llamada de
procedimiento remoto.

13
Una razón principal para usar los servicios como componentes (en lugar de bibliotecas) es que
los servicios se pueden implementar de forma independiente. Si se tiene una aplicación que
consta de varias bibliotecas en un solo proceso, un cambio en cualquier componente implica
volver a implementar la aplicación completa. Pero si esa aplicación se descompone en múltiples
servicios, puede esperarse que muchos cambios en el servicio solo requieren que éste se vuelva
a cargar. Eso no es absoluto, en algunos casos se tendrá que reiniciar
Otra consecuencia de usar servicios como componentes es una interfaz de componentes más
explícita. La mayoría de los lenguajes de programación no tienen un buen mecanismo para definir
una interfaz pública explícita. A menudo, solo la documentación y la disciplina impiden que los
clientes rompan la encapsulación de un componente, lo que lleva a un acoplamiento demasiado
apretado entre los componentes. Los servicios hacen que sea más fácil evitar esto utilizando
mecanismos de llamada remota explícitos

FIGURA 6: Arquitectura orientada a Microservicios.

Fuente: (Newman, 2015)

14
Un microservicio debe ser "desplegable de forma independiente" y cada microservicio tiene su
propia arquitectura de despliegue; y no comparta sus recursos como contenedores, cachés,
almacenes de datos con otros componentes de software empresarial. Por ejemplo, donde el
microservicio almacena y recupera información de una base de datos, el esquema de la base de
datos debe ser parte del microservicio. De manera similar, la escala de un microservicio es
independiente de otros microservicios; y el aumento de la capacidad de un microservicio, al mover
su objetivo alojado o al aumentar el número de instancias, no debería tener ningún impacto en
sus consumidores.
Las aplicaciones que exponen interfaces que otras aplicaciones pueden utilizar para interactuar
se definen como “interfaces de programación de aplicaciones”, y un microservicio proporciona
sus propias interfaces para las comunicaciones. Se construyen APIs de microservicio utilizando
protocolos de comunicación de Internet como HTTP y se adhiere a estándares abiertos como
REST y utiliza tecnologías de intercambio de datos como JSON (Richardson & Smith, 2016).
En una empresa, varios equipos requieren acceso para crear o mejorar funciones comunes como
la cuenta del cliente. Para fomentar una comprensión clara de un microservicio, para que puedan
reutilizarse de manera efectiva, las especificaciones deben definirse y mantenerse en un
repositorio compartido de toda la empresa de todas las especificaciones de microservicios.
Información adicional como estado, propiedad, también puede ser incluida. Las interfaces
proporcionadas por microservicios deben ser detectables: el consumidor de las interfaces debe
poder buscar, encontrar las interfaces sin tener un conocimiento explícito de la implementación o
ubicación de la tecnología subyacente.
La independencia es una característica clave de la arquitectura de microservicios. Para habilitar
esta característica, un microservicio debe tener la administración de los datos dentro de su
contexto; otro microservicio permitiría leer sus datos; sin embargo, las escrituras se realizan a
través del servicio que posee la administración de los datos. Por ejemplo, un microservicio de
cuenta de cliente es el administrador de datos para las cuentas de cliente, y otros microservicios
pueden acceder a versiones de solo lectura de los datos de la cuenta de cliente.
Un microservicio normalmente consta de tres capas como una aplicación típica de 3 niveles, que
consiste en una capa de interfaz, una capa de lógica de negocios y una capa de persistencia de
datos, pero dentro de un contexto acotado mucho más pequeño. Esto establece un amplio
alcance de las capacidades técnicas que podría poseer un microservicio. Sin embargo, no todos
los microservicios proporcionan todas las capacidades; esto variaría sobre cómo se debe
consumir la función proporcionada. Por ejemplo, un microservicio utilizado principalmente por
proveedores de API tendría una capa de interfaz de comunicaciones, lógica de negocios y capas
de persistencia de datos, pero no necesariamente interfaces de usuario (Barcia, Brown, &
Osowski, 2019).
3.3.1- Componentes básicos en una arquitectura de microservicios.

Un modelo de arquitectura para microservicios consta de componentes arquitectónicos clave y

bloques de construcción para implementar y administrar microservicios en el contexto de la
arquitectura empresarial dentro de una organización (Techtaget.com, 2018). Estos componentes
son los siguientes.

15
 Edge service, Un edge service también se conoce como servicio de enrutamiento. Este
servicio permite a los clientes de una aplicación de microservicios, acceder a servicios
individuales, por un único punto de entrada. una definición más formal "un servicio de
enrutamiento es una puerta de enlace para un único punto de entrada, gestiona todas las
peticiones de los clientes, y realiza un re direccionamiento al servicio o servicios
apropiados", En la figura siguiente se muestra cómo un servicio de enrutamiento
redirecciona las peticiones de un cliente hacia un determinado servicio. Este servicio es
importante para abstraer a todos los microservicios del tráfico externo; mapear las URLs
de cada microservicio y permitir redirigir peticiones concretas a servicios concretos.
Algunas de las implementaciones de servicios de enrutamiento más utilizadas son: API
Gateway (AWS), HA-Proxy, Zuul (parte de Spring Cloud Netflix).
 Balanceador de carga y registro de servicios, Un cliente, para poder realizar una
petición necesita conocer la ubicación de red (dirección IP y puerto) de la instancia del
microservicio. Esto puede resultar un problema difícil de resolver, ya que las ubicaciones
de red cambian y el conjunto de instancias de los microservicios cambian dinámicamente
(por escalamiento, fallas o actualizaciones). Precisamente, para resolver el problema
anterior, se utiliza un servicio de descubrimiento (discovery service). un servicio de
descubrimiento se define como “el responsable de determinar la ubicación de red de las
instancias de los servicios disponibles”. Algunos autores lo definen como “una base de
datos de instancias de servicios disponibles". Existen dos tipos de servicios de
descubrimiento, lo cuales se describen a continuación.
1. Descubrimiento del lado del cliente
El cliente es responsable de determinar tanto la ubicación de red de las instancias de los
servicios disponibles, así como del balance de carga de las peticiones entre ellos.
Un registro de servicios es consultado por el cliente, el cual "es una base de datos de
instancias de servicios disponibles". Luego el cliente utiliza un algoritmo de balanceo de
carga para seleccionar una instancia de servicio disponible y así poder procesar la
petición. La ubicación de red de una instancia de servicio es registrada, en el registro de
servicios cuando esta es inicializada, y removida cuando esta es finalizada. Los registros
de instancias de servicios típicamente son actualizados periódicamente.
2. Descubrimiento del lado el servidor
Para este tipo de servicio de descubrimiento, el cliente realiza una petición por medio de
un balanceador de carga. El balanceador de carga consulta el registro de servicios y re
direcciona la petición a una instancia de servicio disponible.
 Circuit breaker Un circuit breaker (circuito cerrado) sirve para "degradar funcionalidad
cuando la llamada a un método falla. Esto permite a un microservicio continuar operando
cuando un servicio relacionado falla, previniendo el fallo en cascada y dando tiempo al
servicio que fallo de recuperarse". Cuando un servicio que tiene dependencias falla, se
desencadena lo que se conoce como un fallo en cascada, tal como se puede observar en
la siguiente figura.
 Logs centralizados, Se definen a los logs centralizados como “una configuración global
de servidores que, escriben todos sus logs a un único archivo de registro". La
centralización de logs, puede ser de mucha utilidad cuando se trata de identificar los
problemas que ocurren en las diferentes instancias de los servicios.
 Configuración centralizada, En un sistema distribuido se necesita disponer de un
componente de configuración centralizada. Esto permite asegurar que los ficheros de
16
 configuración sean únicos para todas las instancias de los microservicios. Pivotal Software
Inc. Describe un servidor de configuración como "un lugar centralizado para gestionar
propiedades externas de aplicaciones alrededor de todos los ambientes". Este
componente lo que hace es tener una copia de los ficheros de configuración, los
microservicios se la piden en caliente, es decir siempre que necesitan una propiedad se
la piden a este servicio.
3.3.2- Coreografia
La coreografía es un patrón en la cual los microservicios interactúan entre sí, cada componente
conoce perfectamente su función, sabe en qué momento debe actuar y a dónde enviar sus datos
al terminar, normalmente la coreografía se basa en servicios asíncronos que pueden encolar sus
peticiones y ejecutarse independientemente.
Aplicar un patrón de coreografía significa que un servicio no habla con otro servicio para instruir
una acción. En su lugar, cada servicio está observando su entorno y actúa sobre eventos
autónomos.
Para que la integración de los microservicios sobre un patrón coreográfico funcione es necesario
que cada microservicio conozca la totalidad del proceso que va a desarrollar, además la
coreografía puede ser complicada de escalar si no se tiene un control sobre el flujo que estuviera
siguiendo, es decir es necesario un monitor que pueda controlar los eventos que se estuvieran
ejecutando.
3.3.3.- Despliegue
Cuando se piensa en la arquitectura de microservicios una cuestión importante a tener en cuenta
es su modelo de despliegue. El modelo de despliegue se refiere a el modo en el cual se va a
organizar y gestionar los despliegues de los microservicios y la tecnología que se utilizara para
lograr este fin (Xabier Larrucea & Santamaria, 2017).

El despliegue puede ser categorizado en los siguientes tipos:

 Mutiples instancias de servicio por host, Este es el enfoque común para desplegar
aplicaciones de microservicios. se disponen de uno o más hosts físicos o virtuales y cada
uno corre múltiples instancias de servicios. Algunas ventajas que tiene este patrón son: el
uso eficiente de los recursos, ya que las instancias de los servicios comparten recursos;
el despliegue e inicio de una instancia de servicio es relativamente rápida. A pesar de sus
beneficios, este patrón también presenta algunas desventajas, por ejemplo, no hay
aislamiento si múltiples instancias de un servicio corren en el mismo proceso, lo cual, si
un servicio falla, puede hacer que los demás servicios fallen.
 Instancia de servicio por host, Al utilizar este patrón se ejecuta cada instancia del
servicio de forma aislada en su propio host. En seguida, se describen dos tipos de
enfoques para este tipo de patrón.
 Instancia de servicio por máquina virtual. Tal como su nombre lo indica, en este tipo
de patrón "se empaqueta cada servicio como una imagen de máquina virtual. Cada
instancia de servicio es una máquina virtual que es iniciado usando esa imagen de
máquina virtual". Este patrón tiene varios beneficios: cada servicio se ejecuta en completo
aislamiento; tiene recursos fijos asignados; se pueden aprovechar los beneficios de la
nube; una vez que la aplicación esta empaquetada como imagen de máquina virtual esta
17
 queda encapsulada. Algunas desventajas que presenta este patrón son: menor eficiencia
en la utilización de los recursos; si se utiliza un IaaS, típicamente se cobra extra por cada
máquina virtual; la construcción, el inicio y el despliegue de la máquina virtual son lentos.
 Instancia de servicio por contenedor. Para este caso, cada instancia del servicio se
ejecuta en un contenedor, lo que implica que se debe empaquetar la aplicación en una
imagen de contenedor. Usualmente se ejecutan múltiples contenedores en cada host, ya
sea físico o virtual. Los beneficios de este enfoque son similares al enfoque anterior: se
aíslan las instancias del servicio; se puede monitorear fácilmente los recursos utilizados
por cada contenedor; encapsulan la tecnología utilizada para implementar los servicios;
son una tecnología liviana; la construcción, el inicio y el despliegue del contenedor son
muy rápidos. Algunas desventajas que tiene este tipo de enfoque son: la infraestructura
para este tipo de tecnología no es tan madura; no son tan seguros como las máquinas
virtuales, ya que se comparte el kernel del sistema operativo host y esto puede ocasionar
que, si un contenedor falle, los otros contenedores también lo hagan; al igual que con el
enfoque de máquinas virtuales, si se utiliza un IaaS, se cobra extra por cada contenedor.

3.3.4.- Escalabilidad y desacoplamiento

En aplicaciones monolíticas, donde tenemos un único núcleo, de manera natural se produce un
acoplamiento mayor entre sus distintas partes, es decir, dependen más entre sí, de modo que los
cambios en una parte suelen repercutir más en otras partes.
Si se tiene varios servicios pequeños más independientes, podemos desmontar cualquier
servicio, cambiarlo y volverlo a montar sin que esto afecte a otros servicios. En realidad, los
servicios comunican entre ellos para realizar tareas mayores, pero con que se respete los
términos de esas comunicaciones es suficiente para que sigan colaborando a pesar de sus
cambios.
En cuanto a escalabilidad la mejora es fundamental. En aplicaciones monolíticas se escala
generalmente replicando el servidor de aplicaciones completo. Pero no siempre ocurre que todas
las partes de la aplicación están saturadas y necesitando la replicación. En microservicios si un
servicio se satura, simplemente se necesita replicar ese pequeño servicio que estaba dando
problemas. O si se levanta un nuevo servidor de aplicaciones se puede elegir qué servicios
replicar porque sean los que lo estén necesitando. En microservicios el mantenimiento en la
aplicación se puede realizar de manera individual por servicios. Si una parte de tu aplicación
cambia, necesitas una nueva funcionalidad o reparar un bug, no necesitas hacer un despliegue
de toda una macro-aplicación, sino simplemente del servicio en cuestión que había que actualizar.

18
 4 SOA vs MSOA ANALISIS COMPARATIVO

De acuerdo al ciclo de sobreexpectación de gartner podemos situar a las dos arquitecturas en

diferentes etapas, SOA se encuentra en la etapa de consolidación y MSOA se encuentra en la
etapa de expectativas sobredimensionadas, en este sentido es que se comparan ambas
arquitecturas. Ambos tienen al “servicio” como su núcleo y sus componentes son parecidos, pero
tienen diferencias en cuanto a la granularidad, la integración y los protocolos.
Se compararon ambas arquitecturas con sus diferentes características y se encontraron las
siguientes diferencias y semejanzas: MSOA tiene un mayor costo de despliegue comparado
contra SOA, SOA no tiene una granularidad definida para su implementación mientras que MSOA
sugiere una granularidad fina, SOA proporciona una mejor abstracción de la interfaz y mejor
manejo de protocolos, para la interacción fuera del servicio las MSOA proporciona una mayor
independencia respecto a SOA, de acuerdo al alcance de la aplicación es que MSOA es más
apropiado que SOA, en el apartado de integración SOA puede interactuar con diferentes
protocolos, mientras que MSOA necesita que el protocolo sea el mismo en ambas direcciones.
En tiempos de respuesta SOA es 10 % más rápido que MSOA, MSOA tiene ventaja en el apartado
de equipos ya que SOA depende de diferentes recursos de acuerdo al requerimiento del servicio,
MSOA es más apropiado para sistemas escalables mientras que SOA es apropiado para
aplicaciones empresariales fijas.
Los microservicios tienen ventajas y desventajas; lo positivo es que son independientes, pueden
ser escalables, utilizan pequeños equipos de desarrollo y tienen un mantenimiento fácil, el lado
negativo es que las pruebas son complicadas, requiere un esfuerzo adicional para implementar
la integración de servicios y la complejidad del sistema distribuido. SOA también presenta
ventajas tales como la optimización de los procesos de negocio, se tiene un mayor control sobre
los servicios ejecutados y permite una personalización de los servicios, en contra SOA se hace
costosa, se depende de un único ESB e implica conocer los procesos del negocio.
4.1.- Introducción
Como se pudo observar, SOA y microservicios no se ubican al mismo nivel en una curva de
madurez. de acuerdo al ciclo de sobreexpectación de Gartner (Gartner, 2002), el primero ha
llegado a su punto más bajo en el ciclo de sobreexpectación y ahora está avanzando hacia arriba
a lo largo de la rampa de consolidación, mientras que el segundo es en gran medida la nueva
arquitectura de moda que se encuentra en el pico de expectativas sobredimensionadas. En las
Secciones anteriores, se describió la intención, los principios, los fundamentos y la funcionalidad
asociados con los estilos arquitectónicos de SOA y microservicios sin comentarios adicionales.
En este capítulo se dará un vistazo crítico a las dos arquitecturas.
4.2.- Análisis
El primer punto a destacar es la similitud entre los dos enfoques. Ambos tienen la noción de un
"servicio" en su núcleo, una pieza de software que sigue un protocolo de solicitud de respuesta.
Los componentes que soportan los dos estilos arquitectónicos son notablemente similares. En el
siguiente cuadro se puede observar una comparación entre los componentes de SOA y
Microservicios de acuerdo a la función que representan cada uno de estos.

19
 Función Componente (SOA) Componente (Micro servicio)

Punto de gestión central; Registro de Registro de API de empresa;

Servicios registrados / APIs de servicios, repositorio repositorio de micro servicio
búsqueda y descubridores de servicios. empresarial

Interfaz compuesta por servicios

Bus de servicios Capa de gestión API (API
/ APIs son proxy o puestos a
empresariales(ESB) proxy)
disposición para el consumo
como único punto de entrada.

Punto final del servicio o micro Proveedor de

Proveedor de micro servicio
servicio servicio

BAM, monitoreo de
Servicio de tiempo de ejecución
servicio. Monitoreo empresarial.
/ monitoreo y gestión de API

TABLA 2: Comparación entre componentes de la arquitectura SOA y MSOA.

Fuente: (Xiao, 2016).

Además, se puede observar que las dos arquitecturas tienen las siguientes diferencias.
SOA servicios Micro servicios
Los servicios pueden ser de granularidad fina
o grueso. Granularidad fina, servicios pequeños.

Servicio independiente, sin acoplar que se

Acoplado libremente, cohesivo
ejecuta en su propio contenedor; escalable
independientemente

Gobernanza centralizada, la gobernanza vista

Gobierno descentralizado
como un valor estratégico agregado

Considerado diseño y desarrollo; Diseñado

para durabilidad, control de cambios bien
Desarrollo muy rápido; rápida reposición.
definido.

Protocolos: HTTP; REST, JSON

Protocolos: HTTP, JMS, mensajes específicos
de otros proveedores; SOAP, XML

TABLA 3: Diferencias entre la arquitectura SOA y MSOA.

Fuente: (Xiao, 2016)

20
4.3.- Comparación
Para comparar ambas arquitecturas se evaluaron diferentes áreas de aplicación, su costo de
infraestructura, rendimiento, escalabilidad y entrega continua, con los desafíos que implican la
adopción de la cultura empresarial y las metodologías de desarrollo, los detalles se describen en
los siguientes apartados.
4.3.1.- Costo de infraestructura

De acuerdo a información sobre el costo de despliegue en servidores en la nube de amazon web

services y ejecutando una misma infraestructura, pero con las diferentes arquitecturas se pudo
concluir que, el costo de infraestructura de la arquitectura de microservicios aumenta
aproximadamente un 25% en comparación con la arquitectura SOA. Esto debido a que se pagará
por cada microservicio desplegado, es decir, los microservicios están compuestos por diferentes
componentes estos componentes superan en cantidad a los componentes que se utilizaran en la
arquitectura SOA, todo esto depende de la granularidad con la cual se desarrolle el sistema.
4.3.2.- Granularidad del servicio
El concepto de granularidad parte del principio que es más fácil reutilizar unidades más pequeñas
dado, que, de este modo, es posible seleccionar aquellas partes que nos interesan y descartar
aquellas que no son adecuadas en el contexto donde nos encontramos.
Además, la granularidad describe el nivel de detalle de un servicio. La determinación del nivel de
granularidad es uno de los puntos más importantes del modelado lo cual impacta directamente
en el tamaño de la arquitectura.
Se identifican tres tipos de granularidad del servicio:
 la granularidad de la funcionalidad; indica la cantidad de funcionalidad proporcionada por
un servicio.
 la granularidad de los datos; cuantifica los datos que se intercambian.
 la granularidad de valor de negocio; describe el valor de negocio agregado de un servicio.
En los Microservicios se sugiere alinear cada servicio con una capacidad del sistema de software
que sea distinta a otras capacidades, El objetivo es agrupar y aislar conceptos de dominio
relacionados y funcionalidades de otros servicios, lo que resulta en una disminución de las
interacciones de servicio y una reducción de conceptos que se superponen a varios servicios. En
consecuencia, esto da como resultado una granularidad de funcionalidad limitada y una
granularidad de valor comercial de un Microservicio. Sin embargo, la granularidad de los datos
depende en gran medida de la adecuación del servicio. La minuciosidad de los servicios podría
llevar a una cantidad ineficaz de interacciones necesarias para cumplir con la solicitud de un
consumidor. Por otro lado, cuando la interacción sólo tiene lugar en el caso de que dos servicios
adaptados óptimamente necesiten atender una solicitud que abarque áreas distintas del dominio
de la aplicación, se mitiga la posibilidad de una granularidad de datos excesiva (Richards, 2015).
Por el contrario, SOA no proporciona una guía explícita sobre la granularidad del servicio. Por lo
tanto, el tamaño y el alcance de los servicios pueden variar desde servicios específicos de
aplicación finos hasta servicios empresariales de granularidad gruesa que realizan una variedad
de capacidades de un sistema de software distribuido.

21
4.3.3.- Abstracción de la interfaz
Una interfaz es una condición previa para interactuar con un servicio, ya que especifica
información obligatoria como la estructura y la semántica de los mensajes y datos intercambiados.
SOA y MSA comparten requisitos centrales con respecto a las interfaces, por ejemplo:
 disponibilidad de descripciones de interfaz para los consumidores, probablemente junto
con un mecanismo de control de versiones, para permitir la interacción
 provisión de múltiples, pero diferentes descripciones de interfaz por servicio
 acoplamiento con protocolos como medio para el transporte de información
Sin embargo, SOA proporciona un mayor nivel posible de abstracción de interfaz que MSOA.
Esto se debe a que las SOA generalmente integran un Enterprise Service Bus (ESB), que permite
la transformación y mejora de los mensajes de interacción. Por lo tanto, las SOA facilitan la
interacción de los servicios, cuyos formatos y estructuras de mensajes difieren, por ejemplo, a
través del desacoplado patrón de contrato. Como los sistemas basados en MSOA generalmente
no comprenden un ESB, la interacción con los servicios solo es posible si los consumidores
utilizan formatos de mensajes y estructuras directamente compatibles con los servicios (Richards,
2015).
4.3.4.- Protocolos
Junto a la transformación del mensaje, los ESB también son capaces de transformar el protocolo,
lo que proporciona a las SOA el potencial de soportar una cantidad arbitraria de protocolos de
transporte. Esto permite la interacción de los participantes que utilizan diferentes protocolos. Por
el contrario, las MSA generalmente se aplican a la mayoría de dos protocolos diferentes, es decir,
uno a uno y uno a varios escenarios de interacción. Si bien las interacciones uno a uno dependen
principalmente de REST a través de HTTP, las interacciones uno a muchos siguen un patrón de
mensajería de publicación-suscripción (Xiao, 2016).
4.3.5.- Interacción entre servicios

En las arquitecturas basadas en servicios, los patrones más comunes para la coordinación de las
interacciones entre la arquitectura y el servicio interno son la orquestación y la coreografía.
Las orquestaciones se basan en un mediador central que coordina las interacciones del servicio
de acuerdo con la solicitud que debe manejarse.
Dentro de las coreografías, los servicios deciden de forma autónoma cuándo interactuar con otros
servicios. Esto generalmente resulta en cadenas de llamadas de servicio.
Para la interacción entre servicios, las MSA prefieren la coreografía sobre la orquestación,
mientras que SOA puede considerar igualmente la aplicación de ambos patrones según el
escenario de interacción concreto, pero generalmente se utiliza una orquestación. La razón detrás
del predominio de la coreografía en las MSA es la ausencia de un ESB y, por lo tanto, una capa
de orquestación habilitada para ESB.
4.3.6.- Interacción fuera del servicio
En las SOA, la ESB actúa como un intermediario entre los servicios internos de la arquitectura y
los consumidores externos con el potencial de mediar, en rutar y transformar los mensajes
intercambiados.
22
Los MSOA pueden proporcionar puertas de enlace API para que los llamantes externos realicen
solicitudes. En comparación con los ESB, las puertas de enlace API no muestran ninguna
capacidad de transformación de protocolo o mensaje. En su lugar, actúan como fachadas
bastante simples entre microservicios y consumidores, que se abstraen de los puntos finales y
granularidades de los servicios. Por lo tanto, un conjunto de interfaces de microservicio de
granularidad fina podría agregarse en una única función de API de granularidad gruesa más
conveniente para llamadores externos. Esto requiere una puerta de enlace API para implementar
capacidades de enrutamiento y mediación similares a un ESB. Las puertas de enlace API
fomentan el desacoplamiento de las estructuras de servicio de las expectativas de los
consumidores y permiten la evolución independiente de la MSOA siempre que la API expuesta
permanezca estable (Xiao, 2016).
4.3.7.- Alcance de la aplicación
SOA está predestinado para sistemas de software empresariales o de empresas cruzadas que
presentan un alto grado de heterogeneidad con respecto a, por ejemplo, formatos de datos,
estructuras de mensajes, protocolos y tecnologías. Además, cuando las preocupaciones como
las políticas y la gobernabilidad deben abordarse de forma centralizada en la arquitectura, SOA
es preferible a MSOA.
Los tipos de sistemas de software que favorecen a MSOA comprenden

 aplicaciones basadas en flujos de trabajo con flujos de procesamiento bien definidos y

capacidades empresariales predominantemente distintas.
 monolitos con escalabilidad disminuida.
 aplicaciones basadas en web que no requieren transformación de protocolo o mensaje
genérico. Algunos ejemplos de dominios de aplicación de MSA son los servicios
financieros, por ejemplo, Comercio de valores, transporte e Internet de las cosas.

4.3.8.- Integración
La arquitectura de microservicio admite interoperabilidad heterogénea sensible al protocolo en la
que el consumidor de servicios y ambas partes deben tener los mismos protocolos (REST), pero
la implementación del servicio y su consumidor pueden estar en diferentes tecnologías, como el
consumidor de servicios en java y el servicio implementado en .Net C #, esto es También se llama
lenguaje agnóstico en la arquitectura microservicio. Se encontraron algunos problemas durante
el desarrollo de la arquitectura de Microservicios debido a un entorno distribuido que enfrentó
fallas, transacciones distribuidas, comunicación entre servicios y problemas relacionados con las
dependencias, pero en la arquitectura SOA se administra en el nivel de la aplicación en una base
de código único.
En lo que respecta a la integración de nuevos servicios y consumidores externos, ambos estilos
arquitectónicos difieren en que las SOA impulsadas por ESB soportan implícitamente la
interoperabilidad heterogénea agnóstica del protocolo, mientras que las MSA solo admiten la
interoperabilidad heterogénea sensible al protocolo. Por lo tanto, los servicios SOA pueden
interactuar con las personas que llaman que basan su comunicación en diferentes protocolos. En
contraste, un requisito fundamental para interactuar con Microservicios es que el protocolo sea el
mismo para ambas direcciones de comunicación (Xiao, 2016).

23
4.3.9.- Rendimiento y tiempo de respuesta
Después del análisis, se ha evaluado el rendimiento de una aplicación desarrollada con la
arquitectura SOA y de microservicio en JMeter, configurado para la instancia de microservicio y
se ha observado que, debido a tareas secuenciales, los Microservicios tienen un 10% más de
tiempo de respuesta en comparación al tiempo que ejecutó SOA.
4.3.10.- Desafíos, esfuerzo y adopción de la cultura
Los Microservicios fomentan la organización de equipos de desarrollo en torno a características,
es decir, capacidades de infraestructura y negocios que deben realizarse y proporcionarse. Como
esto se alinea con la adaptación de los servicios, por lo general, exactamente un equipo es
responsable de un Microservicio determinado, que incluye su implementación y operación. Por lo
tanto, al lado de los desarrolladores, un equipo de desarrollo de Microservicios consta de personal
operativo que supervisa todos los aspectos relevantes para la operación de un servicio, por
ejemplo. Implementación, seguimiento y registro. Este enfoque de combinar el desarrollo y la
experiencia operativa en un equipo se conoce como DevOps. Otra característica de los equipos
de Microservicios es su tamaño comparativamente pequeño, que a menudo oscila entre cinco y
doce miembros.
En Microservicios, el equipo de desarrollo debe seguir el conjunto de directrices de la cultura de
mejores prácticas entre todos los miembros del equipo y adoptar esta cultura innovadora a lo
largo del proyecto.
En la arquitectura SOA, la responsabilidad de un servicio depende de su tipo. Por ejemplo, los
analistas de negocios proporcionan descripciones abstractas basadas en procesos de servicios
de negocios y desarrolladores de aplicaciones que implementan partes de estos servicios de
negocios como servicios de aplicaciones. Los arquitectos de software componen varios servicios
de aplicaciones y pueden desarrollar una funcionalidad adicional para toda la empresa para
proporcionar una realización ejecutable de un servicio empresarial. Por lo tanto, en una SOA es
común que los equipos se armen de manera homogénea sobre la base de disciplinas
profesionales y que más de un equipo esté involucrado en el desarrollo y la provisión de un solo
servicio.
4.3.11.- Escalabilidad y entrega continua
La implementación de Microservicios requiere muchos servicios y una puerta de enlace para
implementar individualmente y configurar sus ajustes. Una de las principales complejidades
durante la implementación por primera vez de una aplicación completa es implementar y
configurar cada servicio, puerta de enlace, frente de nube, instancia de EC2 y etc. debido a la
necesidad de una implementación continua de la arquitectura de Microservicios es una tarea
difícil.
En la nube se necesita usar herramientas de automatización para ahorrar tiempo de
implementación y mantener la agilidad. En la arquitectura de Microservicios, el equipo de
desarrollo sigue las estrategias de DevOps (desarrollo + operación) en las que el equipo de
desarrollo también implementa, opera y monitorea la aplicación en la nube. en contraste SOA es
fácil de implementar en la nube si se tiene un número limitado de usuarios, entonces la
arquitectura SOA será la mejor opción cuando se tenga una aplicación empresarial que no se
actualice constantemente y tenga un número limitado de clientes, por el contrario si la
escalabilidad y la administración del equipo son la prioridad más alta de la aplicación para este
24
propósito que necesitamos de manera incremental, se sugiere aplicar la arquitectura de
Microservicio para manejar este problema de escalabilidad y administración de equipos. También
ayuda a mejorar el incremento continuo del proyecto porque fue desarrollado, probado,
implementado, escalado y modificado por equipos individuales.
4.3.12.- Orientación practica
Se percibe que la MSOA muestran una orientación más fuerte hacia las necesidades de los
desarrolladores que la arquitectura SOA debido a sus conceptos y tecnologías más "ligeros" y
menos complejos. Una disminución de la complejidad conceptual de los MSOA se debe a su
reducida taxonomía de servicios. Mientras que en un SOA diversos tipos de servicio, por ejemplo,
Los servicios de empresa, aplicación o integración pueden existir al mismo tiempo, los MSOA
básicamente se basan en dos tipos de servicios:

 Los servicios funcionales realizan capacidades de negocios, que están directamente

expuestas a los consumidores o a través de una API intermedia.

 los servicios de infraestructura proporcionan capacidades técnicas integrales, por

ejemplo, autenticación, auditoría y monitoreo, y generalmente no son accesibles por
personas externas.

La complejidad conceptual de MSOA se reduce aún más al no requerir soporte de protocolo

genérico. También carece o restringe el soporte de ciertas capacidades específicas de
interacción. Por ejemplo, se omiten las capas de orquestación y se utilizan las puertas de enlace
API en lugar de los ESB. Con respecto a las tecnologías de implementación, es posible crear
MSOA con conciencia empresarial a partir de un framework único que también proporcione
componentes de infraestructura adicionales y así faciliten el desarrollo.
Debido al soporte sofisticado de SOA para los sistemas de software con una alta heterogeneidad
tecnológica, podría no ser sensato o factible restringir una arquitectura SOA a una única
tecnología o marco de implementación. Sin embargo, la posibilidad de realizar una MSOA con
conciencia empresarial con un solo framework aumenta el riesgo de un posible bloqueo del
proveedor, un MSOA podría exhibir una cantidad excesiva de diferentes tecnologías de
implementación de servicios porque los equipos suelen ser muy independientes. La complejidad
tecnológica percibida de la arquitectura MSOA también se reduce, ya que REST es su protocolo
de comunicación predeterminado. SOA a menudo se basa en SOAP, que comúnmente se supone
que exhibe un mayor grado de complejidad que REST.
4.3.13.- Procesos
Los Microservicios y su composición del equipo desarrollador basada en características lleva a
un aumento de la independencia del equipo porque reduce:

 la probabilidad de problemas transversales

 la cantidad y el alcance de los procesos de comunicación entre equipos relacionados con

las funciones internas de la funcionalidad del servicio

En combinación con DevOps basados en contenedores, esto facilita la organización de los

procesos de desarrollo sobre la base de enfoques de integración continua.
25
Con la adopción de entrega continua(CD), cada equipo configura un canal de CD para su
Microservicio, que se ejecuta cuando cambia el código de un servicio. Los pasos típicos de la
ejecución de la canalización de CD comprenden

 compilación y construcción.

 pruebas unitarias.

 despliegue de contenedores.

 Pruebas de integración y de extremo a extremo.

La entrega continua permite la automatización de la creación de artefactos y proporcionan un

control centralizado de los resultados de las pruebas. Además, junto con los microservicios que
son artefactos autónomamente operables, se espera que la entrega continua de un beneficio
clave entregados en las MSOA sean una mayor rapidez en la retroalimentación con respecto a la
calidad del código.
4.4.- Ventajas y desventajas en la arquitectura orientada a los Microservicios
Ventajas

 Cada ejecución en un proceso separado, que se puede implementar de forma

independiente y se puede administrar, la reparación y el mantenimiento de una unidad
pequeña pueden evitar fallas en el sistema, un mantenimiento fácil y una implementación
rápida y la actualización de nuevas versiones.

 Si ocurre una falla, solo ese servicio se verá afectado en lugar de una empresa completa,
pero en SOA un componente con falla, puede derribar todo el sistema.

 El sistema de micro nivel de unidad individual para cada equipo de desarrollo se centra
en su objetivo y puede utilizar cualquier nueva tecnología de lenguaje de programación
para el primer desarrollo o después de eso.

 Tiene diversidad tecnológica, cada una puede escribirse en diferentes lenguajes de

programación y puede tener su sistema de base de datos.

 Pequeños proyectos fáciles de administrar y hacer un IDE más rápido con un mayor
enfoque y productividad del desarrollador.

 Nos permite organizar el proceso de desarrollo en equipos separados debido a su

naturaleza escalable.

 Un Microservicio puede ser desarrollado por un equipo bastante pequeño.

 Fácil integración e implementación automática (utilizando herramientas de integración

continua de código abierto como Jenkins, Hudson, etc.).

 Fácil de entender y modificar para los desarrolladores, por lo tanto, puede ayudar a un
nuevo miembro del equipo a ser productivo rápidamente.

26
Desventajas

 El desarrollador debe lidiar con la complejidad del sistema distribuido.

 El IDE del desarrollador, por lo general orientado a modelos monolíticos, no es compatible

con el entorno de código distribuido, requerirá un esfuerzo adicional para administrar y
configurar los servicios requeridos y los servicios interdependientes, por lo que el
desarrollador debe implementar un mecanismo entre servicios.

 Las pruebas serán complicadas para cada módulo separado. La gestión de diferentes
tipos de servicios es compleja durante la operación de la implementación, especialmente
la primera vez que la aplicación empresarial está en producción.

 Existe cierto desafío al implementar los MSOA por primera vez, esto debido a las
diferentes implementaciones que tiene dicha arquitectura, uno de los desafíos sino el
mayor es cómo convertir su aplicación en MSOA.

 SOA admite tanto la interoperabilidad heterogénea, consciente del protocolo como la del
protocolo, pero MSOA solo admite un protocolo de mensajería simple.

 El aumento en el número de servicios puede generar barreras de información.

 La arquitectura ofrece una complejidad adicional ya que los desarrolladores deben mitigar
la tolerancia a fallas, la latencia de la red y lidiar con una variedad de formatos de
mensajes, así como con el equilibrio de carga.

 Al ser un sistema distribuido, puede dar lugar a la duplicación de esfuerzos.

 La arquitectura generalmente resulta en un mayor consumo de memoria.

4.5- Ventajas y desventajas de la arquitectura orientada a servicios

Ventajas

 Mejora en los tiempos de realización de cambios en procesos.

 Facilidad para evolucionar a modelos de negocio basados en tercerización.

 Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso
de negocio.

 Aplicaciones flexibles

 Mejora la toma de decisiones.

 Agilidad para habilitar rápidamente soluciones innovadoras y para adaptarse a cambios

en el mercado cuando ocurran.

 Flexibilidad para reducir los tiempos y costos de implantación, y para contar con una
arquitectura ágil que permita la evolución, cambio y crecimiento del negocio.

 Rapidez para llegar primero al mercado antes que la competencia y crecer la participación
de mercado.

27
  Obtener mejor visibilidad de la información a través de toda su organización.

 Optimiza sus procesos de negocios.

 Tasas internas del retorno sobre la inversión de hasta el 100%.

 Capacidad de reutilizar y potenciar otras aplicaciones informáticas como ERP's, CRM's,

etcétera. Por otra parte, permite: Una "personalización masiva" de las tecnologías de la
información.

 La simplificación del desarrollo de soluciones mediante la utilización de estándares de la

industria y capacidades comunes de industrialización.

 Aislar los sistemas frente a cambios generados por otras partes de la organización
(protección de las inversiones realizadas).

 Alinear y acercar las áreas de tecnología y negocio.

Desventajas

 La implementación de un bus de servicios empresarial ESB, se convierte en un factor

crítico, si el bus llegase a fallar, la comunicación (integración), de los diferentes servicios
y las aplicaciones se perdería, colapsando el sistema basado en servicios.

 La arquitectura orientada a servicios depende de la implementación de estándares. Sin

estándares, la comunicación entre aplicaciones requiere de mucho tiempo y código.

 La arquitectura orientada a servicios no es para: aplicaciones con alto nivel de

transferencia de datos, aplicaciones que no requieren de implementación del tipo
request/response y para aplicaciones que tienen un corto periodo de vida.

 La arquitectura orientada a servicios se hace difícil y costosa, esto debido a las exigencias
de cumplir con los protocolos y hablar con un servicio.

 Implica conocer los procesos del negocio, clasificarlos, extraer las funciones que son
comunes a ellos, estandarizarse y formar con ellas capaz de servicios que serán
requeridas por cualquier proceso de negocio.

En la medida en que un servicio de negocio, vaya siendo incorporado en la definición de los

procesos de negocio, dicho servicio aumentará su nivel de criticidad. Con lo cual cada que se
requiera efectuar una actualización en dicho servicio, deberá evaluarse previamente el impacto y
tener mucho cuidado con su implementación.

28
 5 IMPLICACIONES Y BUENAS PRACTICAS

Con la clara distinción de MSA de SOA, ahora es posible deducir las implicaciones en el desarrollo
de ambas arquitecturas, estas implicaciones nos sugieren que existe una mayor cohesión de los
servicios en MSOA, la fragmentación de los servicios es más flexible en SOA, existe un
comportamiento menos complejo respecto a los servicios en MSOA, SOA puede implementar
diferentes tipos de controladores mientras que MSOA solo uno, para la integración de los
servicios SOA utiliza la orquestación y MSOA puede utilizar tanto la orquestación como la
coreografía y MSOA deriva el modelado y gobernanza de los servicios al equipo de desarrollo.
Estas implicaciones proporcionan una visión general inicial de los criterios que deben
considerarse al aplicar SOA y MSA.
Es importante aplicar buenas prácticas en las arquitecturas SOA y MSOA estas deben estar
orientadas a mantener el sistema y la solución flexible, eficiente y escalable. Ambas arquitecturas
deben poner como prioridad la velocidad de desarrollo y la comprensión de la lógica de negocio
de la empresa, se sugiere utilizar un modelo en el que los servicios están divididos en grupos con
el objetivo de poder brindar servicios en un tiempo corto y contemplando un buen modelo de
arquitectura. si se tiene la opción de desarrollar una arquitectura desde el inicio es recomendable
utilizar MSOA para su implementación, en caso que la empresa ya utiliza SOA, se debe utilizar
los protocolos actuales para las nuevas implementaciones.
5.1.1- mayor cohesión en los modelos de negocio internos del servicio
En MSA sugiere implementar una capacidad de negocio autónoma en exactamente un servicio
funcional de granularidad gruesa. Esto da como resultado una mayor cohesión de los modelos
de negocios internos del servicio, ya que estos solo abarcan conceptos y elementos de un
extracto aislado y coherente del dominio empresarial.
Un contexto acotado determina el alcance de un modelo de negocio y agrupa los modelos de
negocio relacionados. Cada contexto limitado especificado puede servir como punto de partida
para adaptar la funcionalidad de un Microservicio y la definición de su límite, esto también es
aplicado a SOA ya que este último no tiene un contexto definido sobre la granularidad del servicio.
5.1.2- Fragmentación más explícita del modelo
La realización de una capacidad empresarial en un Microservicio autónomo y el consiguiente
aumento de la cohesión de los modelos internos del servicio, permiten una definición más
explícita de la lógica de los negocios. los modelos compartidos se utilizan como encapsulaciones
explícitas de partes de modelos de negocios que deben intercambiarse entre contextos limitados.
Cuando se asigna un contexto limitado a un microservicio, estos modelos proporcionan
definiciones iniciales de interfaces de servicio. Los modelos compartidos suelen participar en la
interacción de microservicios funcionales y La puerta de enlace API podría combinar varios
modelos compartidos en un servicio de granularidad gruesa.
Sin embargo, en una SOA, los conceptos de negocios pueden fragmentarse de manera más
flexible en diferentes partes de la arquitectura con diversas granularidades. Por ejemplo, un
servicio empresarial puede combinar e incluso enriquecer conceptos de diferentes servicios de
aplicación. Entonces es posible proporcionar el servicio empresarial resultante y sus conceptos

29
de negocios alterados a una variedad de participantes de SOA, por ejemplo. Consumidores
externos u otros servicios empresariales.
5.1.3- Modelos de comportamiento menos complejos en modelos de arquitectura
Dado que MSA favorece la coreografía sobre la orquestación, las interacciones de microservicios
expresadas como parte del modelo de arquitectura pueden ser solo coreografías. Las cadenas
de llamadas de servicio resultantes tienden a ser menos complejas que los modelos de
orquestación basados en procesos o los escenarios de interacción mixta que involucran ambos
patrones de coordinación de servicios. Un potencial adicional para la reducción del modelo de
comportamiento. la complejidad se logra cuando el MSA y sus interacciones exhiben flujos de
procesos bien definidos.
5.1.4- Diferentes controladores para la complejidad del modelo de arquitectura
SOA comprende una variedad de tipos de servicios sofisticados. Estas características están
diseñadas por SOA para predestinarse a los sistemas de software que abarcan diferentes
departamentos empresariales e incluso a las empresas mismas.
En las MSA, las características mencionadas generalmente no existen o exhiben una peculiaridad
menos compleja, lo que disminuye parcialmente la complejidad del modelo de arquitectura. Sin
embargo, para habilitar los aspectos de servicios relacionados con la operación de modelado se
requiere conceptos de modelado adicionales que no son tan importantes. Por ejemplo, parece
sensato que los modelos de arquitectura MSA comprendan aspectos relacionados con la
operación, como la asignación de servicios a contenedores, por ejemplo. para generar guiones
de configuración.
5.1.5- Modelado de integración menos complejo pero restringido
La integración de los servicios en una MSA es consciente del protocolo, es decir, un requisito
previo para la interacción del servicio es el acuerdo del servicio y el consumidor en un protocolo
determinado. Por lo tanto, las capacidades de transformación habilitadas por ESB que aseguran
la comunicación sin protocolo no deben ser consideradas por los lenguajes de modelado. Sin
embargo, la integración se limita entonces a la homogeneidad del protocolo y no es posible
modelar la integración de consumidores externos con una MSA que no es compatible con sus
protocolos.
5.1.6- Modelado de la operación del servicio dependiente del equipo de desarrollo
En el contexto del desarrollo los equipos se componen de desarrolladores de servicios y
operadores. El soporte de la lógica de negocio para modelar los aspectos relacionados con la
operación de un Microservicio es, beneficioso y también es considerado a nivel conceptual para
SOA. Asigna modelos relacionados con la operación, por ejemplo, para la implementación y el
monitoreo, a diferentes vistas, pero carece de una vista consolidada, dependiente del equipo, que
comprenda toda la lógica del negocio de operación de servicio. En la investigación SOA, los
aspectos de operación no parecen estar ampliamente cubiertos en lenguajes de modelado.
Esperamos que la MSOA, cuyas sintaxis abstractas incluyan conceptos relacionados con la
operación del servicio, mejoren la comunicación de los desarrolladores y los miembros del equipo
operativo. La razón de esto es el potencial para proporcionar a los operadores elementos de
lenguaje concisos para describir con eficacia los aspectos técnicos de la operación del servicio,
por ejemplo. Configuración de contenedores. Dependiendo de la adecuación de la granularidad

30
de abstracción de estos elementos del lenguaje, la comprensión de las configuraciones concretas
de los contenedores podría facilitarse a los desarrolladores que no estén familiarizados con este
aspecto relacionado con la operación a nivel técnico (Richards, 2015).
5.1.7- Modelo de gobernanza dependiente del equipo.
MSA fomenta una gran independencia de los equipos de desarrollo esto también afecta a la
gobernabilidad, que es un aspecto central de las SOA y se espera que se beneficie del apoyo
explícito al modelado.
Sin embargo, en las MSA, la responsabilidad de la gobernanza está delegada a los equipos y no
está determinada por una unidad organizativa central. Esto lleva a la existencia y madurez de los
modelos de gobierno que dependen del equipo. Si bien la gobernabilidad no es un aspecto
funcional como la implementación y operación del servicio, los equipos de MSA que usualmente
se enfocan en la provisión rápida de nuevas funcionalidades podrían no considerar la
gobernabilidad y la calidad de los modelos relacionados como una de sus tareas principales. A
través de transformaciones efectivas de modelos y validaciones sofisticadas, se puede mitigar la
posible inmadurez de los modelos de gobernabilidad (Xiao, 2016).
5.2.- Mejores practicas
¿Cuál es, entonces, el mejor enfoque para diseñar, desarrollar y administrar las interfaces de los
programas de aplicación; aquí se toma "mejor" en el sentido de cuál es la mejor manera de lograr
los resultados comerciales de la empresa?
Irónicamente, una de las razones por la que la arquitectura SOA tuvo una percepción de falta de
agilidad en el mundo de las tecnologías de información corporativo fue causado por los sistemas
monolíticos, los entornos complejos y la integración, los entornos heredados mal entendidos, etc.
Desafortunadamente, existe la misma complejidad hoy en día. especialmente en negocios
establecidos, que invariablemente tienen un legado de sistemas con diferente antigüedad y
diferentes diseños. Sin embargo, la demanda de agilidad y velocidad de respuesta han
aumentado casi en un orden de magnitud, principalmente a través de la aparición del mundo
digital. Y este es un desafío muy real, especialmente para las empresas establecidas que ven a
los desarrolladores innovando e introduciendo modelos de negocio disruptivos que reducen el
mercado y la rentabilidad. También considerar que el cambio de respuesta para la entrega de
proyectos hace años eran meses, hoy se ha convertido en días.
5.3.- Entrega rápida y Lógica del negocio
Como describimos anteriormente, la capacidad de innovar, probar y lanzar productos al mercado
con rapidez, adaptarlos y perfeccionarlos rápidamente es el ideal muy buscado por la empresa
digital de hoy en día. Varias empresas de tecnología y nuevas empresas se han beneficiado de
esta perspectiva, trayendo productos y servicios disruptivos rápidamente al mercado. Sin
embargo, las empresas típicas de hoy en día poseen sistemas centrales (sistemas que respaldan
sus operaciones principales) que simplemente no poseen las características necesarias para
satisfacer esta necesidad de rapidez y agilidad, sus ciclos de desarrollo y liberación están en el
orden de meses, no de horas y días demandados por el mundo digital.
En general, la arquitectura de microservicios de hoy surgió de esta necesidad, es decir, la
necesidad de desarrollar, implementar, cambiar servicios (o API) rápidamente para respaldar los
negocios digitales de hoy. Sin embargo, exploremos un poco más el requisito esencial.

31
los canales actuales de atención al cliente necesitan una entrega rápida de servicios; al mismo
tiempo, los principales sistemas centrales de la empresa tienen reglas de negocios complejas,
relaciones complejas con otros sistemas y exhiben una variedad de características adicionales
que inhiben el desarrollo rápido: monolítico y no modular, escasez de documentación y
habilidades de mantenimiento y soporte, construidas en un momento diferente a diferentes
principios de diseño relevantes para ese día, etc. Construir sus microservicios pequeños para
reemplazar la masa existente de funcionalidad corporativa no es una opción viable. Posiblemente
podría hacerlo, a un costo masivo y en un período de tiempo muy largo, momento en el cual
probablemente se habría visto afectado por su negocio. Incluso si, por algún milagro, hiciera eso,
introducirá una complejidad adicional que surge de la necesidad de administrar un patrimonio que
comprende una gran cantidad de servicios “pequeños” que evolucionan muy rápidamente.
Regresamos al punto señalado anteriormente: un nivel de complejidad es inseparable a su
negocio y esto está determinado por el entorno empresarial: factores tales como la naturaleza del
negocio, el entorno competitivo y regulatorio, el tamaño y la escala de su negocio etc. Esta
complejidad se traducirá en los sistemas que soportan el negocio, es decir, en la complejidad de
las reglas comerciales, las entidades de datos y las relaciones entre las entidades de datos, y se
reflejará en su colección de API o servicios. Por lo tanto, el mejor enfoque de diseño es reconocer
que no puede desechar esta complejidad, pero necesita crear un marco que introduzca la menor
cantidad de complejidad adicional, evitable.
Entonces, ¿cuál es el mejor enfoque para seguir adelante, dado que necesitamos respaldar dos
requisitos opuestos? Un requisito es la entrega rápida y el cambio de los servicios; el otro por el
mayor diseño medido y la entrega de requisitos necesaria para entender el camino a través de la
complejidad del negocio.
El punto crucial, por lo tanto, es que estos dos mundos, uno para entrega rápida y otro para diseño
y entrega medidos y considerados, deben coexistir. Aquí es donde entra en juego las diferentes
velocidades de las tecnologías de información. Una arquitectura de tecnologías de información
de diferentes velocidades puede ponerse en servicio para permitir a las empresas desarrollar sus
capacidades de atención al cliente a alta velocidad mientras desacoplan los sistemas heredados,
para lo cual se ofrece un enfoque mucho más deliberado y considerado. y los ciclos de liberación
son esenciales, lo que les permite proceder a su propio ritmo.
Estos dos mundos deben estar débilmente acoplados, pero obviamente no completamente
separados. Creemos que la forma en que se unen los dos mundos es a través de la integración
adecuada. La integración entre los dos mundos se debe reflejar a través de una construcción
arquitectónica y de diseño que muestra cómo se los abarca de una manera que permite un
acoplamiento suelto al tiempo que preserva la integridad y la cohesión. Existe un modelo de
servicio se adapta adecuadamente a los dos estilos de servicios. Los servicios que se construyen
de forma considerada y medida para satisfacer las necesidades de sus sistemas centrales, así
como las API digitales de entrega rápida, se ajustan a este requisito (Xiao, 2016).
5.4.- Un modelo de servicio para la arquitectura de diferentes velocidades
Como describimos anteriormente en este documento, un modelo de servicio es una construcción
de organización donde los "servicios" o "API" se describen en el modelo, que es una taxonomía
de los tipos de servicio y las relaciones entre ellos.

32
A continuación, un modelo de servicio, que tiene sus raíces en el modelo de servicio SOA, pero
modificado para adaptarse a las necesidades digitales actuales.

FIGURA 7: Ejemplo de un modelo de servicio.

Fuente: (Xiao, 2016).

Capa Descripción
Los Servicios de entidad están diseñados para manejar datos persistentes y administrar
Servicios todas las funciones asociadas, como el almacenamiento y la recuperación, el bloqueo y la
de administración de transacciones; es decir, los servicios de CRUD. Dichos servicios
entidad administrarán una única entidad de datos, encapsulando sus operaciones CRUD más la
lógica comercial asociada.

Los servicios de negocio representan servicios sin estado que implementan directamente la
Servicios capacidad de servicio comercial y proporcionan valor comercial. Por lo general, los servicios
de de negocio son de una granularidad gruesa, encapsulan los datos y la lógica empresarial
negocio necesarios para ofrecer un resultado empresarial. Estos servicios pueden consumir servicios
de entidad u otros servicios comerciales.

Los servicios técnicos brindan apoyo a las funciones de negocios, en lugar de entregar
directamente los resultados de negocios. Estos pueden ser servicios de utilidad de negocios
Servicios (almacenamiento de documentos, correo y funciones de impresión), servicios de utilidad
técnicos técnica (por ejemplo, registro, manejo de excepciones técnicas), etc. Los servicios técnicos
pueden vincularse para formar servicios de negocios compuestos, utilizando el ensamblaje
del servicio o la orquestación de procesos.

Servicios Los Servicios de proceso son servicios que representan la totalidad o un fragmento de uno
de de los procesos de negocios de la organización. Estos pueden consumir otros servicios de
procesos procesos de negocios, servicios de negocios, servicios de entidades y servicios técnicos.
de
negocio
33
 Un servicio construido para aprovisionar un requisito de frontend particular; Por lo general,
Backend está compuesto por servicios de negocios, entidad, servicios técnicos para un propósito en
para particular del usuario. Puede considerarse como una forma especializada de servicio
Frontend comercial, construida para un propósito de frontend particular.

TABLA 4: Tipos de servicio según su funcionalidad.

Fuente: (Xiao, 2016).

El tipo de servicio Backend para Frontend (BEF) es un servicio susceptible de una rápida rotación,
creado para satisfacer las necesidades de la era digital. Los servicios de tipo BEF son
"desechables", con el desarrollador construyendo un nuevo BEF en lugar de una versión
actualizada cuando sea necesario.
Estos servicios BEF se basan en una base proporcionada por otros tipos de servicios: negocios,
procesos de negocios, técnicos, estos servicios siempre deben estar disponibles. En
contraposición a los BEF, los servicios de negocio "tradicionales" por mencionar SOA necesitan
un enfoque de desarrollo más medido; especialmente en el caso de servicios expuestos fuera de
los sistemas centrales de una empresa compleja. Los servicios BEF forman parte de un
paradigma completo, que generalmente incluye DevOps y desarrollo ágil, pruebas
automatizadas, ciclos de entrega rápidos e incrementales.
Para que este modelo de servicios tenga éxito, los principales servicios deben estar disponibles,
No se puede esperar seis meses para un par de servicios de negocio que requieran los servicios
BEF. Lo que debe suceder para el éxito de este modelo es la disponibilidad; Los servicios fuente
que requiere los servicios BEF y servicios de proceso de negocio deben existir. La empresa debe
invertir en "renovar" la lógica de negocio de los servicios existentes, re factorizándolos para
deshacerse de la deuda técnica asociada con el patrimonio. Esta actividad puede llevarse a cabo
antes de la necesidad de una funcionalidad empresarial específica, como una actividad
fundamental de fondo.
Si la organización ya posee una infraestructura tecnológica SOA madura, se debe continuar
usando la infraestructura SOA y los protocolos API más nuevos y más simples (REST / HTTP)
para las nuevas API digitales. Si, por otro lado, la empresa es relativamente nueva en la
administración de servicios, entonces es recomendable utiliza la arquitectura MSOA con su
respectivo marco de trabajo y los protocolos de administración de API para construir los nuevos
servicios de acuerdo a los tipos de servicios del modelo sugerido en la figura 7.

34
 6 CONCLUCIONES

En el desarrollo del presente documento, se realizó a un análisis comparativo entre el desarrollo

basado en la arquitectura orientada a servicios y microservicios, se pudo identificar que, aunque
ambas arquitecturas están basadas en los servicios, tiene bastantes diferencias a la hora de ser
desarrolladas, esto conlleva a que la arquitectura SOA este un poco anticuada respecto a las
implementaciones actuales de MSOA.
SOA intenta integrar las diferentes aplicaciones de una empresa, favoreciendo la interacción entre
estas. La interacción entre las aplicaciones se da a través de un canal en común, en este caso el
Enterprise Service Bus (ESB), que se encarga de recibir y enviar las diferentes peticiones de
servicios, transformándolos o guardando un registro de ejecución dependiendo lo requerido. SOA
utiliza el protocolo WSDL que está basado en XML para definir todos los detalles de la estructura
de los mensajes en la comunicación cliente servidor. La arquitectura orientada a los
microservicios (MSOA), está basada en servicios que son pequeñas aplicaciones con su propia
tecnología y plataforma, estas se comunican a través de mecanismos, cada microservicio se basa
en las necesidades del negocio. la necesidad de utilizar microservicios es debido a que estas nos
proporcionan una buena escalabilidad y bajo acoplamiento, existen diferentes tipos de
implementación de acuerdo a las tecnologías que se estén utilizando. MSOA está conformada
por los componentes: Servicio de enrutamiento, balanceador de carga, circuit breaker y logs
centralizados, para la integración de los servicios MSOA se basa en un estilo coreográfico.
De acuerdo al ciclo de sobreexpectación de gartner podemos situar a las dos arquitecturas en
diferentes etapas, SOA se encuentra en la etapa de consolidación y MSOA se encuentra en la
etapa de expectativas sobredimensionadas, en este sentido es que se comparan ambas
arquitecturas. Ambos tienen al “servicio” como su núcleo y sus componentes son parecidos, pero
tienen diferencias en cuanto a la granularidad, la integración y los protocolos. Se compararon
ambas arquitecturas con sus diferentes características y se encontraron las siguientes diferencias
y semejanzas: MSOA tiene un mayor costo de despliegue comparado contra SOA, SOA no tiene
una granularidad definida para su implementación mientras que MSOA sugiere una granularidad
fina, SOA proporciona una mejor abstracción de la interfaz y mejor manejo de protocolos, para la
interacción fuera del servicio las MSOA proporciona una mayor independencia respecto a SOA,
de acuerdo al alcance de la aplicación es que MSOA es más apropiado que SOA, en el apartado
de integración SOA puede interactuar con diferentes protocolos, mientras que MSOA necesita
que el protocolo sea el mismo en ambas direcciones. En tiempos de respuesta SOA es 10 % más
rápido que MSOA, MSOA tiene ventaja en el apartado de equipos ya que SOA depende de
diferentes recursos de acuerdo al requerimiento del servicio, MSOA es más apropiado para
sistemas escalables mientras que SOA es apropiado para aplicaciones empresariales fijas. Los
microservicios tienen ventajas y desventajas; lo positivo es que son independientes, pueden ser
escalables, utilizan pequeños equipos de desarrollo y tienen un mantenimiento fácil, el lado
negativo es que las pruebas son complicadas, requiere un esfuerzo adicional para implementar
la integración de servicios y la complejidad del sistema distribuido. SOA también presenta
ventajas tales como la optimización de los procesos de negocio, se tiene un mayor control sobre
los servicios ejecutados y permite una personalización de los servicios, en contra SOA se hace
costosa, se depende de un único ESB e implica conocer los procesos del negocio.

35
Con la clara distinción de MSA de SOA, ahora es posible deducir las implicaciones en el desarrollo
de ambas arquitecturas, estas implicaciones nos sugieren que existe una mayor cohesión de los
servicios en MSOA, la fragmentación de los servicios es más flexible en SOA, existe un
comportamiento menos complejo respecto a los servicios en MSOA, SOA puede implementar
diferentes tipos de controladores mientras que MSOA solo uno, para la integración de los
servicios SOA utiliza la orquestación y MSOA puede utilizar tanto la orquestación como la
coreografía y MSOA deriva el modelado y gobernanza de los servicios al equipo de desarrollo.
Estas implicaciones proporcionan una visión general inicial de los criterios que deben
considerarse al aplicar SOA y MSA.
Es importante aplicar buenas prácticas en las arquitecturas SOA y MSOA estas deben estar
orientadas a mantener el sistema y la solución flexible, eficiente y escalable. Ambas arquitecturas
deben poner como prioridad la velocidad de desarrollo y la comprensión de la lógica de negocio
de la empresa, se sugiere utilizar un modelo en el que los servicios están divididos en grupos con
el objetivo de poder brindar servicios en un tiempo corto y contemplando un buen modelo de
arquitectura. si se tiene la opción de desarrollar una arquitectura desde el inicio es recomendable
utilizar MSOA para su implementación, en caso que la empresa ya utiliza SOA, se debe utilizar
los protocolos actuales para las nuevas implementaciones.

36
 7 Bibliografía

 Alejandro, H. T. (2003). Los sistemas de información: Evolución y desarrollo.

 Arceo. (2006). SOA levanta vuelo.
 Barcia, R., Brown, K., & Osowski, R. (2019). Guía para punto de vista de microservicios.
IBM.
 Birrell, A., & Nelson, B. j. (1984). Implementing Remote Procedure Calls. ACM.
 Czapski, M. (2009). OPEN ESB. LOGICOY.
 Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Prentice
Hall International.
 Gartner. (1995). El Hype Cycle de Gartner.
 Gartner. (2010). Hype Cycle for Application Architecture.
 Gonzalez, L. (2009). Servicios Web y Orquestacion. WillyDev.
 IBM. (2019). IBM webservices. Obtenido de
https://www.ibm.com/developerworks/ssa/webservices/newto/index.html
 J, C. (2009). Service Oriented Architecture.
 Krafzig, D. (2005). ENTERPRISE SOA.SERVICE-ORIENTED ARCHITECTURE BEST
PRACTICES. PRENTICE HALL.
 Lafon, Y. (2002). World wide web. Obtenido de web services: https://www.w3.org/2002/ws/
 Microsoft. (2019). Orquestación de microservicios y aplicaciones de varios contenedores
para una alta escalabilidad y disponibilidad. Obtenido de https://docs.microsoft.com/es-
es/dotnet/standard/microservices-architecture/architect-microservice-container-
applications/scalable-available-multi-container-microservice-applications
 Nelson, B. a. (1984). Implementing Remote Procedure Calls.
 Newman, S. (2015). Building Microservices. O'Reilly Media.
 Reynoso. (2006). Introducción a la Arquitectura de Software.
 Richards, M. (2015). Microservices vs. Service-Oriented Architecture. O' REILLY.
 Richardson, C., & Smith, F. (2016). MICROSERVICES from design to deployment.
NGINX.
 Romero. (2005). ARQUITECTURA DE SOFTWARE, ESQUEMAS y SERVICIOS. Softel.
 Techtaget.com. (2018). Qué es la arquitectura de microservicios. Obtenido de
https://www.evaluandosoftware.com/que-es-la-arquitectura-de-microservicios/
 wikipedia. (2019). Arquitectura orientada a servicios. Obtenido de
https://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
 Wikipedia. (2019). Servicios web. Obtenido de https://es.wikipedia.org/wiki/Servicio_web
 Xabier Larrucea, & Santamaria, I. (2017). Microservices. united states.
 Xiao, Z. (2016). Reflections on SOA and Microservices . International Conference on
Enterprise Systems.

37
38