ESCUELA PROFESIONAL DE INGENIERIA DE

SISTEMAS E INFORMATICA

Área:
Ingeniería de Información
Docente:
Ing. Camilo Ernesto Suárez Rebaza
Ciclo:
VII
Integrantes:
Castillo Graus Rubén
Chirinos Carranza Luis
Cisneros Baca Benny
Lecca Reyna Edison
Sandoval Chauca Christian

Nvo. Chimbote 2018

 ÍNDICE
1. NEGOCIO ............................................................................................................................................... 2
1.1. BPM ................................................................................................................................................ 2
1.2. BPMN ............................................................................................................................................. 2
2. APLICACIONES .................................................................................................................................... 3
2.1. PROGRAMACIÓN AOP ...................................................................................................................... 3
2.2. MICROSERVICIOS ............................................................................................................................. 5
2.3. FRAMEWORK SPRING ..................................................................................................................... 11
2.4. PROGRAMACIÓN REACTIVA ........................................................................................................... 14
2.5. RESPONSIVE DESIGN ...................................................................................................................... 16
2.6. UX-DESIGN ................................................................................................................................... 17
2.7. PROGRAMACIÓN SERVERLESS ........................................................................................................ 19
3. GESTIÓN DE DATOS ......................................................................................................................... 21
3.1. BASES DE DATOS RELACIONALES ................................................................................................... 21
3.2. BASES DE DATOS NO RELACIONALES .............................................................................................. 21
3.3. BASES DE DATOS EN MEMORIA ....................................................................................................... 22
3.4. IN-MEMORY DATAGRID ................................................................................................................ 23
3.5. IN-MEMORY DATAFABRIC ............................................................................................................. 24
4. PLATAFORMA TECNOLÓGICA ..................................................................................................... 25
4.1. CABLEADO ESTRUCTURADO ........................................................................................................... 25
4.2. GUÍA DE DISEÑO DE REDES DE CAMPOS CISCO.............................................................................. 25
4.3. METODOLOGÍA TOPDOWN DE CISCO ........................................................................................ 26
4.4. CENTRO DE DATOS ......................................................................................................................... 27
4.5. HIPERCONVERGENCIA .................................................................................................................... 29
4.6. CLOUD COMPUTING ....................................................................................................................... 29
4.7. SOFTWARE CLOUD COMPUTING ..................................................................................................... 30
4.8. CONTENEDORES DOCKER Y KUBERNETS ....................................................................................... 31
5. BIBLIOGRAFÍA .................................................................................................................................. 34

1
1. Negocio
1.1. BPM

BPM es la abreviatura de Business Process Management que significa Gestión de

Procesos de Negocio. BPM es un enfoque de manejo adaptable, desarrollado con el fin
de sistematizar y facilitar los procesos individuales de negocio complejos, dentro y fuera
de las empresas (Heflo, 2015).

BPM tiene como objetivo, traer a colación la información relevante sobre cómo los
procesos se ejecutan de manera que se puedan hacer mejoras y para que los procesos
se puedan manejar, permitiendo una mejor toma de decisiones y visión de negocios
como un todo (Club-BPM, 2009).

El BPM es el entendimiento, visibilidad, modelado y control de los procesos de negocio

de una organización. Un proceso de negocio representa una serie discreta de
actividades o pasos de tareas que pueden incluir personas, aplicativos, eventos de
negocio, tareas y organizaciones (Heflo, 2015).

Para soportar esta estrategia es necesario contar con un conjunto de herramientas que
den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de
herramientas son llamadas Business Process Management Software (BPMS), y con ellas
se construyen aplicaciones BPM. Normalmente siguen una notación común,
denominada Business Process Modeling Notation (BPMN). Otras poseen una notación
propia y son capaces de generar código (Club-BPM, 2009).

1.2. BPMN

Business Process Model and Notation (BPMN), en español Modelo y Notación de

Procesos de Negocio, es una notación gráfica estandarizada que permite el modelado
de procesos de negocio, en un formato de flujo de trabajo (workflow). BPMN fue
inicialmente desarrollada por la organización Business Process Management
Initiative (BPMI), y es actualmente mantenida por el Object Management Group (OMG),
después de la fusión de las dos organizaciones en el año 2005 (Wikipedia, 2018).

El modelado en BPMN se realiza mediante diagramas muy simples con un conjunto muy
pequeño de elementos gráficos. Con esto se busca que para los usuarios del negocio y
los desarrolladores técnicos sea fácil entender el flujo y el proceso. Las cuatro categorías
básicas de elementos son (Wikipedia, 2018):

2
 Objetos de Flujo: Eventos, Actividades, Rombos de control de flujo (gateways); (Club-
BPM, 2009)

Objetos de Conexión: Flujo de Secuencia, Flujo de Mensaje, Asociación;

Carriles de nado (swimlanes): Piscina, Carril;

Artefactos: Objetos de Datos, Grupo, Anotación.

Estas cuatro categorías de elementos nos dan la oportunidad de realizar un diagrama

simple de procesos de negocio (en inglés Business Process Diagram, BPD). En un BPD
se permite definir un tipo personalizado de objeto de flujo o un artefacto, si con ello se
hace el diagrama más comprensible (Club-BPM, 2009).

(Wikipedia, 2018)

2. Aplicaciones
2.1. Programación AOP

Paradigma de programación relativamente reciente cuya intención es permitir una

adecuada modularización de las aplicaciones y posibilitar una mejor separación de
responsabilidades (Obligación o correspondencia de hacer algo) (Wikipedia, 2018).

En AOP, a los elementos que son transversales a la estructura del sistema y se pueden
modularizar gracias a las construcciones que aporta el paradigma se les
denomina aspectos (aspects) (Wikipedia, 2018).

3
 El principal objetivo de la POA es la separación de las funcionalidades dentro del sistema
(Wikipedia, 2018):

 Por un lado funcionalidades comunes utilizadas a lo largo de la aplicación.

 Por otro lado, las funcionalidades propias de cada módulo.
 Cada funcionalidad común se encapsulará en una entidad.

Conceptos Basicos:

 Aspecto (en inglés Aspect) es una funcionalidad transversal (cross-cutting) que se

va a implementar de forma modular y separada del resto del sistema. El ejemplo
más común y simple de un aspecto es el logging (registro de sucesos) dentro del
sistema, ya que necesariamente afecta a todas las partes del sistema que generan un
suceso (Ruelas, 2017).
 Punto de Cruce o de Unión (en inglés Join point) es un punto de ejecución dentro
del sistema donde un aspecto puede ser conectado, como una llamada a un método,
el lanzamiento de una excepción o la modificación de un campo. El código del
aspecto será insertado en el flujo de ejecución de la aplicación para añadir su
funcionalidad (Ruelas, 2017).
 Consejo (en inglés Advice) es la implementación del aspecto, es decir, contiene el
código que implementa la nueva funcionalidad. Se insertan en la aplicación en los
Puntos de Cruce (Ruelas, 2017).
 Puntos de Corte (en inglés Pointcut) define los Consejos que se aplicarán a cada
Punto de Cruce. Se especifica mediante Expresiones Regulares o mediante patrones
de nombres (de clases, métodos o campos), e incluso dinámicamente en tiempo de
ejecución según el valor de ciertos parámetros (Ruelas, 2017).
 Introducción (en inglés Introduction) permite añadir métodos o atributos a clases
ya existentes. Un ejemplo en el que resultaría útil es la creación de un Consejo de
Auditoría que mantenga la fecha de la última modificación de un objeto, mediante
una variable y un método setUltimaModificacion(fecha), que podrían ser
introducidos en todas las clases (o sólo en algunas) para proporcionarles esta nueva
funcionalidad (Ruelas, 2017).
 Destinatario (en inglés Target) es la clase aconsejada, la clase que es objeto de un
consejo. Sin AOP, esta clase debería contener su lógica, además de la lógica del
aspecto (Ruelas, 2017).
 Resultante (en inglés Proxy) es el objeto creado después de aplicar el Consejo al
Objeto Destinatario. El resto de la aplicación únicamente tendrá que soportar al
Objeto Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP) (Ruelas,
2017).
 Tejido (en inglés Weaving) es el proceso de aplicar Aspectos a los Objetos
Destinatarios para crear los nuevos Objetos Resultantes en los especificados Puntos

4
 de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto
Destinatario (Ruelas, 2017).
 Aspectos en Tiempo de Compilación, que necesita un compilador especial
(Ruelas, 2017).
 Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el Objeto
Destinatario es cargado. Requiere un ClassLoader especial (Ruelas, 2017).
 Aspectos en Tiempo de Ejecución.

2.2. Microservicios

