Kubernetes, redes e como encontrar o VMware do Cloud Native

Thomas Graf é cofundador e CTO da Isovalentee criador de uma popular tecnologia de rede de código aberto (e nativa da nuvem) chamada Cílio. Cilium é construído sobre uma tecnologia Linux em nível de kernel chamada eGMP.

Nesta entrevista, Graf discute as funções que Cilium e eBPF desempenham no crescente ecossistema de redes nativas da nuvem, bem como algumas tendências mais amplas em torno da adoção e evolução do Kubernetes. Ele explica quem está usando e comprando Kubernetes em grandes empresas, onde a infraestrutura nativa da nuvem ainda precisa melhorar e como o desejo de padronização está impulsionando a inovação.

---

FUTURO: Como devemos pensar sobre eBPF e Cilium no contexto da computação e redes, em geral, e depois especificamente no contexto do ecossistema nativo da nuvem?

THOMAS GRAF: No geral, eBPF é a tecnologia e é de nível extremamente baixo. Ele foi projetado para desenvolvedores de kernel, e minha experiência é em desenvolvimento de kernel. eBPF está para o kernel, para o sistema operacional, o que o JavaScript está para um navegador. Torna o sistema operacional programável assim como o JavaScript torna o navegador programável. No passado, tínhamos que atualizar as versões de nossos navegadores para realmente usar determinados sites. E então veio o JavaScript e, de repente, as equipes de aplicativos e os desenvolvedores puderam criar aplicativos massivos – a ponto de o aplicativo de processamento de texto mais popular ser substituído por um aplicativo no navegador. Isso levou a uma enorme onda de inovação. 

O mesmo está acontecendo com o eBPF, embora no nível do sistema operacional, porque de repente podemos fazer coisas no nível do kernel ou do sistema operacional onde vemos tudo e controlamos tudo — o que é muito importante para a segurança — sem ter que mudar o kernel Código fonte. Podemos essencialmente carregar programas no kernel para estender sua funcionalidade e trazer novos recursos com ele. Isso também desencadeou uma enorme onda de inovação. Hyperscalers como Facebook, Google e Netflix estão usando isso por conta própria, diretamente, com suas próprias equipes de kernel. 

O que Cilium traz para a mesa é que ele usa a tecnologia eBPF de baixo nível para fornecer essencialmente uma nova onda de infraestrutura de software, especialmente para a onda nativa da nuvem. Pense nisso como uma rede definida por software e o que Nicira, que se tornou VMware NSX, fez pela indústria de virtualização. Estamos fazendo o mesmo com a nuvem nativa, onde é uma combinação de provedor de nuvem ou infraestrutura de nuvem pública, bem como infraestrutura local. E estamos resolvendo casos de uso de rede, segurança e observabilidade na camada de infraestrutura.

E o Cilium Service Mesh, recém lançado, é uma evolução dessas capacidades?

O que está acontecendo atualmente, há cerca de um ano, é que os dois espaços estão colidindo. O que a Cilium tem feito até agora é focado em redes, redes virtualizadas e, em seguida, redes nativas em nuvem – mas ainda assim em redes. Mas então, abordando a questão de cima para baixo, as equipes de aplicativos do Twitter e do Google estavam fazendo malha de serviço coisas - primeiro no aplicativo e depois no modelo baseado em sidecar, o modelo baseado em proxy, que é o que os projetos gostam Istio entregar. E agora estas duas camadas estão se aproximando porque as empresas tradicionais estão migrando para o mundo nativo da nuvem e têm requisitos de rede corporativa, mas suas equipes de aplicativos também desejam uma malha de serviço. 

O Gartner está chamando essa nova camada de “conectividade de serviço” – veremos se esse termo pega – mas é essencialmente uma camada que inclui a parte da rede corporativa e a parte da malha de serviço que vem das equipes de aplicativos. E porque é isso que os clientes exigem, adicionamos os recursos ao próprio Cilium. Então, essencialmente, o Cilium está subindo do lado da rede corporativa e as malhas de serviço estão descendo para o lado da rede.

Por que há tanto foco no nível de rede e malha de serviço da pilha do Kubernetes?

Porque com o desejo de executar em múltiplas nuvens e dividir os aplicativos em contêineres, a camada de conectividade tornou-se central. O que costumava ser talvez comunicação entre processos e middleware agora é a rede, portanto a rede está se tornando absolutamente essencial para que os aplicativos se comuniquem entre si e para que os dados fluam. 

