Avançar para o conteúdo principal
BlogueLinodeSua estratégia de desenvolvimento na nuvem está errada?

A sua estratégia de desenvolvimento na nuvem está errada?

A sua estratégia de desenvolvimento na nuvem está errada? Imagem em destaque no cabeçalho da publicação do blogue.

Comecei a minha carreira há 20 anos como engenheiro de software. Muitos de nós - e sei que não sou o único - testemunharam o crescimento sem precedentes da nuvem pública e continuam a fazê-lo actualmente.

Há fornecedores de serviços em nuvem que têm uma visão opinativa sobre a forma como se deve construir com eles. Chamamos essa abordagem de plataforma nativa. Eles querem que você construa de uma forma que use seus serviços e suas ferramentas, tudo dentro de seu ecossistema. Mas os provedores de nuvem não devem ditar como você constrói e implanta. Em vez disso, as suas cargas de trabalho devem ser portáteis, utilizando ferramentas abertas e baseadas em normas que lhe permitam implementá-las e movê-las para onde quer que faça sentido encontrar a melhor localização geográfica, preço ou desempenho para a sua carga de trabalho.

O actual percurso de compra do programador

Já cometi erros ao seleccionar o fornecedor de serviços de computação em nuvem adequado. Muitos de nós cometemos. Mas estas experiências - boas e más - permitiram-me ver padrões no processo de selecção. E descobri cinco etapas na jornada de compra da nuvem de um desenvolvedor.

1. Descobrir. Quer se ouça falar de algo novo num evento, enquanto se lê o Stack Overflow ou um tópico do Reddit, se vê o YouTube, ou onde quer que seja, um serviço de nuvem despertará o seu interesse porque nunca ouviu falar dele antes. E, de repente, você pensa: O que é isso? Como é que isto se aplica a mim? Como é que me pode ajudar?

Há muitas outras perguntas a fazer durante a descoberta. O seu objectivo deve ser obter respostas sobre o que torna uma oferta de nuvem única, o que a diferencia de algo perceptivelmente semelhante e a proposta de valor específica que lhe apresenta. Quer se trate de um compromisso de serviço ou de outra coisa qualquer, é aqui que se pergunta "Porquê?".

2. Avaliação. Nesta fase, já ultrapassámos as dúvidas e temos quase a certeza de que existe algo aqui. É agora altura de nos empenharmos e avaliarmos o que descobrimos. Não planeie um grande compromisso de tempo. Normalmente, são necessários apenas 15 a 20 minutos para mergulhar na documentação. Mas terá de mergulhar mais fundo para compreender o serviço ou a ferramenta e avaliar quaisquer diferenças em relação ao que já sabe.

Embora seja útil compreender exactamente quais os serviços que está a avaliar, não se preocupe se o seu conhecimento de outros fornecedores de serviços cloud for um pouco limitado. Por exemplo, veja nossa oferta gerenciada de Kubernetes. Se você estiver familiarizado com as ofertas da concorrência, poderá fazer algumas comparações entre elas e o Linode Kubernetes Engine.

Eis um excerto de um caso de utilização de avaliação de Elliot Graebert, Director de Engenharia do fabricante de drones Skydio.

"As interfaces são bastante idênticas, o que torna impossível declarar uma melhor. O seu design é nítido e limpo, sem o excesso de funcionalidades predominante em AWS e no Azure. Na minha opinião, esta simplicidade ajuda-o muito a entrar, a implementar a sua aplicação e a voltar a escrever código." Ele acrescenta: "A incrível velocidade da Linode para inicializar novos clusters k8s atrairá alguns públicos, e seu tempo geral de implantação de nós foi sólido."

3. Aprender. Agora estamos prontos para passar à etapa mais importante. E a razão é que, durante a fase de avaliação, vai investir algum tempo, mas é nesta fase que vai investir a maior parte do seu tempo. Como programadores, temos um milhão de projectos a passar pela nossa cabeça. Agora, estamos a passar por um exercício de adaptação para ver se esta oferta de nuvem vale a pena. Prepare-se para investir horas em aprendizagem. A maior questão a responder é: Este fornecedor de serviços na nuvem e a sua solução funcionarão para o meu próximo projecto?

4. Construir. Que engenheiro não gosta de pôr as mãos num teclado? Mas é neste passo que muitas vezes as coisas correm mal. Condicionamo-nos a construir MVPs (produtos mínimos viáveis) quando na verdade precisamos de construir MLPs, "produtos mínimos adoráveis".

Os MVP são o mínimo indispensável, e não é necessário gostar deles. De todos os MVPs que criei ao longo da minha carreira, não consigo citar nenhum que fosse adequado para produção. Actualmente, na minha função, adoro mostrar aos programadores como criar um MVP. O resultado é algo que eles podem avaliar honestamente se o esforço que fizeram para o construir valeu ou não a pena.

5. Escala. São muitas as perguntas que irá fazer nesta fase. Ao compreender a escala, vai querer saber como tirar partido de várias regiões, seja para replicar dados de um ponto para outro para recuperação de desastres ou apenas para existir em mais do que uma região. Pense na escala não só numa perspectiva de processo, mas também numa perspectiva de pessoal. Se precisar de injectar mais pessoas neste processo, o que é que isso significa? 

Você também vai querer entender o processo de integração. Seja através de um CLI ou API, descubra o que está disponível que pode ajudá-lo a automatizar. Estamos nesta onda de automação com a Infraestrutura como código (IAC) liderando o caminho. Estamos fazendo mais com menos porque sabemos que os processos são escalonáveis e as pessoas não. Avalie o esforço necessário para manter a infraestrutura e escalar.

Plataforma nativa versus nuvem nativa

A escolha da nuvem continuará a ser uma viagem evolutiva. Temos de começar a olhar para ela de forma mais objectiva. Quando me aventurei pela primeira vez na nuvem, construí exclusivamente com essas plataformas e ferramentas. Toda a literatura técnica disponível na altura era sobre uma determinada plataforma. Mas à medida que cresci como engenheiro, comecei a construir de uma forma nativa na nuvem, onde podia pegar na minha carga de trabalho e movê-la para qualquer lugar, dando-me mais controlo sobre as coisas que construía. E fiz isso com a ajuda de ferramentas de código aberto, o que me permitiu adotar padrões unificados, como CI/CD, IaC e conteinerização

Se tudo isto se alinha com a sua forma de pensar e pretende construir desta forma nativa da nuvem, gostaríamos de falar consigo. Entre em contacto comigo ou com qualquer membro da equipa para discutir o seu percurso de compra na nuvem.

Comentários

Deixe uma resposta

O seu endereço de correio electrónico não será publicado. Os campos obrigatórios estão marcados com *