Universidade Federal de Pernambuco

Centro de Informática

Graduação em Sistemas de Informação

MORI’S LAB: Plataforma ChatOps de

automação e monitoramento de servidores

Ian Marino Lavenere Bastos Fireman

Trabalho de Graduação

Recife
09 de julho de 2018
ii

Universidade Federal de Pernambuco

Centro de Informática

Ian Marino Lavenere Bastos Fireman

MORI’S LAB: Plataforma ChatOps de automação e

monitoramento de servidores

Trabalho apresentado ao Programa de Graduação em Sis-

temas de Informação do Centro de Informática da Univer-
sidade Federal de Pernambuco como requisito parcial para
obtenção do grau de Bacharel em Sistemas de Informação.

Orientador: Vinícius Cardoso Garcia

Recife
09 de julho de 2018
 Universidade Federal de Pernambuco
Centro de Informática

Ian Marino Lavenere Bastos Fireman

MORI’S LAB: Plataforma ChatOps de automação e

monitoramento de servidores

Monografia submetida ao corpo docente da Universidade Federal de

Pernambuco, defendida e aprovada em de de .

Banca examinadora:

Orientador:
Vinícius Cardoso Garcia

Examinador:
Kiev Santos da Gama

Recife
09 de julho de 2018
 Resumo

Diante das recentes popularizações e crescente demanda no mercado acerca de DevOps e Chat-
Bots, uma nova maneira de criar ferramentas nasceu, o ChatOps. Fruto do entusiasmo da
empresa GitHub, que criou o conceito onde ChatBots auxiliam times de desenvolvimento/o-
perações a realizar suas atividades de modo colaborativo, transparente e uniforme através de
conversas naturais. Automatizando builds e trazendo transparência nos processos. Com isso
esse trabalho tem o intuito de estudar e propor uma plataforma ChatOps de monitoramento e
automação de tarefas em servidores em uma maneira serverless. Tendo seu objetivo auxiliar
qualquer membro de uma equipe de desenvolvimento ou operações.

Palavras-chave: microservices, ChatBots, DevOps, ChatOps

v
 Abstract

In the face of recent popularization and growing market demand for DevOps and ChatBots,
a new way to create tools was born, ChatOps. The result of the enthusiasm of the company
GitHub, which created the concept where ChatBots help development/operational teams to
peform their activities, in a collaborative, transparent and uniform way, through natural con-
versations. Automating builds and bringing transparency into processes. This work intends
to study and propose a ChatOps platform for monitoring and automating tasks in servers in a
serverless manner. Its purpose is to assist any member of a development/operational team.

Keywords: microservices, ChatBots, DevOps, ChatOps

vii
 Sumário

1 Introdução 1
1.1 Motivação 1
1.2 Objetivos 2
1.2.1 Gerais 2
1.2.2 Específicos 2
1.3 Estrutura do trabalho 2
2 Contexto 3
2.1 Microservices 3
2.2 DevOps 4
2.2.1 Continuous Integration 4
2.2.2 Continuous Delivery 4
2.3 ChatBots 4
2.3.1 ChatOps 5
2.3.1.1 Origem 5
2.4 Sumário 5
3 Mori’s Lab 7
3.1 Introdução a arquitetura 8
3.1.1 Características 8
3.1.2 Motivação 8
3.1.3 Comunicação 8
3.2 Dashboard - O laboratório parte 1 8
3.2.1 Tecnologias 8
3.2.2 Servidores 9
3.2.2.1 Listagem 9
3.2.2.2 Cadastro 9
3.2.3 Actions 10
3.2.3.1 Listagem 10
3.2.3.2 Cadastro 10
3.2.4 Autenticação de Chats 12
3.2.4.1 Listagem 12
3.2.4.2 Conectar 12
3.3 API - O laboratório parte 2 14
3.3.1 Tecnologias 14

ix
x SUMÁRIO

3.3.1.1 Express 14
3.3.2 Heart Beat 15
3.3.3 Rotas 16
3.3.4 Arquitetura 17
3.3.4.1 Controladores 17
3.3.4.2 Services 18
3.3.4.3 Models 18
3.3.4.4 Data access objects 20
3.3.4.5 Criptografia 20
3.4 Heart 20
3.4.1 Tecnologias 21
3.4.2 Mind Middleware 21
3.4.2.1 Autenticidade 21
3.4.2.2 Rotas 22
3.5 Server Manager 22
3.5.1 Tecnologias 22
3.5.2 Arquitetura 22
3.5.3 Executando ações 22
3.6 Mori (ChatBot) 23
3.6.1 Arquitetura 24
3.6.1.1 Event Handling - Tratameto de Eventos 24
3.6.1.2 Services 24
3.6.2 Eventos 24
3.6.3 Sumário 25
4 Mori em ação 27
4.1 Monitoramento via stream de log 27
4.2 Movendo banco de dados entre servidores 30
4.3 Sumário 32
5 Conclusão 33
5.1 Trabalhos Futuros 33
 Lista de Figuras

3.1 Ilustração da arquitetura da plataforma 7

3.2 Tela de listagem de servidores 9
3.3 Tela de registro de servidores 10
3.4 Tela de listagem de actions 11
3.5 Tela de registro de action 11
3.6 Tela de listagem de chats 12
3.7 Conectar chat 13
3.8 Arquitetura da api 14
3.9 Arquitetura Heart 21
3.10 Arquitetura Server Manager 23
3.11 Arquitetura Mori 24

4.1 Cadastro de stream de log 27

4.2 Stream de log 1 28
4.3 Stream de log 2 28
4.4 Stream de log 3 29
4.5 Stream de log 4 29
4.6 Cadastro de mover dump 30
4.7 Mover dump 1 30
4.8 Mover dump 2 31
4.9 Mover dump 3 31
4.10 Mover dump 4 31
4.11 Mover dump 5 32

xi
 Lista de Tabelas

3.1 Rotas de autenticação 16

3.2 Rotas de Chats 16
3.3 Rotas de Ações 17
3.4 Rotas de Servidores 17
3.5 Rotas Heart 22

xiii
 C APÍTULO 1

Introdução

1.1 Motivação

Devido à grande competitividade no mercado de tecnologia, empresas vem buscando maneiras

