Reduzindo o tempo para gerar valor: processos e paralelização

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Há um lamento comum na época do Natal. Ele ecoa do alto dos telhados e debaixo dos galhos espinhosos dos pinheiros.

"Quando uma luz apaga, todas as outras apagam!"

Esse é o lamento de quem está às voltas com luzes ligadas em um circuito em série. Não vou me desviar do assunto para explicar por que isso acontece; basta dizer que uma única lâmpada queimada impede o funcionamento de todas as outras.

Isso não acontece com aqueles que têm a sorte de possuir luzes ligadas em um circuito paralelo. Uma lâmpada pode queimar enquanto as outras continuam brilhando intensamente.

O que isso tem a ver com o tempo para geração de valor e com as aplicações? Tudo. Porque, ao que parece, a TI tradicional avança rumo à produção em um circuito em série, enquanto o desenvolvimento de aplicações modernas segue a todo vapor, dia e noite, em um circuito paralelo.

Processo

Em uma publicação recente no blog, o CTO global de campo da Pivotal, James Urquhart apresenta uma visão importante da TI contínua que, apropriadamente, prioriza o processo em vez do produto. Ele a chama de Caminho para a Produção.

A ideia de um Caminho para a Produção diz respeito, na verdade, ao processo e, para a TI tradicional, à paralelização. Esse conceito é fundamental para o desenvolvimento e as arquiteturas de aplicações modernas. A própria decomposição das aplicações em componentes individuais e específicos (às vezes chamados de microsserviços) leva naturalmente ao desenvolvimento em paralelo. Isso ocorre porque equipes menores trabalham em diferentes componentes ao mesmo tempo. Em última análise, é isso que faz o Agile funcionar como um mecanismo para aumentar a velocidade e reduzir o tempo necessário para que as aplicações gerem valor. Não são as equipes menores. Não são as aplicações menores. É a paralelização obtida ao aplicar esses conceitos ao desenvolvimento e à entrega de aplicações.

A mesma abordagem se aplica ao Caminho para a Produção. Ou seja, os componentes (serviços) de produção necessários para implementar a escalabilidade e garantir a segurança das aplicações fazem parte de um processo muito mais amplo, e alguns deles podem ser desenvolvidos e entregues em paralelo.

O que impede esse avanço é a TI tradicional. A TI sequencial. Metodologias de desenvolvimento em cascata que acabaram se estendendo ao ambiente de produção. Construímos redes como canais sequenciais porque os dados fluem sequencialmente pela rede: do roteador para o firewall, depois para o balanceador de carga, o servidor de aplicações e o banco de dados. Os dados percorrem um caminho previsível de uma extremidade da rede à outra. Por isso, implementamos e disponibilizamos esses serviços de aplicação da mesma forma: por meio de um processo previsível e sequencial que acompanha naturalmente o caminho dos dados.

Isso não vai mais funcionar.

Primeiro, porque agora existem vários caminhos de dados. Não apenas os caminhos de dados que percorrem os eixos N-S e L-O, mas também aqueles que se desviam para outros pontos cardeais. NE até uma nuvem para obter um script. SO para obter sprites e fontes da web. OSE para obter um mapa e incorporá-lo ao nosso aplicativo.

Mas não é apenas a distribuição dos caminhos de dados que torna necessária, hoje, a paralelização do caminho até a produção. É também a busca por eficiência e velocidade, ou seja, a otimização.

Paralelização

Para alcançar a velocidade necessária para atender às atuais expectativas de tempo para geração de valor, é preciso adotar o desenvolvimento paralelo. Isso se aplica não apenas ao desenvolvimento de aplicativos, mas também à infraestrutura central de TI. Se observarmos a amplitude dos serviços de aplicativos utilizados atualmente pelas organizações, veremos diversas áreas em que a paralelização pode ajudar a acelerar a implantação.

Não é exatamente que a TI tradicional seja compartimentada. Afinal, uma arquitetura de microsserviços resulta em dezenas ou centenas de pequenas equipes isoladas, cada uma concentrada em um conjunto muito específico de funções da aplicação. A TI tradicional já é composta por silos dentro de silos. O problema é que as práticas de desenvolvimento ágil incentivam o desenvolvimento paralelo dentro desses silos, enquanto a TI tradicional ainda conduz os processos de produção de forma metódica e sequencial.

O problema está na transferência de responsabilidades entre as equipes e na forma como espelhamos o tráfego de rede em nosso caminho até a produção. Esse não é um processo sequencial e, sempre que pudermos, devemos paralelizar o desenvolvimento e a entrega de serviços.

Isso significa estruturas de equipes multifuncionais que incentivem a colaboração desde o início.

Ao executar processos em paralelo por meio da adoção de práticas mais ágeis em todas as áreas, as organizações podem alcançar maior velocidade e eficiência em seu caminho até a produção.

O processo é o produto

Como James sugere, o Caminho para a Produção é, na verdade, um processo. E processos são compostos por etapas. Como qualquer ninja de processos Six Sigma faixa-preta dirá, acelerar esse processo significa identificar e eliminar ineficiências. Na produção, essas ineficiências se manifestam como tempos de espera (transferências) entre etapas rígidas e sequenciais do processo de implantação.

As ferramentas podem ajudar. Mas, em última análise, para melhorar será necessário analisar os processos de forma minuciosa e criteriosa, além de buscar oportunidades para executar em paralelo a entrega de serviços de aplicações como parte do seu Caminho para a Produção.

A cultura — especificamente, uma cultura de colaboração — não é opcional. Ela tem um impacto muito concreto nos comportamentos e nas práticas. A própria estrutura da equipe altera drasticamente a automação do pipeline, e as equipes tradicionais de função única ficam para trás em relação às equipes modernas orientadas por DevOps. Incentive estruturas de equipe mais colaborativas. Da mesma forma, uma equipe colaborativa deve estar alinhada quanto às principais métricas. Métricas compartilhadas permitem que as equipes de NetOps e Segurança trabalhem em prol da implantação contínua sem serem penalizadas. Atualmente, quase três quartos das equipes de NetOps são avaliadas pela DISPONIBILIDADE DA REDE. A frequência de implantação mal é considerada para elas. Essas equipes se concentram em manter a rede disponível porque é nisso que precisam se concentrar. Métricas compartilhadas dão às equipes de NetOps a liberdade de focar no que a empresa precisa: implantações mais rápidas e frequentes.

Por fim, é preciso ter empatia. Todos fazem parte da mesma equipe e — por mais surpreendente que pareça — valorizam as mesmas coisas. As equipes de NetOps têm tanta probabilidade quanto as de DevOps de atribuir grande importância à automação de pipelines. Vale lembrar que o DevOps está dez anos à frente do NetOps na tarefa de lidar com e superar obstáculos relacionados à integração, às ferramentas e às competências. Equipes colaborativas podem ajudar promovendo a padronização de ferramentas que abranjam todo o processo, da entrega à implantação (como Jenkins e GitHub/GitLab).

O caminho até a produção não é um produto. É um processo. E é um processo que precisa ser colaborativo e executado em paralelo sempre que possível, a fim de acelerar a geração de valor e viabilizar implantações de aplicações bem-sucedidas.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie