segunda-feira, 8 de junho de 2015

Antenado com as novidades em TI


Se você é um profissional pelo menos um pouquinho antenado, deve ficar meio “baratinado” com tanta novidade, não? Aqui, no Bom Programador, eu tenho tentado apontar caminhos, mostrando a você, sempre com exemplos práticos, o que os líderes de tecnologia estão usando. São soluções que podem racionalizar seus custos e permitir que você se adapte a esse mundo de “método ágil”.


Então, preparando seu espírito para o meu próximo artigo técnico, gostaria de rever alguns conceitos que formam o moderno ambiente de Tecnologia da Informação.



 É mais ou menos assim



Vivemos em um mundo, no qual as empresas necessitam de extrema agilidade e independência. A concorrência e as instabilidades (sejam tecnológicas ou políticas) não podem atrapalhar o ambiente de negócios.

Uma das gigantes tecnológicas atuais, é a Netflix! Isso mesmo! Aquela app que você usa para ver filmes. Sabia que ela não tem um datacenter? E que ela também não tem servidores? Sabia que toda a infraestrutura da Netflix é baseada em nuvem, fornecida pela Amazon? Pois é... Mas tem muito mais por trás desse conceito.

Os pilares da TI moderna

  • IaC (Infrastructure As Code): Infraestrutura como código;
  • IaaS (Infrastructure As A Service): Infraestrutura como Serviço;
  • CD (Continuous Delivery): Entrega contínua;
  • Phoenix Servers;
  • Monitoramento Ativo;
  • Escalabilidade Elástica;
  • Arquitetura de Micro serviços;

Sem utilizar esses conceitos, você não vai se beneficiar das novas práticas, como: Computação em Nuvem e Métodos Ágeis.

Radical? Bem, posso até ser, mas leia o meu “arrazoado”, antes de formar sua opinião.

IaC – Infraestrutura como código



É transformarmos nossos ativos de infraestrutura, como: Subnets, servidores e outros, em código-fonte, executado por softwares de provisionamento de VMs ou de Containers, como: Vagrant ou Docker.

Toda nossa infra física é composta por máquinas “hospedeiras”, que podem ser programadas para acomodar novos “hosts” dinamicamente.

Por que usar? Em um ambiente de TI moderno, não há mais espaço para configuração manual de servidores. A tarefa de instalar software e preparar um Servidor é mecânica e repetitiva, ou seja, um processo que pode ser executado de maneira mais rápida e confiável por um computador, acaba se tornando fonte de problemas, quando executada por pessoas.

Se você usa IaC, qualquer alteração em sua infraestrutura, seja para corrigir configuração ou apenas para subir mais instâncias, é feita com base em um código-fonte, armazenado em um Repositório versionado. Assim, além de mitigar o risco de erros de configuração, automaticamente documentamos toda a nossa infraestrutura.

IaaS – Infraestrutura como Serviço



É a própria definição de “nuvem”: Um grupo de recursos físicos (servidores, roteadores, firewalls etc), configurado por software, e executado sobre virtualizadores, como: VirtualBox, VMware, Docker, ou outros, que fornecem “hosts” virtuais, sob demanda, para os seus clientes.

Com um bom software de controle de nuvem, como o OpenStack, é possível permitir até mesmo a configuração da rede e dos serviços, por exemplo: Load Balance, Subnets, Firewalls e Storage.

Hoje em dia, não faz sentido comprar infraestrutura física, ou seja, para um determinado propósito. O avanço dos processadores e dos softwares de virtualização, permite compartilharmos os recursos físicos, expandindo sob demanda.

CD – Entrega Contínua



Uma das coisas mais difíceis de fazer é colocar software em produção, certo? Chega a ser doloroso… Um processo delicado, mal documentado e, quase sempre, executado com problemas, necessitando de “quebra-galhos”.

Não deveria ser assim! Afinal de contas, o software está pronto ou não? Se está pronto, então deve ser simples colocá-lo em “produção”, ou seja, entregá-lo.

Já estamos acostumados a integrar nosso software continuamente, certo? A Entrega Contínua é apenas uma extensão da “Integração Contínua”. Entrega contínua é baseada em alguns preceitos, listados por Martin Fowler:

  • O Software é entregável através do seu ciclo de vida. Ou seja, faz parte do ciclo de vida a instalação do software em um ambiente operacional, que pode ser utilizado pelo usuário final, ou apenas como ambiente de teste. Nenhuma etapa adicional, ou intervenção manual, é necessária para isto;
  • A equipe prioriza manter o software “entregável”, sobre trabalhar em novas características. É fundamental evitar a geração de “builds quebrados”, e o software tem que estar sempre pronto para ser instalado em qualquer ambiente, independentemente das manutenções em curso. Se houver qualquer problema com o software, que impeça esta condição, deve ser resolvido imediatamente;
  • Qualquer um pode obter feedback rápido e automatizado sobre a prontidão de produção dos seus sistemas, sempre que alguém altera alguma coisa neles;
  • Você pode executar entregas com um simples toque de botão, de qualquer versão do software, em qualquer ambiente, sob demanda;