de se tornarem mais ágeis e reduzirem a perda de tempo com trabalhos repetitivos e manuais.
Em busca de métodos que as façam alcançar tais objetivos que se da a recente onda de adoção
dá cultura DevOps. Essa adoção engloba o uso de ferramentas de Continuous Integration e
Continuous Delivery, que trazem reduções de riscos e processo repetitivos, melhor visibilidade
aos projetos [16] e processos de release que sejam reusáveis, confiáveis e previsíveis [3]. Com
esses benefícios, implantar arquiteturas baseadas em Microservices tornam-se mais viáveis
[3], já que uma aplicação monolítica ao se tornar pequenos serviços independentes poderá ser
facilmente atualizada constantemente de modo seguro e com baixos riscos [16], além de ter
uma boa visibilidade de todos os processos.
Por outro lado, com o aperfeiçoamento da tecnologia ao passar dos anos tornou-se possível
o uso de máquinas inteligentes para realizar tarefas como humanos através de Machine Lear-
ning1 . Sendo possível alcançar os mesmos benefícios de agilidade e eliminação de trabalhos
manuais com uso de automação [19]. Um dos métodos possíveis de aplicar inteligência e auto-
mação é através de ChatBots, que são aplicações de chat interativas capazes de realizar ações
por meio de conversas. São implementados como agentes inteligentes2 que podem perceber
seu ambiente, analisá-lo e agir diante da situação [19].
Com esses conceitos em mente a empresa de tecnologia GitHub elaborou um novo con-
ceito, chamado de ChatOps, que engloba DevOps, Microservices e Chatbots. Isso foi possível
através do desenvolvimento do Hubot3 , um framework de código aberto para desenvolvimento
de ChatBots, onde a empresa levou automação para nível de chat, ou seja, operações são exe-
cutadas através de comandos em conversas, de modo transparente para o usuário. O GitHub
mostrou possível esse tipo de abstração e facilidade para utilização de metodologias DevOps e
comunicação entre diversos serviços.
Com esse primeiro passo realizado pelo GitHub, e observando a crescente busca por agili-
dade e automação junto dos conceitos apresentados acima, torna-se viável o desenvolvimento
de uma aplicação que leve adiante a proposta inicial de ChatOps de automação via chat para um
nível de plataforma, trazendo esses benefícios de modo serverless4 a partir de um Dashboard
1 https://en.wikipedia.org/wiki/Machine earning
l
2 https://en.wikipedia.org/wiki/Intelligent gent
a
3 https://hubot.github.com/
4 https://en.wikipedia.org/wiki/Serverless omputing
c

1
2 CAPÍTULO 1 INTRODUÇÃO

capaz de configurar e gerenciar ações a serem executadas por meio de ChatBots em servidores
remotos, sem a obrigação de programar para criação de tais configurações.

1.2 Objetivos

1.2.1 Gerais
Objetivo desse trabalho é implementar uma plataforma ChatOps onde seja possível através de
um Dashboard comunicando-se com uma API REST automatizar um ChatBot para executar
ações em servidores em tempo real que sejam capazes de trazer transparência, resiliência e alta
disponibilidade para seus serviços.

1.2.2 Específicos
• Desenvolvimento de um ChatBot como interface capaz de interpretar ações para execu-
ção de comandos remotos

• Desenvolvimento de uma API REST para orquestração de ações e dados entre os Micro-
services

• Desenvolvimento de um Microservice de autenticação para a plataforma, facilitando sua

comunicação interna de modo seguro

• Desenvolvimento de um Microservice de execução de comandos nos servidores remotos,

que funcione em um modelo serverless, executando comandos sob demanda

• Desenvolvimento de um Dashboard para cadastro de dados e informações de segurança

1.3 Estrutura do trabalho

Este documento é composto por 5 capítulos:

• Capitulo 1 - Introdução: Demonstra motivações e objetivos do projeto.

• Capitulo 2 - Contexto: Apresenta todo o contexto teórico e tecnológico para entendi-

mento dos demais capítulos.

• Capitulo 3 - Mori’s Lab: Apresenta a proposta do projeto desenvolvido, sua arquitetura

detalhada e tecnologias usadas.

• Capitulo 4 - Mori em ação: Demonstra casos de uso do projeto e seus resultados.

• Capitulo 5 - Conclusões: Apresenta as conclusões obtidas pelo decorrer do projeto e

trabalhos futuros.
 C APÍTULO 2

Contexto

2.1 Microservices

Aplicações monolíticas funcionam bem quando são pequenas e de médio porte. Uma vez que
seus processos de desenvolvimento, teste e implantação são simples e com poucos passos. No
entanto, no momento que se tem grandes aplicações, muitas coisas passam a estar contidas em
apenas um lugar, e dificulta a manutenção, atualização e adoção de novas tecnologias. Por esses
tipos de problemas que os Microservices apareceram. O termo nasceu em 2012 como evolu-
ção do SOA e é definido por James Lewis, consultor principal de tecnologia da Thoughtworks
como "Uma pequena aplicação que pode ser implantada/escalada/testada de modo indepen-
dente e que tenha responsabilidade única (uma única razão para mudar, uma única razão
para ser substituída e única capacidade)". Resumindo, Microservices é uma abordagem para
desenvolver uma única aplicação como uma suíte de serviços1 .

• Benefícios

– Manutenção: Microservices quebram a complexidade de grandes aplicações em

aplicações menores [20], dando a liberdade de times desenvolverem, testarem e
resolverem problemas de maneiras independentes.

– Escalabilidade: Diversas instâncias de um mesmo Microservice podem rodar em

paralelo, além de que como as responsabilidades são únicas e separadas [6], pode-
se escalar de modo independente serviços específicos que necessitam de mais poder
computacional.

– Suporte a DevOps: Devido a sua modularidade, desenvolvimento e implantações

podem ser feitos de maneira independentes e paralelas [5][20], facilitando uso de
ferramentas DevOps.

– Tolerância a falhas: Se um Microservice ficar fora do ar, o resto da aplicação

continuará funcionando normalmente, já que se tratam de processos diferentes e
independentes [20]. Ainda mais, por serem por definição mais simples e compactos,
erros tornam-se simples de encontrar, e por serem mais leves, os serviços podem ser
reiniciados de maneira rápida.

1 https://martinfowler.com/articles/microservices.html

3
4 CAPÍTULO 2 CONTEXTO

2.2 DevOps

DevOps é uma cultura onde se junta diversas práticas integradas e vem sido usada e inves-
tida por grandes empresas, para agilizarem seus processos e aumentar sua produtividade. Isso
acaba sendo muito atrativo para empresas menores e incentivando a propagação da cultura no
mercado. Ela é um grande aliada da arquitetura Microservices, já que suas práticas ajudam os
Microservices a alcançarem maior potencial[3], automatizando builds, testes[16] e entregas de
diversos serviços simultaneamente.
Essas práticas são baseadas em melhorar a comunicação e interatividade entre desenvolvi-
mento e operações [12], junto da automatização de atividades [18].

