BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Como adotar uma nova tecnologia: Conselhos da Buoyant sobre a utilização de um service mesh

Como adotar uma nova tecnologia: Conselhos da Buoyant sobre a utilização de um service mesh

Favoritos

Pontos Principais

  • Estar atento ao impacto que a adoção de uma nova tecnologia, como um service mesh no stack de desenvolvimento, tem sobre os responsáveis, nos permite capacitar com sucesso os stakeholders;
  • Precisamos ser claros quanto ao problema que estamos resolvendo, definindo critérios de aceitação apropriados. Fazer experimentos que mostrem como um service mesh pode melhorar a vida dos stakeholders, é uma boa opção;
  • Cultive aliados e vencedores, adotando soluções que foram demonstradas em pequena escala e assim mostrando como um service mesh tornou as atividades muito melhores;
  • Planejamento de prevenção à falhas e o entendimento dos riscos ao longo de todo o processo, podem realmente nos preparar para o sucesso. As preocupações que coletamos desde o início nos ajudam nesse planejamento. Cada risco possível pode ser tratado no começo do projeto, para que não se torne um problema.

Adotar uma tecnologia e implantá-la no ambiente produtivo requer mais do que um simples estalar de dedos. Fazer a implantação ser bem-sucedida e desenvolver melhorias reais é ainda mais difícil. Quando estamos olhando para uma nova tecnologia, como o service mesh, é importante entender que os desafios organizacionais que enfrentamos são tão importantes quanto a tecnologia em si. Mas existem etapas claras que podemos seguir para nos mantermos no caminho da produção.

Para começar, é importante identificar quais problemas um service mesh resolverá no nosso caso. Lembre-se, não se trata apenas de adotar uma tecnologia. Uma vez que o service mesh esteja em produção, é necessário que traga benefícios reais. Essa é a base do nosso caminho para a produção. Depois de identificar o problema que será resolvido, é hora de vender a ideia. Por menor que seja o preço, é necessário investimento real para inserir um service mesh no ambiente produtivo. O investimento exigirá mais do que as suas horas de serviço. As mudanças impactam os colegas de trabalho de várias maneiras, desde o aprendizado da nova tecnologia até a interrupção de tarefas críticas.

Uma das minhas citações favoritas é: "Nenhum plano sobrevive ao contato com o inimigo", dita por Helmuth von Moltke. Quantas vezes fomos surpreendidos durante uma implantação no ambiente produtivo? Se assumirmos que algo vai dar errado, é possível planejar as medidas as serem tomadas com antecedência. Isso tudo faz parte das boas práticas de engenharia. Infelizmente, é mais fácil imaginar os cenários em que tudo dá certo, do que aqueles que podem dar errado. Em particular, porque é comum não sabermos quais os momentos e onde as coisas podem dar errado.

Lembra do problema que está tentando resolver? Agora precisamos confirmar se estamos realmente resolvendo-o. Mesmo quando passamos por uma prova de conceito de tecnologia, o abismo entre o que o site do produto mostra e o que a tecnologia realmente faz no mundo real, pode ser imenso. Ao dar pequenos passos em direção a uma implantação completa em produção, é importante parar um pouco e avaliar se realmente estamos ajudando, ou apenas gastando tempo e dinheiro, e nos estressando por nada.

Que problema estamos resolvendo?

Podemos usar os service meshes para resolver diversos problemas. É importante definir aquele que é mais importante para nós. Isso pode ser usado como critério de aceitação para responder a seguinte pergunta: Tudo isso realmente vale a pena? Bons problemas são aqueles que têm várias soluções possíveis. Se a única solução para um problema é usar uma tecnologia específica, estamos com a faca e o queijo nas mãos.

Os melhores problemas que os service meshes resolvem são aqueles em que os proprietários dos microservices estão aptos a operar no que são especialistas, retirando da obrigação deles coisas que toda plataforma precisa fornecer: Observabilidade, confiabilidade e segurança.

