i n t e rf a z g rá f i ca mo st ra d a e n e l e ve n t o
Post on 07-Jul-2022
2 Views
Preview:
TRANSCRIPT
Migración de plataforma tecnológica basada en redes definidas por software para gestión de subestaciones eléctricas a una arquitectura
basada en microservicios
NILTON STEVEEN VÉLEZ GARCÍA
Informe final bajo la modalidad práctica empresarial presentado para
optar al título de: Ingeniero de Sistemas
Asesor interno: Ph.D. Juan Felipe Botero
Asesor Externo: Andrés Felipe Castaño Mazo
Departamento de Ingeniería de Sistemas
Facultad de Ingeniería Universidad de Antioquia
Medellín, Colombia 2019
TABLA DE CONTENIDO
Resumen 3
Introducción 4
Objetivos 10 Objetivo General 10 Objetivos específicos 10
Marco Teórico 10 Arquitectura de software 10 Arquitectura monolítica 12 Arquitectura cliente - servidor 14 Arquitectura de n-capas 17 Arquitectura orientada a servicios 18 Microservicios 19 Aspectos de calidad del software (ISO/IEC 25010) 21
Adecuación funcional: 22 Eficiencia de desempeño: 22 Compatibilidad: 22 Usabilidad: 23 Fiabilidad: 23 Seguridad: 23 Mantenibilidad: 24 Portabilidad: 24
Subestaciones eléctricas 25 IEC 61850 25 Redes definidas por software 26
Metodología 26 Fase de análisis 26
Necesidades y/o problemas encontrados: 27 Alcance del proyecto: 28 Funcionamiento inicial de la aplicación: 28
Fase de diseño 29 Exploración de tecnologías: 29 Diseño de arquitectura: 31 Diseño de base de datos 33 Diagramas de flujo: 34 Mockups: 34
Fase de implementación 35 Fase de pruebas 36
1
Resultados y análisis 36 Interfaz gráfica mostrada en el evento 61850: 36 Proyecto realizado con microservicios y ONOS: 42 Pruebas de aceptación: 45 Resultados y opiniones en el evento 61850: 46
Conclusiones 47
Referencias Bibliográficas 49
2
Resumen La automatización de tareas y procesos ha madurado gracias a innovaciones tecnológicas por ejemplo en los campos de la robótica y la inteligencia artificial logrando en la mayoría casos más eficiencia o mayor precisión. En el campo del desarrollo de software nace un concepto nuevo denominado DevOps donde los equipos de desarrollo y operaciones ya no están "aislados" y donde los ingenieros desarrollan un rango de habilidades que no están limitadas a una sola función. Ahora bien para el caso del campo de las redes de datos en los últimos 20 años no han sido muchos los avances y éstos se han limitado sólo a innovaciones en el hardware, por lo que el enrutamiento o envío de paquetes sigue siendo igual que antes, lo que ha generado un gran problema en su administración, debido a que las redes han crecido gracias a que más personas siguen teniendo acceso a la red. Afortunadamente en los últimos años surgió un nuevo paradigma denominado redes definidas por software que gracias a que separa el plano de datos del plano de control (éste se le da a una aplicación de software llamado controlador), es posible cumplir con el objetivo de centralizar y automatizar una red dando un paso firme hacia la creación de redes inteligentes. Una gran diversidad de redes de comunicaciones se pueden diferenciar en la actualidad, sin embargo una aplicación interesante bajo el marco de las redes definidas por software y que ha sido abordada durante los últimos años gracias al trabajo conjunto de compañías e instituciones como la Universidad de Antioquia, Colciencias, Ruta N o Kinnesis S.A.S, son las redes en las subestaciones eléctricas, dando como resultado una plataforma web para la gestión de dichas subestaciones. La aplicación desarrollada contaba entonces con un controlador capaz de comunicarse con un concentrador comercial de subestación, para alcanzar ciertas funciones de automatización, e incluía una interfaz web donde el personal de la subestación podía realizar tareas de configuración y gestión sobre la red; sin embargo después de múltiples pruebas y ser mostrado en diferentes empresas del sector eléctrico a nivel nacional e internacional se determinó que una buena opción para este tipo de aplicación que podía seguir escalando y además ofrecía funcionalidades específicas, era desarrollarla bajo una arquitectura basada en microservicios, debido a que el fallo en algún componente estaba afectando la disponibilidad de toda la aplicación en general, al tratarse de una aplicación monolítica. De esta manera nació este proyecto con el objetivo de migrar las funcionalidades a pequeños módulos y separar el front-end del back-end. Por el lado del
3
front-end se logró cambiar la interfaz gráfica añadiendo ese aspecto de calidad correspondiente a la usabilidad y del lado del back-end se desarrollaron microservicios para topología, usuarios y dispositivos utilizando ONOS como controlador para revisar su correcto funcionamiento. La plataforma fue presentada en un evento a nivel internacional que reunió a más de 150 expertos en la norma IEC 61850 acaparando el interés de grandes compañías del sector eléctrico para posibles alianzas y ventas. Introducción El crecimiento de las redes informáticas o redes de computadores desde su origen ha estado estrechamente relacionado con 2 factores fundamentales como lo son la necesidad de comunicación o transmisión de la información, y el desarrollo de nuevas y avanzadas tecnologías para dicho propósito. Esos avances no se detienen y van aumentando a medida que pasa el tiempo como un efecto de “bola de nieve” y es por eso que la población mundial ha podido percibir como se ha pasado rápidamente del invento de las supercomputadoras y transistores, a tener en la actualidad computadoras personales y dispositivos inteligentes que a través de las redes interconectadas cumplen con el propósito de comunicar o intercambiar información. Ahora bien, todos los tipos de redes (campus, data center, etc) están creciendo a grandes velocidades a medida que más personas con más dispositivos se están conectando y accediendo a una creciente cantidad de datos, y como se menciona en [1], ésto no está del todo mal con el usuario final o los desarrolladores de software, en primer lugar debido a que el que hace uso de la información solo cumple el rol de consumidor y por el otro lado para el desarrollador de software de la actualidad nace un nuevo concepto denominado DevOps que según [3], es un conjunto de prácticas que automatiza los procesos entre el desarrollo y los equipos de TI logrando de esta manera poder construir, probar y desplegar de una forma más rápida y segura, y que gracias a los servicios basados en la nube ([4] PaaS, SaaS, Iaas) no se necesita ser un experto en infraestructura para configurar las aplicaciones y finalmente el desarrollador sería un consumidor más de los proveedores de servicios de la nube (Google, AWS, Azure, etc). Según lo mencionado anteriormente tanto el usuario final como los desarrolladores no tienen mucho de qué preocuparse sobre dónde y cómo se están administrando los datos ya que estos procesos tienden a automatizarse y ser transparentes para ellos. Ahora bien surge la duda entonces sobre quién o quiénes son los que hacen que la información esté disponible en todo momento y lugar y también como lo hacen. Para conocer o dar respuesta a esta inquietud hay que entender cómo funcionan las redes de comunicaciones en la actualidad; por ejemplo en la figura 1 tomada de [2], se puede ver una red básica y donde se
4
pueden identificar diversos equipos como switches, routers, firewall o host, con el propósito de transmitir información entre los equipos terminales o con motivos de seguridad para la red, y, según la configuración de éstas redes, propósito y ubicación hoy en día se pueden ver diversos tipos: LAN, WAN, PAN, CAN, VLAN, etc [5].
figura 1. Componentes de una red ethernet [2].
Como se puede ver en [6] el avance en el campo de las redes se debe al avance de grandes tecnologías como el internet, los enrutadores, ethernet, firewall, vlan y el wifi, sin embargo, puede verse que todos estos cambios se fueron dando hasta el fin de siglo, es decir que en 20 años no han sido muchos los avances en redes y como se mencionó anteriormente cada vez hay más personas conectadas y con más dispositivos, lo que ha generado un crecimiento a gran escala de las redes, y por ende ha crecido la complejidad de mantenerlas. Como puede verse en la figura 2, los grandes proveedores de servicios en la nube tienen instalaciones ‘gigantescas’ las cuales están distribuidas en todo el planeta, lo que nos hace preguntar cuánto más pueden crecer y hasta qué punto va a ser posible continuar administrando las redes de la misma manera sin llegar al extremo de continuos colapsos en la red o que ésta se convierta en un cuello de botella.
5
figura 2. Centro de datos de Google en Los Ángeles [8].
Los grandes proveedores han entendido éste gran problema y es por ello que se han generado nuevas alternativas o tecnologías, entre ellas las redes definidas por software (SDN por sus siglas en inglés) que es una tecnología que busca centralizar, automatizar y depurar una red. Empresas como Google o AWS como se menciona en [9], están utilizando SDN para crear de manera eficiente nubes privadas, públicas e híbridas para aumentar la agilidad de implementación de aplicaciones y responder mejor a las necesidades comerciales; sin embargo durante los últimos 20 años los grandes proveedores de equipos (enrutadores, conmutadores) han diseñado equipos con la misma filosofía (para enrutamiento, tráfico de red, seguridad) por lo que el software sigue siendo propiedad intelectual de dichas empresas. Ésta fue bien percibida por Nick McKeown científico informático de Stanford quien junto a sus colegas desarrollaron un estándar denominado OpenFlow con el cual es posible definir los flujos de datos mediante software, brindando de esta manera acceso a las tablas de flujo y reglas que le indican a los conmutadores y enrutadores como dirigir el tráfico de red [31]. Básicamente las redes definidas por software consisten entonces en separar el hardware encargado de reenviar los paquetes de las decisiones de control, o lo que se conoce comúnmente como el plano de datos y plano de control. En la figura 3 que se muestra a continuación, es posible ver que en SDN todo el plano de control es centralizado en un solo componente el cual de ahora en adelante es denominado el controlador, el cual es quien lleva la ‘inteligencia’ de la red y se encarga de proporcionar esas reglas a los switches o routers, que ahora sólo se convierten en simples emisores del controlador y hacen el trabajo habitual de reenvío de paquetes solo que bajo las órdenes o lógica implementada en dicho controlador [11].
6
figura 3. Red tradicional vs Red definida por software [10].
Por otro lado el controlador de SDN no sólo cumple con la función de gestionar un amplio rango de recursos del plano de datos o de hacer que la red sea mucho más abierta, flexible, escalable y reprogramable, si no que también ofrece una serie de API que permite a los servicios y aplicaciones simplificar y automatizar las tareas de configuración, provisión y gestionar nuevos servicios en la red, ofreciendo a los operadores nuevas vías de ingresos, diferenciación e innovación [12]. De acuerdo a ésto y gracias a nuevas versiones del protocolo OpenFlow, que ha permitido nuevas funcionalidades como tunelización, NAT, medición, etc, es posible hoy en día generar nuevas y novedosas aplicaciones para la gestión de redes. Según [11,13] esas aplicaciones se pueden categorizar dependiendo de la función que realizan como aplicaciones de seguridad, calidad de servicio (QoS), ingeniería de tráfico (TE), gestión de las listas de control de acceso (ACL), balanceo de carga, servicios en ambientes específicos como la computación en la nube, las redes móviles, la virtualización de la red y la virtualización de las funciones de red (NFV). Ahora bien un enfoque diferente el cual puede ser abordado usando SDN son las redes de las subestaciones eléctricas, o como se menciona de aquí en adelante subestación definida por software (SDS por sus siglas en inglés), el cual nació y se ha venido implementado en el Grupo de Investigación de Telecomunicaciones Aplicadas (GITA) de la Universidad de Antioquia [32]; en la figura 4 mostrada a continuación se puede observar que SDS inicialmente fue concebido como una investigación y un prototipo, y no fue sino hasta el año 2015 donde se
7
concibe un proyecto denominado “Redes definidas por software (SDN) como habilitador de tecnologías de redes inteligentes para el sector energía eléctrica” desarrollado gracias al aval de la Universidad de Antioquia y los recursos otorgados por Colciencias, donde se pudo construir un aplicativo de software básico, compuesto por un controlador SDN y una interfaz de usuario con funcionalidades mínimas, que permitió corroborar la utilidad de SDN en las redes de datos de las subestaciones eléctricas. Posteriormente, al verificar la adaptabilidad de SDN con las subestaciones eléctricas se ejecuta un nuevo proyecto nombrado “Plataforma tecnológica de redes inteligentes para el sector energía, habilitada por redes definidas por software (SDN)” donde participaron RutaN como promotor del proyecto e igualmente el Grupo de Investigación de Telecomunicaciones Aplicadas GITA, a través de la Universidad de Antioquia, y la empresa Kinnesis Solutions como principales proponentes [15], el cual tiene como principal objetivo la mejora del aplicativo del proyecto anterior, con un controlador más robusto, que pueda comunicarse con un concentrador comercial de subestación para alcanzar ciertas funciones de automatización, y que incluya una interfaz web desde donde el personal de la subestación pueda realizar tareas de configuración y gestión sobre la red.
figura 4. Línea de tiempo de SDS.
Finalmente nace un nuevo proyecto denominado “Desarrollo de plataforma web para gestión de subestaciones eléctricas, basadas en redes definidas por software” cuyo principal propósito era el desarrollo de una plataforma web construída sobre un entorno SDN, que obedeció a la idea de administrar la red de datos de las subestaciones a través de una interfaz a alto nivel. En dicho proyecto se incluyó la visita a cuatro empresas del sector energético ‒ tres del exterior y una regional‒, en donde se desplegó el sistema y se recogieron nuevas necesidades y requisitos específicos para retroalimentación en general de toda la plataforma. Precisamente de dicha retroalimentación se da origen a la propuesta de práctica empresarial para el presente informe el cual consiste primordialmente en mejorar en los aspectos de calidad
8
de software, puesto que se evidenciaron falencias en algunas funcionalidades cuando fueron puestas a prueba en ambientes reales. El objetivo principal de esta manera es proporcionar del mismo modo una aplicación web que reúna los requisitos del proyecto inmediatamente anterior y que tenga consigo los más importantes aspectos de calidad del software como lo son la eficiencia, usabilidad fiabilidad y mantenibilidad. Con este objetivo trazado se decide cambiar la arquitectura del sistema, que en el momento es monolítica por una basada en microservicios, ya que cada función dentro del sistema (descubrimiento de topología, dispositivos, usuarios, slices, estadísticas, seguridad, flujos ,etc), pueden ser tratados como servicios individuales con el propósito de proporcionar al sistema modularidad, escalabilidad o contenedores para un despliegue más rápido. Del mismo modo se opta por cambiar la interfaz gráfica por una en la que se use una tecnología más reciente para el front-end aprovechando las ventajas de las aplicaciones de una sola página añadiendo al usuario una mejor percepción visual y un mejor manejo de la plataforma en general. Por último se opta por cambiar también el controlador de SDN por uno que presente menos fallas en algunas de las funcionalidades del sistema y que del mismo modo posea las mismas ventajas que se tenían con el anterior controlador. Cabe destacar que el proyecto actual tiene como objetivo principal mejorar en aspectos de calidad, por lo que el desarrollo no se basa en crear nuevas funcionalidades hasta no tener una versión estable y debidamente probada que incluya todas aquellas con las que contaba el anterior proyecto, sin embargo es importante destacar el hecho de que la plataforma igualmente se seguirá mostrando en diferentes eventos por lo que objetivos como el de mejorar la interfaz gráfica deben estar incluidos en el antiguo proyecto mientras se va haciendo la migración del mismo. Por ejemplo, el evento se mostró en el evento 61850 Global llevado a cabo en Berlín Alemania, que reúne a más de 150 especialistas en IEC 61850 y líderes de implementación de todo el mundo, razón por la cual el desarrollo por el lado lado del backend se vió afectado para prestar mayor atención en el front-end. Para la correcta elaboración de este proyecto no se consideraron nuevos requisitos funcionales ya que como se dijo anteriormente la prioridad en el momento es mejorar en los aspectos o falencias que se pudieron evidenciar en las visitas que se realizaron en las 4 compañías eléctricas, sin embargo se hizo necesario redefinir la arquitectura general del sistema para que sea modular e incluir el nuevo controlador SDN. Para la interfaz gráfica se diseñaron mockups con la finalidad de tener resultados mucho más rápidos y acordes a las necesidades encontradas. Ahora bien, para llevar a cabo el diseño e implementación de la aplicación se va a continuar bajo el marco de trabajo de las metodologías ágiles ya que como se menciona en [16]
9
esta metodología ha sido aceptada por la industria como una mejor solución para el desarrollo de proyectos. De este modo se utiliza la metodología ágil denominada “programación extrema” (XP por sus siglas en inglés) debido a que se enfoca en potenciar las relaciones interpersonales, promoviendo el trabajo en equipo y además es iterativa e incremental, por lo que se tiene retroalimentación continua entre el cliente y el equipo de desarrollo; además, se adecua perfectamente al proyecto debido a que los requisitos pueden ser muy cambiantes o imprecisos en el tiempo. Por otro lado, es oportuna para la idea de negocio debido a que el cliente decide lo que quiere y el trabajo es dividido en acciones pequeñas y se le asigna un tiempo a cada una. Éstas acciones son priorizadas por el cliente y el equipo de desarrollo realiza lo que el cliente ha decidido Objetivos Objetivo General Desarrollar una plataforma web que optimice la gestión y configuración de la red de las subestaciones eléctricas bajo una arquitectura modular. Objetivos específicos Realizar una fase de diseño en la cual se incluya el diseño de la arquitectura, el modelo de datos y mockups de la aplicación. Implementar una aplicación web de acuerdo a las especificaciones obtenidas en el objetivo específico 1. Verificación y validación de la correcta integración y operación de todo el sistema, mediante la realización de diferentes pruebas de funcionalidad y comunicación entre sus componentes, tanto en ambientes simulados como reales. Marco Teórico Arquitectura de software En la etapa de diseño de software, definir una arquitectura para el sistema al igual que en los planos de obras en construcción, es de vital importancia, debido a que del mismo modo, ayuda a estructurar, definir el funcionamiento e interacción de los componentes del sistema y crea una base sólida para el proyecto de software para garantizar que sea escalable y poderoso.
10
A través de la historia se han dado grandes avances tecnológicos que han hecho evolucionar la forma de estructurar las aplicaciones en la actualidad. A continuación en la figura 5 es posible ver una línea de tiempo resumida del avance en el campo de la arquitectura de software que se remonta desde la aparición de la programación no estructurada hasta los proyectos basados en microservicios.
figura 5. Línea de tiempo de la arquitectura de software [Fuente propia].
11
Arquitectura monolítica Este tipo de arquitectura como lo dice su nombre consta o se compone de una sola pieza, por lo que está diseñada para ser autónoma, por consiguiente los componentes del programa están interconectados e interdependientes en lugar de estar débilmente acoplados, como es el caso de los programas de software modulares. Del mismo modo cada componente y sus componentes asociados deben estar presentes para que el código sea ejecutado o compilado, por consiguiente para cada cambio o actualización del sistema es necesario compilar e implementar una versión actualizada del sistema. Ahora bien, una aplicación puede estar dividida por muchos componentes, entre los principales encontramos la base de datos, front-end o back-end por lo que este tipo de arquitectura obedece a los servicios que dichos componentes ofrecen y no depende de otros servicios fuera de este sistema aparte de la integración con otras aplicaciones como por ejemplo a través de REST. En la figura 6 tomada de [17] se puede evidenciar de una mejor manera como los principales componentes están acoplados en la aplicación y entre ellos se pueden comunicar para el correcto funcionamiento del sistema.
figura 6. Componentes de una arquitectura monolítica [17].
Las ventajas de acuerdo a lo mencionado anteriormente de este tipo de arquitectura serían las siguientes [18,19]:
12
- Fácil de desarrollar: Al comienzo de un proyecto, es mucho más
fácil ir con la arquitectura monolítica. - Sencillo de probar - Simple de implementar: Hay que copiar la aplicación
empaquetada a un servidor. - Simple para desplegar - Menos costosas: Debido a la simpleza de su estructura, el
desarrollo de aplicaciones monolíticas suele ser menos costoso que otras.
Por otro lado también se tienen desventajas:
- Mantenimiento: Se presenta en el momento en que la aplicación ya es demasiado grande y compleja de comprender por completo, debido a que realizar nuevos cambios de manera rapida y correcta suele ser un desafío.
- El tamaño de la aplicación puede ralentizar el tiempo de inicio. - Debe volver a implementar la aplicación completa en cada
actualización. - Las aplicaciones monolíticas también pueden ser difíciles de
escalar cuando diferentes módulos tienen requisitos de recursos en conflicto.
- Confiabilidad: Un error en cualquier módulo (por ejemplo, pérdida de memoria) puede potencialmente desbaratar todo el proceso. Además, dado que todas las instancias de la aplicación son idénticas, ese error afecta la disponibilidad de toda la aplicación independientemente de lo fáciles que puedan parecer las etapas iniciales, las aplicaciones monolíticas tienen dificultades para adoptar tecnologías nuevas y avanzadas. Dado que los cambios en los lenguajes o marcos afectan a una aplicación completa, requiere esfuerzos para trabajar a fondo con los detalles de la aplicación, por lo tanto, es costoso considerando tanto el tiempo como los esfuerzos.
13
Arquitectura cliente - servidor
figura 7. Arquitectura cliente-servidor [20].
Según IBM la arquitectura cliente-servidor es la tecnología que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la organización, en múltiples plataformas. El modelo soporta un medio ambiente distribuido en el cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o "clientes, resultan en un trabajo realizado por otros computadores llamados servidores. En la figura 7 tomada de [20] se puede observar una pequeña representación de este tipo de arquitectura, donde se pueden identificar diversos elementos que la componen y que nos ayudan a entender de una mejor manera el funcionamiento en general de las aplicaciones cliente-servidor. Como se puede observar se tiene un elemento denominado servidor que como su nombre lo dice viene de la palabra servir, es decir que puede ser una máquina para la función de alojar archivos o también un software instalado en un máquina que sirve a las páginas web (denominado servidor web). Un servidor tiene que ser una máquina con especificaciones considerables que atiende a requerimientos específicos de clientes, por lo que puede manejar un número considerable de peticiones de acuerdo al número de clientes que solicitan algún servicio. Comúnmente al servidor también se le llama back-end y la interfaz para interactuar con el usuario no debe ser muy sofisticada dentro del mismo, debido a que la comunicación se hace a través de la interfaz gráfica del cliente.
14
Por otro lado se tiene el componente cliente, en la actualidad denominado front-end, que normalmente reside en el computador del usuario (generalmente un navegador web), es decir que puede ser cualquier dispositivo que esté conectado a la red (computador, móvil, etc) y es quien solicita algún servicio del servidor comúnmente desde una interfaz gráfica [20]. Ahora bien de acuerdo a la figura 7 faltaría darle significado a las solicitudes o respuestas que existen entre los clientes y el servidor y es que en la actualidad esta comunicación es posible gracias al protocolo HTTP que sirve para transferir archivos a través de la world wide web y que se ejecuta sobre el conjunto de protocolos TCP/IP. A lo largo de los años se han desarrollado algunos protocolos y tecnologías para el intercambio de datos o archivos. En un principio el protocolo más usado fue el protocolo simple de acceso a objetos (SOAP por sus siglas en inglés), el cual puede funcionar con cualquier protocolo de la capa de aplicación (HTTP, SMTP, TCP, UDP) y devuelve los datos al receptor o cliente en un formato XML, éste protocolo es el más usado en entornos empresariales distribuidos debido a que la seguridad, la autorización y el manejo de errores están incorporados en el protocolo y no asume una comunicación directa de punto a punto. Por otro lado en los últimos años ha cogido una gran fuerza el uso de un estilo arquitectónico denominado “Transferencia de estado representacional” (REST por sus siglas en inglés), que define un conjunto de recomendaciones para el diseño de aplicaciones de acoplamiento flexible que utilizan el protocolo HTTP para la transmisión de datos. REST no prescribe cómo implementar los principios en un nivel inferior. En cambio, las pautas de REST permiten a los desarrolladores implementar los detalles de acuerdo con sus propias necesidades [21]. Ventajas de un sistema cliente/servidor [22]:
- Centralización del control: El servidor dedicado controla el acceso, los recursos y la integridad de los datos para que un programa o cliente no autorizado no pueda dañar el sistema.
- Escalabilidad : puede aumentar la capacidad de los clientes y servidores por separado.
- Fácil mantenimiento : Distribución de las funciones y responsabilidades a varias computadoras independientes, puede reemplazar, reparar, actualizar o incluso mover un servidor, mientras que los clientes no se verán afectados por ese cambio (o afectarán de manera mínima). Esta independencia de los cambios también se conoce como encapsulación.
15
- Existen tecnologías suficientemente desarrolladas, diseñadas para el paradigma de C/S para garantizar la seguridad en las transacciones, la facilidad de uso de la interfaz y la facilidad de uso.
Desventajas de un sistema cliente/servidor [22]:
- El tráfico de red siempre ha sido un problema en el paradigma de C/S. Cuando una gran cantidad de clientes simultáneos envían solicitudes al mismo servidor, esto puede causar muchos problemas (directamente proporcional: a más clientes - más problemas para el servidor).
- El software y el hardware de un servidor son generalmente muy decisivos. Es posible que un personal de hardware de computadoras no pueda atender a un cierto número de clientes. Por lo general, necesita software y hardware específicos, especialmente en el lado del servidor, para cumplir con el trabajo. Por supuesto, esto aumentará el costo.
Las arquitecturas cliente/servidor han evolucionado como se puede ver en la figura 8 por lo que frecuentemente se pueden ver variaciones de acuerdo al número de capas que incorpora. Un sistema basado en capas es un sistema jerárquico donde cada capa provee servicios a la capa superior y es servido por la capa inferior e igualmente cada componente corresponde a cada capa y la comunicación entre ellas al igual que como se explicó con el modelo cliente/servidor se da a través de protocolos, sin embargo esta comunicación solo se puede dar entre las capas adyacentes. Para comprender mejor esta afirmación véase la figura 8 en donde se pueden identificar tres unidades funcionales fundamentales: lógica de presentación o interfaz de usuario, lógica de negocios y lógica de datos. Existen entonces 2 variaciones, por ejemplo en las aplicaciones cliente/servidor de 2 niveles, donde la lógica de negocios está oculta dentro de la interfaz de usuario en el cliente o dentro de la base de datos en el servidor en forma de procedimientos almacenados. Alternativamente, la lógica de negocios puede dividirse entre el cliente y el servidor. Los servidores de archivos y los servidores de bases de datos con procedimientos almacenados son ejemplos de arquitectura de 2 niveles. Por otro lado en aplicaciones cliente/servidor de 3 niveles, la lógica de negocios reside en el nivel medio, separada de los datos y la interfaz de usuario. De esta manera, los procesos se pueden administrar y desplegar por separado desde la interfaz de usuario y la base de datos. Además, los sistemas de 3 niveles pueden integrar datos de múltiples fuentes.
16
figura 8. Arquitectura cliente-servidor de 2 y 3 capas[23].
Arquitectura de n-capas En la figura 5 igualmente se puede evidenciar que en la arquitectura cliente/servidor también es posible extender de 1,2 ó 3 capas a ‘N’ número de éstas, y de ésta manera es posible diferenciar entre lógica de presentación y de aplicación. Según [24] la arquitectura de ‘N’ capas es también llamada arquitectura de múltiples niveles porque el software está diseñado para tener las funciones de procesamiento, gestión de datos y presentación separadas física y lógicamente. Esto significa que estas diferentes funciones se alojan en varias máquinas o clústeres, lo que garantiza que los servicios se brindan sin compartir los recursos y, como tales, estos servicios se entregan a la máxima capacidad. Esta arquitectura al igual que en 1, 2 ó 3 capas implica dividir la aplicación en los 3 niveles:
● Capa de presentación: El nivel más alto de la aplicación es la interfaz de usuario. La función principal de la interfaz es la traducción de tareas y resultados a algo que el usuario pueda entender.
● Capa de lógica o negocios: Esta capa se encarga de coordinar la aplicación, procesa comandos, realiza decisiones lógicas y evaluaciones y realiza cálculos como también mueve y procesa datos entre las 2 capas adyacentes.
17
● Capa de datos: En esta capa es donde la información es almacenada y recuperada desde una fuente de datos (base de datos, archivos, etc) para luego ser pasada de regreso a la capa de negocio para su procesamiento y así ser luego devuelta al usuario final o cliente quien realizó dicha solicitud.
Ventajas de la arquitectura a ‘N’ capas:
- Seguro: Puede asegurar cada uno de los tres niveles por separado utilizando diferentes métodos.
- Fácil de administrar: Puede administrar cada nivel por separado, agregando o modificando cada nivel sin afectar los otros niveles.
- Escalable: Si necesita agregar más recursos, puede hacerlo por nivel, sin afectar los otros niveles.
- Flexible: Además de la escalabilidad aislada, también puede expandir cada nivel de la manera que lo requieran sus requisitos.
Es decir que con la arquitectura de n niveles, es posible adoptar nuevas tecnologías o agregar más componentes y funcionalidades sin tener que volver a diseñar e implementar todo el software, facilitando de esta manera el escalamiento y mantenimiento del mismo y, por otro lado, en cuanto al tema de la seguridad se puede almacenar información sensible o confidencial en el nivel lógico, manteniéndola alejada del nivel de presentación, lo que lo hace más seguro. Arquitectura orientada a servicios Una arquitectura orientada a servicios (SOA) es un patrón de arquitectura de software, cuyos componentes de aplicaciones proporcionan servicios a otros componentes a través de un protocolo de comunicaciones a través de una red. La comunicación puede involucrar el paso simple de datos o podría involucrar dos o más servicios que coordinen servicios de conexión entre sí. De esta manera, en una SOA existen 2 roles principales: el proveedor y consumidor de servicios, en donde se usa un Enterprise Service Bus para la comunicación punto a punto. La capa de consumidor es el punto donde los consumidores (usuarios humanos, otros servicios o terceros) interactúan con la SOA y la capa de proveedor consta de todos los servicios definidos dentro de la SOA. La figura 9 muestra una vista rápida de una arquitectura SOA.
18
figura 9. Arquitectura SOA[25].
Microservicios Cuando se habla de microservicios, más que un tipo de arquitectura es mejor visto como un estilo arquitectónico debido a que los componentes de la aplicación son aplicaciones independientes de su propiedad y se pueden comunicar entre sí mediante RMI (Invocación de método remoto), servicios web Restful o mensajería push. Además estas pequeñas aplicaciones independientes pueden considerar o configurar su propia arquitectura, por ejemplo un microservicio para la administración de usuarios de una aplicación puede tener una arquitectura cliente-servidor de n capas y ser implementado con python y un modelo de datos no relacional, mientras que un microservicio para la misma aplicación para la gestión de compras podría tener un tipo de arquitectura totalmente diferente, codificado en JavaScript y con un modelo de datos relacional por ejemplo. Teniendo en cuenta lo dicho anteriormente es fundamental que cada microservicio sea totalmente independiente del resto y que de esta manera se puedan cambiar, eliminar o actualizar fácil y rápidamente sin afectar a toda la aplicación como sucede en el caso del monolítico,
19
además la gobernanza descentralizada de los servicios permite a los desarrolladores utilizar diferentes lenguajes de programación o modelos de datos por lo que la escabilidad es casi ilimitada [25]. Como los servicios son muy pequeños, las aplicaciones cliente por lo general necesitan interactuar con múltiples servicios para obtener la información solicitada, por tal motivo se utiliza un API Gateway, que es una capa abstracta que oculta todos los microservicios y al llegar una solicitud desde el cliente el Gateway la procesa y luego enruta hacia los servicios específicos como puede verse en la figura 10.
figura 10. Arquitectura basada en microservicios. [36]
Ventajas de los microservicios [27]:
- Cada servicio se puede desarrollar en el lenguaje que mejor se adapte a los requisitos
- El microservicio es lo más independiente y pequeño posible por lo que el desarrollador tendrá mejor conocimiento y entendimiento del código
- No hay una base de datos centralizada (esta es una de las grandes diferencias con SOA)
- Cuando un servicio necesita hablar con otro servicio, pueden hablar mediante API, específicamente mediante un servicio REST. Un servicio REST es el medio para comunicarse, por lo que hay poca transformación
- Escabilidad
20
Desventajas de los microservicios [26]:
- Los microservicios al disminuir la complejidad de la administración del equipo puede también disminuir la comunicación, por lo que la modificación de un servicio puede afectar la funcionalidad de muchos otros y la comunicación es un aspecto clave para la solución de este tipo de problemas.
- Aplicación no uniforme: El tener libertad de escoger las tecnologías para cada microservicio también puede generar problemas y puede aumentar los costos de mantenimiento a largo plazo.
- Mayor uso de recursos: la inversión inicial para ejecutar estas aplicaciones es alta porque todos los componentes que se ejecutan de forma independiente necesitan sus propios contenedores de tiempo de ejecución con más memoria y CPU.
- Complejidad Dev-Ops: Se debe tener un equipo maduro para manejar la complejidad del despliegue de una aplicación basada en microservicios.
Aspectos de calidad del software (ISO/IEC 25010) Cómo lo describe la norma ISO/IEC 25010 [28], la calidad de software puede entenderse como el grado en el que un producto satisface las necesidades del usuario aportando de esta manera un valor (comercial por ejemplo). Esos requisitos (funcionalidad, mantenibilidad, fiabilidad, etc) son precisamente los que se encuentran representados en el modelo de calidad. Según la ISO/IEC 25010 el modelo de calidad del producto de software se encuentra compuesta por las 8 características de calidad mostradas a continuación en la figura 11:
figura 11. Arquitectura basada en microservicios [28].
21
Adecuación funcional: Esta característica representa la capacidad del producto de software para proporcionar funciones que satisfacen los requisitos declarados e implícitos, cuando el producto se usa en las condiciones especificadas. Como se ve en la figura 11 esta característica se subdivide a su vez en las siguientes subcaracterísticas:
● Completitud funcional. Grado en el cual el conjunto de funcionalidades cubre todas las tareas y los objetivos del usuario especificados.
● Corrección funcional. Capacidad del producto o sistema para proveer resultados correctos con el nivel de precisión requerido.
● Pertinencia funcional. Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.
Eficiencia de desempeño: Esta característica representa el desempeño relativo a la cantidad de recursos utilizados bajo determinadas condiciones. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
● Comportamiento temporal. Los tiempos de respuesta y procesamiento y los ratios de throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas en relación con un banco de pruebas (benchmark) establecido.
● Utilización de recursos. Las cantidades y tipos de recursos utilizados cuando el software lleva a cabo su función bajo condiciones determinadas.
● Capacidad. Grado en que los límites máximos de un parámetro de un producto o sistema software cumplen con los requisitos.
Compatibilidad: Capacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
● Coexistencia. Capacidad del producto para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes sin detrimento.
● Interoperabilidad. Capacidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada.
22
Usabilidad: Capacidad del producto software para ser entendido, aprendido, usado y resultar atractivo para el usuario, cuando se usa bajo determinadas condiciones. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
● Capacidad para reconocer su adecuación. Capacidad del producto que permite al usuario entender si el software es adecuado para sus necesidades.
● Capacidad de aprendizaje. Capacidad del producto que permite al usuario aprender su aplicación.
● Capacidad para ser usado. Capacidad del producto que permite al usuario operarlo y controlarlo con facilidad.
● Protección contra errores de usuario. Capacidad del sistema para proteger a los usuarios de hacer errores.
● Estética de la interfaz de usuario. Capacidad de la interfaz de usuario de agradar y satisfacer la interacción con el usuario.
● Accesibilidad. Capacidad del producto que permite que sea utilizado por usuarios con determinadas características y discapacidades.
Fiabilidad: Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
● Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones normales.
● Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible para su uso cuando se requiere.
● Tolerancia a fallos. Capacidad del sistema o componente para operar según lo previsto en presencia de fallos hardware o software.
● Capacidad de recuperación. Capacidad del producto software para recuperar los datos directamente afectados y restablecer el estado deseado del sistema en caso de interrupción o fallo.
Seguridad: Capacidad de protección de la información y los datos de manera que personas o sistemas no autorizados no puedan leerlos o modificarlos. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
23
● Confidencialidad. Capacidad de protección contra el acceso de datos e información no autorizados, ya sea accidental o deliberadamente.
● Integridad. Capacidad del sistema o componente para prevenir accesos o modificaciones no autorizados a datos o programas de ordenador.
● No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de manera que dichas acciones o eventos no puedan ser repudiados posteriormente.
● Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una entidad.
● Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.
Mantenibilidad: Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
● Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de componentes discretos) que permite que un cambio en un componente tenga un impacto mínimo en los demás.
● Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un sistema software o en la construcción de otros activos.
● Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o identificar las partes a modificar.
● Capacidad para ser modificado. Capacidad del producto que permite que sea modificado de forma efectiva y eficiente sin introducir defectos o degradar el desempeño.
● Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se cumplen dichos criterios.
Portabilidad: Capacidad del producto o componente de ser transferido de forma efectiva y eficiente de un entorno hardware, software, operacional o de
24
utilización a otro. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
● Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y eficiente a diferentes entornos determinados de hardware, software, operacionales o de uso.
● Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o desinstalar de forma exitosa en un determinado entorno.
● Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en lugar de otro producto software determinado con el mismo propósito y en el mismo entorno.
Subestaciones eléctricas Una subestación consiste de un gran número de conmutadores y equipos usados en la transmisión de electricidad, los cuales son controlados, supervisados y protegidos por un sistema de automatización de subestaciones (SAS), el cual se encarga de proveer todas las funciones requeridas para la operación confiable y segura de toda la subestación. Estos sistemas de automatización están conformados por un equipo de dispositivos electrónicos inteligentes (IEDs por sus siglas en inglés) y la red de comunicaciones entre ellos. Estos equipos implementan tareas de control, protección y monitoreo sobre el sistema de potencia. Básicamente para el intercambio de datos, todos los IEDs son conectados a través de TCP/UDP e IP, sobre redes de área local (LAN) basadas en Ethernet. Gracias a esto, es posible desplegar cualquier tecnología avanzada de comunicaciones en la subestación. IEC 61850 IEC 61850 es un estándar el cual define una norma que consta de 10 partes y aborda un conjunto de especificaciones aplicables a los sistemas de automatización de subestaciones por lo que define entonces un modelo de datos que tiene como objetivos principales posibilitar interoperabilidad entre IEDs de diferentes fabricantes y deseablemente la intercambiabilidad, entendida como la capacidad de reemplazar un dispositivo de cierto fabricante que esté en operación, con un dispositivo de otro proveedor sin tener que hacer cambios adicionales en algún otro elemento de la red. Esta norma especifica además un conjunto de servicios y objetos abstractos, que permiten que se puedan desarrollar aplicaciones de manera independiente de un protocolo específico y que haya un intercambio
25
compatible de información entre los diferentes componentes de los sistemas de automatización [29]. Redes definidas por software Las redes definidas por software (SDN), se constituyen en un nuevo enfoque de redes basado en un plano de control centralizado, en donde la arquitectura cuenta con interfaces estandarizadas entre el plano de control y el plano de los datos. En este paradigma, desde el punto de vista de los operadores de red, el elemento clave diferencial es reemplazar la interfaz de la línea de comandos estándar, por la gestión directa de los dispositivos mediante una interfaz abierta y programable [12]. De manera más general, se afirma también en [12] que la llave básica de SDN es la separación de la lógica de control de la operación del hardware, y se otorga dicha lógica a una plataforma de software denominada controlador como se puede observar en la figura 3. Esto habilita la automatización de los procesos de gestión de la red, centraliza la lógica de control y abre los recursos de la red hacia estándares abiertos y hacia los usuarios finales Metodología El proyecto fue realizado con la metodología ágil ‘programación extrema’ (XP por sus siglas en inglés), debido a que los requisitos pueden cambiar mucho en el tiempo, el uso de nuevas tecnologías es algo fundamental para la migración del proyecto y por ende trae consigo riesgos al ser un proyecto con un tiempo fijo estipulado y además el equipo de desarrollo es relativamente pequeño como se menciona en [30] la adopción de esta metodología para el proyecto es muy adecuada. Ahora bien, para la realización del proyecto se incluyeron de igual forma 4 etapas para tener una mayor claridad del alcance del sistema: una etapa o fase de análisis, fase de diseño, fase de desarrollo y finalmente una fase de pruebas. Aunque pareciera una metodología de desarrollo tradicional se establecieron ciertas actividades iniciales para cada fase, sin embargo éstas fueron cambiando acorde a los requisitos y la respectiva retroalimentación que se fue haciendo en cada entrega. Fase de análisis En ésta fase se analizaron los requisitos funcionales y no funcionales del sistema, la viabilidad, limitaciones y el alcance del mismo.
26
Necesidades y/o problemas encontrados: - Requisitos funcionales: De acuerdo a las recomendaciones y
problemas encontrados en las visitas realizadas en el anterior proyecto se pudo determinar que para la migración del sistema no es necesario realizar nuevas implementaciones para la aplicación por lo que los requisitos funcionales se limitó solo a la correción de bugs en las funcionalidades existentes y los requisitos que surgieron según las tecnologías que se usaron.
- Requisitos no funcionales: El sistema para automatización en subestaciones eléctricas cuenta con un gran número de funcionalidades entre las que se encuentran: descubrimiento de topología, creación de slices, tabla de flujos y grupos, estadísticas, detalle de dispositivos, wireshark, entre otros, por lo que crear un sistema fácil de usar y conforme a los requisitos funcionales no es tarea fácil, en el anterior proyecto se pudo evidenciar que al sistema le hacía falta usabilidad y es por ello que se consideró el cambio por completo de la interfaz gráfica para darle a los usuario finales una mejor percepción del sistema. Por otro lado con la migración también se tuvieron en cuenta las otras características de calidad como la eficiencia, fiabilidad, seguridad, mantenibilidad, etc.
- Controlador: Durante las visitas realizadas en el anterior proyecto
se ha evidenciado que el controlador que actualmente se está utilizando (ODL) ha tenido problemas de estabilidad y algunos bugs con funcionalidades específicas que hacía tedioso el desarrollo.
- Evento 61850 Global y otros proyectos: En un principio SDS fue
desarrollado bajo el Grupo de Investigación de Telecomunicaciones Aplicadas GITA de la Universidad de Antioquia y apoyado por Ruta N, Kinnesis y Colciencias. Posteriormente, el papel que cumplia la universidad de Antioquia para con el grupo, lo empezó a tener Inorks (Industrial networks https://inorks.com), ahora solo con los recursos de Ruta N y Kinnesis. Inorks se conforma como una empresa con la visión de desarrollar un nuevo nivel de abstracción para las redes de datos industriales y virtualización, no una solución tradicional basada en enfoques heredados, sino una mejora sustancial para resistencia futura. El proyecto de automatización de subestaciones eléctricas (SDS) actualmente es uno de los productos y la empresa fue invitada al evento 61850 global llevado a cabo en Berlín
27
Alemania, el cual reúne a las más reconocidas empresas de TI, más de 150 especialistas en IEC 61850 y líderes de implementación de todo el mundo. Sin embargo inorks también está llevando a cabo otro producto denominado SION CORE que es una plataforma de comunicaciones que simplifica la administración y operación de redes de datos. SION permite una conexión segura en redes privadas y públicas a través de la automatización, el control centralizado de la red y la gestión del tráfico en tiempo real. Inorks siendo un startup cuenta con los mismos recursos para ambos proyectos razón por la cual el alcance de la migración del sistema de SDS fue modificado para cumplir de manera correcta en el evento y avanzar igualmente en el desarrollo.
Alcance del proyecto: Teniendo en cuenta las necesidades y problemas que se mencionaron anteriormente el alcance del proyecto se dividió en 2 frentes: uno fue el mejorar la interfaz gráfica de la aplicación existente y corregir sus bugs y por otro lado se llevó a cabo el desarrollo de algunas funcionalidades de la plataforma SDS con una arquitectura basada en microservicios. A continuación en la figura 12 se puede evidenciar el cronograma propuesto y las actividades que se llevaron a cabo para el desarrollo de la plataforma web:
figura 12. Cronograma del proyecto. [Fuente propia]
Funcionamiento inicial de la aplicación: El proyecto inicialmente estaba implementado bajo las siguientes tecnologías:
- AngularJS: Es un marco de aplicaciones web front-end de código abierto basado en javascript para abordar los desafíos encontrados en el desarrollo de aplicaciones de una sóla página.
28
- Materialize: Es un marco de trabajo con una amplia biblioteca de componentes UI basado en la filosofía de material design de google, el cual es utilizado para realizar aplicaciones adaptables en diferentes dispositivos.
- OpenDaylight: OpenDaylight (ODL) es una plataforma abierta modular para personalizar y automatizar redes de cualquier tamaño y escala. El proyecto OpenDaylight surgió del movimiento SDN, con un claro enfoque en la capacidad de programación de la red.
- Mininet: Mininet crea una red virtual realista, ejecutando el kernel real, el conmutador y el código de la aplicación, en una sola máquina (VM, nube o nativa), en segundos, con un solo comando
- NodeJS: Es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor (pero no limitándose a ello) basado en el lenguaje de programación ECMAScript, asíncrono, con I/O de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google.
De acuerdo con las tecnologías mostradas anteriormente, el proyecto y sus respectivos componentes funcionan de la siguiente manera: Existe un único proyecto desarrollado bajo NodeJS, en el que se ejecutan al mismo tiempo el back-end y front-end (donde se implementan las librerías de materialize y angularjs). El back-end al mismo tiempo y a través de peticiones http realiza solicitudes constantemente al servidor dispuesto por Opendaylight que contiene el api necesario para que funcione el sistema, y a su vez, el controlador se conecta con un ambiente o red simulado por mininet. Como se menciona anteriormente, los componentes principales del sistema tienen mucha relación entre sí, por lo que el objetivo principal es tener una alta cohesión y un bajo acoplamiento. En este sentido, el back-end y front-end se ejecutan de manera simultánea en un solo proceso por lo que el fallo de alguno de los componentes de la aplicación afecta directamente la disponibilidad de los demás componentes o servicios que fue lo que se evidenció en las pruebas realizadas en el anterior proyecto. Fase de diseño Exploración de tecnologías: De acuerdo a los problemas mencionados en la fase de análisis con las tecnologías que se estaban usando, se optó entonces por trabajar con las siguientes tecnologías para la migración del proyecto: Angular 7, MoleculerJS, MDBootstrap, PostgreSQL y ONOS. Es importante señalar
29
que para el proyecto que ya se tiene implementado se usaron las mismas tecnologías, sin embargo las plantillas HTML que se implementaron fueron reutilizables en el otro proyecto. El uso de Angular 7 fue para cumplir con el mismo rol que Angularjs, sin embargo, la razón principal por la que fue cambiado es debido a que su tecnología está un poco obsoleta y esta nueva versión es más recomendada y estable. Por otro lado, el comportamiento del sistema y la interacción de los diferentes módulos y componentes se realizó de la siguiente manera: El back-end se desarrolló de la misma manera en NodeJS, pero en vez de usar su lenguaje nativo, se usó MoleculerJS el cual es un moderno y poderoso marco de trabajo que permite desarrollar microservicios, para poder cumplir con el objetivo de crear una aplicación modular. Entre otras ventajas, este marco nos permite:
- Soporte de arquitectura dirigida por eventos con balanceo. - Registro de servicios integrado y descubrimiento dinámico de
servicios. - Balanceador de cargas de solicitudes y eventos. - Características de tolerancia a fallos.
El front-end, como se dijo anteriormente, es una aplicación realizada con Angular 7 y MDBootstrap para el diseño, el cual fue escogido debido a que tiene soporte para los marcos de trabajo más usados en la actualidad (Angular7, VueJS, React). Además, porque se quita la dependencia de usar jQuery para la manipulación de los diferentes componentes de la interfaz gráfica como se hacía con Materialize. Esta aplicación consultará el back-end através de servicios http y la información obtenida será mostrada en la respectiva plantilla html. Por otra parte, el controlador SDN se cambió de OpenDaylight a ONOS, debido a que con ODL se tenían problemas de estabilidad y algunos bugs con funcionalidades específicas que hacía tedioso el desarrollo. Ahora bien para la información suministrada por el sistema se usará la base de datos relacional PostgreSQL, y del mismo modo se usará mininet para tener una red virtual simulada para realizar el desarrollo en un ambiente de pruebas. Es importante señalar que por cada microservicio se tendrá su respectivo modelo de base de datos (esta información se puede ver de manera más detallada en la figura 13 de la arquitectura del sistema).
30
Diseño de arquitectura: Esta fase del diseño consta de 3 capas como se muestra en la figura 13: - Capa de aplicación: En esta capa es donde se despliegan los microservicios realizados con MoleculerJS, el cual contiene nodos que son un espacio donde pueden estar uno o varios servicios y se ejecuta en un mismo proceso, por lo que los servicios que se definieron para el sistema se ejecutan en nodos individuales y ellos se pueden comunicar entre sí a través del transportador (NATS en este caso). Cabe notar que los servicios tienen su propio modelo de datos y no uno para todos los servicios conjuntamente. Como se indicó en la fase de análisis el modelo relacional se ha realizado con PostgreSQL y para este caso sólo se usará la base de datos en los nodos correspondientes a los servicios de usuarios, dispositivos y slices, debido a que los demás servicios usan la información suministrada por estos nodos. - Capa de control: Al igual que OpenDaylight, ONOS es basado en java y ofrece características como la alta disponibilidad y rendimiento a gran escala, además de un software modular con 135 extensiones que permiten entre otras cosas el control de tráfico, aplicaciones de superposición o modelos YANG precompilados - Capa física: El controlador SDN es capaz de comunicarse con el plano de infraestructura de la arquitectura a través del protocolo OpenFlow, e instalar luego en los switches, flujos de red que obedecen a diversas estrategias programadas para el descubrimiento de los dispositivos y la topología, las cuales se basan en protocolos como ARP, LLDP y STP. El front-end que es desarrollado con Angular 7 y MDBootstrap, que es una aplicación aparte y realiza solicitudes a través del protocolo http; una vez realizada la petición, ésta llega al api gateway del backend que se encarga de publicar, promocionar y supervisar el API en un entorno seguro y escalable, después las solicitudes son enrutadas al servicio correspondiente.
31
figura 13. Arquitectura del sistema. [Fuente propia].
32
Diseño de base de datos Como se mencionó anteriormente la base de datos que se utilizó fue PostgreSQL, sin embargo para facilitar la escritura y lectura en la base de datos se utiliza un ORM (Object-Relational mapping) para utilizar el mismo lenguaje de programación para realizar las operaciones sobre la base de datos y evitarse el uso de SQL nativo. Para realizar dicha tarea se escogió la librería SequelizeJS ya que es liviana, tiene soporte para los dialectos SQL más usados, es faćil de configurar, usar y posee una buena documentación. En las figuras 14 y 15 se pueden ver los modelos de datos correspondientes a los microservicios de usuario y dispositivos respectivamente.
figura 14. Modelo entidad-relación microservicio de usuario [Fuente propia].
33
figura 15. Modelo entidad-relación microservicio de dispositivos [Fuente propia].
Diagramas de flujo: Para realizar la migración hay algunos métodos o funcionalidades que pueden ser reutilizados, sin embargo para algunos es necesario hacer una refactorización, es por eso que se realizaron los siguientes diagramas de flujo para facilitar el desarrollo:
- Diagrama de flujo slice GOOSE (ver anexo 4). - Diagrama de flujo slice MMS (ver anexo 3). - Diagrama de flujo slice DNP3 (ver anexo 6). - Diagrama de flujo para el descubrimiento de dispositivos (ver
anexo 5). Mockups: Para garantizar el aspecto de calidad correspondiente a la usabilidad, se realizaron los diseños de la interfaz gráfica con el fin de disminuir el número de menús, encontrar la información de una manera más rápida y clasificar los menús de acuerdo a su rol o funcionalidad en el sistema. A continuación, se pueden ver algunos de los mockups desarrollados comparados con la versión actual de la interfaz gráfica, para ver más, el lector puede dirigirse al anexo 1.
34
figura 16. Menú principal [Fuente propia].
figura 17. Vista para la topología [Fuente propia].
Fase de implementación Como se mencionó anteriormente en la etapa de análisis, el desarrollo se llevó a cabo para atender 2 frentes: uno con la versión vieja del proyecto y otro con la migración. Lo más importante entonces era darle prioridad a la interfaz gráfica puesto que la visita al evento llevado a cabo en Berlín, Alemania estaba muy próximo (Octubre 2018), por tal motivo a éste proyecto no se le hicieron modificaciones en cuanto a las tecnologías, y a cambio se ajustaron las plantillas html y algunas funcionalidades en el backend para que los cambios no tuvieran problemas con la funcionalidad en general de la aplicación. Una vez se terminó de realizar las vistas del sistema se inició la implementación del nuevo proyecto con la arquitectura antes mencionada basada en microservicios, sin embargo esas vistas realizadas en el anterior proyecto fueron reutilizadas y solo cambiando algunas directivas (permiten la manipulación y reutilización de código HTML) y componentes (permiten gestionar las plantillas HTML y directivas que afectan al comportamiento del sistema) fue posible adaptarlo de forma rápida al nuevo sistema.
35
Luego de realizar toda la navegación del sistema con Angular7 se enfatizó en implementar los servicios de usuarios, topología y dispositivos, además de añadir el controlador ONOS para las funciones de la red. Fase de pruebas Como se muestra en el cronograma en la figura 12, se estipularon 3 tipos de pruebas a realizar: unitarias, integración y aceptación. Las pruebas unitarias se realizaron con Mocha que es un marco de prueba de JavaScript con numerosas funciones que se ejecuta en Node.js y en el navegador, lo que hace que las pruebas asíncronas sean simples de realizar. También se llevó a cabo el proceso de desarrollo de software con la técnica denominada TDD (Test-driven development por sus siglas en inglés), la cual se basa en la repetición de un ciclo de desarrollo muy corto: se escribe primero el caso de prueba automatizado (que falla inicialmente) para una funcionalidad en específico, luego se produce la cantidad de código para pasar esa prueba, y finalmente se refactoriza el nuevo código a estándares aceptables. Esta técnica en las pruebas unitarias facilitó el desarrollo debido a que los diferentes escenarios o casos de prueba que se necesitaban fueron probados y de esta manera si una nueva funcionalidad afecta una de las pruebas puede verse exactamente a qué se debe y de esta manera tener un código más limpio, esto con el fin de que se pueda cumplir con uno de los objetivos principales que está enfocado en la calidad del software, específicamente la fiabilidad. Por otro lado se tienen las pruebas de integración, para probar que esos pequeños módulos o servicios en conjunto funcionan correctamente. Se estipula entonces probar aquellos microservicios que se comunican entre ellos e igualmente la funcionalidad del front-end con los servicios http expuestos por el back-end. Resultados y análisis Interfaz gráfica mostrada en el evento 61850: Las figuras 18 a 27 muestran en funcionamiento y en un ambiente real la aplicación que se tenía en un principio luego de corregir algunos bugs con su funcionamiento. Se puede apreciar que los cambios se ajustan a los mockups presentados en la fase de análisis y lo más importante y como puede verse en la figura 19 es que los menús fueron reducidos a 3 y éstos a su vez tienen submenús con las opciones del sistema. Ahora bien, para añadir usabilidad en la aplicación una vez seleccionada una opción se redirecciona a la página correspondiente y en el template en la parte izquierda se muestra un submenú con las opciones del menú al
36
cual pertenece y de ésta manera el usuario no tiene que abrir nuevamente el menú si quiere seleccionar otra opción del mismo menú. También, puede verse en la figura 28 que éste menú puede ser reducido sólo a sus correspondientes íconos con el fin de aprovechar el espacio.
figura 18. Página de inicio [Fuente propia].
- Formulario con 2 campos de autenticación (email y contraseña). - El usuario debe estar registrado previamente. - Una vez se da en la opción ‘Login’ el usuario es redireccionado a
la ventana principal de la aplicación correspondiente a la topología de red.
37
figura 19. Menú principal [Fuente propia].
figura 20. Topología de red [Fuente propia].
- La ventana principal de la topología de red tiene un menú donde
se puede cambiar la etiqueta de los equipos (opción Node Tag) a su ip, mac, fabricante o ip. También se tiene la opción dispositivos donde al dar click se puede ver la lista de los dispositivos de red en un menú lateral como se muestra en la figura 20 y al dar click sobre alguno de éstos se puede ver el detalle. De igual manera la opción slices nos permite ver la lista de slices (figura 21) y también crear uno nuevo.
- Una nueva funcionalidad es el botón de refresh, útil cuando hay algún cambio y no se ha visto reflejado en la topología.
38
figura 21. Lista de slices [Fuente propia].
figura 22. Lista de dispositivos [Fuente propia].
- Cuenta con una entrada de texto para hacer un filtro de
búsqueda. - Opción para hacer un ordenamiento de la lista según cierto
parámetro (id, tipo, etc). - Opción para exportar un documento en formato pdf con el
reporte de los dispositivos del sistema. - En la tabla se encuentra una opción que puede verse en la parte
superior derecha que sirve para añadir o quitar dinámicamente columnas de la tabla con el fin de mostrar solo las de especial interés.
39
figura 23. Detalle de IED [Fuente propia].
figura 24. Detalle de switch [Fuente propia].
- Se añaden nuevos chasis según el fabricante: HP, CENTEC,
genérico.
40
figura 25. Estadísticas [Fuente propia].
- Para las estadísticas es importante señalar que se optó por dejar
de trabajar con la librería D3 debido a que se hacía muy tedioso el desarrollo y gráficos básicos como los diagramas de tortas, línea o barras pueden ser abordados mejor con otra librería más liviana y fácil de usar como chart.js
figura 26. Monitoreo de red (wireshark) [Fuente propia].
- En esta ventana es posible escoger los dispositivos de red y poder
ver el tráfico de red a través de un analizador de protocolos o wireshark.
41
figura 27. Tienda de los principales módulos del sistema [Fuente propia].
figura 28. Menú lateral izquierdo solo con los íconos. [Fuente propia].
Proyecto realizado con microservicios y ONOS: Como se mencionó anteriormente lo primero que se implementó fue la interfaz gráfica para el anterior proyecto, sin embargo esas mismas vistas fueron adaptadas al nuevo y, una vez se terminó de realizar la navegación y rutas de éste, se procedió a realizar los principales servicios del backend correspondientes a usuarios, dispositivos y topología por lo que se expusieron los servicios web mostrados en la tabla 1. Lo siguiente entonces fue configurar ONOS como controlador y crear una topología de red en mininet con las mismas propiedades que
42
los host o equipos terminales que son agregados por defecto en la base de datos de dispositivos (se hace por defecto en el ambiente simulado); la configuración antes mencionada puede verse en el anexo 2.
Tabla 1. Lista de servicios web Servicio Ruta Token Método Parámetros
Servicios web para el usuario
Crear usuario ip:puerto/api/users/sign_up
No POST user:Object
Obtener usuario por email ip:puerto/api/users/user_by_id/:email
Sí GET email:string
Mostrar todos los usuarios ip:puerto/api/users/allUsers
Sí GET No aplica
Obtener todos los roles ip:puerto/api/users/getAllRoles
Sí GET No aplica
Obtener todas las compañías
ip:puerto/api/users/getAllOrganizations
Sí GET No aplica
Obtener todos los tipos de documentos
ip:puerto/api/users/getAllTypesOfDocuments
Sí GET No aplica
Servicios web para los dispositivos
Obtener dispositivo por id ip:puerto/api/device/getDeviceById/:deviceId
Sí GET deviceId:string
Obtener dispositivo por nombre
ip:puerto/api/device/getDeviceByName/:deviceName
Sí GET deviceName:string
Obtener dispositivos por fabricante
ip:puerto/api/device/getDevicesByManufacturer/:deviceManufacturer
Sí GET devicemanufacturer:string
Obtener dispositivo por dirección ip
ip:puerto/api/device/getDeviceByIp/:deviceIp
Sí GET deviceIp:string
43
Obtener todos los dispositivos
ip:puerto/api/device/getAllDevices
Sí GET No aplica
Agregar dispositivo ip:puerto/api/device/insertDevice
Sí POST device:Object
Servicios web para los dispositivos
Obtener topología de red ip:puerto/api/topology/getCurrentTopology
Sí GET No aplica
Las figuras 29 a 32 muestran la integración de los servivios web expuestos por el backend en el front-end realizado con Angular7, además del correcto funcionamiento de ONOS con mininet.
figura 29. Formulario de registro de usuario. [Fuente propia].
- Puede observarse que los campos corresponden al modelo de
datos expuesto en la figura 14
44
figura 30. Inicio de sesión SDS. [Fuente propia].
figura 31. Topología de red desplegada en ONOS GUI. [Fuente propia].
45
figura 32. Topología de red con microservicios. [Fuente propia].
Pruebas de aceptación: Después de realizar las respectivas pruebas de integración, el sistema entonces fue probado como se planeó en un principio y según lo establecido en el cronograma (figura 12), en un entorno real y simulado. Éste último fue el que se realizó durante todo la etapa o fase de desarrollo y contó con la aprobación y retroalimentación de todo el equipo de desarrollo y/o interesados. Una vez probado el correcto funcionamiento en un ambiente simulado se procedió a configurar un entorno real como puede verse en la figura 33, en el evento 61850 global donde se pueden apreciar los equipos reales y el despliegue de la plataforma.
46
figura 33. Participación de inorks en el IEC 61850 Global 2018 en Alemania. [Fuente
propia]. Resultados y opiniones en el evento 61850: SEL como lo dice en su portal web [33], inventa, diseña y construye productos y sistemas digitales que protegen las redes eléctricas en todo el mundo y durante más de una década, las empresas de electricidad de América del Norte han clasificado a SEL como el fabricante de relés número 1 en el Estudio mundial de Newton-Evans del mercado de relés de protección en servicios eléctricos [34]. SEL fue una de las compañías que estuvo presente en el evento 61850 y pudo evaluar a SDS llegando a la siguiente conclusión: “es una plataforma muy interesante, debido a que es un controlador estándar”. Sin embargo como a SEL les gustaría que sus switch se puedan trabajar con nuestro controlador, ellos resolverán los certificados de los switch SEL 2740 para que sea estándar. Por otro lado, Siemens quien también tuvo presencia en el evento y que es una potencia global que se centra en las áreas de electrificación, automatización y digitalización opinó: “es una plataforma muy interesante que genera una propuesta diferente a nuestro modelo de negocio que se centra en la venta de cajas”. Ellos están interesados en desarrollar un Switch Ruggedcom con capacidades de SDN y que pueda trabajar con nuestro controlador, y ser un partner estratégico.
47
Conclusiones - Durante el proceso de desarrollo de SDS se han revisado diversos
controladores siendo ODL el controlador industrial escogido en las últimas versiones de la plataforma debido a su uso en diferentes tipos de industrias (empresas, gobierno, investigación, educación, telecomunicaciones, proveedores de contenido, etc), lo cual en un principio permitió generar confianza sobre este tipo de controlador y sus desarrollos; además de la modularidad, facilita el uso y desarrollo de nuevas herramientas para la red de comunicaciones (en una subestación eléctrica para este caso), sin embargo el esquema de versionamiento hicieron que los procesos de actualización de la plataforma y mejora se volviera un proceso tedioso, además se encontró algunos bugs con funcionalidades específicas lo que ocasionó que se optara por un nuevo controlador, en este caso ONOS fue el candidato. Con numerosos casos de uso exitosos en la industria se adoptó este controlador el cual fue fácil de instalar y además también está desarrollado en java por lo que parte del código de ODL puede ser reutilizado.
- Por otro lado, dentro de los esquemas de arquitectura de software
el estilo arquitectónico de los microservicios facilita el proceso de automatización del software, la escabilidad que es una característica importante en este tipo de sistemas orientados a las redes de comunicación y lo más importante poder separar cada funcionalidad de manera que se facilite los procesos de mantenimiento, soporte y actualización de la aplicación y que el cambio o solución a algún bug no afecte directamente la estabilidad de todo el sistema. Además, comercialmente la separación en pequeños módulos facilita la separación de funciones específicas de la plataforma (descubrimiento de red, estadísticas, slices, captura de paquetes, etc), de manera que en las soluciones que se venden el cliente se pueden ajustar perfectamente a sus necesidades.
- El uso de la metodología ágil ‘XP’ permitió la adaptación al
cambio en los requisitos y alcance del proyecto, puesto que aunque no se migró la totalidad de las funcionalidades como se tenía pensado en un principio, se trabajó en 2 frentes de desarrollo donde el objetivo principal fue tener una buena participación en el evento 61850 con el proyecto que se tenía desarrollado sin dejar a un lado el desarrollo de este nuevo
48
proyecto. Además fue posible cumplir con las necesidades debido a la interacción continua entre el responsable del proyecto y el equipo de desarrollo.
- Dentro de las herramientas de desarrollo para el front-end MDBootstrap permitió hacer una implementación mucho más rápida debido a la gran cantidad de componentes, estilos y herramientas avanzadas de diseño que provee, además todo ésto con un soporte directo para Angular7, lo que permitió el desarrollo y visualización en los dispositivos.
- La participación en el evento llevado a cabo en Berlín, Alemania permitió a inorks darse a conocer ante la comunidad 61850 con más de 16 expertos internacionales de la norma IEC 61850, donde se tuvo gran percepción y aceptación de las más importantes compañías del sector eléctrico de la plataforma de software, lo que abre una gran posibilidad de consolidar alianzas y/o ventas.
Referencias Bibliográficas [1] Sherwood, Rob. 2014. "SDN Is Devops For Networking" 39 (2): 34-36. https://www.usenix.org/system/files/login/articles/10_sherwood.pdf.
49
[2] "Network Architecture". 2019. Conceptdraw. Accessed January 10. https://www.conceptdraw.com/examples/enterprise-architect-network-topology-diagram. [3] Steinborn, Thomas. 2018. "The Future Of Devops Is Mastery Of Multi-Cloud Environments". Opensource.Com. https://opensource.com/article/18/1/future-devops. [4] Ranger, Steve. 2018. "What Is Cloud Computing? Everything You Need To Know About The Cloud, Explained | Zdnet". Zdnet. https://www.zdnet.com/article/what-is-cloud-computing-everything-you-need-to-know-from-public-and-private-cloud-to-software-as-a/. [5] Juliá, Samuel. 2015. "Tipos De Redes Informáticas Según Su Alcance -". Informática Para Empresas. http://www.gadae.com/blog/tipos-de-redes-informaticas-segun-su-alcance/. [6] Froehlich, Andrew. 2017. "6 Key Milestones In Computer Networking History". Network Computing. https://www.networkcomputing.com/networking/6-key-milestones-computer-networking-history/1438059667. [7] Greene, Kate. 2009. "TR10: Software-Defined Networking - MIT Technology Review". MIT Technology Review. http://www2.technologyreview.com/news/412194/tr10-software-defined-networking/. [8] Li, Abner. 2018. "Google Cloud Opening Fifth U.S. Region In LA Next Month, Targeting Media & Entertainment". 9To5google. https://9to5google.com/2018/06/26/google-cloud-region-los-angeles/. [9] Ma, Chloe. 2014. "SDN Secrets Of Amazon And Google". Infoworld. https://www.infoworld.com/article/2608106/sdn/sdn-secrets-of-amazon-and-google.html. [10] Bhatia, Jitendra. 2017. "A Primer On Software Defined Networking (SDN) And Openflow Standard". Open Source For You. https://opensourceforu.com/2017/10/primer-software-defined-networking-sdn-openflow-standard/.
50
[11] Fulton, Scott. 2018. "What Is SDN? How Software-Defined Networking Changed Everything | Zdnet". Zdnet. https://www.zdnet.com/article/software-defined-networking-101-what-sdn-is-and-where-its-going/. [12] Millán, Ramón. 2016. "SDN (Software-Defined Networking)". Ramonmillan.Com. https://www.ramonmillan.com/tutoriales/softwaredefinednetworking.php. [13] Frómeta, Dayrene, Caridad Anías, Susana Ballester, and Sergio León. 2016. "Desarrollo De Aplicaciones SDN". Revista Técnica De La Empresa De Telecomunicaciones De Cuba S.A 13: 41-47. https://www.researchgate.net/publication/320508215_DESARROLLO_DE_APLICACIONES_SDN. [15] Kinnesis.com. (2017). Kinnesis Solutions. [online] Available at: http://www.kinnesis.com/ [Accessed 27 Oct. 2017]. [16] "A Beginners Guide To Understanding The Agile Method | Linchpin SEO". 2019. Linchpin SEO. Accessed January 10. https://linchpinseo.com/the-agile-method/. [17] "Arquitectura Monolítica Vs Microservicios – Emmita – Medium". 2017. Medium. https://medium.com/@Emmitta/arquitectura-monol%C3%ADtica-vs-microservicios-6d8b14ed6e55. [18] "Aplicaciones Monoliticas O Microservicios | Aplyca". 2019. Aplyca.Com. Accessed January 18. https://www.aplyca.com/es/blog/aplicaciones-monoliticas-o-microservicios. [19] ul Haq, Siraj. 2018. "Introduction To Monolithic Architecture And Microservices Architecture". Medium. https://medium.com/koderlabs/introduction-to-monolithic-architecture-and-microservices-architecture-b211a5955c63. [20] Anwar, Masood. 2019. "What Is Client Server Architecture?". Daily Web Solutions. Accessed January 10. http://www.dailywebsolutions.com/what-is-client-server-architecture. [21] Mitra, Shamik. 2016. "Why Microservices? - Dzone Microservices". Dzone.Com. https://dzone.com/articles/microservices-basics. [22] "Advantages And Disadvantages Of Client Application Server". 2011. Esds.Co.In.
51
https://www.esds.co.in/blog/advantages-and-disadvantages-of-client-application-server/#sthash.j0GZNyxf.dpbs. [23] "Anatomy Of The Client/Server Model". 2019. Docs.Oracle.Com. Accessed January 10. https://docs.oracle.com/cd/E13203_01/tuxedo/tux71/html/intbas3.htm. [24] "What Is N-Tier Architecture? How It Works, Examples, Tutorials, And More". 2017. Stackify. https://stackify.com/n-tier-architecture/. [25] Arsov, Kristijan. 2017. "What Are Microservices, Actually? - Dzone Microservices". Dzone.Com. https://dzone.com/articles/what-are-microservices-actually. [26] Kumar, Mrityunjay. 2016. "Microservices Architecture: What, When, And How - Dzone Microservices". Dzone.Com. https://dzone.com/articles/microservices-architecture-what-when-how. [27] Mitra, Shamik. 2016. "Why Microservices? - Dzone Microservices". Dzone.Com. https://dzone.com/articles/microservices-basics. [28] "ISO 25010". 2019. Iso25000.Com. Accessed January 10. https://iso25000.com/index.php/normas-iso-25000/iso-25010?limit=3&limitstart=0. [29] Mackiewicz, Ralph, and Sterling Heights. 2006. "Technical Overview And Benefits Of The IEC 61850 Standard For Substation Automation". IEEE, 1-8. https://library.e.abb.com/public/04519389e504d7ddc12576ff0070704d/3BUS095131_en_IEC61850_Overview_and_Benefits_Paper_General.pdf. [30] "What Is Extreme Programming (XP)?". 2017. Agile Alliance. https://www.agilealliance.org/glossary/xp/. [31] Feamster, N., Rexford, J., & Zegura, E. (2014). The road to SDN: an intellectual history of programmable networks. ACM SIGCOMM Computer Communication Review, 44(2), 87-98. [32] E. A. Leal and J. F. Botero, “Software defined power substations: an architecture for network communications and its control plane.” Universidad de Antioquia. 2016. [33] "About SEL". 2019. Selinc.Com. https://selinc.com/company/about/.
52
[34] "SEL Ranked #1 Again In Newton-Evans Protective Relay Study". 2019. Cdn.Selinc.Com. Accessed January 10. https://cdn.selinc.com/assets/Literature/Product%20Literature/Flyers/NewtonEvans_Flyer.pdf?v=20151111-171518. [35] "User Stories - Opendaylight". 2019. Opendaylight. Accessed January 10. https://www.opendaylight.org/use-cases-and-users/user-stories. [36] Del Chiaro, Jhonatan. 2018. "Microservicios". Knowing-Microservicios.Blogspot.Com. http://knowing-microservicios.blogspot.com/. ANEXOS: [1] https://app.moqups.com/Development@inorks.com/ipLO2LV4cg/view [2] https://www.dropbox.com/s/5ui1ayuf203oov6/configuraci%C3%B3n%20de%20entorno%20ONOS%20%2B%20Mininet.pdf?dl=0 [3] https://www.dropbox.com/s/34hsec53cvzugfd/onNew.png?dl=0 [4] https://www.dropbox.com/s/qhvgqsw5u2i2bsf/onNew%20%282%29.png?dl=0 [5] https://www.dropbox.com/s/z7wchitcjhbz8y9/device_discoverer.png?dl=0 [6] https://www.dropbox.com/s/lock1mlb840pd0l/onNew%20%283%29.png?dl=0
53
top related