La Arquitectura de micro- servicios, conocido por las siglas MSA (del inglés Micro Services
Architecture) es una aproximación para el desarrollo de software que consiste en construir
una aplicación como un conjunto de pequeños servicios, los cuales se ejecutan en su propio
proceso y se comunican con mecanismos ligeros (normalmente una API de recursos HTTP).
Cada servicio se encarga de implementar una funcionalidad completa del negocio. Cada
servicio es desplegado de forma independiente y puede estar programado en distintos
lenguajes y usar diferentes tecnologías de almacenamiento de datos (Wikipedia, 2018).

Es un enfoque para construir sistemas de software que descomponen los modelos de

dominio de negocios en contextos más pequeños, consistentes y limitados implementados
por los servicios (Wikipedia, 2018).

Estos servicios son aislados y autónomos, pero se comunican para proporcionar algunas
piezas de funcionalidad de negocio. Los microservicios son típicamente implementados
operado por pequeños equipos con suficiente autonomía que cada equipo y servicio puede
cambiar su implementación interna (¡incluida su sustitución inmediata!) con un impacto
mínimo en todo el mundo. el resto del sistema. (Posta, Microservices for Java Developers,
2015)

Características:

En el mundo real no todas las implementaciones de este estilo de arquitecturas siguen las
mismas características, pero la mayor parte de las arquitecturas de microservicios tienen la
mayor parte de las siguientes características (Wikipedia, 2018):

1. Los componentes son servicios. La principal manera de crear componentes (unidad

de software independientemente reemplazable y actualizable) es mediante la
descomposición en servicios en lugar de librerías. Los servicios son componentes
separados que se comunican mediante mecanismos como los servicios web o
los RPC en lugar de usar llamadas a funciones en memoria como hacen las librerías.
2. Organizada en torno a las funcionalidades del negocio. El sistema se divide en
distintos servicios donde cada uno está organizado en torno a una capacidad del

5
 negocio. Es muy importante limitar la responsabilidad de cada servicio. Cada servicio
implementa toda la funcionalidad del negocio que agrupa desde la interfaz de usuario,
la persistencia en el almacenamiento y cualquiera de las colaboraciones externas.
3. Productos no proyectos. En esta arquitectura normalmente se sigue la idea de que
un equipo debe estar a cargo de un componente (servicio) durante todo el ciclo de
vida del mismo, desde la etapa de diseño y construcción, la fase de producción y hasta
la de mantenimiento. Esta mentalidad se acopla bien a con la vinculación a una
capacidad del negocio. En lugar de ver el software como un conjunto de
funcionalidades terminadas se ve como una relación continua, donde la pregunta es
cómo puede el software ayudar a sus usuarios a mejorar la funcionalidad del negocio
que implementa. Esto es facilitado por el bajo nivel de granularidad que ofrecen los
microservicios.
4. Extremos inteligentes tuberías bobas. Las aplicaciones creadas desde
microservicios pretenden ser tan disociadas y cohesivas como sea posible, ellas
poseen su propia lógica de dominio y actúan como filtros en el clásico sentido UNIX:
recibe una solicitud, aplica la lógica apropiada y produce una respuesta. Estos pasos
son coreografiados usando protocolos simples (típicamente HTTP con REST o
mensajería liviana como RabbitMQ o ZeroMQ) en lugar de protocolos complejos
como WS-BPEL.
5. Tener gobierno descentralizado permite usar tecnologías que se adapten mejor a
cada funcionalidad. Con el sistema con múltiples servicios colaborativos, podemos
decidir utilizar diferentes lenguajes de programación y tecnologías dentro de cada
servicio. De esta forma podemos elegir la herramienta adecuada para cada tipo de
trabajo en lugar de tener una estandarizada. Por ejemplo, si una parte del sistema
necesita mejorar su rendimiento es posible usar una tecnología, quizás más
complicada, que permita alcanzar el nivel de rendimiento requerido. Otro ejemplo
sería usar para ciertas cosas (reflejar interacciones entre usuarios) una base de datos
orientada a grafos, y usar para otra bases de datos orientadas a documentos. la
arquitectura de microservicios permite adoptar nuevas tecnologías más rápido y en
aquello lugares donde se puede aprovechar su potencial ya que se acota el impacto.
6. Gestión de datos descentralizada. Los microservicios prefieren dejar a cada servicio
que gestione su propia base de datos, sean estas diferentes instancias de la misma
tecnología de base de datos o sistemas de base de datos completamente diferentes.
Por ejemplo podríamos tener Redis para sesiones de usuarios (base de datos en
memoria), MySQL (relacional) para los datos de pago, MongoDB (orientada a
documentos) para el catálogo de productos, Neo4j (orientada a grafos) para las
recomendaciones y Apache Cassandra (orientado a clave-valor) para el análisis de
logs y analíticas. El estilo de microservicios tiene implicaciones en el manejo de las
actualizaciones las cuales tradicionalmente han usado transacciones para garantizar
la consistencia. la transacción impone un acoplamiento temporal lo que se vuelve
problemático cuando hay varios servicios. Como las transacciones distribuidas son
6
 mucho más difíciles de implementar, las arquitecturas de microservicios promueven
la coordinación no transaccional entre servicios, con el reconocimiento explícito que
la consistencia puede ser una consistencia eventual y los problemas son compensados
operativamente. El sistema merece la pena siempre y cuando el costo de solucionar
los errores sea menor que el costo de perder negocios por una mayor consistencia.
Los microservicios no obligan a tener distintas tecnologías de almacenamiento, solo
lo permiten.
7. Diseño tolerante a fallos. Las aplicaciones necesitan ser diseñadas de modo que
puedan tolerar las fallas de los distintos servicios. Cualquier llamada de servicio
puede fallar y el cliente tiene que ser capaz de responder a esto con la mayor facilidad
y eficacia posible, evitando los muy habituales fallos en cascada de las arquitecturas
distribuidas. Patrones más importantes para conseguir estabilidad que se usan en la
arquitectura de microservicios:
8. Usar tiempos de espera máximos. Es un mecanismo simple que permite dejar de
seguir esperando por una respuesta que consideramos que ya no vendrá. Asociado al
vencimiento de un tiempo de espera es frecuente que aparezcan:
9. Reintento. Consiste en repetir una operación para el cual finalizó su tiempo de espera
10. Encolar para reintentar la operación para ser realizada más tarde
11. Disyuntores. Funcionan de forma similar a los interruptores automáticos accionados
por sobrecargas que hay en las instalaciones eléctricas. En el software existen para
permitir que un subsistema ante una falla no destruya el sistema entero por sobrecarga
y una vez que el peligro ha pasado pueda reestablecerse. Este mecanismo se suele
usar para envolver operaciones peligrosas con un componente y así poder esquivar
las llamadas cuando el sistema no esté operativo. Si el disyuntor detecta que las fallas
superan una frecuencia umbral el disyuntor salta abriéndose y las llamadas fallan sin
realizan ningún intento de ejecutar una operación real. Después de esperar un tiempo
adecuado se decide que la operación tiene una oportunidad y pasa a un estado de
semiabierto en el que la próxima llamada es permitida, si tiene éxito entonces el
disyuntor se vuelve a cerrar y todo vuelve a funcionar normalmente, si falla el
disyuntor se vuelve a abrir y se vuelve a esperar el tiempo adecuado para intentar.
12. Compartimentos estancos para contención de daños manteniendolos aislados.
La forma más común de tenerlos es usando redundancia física teniendo por ejemplo
varios servidores y dentro de cada servidor varias instancias. A gran escala podríamos
tener varias granjas de servidores.
13. Automatización de la infraestructura. La mayoría de los productos y sistemas
desarrollados con el enfoque de microservicios han sido construidos por equipo que
usan entrega continua y su precursor la integración continua. Para conseguir esto es
necesario:
14. Automatizar todo el proceso, desde el chequeo del código, pruebas, despliegue.

7
15. Control de versiones y gestión de configuración. Todo el software tiene que estar
versionado y poder gestionar las distintas configuraciones para conseguir la entrega
continua.
16. Arquitectura adecuada. La arquitectura tiene que permitir realizar cambios sin que
afecten al resto del sistema. La arquitectura de microservicios lo hace posible.
17. Diseño evolutivo. Cuando se divide el sistema en servicios hay que tener en cuenta
que cada uno tiene que poder ser reemplazado o actualizado de forma independiente.
Es decir, tiene que permitir una fácil evolución. El diseño del servicio tiene que ser
de tal forma que evite en lo posible que la evolución de los servicios afecte a sus
consumidores. (Wikipedia, 2018)

