OpenShift e o Desafio dos Containers

Apresentando o Container

O primeiro ponto que precisamos entender é o tema Container. Podemos dizer que um Container é um isolamento de aplicações dentro de um sistema operacional, onde é possível individualizar diversas aplicações em uma mesma infraestrutura física compartilhando acesso internet, disco, processamento e memória. Ao usarmos Container conseguimos prover limites de isolamento para cada aplicação, ampliando não só a segurança do ambiente, mas também o desempenho das aplicações. Entretanto, você pode questionar: Denis, mas isto é o conceito de virtualização como eu já conheço! A resposta é um grande e sonoro “não”. Vamos aprofundar o tema para deixar mais claro, pois existem diferenças muito importantes para o nosso estudo.

Primeiro precisamos entender os motivos que estão fazendo com que o uso de Containers seja cada vez mais popular. Tenha em mente que quando fazemos uso da virtualização tradicional usamos um software chamado virtualizador (hypervisor), que é responsável pelo compartilhamento do hardware físico (memória, disco, processador, placa de rede, porta USB, etc) entre diversos sistemas operacionais (Guest OS/Máquina Virtual). Cada sistema operacional pode ser distinto (Windows, Linux, FreeBSD, etc), necessitando apenas manter a compatibilidade com a plataforma física selecionada que suporta este ambiente computacional.

Para compreender mais profundamente, considere o uso de uma máquina virtual, onde colocamos diversas aplicações. Imagine o que pode acontecer se uma aplicação for invadida, por exemplo? Neste cenário, todo o ambiente pode ser comprometido ou ainda o que aconteceria se uma aplicação apresentar um problema de desenvolvimento e consumir grande parte da memória deste servidor? Possivelmente teremos todas as outras aplicações prejudicadas.

Pensando ainda na maneira tradicional, como solucionaríamos este problema? Basta criar um ambiente com servidores redundantes contendo o mesmo virtualizador e configurar nele várias máquinas virtuais (VMs) separando as aplicações. Claro que o impacto negativo deste modelo é guiado principalmente pelo custo, principalmente se desenvolvermos um projeto onde o uso de sistemas operacionais exige licenciamento. Para materializar o que foi dito até o momento, observe o gráfico seguinte:

tabela

 

