Universidad de las Fuerzas Armadas ESPE

Unidad de Educación a Distancia

Tecnologías de la Información y Comunicación

Ingeniería en Software II

Tema: Realización Actividad de Aprendizaje N°1

Integrantes: Diego Alejandro Guzmán Cajas

Raúl Alexander Meneses Ortiz
Steven Santiago Jaramillo Ortega,
Bryan Steven Cárdenas Auquilla,
José Geovanny Mejía Ramos

Tutor: Ing. Efraín Rodrigo Fonseca Carrera

2021-2023
 Actividad Entregable 1
Esta actividad tiene como propósito llevar a cabo una investigación sobre la
arquitectura de software de dos sistemas comerciales actuales, en la que se
identifique y describa sus componentes y se establezca similitudes y
diferencias.

Tema: Arquitecturas de Software de Sistemas Comerciales

INTRODUCCIÓN

OBJETIVO
Descripción de la actividad

1. Lleve a cabo una investigación bibliográfica y/o exploratoria de fuentes fiables

(Criterio de expertos, bases digitales, libros, artículos actuales, sitios web fiables
con información actualizada, blogs, etc.) sobre las arquitecturas de software de
dos sistemas comerciales actuales.

Primer Sistema Comercial:

 Spotify
Es un software comercial, cuyo propósito es la distribución de música mediante una
plataforma o aplicación que permite a los usuarios acceder a contenido multimedia.
La aplicación sigue un modelo freemium: Los servicios básicos están disponibles de
forma gratuita, mientras que las características avanzadas necesitan de una cuenta
Premium. Esta cuenta Premium permite la reproducción sin anuncios, en alta calidad
y, para las versiones móviles, la elección de la canción a reproducir en cada
momento. La versión gratuita para dispositivos móviles sólo permite la reproducción
de listas o el contenido disponible de un artista de forma aleatoria. El 70% de los
beneficios que se obtienen se pagan en forma de royalties a artistas y discográficas,
mientras que el 30% restante queda para la compañía.

Actualmente, está disponible en 58 países en el continente europeo, América y

Oceanía. Cada día se añaden unas 20000 canciones, que están disponibles tanto en
la aplicación de escritorio para PC y Mac como para dispositivos móviles con
sistema operativo Android, iOS, Symbian, Blackberry OS, Windows Phone, Windows
Mobile y WebOS.

Arquitectura de software
Spotify es una empresa que ha ido evolucionando y aplicando el concepto de que si
una empresa desea una moverse rápido y mantenerse innovadora en un mercado
altamente competitivo requiere una arquitectura que pueda escalar.
Partiendo de este concepto la empresa planteo un ciclo de desarrollo de arquitectura
basado en 3 etapas que son:

Requerimientos: Spotify planteo un modelo de software centrado en un público

global, en el cual deberían atender las necesidades de un gran número de usuarios
bajo una misma plataforma, es decir, tendrían un gran tráfico de usuarios dentro de
su aplicativo y servidores, por lo cual estos debían ser capaces de soportar un gran
número de usuarios en una misma cantidad de tiempo, con el mejor rendimiento
posible. En la actualidad esta plataforma atiende a más de 75 millones de usuarios
activos por mes, con una duración promedio de sesión de 23 minutos, mientras
ejecuta roles comerciales increíblemente complejos detrás de escena.

Diseño: Ante dichas necesidades Spotify llegó a la conclusión de que, para poder
dar solución a los requerimientos establecidos y a su vez poder escalar a cientos de
millones de usuarios, debía plantar un sistema que permita escalar los componentes
de forma independiente. Y fue así que decidió construir una arquitectura de micro-
servicios con equipos full-stack autónomos a cargo, para evitar el infierno de
sincronización dentro de la organización. Estos equipos son autónomos y su misión
no se superpone con la misión de otros equipos. Y este diseño se adaptó de forma
óptima que al día de hoy cuenta con alrededor de 90 equipos, 600 desarrolladores y
5 oficinas de desarrollo en 2 continentes que crean el mismo producto.
La arquitectura de software basada en micro-servicios de spotify le permite reducir
drásticamente las grandes fallas ya que le permiten tener una gran cantidad de
servicios inactivos al mismo tiempo sin que los usuarios lo noten, debido a que los
servicios individuales que podrían fallar no están haciendo demasiado, por lo que no
pueden arruinar la experiencia de usar Spotify.

