Previsões para o Cloud Native em 2021 e além

NCF recentemente lançou seu relatório anual com todo o trabalho realizado ao longo de 2020. Recomendo a leitura do material, tivemos um ano sólido em função da pandemia. Como parte do meu trabalho, tenho uma visão única e privilegiada das tendências de cloud native - visto todas as empresas e desenvolvedores com os quais lido diariamente. Então, decidi compartilhar meus pensamentos sobre para onde as coisas irão em 2021 e além.

IDEs Cloud Native

Como uma pessoa que passou uma boa parte de sua carreira trabalhando com ferramentas de desenvolvimento dentro da Eclipse Foundation, estou muito entusiasmado com o recente progresso das coisas. O futuro vai garantir que o ciclo de vida de desenvolvimento (código, construção, depuração) aconteça principalmente na nuvem - em comparação com a configuração local do Emacs ou VSCode. Você acabará obtendo uma configuração de ambiente de desenvolvimento completa para cada pull request, pré-configurada e conectada à sua própria implantação para auxiliar no seu desenvolvimento e nas necessidades de depuração. Um exemplo concreto dessa tecnologia hoje é habilitado via GitHub Codespaces e GitPod. Embora o GitHub Codespaces ainda esteja em versão beta, você pode ter essa experiência ao vivo com o GitPod, usando o Prometheus por exemplo. Em cerca de um minuto você tem um ambiente de desenvolvimento completo com um editor e um ambiente de pré-visualização. O mais interessante é que esse ambiente de desenvolvimento (espaço de trabalho) é descrito em código e pode ser compartilhado com outros desenvolvedores de sua equipe como se fosse um código comum.

Enfim, espero ver uma inovação incrível no espaço IDE cloud native no próximo ano, especialmente quando o GitHub Codespaces se tornar disponível de forma mais ampla, para que os desenvolvedores possam experimentar este novo conceito e se apaixonar.

Kubernetes no Edge

O Kubernetes nasceu por meio de sua utilização em massa em grandes data centers, mas ele evoluirá - assim como Linux o fez - para novos ambientes. O que aconteceu com o Linux foi que os usuários finais eventualmente estenderam o kernel para oferecer suporte a uma variedade de novos cenários de implantação de dispositivos móveis, embarcados e muito mais. Acredito fortemente que o Kubernetes passará por uma evolução semelhante e já estamos testemunhando empresas de telecomunicações (e startups) explorando o Kubernetes como uma plataforma de ponta por meio da transformação de VNFs em Cloud Native Network Functions (CNFs) junto com projetos de código aberto como o k3s, KubeEdge, k0s, LFEdge, Eclipse ioFog e muito mais. As forças que impulsionam as nuvens hyperscaler para oferecer suporte a telecomunicações e ao edge, combinadas com a capacidade de reutilizar o software nativo da nuvem e construir em cima de um grande ecossistema, consolidarão o Kubernetes como uma plataforma dominante em computação edge nos próximos anos.

Cloud Native + Wasm

O Web Assembly (Wasm) é uma tecnologia em estado inicial, mas espero que se torne um utilitário e carga de trabalho em expansão no ecossistema cloud native, especialmente à medida que o WASI amadurece e o Kubernetes é mais usado como um orquestrador de ponta, conforme descrito anteriormente. Um caso de uso é alimentar um mecanismo de extensão, como o que o Envoy faz com filtros e LuaJIT. Ao invés de lidar com Lua diretamente, você pode trabalhar com um tempo de execução otimizado menor que suporta uma variedade de linguagens de programação. O projeto Envoy está atualmente em sua jornada para adoção do Wasm e espero que um padrão semelhante siga para qualquer ambiente em que as linguagens de script sejam um mecanismo de extensão popular a ser substituído em massa pelo Wasm no futuro.

Na frente Kubernetes, há projetos como o Krustlet da Microsoft que estão explorando como um tempo de execução baseado em WASI pode ser compatível com o Kubernetes. Isso não deve ser muito surpreendente, pois o Kubernetes já está sendo estendido por meio de CRDs e outros mecanismos para executar diferentes tipos de cargas de trabalho, como VMs (KubeVirt) e muito mais.

Além disso, se você é novo no Wasm, recomendo este novo curso de introdução da Linux Foundation que vai além das expectativas, junto a sua excelente documentação.

Ascensão do FinOps (CFM)

O surto de coronavírus acelerou a mudança para o cloud native. Pelo menos metade das empresas está acelerando seus planos de nuvem em meio à crise... quase 60% dos entrevistados disseram que o uso da nuvem ultrapassaria os planos anteriores devido à pandemia da COVID-19 (Relatório do Estado da Nuvem 2020). Além disso, Cloud Financial Management (ou FinOps) é um problema e preocupação crescente para muitas empresas e, honestamente, surge em cerca de metade das minhas discussões nos últimos 6 meses com empresas navegando em sua jornada cloud native. Você também pode argumentar que os provedores de nuvem não são incentivados a tornar o gerenciamento financeiro da nuvem mais fácil, pois isso tornaria mais fácil também para os clientes gastarem menos, no entanto, a verdadeira dor é a falta de inovação de código aberto e padronização em torno do gerenciamento financeiro da nuvem, na minha opinião (todas as nuvens fazem o gerenciamento de custos de maneira diferente). No contexto CNCF, não há muitos projetos de código aberto tentando tornar o FinOps mais fácil, há o projeto KubeCost, mas ainda está em sua fase inicial.

Além disso, a Linux Foundation lançou recentemente a “FinOps Foundation” para ajudar na inovação neste espaço, eles têm alguns materiais introdutórios excelentes. Espero ver muito mais projetos e especificações de código aberto no espaço do FinOps nos próximos anos.

Mais Rust em Cloud Native

Rust ainda é uma linguagem de programação jovem e de nicho, especialmente se você olhar as classificações de linguagem de programação do Redmonk, por exemplo. No entanto, minha sensação é que você verá o Rust em mais projetos nativos da nuvem no próximo ano, visto que já existem vários projetos CNCF fazendo uso de Rust, surgindo em projetos de infraestrutura interessantes como monitor de máquina virtual (VMM) Firecracker. Embora o CNCF tenha atualmente uma maioria de projetos escritos em Golang, espero que os projetos baseados em Rust estejam no mesmo nível dos baseados em Go em alguns anos, conforme a comunidade Rust for amadurecendo.

GitOps + CD / PD cresce significativamente

GitOps é um modelo operacional para tecnologias nativas em nuvem, fornecendo um conjunto de melhores práticas que unificam a implantação, gerenciamento e monitoramento de aplicativos (originalmente cunhado por Alexis Richardson da famosa Weaveworks). O aspecto mais importante do GitOps é descrever o estado do sistema desejado com versão no Git por meio de uma forma de declaração, que essencialmente permite que um conjunto complexo de alterações do sistema seja aplicado corretamente e, em seguida, verificado (por meio de um bom log de auditoria habilitado via Git e outras ferramentas). De um ponto de vista pragmático, GitOps melhora a experiência do desenvolvedor e com o crescimento de projetos como Argo, GitLab, Flux e assim por diante, espero que as ferramentas GitOps alcancem mais o nível empresarial este ano. Se você olhar os dados do GitLab, o GitOps ainda é uma prática iniciante, a maioria das empresas ainda não o explorou, mas à medida que mais empresas mudam para adoção do software cloud native em escala, o GitOps vai naturalmente seguir este caminho, na minha opinião. Se você estiver interessado em aprender mais sobre este espaço, recomendo verificar o recém-formado Grupo de Trabalho GitOps no CNCF.

Catálogos de serviços 2.0: painéis nativos do desenvolvedor na nuvem

O conceito de um catálogo de serviços não é uma coisa nova, para alguns de nós, pessoas mais velhas que cresceram na era ITIL, você pode se lembrar de coisas como CMDBs (o horror). No entanto, com o aumento dos microsserviços e do desenvolvimento nativo da nuvem, a capacidade de catalogar serviços e indexar uma variedade de metadados de serviço em tempo real é fundamental para conduzir a automação do desenvolvedor. Isso pode incluir o uso de um catálogo de serviços para entender a propriedade, para lidar com o gerenciamento de incidentes, gerenciar SLOs e muito mais.

No futuro, você verá uma tendência para os painéis do desenvolvedor que não são apenas um catálogo de serviços, mas fornecem a capacidade de estender o painel por meio de uma variedade de recursos de automação em um só lugar. Os exemplos canônicos de código aberto disso são Backstage e Clutch da Lyft. No entanto, qualquer empresa com uma implantação cloud native bastante moderna tende a ter uma equipe de infraestrutura de plataforma que tentou construir algo semelhante. Conforme os painéis do desenvolvedor de código aberto amadurecem com um grande ecossistema de plugins, você verá uma adoção acelerada por equipes de engenharia de plataforma em todos os lugares.

Cross Cloud torna-se mais real

O Kubernetes e o movimento cloud native demonstraram que as abordagens nativas da nuvem e de várias nuvens são possíveis em ambientes de produção. Os dados são claros “93% das empresas têm uma estratégia para usar vários provedores como Microsoft Azure, Amazon Web Services e Google Cloud” (Relatório sobre o estado do Cloud 2020). Em função do Kubernetes ter amadurecido ao longo dos anos junto com o mercado de nuvem, esperamos desbloquear serviços programáticos gerenciados entre nuvens. Um exemplo concreto dessa abordagem é incorporado ao projeto Crossplane que fornece um plano de controle de nuvem cruzada de código aberto, aproveitando a extensibilidade da API Kubernetes para permitir o gerenciamento de carga de trabalho de nuvem cruzada (consulte “GitLab implanta o plano de controle cruzado para oferecer implantações multicloud”).

O convencional eBPF

O eBPF permite que você execute programas no kernel do Linux sem alterar o código do kernel ou carregar um módulo, você pode pensar nisso como um mecanismo de extensão em área restrita. O eBPF permitiu que uma nova geração de software estendesse o comportamento do kernel do Linux para suportar uma variedade de coisas diferentes, desde redes aprimoradas, monitoramento e segurança. A desvantagem do eBPF historicamente é que ele requer uma versão moderna do kernel para utilizá-lo e, por um longo tempo, isso simplesmente não era uma opção realista para muitas empresas. No entanto, as coisas estão mudando e as versões mais recentes do RHEL finalmente suportam o eBPF - então você verá mais projetos com ele. Se olhar o último relatório de container da Sysdig, verá a adoção do Falco com um aumento recente considerável (embora o relatório possa ser um pouco tendencioso ao Sysdig), isso se reflete no uso da produção. Portanto, fique atento e procure mais projetos baseados no eBPF!

Por fim, feliz 2021!

Tenho mais algumas previsões e tendências para compartilhar, especialmente sobre código aberto direcionado ao usuário final, canibalização/padronização de malha de serviço, Prometheus + OTel, KYC para proteger a cadeia de suprimentos de software e muito mais, mas vou guardar isso para postagens mais detalhadas, nove previsões são o suficiente para começar o ano!

Traduzido e adaptado do Blog CNCF, texto de ANISZCZYK, Chris. Disponível em: <https://www.cncf.io/blog/2021/01/29/cloud-native-predictions-for-2021-and-beyond/>. Acesso em 06 de Fev. 2021.