2.2.1 Continuous Integration

É definido pela pesquisadora científica Dusica Marijan do centro de pesquisa norueguês Certus
como "Continuous Integration é uma prática de desenvolvimento de software de integração e
teste de código-fonte para detectar defeitos em estágios iniciais de desenvolvimento", ou seja
é usado junto ao desenvolvimento para garantir que novas funcionalidades sejam entregues
de modo que esteja garantida suas eficácias, já que é prática de Continuous Integration visa
detectar tais falhas e deixa-las transparente para que não seja possível passa-las a frente sem
devidas correções.

2.2.2 Continuous Delivery

Não existe um consenso de definição para Continuous Delivery na comunidade acadêmica

[12], porém baseasse em acelerar de modo automatizado entregas de software de alta qualidade
e confiabilidade. Podendo por exemplo garantir que novas funcionalidades sejam entregas de
modo independente. Tendo ferramentas verificando a base de código, e no momento que seja
observado novas entregas válidas o build2 será feito automaticamente para então ser feito o
deploy3 .

2.3 ChatBots

O primeiro ChatBot foi criado em 1966 e foi desenvolvido para simular um psicoterapeuta, e
apesar de ser rudimentar, para sua época foi um grande avanço e abriu novos horizontes para
tal tecnologia. ChatBots são softwares que podem interagir ou "conversar"com um usuário
humano por meio de linguagem natural [9]. Diferentemente de outros tipos de softwares, eles
não necessitam de instalação e estão prontos para uso e interação [17], às vezes dependendo
apenas de simples configurações.

2 https://pt.wikipedia.org/wiki/Build
3 https://en.wikipedia.org/wiki/Software eployment
d
 2.4 SUMÁRIO 5

2.3.1 ChatOps
Diferente do primeiro BOT que simulava um terapeuta, de modo mais físico e humano, BOTS
ChatOps servem como softwares assistentes, onde através de conversas naturais conseguem
executar operações técnicas dentro de um projeto, geralmente ligadas a Continuous Integration
e Continuous Delivery, fazendo builds e tests via chat. Definido por Sam Fell [4] "ChatOps é
um modelo de desenvolvimento baseado em colaboração e conversação que enfatiza o fluxo de
trabalho transparente e colaborativo.", tendo como objetivo tornar mais simples o acesso de
times a esses tipos de ferramentas e práticas introduzidas pelo DevOps.

2.3.1.1 Origem
A origem da prática veio do entusiasmo da empresa de software GitHub com a construção
do framework opensource para criação de BOTS chamado Hubot. O que tornou possível à
implementação de Continuous Integration e Continuous Delivery via ChatBots, automatizando
tais fluxos de entrega e integração. Além de disponibilizar uma personalização de comandos e
integrações exclusivamente via scripts4 .

2.4 Sumário

Nesse capítulo foi apresentando as definições dos conceitos básicos necessários para enten-
der a implementação e objetivo do projeto proposto. No próximo capítulo será introduzido a
plataforma, sua definição, arquitetura e detalhes de execução.

4 https://en.wikipedia.org/wiki/Scripting anguage
l
 C APÍTULO 3

Mori’s Lab

Moris’s Lab, no português, Laboratório da Mori, possui um titulo lúdico devido a analogia
criada referente á personagem Mori e seu laboratório elaborados originalmente para o projeto.
O laboratório é toda a parte onde as ações e dados são gerenciados (API, Dashboard e Mi-
croservices). A Mori representa o BOT, a interface de comunicação para acessar as ações e
dados.
O projeto foi desenvolvido como uma plataforma ChatOps para automação de ações em ser-
vidores. Essas ações são configuradas no Dashboard através de actions que funcionam como
pipelines de comandos. Essa escolha foi feita levando em consideração que as personalizações
do Hubot feitas via script obrigam o usuário a programar. Assim, trazendo o beneficio de abs-
tração, onde não é obrigatório o uso de programação. Nesse capitulo irei mostrar os diferentes
módulos e serviços que compõem a plataforma, junto com suas respectivas arquiteturas e tec-
nologias envolvidas. A figura 3.1 ilustra a arquitetura de mais alto nível da plataforma. Suas
partes serão detalhadas nas seções seguintes.

Figura 3.1 Ilustração da arquitetura da plataforma

7
8 CAPÍTULO 3 MORI’S LAB

3.1 Introdução a arquitetura

3.1.1 Características
Foi adotado uma arquitetura baseada em Microservices, onde a plataforma é composta por 5
componentes destintos ilustrados na figura 3.1, sendo eles:

• ChatBot

• API REST

• Serviço de Autenticação

• Serviço de controle de servidores

• Dashboard

3.1.2 Motivação
O projeto tem como objetivo ser uma plataforma com visão de crescimento, e visando isso
foi escolhida uma arquitetura baseada em Microservices. Essa escolha foi feita pela questão
da escalabilidade, pois como será citado na seção de trabalhos futuros, o ChatBot não neces-
sariamente será o único meio de interface de execução de comandos. Além de tornar futuras
refatorações de código mais fáceis, devido a sua independência entre serviços.

3.1.3 Comunicação
A API serve como ponto intermediário para a comunicação de todos os serviços, enquanto
todas as interações com o usuário ocorrem ou pelo Dashboard ou pelo ChatBot, que em sua
parte chamam a API e que então irão usar os serviços necessários para processar e gerar uma
resposta adequada para a requisição.

3.2 Dashboard - O laboratório parte 1

O Dashboard é a parte do laboratório da Mori que esta visível para o usuário, onde o cadastro
de servidores, ações e credencias é feito, além da autenticação de novos chats, para que possam
se comunicar com o BOT(Mori).

3.2.1 Tecnologias
O Dashboard foi construído fazendo uso do framework open-source Angular1 em sua versão
4.4.4. Angular é uma framework JavaScript abrangente que é frequentemente usado por desen-
volvedores de todo o mundo para criar aplicativos Web, desktop e móveis. Ele foi criado e é
1 https://angular.io/
 3.2 DASHBOARD - O LABORATÓRIO PARTE 1 9

mantido pelo Google. Plataformas Web como Google Adwords2 , Google Fiber3 , e Adsense4
usam o Angular como framework de suas interfaces gráficas [15].

