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.
Nenhum comentário:
Postar um comentário