Documentación: Spotify tiene una infraestructura de funcionamiento basada en

Debian y software abierto en su mayor parte. Su arquitectura se centra en micros-
servicios y su motor trabaja en base a unos cien servicios, compuestos entre
pequeños y simples y que se basan en leguaje Java y Python. Los servicios se
comunican mediante un protocolo propio denominado ‘Hermes’, el cual está basado
en mensajes y escrito en ZeroMQ y Protobuf (datos multiplataforma de código
abierto y gratuito que se utiliza para serializar datos estructurados). Sin embargo,
algunos servicios antiguos de la plataforma trabajan mediante http y XML/JSON.
Para el almacenamiento el software radica bajo servidores y tiene acceso a través
de la nube. Y a su vez cuentan con un almacenamiento en Amazon S3 y se utiliza
una caché de ellos en el motor de Spotify.

Para el lado de los usuarios o clientes, estos mantienen una conexión permanente a
un servicio llamado “accesspoint”, que trabaja mediante un router muy potente,
permitiendo la comunicación con los servicios necesitados. El protocolo entre los
clientes y accesspoint es propio de spotify, y funciona mediante un socket
multiplexado sobre TCP. Este maneja un lenguaje en C++. El objetivo principal del
Accesspoint es manejar el estado de la autenticación, login del usuario, tasa de
enrutamiento, entre otros.
Un diagrama representativo de la arquitectura de software de Spotify es el siguiente:

Figura 1: Arquitectura de software de Spotify.

 Fuente: (Aguado, 2015)

Todos los usuarios de la aplicación de escritorio, móvil y embebida (libspotify)

comparten un código base escrito en C++. Cada cliente utiliza este núcleo para
proveer la interfaz de usuario, que se traduce al código utilizado por cada
plataforma.
De igual manera la arquitectura de software de Spotify analiza el audio de las
canciones, el cual tiene tres fuentes: caché, P2P y los servidores de
almacenamiento de la compañía, siendo la primera la más utilizada. Y su vez e l
audio puede estar codificado en múltiples formatos: Ogg Vorbis 96, 160 y 320 000 y
MP3 320 000. Es el cliente quien elige el más adecuado. Debido al gran contenido
musical del que se dispone, la compañía no puede mantener todo. Por ello, se llegan
a acuerdos con las compañías discográficas, que almacenarán los archivos en sus
servidores y se adaptarán al formato utilizado por Spotify.

Figura 2: Fuentes de audio de Spotify

Fuente: (Aguado, 2015)

Segundo Sistema Comercial:

 Salesforce
Es un software comercial de baja demanda, que se basa en una plataforma de
gestión de relaciones con los clientes (CRM) mediante la gestión de marketing,
ventas, comercio, servicios y TI.
Sus servicios se basan en la nube mediante una plataforma multiusuario, dicha
plataforma mantiene tecnología de metadatos (conjunto de datos que describen el
contenido informativo de un recurso, de archivos o de información de los mismos), y
trabajan bajo servicios de datos, inteligencia artificial y API para el desarrollo.

Arquitectura de Software
La arquitectura de Salesforce se basa en un patrón de 2 arquitecturas de software
que son: arquitectura en capas y arquitectura basada en eventos. En la primera
arquitectura los componentes del software o aplicación están organizados en capas
horizontales, en este caso encontramos 3 capas de distribución de componentes
que son:
1. Aplicaciones (Diferentes servicios o componentes del sistema)
2. Plataforma (Base del programa que conecta las aplicaciones con el servidor)
3. Salesforce (Servidor que resguarda la información y datos de los clientes)

Figura 3: Arquitectura en capas de Salesforce

Fuente: (TRAILHEAD, 2021)

Esta arquitectura es la base de toso los procesos del software y permiten una
funcionalidad optima del aplicativo a nivel de clientes y servidores. Sin embargo,
para entablar una comunicación más estratégica con los usuarios, Salesforce
plantea una segunda arquitectura de software basada en eventos.

Esta arquitectura basada en eventos o event-based pattern, consiste en

componentes de procesamiento de eventos de un solo propósito que escuchan los
eventos y los procesan asincrónicamente. La arquitectura impulsada por eventos
construye una unidad central que acepta todos los datos y luego los delega a los
módulos separados que manejan el tipo particular.

En el caso de Salesforce el patrón basado en eventos permite la entrega de