Isto exige uma integração sem precedentes entre o pessoal de desenvolvimento (Dev) e Operação (Ops), daí o conceito derivado de “Devops”, baseado em entrega contínua. Nesse modelo, “produção” é apenas um ambiente, e pode ser gerado automaticamente ou sob demanda.

Se você ainda está naquela onda de “gerar Jar (War, Ear) para produção”, então, meu caro, minha cara, está vivendo no passado. Se você ainda depende da boa vontade e da intervenção manual do pessoal de operações, então algo deve ser feito, e imediatamente.

Phoenix Servers



Martin Fowler cunhou esse termo “Phoenix Servers” em seu artigo: http://martinfowler.com/bliki/PhoenixServer.html.

Vamos a uma pergunta básica: O que aconteceria, se você precisasse instalar mais um Servidor para o seu software? Quanto tempo levaria? Quais seriam os riscos?

Em um ambiente operacional dos anos 80 (a maioria dos nossos Datacenters), isso significaria caos total! Por quê? Porque tudo o trabalho de criação / manutenção de infraestrutura ainda é manual. Conceitos como IaC e IaaS não são empregados, e quando o são, ainda permitem que os operadores façam “logon” nas máquinas!

Um Servidor deveria ser totalmente imutável, ou seja, uma vez que foi gerado, e que esteja “no ar”, só pode ser alterado na fonte. Se for necessário aplicar patch, ou qualquer outra tolice que os Operadores adoram fazer, deverá ser feito no código-fonte, armazenado em um Repositório versionado. Então, o processo de Entrega Contínua deverá criar um Servidor, com o seu software dentro dele, tendo passado por todos os testes automatizados.

Criar e destruir continuamente os Servidores é extremamente saudável, evitando que qualquer pessoa efetue alterações locais e não documentadas. Além disto, caches e arquivos temporários são automaticamente deletados, evitando estouros. E problemas com invasões também! Se você destrói e recria seus servidores continuamente, também exploits que tenham sido utilizados por hackers.

Monitoramento Ativo


O que você faz com seus logs? Para quê serve aquele monte de dados, além de ocupar espaço em disco? Não me diga que você olha os logs!

Cara, o volume de log gerado, tanto pelos softwares básicos, como pelas aplicações, é insano, e, muitas vezes, ignorado. Hoje em dia, as empresas estão processando esses logs, usando softwares de análise de eventos (CEP – Critical Event Processing), ou mesmo soluções de Big Data (Map Reduce), para observar erros e eventos de segurança ou de aplicação. Usando soluções como o Apache Flume, é possível coletar e enviar para pós-processamento.

Além disso, a monitoração deve ser ativa, ou seja, deve tomar atitudes, como: matar um servidor, subir mais servidores ou redirecionar o tráfego.

Escalabilidade Elástica



Sinceramente, a maior razão para usarmos nuvem é economia de recursos. Simples assim. E essa economia é possível através da escalabilidade elástica, ou seja, aumentamos ou diminuímos nosso uso de recursos de infraestrutura, conforme a demanda.

Qual é a contrapartida? Você compra racks e mais racks de servidores, esperando picos de demanda. E, efetivamente, está coberto. Mas, será que nivelar pelo pico de demanda é a melhor soluçãoi? E o que você faz com suas máquinas quando o movimento está baixo? Você pode adicionar e remover servidores da sua aplicação facilmente?

Em um ambiente de nuvem, ser capaz de escalar automaticamente é um fator crucial de sucesso.

Ser capaz de monitorar o tráfego, aumentando ou diminuindo a quantidade de servidores disponíveis, é escalabilidade elástica. É o que a Netflix faz.

Arquitetura de Micro Serviços



Vamos supor que você investiu, e conseguiu quase todos esses “pilares”. Será que sua aplicação está preparada para isto? Será que você vai conseguir fazer entrega contínua e escalabilidade elástica com uma aplicação “monstrengo” monolítica Java EE?

Você acha mesmo que dividir sua aplicação em camadas é o melhor caminho? Arquitetura de micro serviços é apenas uma forma diferente de dividir (ou particionar) uma aplicação, segundo a qual, separamos os conceitos de nossa aplicação em serviços separados, que são independentes e que podem ser entregues em separado.