DISSERTAÇÃO
BELIN, Matheus [1], SOUSA JUNIOR, Rafael Timóteo de [2], PUTTINI, Ricardo Staciarini [3]
BELIN, Matheus. SOUSA JUNIOR, Rafael Timóteo de. PUTTINI, Ricardo Staciarini. Estudo de caso de desenvolvimento de plataforma de cloud governamental para TI bimodal. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano 06, Ed. 02, Vol. 06, pp. 126-150. Fevereiro de 2021. ISSN: 2448-0959, Link de acesso: https://www.nucleodoconhecimento.com.br/tecnologia/cloud-governamental, DOI: 10.32749/nucleodoconhecimento.com.br/tecnologia/cloud-governamental
RESUMO
O cenário é comum na TI das organizações: de um lado, o time de desenvolvimento, preocupado exclusivamente em entregar aplicações em períodos cada vez menores, sem se preocupar com questões como infraestrutura de TI e o ambiente necessário para dar estabilidade aos softwares desenvolvidos. De outro, o setor de operações que, com os olhos fixos na infraestrutura, ignora as particularidades do processo de desenvolvimento. Como os dois segmentos atuam de forma compartimentalizada e com visão global limitada, o resultado costuma ser de pouca eficiência e muitos incidentes. A TI bimodal caracteriza-se pelo uso de dois modelos de operação com propósitos distintos: 1) confiabilidade e; 2) agilidade. O presente estudo é baseado em caso de implementação de estratégia para adoção de TI Bimodal como solução de convivência. Partindo do princípio da criação da camada base, que é a implementação do Data Center definido por Software e da consequente entrega de IaaS (Infraestrutura como Serviço); para o início da segunda etapa de modelagem estratégica e de implementação do DevOps. O presente trabalho cobre um conjunto de práticas abrangentes o suficiente para auxiliar diferentes organizações que tenham interesse e necessidade no desenvolvimento de plataformas com mais de um modo de operação e aumentar o seu grau de maturidade no uso de cloud privada.
Palavras-chave: TI Bimodal, Cloud, DevOps.
1. INTRODUÇÃO
1.1 CONTEXTO GERAL
Grandes corporações buscam desenvolver o conceito e a aplicação de cloud. Em suas dúvidas surgem a utilização de plataformas públicas, privadas ou o conceito híbrido. O tema abordado para este estudo desenvolve a linha de raciocínio da TI Bimodal, aplicando uma nova forma de operação e de desenvolvimento e mantendo os ambientes e sistemas legados, para um roadmap de convivência de plataformas.
Segundo Berry; Mok e Coleman (2015), TI Bimodal refere-se a ter dois modos de operação de TI, onde cada um é projetado para desenvolver e fornecer serviços de tecnologia. O Modo 1 é mais tradicional, enfatizando a segurança e a precisão. Já o Modo 2 não é tão sequencial, enfatizando a agilidade e a velocidade. Cada modo possui pessoas, recursos, parceiros, estrutura, cultura, metodologias, governança, métricas e atitudes relacionadas ao valor requerido pela organização e aos riscos existentes no mercado.
Conforme Mahapatra (2015), a capacidade bimodal envolve a convivência de duas abordagens distintas, mas coerentes entre si na criação e entrega de mudanças requeridas pelo negócio.
De forma geral:
a) modo 1: é uma abordagem linear para mudar, enfatizando previsibilidade, precisão, confiabilidade e estabilidade;
b) modo 2: é uma abordagem não-linear que envolve aprendizagem através da interação, enfatizando agilidade e velocidade e, acima de tudo, a capacidade de gerir a incerteza.
Podemos observar na tabela 1, uma comparação direta entre os processos e os conceitos desses dois modos.
Tabela 1 – Comparação entre o modo 1 e 2
| Variável | Modo 1 | Modo 2 |
| Objetivo | Confiabilidade | Agilidade |
| Valores | Desempenho e preço | Experiência do usuário, marca, receita, serviços |
| Sourcing | Fornecedores de classe mundial, contratos de longo prazo | Recursos adaptativos, vendedores menores, contratos de curto prazo |
| Cultura | Acesso a riscos e focada em métricas de processos | Tolerante a riscos e foco no resultado dos negócios |
| Tipo de TI | Execução de operação e crescimento orgânico | Transformacional |
| Tipo de Negócio | Baseado em medo e fatos | Baseado em propósito |
| Sistemas chave de gerenciamento | Comparações com mercado, métricas de custo, qualidade e riscos e business case | Patrocínio e gerenciamento do escopo |
| Patrocinador | Organização de TI, unidades de negócio e setores administrativos | Unidades de negócio, inovações corporativas |
Fonte: Adaptado de Mahapatra (2015)
O governo federal estabeleceu através da Norma complementar n. 14/IN01/DSIC/GSIPR (BRASIL, 2018), princípios, diretrizes e responsabilidades relacionados à Segurança da Informação para o tratamento da informação em ambiente de computação em nuvem. Publicou também a revisão da IN01/SGD/ME (BRASIL, 2018), já ocorrendo a previsibilidade de contratações em nuvem, corroborando com as tendências e uso de mercado.
A partir de 2017 diversos órgãos da Administração Pública Federal – APF efetivaram contratos com vistas a viabilização da adoção de infraestrutura para construção de cloud privada (BRASIL, 2019).
Segundo Brasil (2020)
o aprimoramento e a extensão do conceito de virtualização possibilitaram o surgimento de outras tecnologias como Software Defined Network (SDN), Software Defined Storage (SDS), e por último Software Defined Data Center (SDDC) que mudou o paradigma do Data Center por completo.
SDN e SDS são tecnologias que virtualizam a rede e o storage respectivamente, além de oferecer recursos de gerenciamento, orquestração e programação.
A adoção da TI Bimodal de forma estratégica se torna uma solução de convivência viável entre os diversos cenários de sistemas e aplicações do governo federal. Com base nesta assertiva, uma grande Empresa Pública de Tecnologia do Governo Federal Brasileiro adotou a construção de sua própria plataforma de Cloud com vistas a se tornar provedor de serviços de Cloud (Cloud Service Provider) e possuir novo modelo de operação baseado em Cloud em seus 03 Data centers, desenvolvendo com sucesso a prática da TI Bimodal na implementação de processo completo de virtualização com oferta de Infraestrutura como Serviço (IaaS).
A natureza dinâmica de uma Cloud exige a otimização de processos para a alocação de recursos com o objetivo de reduzir consumos excessivos e viabilizar a agilidade necessária. Sendo assim, apresentamos como estudo de caso as práticas desenvolvidas na implementação de nuvem privada em Empresa Pública de Tecnologia da Informação, que estabelecendo uma convergência entre as ações e os conceitos acima descritos, Cloud computing e SDDC, viabilizou a adoção estratégica da TI Bimodal, com base na plataforma de sustentação dos serviços oferecidos e operados em nuvem própria.
1.2 OBJETIVO
1.2.1 OBJETIVO GERAL
Apresentar modelo de referência em SDDC validado por estudo de caso como ação inicial de roadmap para adoção de nuvem e consequente adoção da estratégia TI Bimodal.
1.2.2 OBJETIVO ESPECÍFICO
- Estabelecer modelo de referência experimentado para implementação de virtualização completa com orquestração, controle, governança e conformidade;
- Elaborar desenho de referência de arquitetura de SDDC para etapa inicial de implantação de cloud;
- Estabelecer planejamento direto e indireto mínimo para a jornada de implementação do SDDC.
1.2.3 METODOLOGIA
A pesquisa documental estabelecida é a que serve dessas fontes. Ela assemelha-se à pesquisa bibliográfica. A natureza das fontes estabelece a diferença (VIEIRA, 2018). Conforme Yin (2005), este tipo de pesquisa “é constituído pelo exame da matéria que ainda não receberam um tratamento analítico ou que podem ser reexaminados com vistas a uma interpretação nova ou complementar.”
A construção de um modelo de referência para propor um padrão de adoção inicial em nível estratégico para adoção da TI Bimodal e em nível operacional para a construção de um ambiente de virtualização baseado em SDDC, leva em consideração um estudo de caso que, segundo Neves (1996), é uma estratégia de pesquisa que busca examinar um fenômeno contemporâneo, levando em consideração o contexto envolvido e referindo-se exatamente ao presente. Esta decisão fica evidenciada, uma vez que se utiliza um conjunto de práticas presentes atualmente na ótica empresarial.
1.2.4 ORGANIZAÇÃO DO PAPER
Este artigo está estruturado da seguinte maneira: No item 2, são apresentados os conceitos e a fundamentação teórica para definição e análise do modelo de referência proposto. No item 3, é apresentada a proposta do modelo de referência. No item 4, o modelo proposto é analisado no contexto de um estudo de caso implementado. Por fim, o item 5 apresenta as conclusões obtidas no estudo e possíveis desdobramentos futuros para a continuidade da pesquisa.
2. REFERENCIAL TEÓRICO
2.1 TI BIMODAL
Criado em 2013 pela Gartner Inc, o termo “TI Bimodal” surgiu com a proposta de ser uma solução para as limitações da TI tradicional e para conseguir fazer com que os novos desafios da tecnologia sejam mais bem desenvolvidos, aprimorados e colocados em prática pelas organizações. Essa abordagem propõe que a área de tecnologia funcione com duas frentes de atuação diferentes: Modo 1 e Modo 2. Essa nova abordagem procura trabalhar para tornar a experiência dos seus usuários a melhor possível, sejam eles internos ou externos.
A TI bimodal vai além da metodologia de projetos da organização e requer uma atuação ao longo de todo ciclo de desenvolvimento e operações. Envolve também questões como modelo mental, aspectos culturais, estrutura organizacional e habilidades de liderança que assegurem a gestão efetiva destes dois modos de operação (BRASIL, 2020).
A figura 1 representa o modelo Enterprise da TI Bimodal.
Figura 1 – Modelo Enterprise
Podemos observar que o Modo 2 possibilita criar uma estrutura flexível o suficiente para os trabalhos de pesquisa e desenvolvimento de novos produtos e serviços. Além disso, essa postura também permite dar a TI um olhar mais estratégico, tornando-a capaz de se adequar às necessidades mais diversas, sendo capaz de interagir com as outras áreas da organização de forma eficiente, aumentando a colaboração e a capacidade de competitividade do negócio no mercado, tudo isso sem abandonar tudo que já foi construído e precisa ser mantido por vários anos.
2.2 AUTOMAÇÃO
Automação de infraestrutura é o processo de codificar ambientes de TI, ou, infraestrutura como código. Ou seja, a automação é a forma mais prática de se evitar tarefas manuais e repetitivas (HAFKE; KALGOVAS e BENLIAN, 2017). Terry Slattery (2010), da consultoria de redes Netcraftsmen, cita que o principal fator para se adotar automação de redes é evitar erros humanos. Segundo ele, configurar centenas de roteadores e switches não deveria ser uma tarefa manual (DUVALL, 2012). Com isso, percebe-se que a automação além de uma necessidade está sendo amplamente defendida pela indústria de tecnologia. Ou seja, a automação da infraestrutura é um passo importante que gera dinamismo, flexibilidade e qualidade na entrega de serviços de TI.
2.3 CLOUD
O Gartner define Cloud como sendo “um estilo de computação escalável e elástica na qual os recursos de TI são fornecidos como um serviço para clientes externos, a partir da internet”.
Na figura 2, observamos um mapa de serviços em cloud. Cabendo uma reflexão, entendemos que o trabalho em questão aponta para a construção de nuvem privada, atendendo assim, a entrega dos serviços como modelo de negócio a serem comercializados.
Figura 2 – Mapa de Tipos de Serviços em Cloud
2.4 ARQUITETURA SDDC
Em Bezerra (2016), SDDC é definido como “uma plataforma unificada que fornece automação, flexibilidade e eficiência para transformar a maneira de entrega dos serviços de TI. Servidores, storage e rede são reunidos, agregados e entregues como software e são gerenciados por um software inteligente.” O resultado disso é um Data Center otimizado que proporciona agilidade aos negócios, Acordo de Nível de Serviço (ANS) mais altos para as aplicações, operações drasticamente mais simples, e custos menores.
Podemos observar na figura 3 que, conforme apontam Hafke, Kalgovas e Benlian (2017), um Data center definido por software possui alta escalabilidade e redundância completa.
Figura 3 – Ilustração de dois Data Centers. Adaptado pelo autor.
2.5 FRAMEWORK E FERRAMENTAS
Na figura 4, temos um modelo adaptado com as necessidades básicas para a implementação de um recurso de cloud com vistas a execução inicial de um planejamento de IaaS.
Figura 4 – Framework para gerenciamento de Cloud
2.5.1 CAMADA FÍSICA
A camada mais baixa da solução é a camada física, às vezes chamada de camada principal, que consiste nos componentes de computação, rede e armazenamento. Dentro do componente de computação, estão os servidores que executam as cargas de trabalho de gerenciamento e recursos.
2.5.2 CAMADA DE INFRAESTRUTURA VIRTUAL
A camada de infraestrutura virtual fica no topo dos componentes da camada física. A camada de infraestrutura virtual controla o acesso à infraestrutura física subjacente e controla e aloca recursos para as cargas de trabalho de gerenciamento e recursos. As cargas de trabalho de gerenciamento consistem em elementos na própria camada de infraestrutura virtual, juntamente com elementos nas camadas de gerenciamento de nuvem, gerenciamento de serviços, continuidade de negócios e segurança.
2.5.3 CAMADA DE GERENCIAMENTO EM NUVEM
A camada de gerenciamento de nuvem é a camada mais alta do framework. O consumo de serviço ocorre nesta camada. Essa camada exige recursos e orquestra as ações das camadas inferiores, mais comumente por meio de uma interface de usuário ou interface de programação de aplicativos (API).
2.5.4 CAMADA DE GERENCIAMENTO DE SERVIÇOS
Ao construir qualquer tipo de infraestrutura de TI, o gerenciamento de operações desempenha funções importantes na prestação contínua de serviços no dia a dia. A área de Gerenciamento de Serviços dessa arquitetura concentra-se principalmente no gerenciamento de operações, em especial monitoramento, alertas e gerenciamento de logs.
2.5.5 CAMADA DE CONTINUIDADE DE NEGÓCIOS
Um sistema corporativo deve conter elementos para oferecer suporte a continuidade de negócios fornecendo backup de dados, restauração, e recuperação de desastres. Se a perda de dados ocorrer, os elementos certos devem estar no lugar para evitar perdas permanentes no negócio.
2.5.6 CAMADA DE SEGURANÇA
Todos os sistemas precisam ser seguros por definição. Um desenho de arquitetura seguro reduz o risco, e aumenta a conformidade ao fornecer uma estrutura de governança. A camada de segurança descreve o que é necessário para garantir que todo o SDDC seja resiliente a ameaças internas e externas.
2.6 DEVOPS
Considerando que um ambiente de virtualização na TI Bimodal é utilizado com a integração de ferramentas de desenvolvimento, ocasionando uma nova rede de compliance e formatos de entrega, deve-se levar em consideração a preparação do ambiente virtualizado para as conexões com o novo modelo de operar e desenvolver.
Pode-se mencionar, por exemplo que, segundo Slattery (2010), o termo DevOps deriva da junção das palavras “desenvolvimento” (development) e “operações” (operations), sendo uma prática de engenharia de software que possui o intuito de unificar o desenvolvimento de software (Dev) e a operação de software (Ops).
Um princípio basilar do DevOps é investir em automação. Automação permite executar tarefas mais rapidamente e diminui a possibilidade de erros humanos. Um processo automatizado é mais confiável e pode ser auditado com mais facilidade. Além disso, conforme o número de servidores que precisam ser administrados dentro do parque computacional, aumentar processos automatizados se torna essencial. Podemos observar no diagrama em blocos da figura 5 que a integração dos ambientes estabelece uma mudança de paradigma e nova forma da empresa operar.
Figura 5 – Diagrama em blocos DevOps
Com o avanço da cultura DevOps e o aumento da colaboração entre administradores de sistema e desenvolvedores, diversas ferramentas têm evoluído para facilitar e padronizar o gerenciamento automatizado de infraestrutura.
Tais ferramentas permitem tratar infraestrutura da mesma forma que tratamos código de um programa, usando controle de versões, realizando testes, empacotando e distribuindo módulos comuns e, obviamente, executando as mudanças de configuração no servidor. Essa prática é conhecida como infrastructure as code. Na figura 6, podemos observar o conceito fim-a-fim para a aplicação da cultura DevOps.
Figura 6 – Figura base fim-a-fim para DevOps
3. ESTUDO DE CASO
O estudo de caso se deu em uma grande empresa de tecnologia da informação responsável pelo processamento de dados de cidadãos brasileiros. Esta empresa possui 03 (três) Data centers com certificações internacionais e engenharia de facilities consolidada. A solução foi implantada e analisada em dois Data Centers a fim de prover para os usuários finais diferentes zonas de disponibilidade para instanciar suas aplicações.
A plataforma de computação em Nuvem da empresa foi implementada utilizando a suíte vCloud da VMware. Ela tem por objetivo disponibilizar um portal de autosserviço para que os clientes consumam os recursos computacionais disponibilizados pela Empresa.
Com a capacidade de prover uma nuvem híbrida e isolamento completo entre os seus clientes, bem como uma nova forma de operação de sua infraestrutura, a nuvem pode operar nos modelos de IaaS, PaaS, SaaS e XaaS.
3.1 PLANEJAMENTO E ESTRATÉGIA
Observando a necessidade de implantação do conceito da TI Bimodal como forma de convivência entre os dois modos descritos, premissas foram definidas a fim de que se estabelecesse o projeto como um todo, a saber:
- Não tentar fundir os universos de desenvolvimento e de operações a fim de evitar o choque cultural e as resistências naturais;
- Manter as tecnologias e os processos de desenvolvimento e de operações o mais similar aos já existentes para agilizar a curva de conhecimento necessária à adoção do modo 2;
- Automatizar os processos ITIL/COBIT relativos ao modo 2, de maneira que indicadores, controles e rastreabilidade definidos para o modo 1 pudessem ser idênticos aos do modo 2, porém gerados automaticamente;
- Automatizar processos pendentes de operações para o modo 2 (monitoramento, backup, segurança e testes de infraestrutura);
- Integrar as esteiras de desenvolvimento e de operações existentes para o modo 2, de maneira automatizada e agnóstica. A esteira de desenvolvimento deveria se conectar a qualquer esteira de operações (cloud) e a esteira de operações a deveria se conectar a qualquer esteira de desenvolvimento;
- Adequar normativos e plano de carreira (cargos) para contemplar as atividades do modo 2, que anteriormente eram estritamente segmentadas em desenvolvimento e operações.
Na figura 7, podemos observar a relação de convivência da TI Bimodal, necessária para manter a continuidade do ambiente tradicional e a evolução do ambiente em implantação.
Figura 7 – Framework de convivência para modo 1 e 2
Dentro do projeto, a matriz de responsabilidades foi definida conforme a tabela 2. Cabe observar que para melhor governança e evolução do projeto, foi definido um comitê de automação, na qual tem responsabilidades específicas, mantendo a documentação e a compliance definidas e atendidas.
Tabela 2 – Tabela de responsabilidades
| Atributos | Descrição |
| Comitê de automação | Definir regras sobre o uso das ferramentas, assim como papéis e responsabilidades. |
| Administrador | Gestão e configuração da ferramenta em nível de aplicação. |
| Líder de equipe | Inclui usuários ou grupos na equipe ao qual atua. |
| Especialista em automação | Constrói os modelos base que serão utilizados pelos desenvolvedores para automatizar o deployment das aplicações. |
| Desenvolvedor de aplicação | Automação de deployment de aplicações usando modelos pré publicados pelo especialista de automação. |
| Dono do produto | Realiza implantações em um ambiente de homologação, quando houver permissão negociada com os atores. |
| Suporte de serviços | Suporte da ferramenta a nível de infraestrutura. |
| Operador de serviços | Gerencia os objetos na ferramenta que referencial elementos da infraestrutura. Agentes, ambientes, recursos, aprova aplicativos, componentes e processos, permitindo o seu uso em produção. Executa os processos de implantação em conformidade com o processo de requisição de mudanças. |
| Observador | Visualiza objetos e monitoramento. |
Fonte: Autor
O comitê de automação mostrado na Tabela 2 define as diretrizes estratégicas da iniciativa, mostradas na tabela 3, que representam um mapa sintetizado dos principais pontos abordados para a implantação dos projetos.
Tabela 3 – Gestão de pontos de atenção
| Atributos | Descrição |
| Objetivos e resultados | Definir claramente os objetivos e os resultados que devem ser alcançados com a execução do projeto. |
| Análise de Riscos |
Mapear os riscos para os data centers, infraestruturas e aplicações em geral. Identificar possíveis desastres naturais, como terremotos, enchentes, interrupções do serviço público de energia elétrica, acesso físico ao local entre outros. |
| Análise de Impactos |
Mapeamento dos possíveis impactos causados na infraestrutura ou nas aplicações: · Perda de Dados; · Integridade; · Indisponibilidade; · Multas Contratuais; · Penalidades Legais. |
| Estratégia e Continuidade |
A estratégia deve contemplar uma lista baseada no levantamento dos objetivos, riscos e impactos para determinar: · Tipo de Solução a ser adotada; · Necessidades Extras; · Acompanhamento de índices de volumetria e capacidade; · Verificar o nível de disponibilidade necessário e entender os requisitos de cada item que deve ser protegido/recuperado. |
| Prioridade e Dependências |
Construir uma lista com a classificação das aplicações e organizadas: · Grau de Criticidade; · Prioridade; · Dependências Internas; · Dependências Externas; · Ordem/Sequência de Boot. |
|
Proteção
|
Utilizar a lista de prioridade e dependências para determinar o nível de proteção que deve ser utilizado: · Alta Disponibilidade; · Tempo de restauração; · Tempo de recuperação; · Ordem de recuperação; · Processos internos definidos. |
| Equipes e Contatos |
Criar e manter uma lista atualizada das equipes que devem ser acionadas durante a recuperação do ambiente: · Contatos das equipes internas; · Contatos do suporte de todas as aplicações ou produtos; · Contatos dos Fornecedores. |
| Plano de Comunicação | Criar e manter atualizado um plano de comunicação para informar que a crise está decretada, e quais os protocolos de resposta devem ser seguidos. O plano de comunicação deve ter:
· Lista dos Órgãos de Governamentais, Departamento Jurídico, Dirigentes e responsáveis em geral, tomadores de decisão; · Previsão de retorno dos níveis de serviço; · Tipo de solução de recuperação que será utilizada, inclusive onde será restabelecido o serviço; · Capacidade de funcionamento, durante o período de crise; · Departamento Jurídico; · Serviços e Aplicações que serão recuperados em prioridade. |
| Processos de Atualização |
Definir políticas e processos que permitam a avaliação constante dos procedimentos e protocolos utilizados. · Frequência de testes do ambiente; · Atualizações dos procedimentos; · Atualização da solução. |
| Atribuição |
Criar lista com a definição dos papéis e onde cada membro deve atuar seguindo uma hierarquia, uma cadeia de comando: · Quem orquestra; · Quem executa; · Quem válida; · Quem comunica; · Quem trata os impactos causados. |
Fonte: Autor
Para a execução do cronograma inicial, foi definido Cronograma de referência para o projeto, mostrado na tabela 4, onde foram considerados os itens de desenvolvimento de projeto, implementação e ações de impacto direto e indireto, como jurídico e gestão de pessoas.
Tabela 4 – Cronograma de referência
| Cronograma de Referência do Projeto | Tempo Geral | ||
| Desenho da Solução | Projeto de infraestrutura virtualizada de modernização; | 40% | |
| Desenho da arquitetura e solução de rede; | |||
| Desenho da arquitetura e portal de automação; | |||
| Desenho da arquitetura da ferramenta vRI. | |||
| Implementação | Implementação do desenho da arquitetura virtual; | 50% | |
| Implementação da arquitetura da solução de redes (entre Data centers); | |||
| Implementação do portal de automação; | |||
| Implementação do desenho de arquitetura do portal de automação; | |||
| Customização blueprints; | |||
| Integrações externas (quando ocorrer); | |||
| Implementação da console de gerenciamento de operação; | |||
| Implementação da console de gerenciamento de rede; | |||
| Implementação do cluster de registros e logs. | |||
| Ações de projeto – governança, riscos, jurídico, pessoas e comunicação | Elaboração de matriz de responsabilidade; | 10% | |
| Consultas ao jurídico – pertinências operacionais e trabalhistas; | |||
| Ações de marketing interno e externo; | |||
| Licenciamento e ferramentas a serem integradas; | |||
| Análise de volumetria e projeções de custos futuros; | |||
| Definição de marketing e modelagem de vendas; | |||
| Definir ondas de capacitação, multiplicadores e fóruns. | |||
Fonte: Autor
Deve-se levar em consideração que, para o projeto de virtualização ter sucesso, ferramentas devem ser integradas para o processo de automação de códigos. Para a execução do cronograma supramencionado, foram definidos os seguintes marcos secundários:
- [MARCO 1] Instalação e configuração do Blueprint Designer concluída;
- [MARCO 2] Prova de Conceito de provisionamento de ambientes concluída;
- [MARCO 3] Modelo de uso publicado;
- [MARCO 4] POC de provisionamento de serviços em container concluída.
3.2 MODELO DE REFERÊNCIAS PARA TOPOLOGIA E ARQUITETURA
Observamos que as camadas estão diretamente correlacionadas, devido a necessidade de rastreabilidade, governança e compliance. Esta implementação foi feita em dois Data Centers, com a devida capacidade instalada e gerenciada.
Com o objetivo de disponibilizar um portal de autosserviço para que os clientes consumam os recursos computacionais disponibilizados pela Empresa e com capacidade de prover uma nuvem híbrida e isolamento completo entre os seus clientes, bem como uma nova forma de operação de sua infraestrutura, a nuvem pode operar nos modelos de IaaS, PaaS, SaaS e XaaS.
Na figura 8, temos um modelo de referência mínimo necessário com redundância, utilizando a suíte proprietária do fabricante VMware (www.vmware.com), amplamente conhecido e difundido para a implementação de um processo de cloud em modelo IaaS. Observamos que as camadas estão diretamente correlacionadas, devido a necessidade de rastreabilidade, governança e compliance.
Figura 8 – Arquitetura proposta para implantação de cloud no Data center
Para o 2º Data center, a figura 9 apresenta o modo de operação compartilhada, demonstrando que após a execução, ao invés de dois Data centers, a empresa passou a possuir apenas um Data center virtual, com diversos ambientes integrados e compartilhados.
Figura 9 – Arquitetura proposta para implantação de cloud no Data center B
Sua implementação foi feita utilizando-se a abordagem de building blocks, sendo os principais deles o Cluster de Gerenciamento e o Cluster de Recursos. Estes clusters são compostos por hosts dedicados a executar os servidores de gerenciamento e de recursos.
São componentes do cluster de Gerenciamento: vCenter Server Appliance (VCSA), Platform Services Controller Appliances (PSC), Células do vCloud Director, vCloud Extender Appliances, NSX Managers, NSX Controller Cluster (NSX Manager gerência), NSX Edges Load Balancers, vRealize Business for Cloud Appliance, Servidor NFS usado pelo vCloud Director, e servidores criados para a gerência da solução.
São componentes do cluster de Recursos: máquinas virtuais criadas pelos usuários, NSX Edges criados pelo vCloud Director e NSX Controller Cluster (NSX Manager recursos).
A ferramenta vRA permite a criação e publicação de blueprints altamente complexos. Como todos os blueprints publicados e os componentes são reutilizáveis, você pode criar uma biblioteca desses componentes e combiná-los em novos blueprints para oferecer serviços sob demanda cada vez mais complexos.
Os blueprints publicados tornam-se itens de catálogo que os administradores de catálogo de serviços podem fornecer aos usuários. O catálogo de serviços fornece um portal unificado de autoatendimento para o consumo de serviços de TI. Os administradores de catálogo de serviços podem gerenciar o acesso dos usuários aos serviços de catálogo, itens e ações usando direitos e aprovações, e os usuários podem navegar pelo catálogo para solicitar itens necessários, acompanhar as solicitações e gerenciar os itens provisionados.
3.3 FERRAMENTAS COMPLEMENTARES
Para que o processo de virtualização tenha amplo acesso, a Empresa aplicou e integrou o conceito DevOps. Este conceito necessita de um conjunto de ferramentas para sua materialização. Foi verificado que um único fornecedor seria incapaz de fornecer todas as soluções necessárias. Desta forma, além das soluções proprietárias, foi utilizado um conjunto de ferramentas open source que integram a stack tecnológica utilizada.
A implantação de metodologia e esteira ágil demanda a necessidade de um conjunto de softwares integrados para sua viabilização, isso tendo em vista a impossibilidade de atendimento de todo o ciclo produtivo por um único fornecedor ou solução tecnológica. Levando-se em consideração esses aspectos, o primeiro importante desafio apresentado consistiu exatamente em verificar as ferramentas disponíveis de conhecimento da empresa para, a partir daí, identificar as lacunas tecnológicas a fim de complementá-las com soluções robustas e eficientes disponíveis no mercado. Neste compasso, observamos o ecossistema de conhecimento e padronização já adotado na empresa, aqui representado pela figura 10.
Figura 10 – Ecossistema de conexão e devops
Diante de tal cenário, a tabela 5 representa os conceitos e ferramentas a serem buscados e integrados para as fases seguintes da implantação do projeto de virtualização, buscando pelo DevOps e consequente TI Bimodal.
Tabela 5 – Produtos integrados ao projeto de virtualização
| Descrição das ferramentas | |
| Foreman | O Foreman é uma ferramenta para gerenciamento de ciclo de vida de servidores físicos e virtuais. Ele permite instalar máquinas virtuais em Clouds integradas, como AWS, Azure, Google, IBM, tudo integrado com a gestão de configuração como Puppet, Ansible, Salt e Chef, suportando também o contêiner Docker. |
| Puppet | O Puppet é uma ferramenta Open source para gerenciamento de configuração. É uma ferramenta declarativa para configurar sistemas operacionais e tem suporte ao Linux, Solaris, Windows dentre outros. A atenção necessária é que a premissa de configuração seja centralizada em um único ponto e estas configurações sejam distribuídas para diversos nós de uma rede. |
| Jenkins | O Jenkins é uma ferramenta de integração contínua que faz a gestão de todo o pipeline. É um servidor de automação baseado em código aberto em Java que ajuda a automatizar a parte não humana do processo de desenvolvimento de software, com integração contínua e facilitando os aspectos técnicos da entrega contínua. |
| GIT | Git é um projeto Open Source, mantido ativamente e originalmente desenvolvido em 2005 por Linus Torvalds. É um sistema de controle de versões distribuídas, usado principalmente no desenvolvimento de software para registrar o histórico de edições de qualquer tipo de deploy e arquivo. |
| Red Hat Satellite | É uma solução de gerenciamento de sistemas de fácil utilização que ajuda a manter ambientes Red Hat Enterprise Linux e outras infraestruturas do fabricante funcionando de forma segura, eficiente e em conformidade com os padrões adotados. |
| IBM UrbanCode Deploy | O IBM® UrbanCode Deploy é uma ferramenta de automatização e liberação de Deploy em diversos ambientes tecnológicos. Fornece visibilidade completa em implementações de camadas de forma visual e simplificada. |
| IBM Urbancode Blueprint Design | IBM UrbanCode BluePrint Design acelera o teste e a implantação de aplicativos, provisionando ambientes de nuvem e implantando componentes de aplicativos nesses ambientes. Cada blueprint modela um ambiente de a full-stack environment, incluindo camada de infraestrutura e camada de aplicativo. |
Fonte: Autor
CONCLUSÃO
Grandes corporações buscam desenvolver o conceito e aplicação em Cloud. Em suas dúvidas surgem a utilização de plataformas públicas, privadas ou conceito híbrido. O tema abordado para este estudo desenvolve a linha de raciocínio da TI Bimodal, aplicando uma nova forma de operação e desenvolvimento, de modo a manter os ambientes e sistemas legados para um roadmap de atualização de plataforma. A implantação da solução tecnológica é sem dúvida uma etapa vital do projeto, contudo, ela não tem o fim em si mesma. Além da tecnologia, há a necessidade de uma profunda revisão de todos os processos que dão sustentação a esteira DevOps, outrossim, existe também a necessidade de uma revisão de responsabilidades frente ao Modo 1 e Modo 2, pois, durante algum tempo a empresa irá conviver com estes dois modelos.
A implantação deste projeto reposicionou a Empresa em relação ao ineditismo na adoção de tecnologias vanguardistas proporcionando a adoção de novos modelos de negócios e de operações dos Data Centers.
Baseado na oferta inicial de IaaS, a empresa desenvolveu um conjunto de componentes integrados como: portal de marketplace, integração de informações através de barramentos e especialmente, entregou plataforma completa automatizada para a produção de Blockchain as a Service (BCaaS). Todas estas ações, redefiniram o caráter inovador em ambiente de governo tornando assim o reposicionamento estratégico factível, impulsionando o grau de maturidade de Cloud.
O governo brasileiro possui uma nuvem própria com a credibilidade, consistência e governança necessária para colaborar no grau de maturidade de uso de cloud em todas as instâncias da administração pública federal, repensando assim o lobby dos fabricantes que interessam apenas a eles mesmos.
Observamos que, conforme a distinção dos sistemas legados (monolíticos), a plataforma de virtualização é o primeiro passo para a composição de uma nova arquitetura de sistemas e entregas ao usuário final. Ao adentrar no conceito desta primeira etapa, diversas oportunidades e riscos surgem com a tomada de decisão, sendo elas principalmente a mudança de cultura da TI tradicional para a TI baseada em Cloud. Diversos conceitos foram abordados pela Empresa de Tecnologia observada, sendo que, a cultura do crescimento, o trabalhar com metas, resiliência e mindset ágil estão intrinsecamente interligados a aplicação da tecnologia ora analisada.
É importante salientar que projetos derivados da implantação de um processo de automação devem estar no plano de ação dos anos subsequentes, como por exemplo, análise e centro de custos, desenvolvimento jurídico (uma vez da criação da Lei Geral de Proteção de Dados – LGPD), segurança operacional, segurança de dados, marketing, desenvolvimento e capacitação, bem como evolução das plataformas tecnológicas para que o parque não volte a ficar defasado e dependente de sistemas legados, gerando falhas e vazamento de dados por não atualização tecnológica.
Para trabalhos futuros, diversas iniciativas ficam pendentes, como a integração das ferramentas, o mapa de governança definido com ciclo de vida de aplicações e seus graus de maturidade, os centros de custos operacionais, bem como a gestão de custos para modelagem de negócios e as análises qualitativas e de experiência de usuário para aprimoramento das novas plataformas em seu novo modelo adotado para Cloud. A abrangência do trabalho também pode se desenvolver na área de atuação de gestão de pessoas, uma vez que a proposição é por mudança de cultura, mindset e orientações técnicas.
REFERÊNCIAS
BERRY D.; MOK L.; COLEMAN M. Hit the bimodal it highway now – considerations for structuring and staffing. 2015. [Online]. Disponível em: www.gartner.com. [Acesso em 12 2020].
BERRY D.; MOK L. e COLEMAN M. Hit the bimodal it highway now – considerations for structuring and staffing. Stanford, 2015.
BEZERRA J. D. S. Uma Revisão do Estado da Arte Sobre os Desafios e Efeitos do Uso de Software Defined Data Center (SDDC). Recife: UFPE, 2016.
BRASIL. Governo Federal. Diário Oficial da União, 2019. [Online]. Disponível em: https://www.in.gov.br/materia/-/asset_publisher/Kujrw0TZC2Mb/content/id/70267659/do1-2019-04-05-instrucao-normativa-n-1-de-4-de-abril-de-2019-70267535. [Acesso em 12 2020].
BRASIL. Governo Federal. Diário Oficial da União, 2020. [Online]. Disponível em: https://www.in.gov.br/web/dou/-/aviso-de-licitacao-291949490. [Acesso em 12 2020].
BRASIL. Presidência da República. 03/2018. [Online]. Disponível em: https://datasus.saude.gov.br/wp-content/uploads/2019/08/Norma-Complementar-nº-14IN01DSICGSIPR.pdf. [Acesso em 11 2020].
CABRAL J. Melhorando Agilidade e Colaboração com Contêineres. Rio de Janeiro, 2018.
DUVALL P. Agile DevOps: Infrastructure Design. 11/07/2012. [Online]. Disponível em: https://www.ibm.com/developerworks/library/a-devops2/. [Acesso em Novembro 2020].
ERL T.; MAHMOOD Z. e PUTTINI R. Cloud Computing – Conceitos, Technology & Architecture. Massachusets: Prentice Hall, 2013.
HAFKE I.; KALGOVAS B. e BENLIAN A. The transformative role of bimodal IT in an era of digital business. Hawaii International Conference on System Sciences, 2017. [Online]. Disponível em: http:// scholarspace.manoa.hawaii.edu/handle/10125/41822. [Acesso em 11 2020].
Inc V. 03/2017. [Online]. Disponível em: www.vmware.com. [Acesso em 11 2020].
MAHAPATRA, B. Synchronize bimodal IT and cost optimization for the best outcomes. 2015. [Online]. Disponível em: www.gartner.com. [Acesso em 11 2020].
MESAGLIO M.; MINGAY S. e WELDON L. 2015. [Online]. Disponível em: www.gartner.com. [Acesso em 11 2020].
NEVES J. L. Pesquisa qualitativa: características, usos e possibilidades. 1996. [Online]. Disponível em: http://ucbweb.castelobranco.br/webcaf/arquivos/15482/2195/artigo_sobre_pesquisa _qualitativa.pdf. [Acesso em 12 2020].
RAJIV P. Organizing a Digital Technology Department of Medium Size in a Media Company. 2009.
ROLD C.; JIVAN R. A practical guide to bimodal adaptive sourcing research. Gartner IT, 2015. [Online]. Disponível em: www.gartner.com. [Acesso em 11 2020].
SLATTERY T. 25 de agosto de 2010. [Online]. Disponível em: https://www.netcraftsmen.com/top-7-reasons-for-network-automation/. [Acesso em novembro de 2020].
SERVICES V. A. A. Delivering on the Promise of the Software-Defined Data Center. 2012. [Online]. Disponível em: https://www.vmware.com/files/pdf/accelerate/VMW_13Q1_BB_SDDC_020813_FINAL_LTR. pdf. [Acesso em 11 2020].
VIEIRA D. de V. Framework de práticas de gestão de TI para TI bimodal em uma instituição financeira cooperativa. Porto Alegre: Universidade Federal do Rio Grande do Sul, 2018, p. 119.
YIN R. K. Estudo de Caso: Planejamento e Métodos. Porto Alegre, 2005.
[1] Engenheiro de Computação.
[2] Orientador. Doutorado em Processamento de Sinais e Telecomunicações.
[3] Co-orientador. Doutorado em Engenharia Elétrica.
Enviado: Fevereiro, 2021.
Aprovado: Fevereiro, 2021.