E na nuvem nativa, em particular, multi-cloud está se tornando absolutamente essencial. Todos os provedores de nuvem têm suas próprias camadas de rede, mas, é claro, adaptadas às suas próprias nuvens. Eles têm ofertas locais, mas não são verdadeiramente multinuvem. Cilium e eBPF trazem para a mesa essa camada agnóstica e multinuvem. Ele se comporta exatamente da mesma forma no local e na nuvem pública. Vários provedores de nuvem pública estão usando o Cilium nos bastidores para suas ofertas gerenciadas de Kubernetes, e as empresas de telecomunicações estão usando-o para infraestrutura 5G local. Trata-se de falar as duas línguas e conectar esses mundos.

É por isso que há tanto foco nisso: porque uma das maneiras mais fáceis para os provedores de nuvem prenderem os clientes é possuir essa camada de conectividade. Acho que do ponto de vista da infraestrutura estratégica, assim como a camada de virtualização era fundamental, agora a camada de conectividade e rede é absolutamente fundamental.

A fonte de inovação [futura] será de código aberto, e os clientes e utilizadores que impulsionarão a procura serão empresas um nível abaixo dos hiperescaladores – empresas já de tamanho considerável que ainda são altamente disruptivas.

O Kubernetes é amplamente aceito e adotado neste momento, mas ainda se fala em alguns círculos de que ele é um exagero. Para quem você acha que o Kubernetes e o ecossistema nativo da nuvem em geral se destinam?

É para equipes de aplicativos modernas. Acho que percebeu-se que, se você deseja atrair equipes de aplicativos modernas e conseguir tempos de entrada no mercado rápidos, é necessário fornecer a elas uma infraestrutura nativa da nuvem. Muitas vezes vemos prototipagem – inicial, pré-MVP, até mesmo comprovação do conceito ou venda interna – sem servidor, algo como Lambda. E depois no Kubernetes, porque as equipes de aplicativos podem possuir a infraestrutura diretamente. E então, à medida que passa para a produção, eles vão para as distribuições corporativas e locais do Kubernetes. Mas, na verdade, essa é uma porção relativamente pequena de toda a infraestrutura, talvez uma porcentagem de um ou dois dígitos. 

No entanto, será claramente o novo padrão. Assim como a adoção da virtualização foi muito lenta inicialmente e as pessoas disseram que era um exagero – mas com o tempo, é claro, ela começou a substituir a maioria das coisas – veremos o mesmo aqui. Ou apenas como acontece com as línguas modernas. As pessoas diziam que Java era um exagero, e provavelmente ainda é para muitos aplicativos, mas houve um tempo em que se tornou muito difícil desenvolver qualquer aplicativo fora de Java porque era nisso que a maioria dos desenvolvedores de aplicativos conseguia escrever. Isso será verdade para as equipes de aplicativos modernas: elas esperam ter o Kubernetes por perto para se desenvolverem de forma mais ágil e trazerem o produto ao mercado rapidamente.

Do lado da infraestrutura, pode ser um pouco exagerado, mas se a alternativa for reescrever um aplicativo sem servidor para local, será uma tarefa enorme. Então o Kubernetes é o meio termo, o que é muito atraente. 

E a ideia de que o Kubernetes ainda precisa de uma melhor experiência de desenvolvedor?

Se olharmos para o OpenShift original, antes de ser baseado no Kubernetes, era isso. Ficou ainda mais próximo da equipe de aplicativos e proporcionou uma experiência ainda melhor para o desenvolvedor de aplicativos. Você poderia enviar para o Git e ele seria implantado automaticamente. Heroku também tentou isso, mas baseado em SaaS. 

O Kubernetes deu um passo para trás e disse: “Precisamos manter alguns aspectos operacionais nele e torná-lo um pouco mais próximo do que um administrador de sistema esperaria também. Não podemos estar apenas adaptados às aplicações.” É o meio-termo: ele precisa ter atratividade suficiente para as equipes de aplicativos, mas ainda precisa ser possível executar esse aplicativo fora de um ambiente específico e ser gerenciado por outras pessoas que não sejam desenvolvedores de aplicativos.

Eu diria que o maior passo entre o Docker e o Kubernetes foi que o Docker tinha tudo a ver com a experiência do desenvolvedor. Resolveu essa parte, mas não resolveu a parte do ecossistema de nuvem pública.

Como chegamos a este ponto? Essa foi a evolução natural da plataforma como serviço (PaaS) e dos contêineres de aplicativos?