3.2.2 Servidores
Na seção de servidores do Dashboard é possível listar, deletar e cadastrar novos servidores. Os
servidores são cadastrados apenas pelo Dashboard por questões de segurança, principalmente
para evitar a digitação de credencias visíveis via chat. Na seção 3.3.5 será descrito o processo
de criptografia utilizado nas senhas e dados dos servidores armazenados.

3.2.2.1 Listagem
Na tela de listagem ilustrada na figura 3.2 é possível ver o status do servidor, seu ip e método
de conexão que é utilizada pelo Server Manager para se comunicar com o servidor, isso será
melhor abordado na seção 3.4.1. Além de disponibilizar a opção de deletar o servidor e de ir
para tela de cadastrar um novo servidor.

Figura 3.2 Tela de listagem de servidores

3.2.2.2 Cadastro
Na tela de cadastro de servidor como ilustra a figura 3.3 é possível escolher o nome do servidor,
o ip, porta, nome de usuário e senha para que a conexão SSH seja possível de ser realizada pelo
Server Manager.
2 https://adwords.google.com/home/
3 https://fiber.google.com/about/
4 https://www.google.com/adsense/start//?modal ctive = none
a
10 CAPÍTULO 3 MORI’S LAB

Figura 3.3 Tela de registro de servidores

3.2.3 Actions
Actions foram criadas como conjuntos de comandos a serem executados pelo Server Manager
em um servidor, elas são configuráveis para que o BOT seja capaz de fazer perguntas e preen-
cher esses comandos com entradas dos usuários, e isso é possível através dos steps cadastrados
na tela de cadastro de uma nova action. Composição de uma action:

• Steps: são unidades de comando dentro de uma action, eles representam um comando
bash e podem conter n inputs para sua construção.

• Inputs: são perguntas que serão interpretadas pelo BOT, que por usa vez retornará as
respostas dos usuários capturadas, que então serão substituídas dentro dos steps para a
construção do comando

3.2.3.1 Listagem
Na seção de listagem de actions é possível visualizar a quantidade de steps que cada action
possui, em que servidor ela foi cadastrada e sua descrição. Além da opção de deletar a action e
de ir para a pagina de criação de uma nova action.

3.2.3.2 Cadastro
Na tela de cadastro de uma action é possível adicionar n steps, que possuem um comando e
podem possuir n inputs, os inputs ao serem adicionados automaticamente terão suas respectivas
variáveis inseridas na caixa de dialogo.
3.2 DASHBOARD - O LABORATÓRIO PARTE 1 11

Figura 3.4 Tela de listagem de actions

Figura 3.5 Tela de registro de action

12 CAPÍTULO 3 MORI’S LAB

3.2.4 Autenticação de Chats

A autenticação de chat é feita através de tokens recebidos da API que são convertidos em
QRCodes e exibidos no Dashboard, o BOT(Mori) deve receber esse QRCode para descodificar
o token e realizar a autenticação do novo chat, conectando assim sua conta da plataforma ao
seu chat, tornando possível o uso de seus objetos cadastrados no laboratório.

3.2.4.1 Listagem
A listagem mostra o status desse chat, o provedor (inicialmente disponível apenas para tele-
gram), o nome do usuário, quando foi utilizada pela ultima vez, a opção de deletar o chat e
opção de conectar um novo chat.

Figura 3.6 Tela de listagem de chats

3.2.4.2 Conectar
Essa tela possui apenas o QRCode em si, que poderá ser enviado para o BOT, tanto como uma
foto a partir de um dispositivo móvel, como a partir de copiar e colar dentro do telegram web.
3.2 DASHBOARD - O LABORATÓRIO PARTE 1 13

Figura 3.7 Conectar chat

14 CAPÍTULO 3 MORI’S LAB

3.3 API - O laboratório parte 2

A API é a parte do laboratório que processa todas as requisições dos usuários sem eles neces-
sariamente verem, é ela que executa grande parte das escritas no banco, além de gerenciar as
chamadas de serviços e retornar suas respostas corretamente para o usuário.

Figura 3.8 Arquitetura da api

3.3.1 Tecnologias
Na criação da API foi adotado a tecnologia Node.js5 junto com o framework Express6 , em
termos simples, Node.js é uma multiplataforma javascript gratuita de código-fonte aberto para
programação server side [19], enquanto o Express é um web app framework minimalista, open
source e flexível, construído para desenvolver websites, web apps e API’s de maneira fácil com
Node.js [19]. Para entendermos melhor a arquitetura do projeto iremos entender a arquitetura
do Express que será descrita na seção 3.3.1.1.

3.3.1.1 Express
A arquitetura do framework é baseada em middlewares, porém na nomeologia do Express,
middlewares possuem um significado diferente7 do tradicional, eles funcionam como manipu-
5 https://nodejs.org/en/
6 https://expressjs.com/
7 https://medium.com/@agoiabeladeyemi/a-simple-explanation-of-express-middleware-c68ea839f498
 3.3 API - O LABORATÓRIO PARTE 2 15

ladores de requisições [7]. Cada middleware tem acesso ao objeto da request, objeto de resposta
e um objeto chamado "next", que é a função que chama o próximo middleware. Dessa maneira
podem ser adotadas diversas estratégias para construir a arquitetura da aplicação, o qual irei
abordar na seção 3.3.4. Todas as referências a middlewares nesse documento são relacionados
aos middlewares definidos pelo Express.
No bloco de código abaixo é representado uma simples aplicação construída com Node.js
e Express, onde possui dois middlewares, o primeiro middleware na linha 7 ira exibir a men-
sagem dizendo qual método e qual rota foi chamada para aplicação, logo depois na linha 8, o
próximo middleware será chamado, respondendo com a mensagem "Welcome!"para o usuário.
1 const express = require ( " express " ) ;
2 const http = require ( " http " ) ;
3 c o n s t app = e x p r e s s ( ) ;
4

5 / / Logging middleware
6 app . u s e ( f u n c t i o n ( r e q u e s t , r e s p o n s e , n e x t ) {
7 c o n s o l e . l o g ( " Method : " + r e q u e s t . method + " t o U r l : " + r e q u e s t . u r l ) ;
8 next ( ) ;
9 }) ;
10

11 / / Logging middleware 2
12 app . u s e ( f u n c t i o n ( r e q u e s t , r e s p o n s e , n e x t ) {
13 r e s . end ( " Welcome ! " ) ;
14 }) ;
15
16 h t t p . c r e a t e S e r v e r ( app ) . l i s t e n ( 1 3 3 7 ) ;
17

