Maturidade DevOps – Infraestrutura como Código

Conversando com uma pessoa que trabalha em uma grande empresa pública há alguns meses, ouvi o seguinte relato.

“Meu time precisava de um ambiente para a homologação do nosso produto, que já estava com um atraso considerável. Entretanto, ouvi da nossa infraestrutura que a requisição do ambiente de homologação demoraria algumas semanas. A partir deste momento, toda uma cadeia de estresses se estabeleceu de lado a lado, com pressões diversas de pessoas do desenvolvimento e respostas áridas do time de operações. E no final das contas, o nosso time precisou esperar 3 semanas para ter um ambiente liberado. E isso somente tornou o nosso projeto, que já estava ruim, em um pesadelo vivo”, – Gestor Irritado com a sua infraestrutura do século XX

Por mais estranha que esta história pareça, ela é ainda comum nas empresas que visito e nas empresas de meus colegas de TI. E, sim, algo está errado com isso. Com os avanços das últimas duas décadas nas tecnologias de virtualização e conteinerização, a engenharia de automação de infraestrutura pode emergir como uma disciplina.

Infraestrutura Programável

A Infraestrutura como código, ou infraestrutura programável, significa escrever código (que pode ser feito usando um linguagem de alto nível ou qualquer linguagem descritiva) para gerenciar configurações e automatizar o provisionamento da infraestrutura e implantações. Isso não é simplesmente escrever um scripts que sobe e roda uma máquina virtual, mas envolve também o uso de práticas de desenvolvimento de software testadas e comprovadas que já estão sendo usadas no desenvolvimento de aplicativos. Em suma, isso significa que você escreve código para provisionar e gerenciar seu servidor, além de automatizar processos que rodam neste servidor.

Observe o seguinte código abaixo, que pode ser executado no Windows, Linux ou Mac OS/X com uma ferramenta de provisionamento chamada Ansible.

- hosts: server
  sudo: yes
  sudo_user: root

  tasks:

  - name: Instala mysql-server
    apt: name=mysql-server state=present update_cache=yes

  - name: Instala dependencias
    apt: name=python-mysqldb state=present

  - name: Verifica se o mysql está rodando 
    service: name=mysql state=started

  - name: Criar usuario com os privilegios apropriados
    mysql_user: login_user=root login_password="" name={{ mysql_user }} password={{ mysql_password }} priv=*.*:ALL host=% state=present

  - name: Create base de dados AloMundo
    mysql_db: name=alo_mundo state=present

  - name: Copia o dump do SQL para a máquina remota
    copy: src=dumpAloMundo.sql.bz2 dest=/tmp

  - name: Restaura o dump no banco de dados AloMundo
    mysql_db: name=alo_mundo state=import target=/tmp/dump.sql.bz2

Este script (chamado de PlayBook no Ansible) instala o mysql-server na máquina remota (servidor), garante que o mysql está em execução, cria um usuário com a senha, cria o banco de dados alo_mundo, copia um dump sql para a máquina remota e o restaura no banco de dados destino.

Considere agora este exemplo, com o uso da ferramenta Docker.

  
docker pull microsoft/mssql-server-2016-express-window
docker run -d -p 1433:1433 
        -- env sa_password=senha 
        -- isolation=hyperv microsoft/mssql-server-2016-express-windows

Este script baixa um contêiner Docker de um ambiente remoto com um Windows e Microsoft SQL Server e o roda na porta 1433. E este contêiner pode ser rodado em um sistema operacional nativo diferente.

Observe que nos scripts acima você pode eliminar muito trabalho manual e permitir que o provisionamento de ambientes, instalação de softwares, configurações destes software e disparo de servidores seja todo automatizado em scripts.

Nos ambientes mais sistematizados e que requerem práticas ITIL podemos manter toda a governança necessária para o controle da infraestrutura. Ao mesmo tempo, eliminaremos o tedioso e lento trabalho manual que gera filas, atrasos e estresses para os times de TI.