En sistemas complejos, las cosas fallan. Los discos duros se caen, los cables de red se
desconectan, hacemos mantenimiento en la base de datos en vivo en lugar de las copias
de seguridad, y las VMs desaparecen. Las fallas simples pueden propagarse a otras partes
del sistema y resultar en fallas en cascada que toman un largo tiempo de propagación por
todo el sistema caído (Wikipedia, 2018).

Tradicionalmente, al construir aplicaciones, hemos tratado de predecir qué piezas de

nuestra aplicación (por ejemplo, n-tier) podrían fallar y construir una pared lo
suficientemente grande como para evitar que las cosas fallaran. Esta mentalidad es
problemática en porque no siempre podemos predecir qué cosas pueden salir mal en
sistemas complejos. Las cosas fallarán, por lo que debemos desarrollar nuestras
aplicaciones para que sean resistentes y manejen los fallos, no sólo para prevenirlos.
Debemos ser capaces de tratar las faltas con elegancia y no dejar que las faltas se
propaguen hasta fallo total del sistema (Posta, Microservices for Java developers, 2016).

La construcción de sistemas distribuidos es diferente de la construcción de aplicaciones

monolíticas, de memoria compartida y de proceso único. Una diferencia flagrantees que
la comunicación a través de una red no es lo mismo que la comunicación local. con
memoria compartida. Las redes son intrínsecamente poco fiables. Llamadas a través de
la red puede fallar por cualquier número de razones (por ejemplo, la señal
cables/enrutadores/interruptores defectuosos y cortafuegos), y esto puede ser una fuente
importante de cuellos de botella. No sólo las faltas de fiabilidad de la red tienen
implicaciones de rendimiento en los tiempos de respuesta a los clientes de su empresa.
pero también puede contribuir al fallo de los sistemas anteriores. Las llamadas de red
latentes pueden ser muy difíciles de depurar (Wikipedia, 2018).

las llamadas de red no pueden completarse con éxito, fallan inmediatamente, y sus avisos
de aplicación rápidamente (por ejemplo, a través de IOException). En este caso, podemos
tomar medidas correctivas rápidamente, proporcionar o simplemente responda con un
mensaje indicando la solicitud no pudo completarse correctamente y que los usuarios
deberían intentarlo de nuevo más tarde. (Posta, Microservices for Java developers, 2016)

8
Pero los errores en las solicitudes de red o en las aplicaciones distribuidas no siempre son
tan fáciles. ¿Qué sucede si la aplicación de flujo descendente a la que debe llamar tarda
más de lo normal en responder? Esto es mortal porque ahora su aplicación debe tener en
cuenta esta lentitud mediante la aceleración de las solicitudes, la temporización de las
solicitudes de flujo descendente y la posibilidad de que todas las llamadas se detengan a
través de su servicio. Esta copia de seguridad puede causar servicios ascendentes para
experimentar desaceleración y detenerse. Y puede causar fallos en cascada. (Posta,
Microservices for Java developers, 2016)

Mejores prácticas en microservicios

Los siguientes principios han surgido como mejores prácticas para desarrollar y trabajar
con una arquitectura basada en microservicios. Estos principios son útiles durante la
evaluación inicial y sirven como una lista de verificación para su proyecto greenfield
(Wikipedia, 2018).

Diseño para la automatización

La entrega continua (CD) es un enfoque de ingeniería de software en el que los equipos

producen software utilizable en ciclos cortos, a la vez que garantizan que puedan ser
liberados de forma fiable en cualquier momento. Se utiliza en el desarrollo de software
para automatizar y mejorar el proceso de entrega de software (Wikipedia, 2018).

El DC es un tema lo suficientemente complejo y amplio como para abarcar volúmenes y

no sólo unos pocos párrafos. Sin embargo, la idea detrás de la entrega continua
proporciona el mecanismo por el cual puede operar el ciclo de innovación para
aplicaciones basadas en microservicios. El principio de entrega continua que es más
relevante aquí es la capacidad de desplegarse rápidamente en la producción, acortando el
tiempo de ciclo entre una idea y la retroalimentación sobre el valor de la idea (Wikipedia,
2018).

Lograr un despliegue rápido requiere muchas técnicas de entrega continua, incluyendo la

automatización de la infraestructura, la automatización de la construcción, la
automatización de la implementación y el desmantelamiento, y la automatización de la
migración de datos (Wikipedia, 2018).

y (por supuesto) la automatización de pruebas. Cada una de estas técnicas es necesarias

para apoyar el rápido desarrollo de nuevas características, las pruebas rápidas del nuevo
sistema, un despliegue rápido y seguro de la aplicación en producción, y el retroceso
seguro y rápido en caso de que el sistema no sea trabajando como se esperaba o si la
característica resulta ser una mala idea. (Eisele, 2016)

9
Patrón de la tubería

En escenarios más complejos, una sola solicitud desencadena una serie completa de pasos
a ejecutar. En este caso, el número de servicios que tienen que ser llamados para una sola
respuesta es mayor que uno. El uso de un pipeline de servicios permite la ejecución de
diferentes operaciones sobre la solicitud entrante. Se puede desencadenar una sintonía de
pipeline de forma crónica o asincrónica, aunque las etapas de tratamiento son lo más
probable es que sean sincrónicos y dependan los unos de los otros. Pero si los servicios
están usando peticiones síncronas, el cliente tendrá que esperar a que el último paso en el
pipeline a terminar. (Eisele, 2016)

Recursos compartidos

Uno de los principios de diseño críticos de los microservicios es la autonomía.

Especialmente en escenarios de migración, puede ser difícil corregir los errores de diseño
cometidos hace un par de años. Y en lugar de alcanzar el Big Bang, podría haber una
manera más razonable de manejar esos casos especiales. Enfrentarse a una situación en
la que los microservicios tienen que compartir una comunicación. Mi fuente de datos no
es la ideal. Sin embargo, se puede trabajar con el patrón de "recursos compartidos"
(Eisele, 2016)

10
 2.3. Framework Spring

Spring ayuda a solventar este problema ya que cambia las responsabilidades y en vez de que
el propio desarrollador sea el encargado de generar los objetos de cada uno de los frameworks
es Spring basandose en ficheros xml o anotaciones el encargado de construir todos los objetos
que la aplicación va a utilizar (Alvarez, 2018).

11
De esta manera al ser Spring el encargado de inicializar todos los objetos de los distintos
frameworks, es también el responsable de asegurarnos que se integran de la forma correcta
(Wikipedia, 2017).

(Alvarez, 2018)

La primera versión fue escrita por Rod Johnson, quien lo lanzó junto a la publicación de su
libro Expert One-on-One J2EE Design and Development (Wrox Press, octubre 2002).

El framework fue lanzado inicialmente bajo la licencia Apache 2.0 en junio de 2003. El
primer gran lanzamiento fue la versión 1.0, que apareció en marzo de 2004 y fue seguida por
otros hitos en septiembre de 2004 y marzo de 2005. La versión 1.2.6 de Spring Framework
obtuvo reconocimientos Jolt Awards y Jax Innovation Awards en 2006 (Alvarez, 2018).

Spring Framework 2.0 fue lanzada en 2006, la versión 2.5 en noviembre de 2007, Spring 3.0
en diciembre de 2009, y Spring 3.1 dos años más tarde. El inicio del desarrollo de la versión
4.0 fue anunciado en enero de 2013. La versión actual es la 5.0 (Alvarez, 2018).

Si bien las características fundamentales de Spring Framework pueden ser usadas en

cualquier aplicación desarrollada en Java, existen variadas extensiones para la construcción
de aplicaciones web sobre la plataforma Java EE. A pesar de que no impone ningún modelo
de programación en particular, este framework se ha vuelto popular en la comunidad al ser
considerado una alternativa, sustituto, e incluso un complemento al modelo EJB (Enterprise
JavaBean) (Alvarez, 2018).

12
Modulos:

Spring Framework comprende diversos módulos que proveen un rango de servicios (Wikipedia, 2017):

 Contenedor de inversión de control: permite la configuración de los componentes de aplicación y

la administración del ciclo de vida de los objetos Java, se lleva a cabo principalmente a través de
la inyección de dependencias.
 Programación orientada a aspectos: habilita la implementación de rutinas transversales.
 Acceso a datos: se trabaja con RDBMS en la plataforma java, usando Java Database Connectivity y
herramientas de Mapeo objeto relacional con bases de datos NoSQL.
 Gestión de transacciones: unifica distintas APIs de gestión y coordina las transacciones para los
objetos Java.
 Modelo vista controlador: Un framework basado en HTTP y servlets, que provee herramientas para
la extensión y personalización de aplicaciones web y servicios web REST.
 Framework de acceso remoto: Permite la importación y exportación estilo RPC, de objetos Java a