Listing 3.1 Exemplo middleware

3.3.2 Heart Beat

O middleware Heart Beat foi elaborado para facilitar a conexão entre a API e o Microservice
Heart de autenticação, com apenas uma linha de código dentro do projeto da API é possível
ativar sua autenticação fazendo uso do middleware, que automaticamente configurara suas rotas
e usuário ativo na sessão, se existir. O modelo de autenticação especificado será discutido em
detalhes na Seção 3.4 onde a proposta do Microservice será melhor descrita.
1 const express = require ( " express " ) ;
2 const http = require ( " http " ) ;
3 const heartBeat = r e q u i r e ( ’ . / middlewares / heartBeat ’ ) ;
4 const app = e x p r e s s ( ) ;
5

6 app . u s e ( h e a r t B e a t . p u l s e ) ;
7
8 h t t p . c r e a t e S e r v e r ( app ) . l i s t e n ( 1 3 3 7 ) ;
9

Listing 3.2 middleware Heart Beat

16 CAPÍTULO 3 MORI’S LAB

3.3.3 Rotas
Toda as atividades dentro da plataforma são feitas através da API. As rotas foram construídas
de modo versionado, e o modelo de versionamento seguido foi o versionamento por URL8 ,
onde a versão da API deve aparecer explicitamente na URL. Uma rota de exemplo seria:
"http://server.com/v1/actions", onde a versão e representada pelo "v1". Nessa seção será des-
crita a primeira versão da API.
Todas as rotas descritas abaixo com exceção das de autenticação são acessíveis apenas se no
cabeçalho da requisição estiver presente um token de identidade valido, devendo estar presente
na chave "x-access-token". O token pode ser obtido através da rota login descrita abaixo.

• Autenticação - Adicionado automaticamente pelo middleware Heart Beat

Tabela 3.1 Rotas de autenticação

Descrição Método Rota
Login POST /auth/login
Signup POST /auth/signup

• Chats

Tabela 3.2 Rotas de Chats

Descrição Método Rota
Listar chats GET /chats
Requisitar token para novo chat GET /chats/requestNew
Cancelar stream de dados para o chat GET /chats/cancelStream
Cadastrar servidor POST /chats/createByQrCodeToken
Verifica se chat esta habilitado para usuário GET /chats/verifyUser
Retornar chat por id GET /chats/:chatId
Atualizar chat PUT /chats/:chatId
Deletar chat DELETE /chats/:chatId

8 https://restfulapi.net/versioning/
 3.3 API - O LABORATÓRIO PARTE 2 17

• Ações

Tabela 3.3 Rotas de Ações

Descrição Método Rota
Listar ações GET /actions
Cadastrar ação POST /actions
Retornar ação por id GET /actions/:actionId
Atualizar ação PUT /actions/:actionId
Deletar ação DELETE /actions/:actionId
Executar ação POST /actions/:actionId/execute

• Servers

Tabela 3.4 Rotas de Servidores

Descrição Método Rota
Listar servidores GET /servers
Cadastrar servidor POST /servers
Retornar servidor por id GET /servers/:serverId
Atualizar servidor PUT /servers/:serverId
Deletar servidor DELETE /servers/:serverId

3.3.4 Arquitetura
Na aplicação, foi adotado o modelo arquitetural MVC9 junto dos padrões Service Layer10 e
Data Access Object11 . A view do MVC é representada pelo Dashboard descrito no seção 3.2.

3.3.4.1 Controladores
Logo após a aplicação identificar a rota chamada, a requisição será direcionada para o con-
trolador especifico dessa rota. Como no Express tudo são middlewares, os controladores não
são exceções, tendo assim disponíveis os mesmos objetos de requisição, resposta e "next"como
descrito na seção 3.3.1.1.
No bloco de código abaixo é exemplificado a função de executar ações do controlador de
ações da API, que mostra a execução através de um observador que escreve em uma stream
que transmite o retorno dos servidores. Os retornos dos servidores são recebidos do service de
ações, que por sua vez escuta o Server Manager, melhor descrito na seção 3.5.
9 https://en.wikipedia.org/wiki/Model–view–controller
10 https://en.wikipedia.org/wiki/Service ayer attern
l p
11 https://en.wikipedia.org/wiki/Data ccess b ject
a o
 18 CAPÍTULO 3 MORI’S LAB

1 async f u n c t i o n e x ec u te St r ea m ( req , res , next ) {

2 try {
3 l e t observable = await actionService . executeAction ( actionId ,
currentUser , currentChat ) ;
4 observable . subscribe ({
5 n e x t : ( v a l u e ) => r e s . w r i t e ( v a l u e ) ,
6 e r r o r : ( v a l u e ) => r e s . w r i t e ( v a l u e ) ,
7 c o m p l e t e : ( ) => r e s . end ( ) ,
8 }) ;
9 } catch ( error ) {
10 next ( e r r o r ) ;
11 }
12 }
13

Listing 3.3 API controller

3.3.4.2 Services
Os services representam a camada logica de tratamento da requisição, o caminho intermediário
entre a chamada e a persistência, onde ocorre qualquer tratamento dos dados quanto validações
que possam gerar erros.
No exemplo abaixo é mostrado a ação sendo requisitada para o actionDAO, para logo depois
ser enviada para o Server Manager executa-la.

1 async executeAction ( actionId , actionObject , cu r re n tU s er ) {

2 l e t a c t i o n = a w a i t actionDAO . g e t ( a c t i o n I d , c u r r e n t U s e r , ’ t r u e ’ ) ;
3
4 l e t response = await serverManager . executeStepedAction ( action ,
actionObject ) ;
5 return response ;
6 }
7

Listing 3.4 API Service

3.3.4.3 Models
O componente Models corresponde a toda a lógica relacionada a dados com a qual o usuário
trabalha. Isso pode representar os dados que estão sendo transferidos entre os componentes
View e Controller ou qualquer outro dado relacionado à lógica de negócios [11].
No bloco de código abaixo, é exemplificado o Model das actions da plataforma, fazendo o
uso da biblioteca Mongoose Js12 , que funciona como um wrapper da biblioteca original13 do
MongoDB14 para Node.js.
12 http://mongoosejs.com/
13 https://github.com/mongodb/node-mongodb-native
14 https://www.mongodb.com/
 3.3 API - O LABORATÓRIO PARTE 2 19