Com esta definição em mãos, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de configuração e uso de scripts de provisionamento de ambientes. Todo o trabalho de preparação de ambientes é realizado diretamente sobre hardwares reais e isso é sempre repetido para cada nova requisição realizada para o time de infraestrutura. Nesta maturidade, os tempos de atendimento são longos e existe estresse frequente entre o time de desenvolvimento e o time de operações.
  2. Maturidade 2 – Consciente –  Aqui a cultura de virtualização começa a ser experimentada. Os times de operações adotam tecnologias como o Oracle VirtualBox, VMWare, Windows Hypervisor e similares para facilitar o trabalho de criação e configuração das máquinas. Alguns trabalhos são operacionalizados com scripts, mas o trabalho manual é ainda dominante e ainda gera tempos altos de atendimento das requisições.
  3. Maturidade 3 – Gerenciado – Aqui entram em cena ferramentas como Docker, Ansible e Puppet para tornar o trabalho de provisionamento, instalação e configuração de ambientes totalmente automatizados. Os scripts de provisionamento começam a ser escritos e organizados em repositórios de código. Com isso o atendimento de requisições de criação de ambientes é facilitado com tempos de atendimento reduzidos.
  4. Maturidade 4 – Avançado – Neste nível, os scripts são governados e podem ser distribuídos para os times de desenvolvimento para estabelecer ambientes self-service. Temos também o provisionamento dos ambientes de produção (Release Management) completamente controlados por máquinas e com mínima interferência humana. Para isso, são estabelecidos ambientes de nuvens privadas ou públicas para facilitar a implementação de políticas de escalabilidade e alocação de recursos em modelos de pagamento pelo uso. O efeito na redução do trabalho manual nos times de operações é notável.
  5. Maturidade 5 – Melhoria Contínua – Neste nível praticamente todo o trabalho de infraestrutura é gerido por código fonte e ferramentas de provisionamento. Máquinas virtuais, bancos de dados, servidores de aplicação, servidores Web e até mesmo redes (SDN) são configuradas por código fonte. O “hardware” se torna software.

 

Recursos de Aprendizado

Para quem nunca teve contato com a prática da InfraEstrutura como Código, isto pode parecer ficção. Felizmente, esta prática já é realidade em muitas empresas do Brasil. E ela pode ser operacionalizada por ferramentas gratuitas também, na sua empresa inclusive.

Deixo aqui alguns livros a respeito para o interessado em melhorar a gestão da sua infraestrutura e trazê-la para o século XXI. O primeiro explica a prática do IaC em detalhes os três outros livros apresenta ferramentas muito legais para operacionalizar esta prática.

51kktpbssjl    51otkrbt71l-_sx356_bo1204203200_

51piynh5ppl    51mweljjc4l


E como está a prática da infraestrutura na sua empresa? Já no século XXI ou ainda preso em algum túnel do tempo no século XX?

Se você não leu os dois primeiros artigos desta séria de Maturidade DevOps, deixo aqui os links:

Parte 1 – Maturidade DevOps – Qualidade de Código
Parte 2 – Maturidade DevOps – Gestão de Builds e Integração Contínua

 

A evolução do BPM, o iBPM

A Target é uma gigante americana que trabalha no mercado varejista e que desenvolveu nos últimos anos um sofisticado sistema de análise preditiva que lhe permite avaliar, com boa precisão, as preferências de compra de cada consumidor individualmente. Este modelo é resumido no esquema abaixo.

Este modelo demonstra o conceito de Intelligent Business Operations e mostra como empresas podem obter vantagem competitiva com o uso de tecnologia da informação.
Modelo de análise preditiva de compras da Target, para permitir o envio de propagandas mais assertivas e melhorar a probabilidade de compras de novos produtos e portanto aumento do seu faturamento financeiro.

Baseado neste modelo, esta empresa conseguiu até mesmo detectar grávidas no segundo trimestre da gravidez, o que lhe promoveu vantagem competitiva e fidelização das novas mamães e papais. Para referência, antes da Target as empresas somente conseguiam detectar automaticamente as novas mães no terceiro trimestre da gravidez. Este caso foi até citado na revista Veja na edição que fala sobre BigData e representa o que Gartner Group chama de IBO (Intelligent Business Operations). O IBO é o processo de melhoria das operações de uma empresa, que se tornam mais inteligentes e responsivas através da integração de BPM, análise preditiva, tecnologias sociais e móveis. As organizações que já entenderam o potencial do IBO estão avançando e ocupando espaços de outras organizações mais lentas e reativas.

Para que uma empresa implemente um IBO, ela precisa possui uma plataforma de automação de TI apropriada. Esta plataforma é o iBPM, ou o intelligent Business Process Management.

