Um dos calcanhares de Aquiles no processo evolutivo na adoção do DevOps é a arquitetura. Sendo que a grande maioria dos sistemas legados está sustentado em arquiteturas monolíticas, temos aí uma das grandes restrições.
Sintomas da arquitetura monolítica, em um ambiente legado e evoluído ao longo do tempo por muitas mudanças:
A arquitetura monolítica, em um ambiente legado e evoluído ao longo do tempo por muitas mudanças (talvez evoluído de maneira não tão cuidadosa), pode apresentar sintomas que podem demandar bastante esforço para corrigir.
Exemplos manifestados em forma comum podemos dizer a falta de clareza e documentação, códigos replicados, dependências não claramente explícitas, codificação que incorpora uma lógica um pouco confusa de entender devido a adaptações rápidas que de alguma maneira dificultam tanto um bom entendimento entre profissionais, como a possibilidade de incorporar mudanças em forma rápida.
Dificuldade complementar
Uma dificuldade complementar é a dificuldade em encontrar a causa raiz ou pontos de melhoria quando se materializam erros e falhas, especialmente quando precisamos agir em forma rápida para evitar comprometer o negócio com indisponibilidades não desejadas. Talvez os mais experientes na própria solução conseguem mais facilmente decifrar sua implementação, criando uma dependência não saudável entre estes profissionais e suas soluções.
Superespecialização
Sabemos que Devops tenta tirar a dependência do superespecialista de alguma solução que tenha ficado preso, para evitar “silos” onde não teríamos flexibilidade de adaptação com a cooperação de outros profissionais. Então sofremos frente a sobrecarga de trabalho podendo causar esperas e desperdícios.
A superespecialização pode causar outros sintomas, como alienação do negócio, pode estimular a falta de cooperação e a fragilidade de dar continuidade com a solução quando o profissional não participar mais na evolução da solução.
A incorporação de um novo profissional para conseguir atender com qualidade, tendo domínio e preparação para dar continuidade adequada, pode ser demorado e desgastante, já que há necessidade também de conhecer as regras de negócio.
Monitoração e acompanhamento dos parâmetros
Uma outra falta bem comum nestas soluções mais antigas é a falta na capacidade de monitorar a aplicação e conseguir acompanhar parâmetros que possam ser utilizados pelos profissionais da operação para acompanhar e calibrar o comportamento de acordo com a demanda do momento.
Elevar o grau de controle e visibilidade da aplicação, visando poder intervir em forma preventiva para adaptar as necessidades das demandas, como por exemplo, picos de uso de memória, processamento, conexões, alocação temporária de recursos, cálculos específicos, etc. é fundamental para estabilizar a solução para o negócio.
Na medida em que aumenta esta visibilidade é possível direcionar também os recursos que a solução disponibiliza, para em momentos específicos, administrar os recursos e funcionalidades em forma racional e equilibrada, como por exemplo, desabilitar acessos a algumas funcionalidades do usuário para liberar outras, de acordo com prioridade dos momentos (pico de vendas, fechamentos do mês, etc.) de maneira controlada e em alguns momentos até em forma automatizada. Se a arquitetura é monolítica, poderemos estar limitados a usar estas estratégias, que podem exigir um grande esforço para sua incorporação.
Integração Contínua x Arquitetura monolítica
A arquitetura monolítica também tem alguns efeitos indesejados nas disciplinas que DevOps incorpora, como por exemplo, na Integração Contínua.
Se pensarmos que devemos estimular aos desenvolvedores na pratica de realizar commit com frequência em uma estratégia do trunk based ou o mais próximo dela (feature branch ou pull-request, por exemplo), estamos também precisando calibrar um ferramental que permita validar a contribuição de código em um curto intervalo de tempo. Sendo assim, compilação, testes de unidade, análise de código, vinculação, etc são algumas das partes que precisam atenção.
Se o processo demora “muito” (sempre com um bom senso, mas por exemplo, mais do que 10 minutos), podemos ter o efeito contrário, desestimulando a prática frequente, e a execução frequente de commit será evitada. Se a arquitetura é componentizada, por exemplo, não há necessidade de analisar e compilar todos os componentes, e sim, somente os afetados, encurtando os tempos de respostas dos servidores da integração continua.
Coordenação da execução das atividades
A coordenação da execução das atividades de desenvolvimento pode ser afetada também quando estamos inseridos em arquiteturas monolíticas. A prática da integração continua pode precisar ser estimulada para evitar que se acumule código que simultaneamente vários desenvolvedores estão alterando.
Se privilegia a otimização individual (uso de branch) teremos esforços redobrados no ato do merge causando desperdício, retrabalho e atrasos. Se privilegiamos a otimização do grupo (estratégia de uso de trunk) os impactos nos desperdícios são menores, mas exige uma coordenação maior na divisão do trabalho, para evitar que em paralelo os profissionais alterem partes de código comum, podendo demandar esforços sincronia do trabalho.
A incorporação de testes de unidade também pode ser afetada em arquiteturas e soluções que não estejam preparadas. Se a construção das rotinas e funções do código são extensas, poderá ainda demandar esforços de refatoração para dividir em funções menores para poder suportar testes de unidade.
Técnica Estrangulamento
Existem técnicas, como a bem conhecida “Estrangulamento” mencionada por Martin Fowler (padrão estrangulamento) que permite conviver gradualmente a arquitetura, componentizando parte da soluções, mantendo a solução existente e ao mesmo tempo substituindo pedaços controlados em componentes ou micro serviços.
A grande vantagem deste modelo de transformação gradual é que podem ser definidos planos escolhendo pontos mais frágeis, ou aqueles que sofrem mais mudanças e comprometem o restante da solução. Uma estratégia clássica comummente usada é substituir todo o software a partir de uma nova construção em paralelo, que pode ser muito laboriosa, que em muitos casos pode levar a um novo pesadelo nessa linha de trabalho big-bang que o DevOps tenta evitar de todas as formas.
A co-existência evolutiva da solução é também mais econômica, se pensamos que não precisamos duplicar times a partir do modelo clássico.
Grandes desafios, são permeados por soluções geniais, que surgem na medida que compartilhamos conhecimentos e experiência na base do DevOps.