Trabalhar com microservices é complicado. Especificamente, pode ser difícil depurar as interações entre os serviços para encontrar a raiz do problema. É perfeitamente possível contornar este ponto trabalhando com os proprietários de serviços e fazendo com que desenvolvam ferramentas para fornecer a visibilidade necessária. Um service mesh, no entanto, forneceria essa visibilidade com menos esforços das pessoas envolvidas. Pense como é importante permitir que os proprietários dos serviços se preocupem com outras coisas mais importantes e ao mesmo tempo, obtenham a depuração de interação com o mínimo esforço possível.

No mundo dos microservices, cada serviço acaba dependendo de vários outros serviços. Quando um falha, pode atingir outros serviços que compõem as dependências. Os serviços podem ficar presos em longos ciclos de repetição que consomem recursos enquanto processam essas filas. Se não forem gerenciados, o que seria uma pequena falha isolada se torna um problema generalizado no sistema, do qual os usuários irão reclamar a todo momento. A parada do circuito fornece primitivas que podem atenuar esses ciclos longos e também podem impedir uma falha cascateada em todo o processo. Seguindo o tema da capacitação, usando um service mesh para resolver esse problema, iremos fornecer funcionalidades que ajudam os proprietários de serviços a criar soluções resilientes com mais facilidade.

Em algum momento, o medo de não estar em compliance pode assombrar a empresa. Os auditores irão solicitar criptografias para os dados que estão sendo transacionados. A quantidade de trabalho necessária para atualizar e auditar todos os serviços pode ser muito grande. Depois, há os detalhes problemáticos, como revogação e atualização de certificados. Ao usar um service mesh, podemos tornar todos esses problemas uma preocupação operacional em vez de uma questão de desenvolvimento. Utilizando uma maneira de lidar com a criptografia dos dados em movimento, ao invés das centenas de formas que podemos confrontar no mundo dos microservices, a auditoria será muito mais simples.

Para a Houghton Mifflin Harcuort, uma editora de livros educacionais e comerciais dos Estados Unidos, o problema que gostariam de resolver girava em torno da agilidade do desenvolvedor. Robert Allen, diretor de engenharia, afirmou: "Com o Linkerd, a equipe pôde prosseguir num contrato de trabalho e estar um passo a frente, isso sem interromper o cronograma de implantação. Conseguimos dissociar mais as equipes e nos tornar muito mais ágeis. Este foi um grande benefício".

Ter uma declaração dos problemas concretos e os critérios de aceitação bem definidos é o primeiro passo para a adoção bem-sucedida de um service mesh na produção. Tudo isso nos dará insumos para utilizarmos na próxima etapa, que é vender a ideia, mostrando o valor do service mesh para as demais pessoas. Também teremos uma barra para medir o progresso à medida que implementamos a nova ferramenta. Existem outros problemas que podemos resolver. Os citados anteriormente são apenas os mais comuns, que sempre surgem de tempos em tempos.

Venda a ideia

Raramente alguém trabalha sozinho, e é improvável que um service mesh possa entrar em produção sem a ajuda várias pessoas. Se não pode, ou não consegue, convencer os demais colegas de que isso é uma boa ideia, o caminho para a produção irá se tornar infinitamente mais complicado, para não dizer totalmente proibitivo. Armados com o problema que irá ser resolvido, com critérios de aceitação definidos e uma explicação clara do valor da ferramenta, teremos a oportunidade de conquistar aliados à nossa causa. Transformar os colegas em aliados cria vozes mais fortes para defender as virtudes de um service mesh. Esse tipo de aceitação organizacional pode evitar vários erros ao longo do caminho para a produção.

Cada stakeholder terá suas próprias preocupações. Um desenvolvedor pode se preocupar por ter que aprender novas tecnologias, além de necessitar escrever códigos de integração que poderão impactar nos prazos de entrega atuais. O gerente da equipe pode estar preocupado com o tempo de inatividade, bem como com as novas dependências comerciais. É importante conversar com cada um desses stakeholders para entender suas preocupações, pois elas nos ajudarão a moldar como a implantação ocorrerá, além de fornecer uma plataforma para descrever quais benefícios cada um irá receber.

Ao solucionar os problemas mais críticos para a empresa, estaremos fornecendo benefícios a todos os stakeholders. Depois de entender cada preocupação, é possível fornecer uma lista de benefícios e incentivos que explicam o que a ferramenta irá fornecer para cada um. Esta é a parte divertida! Teremos a oportunidade de explicar como a solução desse problema capacitará nossos colegas com novas ferramentas e recursos. Imagine como será emocionante para a equipe de segurança entender que haverá criptografia consistente entre os serviços.

Exemplo de preocupações dos stakeholders:

Stakeholder

Incentivo

Preocupação

Engenheiros de plataforma

  • Visibilidade unificada em todos os serviços
  • Isolamento de falha
  • É confiável?
  • Irá introduzir mais complexidade?

Desenvolvedores / proprietários de serviços

  • Remover a lógica de comunicação complexa do código
  • Executar facilmente versões paralelas de um serviço
  • O que terei de mudar?
  • Preciso aprender uma maneira nova e complicada de fazer as coisas?

Equipe de segurança

  • Aplicação consistente de TLS e authz/authn entre os serviços
  • Diretrizes
  • Isso reduzirá nossa segurança?
  • Quais vetores de ataque são introduzidos?

Gerência

  • Maior ritmo de desenvolvimento
  • Menos interrupções
  • Que dependências estamos introduzindo nos negócios?

Planejar a prevenção às falhas

Em todas as etapas do desenvolvimento, há possibilidades de que um lançamento para a produção dê errado. Planejar cada passo para enfrentar os desafios que virão, tornará todo o processo mais suave. Mesmo antes de qualquer coisa entrar em produção, existem algumas possibilidades de falha. Analise cada etapa do caminho para a produção, focando nos possíveis riscos. Eles podem vir de qualquer lugar e muitos serão desconhecidos até que iniciemos a implementação de um determinado estágio do processo.

Não podemos abraçar o mundo com as mãos. Precisamos nos concentrar no problema que estamos resolvendo. É tentador analisar cada possibilidade e ficar empolgado com uma possível solução. À medida que o escopo de um projeto aumenta, os riscos e o tempo necessário também aumentam. Mantendo o problema e os critérios de aceitação em foco, temos uma alavancagem que pode ajudar a manter o escopo a um nível razoável, permitindo que avancemos com confiança.

Comecemos com pequenos passos, fazendo progressos incrementais. Às vezes parece impossível, mas sempre podemos ver uma peça do quebra cabeça antes de analisarmos toda a imagem. Ao separar o projeto em pequenas entregas, podemos remover grande parte dos riscos que estão envolvidos na introdução das mudanças. Será que podemos imaginar de uma só vez tudo o que é necessário para realizar uma mudança significativa na produção?

Temos separado tempo para lidar com os riscos? Conhecer os riscos é apenas metade do processo. Precisamos saber quanto nos custará o tempo que levaremos para eliminá-los. Comunicar claramente nosso plano para lidar com os riscos, e envolver nossos colegas de trabalho nele, é uma estratégia importante para colocarmos um service mesh em produção.

Está demorando muito para que os stakeholders vejam os benefícios? Pode ser difícil para algumas pessoas entenderem o motivo da implementação do service mesh em produção ser tão demorada. O benefício de trabalhar em pequenas etapas incrementais não é apenas em relação à abordagem de riscos, mas também oferece uma chance de mantermos uma comunicação clara durante cada etapa do processo. Deve-se verificar se cada etapa foi bem-sucedida, e a comunicação deve mostrar este progresso.

Analisar o que funcionou e o que não funcionou em cada etapa também é uma estratégia eficaz para colocar o service mesh em produção. Por meio desta retrospectiva, incentivamos a comunicação e nos concentramos em bons diagnósticos, explicando exatamente o que aconteceu. Quando o problema está sendo resolvido e todos estão cientes disso, a verificação se torna parte integrante do processo de implementação.