Eram as imagens do Docker e o aspecto de empacotamento do Docker. A velha escola era como implantar em máquinas virtuais, e havia todo tipo de automação em torno disso. E havia o que o Facebook estava fazendo com o Tupperware – muito personalizado e em grande escala. E então o Docker apareceu e essencialmente forneceu essa imagem de contêiner e todos puderam tratá-la como uma VM em miniatura. Agora posso distribuir meu aplicativo e, em vez de uma imagem virtual de 600 MB, agora é um contêiner de 10 MB. Mas você pode tratá-lo da mesma forma, ele tem tudo que precisa. 

Isso desbloqueou a capacidade de trazer um orquestrador como o Kubernetes, que ainda permite tratar aplicativos como mini VMs, mas também dar um passo adiante e realmente tratá-los como microsserviços. Ele permite que você faça as duas coisas.

Eu diria que o maior passo entre o Docker e o Kubernetes foi que o Docker tinha tudo a ver com a experiência do desenvolvedor. Resolveu essa parte, mas não resolveu a parte do ecossistema de nuvem pública. Ela não tinha, nem necessariamente queria, uma integração estreita com os provedores de nuvem. Kubernetes resolveu isso. 

Quem você vê administrando o Kubernetes dentro das empresas? São equipes de aplicativos individuais?

Há uma mudança interessante que aconteceu com o nativo da nuvem, que é a ascensão da “equipe da plataforma”, como vou chamá-la. Eles não são engenheiros de aplicação. Eles têm um pouco de conhecimento de operações de rede e bastante conhecimento de segurança. Eles têm conhecimento de SRE e sabem como fazer automação em nuvem. Eles estão fornecendo a plataforma para equipes de aplicativos e tratando essas equipes de aplicativos como seus clientes.

As equipes de plataforma são quem compram Kubernetes e tecnologias relacionadas, que usam porque têm a tarefa de fornecer a infraestrutura de próxima geração para deixar felizes as equipes de aplicativos modernas.

Acho que definitivamente há espaço para o serverless, em particular para o desenvolvimento muito rápido de aplicativos. Mas nas empresas, estamos vendo a nuvem nativa como a nova camada sobre a virtualização

É um novo comprador ou uma equipe totalmente nova? Ou as equipes de plataforma são algo que existe dentro de lugares como Google ou Facebook e agora está se tornando popular?

Eles são principalmente uma equipe nova. Acho que eles são, até certo ponto, como as equipes de SRE do Google e do Facebook. No entanto, as equipes de aplicativos provavelmente possuem mais participação na implantação de aplicativos nas empresas, porque as empresas não têm essa distinção muito clara entre engenheiros de software e SREs como o Google e o Facebook fazem. Eu diria que essa evolução é muito semelhante à forma como você tinha equipes de virtualização e, em seguida, muitas operações de rede migraram de - ou evoluíram ou avançaram de - sendo sobre rede Hardwares ser sobre rede virtualização. E essas equipes, por exemplo, passaram a operar o VMware NSX. O mesmo está acontecendo aqui. 

Embora não seja necessariamente um novo orçamento. Vemos os orçamentos mudando de segurança e rede para esta equipe de plataforma, por exemplo, à medida que os gastos com nuvem aumentam e menos são gastos em hardware de rede. Eles geralmente operam com a equipe de segurança e com a equipe de operações de rede para obter adesão, mas na verdade possuem uma parcela bastante substancial do orçamento.

Como você vê o Fundação de computação nativa em nuvem evoluindo, e o Kubernetes sempre estará no centro disso – ou do movimento nativo da nuvem em geral?

O Kubernetes foi o que deu origem ao CNCF e, nos primeiros anos, tudo girava em torno do Kubernetes e da nuvem pública. O que vimos há cerca de um ano é que agora não se trata mais apenas de Kubernetes, mas sim de nativos da nuvem princípios. Na verdade, isso significa que não é mais necessariamente uma nuvem, nem mesmo uma nuvem privada. Muitas vezes, trata-se até mesmo de redes corporativas tradicionais, infraestrutura local enfadonha, servidores bare-metal e tudo mais, mas com os princípios nativos da nuvem integrados. 

A nova norma agora é híbrida e inclui vários provedores de nuvem pública, bem como infraestrutura local. As empresas desejam fornecer a mesma agilidade ao desenvolvedor de aplicativos, ou fornecer observabilidade com ferramentas modernas nativas da nuvem, ou fazer segurança com ferramentas modernas nativas da nuvem – por exemplo, autenticação, em vez de apenas segmentação ou aplicação baseada em identidade – todos esses novos conceitos nativos da nuvem em infraestrutura existente. 