través de redes que soporten RMI, CORBA y protocolos basados en HTTP incluyendo servicios
web (SOAP).
 Convención sobre Configuración: el módulo Spring Roo ofrece una solución rápida para el
desarrollo de aplicaciones basadas en Spring Framework, privilegiando la simplicidad sin perder
flexibilidad.
 Procesamiento por lotes: un framework para procesamiento de mucho volumen que como
características incluye funciones de registro/trazado, manejo de transacciones, estadísticas de
procesamiento de tareas, reinicio de tareas, y manejo de recursos.
 Autenticación y Autorización: procesos de seguridad configurables que soportan un rango de
estándares, protocolos, herramientas y prácticas a través del subproyecto Spring Security
(antiguamente Acegi).
 Administración Remota: Configuración de visibilidad y gestión de objetos Java para la
configuración local o remota vía JMX.
 Mensajes: Registro configurable de objetos receptores de mensajes, para el consumo transparente
desde la a través de JMS, una mejora del envío de mensajes sobre las API JMS estándar.
 Testing: Soporte de clases para desarrollo de unidades de prueba e integración. (Wikipedia, 2017)

13
2.4. Programación Reactiva

La programación reactiva es un paradigma enfocado en el trabajo con flujos de datos

finitos o infinitos de manera asíncrona (Íñigo, 2017). Su concepción y evolución ha ido
ligada a la publicación del Reactive Manifesto, que establecía las bases de los sistemas
reactivos, los cuales deben ser:

 Responsivos: aseguran la calidad del servicio cumpliendo unos tiempos de

respuesta establecidos.

 Resilientes: se mantienen responsivos incluso cuando se enfrentan a situaciones

de error.

 Elásticos: se mantienen responsivos incluso ante aumentos en la carga de trabajo.

 Orientados a mensajes: minimizan el acoplamiento entre componentes al

establecer interacciones basadas en el intercambio de mensajes de manera
asíncrona.
Compañías como Netflix llevan años aplicando la programación reactiva para mejorar el
rendimiento de sus aplicaciones, superando las limitaciones nativas del lenguaje Java
(Íñigo, 2017).

2.4.1. Modelo de actores

El modelo de actores proporciona la funcionalidad central de los sistemas reactivos,

definidos en el Manifiesto Reactivo como receptivos, resilientes, elásticos y
orientados a mensajes (McKee, 2016).

Los actores son entidades que intercambian mensajes asíncronos y realizan una
tarea en concreto. Los actores pueden agruparse en grupos de actores (clusters), lo
cual permite que el sistema sea escalable horizontalmente (McKee, 2016).

Los actores (supervisors) pueden crear otros autores (workers) para delegarles
trabajos más específicos. Si un worker se encuentra con un problema, se suspende
a sí mismo y notifica a su supervisor de la falla. De esta forma el sistema puede
manejar los errores de forma que no se vea afectado por estos (McKee, 2016).

14
Figura 1: Un actor (supervisor) crea otros actores (workers) (McKee, 2016)

Con los actores y los sistemas de actores, la detección y recuperación de fallos es

una característica arquitectónica, no algo que se pueda parchear posteriormente
(McKee, 2016).

Pensar en términos de actores es mucho más intuitivo al momento de diseñar

sistemas, ya que tiene más en común con la forma en que los humanos
interactuamos. Esto nos permite diseñar e implementar sistemas centrándonos más
en la funcionalidad principal de los sistemas (McKee, 2016).

2.4.2. APIs Java de programación reactiva

RxJava 2

Esta librería, y su versión 1.x fueron las pioneras en el desarrollo reactivo Java. Se
encuentran completamente integradas en frameworks como Spring MVC, Spring
Cloud y Netflix OSS (CampusMVP, 2017).

Project Reactor

Fue concebida con la implicación del equipo responsable de RxJava 2 por lo que
comparten gran parte de la base arquitectónica. Su principal ventaja es que al ser parte
de Pivotal ha sido la elegida como fundación del futuro Spring 5 WebFlux Framework
(CampusMVP, 2017).

2.4.3. Usos

Hay algunos escenarios que son altamente susceptibles de afrontar usando la