Um BPM tradicional, mesmo que muito robusto, pode ser visto como a coleção das seguintes peças:

  • Modelador de processos, com suporte a linguagem como BPMN.
  • Simulador de processos, para análise futura de melhorias de processo.
  • Orquestrador de processos, que é um ambiente de execução que permite que um processo BPM seja executado e enlace serviços de TI.
  • IDE para modelagem e orquestração de processos, que é o ambiente de desenvolvimento do analista de BPM
  • Monitor de processos (BAM), que avalia em tempo real as métricas e indicadores de um processo de negócio.
  • Repositório de processos, que permite manter as versões de processo e governar os ativos de processos de uma organização.

Um iBPM vai muito além. Ele inclui também:

  • Suporte à mídia social para incorporar fontes de dados  externas e perspectivas externas (como especialistas e as vozes dos clientes) e dados de contexto em todo o ciclo de vida de um processo. A mídia social pode melhorar e fornecer mais informações sobre o contexto situacional. A mídia social também apoiará técnicas analíticas adicionais, tais como análise de rede social para apoiar as decisões de um processo. Em termos práticos, um processo de promoções de vendas pode olhar os feedbacks sobre um produto no Twitter e Facebook e tomar decisões baseados nestas questões.
  • Suporte de dispositivo móvel para dar aos contribuintes individuais e supervisores acesso 24/7  para manter a capacidade de respostas em qualquer momento .
  • capacidades analíticas ativas em áreas como monitoramento de atividades de negócios (BAM) e tecnologias CEP (Processamento de eventos complexos) para fornecer análises melhores e mais amplas.
  • painéis de negócios mais elaborados para fornecer melhor visibilidade em tempo real sobre o desempenho do processo.
  • Um conjunto crescente de ferramentas de gestão de decisões, incluindo
    suporte poderoso para a gestão de regras de negócio (BRM e BRMS), tecnologias de otimização e simulação, bem como motores de otimização baseados em restrições que utilizam técnicas matemáticas avançadas para pesar
    trade-offs e gerar a decisão mais eficaz disponível.
  • O acesso a fontes de informação não-estruturados e externas, incluindo vídeo, áudio e streams sociais
  • Integração com ferramentas analíticas on-demand.

Para se implementar um iBPM, é necessário uma boa arquitetura de integração, a escolha e seleção de um bom fornecedor de iBPM e a presença de bons arquitetos para habilitar com sabedoria esta nova e complexa plataforma.

PegaSystems, Appian e IBM largaram na frente e ofertam as soluções mais robustas de iBPM, segundo o quadrante mágico do Gartner Group (Ver quadro abaixo). Mas muitas outras empresas também ofertam soluções interessantes e já habilitam a sua empresa para avançar no caminho das operações inteligentes de negócio.

O quadrante mostra os principais fornecedores da segunda geração de ferramentas BPM do século XXI
O quadrante mostra os principais fornecedores da segunda geração de ferramentas BPM do século XXI, o iBPM.

Texto originalmente postado em: http://www.betapyx.com/blog/2014/01/08/a-evolucao-do-bpm-o-ibpm/.

Plataformas Arquiteturais

Phillipe Kruchten disse uma vez que a vida do arquiteto é uma longa sucessão de decisões sub-ótimas e parcialmente tomadas no escuro. Nada mais verdadeiro, em minha opinião.

Mas qual seria a decisão mais importante que um arquiteto deve tomar. A decisão sobre o estilo da arquitetura é sem dúvida uma destas decisões. Alguns estilos arquiteturais incluem:

  • Cliente-Servidor
  • P2P
  • Multicamadas (n-tier)
  • Centrado em serviços de negócio (SOA)
  • Centrado em processos de negócio (BPMS)
  • Centrado em computação paralela massiva (Grid)

No que tange à tecnologia, entretanto, o conceito da plataforma é sem dúvida a decisão mais importante. A plataforma é o elemento técnico que dá vida ao estilo arquitetural. Uma plataforma é um arranjo de softwares e servidores organizados de forma coerente para resolver problemas comuns no desenvolvimento de software. Dois exemplos comuns de plataformas incluem o Java EE e o Microsoft .NET. Um outro exemplo de um plataforma é o LAMP, que é um arranjo composto de sistema operacional baseado em Linux, servidor Web Apache httpD, servidor de banco de dados MySql e linguagens dinâmicas como PHP, Perl ou Python.

O Java EE,  .NET ou LAMP são usados normalmente para sistemas de informação Web. Naturalmente existem cenários da realidade de mercado onde necessidades mais específicas surgem. Para estes cenários existem outros tipos de plataformas de mercado, muito além do Java EE e o .NET.