notificaciones personalizadas de forma segura y ampliable desde fuentes externas.
Permitiendo monitorear y controlar los cambios entre los diversos aplicativos, lo cual
se conoce como modelo publicador-suscriptor, en donde Un remitente difunde un
mensaje que uno o varios receptores capturan, lo cual permite una conexión optima
entre las diferentes API del software (Capa de aplicaciones) y los clientes.

Ejemplos de patrón de eventos en el software Salesforce

1. Desde la plataforma hacia aplicaciones externas.

Como Salesforce es un software basado en CRM (gestión de relaciones con
los clientes), este permite que las compañías puedan conectar sus productos
a los clientes, y para que estos puedan recibir sus productos, el aplicativo
necesita de proveedores que lleven los productos a los usuarios. Partiendo de
este concepto, el aplicativo debe ser capaz de comunicarse con aplicativos de
 proveedores y de esta manera tener un envió de producción óptimo. La
aplicación externa escucha los eventos de plataforma. Cuando se cierra una
oportunidad, se activa un desencadenador, que forma parte de una aplicación
de pedidos de productos de Salesforce, y se publica un mensaje de evento de
plataforma. Cada aplicación de proveedor recibe una notificación del evento.
El proveedor responsable de enviar el producto específico crea el envío.

Figura 4: Eventos desde una plataforma a aplicaciones externas.

Fuente: (TRAILHEAD, 2021)

2. Desde aplicaciones externas hacia la plataforma.

Partiendo del ejemplo anterior, si en algún caso un cliente desea devolver un
producto adquirido a un proveedor. Un sistema externo envía solicitudes de
devolución de mercancía a Salesforce para su procesamiento. El sistema
externo publica un evento de plataforma para alertar a Salesforce de la
devolución de la mercancía. Un proceso de escucha de eventos
(desencadenador) de Salesforce recibe el evento y realiza algunas acciones.
 Figura 5: Eventos desde aplicaciones externas hacia la plataforma.
Fuente: (TRAILHEAD, 2021)

3. Desde una plataforma hacia otra plataforma

Un ejemplo de este patrón de eventos es cuando se asigna un prospecto en
Salesforce, se activa un desencadenador de prospecto y se comprueban las
oportunidades abiertas y los casos relacionados con el propietario del
prospecto. En función de los registros relacionados, el desencadenador
publica un evento que es recibido por una aplicación de Salesforce. De
acuerdo con la información del evento, la aplicación reasigna el prospecto y
crea una publicación de Chatter.

Figura 6: Eventos desde plataforma hacia plataforma

Fuente: (TRAILHEAD, 2021)
Estos son algunos casos del software Salesforce, en donde se aplica una
arquitectura de software basada en eventos.
En conclusión, el software Salesforce trabaja mediante dos arquitecturas de software
debido a las API que usa la aplicación para ofrecer los diferentes servicios a los
clientes. En la primera arquitectura de capas se encuentran toda la base del
programa y su funcionalidad en los diferentes niveles del aplicativo y en la segunda
arquitectura basada en eventos se encuentran los mecanismos de comunicación
que tiene el software con los diferentes usuarios y plataformas que pueden llegar a
tener las empresas.

2. Identifique los componentes de cada una de las arquitecturas identificadas

e indague su función individual, así como en conjunto.

La arquitectura de software basada en micro-servicios de Spotify:

Función Individual:

Los microservicios nacen con la idea primordial de dividir los sistemas en partes
individuales, permitiendo que se puedan tratar y abordar los problemas de manera
independiente sin afectar al resto.

Cada microservicio es un código que puede estar en un lenguaje de programación

diferente, desempeña una función específica. Los microservicios se comunican entre
sí a través de APIs, y cuentan con sistemas de almacenamiento propios, esto evita
la sobrecarga y caída de la aplicación.

Para cubrirlas cada una de las necesidades, se utilizan microservicios, los cuales
tienen una serie de características que nos permiten desarrollar el producto de forma
ágil.

Figura 7: Microservicios- características.

Fuente (Aprende Arquitectura, 2019)
A continuación, se las describirá a cada una de ellas.
 El servicio de configuración: se encarga de conectar entre sí el resto de los
servicios, de forma que podemos gestionar desde un único punto la
configuración del resto de microservicios sin necesidad de afectar al
funcionamiento general del producto.
 El servicio de descubrimiento: de encarga de detectar todos los puntos de
conexión existentes entre los distintos servicios, para que se puedan
comunicar entre sí.
 El balanceador de carga: recibe las peticiones y comprueba por cada una
qué instancia del servicio deseado es la más apta para atenderla.
 El circuit breaker: evita la propagación de los fallos de un microservicio a
otro, de modo que minimiza la pérdida de servicio de cara al usuario.
 El Edge Service: es la puerta de entrada a todos los endpoints que provee la
aplicación para su servicio (es la IP que se expone).
 El log management: se encarga de centralizar la gestión de los logs. 

Como se organiza el servicio de Spotify dentro de la arquitectura:

Para desarrollar este servicio, Spotify dispone de más de 90 equipos full-stack
autónomos, los cuales se encargan cada uno de una característica a desarrollar,
abarcando de esta manera a cada una de las áreas necesarias para desarrollar la
característica.
A continuación, podremos observar cómo se realiza ese reparto de tareas:

Figura 9: Arquitectura-organización de Spotify.

Fuente: (Aprende Arquitectura, 2018)

Función en Conjunto:
Una arquitectura de microservicios funciona con un conjunto de pequeños servicios
que se ejecutan de manera autónoma e independiente.
 Figura 10: Arquitectura de microservicios.
Fuente: (Decide, 2019)

A continuación, un ejemplo del funcionamiento, donde los usuarios se conectan a los

microservicios, que suelen ser contenedores Docker con alguna funcionalidad. Esto
mediante los balanceadores de carga, que eligen la manera más eficiente de repartir
las peticiones, las cuales se conectan con la BD.

Figura 11: Usuarios conectados a Microservicios.

Fuente: (Decide, 2019)

La arquitectura de software basada en EVENTOS de SALEFORCE:

La arquitectura basada en eventos, como su nombre lo indica, los sistemas están

interconectados a realizar sus funciones de acuerdo a los eventos que se presenta y
se puedan tratar y abordar de manera independiente independiente cada evento sin
afectar al resto.
La idea de esta arquitectura es que cada evento tenga una sola tarea relacionada
con el negocio, así como en el ejemplo anterior, si un cliente quiere devolver un
producto este no afectara a los demás eventos de ventas, marketing, etc. con
sistemas de almacenamiento propios, esto evita la sobrecarga y caída de la
aplicación.

En esta arquitectura se muestra componentes como son los generadores, paquete

de información o mensaje, la plataforma de la empresa, el conector de eventos o
canal, publicador, suscriptor y el consumidor. A continuación, se describe cada uno
de ellos con su función Individual, como colectiva:

Función Individual:

 Generador: este es el encargado de generar los distintos eventos que se

produce en el sistema. En Salesforce la aplicación tiene diferentes tipos de
sucesos que están aplicados en slack que contiene servicios como ventas,
marketing, comercio, analíticas, plataformas, etc.
 Paquetes/Información: Estos son los mensajes que generan los
generadores de la aplicación, y que contienen la información del evento, para
después se envían a través de paquetes hacia la plataforma.
 Plataforma: Es el encargo de los componentes de mensajería, donde recibe
el mensaje de los paquetes que envió el generador, para informar a las otras
partes y luego hacer un procesamiento de el para genere otro evento para el
consumidor o para la misma plataforma.
 Canal/Conector de Eventos: Es donde se realiza la comunicación mediante
el enrutamiento de los mensajes con el generador, la plataforma y los
consumidores.
 Publicador: Es parte de la mensajería, donde tanto como el generador,
consumidor o la plataforma, envía el mensaje a los diferentes destinatarios, o
suscriptores.
 Suscriptor: Es la otra parte de la mensajería, donde recibe la información
que el publicador publica y donde cada evento esta suscrito a un
administrador, para enviarle la información del suceso.
 Consumidor: Son los componentes que están interesados en los eventos,
donde pueden llegar directamente al consumidor final o al productor.

Función en Conjunto:

Como vimos Salesforce tiene dos arquitecturas, en ella actúa la de tres capas y la
arquitectura orientada a eventos, en donde cada capa tiene que actuar el publicador
y suscriptor para el envío de mensajes.

La primera capa actúa los componentes de generador e información, actúan

mediante los eventos creados por el generador de la aplicación, en ella va a viajar el
mensaje que después se transmite a la otra capa donde está la plataforma o el
administrador de mensajes.
En la segunda capa actúa la plataforma para administrar los mensajes y crear
nuevos eventos o mensajes que pueda notificar al consumidor, donde el consumidor
no debe tener conocimiento de quienes generan los eventos. Además, la plataforma
da soporte a los servicios, y administra el canal de acuerdo a publicador/suscritor.