programación reactiva, entre ellos tenemos (That C# guy, s.f.):

15
  Aplicaciones con interfaz gráfica en la que el usuario interactúe con la
aplicación

 Cuando se quiera procesar información en tiempo real como por ejemplo las
lecturas provistas por un termómetro, un sismógrafo o, en el caso de los
automóviles autónomos, la inmensa cantidad de información que reciben a
través de sus sensores.

 Cuando se trabaje con flujos interminables de datos como la inmensa cantidad

de tweets que existen, o las transferencias bancarias que ocurren en un banco
al día.

2.5. Responsive Design

El diseño web responsive o adaptativo es una técnica de diseño web que busca la correcta
visualización de una misma página en distintos dispositivos. Desde ordenadores de
escritorio a tablets y móviles (40deFiebre, s.f.).

Imagen 1: Características del diseño responsive (40deFiebre, s.f.)

Se trata de redimensionar y colocar los elementos de la web de forma que se adapten al

ancho de cada dispositivo permitiendo una correcta visualización y una mejor experiencia
de usuario. Se caracteriza porque los layouts (contenidos) e imágenes son fluidos y se usa
código media-queries de CSS3 (40deFiebre, s.f.).

2.5.1. Ventajas

Las principales ventajas de un diseño responsive son (Wikipedia, 2018):

 El diseño responsive permite reducir el tiempo de desarrollo, evita los contenidos

duplicados, y aumenta la viralidad de los contenidos ya que permite compartirlos
de una forma mucho más rápida y natural.

16
  Con una sola versión en HTML y CSS se pueden cubrir todas las resoluciones de
pantalla, con lo que el sitio web estará optimizado para distintos dispositivos y
resoluciones de pantalla.

 También evita tener que desarrollar aplicaciones ad-hoc para cada sistema
operativo móvil.

 Desde el punto de vista del posicionamiento en buscadores, aparecería una única

URL en los resultados de búsqueda, con lo cual se ahorrarían múltiples
redirecciones y los fallos que se derivan de estas.

2.6. UX-Design

UX Design (User Experience Design) o “Diseño de Experiencia de Usuario” es una

filosofía de diseño que tiene por objetivo la creación de productos que resuelvan
necesidades concretas de sus usuarios finales, consiguiendo la mayor satisfacción y mejor
experiencia de uso posible con el mínimo esfuerzo. Toma forma como un proceso en el
que se utilizan una serie de técnicas multidisciplinares y donde cada decisión tomada
debe estar basada en las necesidades, objetivos, expectativas, motivaciones y capacidades
de los usuarios (PMQuality, s.f.).

La mayoría de los procesos que hacen Diseño Centrado en el Usuario tienen el siguiente
esqueleto (PMQuality, s.f.):

 Conocer a fondo a los usuarios finales, normalmente usando investigación

cualitativa o investigación cuantitativa.

 Diseñar un producto que resuelva sus necesidades y se ajuste a sus capacidades,

expectativas y motivaciones.

 Poner a prueba lo diseñado, usando test de usuario.

17
 Imagen 2: Elementos de la experiencia de usuario (PMQuality, s.f.)

2.6.1. Elementos

El diseño de experiencia de usuario se compone de los siguientes elementos

(Wikipedia, 2018):

 Diseño visual: El propósito del diseño visual es utilizar elementos visuales como
colores, imágenes y símbolos para transmitir un mensaje a su audiencia.

 Arquitectura de la información: Es el arte y la ciencia de estructurar y organizar

la información en productos y servicios para apoyar la usabilidad y la búsqueda.

 Diseño interactivo: Su objetivo es crear un producto que produzca una

experiencia eficiente y placentera para el usuario final, permitiéndole alcanzar sus
objetivos de la mejor manera posible.

 Usabilidad: Es la medida en que un producto puede ser utilizado por usuarios

específicos para lograr objetivos específicos con eficacia, eficiencia y satisfacción
en un contexto específico de uso.

 Pruebas de usabilidad: Es una técnica utilizada en el diseño de interacción

centrada en el usuario para evaluar un producto probándolo en los usuarios.

 Accesibilidad: La accesibilidad de un sistema describe su facilidad de alcance,

uso y comprensión. En términos de diseño de la experiencia del usuario, también
puede relacionarse con la comprensibilidad general de la información y las
características.

 Cumplimiento del WCAG: Seguir estas directrices hará que el contenido sea
accesible a una gama más amplia de personas con discapacidad y usuarios en
general.

18
  Interacción hombre-computadora: Se refiere al diseño, evaluación e
implementación de sistemas de computación interactiva para uso humano y al
estudio de los principales fenómenos que los rodean.

2.7. Programación Serverless

La definición correcta de Serverless, es en aquel proveedor donde alojamos una unidad

completa de nuestro código o aplicación y unas condiciones o triggers que dispararán la
ejecución de este código. Obviamente estaremos sujetos a algunas restricciones como la
ausencia de acceso a disco o a recursos físicos o virtuales de hardware, pero la idea de
poder tener un número ilimitado de funciones o procedimientos listos para ser ejecutados
y solo pagar por el número de ejecuciones, es muy atractivo (Domingo, 2017).

2.7.1. Proveedores

Actualmente se existen tres grandes proveedores de este servicio:

 Amazon Web Services – Lambda

AWS Lambda es el primero en el mercado que estuvo operativo hace ya 3 años. Uno
de los mejores puntos de este servicio es que es posible integrarlo con muchos de los
servicios de Amazon como RDS, Kinesis, DynamoDB y puede ser monitoreado con
Cloudwatch, así como integrarse con servicios de Amazon Alexa (Domingo, 2017).

Lambda es una de las opciones preferidas en grandes proyectos (Netflix, IE Business

School de Madrid…) ya que pueden encontrarse además diversos contribuidores de
funciones Lambda listas para incorporar en un proyecto concreto (Domingo, 2017).

Imagen 3: Arquitectura de Amazon Web Services (Amazon, 2018)

 Azure Functions

Functions fue la respuesta de Microsoft Azure a Amazon. Después de un año y medio

en el mercado podemos decir que Microsoft ha puesto mucha ilusión y energía en la

19
construcción de este servicio y lo demuestra por su capacidad de utilizar los
principales lenguajes de programación de Microsoft, desde .Net, C# hasta scripts
basados en Batch en PowerShell, JavaScript o Python (Domingo, 2017).

Al igual que Amazon es posible integrarlo con muchos de los servicios de Azure y
hasta con Cortana, pieza angular de la nueva guerra para llegar a los dispositivos
domésticos (Domingo, 2017).

 Google Cloud Functions

Google Cloud Functions acaba de llegar a Google Cloud Platform y si bien por ahora
sólo admite código en JavaScript, tiene la gran característica de poder integrarse con
el resto de servicios de Google, desde Storage hasta Spanner. Y al igual que sus
competidores, puede monitorizarse a través de Stackdriver o herramientas de terceros
(Domingo, 2017).

2.7.2. Ventajas

Las principales ventajas de la programación serverless son (CampusMVP, 2017):

 Olvídate de servidores, sistema operativo, instancias...

La informática serverless está totalmente gestionada. Es decir, nunca tienes que

reservar explícitamente instancias de servidor como sí pasa en PaaS (plataforma como
servicio) o por supuesto en IaaS (máquinas virtuales).

 Escalabilidad impulsada por eventos

La idea con funciones serverlesss es que, en lugar de programar una aplicación

completa, escribes una "función", que contiene tanto código (lo que va a hacer) como
metadatos (sus desencadenadores o triggers y los enlaces con otros sistemas).

 Micro facturación

Con la arquitectura sin servidor pagas únicamente cuando se está ejecutando tu

código. Si no hay ejecuciones de funciones activas, no se te cobra. Por ejemplo, si tu
código se ejecuta una vez al día durante 2 minutos, se te facturará 1 unidad de
ejecución y 2 minutos de cómputo.

20
3. Gestión de datos
3.1. Bases de datos relacionales

 Una base de datos relacional es una colección de elementos de datos

organizados en un conjunto de tablas formalmente descritas desde la que se
puede acceder a los datos o volver a montarlos de muchas maneras diferentes
sin tener que reorganizar las tablas de la base. (Rouse, Search Data Center,
2015)

 Cada tabla (que a veces se llaman ‘relación’) contiene una o más categorías
de datos en columnas. Cada fila contiene una instancia única de datos para las
categorías definidas por las columnas. Por ejemplo, una base de datos típica
de ingreso de solicitudes de negocio incluiría una tabla que describiera a un
cliente con columnas para el nombre, dirección, número de teléfono, y así
sucesivamente. Otra tabla identificaría el pedido: producto, cliente, fecha,
precio de venta, y así sucesivamente. (Rouse, Search Data Center, 2015)

 La interfaz estándar de programa de usuario y aplicación a una base de

datos relacional es el lenguaje de consultas estructuradas (SQL). Los
comandos de SQL se utilizan tanto para consultas interactivas para obtener
información de una base de datos relacional y para la recopilación de datos
para los informes. (Rouse, Search Data Center, 2015)

3.2. Bases de datos no relacionales

 Las bases de datos NoSQL son bases de datos no relacionales optimizadas

para modelos de datos sin esquema y de desempeño escalable. También son
ampliamente conocidas por su facilidad de desarrollo, baja latencia y
resiliencia. Utilizan una variedad de modelos de datos, como los almacenes
de valor clave en memoria, de gráficos, de documentos y en columnas. Esta
página incluye recursos que le servirán para comenzar a usar las bases de datos
NoSQL. (Rouse, Base de datos en memoria, 2012)

Como funciona una Base de datos NoSQL

 Los sistemas de bases de datos NoSQL usan una variedad de modelos de

administración de datos, como los almacenes de valor clave en memoria, los
modelos de datos de gráficos y los almacenes de documentos. Estos tipos de
bases de datos están optimizados para aplicaciones que requieren grandes
volúmenes de datos, baja latencia y modelos de datos flexibles, lo que se logra
mediante la flexibilización de algunas de las restricciones de coherencia de

21
 datos en las bases de datos relacionales tradicionales. (Rouse, Base de datos
en memoria, 2012)

TIPOS DE BASE DE DATOS NOSQL

 Base de datos en columnas: están optimizadas para leer y escribir columnas

de datos en lugar de filas. El almacenamiento basado en columnas para las
tablas de bases de datos es un factor importante en el desempeño de las
consultas analíticas, ya que reduce notablemente los requisitos globales de
E/S del disco, así como el volumen de datos que hay que cargar desde este.
(Amazon, 2018)

 Base de datos de documentos: están diseñadas para almacenar datos

semiestructurados como documentos, normalmente en formato JSON o XML.
A diferencia de las bases de datos relacionales tradicionales, el esquema de
cada documento NoSQL puede variar, lo que ofrece más flexibilidad al
organizar y almacenar datos de aplicaciones y al reducir el almacenamiento
necesario para los valores opcionales. (Amazon, 2018)

 Base de datos de gráficos: almacenan vértices y enlaces dirigidos llamados

aristas. Las bases de datos de gráficos se pueden crear en bases de datos
NoSQL y NoSQL. Los vértices y las aristas pueden tener propiedades
asociadas. (Amazon, 2018)

 Los almacenes en valor clave en memoria: son bases de datos NoSQL

optimizadas para cargas de trabajo de aplicaciones que realizan muchas tareas
de lectura (como redes sociales, videojuegos, uso compartido de archivos
multimedia y portales de preguntas y respuestas) o para cargas de trabajo con
un uso intensivo de computación (como un motor de recomendaciones). El
almacenamiento de caché en memoria mejora el desempeño de las
aplicaciones mediante el almacenamiento de los datos críticos en memoria
para lograr un acceso de baja latencia. (Amazon, 2018)

3.3. Bases de datos en memoria

 Una base de datos en memoria (IMBD, según sus siglas en inglés, y también
conocida como base de datos en memoria principal o MMDB) es una base de
datos cuyos datos están almacenados en la memoria principal para facilitar
tiempos más rápidos de respuesta. Los datos de origen se cargan a la memoria
del sistema en un formato comprimido no relacional. Las bases de datos en
memoria optimizan el trabajo relacionado con el procesamiento de consultas.

22
  Una IMDB es un tipo de base de datos analítica, que es un sistema de solo
lectura que almacena datos históricos sobre indicadores para aplicaciones de
inteligencia empresarial/análisis de negocios (BI/BA), usualmente como parte
de un almacén de datos o un data mart. (Rouse, Base de datos en memoria,
2012)

 Además de brindar tiempos extremadamente rápidos de respuesta a consultas,

la analítica en memoria puede reducir o eliminar la necesidad de indexar datos
y almacenar datos preagregados en cubos OLAP o tablas agregadas. Esta
capacidad reduce los costos de informática y permite una implementación más
rápida de aplicaciones de BI/BA. (Rouse, Base de datos en memoria, 2012)

3.4. In-Memory DataGrid

En general, el término caché distribuida significa la capacidad de replicar datos en la

memoria, por lo que es accesible desde cualquier parte del clúster. Las grillas de datos
generalmente logran esto al dividir los datos en la memoria, donde cada miembro del
clúster es responsable solo de su propio subconjunto de datos. También puede
considerarlo como una Tabla Hash distribuida. De esta forma, cuantos más servidores
estén disponibles en su clúster, más datos podrá almacenar en caché. (Setrakyan,
2015)

 Las cuadrículas de datos son generalmente conocidas por tener un conjunto

de funciones bastante rico además de las memorias caché en memoria. Las 3
características principales que son absolutamente obligatorias para cualquier
solución de cuadrícula de datos son:

- transacciones distribuidas

- consultas distribuidas

- Colocación de cálculo y datos

Sin las 3 características anteriores, realmente no se puede llamar a un producto una

cuadrícula de datos. Muchos proveedores también se diferencian entre sí agregando
otras características populares, que incluyen:

- Soporte de SQL

- Memoria Off-Heap (para evitar largas pausas de GC)

- Almacenamiento en caché de WebSession

- Integración Hibernate

23
3.5. In-Memory DataFabric

En Memory Data Fabrics representan la evolución natural de la computación en

memoria. Generalmente, Data Fabrics adopta un enfoque más amplio en la
computación de la memoria, agrupando todo el conjunto de casos de uso de la
computación en memoria en una colección de componentes independientes bien
definidos. Por lo general, un DataGrid es solo uno de los componentes
proporcionados por un tejido de datos. Además de la funcionalidad de la cuadrícula
de datos, una estructura de datos en memoria generalmente también incluye una
cuadrícula de cálculo, transmisión de CEP, un sistema de archivos en memoria y más.
(Setrakyan, 2015)

La principal ventaja de un tejido de datos en memoria es que todos los componentes

informáticos en memoria provistos se pueden usar de forma independiente, a la vez
que se integran bien entre sí. Por ejemplo, en Apache Ignite una Compute Grid sabe
cómo equilibrar la carga y programar cálculos dentro de un clúster, pero cuando se
utiliza junto con una cuadrícula de datos, Compute Grid también enrutará todos los
cálculos que procesan datos a los miembros del clúster responsables del
almacenamiento en caché esa información Lo mismo ocurre con Streaming y CEP:
cuando se trabaja con datos transmitidos, todo el procesamiento se realiza en los
miembros del clúster responsables también del almacenamiento en caché de esos
datos. (Setrakyan, 2015)

Las características comúnmente vistas de In-Memory Data Fabrics incluyen:

- Cuadrícula de datos (debe tener para cualquier tela de datos)

- Calcular cuadrícula

- Cuadrícula de servicio

- Streaming y CEP

- Sistema de archivos distribuidos

- Base de datos en memoria

24
4. Plataforma tecnológica
4.1. Cableado estructurado

Un cableado estructurado es un sistema de conectores, cables, dispositivos y canalizaciones

que forman la infraestructura que implanta una red de área local en un edificio o recinto, y
su función es transportar señales desde distintos emisores hasta los receptores
correspondientes.

Su estructura contiene una combinación de cables de par trenzado protegidos o no protegidos

(STP y UTP por sus siglas en inglés, respectivamente), y en algunas ocasiones de fibras
ópticas y cables coaxiales. Sus elementos principales son el cableado horizontal, el cableado
vertical y el cuarto de telecomunicaciones. (Nextu, s.f.)

4.2. Guía de diseño de redes de campos CISCO

Diseñar una LAN para el caso de uso del campus no es una propuesta de un solo diseño para
todos. La escala de LAN del campus puede ser tan simple como un solo interruptor y AP
inalámbrico en un sitio remoto pequeño o en un complejo grande, distribuido y de múltiples
edificios con puerto cableado de alta densidad y requisitos inalámbricos. La implementación
puede requerir una disponibilidad muy alta para los servicios ofrecidos por la red, con una
baja tolerancia al riesgo, o puede haber tolerancia para el enfoque de fallas de conexión con
interrupciones prolongadas del servicio para un número limitado de usuarios considerados
aceptables. Opciones de plataforma para estas implementaciones a menudo son impulsadas
por las necesidades de capacidad de red, el dispositivo y las capacidades de red que se
ofrecen, y también la necesidad de cumplir con los requisitos de cumplimiento que son
importantes para la organización. Tú impones la mayor parte de la complejidad del diseño
LAN alámbrico del campus al agregar grupos de interruptores de acceso mediante
interconectando las capas de acceso a las capas de distribución. Si los dispositivos que se
conectan a la capa de acceso tienen un requisito para comunicarse con una adyacencia lógica
de Capa 2 y esas conexiones cubren múltiples conexiones físicas armarios conectados a una
capa de distribución, entonces es posible adaptar el diseño tradicional de campus de varias
capas a abordar las necesidades de adyacencia de Capa 2. Sin embargo, los diseños
tradicionales manejan configuraciones más complejas con protocolos adicionales que deben
mantenerse consistentes en varios dispositivos. (CISCO, 2018)

Para mejorar el diseño, existen alternativas preferidas que hacen que la implementación sea
más fácil de administrar y menos propenso a errores, al tiempo que mejora el rendimiento
general de la red. Tales alternativas incluyen la distribución simplificada opción de capa
utilizando una pila de conmutadores o un sistema de conmutación virtual (VSS) o un sistema
StackWise Virtual, lo que hace que la implementación y la resolución de problemas sean
mucho más fáciles para el personal de soporte (CISCO, 2018).

25
Existe una alternativa de diseño disponible para organizaciones que no necesitan ampliar la
conectividad de Capa 2 a través de un límite de acceso a la agregación o tiene otros medios
para implementar esta funcionalidad, como cuando utilizando la tecnología Campus Fabric:
una parte integral de Cisco Software-Defined Access (SD-Access). La alternativa es extender
la conectividad de Capa 3 a la capa de acceso. La implementación de un acceso bien diseñado
de Capa 3 la red garantiza la coherencia, la configuración, el rendimiento, la escalabilidad y
la alta disponibilidad de la red frente al diseño tradicional de campus multicapa. (CISCO,
2018)

La motivación para las opciones de diseño recomendadas no es que sean las únicas opciones
disponibles sino que él las recomendaciones destacan las opciones preferidas dado el alcance
de los requisitos (CISCO, 2018).

El diseño de campus multicapa mencionado anteriormente es una opción de diseño válida y

ampliamente utilizada, el diseño no es uno eso es típicamente recomendado a la luz de
mejores alternativas que están actualmente disponibles (CISCO, 2018).

Cuando integra los componentes inalámbricos del diseño del campus con los componentes
cableados, el diseño puede a menudo se trata como una superposición que depende de los
servicios proporcionados por la infraestructura subyacente del campus (CISCO, 2018).

Esto es especialmente evidente para las redes más grandes, ya que aumenta la capacidad con
dispositivos dedicados un requerimiento. Las redes más pequeñas, como las de sitios remotos
pequeños, ofrecen oportunidades de simplificación y optimización que también se refleja en
las elecciones de diseño que se muestran a continuación (CISCO, 2018).

Las opciones de diseño primarias se agrupan por escala, y luego las selecciones apropiadas
se basan en las capacidades deseadas. La selección del espectro de capacidades se basa en
las necesidades de una implementación específica (CISCO, 2018).

4.3. Metodología TOPDOWN de CISCO

El diseño de redes TOPDOWN es una metodología para diseñar redes que comienza en las
capas superiores del modelo de referencia OSI antes de pasar a las capas inferiores. La
metodología de arriba hacia abajo se centra en aplicaciones, sesiones y transporte de datos
antes de la selección de enrutadores, conmutadores y medios que operan en las capas
inferiores. (CISCO, 2018)

El proceso de diseño de red descendente incluye la exploración de estructuras organizativas

y grupales para encontrar a las personas para quienes la red brindará los servicios y de quienes
el diseñador debe obtener información valiosa para que el diseño tenga éxito (CISCO, 2018).

26
El diseño de red descendente también es iterativo. El diseño de red de arriba hacia abajo
reconoce que el modelo lógico y el diseño físico pueden cambiar a medida que se recopila
más información (CISCO, 2018).

El diseño de redes descendentes es una disciplina que surgió del éxito de la programación de
software estructurado y el análisis de sistemas estructurados. El objetivo principal del análisis
de sistemas estructurados es representar con mayor precisión las necesidades de los usuarios,
que lamentablemente a menudo se ignoran o se tergiversan. Otro objetivo es hacer que el
proyecto sea manejable dividiéndolo en módulos que puedan mantenerse y modificarse más
fácilmente. (CISCO, 2018)

El análisis de sistemas estructurados tiene las siguientes características (CISCO, 2018):

 Analice los requisitos: en esta fase, el analista de red entrevista a los usuarios
y al personal técnico para comprender los objetivos comerciales y técnicos de
un sistema nuevo o mejorado. La tarea de caracterizar la red existente, que
incluye la topología lógica y física y el rendimiento de la red, se muestra a
continuación. El último paso en esta fase es analizar el tráfico de red actual y
futuro, incluidos el flujo de tráfico y la carga, el comportamiento del protocolo
y los requisitos de calidad de servicio (QoS).

 Desarrollar el diseño lógico: esta fase trata sobre una topología lógica para
la red nueva o mejorada, el direccionamiento de capa de red, el nombramiento
y los protocolos de conmutación y enrutamiento. El diseño lógico también
incluye la planificación de seguridad, el diseño de administración de red y la
investigación inicial en la que los proveedores de servicios pueden cumplir
con los requisitos de acceso remoto y WAN.

 Desarrollar el diseño físico: durante la fase de diseño físico, se seleccionan

tecnologías y productos específicos que realizan el diseño lógico. Además, la
investigación de los proveedores de servicios, que comenzó durante la fase de
diseño lógico, debe completarse durante esta fase.

 Probar, optimizar y documentar el diseño: los pasos finales en el diseño de

red descendente son escribir e implementar un plan de prueba, crear un
prototipo o piloto, optimizar el diseño de la red y documentar su trabajo con
una propuesta de diseño de red.

4.4. Centro de datos

Un centro de procesamiento de datos (CPD) es la ubicación física donde se concentran los

recursos necesarios de computación de una organización o proveedor de servicios. También
es conocido como “Internet Data Center” (IDC) en inglés, centro de cómputo en

27
Latinoamérica, o en España que lo llamamos centro de cálculo o centro de datos. (StackScale,
2018)

Un centro de datos dispone de espacios de uso exclusivo donde las empresas mantienen y
operan sus infraestructuras IT. Es ese espacio donde se pueden alojar los servidores y
sistemas de almacenamiento para ejecutar las aplicaciones que procesan y almacenan datos
de empresas. Algunas empresas disponen de una Jaula o de solo uno o varios racks (bastidor),
mientras que otras pueden disponer de salas privadas para alojar un número determinado de
armarios rack, dependiendo del tamaño de la empresa. (Wikipedia, 2018)

El centro de datos proporciona el espacio técnico preparado con falso suelo por debajo de
cual se instalan las tomas eléctricas para conectar los bastidores. (Wikipedia, 2018)

El control de clima para mantener unos parámetros de temperatura y humedad correctos que
garanticen el correcto funcionamiento y la integridad operativa de los sistemas alojados. Los
centros de datos cuentan con sistemas de alimentación eléctrica, alimentación de reserva,
refrigeración, cableado, detección y extinción de incendios, detectores de fugas de agua y
controles de seguridad (StackScale, 2018).

Un Datacenter físico puede alojar Datacenters virtuales, conocidos como cloud datacenters
o cloud privado, con un menor coste gracias a la capa de virtualización. Cada Centro de datos
virtual es totalmente independiente de otros, por lo que, cuenta con las máximas garantías de
seguridad, disponibilidad y flexibilidad (StackScale, 2018).

28
 4.5. Hiperconvergencia

En los entornos computacionales modernos que se tienen que adecuar a las tendencias
informáticas modernas, se necesita sentar las bases de la infraestructura tecnológica sobre
una plataforma que centralice los diversos factores que entran a tallar en el plano del
desarrollo de la ya mencionada infraestructura. De esta manera se combina el
almacenamiento, la computación las redes y la administración de IT que funciona como un
sistema único. Lo descrito anteriormente es la convergencia, y tomándolo como punto de
partida para entender la convergencia que además de combinar lo ya dicho anteriormente,
esta reúne la virtualización y todas las tecnologías definidas por el software.

Según Daniel Morales, de ANADAT CONSULTING, estos son los beneficios de la

hiperconvergencia en las empresas:

 Actualización y consolidación del centro de datos. Suministrar soporte a las

necesidades que demandan los nuevos entornos de movilidad, colaboración, Big
Data y Nube de una manera rápida y sencilla.

 Despliegue de escritorios virtuales. Proporciona, de forma homogénea, una

infraestructura sólida que garantiza el rendimiento de almacenamiento que exigen
los proyectos de VDI.

 Infraestructuras de TI para la apertura de nuevas oficinas o refuerzo de áreas

de negocio. Permite responder rápidamente a los requisitos tecnológicos que
demandan nuevos proyectos u oportunidades de negocio.  Entornos de prueba y
desarrollo. Son infraestructuras aisladas en las que centrar este tipo de labores sin
necesidad de impactar en los sistemas productivos cotidianos de las organizaciones.

 Proveedores de infraestructura y servicios en la Nube. La hiperconvergencia

supone un camino rápido y ágil a la hora de ampliar los recursos de data center de
los Managed Service Providers (MSPs) ante situaciones de picos de servicios,
incorporación de otros servicios nuevos, Disaster Recovery, backups, Desktop as a
Service (DaaS) o entrada de nuevos clientes.

4.6. Cloud Computing

El significado de cloud(“nube”) el cual es la forma que se ha generalizado para referirnos

a internet y computing (“computación”) que se puede considerar para referirnos a
computación y almacenamiento, hace que, de cierta manera, podamos referirnos a una
computación enlazada a internet. La definición de Cloud Computing con la que nos
podríamos quedar es la que nos da el NIST (Instituto Nacional de Estándares y Tecnología
estadounidense), la cual es la siguiente: “El cloud computing es un modelo que permite el

29
acceso bajo demanda a través de la red a un conjunto compartido de recursos de
computación configurables (como por ejemplo red, servidores, almacenamiento,
aplicaciones y servicios) que pueden ser rápidamente aprovisionados con el mínimo esfuerzo
de gestión o interacción del proveedor del servicio”.

Podemos dividir en niveles o modelos de servicios más habituales, los cuales podemos
ver en la siguiente imagen.

Imagen N°4. Enterprise IT vs IaaS, PaaS y SaaS James Bond,2013

4.7. Software Cloud Computing

“En el caso del software como servicio, el proveedor no solo ofrece la infraestructura
hardware y los entornos de ejecución necesarios, sino también los productos software
que interaccionamos con el usuario desde un determinado portal o interfaz a través
de Internet”. (Viñals, 2012)

4.7.1. AWS

Según la página de Amazon Web Services esta se define de la siguiente manera:

“Amazon Web Services (AWS) es una plataforma segura de servicios en la nube que
ofrece potencia de cómputo, almacenamiento de bases de datos, entrega de contenido
y otras funcionalidades para ayudar a las empresas a crecer y crecer. Explore cómo
millones de clientes están aprovechando los productos y las soluciones en la nube
de AWS para crear aplicaciones sofisticadas con mayor flexibilidad, escalabilidad y
confiabilidad”.

30
 4.7.2. Google Cloud Plataform(GCP)

Según la página de Google, Google Cloud Plataform “te libera de los gastos
operativos relacionados con la administración de la infraestructura, el
aprovisionamiento de servidores y la configuración de redes. Así, los innovadores y
programadores de tu empresa pueden dedicarse a las tareas específicas de su
función”.

4.7.3. Microsoft Azure

De acuerdo a la página de Microsoft, “Microsoft Azure es conjunto en constante

expansión de servicios en la nube para ayudar a su organización a satisfacer sus
necesidades comerciales. Le otorga la libertad de crear, administrar e implementar
aplicaciones en una tremenda red mundial con sus herramientas y marcos favoritos”.

4.8. Contenedores Docker y Kubernets

4.8.1. Docker

Docker es una plataforma que permite empaquetar el software y las librerías y demás
componentes en unidades llamadas contenedores.

“Hace unos años, Docker apareció con una solución elegante para entrega inmutable.
Docker nos permite empacar nuestras aplicaciones con todas las dependencias que
necesita (SO, JVM, otra aplicación, dependencias, etc.) en un formato de imagen liviano
y en capas.” (Posta, Microservices for Java developers, 2016)

Según la página web de Red Hat los principales beneficios de los contenedores Docker
son los siguientes:

 Modularidad. El enfoque Docker para la creación de contenedores se centra en

la capacidad de tomar una parte de una aplicación, actualizarla o repararla, sin
tomar innecesariamente toda la aplicación. Además de estos enfoques basados en
microservicios, puede compartir procesos entre varias aplicaciones de la misma
forma que funciona la arquitectura orientada a servicios (SOA).

 Capas y control de versión de imagen. Cada archivo de imagen de Docker está

conformado por una serie de capas. Estas capas se combinan en una única imagen.
Una capa se crea cuando la imagen cambia. Cada vez que un usuario especifica
un comando, como ejecutar o copiar, se crea una nueva capa.

31
 Docker reutiliza estas capas para construir nuevos contenedores, lo cual hace
mucho más rápido el proceso de construcción. Los cambios intermedios se
comparten entre imágenes, mejorando aún más la velocidad, el tamaño y la
eficiencia. El control de versiones es inherente a la creación de capas. Cada vez
que hay un nuevo cambio, básicamente, usted tiene un registro de cambios
incorporado: control completo de sus imágenes de contenedor.

 Restauración. Probablemente la mejor parte de la creación de capas es la

capacidad de restaurar. Toda imagen tiene capas. ¿No le gusta la iteración actual
de una imagen? Restáurela a la versión anterior. Esto soporta un enfoque de
desarrollo ágil y ayuda a hacer realidad la integración e implementación continuas
(CI/CD) desde una perspectiva de herramientas.

 Implementación rápida. Solía demorar días desarrollar un nuevo hardware,

ejecutarlo, proveerlo y facilitarlo. Y el nivel de esfuerzo y sobrecarga era
extenuante. Los contenedores basados en Docker pueden reducir el tiempo de
implementación a segundos. Al crear un contenedor para cada proceso, puede
compartir rápidamente los procesos similares con nuevas aplicaciones. Y, debido
a que un SO no necesita iniciarse para agregar o mover un contenedor, los tiempos
de implementación son sustancialmente inferiores. Asimismo, con la velocidad
de implementación, puede crear y destruir datos creados por sus contenedores sin
preocupación, de forma fácil y accesible.

En retrospectiva la tecnología es una tecnología orientada a los microservicios de forma

granular que nos permite más eficiencia.

Imagen N°5. Funcionamiento de LXC vs Docker Red Hat

32
 4.8.2. Kubernetes

“Kubernetes (K8S) se define como un sistema open-source para la automatización de

despliegues, el escalado y la gestión de aplicaciones contenerizadas” (Fiz, 2017).

Siendo de este modo una plataforma donde podemos desplegar nuestros contenedores y asi
agilizar el trabajo y la eficiencia en producción.

Según la página web de Red Hat, con Kubernetes se puede:

 Orquestar contenedores en múltiples hosts.

 Hacer un mejor uso del hardware para maximizar los recursos necesarios para
ejecutar sus aplicaciones empresariales.

 Controlar y automatizar las implementaciones y actualizaciones de las aplicaciones.

 Montar y añadir almacenamiento para ejecutar aplicaciones con estado.

 Escalar las aplicaciones en contenedores y sus recursos sobre la marcha.

 Administrar servicios de forma declarativa, que garanticen que las aplicaciones

implementadas siempre se ejecuten del modo que las implementó.

 Comprobaciones de estado y autorregeneración de sus aplicaciones con ubicación,

reinicio, replicación y escalamiento automáticos.

Imagen N° 3. Funcionamiento de Kubernetes Red Hat

33
5. Bibliografía
40deFiebre. (s.f.). ¿Qué es el diseño responsive? Obtenido de 40deFiebre:
https://www.40defiebre.com/que-es/diseno-responsive/

Alvarez, C. (2018). ¿Qué es Spring Framework? Obtenido de genbetadev.com:

https://www.genbetadev.com/frameworks/que-es-spring-framework

Amazon. (2018). Amazon Web Services. Obtenido de https://aws.amazon.com/es/nosql/

Bond, J. (19 de Junio de 2013). mycloudblog7. Obtenido de mycloudblog7:

https://mycloudblog7.wordpress.com/2013/06/19/who-manages-cloud-iaas-paas-
and-saas-services/

CampusMVP. (4 de Diciembre de 2017). Qué son las arquitecturas sin servidor (Serverless
Computing) en la nube y por qué deberían interesarte. Obtenido de CampusMVP:
https://www.campusmvp.es/recursos/post/que-son-las-arquitecturas-sin-
servidor-serverless-computing-en-la-nube-y-por-que-deberian-interesarte.aspx

CISCO. (2 de Mayo de 2018). Campus LAN and Wireless LAN Design Guide. Obtenido de
CISCO:
https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/CVD-
Campus-LAN-WLAN-Design-Guide-2018JAN.pdf

CISCO. (14 de Mayo de 2018). TOP-DOWN Network Design. Obtenido de CISCO:

http://www.teraits.com/pitagoras/marcio/gpi/b_POppenheimer_TopDownNetwor
kDesign_3rd_ed.pdf

Club-BPM. (3 de Noviembre de 2009). Club-BPM.com. Obtenido de http://www.club-

bpm.com/ApuntesBPM/ApuntesBPM01.pdf

Domingo, J. (12 de Septiembre de 2017). Serverless en AWS, Azure y Google Cloud.

Obtenido de Ackstorm: https://www.ackstorm.com/serverless-aws-azure-google-
cloud/

Eisele, M. (2016). Modern Java EE Design Patterns . California: O'Reilly Media.

Fiz, J. M. (6 de Noviembre de 2017). ¿Por qué todos apuestan por Kubernetes? Obtenido
de paradigmadigital: https://www.paradigmadigital.com/techbiz/por-que-todos-
apuestan-por-kubernetes/

34
Heflo. (2015). ¿Qué es BPM? Obtenido de Heflo:
https://www.heflo.com/es/blog/bpm/que-es-bpm/

Íñigo, J. A. (10 de Marzo de 2017). ¿Qué es la Programación Reactiva? Una introducción.

Obtenido de Profile: https://profile.es/blog/que-es-la-programacion-reactiva-una-
introduccion/

McKee, H. (2016). Designing Reactive Systems. O’Reilly Media.

Nextu. (s.f.). CABLEADO ESTRUCTURADO: ¿QUÉ ES Y CUÁLES SON SUS ELEMENTOS?

Obtenido de Nextu: https://www.nextu.com/blog/cableado-estructurado-que-es-
y-cuales-son-sus-elementos/

PMQuality. (s.f.). Qué es el diseño UX ? Obtenido de PMQuality:

https://pmqlinkedin.wordpress.com/about/que-es-el-diseno-ux/

Posta, C. (2015). Microservices for Java Developers. California: O'Reily Media.

Posta, C. (2016). Microservices for Java developers. Sebastopol: O'Reilly.

Programacion.net. (s.f.). Introducción a la AOP (Programación Orientada al Aspecto).

Obtenido de Programacion.net:
https://programacion.net/articulo/introduccion_a_la_aop_programacion_orientad
a_al_aspecto_260

Richards, M. (2017). Software Architecture Patterns. California: O’Reilly Media.

Rouse, M. (Noviembre de 2012). Base de datos en memoria. Obtenido de Search Data

Center: https://searchdatacenter.techtarget.com/es/definicion/Base-de-datos-en-
memoria

Rouse, M. (Enero de 2015). Search Data Center. Obtenido de

https://searchdatacenter.techtarget.com/es/definicion/Base-de-datos-relacional

Ruelas, U. (18 de Mayo de 2017). ¿Qué es la programación orientada a aspectos (POA)?

Obtenido de Coding or not: https://codingornot.com/que-es-la-programacion-
orientada-a-aspectos-aop

Setrakyan, D. (26 de Febrero de 2015). Grid Gain. Obtenido de

http://gridgain.blogspot.pe/2015/02/emergence-of-in-memory-data-fabric.html

StackScale. (12 de Mayo de 2018). ¿Que es un DataCenter? Obtenido de StackScale:

https://www.stackscale.es/que-es-un-data-center/

35
That C# guy. (s.f.). La programación reactiva. Obtenido de That C# guy:
https://thatcsharpguy.com/tv/reactiva/

Viñals, J. T. (2012). Del cloudcomputing al bigdata. Barcelona: Eureca Media, SL.

Wikipedia. (Enero de 2017). Spring Framework. Obtenido de Wikipedia:

https://es.wikipedia.org/wiki/Spring_Framework

Wikipedia. (12 de Febrero de 2018). Arquitectura de microservicios. Obtenido de

Wikipedia: https://es.wikipedia.org/wiki/Arquitectura_de_microservicios

Wikipedia. (23 de Enero de 2018). Business Process Model and Notation. Obtenido de
Wikipedia: https://es.wikipedia.org/wiki/Business_Process_Model_and_Notation

Wikipedia. (4 de Mayo de 2018). Centro de Procesamiento de Datos. Obtenido de

Wikipedia: https://es.wikipedia.org/wiki/Centro_de_procesamiento_de_datos

Wikipedia. (4 de Mayo de 2018). Diseño web adaptable. Obtenido de Wikipedia:

https://es.wikipedia.org/wiki/Dise%C3%B1o_web_adaptable

Wikipedia. (20 de Abril de 2018). User experience design. Obtenido de Wikipedia:

https://en.wikipedia.org/wiki/User_experience_design

36