Desenvolvimento de Aplicações Com Kubernetes

O Kubernetes é amplamente considerado a plataforma ideal para equipas em organizações de grande e médio porte com requisitos de alta disponibilidade e autoescalabilidade. No entanto, também adicionou atrito aos fluxos de trabalho existentes dos desenvolvedores. Esta mudança pode ser entendida como parte de um impulso mais amplo para a adoção do paradigma de microsserviços e a crescente complexidade da execução de software. Neste artigo, examinaremos como o problema do desenvolvimento de software evoluiu com esta mudança de paradigma.

Ciclo de Desenvolvimento

Vamos começar com o conceito de ciclo de desenvolvimento e o seu papel nos fluxos de trabalho de desenvolvimento. O ciclo de desenvolvimento para qualquer projeto de software consiste em dois ciclos separados que se intersetam através do Git.

São eles -

• Ciclo de desenvolvimento interno - O processo envolve escrever, compilar e testar um pedaço de código na própria estação de trabalho de um desenvolvedor. Este ciclo continua até que um pedaço de código satisfatório seja movido para o Git.
• Ciclo de desenvolvimento externo - Este ciclo é acionado depois que o código é movido da estação de trabalho do desenvolvedor para o Git. Envolve a execução de testes e a implantação do produto final. Idealmente, este processo deve ser configurado como um ciclo contínuo, onde as implantações ocorrem a cada 'push' de código que passa nos testes.

Estes ciclos alimentam-se mutuamente e formam um ciclo de vida completo de desenvolvimento de software.

A Ascensão dos Microsserviços

O advento dos microsserviços trouxe componentes de software pequenos, independentes e fracamente acoplados que oferecem melhor escalabilidade e fiabilidade. Não discutiremos as vantagens aqui, pois já foram muito bem divulgadas, mas as nossas preocupações surgem da consequente complexidade operacional acrescida.

Consideremos uma configuração simples onde o frontend chama a API, que por sua vez comunica com outros dois serviços chamados identity e db. Neste cenário, nosso desenvolvedor trabalha na api camada, que possui dependências tanto a jusante (frontend) quanto a montante (identity, db). Vamos explorar como o processo de desenvolvimento para o api serviço muda nos dois diferentes ciclos de desenvolvimento  -

Ciclo de desenvolvimento interno

• Acesso a dependências a montante - api serviço precisa se comunicar com os serviços de identity e db para funcionar com sucesso.
• Acesso a dependências a jusante - Para testar se as alterações feitas no api serviço são compatíveis com suas dependências a jusante, também é importante  redirecionar as requisições a jusante para este serviço.

Ciclo de desenvolvimento externo

• Dependências a montante - Para que um teste e2e seja executado para o api serviço, é necessário ter acesso a uma cópia em execução de identity e db serviços
• Dependências a jusante - Há também a necessidade de uma forma de permitir que o frontend acesse este serviço para fins de teste.
• Endpoint hospedado - Além dos requisitos mencionados acima, também precisamos hospedar esta cópia do api serviço para que possa ser testado diretamente

O problema do ciclo de desenvolvimento interno é algo que a Telepresence da Ambassador Labs resolveu. Tentamos resolver o problema do ciclo de desenvolvimento externo na plataforma TrueFoundry por meio de Intercepts.

Apresentando os Intercepts do TrueFoundry

O conceito dos Intercepts do TrueFoundry funciona resolvendo os três problemas do ciclo de desenvolvimento externo descritos nas seções anteriores. Seguimos a seguinte estratégia para abordar isso -

• URLs de pré-visualização - Usando a própria plataforma, é fácil implantar uma cópia de um serviço existente em um SHA de commit específico. Isso permite criar URLs de pré-visualização dedicadas a um commit ou pull request específico.
• Interceptações por cabeçalho - As interceptações permitem que um serviço continue a usar a mesma URL enquanto adiciona um cabeçalho adicional que redireciona para a cópia de pré-visualização. Por exemplo, podemos anexar uma interceptação ao api serviço que redireciona para uma cópia de pré-visualização com base num cabeçalho que lhe é passado. Isso significa frontend pode continuar a trabalhar com a mesma URL apenas passando um cabeçalho adicional durante os testes.

💡

Para saber mais sobre as interceptações do TrueFoundry, consulte a nossa documentação - https://docs.truefoundry.com/docs/intercepts

Conclusão

Discutimos as mudanças no fluxo de desenvolvimento que foram provocadas pelo advento dos microsserviços e como estamos a tentar abordá-las. Esta continua a ser uma questão em aberto, e podemos esperar soluções ainda mais inovadoras neste espaço no futuro.

Fale connosco

se procura maximizar os retornos dos seus projetos de LLM e capacitar o seu negócio para alavancar a IA da forma correta, gostaríamos de conversar e trocar ideias.

Tome um ☕️ connosco

Saiba como o TrueFoundry o ajuda a implementar LLMs em 5 minutos:

Deploy and Fine-tune Open Source LLMs With a Few Clicks!

TrueFoundry offers an intuitive solution for LLM deployment and fine-tuning. With our Model Catalogue, companies can self-host LLMs on Kubernetes, reducing inference costs by 10x in just one click. Discover how to deploy a Dolly-v2-3b model and fine-tune a Pythia-70m using TrueFoundry in our blog.

TrueFoundry Blog Truefoundry