En la tercera capa esta la BD junto con el consumidor, de manera que los procesos
que realice, se vayan generando en la Base de datos, y donde diagnostica el evento
y notifica al servidor o al cliente.

Salesforce nos da un claro ejemplo de cómo se menaje, la aplicación, donde un

cualquier evento, por ejemplo, ventas, genere un evento de compra, venta,
devolución, etc. Y donde cada publicación llega donde la plataforma de modo que
administre y genere estadísticas del negocio, luego donde notifique y se registre a
cada uno de las partes, para generar un servicio de calidad.

3. Establezca similitudes y diferencias entre las arquitecturas, a nivel

conceptual, así como a nivel de elementos.

Similitudes y diferencias a nivel conceptual

Similitudes Diferencias
 Ambas arquitecturas basadas en  Los eventos son la estructura
eventos son flexibles ya que central de la solución. Su
estas se adaptan a los cambios y distribución de roles es de forma
se pueden escalar de manera jerárquica.
independiente.  Desarrollo de aplicaciones
 Estos sistemas se enfocan distribuidas. La arquitectura de
muchas veces en decisiones capas para aplicaciones
empresariales ya sea de manera contables.
automática o manual.  En la arquitectura de capas es
 Sus componentes son capaces independiente cada una de las
de comunicarse entre capas. La interacción de los
componentes, ya sea en forma eventos depende de uno inicial
de eventos o entre capas. que informa a los siguientes para
procesarlos.
Similitudes y diferencias a nivel de elementos

Similitudes Diferencias
 Para comunicarse lo hacen en  Procesamiento de flujo de
forma horizontal así solo se elementos a través de una
comunican con su inmediata plataforma de transmisión de
capa o evento. datos. A través de capas realiza
 Su facilidad para desarrollar una descomposición funcional
aplicaciones y además de para mejorar su escalabilidad,
implementar un enfoque de utilización de recursos.
programación.  Toda su estructura se basa en
 Presentan un gran volumen de eventos, mientras que la otra
datos y velocidad para el IOT. estructura se basa en capas.
 Ambos son patrones de diseño  El enfoque que realiza siempre
que actúan en tiempo real y que es bajo eventos, desde producto
están listos para responder a al consumidor. Mientras que por
cualquier acción en respuesta a capas va desde una capa cliente
una orden dada. y pasa por varios procesos hasta
la capa de la base de datos.

4. Realice un video de máximo cinco minutos en el que se exponga la

investigación realizada, resaltando los hallazgos más representativos. En la
exposición debe participar cada uno de los miembros del equipo de trabajo
conformado.

5. Elaborar un informe por cada equipo de trabajo, con los siguientes

apartados: Caratula (donde conste el nombre de la institución,
departamento, carrera, número de grupo, integrantes, nombre del profesor,
fecha); Introducción; Objetivo; Desarrollo (describir paso a paso la
 investigación y resaltar la descripción de las arquitecturas y sus elementos,
y la comparación de estas a nivel conceptual y a nivel de componentes.

Conclusiones
Bibliografía:

Aguado, J. E. (2015). Implementación de una arquitectura para movilidad de

sesiones entre dispositivos. Madrid: Universidad Carlos III de Madrid.
Novoseltseva, E. (18 de Abril de 2020). apiumhub. Obtenido de apiumhub:
https://apiumhub.com/es/tech-blog-barcelona/los-microservicios/
salesforce. (2022). salesforce. Obtenido de salesforce:
https://www.salesforce.com/products/what-is-salesforce/
Spotify. (2022). Spotify. Obtenido de Spotify: https://www.spotify.com/bo/
TRAILHEAD. (2021). trailhead. Obtenido de trailhead:
https://trailhead.salesforce.com/es-MX/content/learn/modules/platform_events
_basics/platform_events_architecture
Decide. (3 de septiembre 2019). Arquitectura de microservicios. Recuperado de.
https://decidesoluciones.es/arquitectura-de-microservicios/

Aprende Arquitectura de Software. (27 de septiembre 2018). Arquitectura Spotify -

Microservicios. Recuperado de.
https://aprendearquitecturasoftware.wordpress.com/2018/09/27/arquitectura-spotify-
microservicios/