Note como é diferente o desenho de aplicações inseridas em VMs e aplicações projetadas para ambientes com Containers.  Se continuarmos a olhar para o tema “custo”, perceberemos que licenciamos apenas um sistema operacional e configuramos diversas aplicações individualizadas em quantos Containers forem necessários ou suportados pelo hardware usado. Vamos ampliar os horizontes este conceito para o ambiente de Cloud Pública ou Cloud Privada. Ao fazermos isto, perceberemos que é cada vez mais natural o uso de duas tecnologias importantes: Docker (https://www.docker.com/) e Kubernetes (http://kubernetes.io/).  Vamos estudá-los um pouco e identificar quais benefícios podemos encontrar neles.

 

Entendendo Docker, Kubernetes e OpenShift

Ponto 1: Docker é uma plataforma onde um Container é tratado como uma “imagem” contendo todos os elementos para o funcionamento de uma aplicação. Assim a ideia de compartilhar e colaborar muito usada por uma equipe de desenvolvedores é facilmente mantida.

Ponto 2: Docker consegue controlar atualizações, mapear as mudanças ou controlar de maneira automática todo o ciclo de vida de uma aplicação contida em uma imagem. Neste cenário não existe a preocupação em depositar uma aplicação em um ambiente de homologação e sofrer com problemas de funcionamento ao migrar para o ambiente de produção. O segredo é que tudo que é necessário para a aplicação funcionar está dentro do Container.

Ponto 3: E o que podemos falar a respeito do Kubernetes? É importante termos em mente que é inviável controlar manualmente o ciclo de vida de uma quantidade elevada de Containers devido a diversos fatores, dentre eles podemos citar a ordem com que eles são iniciados, por exemplo. É neste tema que entra o Kubernetes. O Google faz uso dele há mais de 15 anos para controlar as cargas de trabalhos (workloads) existentes em seus Data Centers. Desta forma podemos encontrar nele elementos como:

  • Controle da saúde de cada aplicação durante o processo de deploy, facilitando a identificação de problemas, possibilitando a reinicialização do Container que falhar, substituindo ou até reagendando um Container quando uma máquina virtual falhar;
  • Presença de Load Balance (Balanceador de Carga) para controlar o fluxo de acesso a aplicação duplicada;
  • Crescimento ou demolição automática da quantidade de réplicas de uma aplicação. Isto é feito com o controle da quantidade de Containers seguindo as regras previamente estabelecidas ou interagindo diretamente via linha de comando.
  • Crescimento horizontal da aplicação usando Containers;
  • Execução de tarefas usando arquivos em lotes para otimizar e automatizar atividades de maneira sequencial que normalmente seriam feitas por técnicos ou programadores (Batch).

Imagine se uníssemos em uma única plataforma todas as funcionalidades e benefícios do Docker com o Kubernetes. Claro que seria algo fantástico, mas será que realmente é possível? Tenho uma ótima notícia para você, esta pergunta já foi respondida com um grande “sim” pela Red Hat com a criação do OpenShift em 2013. O OpenShift posiciona-se como um PaaS (Plataforma como Serviço/Platform as a Service) permitindo simplificar o desenvolvimento, acrescentando ganho de escala nas aplicações em diversos tipos de ambientes e deixando mais simples o armazenamento de aplicações.

Para o UOLDIVEO introduzir o OpenShift em nossas atividades foi um caminho natural trilhado pela parceria de longa data com a Red Hat. Nossa experiência nos possibilita entender a necessidade de dinamismo em um mundo que segue com força para a transformação digital e nos capacita a desenvolver diversos modelos de projetos envolvendo OpenShift.

Esta parceria proporciona ganhos para os nossos clientes, pois permite um acesso direto ao suporte especializado e diferenciado, juntamente com treinamentos e certificações para nossa equipe, garantindo acesso às novidades e lançamentos da Red Hat com bastante antecedência.

 

* Denis Augusto A. de Souza, Analista de Produtos do UOLDIVEO. Autor da série de livros Tempestade Hacker, publicada pela Amazon.com.br.

 

Links indicados:

 

Arquitetura em Micro serviços uma nova abordagem para aplicações.

Com a evolução rápida da tecnologia e a transformação digital, as áreas de negócio passaram a exigir maior velocidade na área de TI. A lógica das aplicações determinadas pela abordagem das “3” camadas “back-end”, “negócios” e a interface de “front-end” está passando por uma nova revisão. Essa revisão que chamo de nova abordagem são que as aplicações construídas pelos desenvolvedores estão sendo construídas e distribuídas para a nuvem, impulsionado pela direção do negócio.

A abordagem atual dos negócios são:

 

  • Aplicação deve ser construída e operar em serviços de escala, a fim de atingir a todos em todos os lugares que requisitado pelo negócio.
  • Recursos devem ser capazes de responder às demandas, assim como, a capacidade deve suportar as solicitações de muito clientes. J
  • Utilização de recursos de forma a produzir reduções de custos devido a inteligência da aplicação.

 

A realidade dos negócios apresenta aos desenvolvedores a adotar um modelo de arquitetura chamada de “Micro serviços” termo popularizado James Lewis e Martin Fowler (http://martinfowler.com/articles/microservices.html)

Para entendermos a nova abordagem é necessário compreender a evolução da TI pela ótica do desenvolvimento de aplicações. Você já deve ter ouvido de muitas empresas que para crescer basta inserir mais hardware para aplicação suportar, e isso foi por muitas décadas a realidade da gestão de TI nas empresas, pois a  aplicação neste momento seria orientada pelo back-end devido a ineficiência e limitação da infraestrutura que criava uma forte dependência (acoplamento) entre os serviços de aplicação, isto é, componentes não relacionados dentro das camadas. Por anos essa abordagem que chamamos de “aplicação monolítica” conseguia entregar de forma ágil a entrega de hardware a velocidade que o negócio requisitava, mesmo hoje, ainda existam aplicações com essa abordagem e não devem ser descartas devido aos requisitos de negócio.

Com a evolução da TI para o cloud computing e com isso os requisitos de agilidade, confiabilidade e escala do negócio promoveu ao desenvolvimento  de aplicações o rompimento das limitações de hardware no passado. O micro serviço é um conjunto finito de requisito funcionais que determinado pela arquitetura possa trazer independência, agilidade e funcionalidades que ora separadas possam unificar e implementar uma única função. Ao contrário da aplicação monolítica, que promovem abundância de recursos de infraestrutura, as aplicações em micro serviços promove inteligência ao sabiamente realocar recursos e serviços para as determinadas tarefas cotidianas do negócio.

Enfim, com a mudança do modelo monolítico para o micro serviços muda bastante a velocidade no nosso modo de pensar. Agora podemos ter equipes especializadas naquele conjunto de funcionalidades de negócio, que passarão a tratar o serviço não como um mero componente, mas sim um produto, com ciclo de vida independente, escalável e mais próximo do negócio.

 

Abs.

Luiz Eduardo.

Garanta suas datas – Parte 2

Olá pessoal,

Estou dando sequência ao artigo ‘Garanta suas Datas – Parte 1’ publicado no dia 14 de setembro, caso você não tenha lido a primeira parte clique aqui, pois poderá ter dificuldades de entender a lógica do estudo de caso.

 

O DESAFIO ESTÁ LANÇADO

Um bom desafio é o que me motiva a investir na carreira de gestão. Sou partidário do conceito defendido por Henry Mintzberg no livro ‘MBA? Não, Obrigado’, onde ele expõe que o gestor não se forma dentro da sala de aula, mas sim na prática.

Obvio que defendo a busca de conhecimento, seja qual for o caminho que você escolher. Eu mesmo investi em um MBA de Gestão Empresarial e tirei grande proveito dele. Mas é a prática que lhe permitirá montar o quebra cabeça; escolher dentre os diversos conhecimentos que você acumulou ao longo de sua carreira quais irá utilizar para arquitetar a solução.

O desafio apresentado neste estudo de caso estava em pulverizar a implantação de um determinado projeto dentro do time de Implantação. Centralizar o projeto a um único analista gera um ponto de risco muito alto e compromete o cronograma alinhado com os stakeholders do projeto.

O caminho que escolhemos para arquitetar a solução foi trabalhar com metodologias ágeis. Neste conceito ‘quebramos’ o projeto (épico) em várias etapas (histórias) e através do processo de Kanban o time terá condições de absorver a implantação de forma compartilhada.

Acompanhe os passos que adotamos para alcançar este objetivo.

CONHEÇA O FLUXO DE IMPLANTAÇÃO

O primeiro passo para alcançar o objetivo estabelecido foi mapear e entender o fluxo de implantação. Não existe muito segredo, você deve reunir o time e repassar passo a passo todas as atividades que podem ser realizadas durante a implantação de um projeto.

Mapeie inclusive aquelas atividades que não são realizadas em todas as implantações, mas que devem ser avaliadas durante seu planejamento.

Não espere acertar de primeira, quando o processo está apenas na cabeça das pessoas é natural que não se tenha um caminho muito bem definido a ser seguido. Todos sabem o que deve ser entregue, mas não necessariamente irão seguir o mesmo caminho para alcançar seus objetivos.

Este é motivo de termos impacto ao ‘perdermos’ o owner de uma implantação no meio do processo. Como cada pessoa define seu caminho para chegar no objetivo final, a passagem e bastão não é tão clara e simples como deveria.

Mapeie o fluxo inicial e acompanhe de perto as próximas implantações. Garanta que o fluxo estabelecido esteja sendo seguido e quando identificado melhorias, faça as correções necessárias.

 

DICAS PARA MAPEAR O FLUXO

Para que vocês não tenham que cometer os mesmos erros que eu cometi ao realizar este trabalho, seguem algumas dicas para direcioná-los nesta atividade.

  1. Dependências: mapeie as dependências entre cada etapa do fluxo. Busque eliminar dependências desnecessárias ou em duplicidade.
  2. Owner: provavelmente o responsável por ‘pilotar’ a implantação é o analista do seu time, mas existem grandes chances de ter etapas dependentes de times terceiros. Mapeie o dono de cada etapa (exemplo: liberar ACL – Time de Segurança; criar Multicast – Time de Redes).
  3. Kanban: tenha em mente que a princípio cada etapa mapeada no fluxo será uma história criada no board do seu Kanban (irei detalhar mais à frente).
  4. Detalhamento: você deve achar a medida certa ao detalhar o seu fluxo. Criar etapas muito macros não lhe dará as informações necessárias para realizar a gestão do fluxo, mas detalhar demais irá dificultar o controle posteriormente.

Exemplo: criar uma etapa genérica ‘ACL’ não irá lhe permitir bater o olho e saber o que já foi realizado e o que está pendente, mas detalhar ao ponto de ‘Solicitar ACL Backup’, ‘Liberar ACL Backup’ e ‘Validar ACL Backup’ pode gerar dificuldades para seu time manter o Kanban atualizado. Um meio termo, como: ‘ACL Backup’, ‘ACL Host’, ‘ACL Puppet’, foi a melhor medida que encontrei para detalhar o fluxo.

  1. Atualizações: não tenha receio de ajustar o fluxo inicial após auditá-lo na prática.
  2. Cultura: se os quesitos de qualidade da companhia estão sendo atendidos, evite mudar o fluxo que já está sendo seguido pelo time. Quanto menor a mudança aplicada nesta etapa, mais rápido serão colhidos os benefícios deste trabalho. Ao longo do tempo melhorias poderão ser adicionadas ao processo.
  3. Ferramenta: documente o fluxo mapeado e mantenha um controle de versão para cada alteração aplicada. Sugiro a utilização da ferramenta GRAPHVIZ. É gratuita e de fácil entendimento.

Caso você queira aprofundar o estudo neste assunto sugiro a leitura da coleção sobre Lean Six Sigma da Cristina Werkema, editora Campus.

 

RESULTADO ESPERADO

O resultado esperado do mapeamento do fluxo de implantação para ambientes que não estão na nuvem deve ser algo parecido com o fluxo apresentado na figura abaixo. Uma dica bacana é destacar as atividades cuja responsabilidade de execução for do time de Implantação, das atividades cuja a responsabilidade de execução for de times terceiros.

  • Exemplo de fluxo de Implantação

fd

Outra visão interessante é numerar cada etapa do fluxo e distribuí-las entre os times envolvidos

  • Etapas vs Equipes

dsf

Conhecer o fluxo de implantação é a base para pensarmos em metodologias ágeis.

MÉTODOS ÁGEIS

Após mapear o fluxo de implantação e conhecer todas as etapas envolvidas na implantação de projetos corporativos, temos a oportunidade de estruturar o time para consumir as novas demandas dentro do fluxo do Kanban.

Irei abordar a estratégia utilizada e os benefícios colhidos por ela, mas não entrarei no detalhe do conceito de Kanban. O trabalho realizado foi baseado nos livros KANBAN de David J. Anderson – Editora Blue Hole Press e Real-World Kanban de Mattias Skarin – Editora Pragmatic Bookshelf. Indico como leitura essencial caso queira aprofundar seus conhecimentos no tema.

O objetivo principal de utilizar o Kanban é pulverizar a Implantação em etapas a serem consumidas pelo time. Ao invés do analista ser owner do projeto, ele passará a ser owner da etapa, com isto teremos vários analistas trabalhando de forma coordenada no mesmo projeto

  • Atividades do projeto distribuías entre vários analistas do time

fdg

Esta forma de trabalho mitiga muito o risco de impacto caso um dos analistas desfalque o time, pois é muito fácil absorver e dar continuidade à etapa que ficou ‘órfão’.

No meu próximo post, vou apresentar algumas regras que utilizei para tornar esta teoria em realidade.

Abraços e até breve,

Rodrigo Muniz

O que você precisa saber antes de desenvolver aplicações para a nuvem

Vivemos em uma sociedade hiperconectada, com smartphones, tables e outros dispositivos móveis fazendo parte de nosso dia a dia. A velocidade das transformações é aluciante e aumenta a cada dia. 🙂

Os antigos processos de desenvolvimento e gestão do ciclo de vida das aplicações foram baseados no conceito que o sistema era desenhado para ser praticamente estático na TI tradicional. As modificações, sejam por incremento de novas funcionalidade ou aspectos pertinentes a demanda do negócio, eram acumuladas e embutidas em nova versões do software, em ciclos de no mínimo um ano entre estas mudanças.

O mercado demanda mudanças urgentes e para vencer é necessário proporcionar uma boa experiência de uso aos usuários. A busca por melhores experiências deve ser contínua. As evoluções fazem com que o ciclo de vida das aplicações passem de longos períodos de requerimentos e desenvolvimento, para um modelo em contínuo “estado beta”, ou seja, em evolução constante, em intervalos cada vez mais curtos.

Atualizações não são mais anuais, mas sim mensais, semanais ou mesmo diárias!

É exatamente por causa dessa mudança de paradigma, onde características das aplicações tradicionais se distinguem das características da nova geração de aplicações que a implantação de aplicativos em um ambiente de nuvem pode ser muito diferente de implantá-los em um ambiente de TI tradicional.

É esperado que a nova geração de aplicativos em nuvem tenham a capacidade de adicionar e reduzir a elasticidade sem impactar a performance da infraestrutura.

Os aplicativos considerados cloud native utilizam:

  1. Recursos via API (Application Programming Interface)
  2. CLI (Command-line Interface)
  3. SDK (Software Developement Kit)

Tudo isso permite que os processos de desenvolvimento e operação do aplicativo funcionem de forma integrada, permitindo que o desenvolvedor atue inclusive como um DevOps.

O DevOps representa uma ruptura na cultura tradicional de desenvolvimento e gestão do ciclo de vida das aplicações. Ao utilizar os conceitos já consagrados de “agile development” e adiciona também as práticas de “lean startup”. E ao oferecer um conjunto de ferramentas aos desenvolvedores como as APIs, CLI e SDK possibilita a utilização de nuvens sem lock-in como o OpenStack – o maior orquestrador de nuvens em opensource para IaaS.

Com a nuvem OpenStack, por exemplo, os desenvolvedores possuem diversas possibilidades de criação dos seus aplicativos, podendo escolher diversas linguagens de programação tanto via SDK ou APIs.

A nova geração das aplicações permite a consolidação da nova TI. De modelos monolíticos, altamente integrados e fechados em si mesmo, para um modelo de serviços, com pontos de contato com o mundo exterior através de um ecossistema de APIs. Na prática, nenhuma aplicação é uma ilha isolada. Ela deve proporcionar experiências positivas para seus usuários.

As empresas responsáveis por produzir software estão cada vez mais alinhadas com o movimento DevOps.