1 new Schema ( {
2 name : {
3 type : String ,
4 required : true
5 },
6 description : {
7 type : String
8 },
9 server : {
10 t y p e : Schema . Types . O b j e c t I d ,
11 ref : ’ Server ’ ,
12 required : true
13 },
14 steps : [
15 {
16 stepNumber : {
17 t y p e : Number ,
18 required : true
19 },
20 command : {
21 text : {
22 type : String ,
23 required : true
24 },
25 inputs : [{
26 question : {
27 type : String
28 },
29 answer : {
30 type : String
31 },
32 varName : {
33 type : String
34 },
35 server : {
36 t y p e : Schema . Types . O b j e c t I d ,
37 ref : ’ Server ’
38 }
39 }]
40 }
41 }
42 ],
43 userId : {
44 t y p e : Schema . Types . O b j e c t I d ,
45 required : true
46 }
47 } , { timestamps : t r u e }) ;
48

Listing 3.5 Action Model

 20 CAPÍTULO 3 MORI’S LAB

3.3.4.4 Data access objects

Objeto de acesso a dados (DAO) é um objeto que fornece uma interface abstrata para algum
tipo de banco de dados ou outro mecanismo de persistência [2].
No bloco abaixo é mostrado o função que retorna uma ação do banco de dados, usada no
código demonstrado na seção 3.3.4.3.
1 get ( actionId , currentUser ) {
2 r e t u r n new P r o m i s e ( ( r e s o l v e , r e j e c t ) => {
3 Action . findOne ({ _id : a c t i o n I d , u s e r I d : c u r r e n t U s e r . _id }) .
p o p u l a t e ( ’ s e r v e r ’ ) . exec ( f u n c t i o n ( err , a c t i o n ) {
4 if ( err ) return reject ( err ) ;
5
6 if (! action ) {
7 r e t u r n r e j e c t ( new D a t a N o t F o u n d E r r o r ( ) ) ;
8 }
9
10 resolve ( action ) ;
11 }) ;
12 }) ;
13 }
14

Listing 3.6 API DAO

3.3.4.5 Criptografia
A criptografia dos dados de servidor é feita através de uma biblioteca que funciona por cima do
modulo crypto15 do Node.js, a criptografia é feita usando AES-256-CBC16 , um cipher muito
usado na internet por SSL/TLS17 , ele é usado com um vetor de inicialização exclusivo e aleató-
rio para cada operação, servindo como secret. A autenticação para leitura dos dados é realizada
usando o HMAC-SHA-51218 , uma função hash de codificação baseada no secret.

3.4 Heart

O Microservice foi inicialmente proposto para facilitar o uso de autenticação e garantia de iden-
tidade, para melhor organização do código e modularidade do projeto, e se tornou uma parte
essencial para a plataforma, assim como possivelmente será para trabalhos futuros, facilitando
bastante a escalabilidade da plataforma.
Heart foi desenvolvido como um Microservice para autenticação, podendo ser usado in-
dependentemente por qualquer aplicação através de sua API REST, porém é necessário uma
chave de API para ser possível sua utilização, isso para ter rastreabilidade das aplicações e seus
usuários.
15 https://nodejs.org/api/crypto.html
16 https://en.wikipedia.org/wiki/Advanced ncryption tandard
E S
17 https://en.wikipedia.org/wiki/Transport ayer ecurity
L S
18 https://en.wikipedia.org/wiki/HMAC
 3.4 HEART 21

Figura 3.9 Arquitetura Heart

3.4.1 Tecnologias
Seguindo o padrão da API, o Microservice também foi desenvolvido fazendo uso das tecno-
logias Node.js e o framework Express, e com a mesma arquitetura, descritos na seção 3.3.1,
porém seu código é bastante simples, já que por sua vez trata-se de um Microservice.

3.4.2 Mind Middleware

O middleware foi desenvolvido para gerenciar as diferentes aplicações e suas chaves de API, ele
é aplicado antes das rotas para configurar os objetos de aplicação, usuário e chat(se necessário)
da atual sessão da requisição.

3.4.2.1 Autenticidade
A autenticidade é feita a partir de Json Web Token(JWT)19 , que é um padrão RFC-751920 de
mercado que define como transmitir e armazenar objetos JSON de forma compacta e segura
entre diferentes aplicações [13].
19 https://en.wikipedia.org/wiki/JSON eb oken
W T
20 https://tools.ietf.org/html/rfc7519
22 CAPÍTULO 3 MORI’S LAB

Fazendo uso do JWT e da chave de API o Microservice recupera os dados do usuário para
configurar a requisição com os dados de conta e aplicação para serem utilizados pela aplicação
que chamou o Microservice.

3.4.2.2 Rotas
O Microservice é composto por apenas três rotas, sendo uma para login, que retorna um novo
token, uma para autenticação e outra para verificar se o token passado é valido, retornando o
objeto do usuário.

Tabela 3.5 Rotas Heart

Descrição Método Rota
Verify token GET /
Login POST /auth/login
Signup POST /auth/signup

3.5 Server Manager

Foi construído com a proposta de controlar todos os acessos a servidores dos usuários, de
maneira simples e direta;

3.5.1 Tecnologias
Apesar do Server Manager ser construído com as mesmas tecnologias que a API (seção 3.3.1) e
Microservice Heart (seção 3.4.1), seus padrões de projeto e arquitetura são diferentes e bastante
mais simples. pois possui funcionalidade única, essa sendo executar commandos em servidores
e manter stream de dados entre servidores e API das respostas obtidas.

3.5.2 Arquitetura
Sua arquitetura não faz uso de middlewares personalizados como nos outros projetos, pos-
suindo um controller único e serviço único, que fazem todo o controle das conexões e stream
de dados.

3.5.3 Executando ações

• Tratamento de ações: Para compreendermos a conexão com os servidores, devemos en-
tender como o tratamento das ações funcionam, a API ira enviar uma requisição para o
Server Manager, passando um objeto de ação, o Server Manager que por sua vez ira re-
ceber esse objeto de ação, aplicar o algoritmo de substituição das variáveis configuradas
nos inputs (seção 3.2.3.2) e respondidas pelos usuários através dos chat.
 3.6 MORI (CHATBOT) 23

Figura 3.10 Arquitetura Server Manager

• Conexão com servidores: Com os comandos devidamente preenchidos e tratados, o Ser-

ver Manager ira abrir a primeira conexão com servidor, que se for efetuada com sucesso
ira iniciar a execução.

• Executando: o comando será executado e suas respostas serão enviadas em tempo de