Exemplos incluem:

  • Plataformas de ERP/MRP (Enterprise Resource Planning/Material Resource Planning), usadas para automatizar processos de suporte de organizações. Exemplos de produtos nesta linha são o SAP ECC, o Oracle PeopleSoft e Oracle JD Edwards.
  • Plataformas de portais usadas para a criação de sites que unifiquem informações de diversas fontes. Exemplos incluem o Microsoft SharePoint, o Oracle Portal ou o IBM WebSphere Portal.
  • Plataformas de serviços interoperáveis para estilos centrados em serviços SOA. Exemplos incluem o Microsoft WCF ou o Apache Tuscany (padrão SCA).
  • Plataformas de automação de processos de negócio (BPMS) para empresas que estejam e estágios avançados de implementações BPM. Exemplos incluem o IBM Business Process Manager ou o Oracle BPM.
  • Plataformas de serviços de decisão (BRMS) para empresas que busquem flexibilidade e responsividade extrema para as suas regras de negócio. Exemplos incluem o IBM ILOG Operational Decision Management ou o Redhat JBOSS Drools.
  • Plataformas de BI/ETL para o suporte a inteligência de negócios avançada. Exemplos incluem a suíte de produtos IBM Cognos, Microsoft SISS ou Oracle Hyperion.
  • Plataformas de integração de aplicações chamadas de ESB (Enterprise Service Bus). Exemplos incluem o SAP PI, IBM WebSphere ESB e o Microsft BizTalk.

Se escolhemos uma plataforma arquitetural inadequada teremos graves problemas durante o projeto. Curiosamente, muitos “arquitetos” consideram a plataforma como dada e nem sequer pensam nisso. É a síndrome do arquiteto de uma plataforma só, que coloca a tecnologia na frente do problema.

Arquitetos de soluções racionais agem na direção inversa. Eles tem a mente aberta e fazem uma análise dos condutores arquiteturais. A partir destes condutores eles recomendam a plataforma mais apropriada que irá promover o melhor balanceamento dos condutores.

Em cenários mais sofisticados, uma solução pode exigir um conjunto de plataformas distintas. Em um caso SOA que estamos trabalhando atualmente, uma determinada empresa organizou a sua infraestrutura a partir de um conjunto de soluções integradas de BPMS, SOA e ESB.

Grandes fornecedores de mercado como a IBM, Oracle, TIBCO, SAP, Redhat, entre outros gigantes, possuem esquemas conceituais que nos permitem navegar neste mar de tecnologias. Deixo para os curiosos e aficionados pelo tema duas referências respectivamente da IBM e da Redhat.

Arquitetura Referência IBM

Arquitetura de Referência da IBM

Arquitetura Redhat JBOSS Enterprise Middleware

Arquitetura de Referência RedHat JBOSS

O arquiteto das nuvens

A arquitetura de software existe como uma disciplina formal há quase 25 anos. Podemos destacar, ainda no início da sua base como disciplina, alguns artigos fundamentais como este: Larger Scale Systems Require Higher-Level Abstractions, da autora Mary Shaw, do ano de 1989.

Neste artigo ela escreve, de forma pioneira.

“Over the past thirty years, abstraction techniques such as high level programming languages and abstract data types have improved our ability to specify and develop software. However, the increasing size and complexity of software systems have introduced new problems that are not solved by the current techniques. These new problems involve the system-level design of software, in which the important decisions are concerned with the kinds of modules and subsystems to use and the way these modules and subsystems are organized. This level of organization, the software architecture level, requires new kinds of abstractions that capture essential properties of major subsystems and the ways they interact.”

Desde 1989, o campo da arquitetura de software evoluiu muito e diversas outras especializações surgiram tais como o Arquiteto de Soluções, o Arquiteto de Dados ou o Arquiteto de Infra-estrutura . Destaco neste post um novo membro da fauna de arquitetos, o arquiteto das nuvens ou the cloud architect.

