Melhorando o Tempo para Valor: Processo e Paralelização

Há um lamento comum na época do Natal. É gritado do alto dos telhados e de baixo dos galhos espinhosos dos pinheiros.

"Quando uma luz se apaga, todas se apagam!"

Esse é o grito de alguém que está preso com luzes ligadas em um circuito serial. Não vou me alongar em uma palestra sobre o porquê disso acontecer, mas basta dizer que uma única lâmpada queimada é um fator de bloqueio.

Isso não é verdade para aqueles abençoados com luzes conectadas em um circuito paralelo. Uma lâmpada pode queimar enquanto as outras continuam queimando intensamente.

O que isso tem a ver com tempo de retorno e aplicações? Tudo. Porque, como se vê, a TI tradicional está realmente impulsionando a produção em um circuito serial, enquanto o desenvolvimento de aplicativos modernos está a todo vapor em um circuito paralelo.

Processo

Em um blog recente , o CTO de campo da Pivotal Global, James Urquhart, apresenta uma imagem importante da TI contínua que se concentra, apropriadamente, no processo em vez do produto. Ele chama isso de Caminho para a Produção.

A ideia de um Caminho para Produção é realmente sobre processo e, para a TI tradicional, paralelização. Este conceito é essencial para o desenvolvimento e arquiteturas de aplicativos modernos. A decomposição de aplicativos em componentes individuais e focados (às vezes chamados de microsserviços) naturalmente leva ao desenvolvimento paralelo. Isso ocorre porque equipes menores estão trabalhando em componentes diferentes ao mesmo tempo. Em última análise, é isso que faz o Agile funcionar como um mecanismo para atingir maior velocidade e diminuir o tempo de geração de valor para aplicativos. Não são equipes menores. Não são aplicativos menores. É a paralelização alcançada ao alavancar esses conceitos no desenvolvimento e na entrega de aplicativos.

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

O que está no caminho é a TI tradicional. TI serial. Metodologias de desenvolvimento em cascata que se espalharam para o pool de produção. Construímos redes como canais seriais porque os dados fluem serialmente pela rede. Do roteador ao firewall, ao balanceamento de carga, ao servidor de aplicativos e ao banco de dados. Os dados fluem em um caminho previsível de uma extremidade da rede para a outra. E assim implementamos e entregamos esses serviços de aplicativos da mesma maneira: em um processo previsível e serializado que segue 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 atravessam NS e EW, mas aqueles que se desviam para outras direções cardeais. NE para uma nuvem para recuperar um script. SW para recuperar sprites e fontes da web. WSE para pegar um mapa e incorporá-lo em nosso aplicativo.

Mas não é apenas a distribuição de caminhos de dados que torna a paralelização do caminho para a produção necessária hoje. É a busca por eficiência e rapidez, também conhecida como otimização.

Paralelização

Para ganhar a velocidade necessária para executar as expectativas atuais de tempo e valor, é necessário um desenvolvimento paralelo. Não apenas no desenvolvimento de aplicativos, mas também na TI principal. Se observarmos a amplitude dos serviços de aplicativos em uso pelas organizações hoje , podemos ver diversas áreas nas quais a paralelização pode ajudar a acelerar a implantação.

Não é que a TI tradicional seja isolada. Afinal, o resultado de uma arquitetura de microsserviços são dezenas ou centenas de pequenas equipes isoladas, cada uma focada em um conjunto muito específico de funções de aplicativo. A TI tradicional já é composta por silos dentro de silos. O problema é que as práticas de desenvolvimento ágil incentivam o desenvolvimento paralelo dentro de seus silos, e a TI tradicional ainda está implementando processos de produção de forma metódica e serializada.

O problema é a transferência entre equipes e a maneira como espelhamos o tráfego de rede em nosso caminho para a produção. Não é um processo serial e, sempre que possível, devemos fazer isso em paralelo, tanto no desenvolvimento quanto na entrega de serviços.

Isso significa estruturas de equipes multifuncionais que incentivam a colaboração o mais rápido possível.

Ao paralelizar processos por meio da adoção de práticas mais ágeis em todas as áreas, as organizações podem obter maior velocidade e eficiência em seu caminho para a produção.

Processo é o produto

Como James alude, o Caminho para a Produção é realmente um processo. E os processos são compostos de etapas. Como qualquer ninja faixa-preta do processo Six-Sigma lhe dirá, acelerar esse processo significa encontrar e eliminar ineficiências. Na produção, essas ineficiências aparecem como tempos de espera (transferências) entre etapas rígidas e serializadas no processo de implantação.

Ferramentas podem ajudar. Mas, em última análise, a melhoria exigirá uma análise longa e detalhada dos processos e uma busca por oportunidades de paralelizar a entrega de serviços de aplicativos como parte do seu Caminho para a Produção.

Cultura — especificamente uma cultura de colaboração — não é opcional. Tem um impacto muito real nos comportamentos e práticas. A estrutura da equipe por si só muda drasticamente a automação do pipeline, com equipes tradicionais de função única ficando para trás em relação às suas contrapartes contemporâneas, orientadas por DevOps. Promova estruturas de equipe mais colaborativas. Na mesma linha, uma equipe colaborativa deve estar alinhada com as principais métricas. Métricas compartilhadas permitem que NetOps e Segurança trabalhem em direção à implantação contínua sem penalidades. Atualmente, quase três quartos do NetOps são medidos com base no TEMPO DE ATIVIDADE DA REDE. A frequência de implantação mal é registrada para eles. Eles vão se concentrar em manter a rede ativa porque é nisso que eles precisam se concentrar. Métricas compartilhadas dão à NetOps permissão para se concentrar no que a empresa precisa: implantações mais rápidas e frequentes. 

Por fim, é necessária empatia. Vocês estão todos no mesmo time e - pode ser uma surpresa saber - valorizam as mesmas coisas. É provável que o NetOps dê tanta importância à automação de pipeline quanto o DevOps. Lembre-se de que o DevOps tem uma vantagem de dez anos sobre o NetOps na navegação e superação de obstáculos em torno de integração, ferramentas e conjuntos de habilidades. Equipes colaborativas podem ajudar promovendo a padronização de ferramentas que abrangem desde a entrega até a implantação (como Jenkins e GitHub/GitLab).

O caminho para a produção não é um produto. É um processo. E é um processo que precisa ser colaborativo e entregue em paralelo sempre que possível para melhorar o tempo de retorno do investimento e permitir implantações de aplicativos bem-sucedidas.