Por que você precisa adotar Docker agora mesmo, mesmo se a sua TI for uma Velhinha de Taubaté

DockerUbuntu A Velhinha de Taubaté é um clássico personagem do Veríssimo, criada ao final da ditadura militar (durante o governo Figueiredo). Embora antiga, a Velhinha é atemporal – era a última pessoa no Brasil que ainda acreditava no governo e portanto era constantemente monitorada pelo Planalto. Em suas saudosas crônicas nossos políticos respiravam aliviados quando a Velhinha acreditava dos desmentidos veiculados após os escândalos e trapalhadas ainda hoje tão característicos de nossos representantes. Se perdessem a Velhinha tudo estaria acabado; enquanto ela ainda acreditasse ainda haveria esperança. Impossível não lembrar da Velhinha quando lemos um típico relatório de auditoria de TI, mesmo hoje já adentrando 2016. A impressão que tenho é que auditores de TI restringiram-se à literatura de certificação ITIL, PMP, Cobit e outras porcarias semelhantes e jamais acompanharam nada do que tem acontecido nos últimos 10 anos. Quando colocado acima da principal obrigação da TI – que é pura e simples entrega de valor – todo este cabedal messiânico de “melhores práticas” e “ferramentas para excelência” tem a mesma importância que as Obras Completas de Auto-Ajuda do Lair Ribeiro: nenhuma.

“Isso é um problema de gestão”

É típica entre auditores e consultores desta linhagem a crença que para um barco seguir um rumo melhor temos que trocar remadores por corneteiros. Para eles tudo é “um problema de gestão”, tecnologias têm contribuição apenas marginal para processos de entrega e processos são melhorados tornando-se mais burocráticos e morosos. O sonho dourado de todo auditor é tornar a TI tão eficiente quanto uma repartição pública de Sucupira. Gostamos de pensar na TI corporativa como o motor de inovação institucional, mas na maioria das vezes a TI passa metade do seu tempo gerenciando caos e a outra metade tentando piorar a própria vida. Perdemos uma década escrevendo casos de uso como oferendas ao RUP até que processos ágeis puseram fim a esta insanidade. Enquanto isso as equipes de infra-estrutura construíram seus castelos (apoiadas pelos manuais de “melhores práticas”) e agora entregar um release é como acertar um tiro em uma mosca dentro de uma sala escura.

Tara por Controle

Toda organização tem uma história destas para contar: algum desenvolvedor em priscas eras, com permissões demais e precaução de menos, deu um DROP TABLE em produção sem querer. Caos e traumas à parte, implantam-se processos formais de aprovação para este tipo de operação de forma que isto nunca mais se repita. O tempo passa e, com a especialização das muitas áreas de TI, temos agora equipes distintas para bancos de dados, rede, application servers, storage etc., cada uma delas com seus processos documentados, suas métricas de sucesso, seus silos operacionais. Processos “a la ITIL”, com sua tara por ilusões de controle, não raro têm o efeito prático inverso do que pretendem. A divisão forçada de papéis e mecanismos de controle esquizofrênicos criam apenas uma engenharia de transferência de culpa e de abandono de responsabilidade, prejudicam a comunicação entre as equipes e garantem apenas que entregas não tenham qualidade. Para sermos mais justos, ITIL tem boa aderência a processos operacionais associados à infraestrutura ou mesmo à gestão financeira – nestes nichos os processos ITIL ainda são consistentes. De resto, com um pouco de boa vontade ainda podemos encontrar coisas boas aqui e ali, mas quando observamos tais processos sob a ótica de entrega de valor a coisa toda começa a cheirar muito mal – ITIL exala o fedor antigo das profundezas ancestrais do desenvolvimento em cascata (waterfall model ). Empresas digitais já perceberam que a capacidade de inovar e de entregar funcionalidades rapidamente é um fator crítico para o sucesso. Nestas organizações a entrega de valor tem prioridade adequada aos dias de hoje. Já em empresas “tradicionais” a entrega de um release é encarada como um ato de risco, e a pobre alma responsável pela tarefa deve agora abrir requisições formais para uma dezena equipes e rezar para que todas sejam executadas em tempo hábil e de forma coordenada (o que nunca ocorre). A situação absurda – lugar comum em TIs corporativas que ainda não fizeram a transição para processos ágeis e entregas em nuvem – é que os processos instaurados para dirimir risco são – eles mesmos – o maior risco operacional de todos. É bom repetir: não há maior risco operacional para corporações que a preservação de seus processos legados de TI. Nada é mais determinante para colocá-las completamente fora do jogo competitivo que a inabilidade para mudar rapidamente. Se os processos vigentes promovem estabilidade em detrimento de entregas jogue-os fora e tente de novo, quantas vezes precisar, até aprender a fazer direito.

Prevenção a Mudanças

Uma obviedade que salta aos olhos de qualquer um que não mora em uma caverna é que compliance e governança estão – ou deveriam estar – mais preocupados com a coleta de evidências ao longo da condução de processos ágeis que com a imposição de processos morosos que pareciam uma boa ideia nos anos 90. A lógica deturpada da “velha escola” (que é a cartilha típica de muitos auditores) é que toda mudança representa risco, deve ser analisada, aprovada e implantada em uma janela de tempo considerada segura. A TI é cortada em silos operacionais (cada um com suas responsabilidades, métricas e SLAs), processos formais são enfiados goela abaixo em cada uma de suas interfaces e às favas com a cadeia de valor. É um teatro de absurdos sem tamanho: todos felizes com suas métricas mas a entrega de projetos – que é a única entrega de valor que realmente conta para a organização – transforma-se em uma alegre caminhada por um campo minado. Como absolutamente ninguém conhece as reais necessidades do processo de entrega de ponta a ponta as aprovações são pro-forma (mera formalidade inútil), os problemas são muitos e recorrentes (as relações de causa e efeito são ignoradas) e o troubleshooting de qualquer coisa só é viável com uma força-tarefa que envolva 4 ou 5 equipes distintas. A vida vira um pesadelo kafkiano. Não importa quantas vezes você tente até conseguir: seus processos de entrega apenas terão valor quando suportarem entregas frequentes – a prevenção a mudanças apenas garante o represamento das mesmas, aumentando o risco de cada entrega. Como garantir que entregas contínuas tenham qualidade é onde os esforços devem se concentrar. Para o desespero de quem vive de auditoria e consultoria, ITIL falhou miseravelmente em sua missão de trazer eficácia e eficiência à TI corporativa. O modelo DevOps é uma reação natural a este fracasso – o sucesso da adoção de entrega em nuvem (e seu baixo custo) é em devido em boa parte porque seus processos ignoraram solenemente o modelo ITIL. E de todas as tecnologias disponíveis para uma TI corporativa iniciar uma transição para o modelo DevOps de longe Docker é a mais conveniente, eficiente e barata.

Eis que temos o Docker

Poucas vezes ao longo de nossa vida profissional temos o privilégio de testemunhar rupturas tão rápidas e positivas quanto a adoção em larga escala decontainers. A simplicidade de seu uso somada a grande riqueza de cenários em que containers simplificam a vida de todos representam um momento único. Antes do Docker vivíamos um  mundo de duas TIs: o mundo das startups – tipicamente de entrega contínua em plataformas de nuvem com processos ágeis – e o mundo da TI corporativa – o pesadelo kafkiano que já discutimos, moroso, caro e lento. Não é que corporações ignorassem a existência de ofertas em nuvem: mover e-mail, CRM e ERP para a nuvem são escolhas óbvias demais. Quando falamos, porém, em entrega de software (o que sempre existe, nem que seja para integrar as suites na nuvem) é que percebemos estes dois mundos opostos. E você sempre precisa entregar software. Não importa o quanto custou sua solução integrada de logística, CRM ou XPTO – se você entregar a interface padrão para o usuário final ou descuidar das integrações que precisam ser construídas estará em maus lençóis. E não é que não houvessem plataformas para construção de nuvens privadas, mas estas representavam uma ruptura súbita (e talvez cara), sem a possibilidade de adoção gradual e com uma curva de aprendizado proibitiva. Containers permitem que o mesmo modelo de entrega que temos na nuvem seja replicado no meio corporativo com muita facilidade. A curva de aprendizado e o custo de adoção de containers são mínimos e abundam opções para uma transição gradual na TI corporativa. O flerte com containers traz de imediato grandes possibilidades sem que uma infraestrutura de nuvem ou PaaS precise ser montada upfront. O momento em que você percebe que, após todos estes anos, finalmente é possível conceber uma entrega que possa contar com uma infraestrutura imutável – é um momento “take the red pill”. Riscos? Não raro adotar containers irá, já no dia “zero”, eliminar riscos consideráveis – verdadeiros bodes na sala – com os quais a TI corporativa se acostumou a fazer vista grossa. Investimento? Amigos, já estamos no século XXI. Investimentos sucedem a percepção de valor – você terá containers em produção bem antes de decidir investir em ferramentas que lhe permitam ganho de escala e melhor gestão.

Qualquer caminho é caminho

É importante frisar bem: com “costuras” bem simples de produtos open-source é possível para qualquer organização adotar processos de entrega no modelo de uma nuvem privada sem gastar um centavo sequer com licenciamento. Para o mundo JEE, por exemplo, containers representam uma rota de fuga segura do modelo de entregas monolíticas em application servers “gordos” para, por exemplo, entregas de serviços implementados via Spring Boot.
“Não existe uma única maneira “mais correta” de se adotar containers. Estas novas criaturas são tão úteis e flexíveis que você se surpreenderá utilizando-os em cenários completamente distintos.”
Se você está querendo aprender cada vez mais sobre o Docker, conheça o que a virtualização enxuta pode fazer para sua empresa, a Linux Solutions possui dois conteúdos sobre esse tema:
  1. um artigo no blog: O Docker e a Virtualização Enxuta
  2. um curso sobre Docker: Introdução ao Docker

Próximos artigos

Nos próximos artigos iremos discutir estratégias de adoção de containers em ambientes corporativos. E você, está pensando em adotar alguma solução baseada em Docker? Está estruturando algum projetando e quer ajuda de um especialista? Converse conosco, a Vertigo é parceira oficial da DockerWSO2 e Mulesoft aqui no Brasil e temos experiência em projetos dessa natureza.

Tags: , , , , ,

Trackback de seu site.

Vertigo

Somos uma consultoria de negócios focados em TI, agilidade e inovação são aspectos que levamos a sério. O nosso objetivo é Ajudar o nosso cliente a crescer utilizando a Tecnologia, é nisso que acreditamos!

Canais

Assine a nossa newsletter:

   


Av. Rio Branco, 151, sala 1002 – Centro
Rio de Janeiro, RJ - Brasil
CEP 20040-911
+55 (21) 2232-0123