Este novo membro da fauna de arquitetos requer competências diferenciadas a este novo mundo da computação nas nuvens, tais como:

  • Conhecer os novos modelos econômicos que podem ser alavancados por áreas de TI. Modelos de cauda longa (Big Tail), multi-inquilinos (Multitenancy), computação utilitária (Utility Computing) ou Computação Elástica (Elastic Computing) são exemplos destes modelos.
  • Conhecer e usar as diretrizes que influenciam e determinam que serviços de TI devem operar dentro da própria empresa (On-Premises) ou nas nuvens (Cloud).
  • Conhecer e saber comparar os diferentes tipos de nuvens tais como Nuvens Públicas, Nuvens Privadas ou Nuvens Híbridas.
  • Conhecer as principais soluções de mercado e fornecedores nos três pilares da Cloud Computing: Software as a Service – SAAS, Platform as a Service – PAAS e Infrastructure as a Service – IAAS.
  • Aplicar todos estes conhecimentos no desenho de soluções de software que utilizem software como serviço, plataformas como serviços e infra-estruturas virtualizadas como serviços em ambientes nas nuvens.
  • Acompanhar os projetos de ponta a ponta para garantir que atributos fundamentais como baixo acoplamento, segurança, confiabilidade e sustentabilidade (Green Computing), entre outros, estejam sendo corretamente implementados pelo time de desenvolvimento.
  • Ler mais sobre qualquer outra coisa que não seja TI. Arquitetos de nuvens devem falar a linguagem do negócio para recomendarem e sustentarem suas soluções.

Para os que querem adentrar no tema, é recomendável estudar na prática plataformas como o Database.com ou o Force, da Sales Force, o Microsoft Azure ou o Amazon AWS. Estes fornecedores, dentre outros, fornecem kits de desenvolvimento e uso gratuito de suas plataformas para provas de conceito e estudos.

“In 2000, when my partner Ben Horowitz was CEO of the first cloud computing company, Loudcloud, the cost of a customer running a basic Internet application was approximately $150,000 a month”, Marc Andreessen .

O princípio de Occam aplicado na escolha de soluções técnicas

Consideremos um problema de integração ad-hoc entre duas empresas sobre um canal seguro. A empresa B precisa disponibilizar informações sobre estoques de seus produtos criados em uma aplicação ASP.NET MVC. A empresa A precisa consumir estas informações sincronamente (RPC) em uma aplicação Java EE. Os desenvolvedores nas empresas A e B conhecem suas tecnologias de desenvolvimento e o protocolo HTTP.

Um arquiteto de integração é exposto a três soluções possíveis de RPC:

1. Criar uma API sobre SOAP/HTTPS, expor os serviços da empresa em WSDL e criar objetos de dados complexos em XSD.

2.Expor a API  sobre protocolo HTTPS através dos métodos GET/POST em um mecanismo REST.

3. Criar uma comunicação CORBA sobre GIOP/IIOP a partir do uso de COM+ ou WCF em .NET e consumir o objeto remoto através de um EJB (RMI/IIOP).

A lei da parcimônia nos diz para escolher a solução 2 neste contexto, dada que é a mais simples e irá resolver o problema sem a adição de mais complexidade à solução.

Se houver algum outra variável no problema, a solução é reavaliada naturalmente. Assumi no exemplo que nenhum outra questão se faz presente para tornar a explicação mais didática.A lei da parcimônia é antiga e foi formulada por Willian of Ockham ainda no século 14. Ele descreveu o princípio que é conhecido como lâmina de Occam, que diz  que a explicação para qualquer problema deve assumir apenas as premissas estritamente necessárias à explicação do fenômeno e eliminar todas as que não causariam qualquer diferença aparente nas predições da hipótese ou teoria. Em outras palavras, este princípio recomenda assim que se escolha a teoria explicativa que implique o menor número de premissas assumidas e o menor número de entidades na solução. Na arquitetura e desenho de software, este princípio nos diz que a solução mais simples para resolver um problema deve ser escolhida, quando temos diversas soluções para resolver uma determinada questão.

São contra-exemplos deste princípio:

  • As famigeradas arquiteturas lasanhas do J2EE 1.3 e 1.4 com quase 10 camadas entre a tela  o banco de dados.
  • Objetos de transferência TO/VO iguais aos objetos de domínio (POJO/POCO).
  • Bancos de dados normalizados além da necessidade do problema.
  • Padrões de desenho artificiais.
  • Métodos/Funções com centenas de linhas de código.

Um bom exemplo da simplicidade aplicada é o método EssUP de Ivar Jacobson. Uma lâmina no contexto da essência arquitetural de um projeto é apresentada aqui para os interessados.

“We are to admit no more causes of natural things than such as are both true and sufficient to explain their appearances. Therefore, to the same natural effects we must, so far as possible, assign the same causes.”, Isaac Newton