Em discussões anteriores, destacamos a importância de alinhar os esforços de modernização com os resultados de negócios e o alinhamento estratégico corporativo. Também exploramos os desafios associados à modernização de aplicativos em um ambiente corporativo, incluindo cultura isolada e regulamentos inesperados ou problemas de política. Considerando esses fatores, fica claro que alcançar o valor desejado da modernização requer uma abordagem que leve em consideração detalhes específicos da empresa. É importante observar que essa abordagem nem sempre resulta na solução técnica ideal ou perfeita. Para nos ajudar a enfrentar esses desafios e alcançar o resultado desejado, vamos explorar o conceito de fluxos de trabalho opinativos.
O que é um fluxo de trabalho opinativo?
Parte da escrita sobre fluxos de trabalho opinativos gira em torno de produtos SaaS (software como serviço). No entanto, gostaria de focar a discussão em torno do conceito de que um fluxo de trabalho opinativo pode fornecer resultados alinhados com nossos objetivos estratégicos, que são imediatamente utilizáveis ??em um ambiente corporativo específico porque muitas das opções (por exemplo, segurança, auditoria e conformidade) usadas para chegar ao resultado foram pré-configurados por membros da empresa que conhecem melhor esses padrões.
Com os fluxos de trabalho opinativos corretos, você pode melhorar a velocidade do loop de feedback do desenvolvedor e do loop de feedback das operações . Conforme declarado em artigos anteriores, esses loops são necessários para entregar os resultados acordados durante o esforço de modernização e também fazer com que o aplicativo recém-modernizado possa realmente ser operado com a cultura de operações existente da empresa. Melhorias na cultura da operação podem ser feitas durante o projeto de modernização. No entanto, se o resultado da modernização de um aplicativo exigir que toda a cultura operacional da empresa também seja modernizada, o projeto poderá muito bem perder seus cronogramas e restrições orçamentárias.
Vamos falar sobre as características de um fluxo de trabalho bem opinativo em relação aos desafios específicos encontrados nas empresas.
Características de um bom fluxo de trabalho opinativo
Deve fornecer um resultado valioso para o ciclo de feedback
Conforme declarado anteriormente, o fluxo de trabalho opinativo deve fornecer um resultado que beneficie um ou ambos os ciclos de feedback. Exemplos podem ser
- criar uma ferramenta de implantação (ou cadeia de ferramentas) com configuração para equipes/usuários consumirem imediatamente, ou
- criando ambientes configurados para serem compatíveis e imediatamente acessíveis à equipe que os solicita.
Resultados sem atrito
Os usuários que consomem a saída do fluxo de trabalho (por exemplo, a ferramenta de implantação, ambiente etc.) devem poder usá-lo imediatamente, sem etapas extras. Não deve haver leitura de páginas de confluência para descobrir etapas complexas de pós-configuração e nenhuma solicitação de permissões para usar os artefatos, ferramentas ou ambientes fornecidos pelo fluxo de trabalho opinativo. O fluxo de trabalho opinativo deve produzir tudo isso, com base nas informações do solicitante e no objetivo que ele deseja alcançar.
Espaço para personalização específica da empresa
Um fluxo de trabalho opinativo ideal é aquele que não apenas fornece resultados sem atrito (por exemplo, ferramentas, serviços, ambientes) para as equipes, mas também fornece pontos de configuração nos bastidores para que os resultados produzidos possam ser ajustados para funcionar nessa empresa a partir de uma auditoria ou conformidade ponto de vista. Não é benéfico para a equipe se eles obtiverem um ambiente que falhe em todas as verificações corporativas ou que não tenha as etapas de proteção necessárias. As pessoas na empresa que estão cientes desses requisitos devem estar envolvidas na configuração do fluxo de trabalho opinativo para produzir resultados compatíveis.
Tudo é observável
Quando se trata da própria ferramenta de fluxo de trabalho opinativa e dos resultados que ela fornece, tudo deve ser observável. Isso pode incluir integração com ferramentas existentes (por exemplo, uma ferramenta APM como New Relic) ou soluções de observabilidade personalizadas. A pilha de observabilidade não deve incluir apenas métricas de sistema de serviços e ambientes, mas também objetivos de nível de negócios.
O fluxo de trabalho deve oferecer suporte a raias para desenvolvedores e operadores
As raias de natação são um conceito importante quando se trata de comunicação entre silos. Uma pista de natação é um fluxo de trabalho que uma equipe (por exemplo, desenvolvedores de uma linha de negócios) pode usar (por exemplo, obter acesso a logs em um ambiente não produtivo) sem ter que interagir com outras equipes (por exemplo, operadores da equipe de infraestrutura ). Isso significa que os desenvolvedores não estão abrindo tickets, enviando e-mails ou conversando com as pessoas para conseguir o que precisam.
Nesse loop, pode haver muitas implantações, com o objetivo expresso de criar um determinado estado no aplicativo implantado e, em seguida, verificar o que aparece nos logs e nas métricas. Se for necessário muito esforço para obtê-los, a experimentação será prejudicada, o que afetará tanto a qualidade quanto a velocidade de entrega do produto.
Da mesma forma, as operações devem ser capazes de fazer suas atualizações e correções na infraestrutura com o mínimo de tempo de inatividade para os desenvolvedores.
Ter essas pistas de natação pode permitir que todos os ciclos de feedback necessários funcionem simultaneamente, melhorando muito a capacidade de obter resultados de qualidade.
Um bom fluxo de trabalho opinativo deve fornecer tais pistas de natação para satisfazer as necessidades dos consumidores dos resultados do provedor de fluxo de trabalho opinativo, mas também marcar as caixas daqueles que auditam e avaliam esses resultados.
Red Hat OpenShift: um exemplo de fluxo de trabalho opinativo para empresas
O Red Hat OpenShift é um exemplo de fluxo de trabalho opinativo para criar e gerenciar clusters personalizados do Kubernetes, que por sua vez pode gerenciar o conteúdo que pode alimentar nosso ciclo de feedback do desenvolvedor. Mas também, o OpenShift adiciona ferramentas e opiniões que podem satisfazer preocupações operacionais, de segurança e de auditoria.
Personalizações corporativas
O Kubernetes surgiu como o plano operacional aceito para executar cargas de trabalho em contêineres. Mas obter um cluster Kubernetes em execução na empresa que atenda a todos os requisitos de auditoria e segurança da empresa pode ser muito difícil para uma equipe de desenvolvimento. Dito isso, diferentes equipes de aplicativos podem exigir clusters com características diferentes (com base em suas diferentes cargas de trabalho).
Isso pode ser problemático para as equipes de operações que tentam oferecer suporte às equipes de aplicativos em toda a empresa. Isso geralmente faz com que os desenvolvedores tenham que abrir tíquetes e/ou fazer reuniões com as operações, retardando qualquer tipo de ciclo de feedback, mas ajudando a abordar melhor os padrões e especificações específicas da empresa.
Adicione a isso os requisitos do regulador para cargas de trabalho que afetam os dados do cliente e/ou aumentam o risco de ameaças cibernéticas caso o aplicativo tenha saída pública. A maioria dos principais provedores de nuvem oferece uma opção hospedada do Kubernetes, que pode ajudar com parte do trabalho de gerenciamento e fortalecimento da segurança para as equipes de operações. Porém, os requisitos regulamentares e as personalizações específicas da carga de trabalho são limitados com um Kubernetes gerenciado em uma nuvem pública.
É aqui que entra o OpenShift. Ele fornece uma abordagem opinativa para um cluster Kubernetes que nos fornece nossos resultados (contêineres para executar aplicativos para alimentar nossos loops de feedback), ao mesmo tempo em que atende aos nossos padrões exigidos e fornece a observabilidade que a equipe de operações precisa para seu feedback laço.
A configuração padrão do OpenShift é moldada pela execução em ambientes altamente regulamentados. Muitas opções já foram feitas para satisfazer a maioria das empresas preocupadas com a segurança, mas ainda oferecem muitas opções para adicionar configuração e personalizações para vários casos de uso.
Pistas de natação do desenvolvedor: observabilidade de aplicativos em um cluster
O OpenShift fornece uma pista de natação para equipes de produtos com seu console de aplicativos, API e CLI. Usando qualquer uma das opções, uma equipe de desenvolvimento pode acessar os status de aplicativos e infraestrutura, bem como logs e métricas, sem precisar entrar em contato com o suporte. Isso mostra minha pista de natação, juntamente com um resultado sem atrito (meu aplicativo sendo executado para mim em um ambiente).
Como desenvolvedor, tenho tudo de que preciso para resolver um problema ou um experimento. Desde que a equipe de operações tenha injetado as opiniões corretas, tudo isso é configurado de maneira compatível. Isso significa que ninguém vai aparecer de repente e tirar essa ferramenta da equipe de desenvolvimento em um momento crítico do projeto.
Agora, para aqueles de vocês com um olhar atento, você pode perguntar, como isso foi construído e implantado no OpenShift? Onde está o gasoduto? É claro que isso também deve ser abordado, mas, para o propósito deste artigo, estamos nos concentrando em obter um tempo de execução utilizável/compatível com pouco ou nenhum atrito por meio do OpenShift (nosso exemplo de um fluxo de trabalho opinativo).
Operando raias de natação: observabilidade de clusters
Enquanto isso, o OpenShift oferece aos operadores dos clusters um meio de atualizar o cluster com tempo de inatividade mínimo ou imperceptível para os desenvolvedores que executam a carga de trabalho nele.
Isso significa que os operadores podem fazer as alterações de segurança necessárias nos ambientes em execução com um efeito mínimo no momento do desenvolvedor.
Caso uma empresa decida mover determinadas cargas de trabalho para a nuvem pública, um cluster nesse ambiente fornecerá o mesmo Console, API ou CLI para as equipes (as raias de natação são mantidas). Nesse caso, pode haver uma customização diferente necessária porque a nuvem pública tem mais vetores de ataque, mas uma vez aplicados os clusters podem ser criados e mantidos na nuvem pública da mesma forma que no datacenter privado.
Selecionando um fluxo de trabalho opinativo para projetos de software
Como escolher um produto que forneça fluxos de trabalho opinativos? Aqui estão algumas ideias.
Deve ter uma comunidade visível trabalhando no produto
Se uma empresa depende de um produto que fornece um fluxo de trabalho opinativo e gastou tempo para integrá-lo ao seu ambiente, a empresa que fornece o fluxo de trabalho opinativo começa a se tornar muito importante. Se essa empresa aumentar drasticamente seus preços, depreciar o produto ou fechar as portas, isso pode ser um problema para seus clientes corporativos. Portanto, selecionar um fluxo de trabalho opinativo que seja de código aberto e tenha uma comunidade ativa pode ser uma vantagem. No mínimo, se o projeto se tornar ativo e for de código aberto, uma empresa poderá formar uma equipe para continuar melhorando e aprimorando o produto para seu uso.
O que há de bom em uma comunidade de código aberto é que o nível de atividade (presente e histórico) é visível. Incluindo a solicitação de recurso e os bugs que os usuários estão encontrando. Com código fechado, uma empresa pode estar lutando para manter o produto antes de descontinuar. Essa luta não seria visível para um cliente que deseja adotar o produto.
Tem uma comunidade saudável de aprendizado e implementação
O produto que fornece o fluxo de trabalho opinativo deve ter suporte para permitir que os usuários corporativos tenham sucesso com ele. A empresa que faz o fluxo de trabalho opinativo deve ter bons treinamentos, amostras e tutoriais.
Novamente, usando o OpenShift como exemplo, uma pesquisa rápida na Amazon traz muitas opções – você já pode ver o livro que escolhi para iniciar minha jornada no OpenShift. Na Udemy, uma variedade semelhante de opções pode ser encontrada. Isso significa que, como desenvolvedor, se você travar, há opções para aprender.
Suporta raias de natação para desenvolvedores e operadores
Conforme discutido, é fundamental que os fluxos de trabalho opinativos habilitem ferramentas ou APIs que permitam que equipes entre silos trabalhem independentemente umas das outras. Isso pode significar fornecer um console para que os desenvolvedores obtenham logs sob demanda (como no exemplo do OpenShift acima) ou fornecer opções de tecnologia que podem ser executadas localmente para os desenvolvedores. Freqüentemente, um desenvolvedor só quer chutar os pneus um pouco em alguma coisa. Isso é bom e deve ser incentivado. Mas algumas equipes de operações encerrarão isso querendo saber por que um desenvolvedor deseja algo e forçando-os a obter aprovações para obtê-lo.
É como o OpenShift lite para os desenvolvedores usarem em suas próprias máquinas.
É perfeito para os desenvolvedores aprenderem alguns conceitos fundamentais que os ajudarão a serem mais proficientes sem ter que passar pelo desafio de provisionamento de infraestrutura. Além disso, ao contrário da experiência na nuvem pública, não custará nada à empresa para os desenvolvedores executarem.
Por que não construir o seu próprio?
Construir x Comprar é uma discussão constante dentro das empresas. Idealmente, se feito com as pessoas certas , a construção pode ser a solução perfeita. Mas o desafio está mais no que acontece depois de construído; é aqui que as rodas geralmente caem.
- A empresa investirá neste produto personalizado a longo prazo?
- Muitas vezes as pessoas estão mais interessadas em construir do que em manter, é preciso haver um investimento em ambos
- Existe um plano para lidar com o desgaste de talentos que conhecem o produto personalizado?
- A equipe de operações pode fornecer suporte de produção para o produto personalizado e/ou os fluxos de trabalho opinativos que ele produz?
Há outro fator a considerar também. Existem desafios e problemas de segurança que só podem ser descobertos em um produto quando ele é executado em escala. Continuando com o exemplo do OpenShift, a plataforma está sendo executada em escala nas empresas há algum tempo. Muitos problemas foram descobertos e corrigidos. Ao criar algo em seu próprio ambiente, esteja preparado para o surgimento de problemas que só podem ser descobertos em escala. Alguns deles podem ser difíceis de corrigir quando os usuários estiverem em seu produto.
Ao seguir esse caminho, uma empresa precisa aceitar esses desafios e concordar em financiar os esforços em torno deles por vários anos. Esta não é uma tarefa pequena e exigirá um compromisso (e dinheiro) sério e de longo prazo. Mas, se bem feito, pode não apenas fornecer uma ótima solução, mas também construir algo de que a empresa possa se orgulhar. Mas essa jornada não é para todas as empresas. Muitos vão lutar para manter o talento necessário ao longo do tempo.
Adotando algo novo
Que tal algo que atende às necessidades do projeto, mas é totalmente novo, o que significa que não possui os casos de uso de produção e a comunidade que algo mais estabelecido possui? Isso pode ser arriscado. No entanto, se esse novo projeto/ferramenta fornecer alguns recursos exclusivos, poderá oferecer uma enorme vantagem ao esforço de modernização. Além disso, se a equipe que está construindo o projeto estiver disposta a colaborar, talvez para obter os primeiros casos de uso de produção, seu projeto pode se deparar com algum poder de engenharia inesperado.
Essa decisão depende das partes interessadas da equipe de aplicativos e operações para determinar se eles estão confortáveis ??com os riscos potenciais. Às vezes, as empresas podem ter algumas barreiras difíceis para colocar novas ferramentas na produção. Mas, novamente, alguém precisa ir primeiro (até o Kubernetes teve um primeiro cliente em algum momento).
Todos gostarão de usar o resultado de um fluxo de trabalho opinativo?
Até agora, concentrei-me nos benefícios dos fluxos de trabalho opinativos na perspectiva de superar os desafios corporativos. No entanto, e os usuários que irão interagir com os resultados opinativos de um fluxo de trabalho opinativo?
Pela minha experiência, uma porcentagem de desenvolvedores em qualquer ambiente corporativo rejeitará completamente um resultado opinativo fornecido por um fluxo de trabalho opinativo . O tamanho dessa porcentagem depende da empresa.
Todos gostarão de usar o resultado de um fluxo de trabalho opinativo?
Até agora, concentrei-me nos benefícios dos fluxos de trabalho opinativos na perspectiva de superar os desafios corporativos. No entanto, e os usuários que irão interagir com os resultados opinativos de um fluxo de trabalho opinativo?
Pela minha experiência, uma porcentagem de desenvolvedores em qualquer ambiente corporativo rejeitará completamente um resultado opinativo fornecido por um fluxo de trabalho opinativo . O tamanho dessa porcentagem depende da empresa.
As razões para esta rejeição podem ser:
- ter o desejo de fazer pessoalmente as opiniões que levam a resultados,
- ter conhecimento de como todos os aspectos do fluxo de trabalho funcionam e não gostar de um resultado sendo produzido sem o envolvimento deles
- querendo ser a equipe para construir tal solução. Nesse caso, os comentários anteriores sobre Construir x Comprar ou adotar uma nova tecnologia podem ser relevantes. Mas tem que haver uma intenção de levar isso para uma produção. Não pode ser apenas um experimento de aprendizado
Se uma empresa tiver muitas dessas pessoas que se enquadram em uma ou mais dessas opções, a ferramenta/plataforma de fluxo de trabalho opinativo falhará.
Dito isso, dados os desafios estabelecidos anteriormente (especificamente em relação ao desgaste e uso de fornecedores terceirizados), uma porcentagem das pessoas no ambiente corporativo desejará apenas fazer um trabalho e ir para casa. Talvez esses recursos estejam lá apenas por três ou quatro meses. Eles podem não se importar ou ter tempo para aprender como fazer as escolhas certas em relação à segurança ou conformidade ou aprender uma nova ferramenta de CI/CD. Em uma situação como essa, um fluxo de trabalho opinativo que forneça resultados sem atrito é o ideal.
Para concluir
Quando escolhido corretamente, um fluxo de trabalho opinativo pode beneficiar muito um ambiente corporativo, ajudando recursos que não estão inclinados ou em posição de fazer todas as escolhas necessárias para usar imediatamente a tecnologia de que precisam.
Em termos de um projeto de modernização, pode ser altamente eficaz na produção dos resultados necessários e na aceleração das mudanças transformadoras necessárias, com menos chances de se envolver em processos exclusivos da empresa, desde que o fluxo de trabalho opinativo suporte configurações personalizadas.
Claro, mesmo depois de selecionar a equipe ideal, colocar seus planos em prática, engajar uma estratégia apropriada e implementar um fluxo de trabalho opinativo, nas empresas às vezes há fatores fora de seu controle que ainda podem levar a problemas de projeto, que é o assunto do meu próximo artigo.
FONTE: Blog Red Hat
A Software.com.br é parceira da Red Hat e também é referência em soluções de tecnologia para o mundo corporativo na América Latina. Através de parcerias com os principais fabricantes do mercado, a empresa atua em Transformação Digital, com consultores especializados em: Licenciamento de Software, Cibersegurança, DevOps, Infraestrutura e Data Analytics.
Veja mais sobre Kaspersky em nosso site: Software.com.br