Planejar prevenções para as falhas também é útil para apontar quem é o culpado. Quando algo der errado enquanto estivermos alterando alguma coisa no sistema, nós seremos responsabilizados. Entretanto, nem sempre a culpa é nossa! A tecnologia que não foi compreendida em sua totalidade, normalmente é culpada por coisas que não fez. Sempre que isso acontece, temos uma oportunidade de transmitir conhecimento aos nossos colegas de trabalho, explicando exatamente o que um service mesh faz, e principalmente o que não faz.

Quais são as implicações? Pode ser tentador abordar "todos" os possíveis riscos. Mas nem sempre isso faz sentido. Entenda o impacto potencial de cada risco. Alguns deles podem ser extremamente improváveis de acontecer, embora tenham implicações extremas. É provável que outros riscos ocorram e mantenham nosso escopo de implicação pequeno. Cada um desses riscos tem um custo para ser mitigado. Depois de entendermos o custo de cada um, e seu devido impacto, é possível fazer uma análise de custo/benefício em torno de todas as implicações e comunicá-las de maneira clara. Ao falarmos que analisamos os custos e benefícios de mitigarmos os riscos, é possível acalmar os stakeholders que possuem preocupações específicas.

Conclusão

Quando atentamos ao impacto que a implantação de uma nova tecnologia na produção tem sobre os nossos colegas de trabalho, podemos capacitar os stakeholders sem muitas dificuldades. O primeiro passo é deixar claro o problema que estamos resolvendo. Precisamos escolher um problema real que estejamos enfrentando, posteriormente definimos os critérios que, de forma clara, irão demonstrar que o problema foi corrigido e, por fim, podemos utilizá-los para mostrar como um service mesh melhora a vida de todos na empresa.

Obter aliados mostrando as soluções e instruindo-os sobre como um service mesh irá melhorar as coisas, é uma atividade muito importante. É esse tipo de ajuda direta que os colocará do nosso lado e é assim que criamos mais aliados. Precisamos entender quais são as preocupações deles. Também devemos aceitar que a mudança trará riscos. Esses entendimentos, combinados com uma clara visão do problema que estamos resolvendo e os critérios de aceitação, apresentarão oportunidades para ajudar a tornar os colegas em aliados do nosso projeto.

Por fim, fazer um planejamento de prevenção à falhas e entender os riscos ao longo de toda a jornada nos preparará o sucesso. As preocupações que levantamos desde o início podem ajudar neste planejamento. Cada risco possível pode ser tratado desde o início, para que não se torne um problema.

O Form 3 colocou o Linkerd em produção, resultando em algo que podem confiar. Ed Wilde menciona como isso fez uma enorme diferença nos sistemas legados:

"Uma coisa que está clara com o Form 3, é como o número de erros caiu. No nosso sistema legado, veríamos um baixo nível de erros de segundo plano. Isso era aceito. A diferença com este sistema é que simplesmente não temos mais erros. O Linkerd provou ser um componente em que podemos confiar por ser robusto. Não tivemos nenhum problema operacional com ele".

Este não é um plano infalível. Mas, seguindo estas etapas, estaremos muito mais equipados para implantar um service mesh em produção na nossa empresa. Colocar um service mesh em produção não está relacionado apenas com a tecnologia, trata-se também de saber como capacitar nossos colegas e fazê-los sentir que o resultado lhes dará superpoderes.

Sobre o autor

Thomas Rampelberg é engenheiro de software da Buoyant Inc, autores do service mesh Linkerd. Tem feito uma carreira na construção de softwares de infraestrutura que permitem que desenvolvedores e operadores se concentrem no que é importante em seu cotidiano. Enquanto trabalhava na Mesosphere, ajudou a criar o DC/OS, uma das primeiras plataformas de orquestração de containers usadas por muitas das empresas listadas na Fortune 500. Passou para o próximo grande problema: Fornecer informações sobre o que está acontecendo entre os serviços, melhorando a confiabilidade entre eles, usando as melhores práticas para proteger os canais de comunicação.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT