Endereço original: https://www.aniszczyk.org/2021/01/19/cloud-native-predictions-for-2021-and-beyond/
O conteúdo deste artigo foi traduzido do blog pessoal de Chris Aniszczyk
Espero que todos estejam tendo ótimas férias, porque as primeiras semanas de janeiro de 2021 foram muito loucas, de tumultos a novas cepas de COVID. No espaço nativo da nuvem, o CNCF divulgou recentemente seu relatório anual sobre todo o trabalho que realizamos no ano passado. Encorajo todos a aproveitar esta oportunidade para ler o relatório, tivemos um ano sólido devido à situação de pandemia.
https://twitter.com/CloudNativeFdn/status/1343914259177222145
Como parte do meu trabalho, tenho uma certa vantagem sobre as tendências nativas da nuvem para todas as empresas e desenvolvedores membros com quem trabalho, então acho que tenho minha própria visão sobre para onde as coisas estão indo em 2021 e além:
foto
Cloud Native IDE (ambiente de desenvolvimento integrado)
Como alguém que trabalha com ferramentas de desenvolvimento na Eclipse Foundation, estou muito entusiasmado com os avanços tecnológicos mais recentes. No futuro, o ciclo de vida de desenvolvimento (código, compilação, depuração) ocorrerá principalmente na nuvem, em vez de uma configuração local do Emacs ou do VSCode. Você terminará com uma configuração completa do ambiente de desenvolvimento para cada solicitação pull, pré-configurada e conectada em sua própria implantação para ajudá-lo no desenvolvimento e na depuração. Exemplos concretos dessa tecnologia são ativados hoje por meio do GitHub Codespaces e do GitPod. Embora o GitHub Codespaces ainda esteja na versão beta, você ainda pode usar o GitPod usando o Prometheus como exemplo para experimentá-lo. Em cerca de um minuto, você terá um ambiente de desenvolvimento totalmente ativo com um editor e um ambiente de visualização. Melhor ainda, esse ambiente de desenvolvimento (espaço de trabalho) é descrito em código e pode ser compartilhado com outros desenvolvedores da equipe como qualquer outro artefato de código.
Por fim, espero ver uma inovação incrível no espaço IDE nativo da nuvem no próximo ano, especialmente quando o GitHub Codespaces entrar na versão beta e se tornar mais amplamente disponível, para que os desenvolvedores possam experimentar esse novo conceito e se apaixonar por ele.
Aplicação de Kubernetes em edge computing
O Kubernetes nasceu do uso em grandes data centers, mas o Kubernetes evoluirá como o Linux em novos ambientes. O que aconteceu com o Linux foi que os usuários finais acabaram estendendo o kernel para oferecer suporte a novos cenários de implantação, como móvel, incorporado e muito mais. Acredito firmemente que o Kubernetes passará por uma evolução semelhante, já testemunhamos empresas de telecomunicações (e startups) explorando o Kubernetes como uma plataforma de ponta, convertendo VNFs em Cloud Native Network Functions (CNF) e projetos de código aberto como k3s, KubeEdge, k0s, Aplicativos LFEdge, Eclipse ioFog. As forças que impulsionam o suporte à nuvem em hiperescala para empresas de telecomunicações e computação de ponta, combinadas com a capacidade de reutilizar software nativo da nuvem com base em um grande ecossistema já existente, farão do Kubernetes a plataforma dominante para computação de borda nos próximos anos.
Nativo da nuvem + Wasm
O Web Assembly (Wasm) é uma tecnologia emergente, mas espero que se torne um utilitário e carga de trabalho crescente no ecossistema nativo da nuvem, especialmente à medida que o WASI amadurece e o Kubernetes é mais usado para orquestração de borda como dispositivo mencionado. Um caso de uso é fortalecer mecanismos de extensão, como o que o Envoy faz com filtros e LuaJIT. Em vez de lidar diretamente com Lua, você pode usar um tempo de execução otimizado menor que suporte várias linguagens de programação. Atualmente, o projeto Envoy está adotando o Wasm, as linguagens de script são um mecanismo de extensão popular em qualquer ambiente e serão substituídas pelo Wasm no futuro, e espero que um modelo semelhante possa ser adotado em qualquer ambiente.
Do lado do Kubernetes, há projetos como o Krustlet da Microsoft que estão explorando como oferecer suporte a tempos de execução baseados em WASI no Kubernetes. Isso não é surpreendente, pois o Kubernetes foi estendido com CRDs e outros mecanismos para executar diferentes tipos de cargas de trabalho, como VMs (KubeVirt) etc.
Além disso, se você é novo no Wasm, recomendo que faça este novo curso introdutório da The Linux Foundation e sua excelente documentação.
A ascensão do FinOps (CFM)
O surto de coronavírus acelerou a mudança para a nuvem nativa. Pelo menos metade das empresas está acelerando seus planos de nuvem em meio à crise... quase 60% dos entrevistados disseram que o uso da nuvem excederá os planos anteriores devido à pandemia de COVID-19 (relatório State of the Cloud 2020). Além disso, o gerenciamento financeiro da nuvem (ou FinOps) é uma preocupação crescente para muitas empresas, com cerca de metade das discussões nos últimos seis meses envolvendo empresas que se deslocam para o espaço nativo da nuvem, e esse é honestamente o caso. Você também pode argumentar que os provedores de nuvem não são incentivados a facilitar o gerenciamento financeiro da nuvem porque tornaria mais fácil para os clientes gastarem menos. custos diferentes). No ambiente CNCF, não há muitos projetos de código aberto tentando simplificar o FinOps, existe o projeto KubeCost, mas ainda é cedo.
Além disso, a Linux Foundation iniciou recentemente a "FinOps Foundation" para ajudar a inovar nessa área, e eles têm um ótimo material introdutório nessa área. Espero ver mais projetos e normas de código aberto no espaço FinOps nos próximos anos.
Mais uso de Rust na nuvem nativa
Rust ainda é uma linguagem de programação emergente e de nicho, especialmente se as classificações de linguagens de programação da Redmonk forem um exemplo. No entanto, sinto que você verá o Rust em mais projetos nativos de nuvem no próximo ano, visto que já existem alguns projetos CNCF aproveitando o Rust em projetos de infraestrutura interessantes como microvm Firecracker. Embora o CNCF atualmente tenha a grande maioria dos projetos escritos em Golang, espero que os projetos baseados em Rust estejam no mesmo nível dos projetos baseados em Go dentro de alguns anos, à medida que a comunidade Rust amadurece.
Crescimento significativo em GitOps + CD/PD
GitOps é um modelo de entrega para tecnologias nativas de nuvem que fornece um conjunto de práticas recomendadas para unificar a implantação, o gerenciamento e o monitoramento de aplicativos (originalmente cunhado pelo luminar da Weaveworks, Alexis Richardson). O aspecto mais importante do GitOps é descrever declarativamente o estado desejado do sistema, que é versionado no Git declarativamente, o que essencialmente permite que um conjunto complexo de sistemas seja corretamente aplicado, corrigido e depois verificado (via Git e bons logs de auditoria ativados por outras ferramentas). Do ponto de vista pragmático, o GitOps melhora a experiência do desenvolvedor e, com o crescimento de projetos como Argo, GitLab e Flux, espero que as ferramentas GitOps tenham um impacto maior na empresa este ano. Se você observar os dados do GitLab, o GitOps ainda é algo incipiente que a maioria das empresas ainda não explorou, mas à medida que mais e mais empresas começam a adotar software nativo da nuvem em escala, acho que o GitOps seguirá naturalmente. Se você estiver interessado em aprender mais sobre este espaço, recomendo verificar o recém-formado grupo de trabalho GitOps no CNCF.
Catálogo de serviços 2.0: painel do desenvolvedor nativo da nuvem
O conceito de catálogo de serviços não é novidade e, para alguns de vocês que cresceram na era ITIL, podem 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 vários metadados de serviço em tempo real é fundamental para impulsionar 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 etc.
No futuro, você verá uma tendência de painéis de desenvolvedor que não são apenas um catálogo de serviços, mas também a capacidade de estender o painel em um só lugar com várias automações. Exemplos canônicos de código aberto são Backstage e Clutch da Lyft, no entanto, qualquer empresa com uma implantação nativa em nuvem razoavelmente moderna tende a ter uma equipe de infraestrutura de plataforma tentando construir algo assim. À medida que os painéis do desenvolvedor de código aberto e o grande ecossistema de plug-ins amadurecem, você verá uma adoção acelerada por equipes de engenharia de plataforma em todos os lugares.
Atingindo a Realidade Através das Nuvens
Kubernetes e Cloud Native Dynamics mostra que uma abordagem nativa da nuvem e uma abordagem multi-nuvem podem ser usadas em ambientes de produção, e os dados mostram claramente: "93% das empresas têm uma estratégia para usar vários provedores, como Microsoft Azure, Amazon Web Services , e Google Cloud" (Relatório State of the Cloud de 2020). Espera-se que o fato de o Kubernetes ter amadurecido com o mercado de nuvem desbloqueie os serviços programáticos de hospedagem entre nuvens. Um exemplo concreto dessa abordagem está incorporado no projeto Crossplane, que fornece um plano de controle entre nuvens de código aberto que aproveita a extensibilidade da API do Kubernetes para gerenciamento de carga de trabalho entre nuvens (consulte "GitLab Deploying a Cross-Plane Control Plane" ) para fornecer implantação em várias nuvens").
eBPF convencional
O eBPF permite que você execute programas no kernel do Linux sem alterar o código do kernel ou carregar módulos, você pode pensar nisso como um mecanismo de extensão em área restrita. O eBPF permite que uma nova geração de software estenda o comportamento do kernel do Linux para oferecer suporte a uma variedade de coisas diferentes, incluindo redes, monitoramento e segurança aprimorados. Historicamente, o eBPF teve a desvantagem de exigir uma versão moderna do kernel para aproveitá-lo e, por muito tempo, essa não era uma opção realista para muitas empresas. No entanto, as coisas estão mudando e versões ainda mais recentes do RHEL estão finalmente suportando o eBPF, então você verá mais projetos aproveitando isso. Se você observar o relatório de contêiner mais recente do Sysdig, verá que a adoção do Falco aumentou recentemente e, embora o relatório possa ser distorcido do Sysdig, isso se reflete no uso da produção. Portanto, fique atento e procure mais projetos baseados em eBPF no futuro!
Enfim, feliz 2021!
Tenho algumas outras previsões e tendências para compartilhar, especialmente em torno de código aberto direcionado ao usuário final, canibalização/padronização de malha de serviço, Prometheus + OTel, KYC para proteger cadeias de suprimentos de software e muito mais, mas vou economizar para um post mais detalhado, nove previsões são suficientes para começar o novo ano! De qualquer forma, obrigado por ler, espero ver todos vocês no KubeCon + CloudNativeCon EU em maio de 2021, as inscrições estão abertas!
Pesquise por "software de topologia" na conta pública para ver mais~