execução através de uma stream, sempre que um step for terminado o outro será ime-
diatamente iniciado, sempre seguindo ordem correta configurada no Dashboard (seção
3.2). Essa execução pode ser cancelada a qualquer momento, se requisitada pelo usuário
através do chat pelo uso do comando "cancel"descrito melhor na seção 3.6.2.

3.6 Mori (ChatBot)

Mori, a ChatBot é o módulo da plataforma que conversa com o usuário, servindo de inter-
face para que as ações sejam executadas, trazendo visibilidade das execuções em tempo real e
controle de seus dados.
O ChatBot foi desenvolvido inicialmente apenas para o telegram21 , uma plataforma de men-
sagens open source, sendo um dos grandes concorrentes do aplicativo de mensagens whatsapp.
O telegram foi escolhido pois disponibiliza uma plataforma, API e bibliotecas muito completas
21 https://telegram.org/
24 CAPÍTULO 3 MORI’S LAB

direcionadas ao desenvolvimento de ChatBots, possibilitando assim criar soluções muito mais

completas de maneira mais simples e rápida.

3.6.1 Arquitetura
A aplicação foi construída utilizando Node.js e fazendo uso da biblioteca framework para cri-
ação de BOTS para telegram, Telegraf22 , que funciona sobre a API do próprio telegram.

Figura 3.11 Arquitetura Mori

3.6.1.1 Event Handling - Tratameto de Eventos

A camada de tratamento de eventos é a camada que escuta o que usuário manda para o serviço
de mensagens do telegram e verifica respostas configuradas para que sejam tratadas, interpre-
tadas e a partir disso montar a resposta correta, esse processo de construção de resposta faz uso
dos services para leitura e escrita na API.

3.6.1.2 Services
A camada de services é a camada que faz comunicação entre o BOT e o Laboratório (API), tra-
zendo assim informações e gerando dados, assim como executando ações e mantendo streams
ativas ao chat.

3.6.2 Eventos
• /start - inicia a conversa com a Mori, ela a partir disso mandará instruções básicas sobre
como conversar com ela, baseado se o usuário esta autenticado ou não.
22 https://telegraf.js.org/
 3.6 MORI (CHATBOT) 25

• Ao mandar foto - A Mori ao receber uma foto vai tentar achar padrões de QRCode na
foto, para assim poder fazer a autenticação da sua conta ao chat, essa função é exclusiva
para autenticação.

• /help - Ira mostrar instruções assim como o /start.

• actions - Ira fazer a Mori listar as suas ações disponíveis, e a qual servidor elas estão
ligadas.

• execute nomeDaAção - Ira mandar a Mori executar uma ação no servidor, ela a partir
disso ira te fazer perguntas, caso a ação tenha inputs, para que sejam completados. Uma
vez que todas as perguntas estiverem respondidas, ela ira se comunicar com o Labora-
torio(API) através do services para mandar executar a ação, com isso, será iniciado uma
stream com seu servidor, mostrando o log em tempo real da execução dos comandos.

• cancel - Ira pedir para cancelar a ação atual, cancelando a stream e fazendo a Mori voltar
a seu estado inicial.

3.6.3 Sumário
Nesse capítulo foi abordado a definição do projeto e as arquiteturas e tecnologias dos diversos
componentes que o compõem, junto com suas regras de execução, segurança e detalhes. Tendo
assim uma noção de suas funcionalidades e de como funcionam em conjunto.
O próximo capítulo mostra como a plataforma entrega seu valor usando seus componentes
em casos de uso reais para demonstrar os benefícios alcançados.
 C APÍTULO 4

Mori em ação

Neste capítulo é demonstrado casos de uso em servidores reais que mostram de modo prático
em que tipo de situações a Mori pode ser utilizada, mostrando seu passo a passo de execução e
analise de resultados.

4.1 Monitoramento via stream de log

Para esse teste, uma simples ação para stream de log foi configurada, capaz de trazer transpa-
rência com apenas um step e um input, sendo o cadastro demonstrado na figura 4.1.

Figura 4.1 Cadastro de stream de log

Ao ser executado o BOT ira fazer a pergunta do input para o step como mostra a figura 4.2.

27
28 CAPÍTULO 4 MORI EM AÇÃO

Figura 4.2 Stream de log 1

Apos responder o nome do arquivo, todas os inputs já estarão preenchidos, sendo assim
iniciada a execução remota. Com isso, ela ira mandar parte do arquivo, e iniciara a stream de
dados para novas entradas como mostra a figura 4.3.

Figura 4.3 Stream de log 2

Nesse exemplo vamos monitorar novas sessões em um servidor. Pedimos para Mori moni-
torar o arquivo "/var/log/syslog", que é o arquivo de log do sistema operacional Ubuntu1 que
registra as sessões dos usuários, ou seja, sempre que um usuário iniciar uma sessão, isso sera
registrado nesse arquivo. Com a stream ativa, iniciei uma conexão ssh no mesmo servidor que a
Mori está observando o syslog, como demonstra a figura 4.4, assim que a conexão foi iniciada
1 https://www.ubuntu.com/
 4.1 MONITORAMENTO VIA STREAM DE LOG 29

a Mori nos envia o nova entrada no log figura 4.5. Esse monitoramento registrou resultados
com delay em média de menos de um segundo.

Figura 4.4 Stream de log 3

Figura 4.5 Stream de log 4

30 CAPÍTULO 4 MORI EM AÇÃO

4.2 Movendo banco de dados entre servidores

Nesse teste irei mover entre servidores a base de dados de exemplo disponibilizada pele equipe
do mysql chamada sakila, essa ação necessita de apenas 3 steps e 3 inputs demonstrados na
figura 4.6.

Figura 4.6 Cadastro de mover dump

Ao requisitar a execução da ação, a Mori ira começar a perguntar os steps necessários,

iniciando pela pergunta de qual banco de dados vai ser feito o dump figura 4.7.

Figura 4.7 Mover dump 1

Após isso, será perguntado para qual servidor o dump devera ser enviado figura 4.8.
 4.2 MOVENDO BANCO DE DADOS ENTRE SERVIDORES 31

Figura 4.8 Mover dump 2

Em seguida será perguntado qual o usuário de acesso ao servidor figura 4.9.

Figura 4.9 Mover dump 3

Com o fim dos inputs, a Mori ira fazer o processamento das respostas e enviar a ação
preenchida para a API executá-la, ativando assim a stream de execução em tempo real dos
comandos como mostra a figura 4.10 e 4.11.

Figura 4.10 Mover dump 4

32 CAPÍTULO 4 MORI EM AÇÃO

Figura 4.11 Mover dump 5

Tanto o tempo de execução do dump quanto o tempo de transferência de arquivos entre

servidores são variáveis dependentes de tamanho da base de dados, nesse caso, por se tratar de
uma data base de dados pequena, toda a execução não chegou a durar 2 segundo.

4.3 Sumário

Nesse capitulo foi demonstrado alguns exemplos práticos possíveis da utilização da plataforma,
trazendo benefícios como transparência de dados e resiliência. Uma vez que é possível observar
em tempo real entrada de dados e automatizar backup/envio de dados entre servidores.
 C APÍTULO 5

Conclusão

O GitHub deu um passo muito importante para a área de DevOps e ChatBots com seu en-
tusiasmo e introdução do conceito de ChatOps, trazendo um grande valor levando em conta
que a adoção de ferramentas de Continuous Integration e Continuos Delivery vem se tornando
bastante popular tanto em grandes empresas como novas startups. Trazendo benefícios de agi-
lidade e maior transparência de todo o processo de uma aplicação.
Com o desenvolvimento desse trabalho, a plataforma, seus serviços e modelos, foi possível
provar de maneira pratica e simples a automação via chat de tarefas simples e bastante distin-
tas. Tendo seu objetivo principal concluído, que era do desenvolvimento da plataforma, que
encontrasse em produção e disponível para uso1 . Também foi possível alcançar transparência,
resiliência e alta disponibilidade nos servidores, uma vez que é possível configurar ações ca-
pazes de gerar streams em tempo real de dados, fazerem backups, atuar para recuperações de
desastres transferindo dados e comunicação entre inúmeras instâncias.
Com os testes feitos foi possível ilustrar sua capacidade de executar ações em casos reais,
trazendo mais agilidade aos times, mesmo o projeto se limitando em comandos que não en-
volvem respostas interativas (que respondem perguntas do próprio sistema). Além de que a
comunicação entre servidores encontrasse em um estado simples inicial, onde é necessário o
uso de senhas inline. Outra Limitação é que as actions não são testadas automaticamente no
momento de criação, deixando sob responsabilidade do autor sua eficácia.

5.1 Trabalhos Futuros

• Inteligência Artificial: Investigar inteligência artificial, para ser implantada de modo

que consiga predizer problemas e agir sozinha.

• Tipos de Conexões: Sera estudado outras maneiras além de SSH de garantir a conexão
com servidores.

• SSH Por par de chaves: Sera adicionada a opção de autenticação de servidor via chaves,
evitando o uso de senhas e trazendo mais segurança.

• Suporte a VPN: Por questões de segurança, diversas empresas não abririam seus servi-
dores para internet, por isso que tal suporte sera extremamente essencial.
1 http://morislab.com

33
34 CAPÍTULO 5 CONCLUSÃO

• Teclado Interativo: Funcionalidade atual sob estudo, sera adicionado interatividade as

ações em nível de servidor.

• Marketplace de Ações: Sera desenvolvido um marketplace onde as ações possam ser

compartilhadas e reusadas.

• Novas interfaces de execução: Sera estudado novos provedores de ChatBots para serem
adotados, assim como possível desenvolvimento de aplicativo.
 Referências Bibliográficas

[1] A MAZON. What is devops?

[2] E VERYKING , M AC T ED , R EDW OLF . Data access object — Wikipedia, the free encyclo-
pedia, 2004. [Online; accessed 22-July-2018].

[3] FARLEY, J. H. D. Continuous Delivery, 1 ed. Addison-wesley, 2010.

[4] FELL, S. Are you talking to me? chatops and the rise of conversation-driven devops.

[5] F URDA , A., F IDGE , C., Z IMMERMANN , O., K ELLY, W., AND BARROS , A. Migrating
enterprise legacy source code to microservices: On multitenancy, statefulness, and data
consistency. IEEE Software 35, 3 (May 2018), 63–72.

[6] G AN , Y., AND D ELIMITROU , C. The architectural implications of cloud microservices.

IEEE Computer Architecture Letters 17, 2 (July 2018), 155–158.

[7] H AHN , E. Understanding express.js.

[8] HULME, G. V. Chatops: Communicating at the speed of devops.

[9] I O , H. N., AND L EE , C. B. Chatbots and conversational agents: A bibliometric analy-

sis. In 2017 IEEE International Conference on Industrial Engineering and Engineering
Management (IEEM) (Dec 2017), pp. 215–219.

[10] K ERSTEN , M. A cambrian explosion of devops tools. IEEE Software 35, 2 (March 2018),
14–17.

[11] KONONENKO , K. Model-view-controller (mvc) explained through ordering drinks at the

bar.

[12] M ARIJAN , D., L IAAEN , M., AND S EN , S. Devops improvements for reduced cycle times
with integrated test optimizations for continuous integration. In 2018 IEEE 42nd Annual
Computer Software and Applications Conference (COMPSAC) (July 2018), pp. 22–27.

[13] NASCIMENTO , W. Entendendo tokens jwt (json web token).

[14] N EWMAN , S. Building Microservices: Designing Fine-Grained Systems, 1 ed. O’Reilly

Media, 2015.

[15] OTEMUYIWA , P. Angular 5 release: What’s new?

35
36 REFERÊNCIAS BIBLIOGRÁFICAS

[16] PAUL M. D UVALLITH , S TEVE M ATYAS , A. G. Continuous Integration Improving Soft-

ware Quality and Reducing Risk, 1 ed. Addison-wesley, 2007.

[17] R AHMAN , A. M., M AMUN , A. A., AND I SLAM , A. Programming challenges of chat-
bot: Current and future prospective. In 2017 IEEE Region 10 Humanitarian Technology
Conference (R10-HTC) (Dec 2017), pp. 75–78.

[18] S HAHIN , M., BABAR , M. A., Z AHEDI , M., AND Z HU , L. Beyond continuous delivery:
An empirical investigation of continuous deployment challenges. In 2017 ACM/IEEE
International Symposium on Empirical Software Engineering and Measurement (ESEM)
(Nov 2017), pp. 111–120.

[19] S TUART J. RUSSELL , P. N. Artificial Intelligence A Modern Approach, 1 ed. Prentice

Hall, 2007.

[20] TAIBI , D., L ENARDUZZI , V., AND PAHL , C. Processes, motivations, and issues for
migrating to microservices architectures: An empirical investigation. IEEE Cloud Com-
puting 4 (2017), 22–32.

[21] V IVAH , L. The beginner’s guide: Understanding node.js & express.js fundamentals.