Estamos vendo uma demanda muito forte para ainda se conectar ao velho mundo e falar sobre MPLS, VLAN, sFlow e NetFlow – todo o conjunto existente de requisitos empresariais. Nenhum deles foi embora.

Cerca de uma década depois, o espaço nativo da nuvem não parece ser uma moda passageira. Quanto espaço existe para continuar evoluindo?

Definitivamente houve um tempo em que pensei: “Oh, o Kubernetes provavelmente terá vida curta e o serverless será a próxima camada”. Ou “Kubernetes é semelhante ao OpenStack. Ou “Vai desaparecer e será um detalhe de implementação”. E isso não aconteceu. 

Acho que definitivamente há espaço para o serverless, em particular para o desenvolvimento muito rápido de aplicativos. Mas nas empresas, estamos vendo a nuvem nativa como a nova camada sobre a virtualização e acreditamos que ela tenha uma vida útil semelhante à da virtualização. O que significa que estamos bem no início da migração nativa para nuvem.

Que grandes problemas ainda precisam ser resolvidos ao nível da infra-estrutura?

Vemos empresas numa situação em que, de repente, quer queiram ou não, necessitam de uma estratégia multinuvem. Como também possuem infraestrutura local, agora precisam de uma estratégia de nuvem híbrida além disso. E eles precisam descobrir como executar a segurança e outras funções universalmente em toda essa infraestrutura, sem ficarem presos a uma nuvem pública específica. 

Portanto, este é o próximo grande desafio: quem será a camada agnóstica para multinuvem e nativa da nuvem, como o que o VMware se tornou? Quem será o VMware nativo da nuvem?

Acho que percebeu-se que, se você deseja atrair equipes de aplicativos modernas e conseguir tempos de entrada no mercado rápidos, é necessário fornecer a elas uma infraestrutura nativa da nuvem.

E embora a adoção nativa da nuvem possa ter sido relativamente fácil para as empresas modernas da web que foram as primeiras a adotar, o desafio, na sua perspectiva, é construir novas tecnologias que preencham a lacuna entre este mundo moderno e as ferramentas e sistemas empresariais existentes?

A parte difícil é que as equipes de aplicativos modernas estão acostumadas a ver a camada de infraestrutura evoluir tão rapidamente quanto elas. E isto forçou a camada de infraestrutura a ser ainda mais programável, mais ajustável. É por isso que vemos uma camada de rede e uma camada de segurança no topo da camada de rede em nuvem. Mas agora temos empresas chegando e estamos vendo uma demanda muito forte para ainda se conectar ao velho mundo e falar sobre MPLS, VLAN, sFlow e NetFlow – todo o conjunto existente de requisitos empresariais. Nenhum deles desapareceu, todas as regras de conformidade continuam as mesmas. E até mesmo algumas das empresas modernas de SaaS agora enfrentam esses desafios à medida que crescem e se preocupam com a conformidade e assim por diante. 

Do ponto de vista tecnológico, trata-se de como conectar esse novo mundo nativo da nuvem aos requisitos empresariais existentes. Porque muitos desses problemas foram ocultados pelos provedores de nuvem pública. Os provedores de nuvem pública resolveram os problemas de conformidade, mas não abriram o código nem publicaram nada disso; eles resolveram isso sozinhos. Faz parte do valor da nuvem. As empresas agora precisam reconstruir e comprar isso se não quiserem ficar presas às ofertas de nuvem pública.

De onde você vê vindo a próxima onda de inovação nativa da nuvem? Ainda vem de uma empresa como o Google ou existe um novo tipo de empresa liderando o ataque?

É muito interessante. Eu diria que provavelmente não vem dos Googles e dos Facebooks. A fonte de inovação será de código aberto, e os clientes e usuários que impulsionarão a demanda serão empresas um nível abaixo dos hiperescaladores – empresas já de tamanho considerável que ainda são altamente disruptivas, como Adobe, Shopify ou GitHub. Mas também empresas que correm o risco de serem perturbadas pela tecnologia, como serviços financeiros, seguradoras e empresas de telecomunicações. Todas essas empresas têm um interesse comum na padronização da infraestrutura com modelos de desenvolvimento e de infraestrutura repetíveis.

Postado em julho 26, 2022