Painel virtual: Kubernetes e os desafios da nuvem múltipla

Na conferência Kubecon+CloudNativeCon 2018 em Seattle, com a participação de cerca de 8500 pessoas, muitos dos vários serviços do Kubernetes oferecidos pelos principais provedores de nuvem foram discutidos desde a palestra de abertura até as muitas sessões técnicas.

Embora a variedade de provedores de nuvem tenham as respectivas ofertas do Kubernetes, com cada nuvem tentando distinguir suas ofertas em torno de serviços complementares, a meta para a comunidade do Kubernetes é a portabilidade de aplicativos entre as ofertas do Kubernetes. No entanto, na realidade, uma única aplicação ou solução pode abranger essas múltiplas nuvens, ou a multi-nuvem significa simplesmente a realidade organizacional de lidar com múltiplas nuvens?

O InfoQ conversou com especialistas de campo no Kubecon 2018 em Seattle: Dr. Lew Tucker, ex-CTO na nuvem da Cisco, Dr. Sheng Liang, CEO da Rancher Labs, Marco Palladino, CTO da Kong e Janet Kuo, co-presidente da Kubecon+CloudNativeCon 2018 e engenheiro de software do Google, sobre os aspectos multi-nuvem do Kubernetes e os desafios que permanecem

Os palestrantes começaram discutindo o crescimento da comunidade Kubernetes e como ela permitiu o desenvolvimento e a implantação de aplicativos na nuvem. Também falaram sobre o que significa multi-nuvem e as sinergias com a plataforma e comunidade Kubernetes. Foram discutidos alguns padrões de sistema distribuídos que se tornam adequados para multi-nuvem, incluindo alguns projetos existentes e estudos de caso em camadas ao redor do Kubernetes. Por fim, os membros do painel identificaram alguns dos desafios que ainda devem ser enfrentados pela comunidade Kubernetes para tornar a multi-nuvem uma realidade, incluindo o roteiro potencial para o projeto abordar alguns dos desafios.

InfoQ: Vamos falar sobre a comunidade de Kubernetes em geral e sobre o Kubecon 2018 em particular. Como as pessoas estão envolvidas com a comunidade e a conferência desde o início, que razões você atribui ao crescimento e como isso afeta os desenvolvedores e arquitetos em particular daqui para frente?

Lew Tucker: É verdade - o Kubernetes está vendo crescimento e expansão incríveis das comunidades de desenvolvedores e usuários. Como um sistema de orquestração de código aberto para contêineres, fica claro que o Kubernetes torna mais fácil para os desenvolvedores criar e implantar aplicativos com resiliência e escalabilidade, enquanto fornece portabilidade em várias plataformas de nuvem. Como o primeiro projeto a se formar na Cloud Native Computing Foundation, está rapidamente se tornando a plataforma de fato para aplicativos nativos da nuvem.

Sheng Liang: O Kubernetes se tornou popular porque resolveu um problema importante muito bem: como executar aplicativos de maneira confiável. É o melhor orquestrador de contêineres, gerenciador de cluster e agendador existente. A melhor tecnologia combinada com uma comunidade de código aberto muito bem administrada tornou o Kubernetes impossível de ser parado.

Marco Palladino: O crescimento do Kubernetes não pode ser explicado sem levar em consideração tendências muito disruptivas da indústria que transformaram a forma como construímos e dimensionamos software: microservices e o surgimento de contêineres. À medida que as empresas continuavam inovando para encontrar novas maneiras de expandir seus aplicativos e suas equipes, descobriram que desvincular e distribuir o software, bem como a organização, forneceria uma estrutura melhor para permitir que seus negócios também crescessem exponencialmente ao longo do tempo. Grandes equipes e grandes aplicações monolíticas foram, portanto, desacopladas - e distribuídas - em componentes menores. Enquanto algumas empresas originalmente lideraram essa transformação há muito tempo (Amazon, Netflix e assim por diante) e construíram suas próprias ferramentas para permitir seu sucesso, todas as outras grandes organizações corporativas não tinham a eficácia, o know-how e a capacidade de P/D para abordar uma transição semelhante. Com a grande adoção de contêineres (Docker em 2013) e o surgimento de plataformas como a Kubernetes (em 2014) logo após, cada empresa no mundo poderia agora abordar a transição de microservices alavancando um novo ecossistema de autoatendimento fácil de usar . O Kubernetes, portanto, tornou-se o facilitador não apenas para uma maneira específica de executar e implantar software, mas também para uma modernização arquitetônica que as organizações eram anteriormente cautelosas em adotar devido à falta de ferramentas, que agora está acessível a elas. Não se pode ignorar que Docker e Kubernetes, e a maior parte do ecossistema em torno dessas plataformas, são de código aberto - para entender a adoção do Kubernetes, também precisamos entender a mudança decisional da adoção de software corporativo de cima para baixo (como SOA, por fornecedores) a ser de baixo para cima (impulsionado por desenvolvedores). Como resultado dessas tendências do setor, que, por sua vez, alimentaram ainda mais a adoção do Kubernetes, os desenvolvedores e arquitetos agora podem aproveitar um grande ecossistema de tecnologias de software livre de autosserviço sem precedentes, se comparado a até uma década atrás.

Janet Kuo: Uma das principais razões do Kubernetes ter uma comunidade muito forte é porque ela é composta por um conjunto diversificado de usuários finais, colaboradores e provedores de serviços. Os usuários finais não escolhem o Kubernetes porque adoram a tecnologia de contêineres ou o Kubernetes, eles escolhem o Kubernetes porque ele resolve seus problemas e permite que eles se movam mais rapidamente. O Kubernetes é também um dos maiores e mais ativos projetos de código aberto, com colaboradores de todo o mundo. Isso ocorre porque não há concentração de poder no Kubernetes, e isso incentiva a colaboração e a inovação, independentemente de alguém trabalhar ou não no Kubernetes como parte de seu trabalho ou como hobby. Por fim, a maioria dos principais provedores de nuvem e fornecedores de serviços de TI adotaram o Kubernetes como solução padrão para orquestração de contêineres. Esse efeito de rede faz o Kubernetes crescer exponencialmente.

InfoQ: Alguns de nós podem recontar os dias em que o Java eliminou o bloqueio de fornecedores. O Kubernetes tem uma missão semelhante na qual os fornecedores parecem cooperar com os padrões e competir nas implementações. Eliminar o bloqueio do fornecedor pode ser bom em geral. No entanto, o que significa portabilidade de nuvem ou multi-nuvem, e isso é importante para o cliente (deixando de lado o Kubernetes)?

Tucker: Camadas de abstração são tipicamente feitas para esconder a complexidade das camadas subjacentes e, à medida que se tornam plataformas, elas também fornecem um grau de portabilidade entre os sistemas.

Nos primeiros dias do Java, falamos sobre a promessa de "gravar uma vez e executar em qualquer lugar" reduzindo ou eliminando o bloqueio tradicional do sistema operacional associado ao Unix ou ao Windows. O grau em que isso foi realizado muitas vezes exigia uma codificação cuidadosa, mas o valor era claro. Agora, com fornecedores de nuvem pública concorrentes, temos uma situação semelhante. As plataformas de nuvem subjacentes são diferentes, mas os contêineres do Docker e o Kubernetes fornecem uma camada de abstração e alto grau de portabilidade entre nuvens. De certa forma, isso força os provedores de nuvem a competir nos serviços oferecidos. Os usuários então decidem quanto de bloqueio pode existir para aproveitar os serviços específicos do fornecedor. À medida que avançamos cada vez mais em direção a arquiteturas baseadas em serviços, espera-se que esse tipo de bloqueio de fornecedor natural se torne a norma.

Liang: Embora a eliminação do bloqueio de nuvem possa ser importante para alguns clientes, não acredito que um produto destinado exclusivamente à portabilidade da nuvem possa ser bem-sucedido. Muitos outros fatores, como agilidade, confiabilidade, escalabilidade e segurança, são geralmente mais importantes. Estas são precisamente algumas das capacidades oferecidas pelo Kubernetes. Acredito que o Kubernetes acabará sendo uma camada efetiva de portabilidade na nuvem e atingirá a portabilidade da nuvem quase como um efeito colateral, mais ou menos como o navegador alcançou a portabilidade do dispositivo.

Palladino: A multi-nuvem é frequentemente abordada do ponto de vista de uma decisão consciente de cima para baixo, feita pela organização como parte de uma estratégia e roteiro de longo prazo. No entanto, a realidade é muito mais pragmática. As grandes organizações empresariais são, na verdade, a agregação de uma grande variedade de equipes, agendas, estratégias e produtos que fazem parte do mesmo organismo complexo "multi-celular". A multi-nuvem dentro de uma organização está fadada a acontecer simplesmente porque cada equipe/produto diferente toma decisões diferentes sobre como construir seu software, especialmente em uma era de desenvolvimento de software onde os desenvolvedores estão liderando, de baixo para cima, todas as principais decisões tecnológicas e experimentações. As equipes que estão muito próximas do usuário final e do negócio vão adotar qualquer tecnologia (e nuvem) melhor, permitindo que elas atinjam seus objetivos e, em última análise, dimensionem os negócios. A tradicional TI central - longe dos usuários finais e dos negócios, mas mais próxima das equipes - precisará se adaptar a uma nova realidade híbrida que está sendo desenvolvida abaixo deles, enquanto falamos. As aquisições corporativas, ao longo do tempo, de produtos e equipes que já estão usando nuvens diferentes também levarão a uma organização multi-nuvem ainda mais distribuída e desacoplada. A multi-nuvem está acontecendo não necessariamente porque a organização quer, mas porque precisa. Contêineres e Kubernetes - por serem extremamente portáteis - são, portanto, uma boa resposta tecnológica para esses requisitos pragmáticos. Eles oferecem uma maneira de executar software entre diferentes fornecedores de nuvem (e bare-metal) com fluxos de implantação e empacotamento semi-padronizados, reduzindo assim a fragmentação operacional.

Kuo: Portabilidade da nuvem e multi-nuvem dá aos usuários a liberdade de escolher soluções de melhor ajuste para diferentes aplicativos para diferentes situações com base nas necessidades de negócios. A multi-nuvem também permite mais níveis de redundância. Ao adicionar redundância, os usuários obtêm mais flexibilidade para construir com a melhor tecnologia e também ajudam a otimizar as operações e manter a competitividade.

InfoQ: As distribuições e ofertas do Kubernetes em diferentes nuvens tentarão diferenciar suas respectivas ofertas, o que parece ser o curso natural da "Co-opetition". Quais são as armadilhas que a comunidade de Kubernetes deve evitar, com base em suas experiências passadas com comunidades semelhantes?

Tucker: é natural esperar que diferentes fornecedores desejem diferenciar suas respectivas ofertas para competir no mercado. O mais importante para a comunidade Kubernetes é permanecer fiel aos princípios de código aberto e colocar as diferenças baseadas em fornecedores ou infraestrutura nas interfaces padrão para evitar que a plataforma se fragmente em variantes proprietárias. Interfaces públicas, como a estrutura do plug-in do dispositivo (para coisas como GPUs) e a CNI (Container Networking Interface) isolam a diferença específica da infraestrutura por trás de uma API comum, permitindo que os fornecedores concorram na implementação oferecendo uma camada comum. Os fornecedores de hoje também se diferenciam em como eles fornecem Kubernetes gerenciados. Isso fica fora da plataforma, deixando intacta a API do Kubernetes, que ainda deixa ao usuário a escolha se deseja ou não adotar uma estrutura de gerenciamento de fornecedores em seu modelo de implantação.

Liang: A comunidade de usuários deve evitar o uso de recursos que fazem seu aplicativo funcionar apenas com uma distribuição específica do Kubernetes. É fácil manter clusters do Kubernetes a partir de uma variedade de provedores agora. Depois de criar os arquivos YAML ou os gráficos de Helm para implantar seu aplicativo em sua distribuição escolhida, você também deve tentar os mesmos arquivos YAML ou gráficos de Helm nos clusters GKE ou EKS.

Palladino: A comunidade deve desconfiar de qualquer fornecedor de nuvem insinuando uma estratégia de "abraçar, estender e extinguir" que, a longo prazo, irá fragmentar o Kubernetes e a comunidade e abrirá caminho para uma nova plataforma "para governá-los todos".

Kuo: Fragmentação é o que a comunidade Kubernetes deve trabalhar em conjunto para evitar. Caso contrário, os usuários finais não poderão obter um comportamento consistente em diferentes plataformas e perderão a portabilidade e a liberdade de escolha - o que os levou o Kubernetes para o primeiro lugar. Para atender a essa necessidade identificada pela primeira vez pelo Google, a comunidade Kubernetes investiu muito em conformidade, o que garante que a versão do Kubernetes de todos os provedores de serviços ofereça suporte às APIs necessárias e forneça um comportamento consistente aos usuários finais.

InfoQ: Vocês podem mencionar alguns padrões distribuídos de sistema ou aplicativos que fazem dele um Kubernetes multi-nuvem? São microservices?

Tucker: Arquiteturas baseadas em microservices são um ajuste natural com o Kubernetes. Mas ao separar os aplicativos monolíticos em um conjunto de serviços individuais, trouxemos agora a complexidade de um sistema distribuído que depende da comunicação entre suas partes. Isso não é algo que todo desenvolvedor de aplicativos está preparado para assumir. As malhas de serviço, como o Istio, parecem um complemento natural para o Kubernetes. Eles descarregam muitas funções de gerenciamento de tráfego e rede, liberando o desenvolvedor do aplicativo de ter que se preocupar com autenticação de serviço, criptografia, troca de chaves, gerenciamento de tráfego e outros, enquanto fornece monitoramento e visibilidade uniformes.

Liang: Embora os microservices obviamente se encaixem no Kubernetes com multi-nuvens, a arquitetura de implantação legada também se encaixa. Por exemplo, alguns de nossos clientes implantam Kubernetes com multi-nuvens para fins de recuperação de desastres. A falha do aplicativo em uma nuvem não afeta o funcionamento do mesmo aplicativo em outra nuvem. Outro caso de uso é a replicação geográfica. Alguns de nossos clientes implantam o mesmo aplicativo em várias regiões diferentes em várias nuvens para fins de proximidade geográfica.

Palladino: Microservices é um padrão que adiciona um prêmio significativo aos nossos requisitos de arquitetura porque leva a mais partes móveis e mais operações de rede em toda a linha - gerenciar um monolito é um problema da ordem de O(1), enquanto o gerenciamento de microservices é um problema da ordem de O(n). O Kubernetes tem sido uma plataforma muito bem-sucedida para o gerenciamento de microservices, pois fornece primitivos úteis que podem ser aproveitados para automatizar uma grande variedade de operações que, por sua vez, removem alguns - se não a maioria - do "prêmio de microservices" da equação. O surgimento de plataformas de API estritamente integradas com as primitivas do Kubernetes - como sidecar e proxies de ingresso - também está facilitando a construção de arquiteturas de redes intensivas, desacopladas e distribuídas. Com isso dito, qualquer aplicativo pode se beneficiar da execução em cima do Kubernetes, incluindo monolitos. Com o Kubernetes sendo executado como a camada de abstração subjacente em vários fornecedores de nuvem, as equipes agora podem consolidar as preocupações operacionais - como distribuir e implantar seus aplicativos - sem precisar se preocupar com as especificidades de cada provedor de nuvem.

Kuo: Microservices é um dos padrões mais conhecidos. O padrão sidecar também é crítico para que aplicativos modernos integrem funcionalidades como criação de log, monitoramento e rede nas aplicações. O padrão de proxy também é útil para simplificar a vida dos desenvolvedores de aplicativos, de modo que é mais fácil escrever e testar seus aplicativos, sem precisar lidar com a comunicação de rede entre microservices, e isso é comumente usado por soluções de malha de serviços, como o Istio.

InfoQ: O que o padrão emergente do Service Mesh faz para habilitar a implementação da plataforma com multi-nuvens (se houver)?

Tucker: Acredito que os aplicativos baseados no Kubernetes e também baseados em uma arquitetura de microservices e Service Mesh, provavelmente se tornarão mais predominantes à medida que a tecnologia amadurece. A próxima etapa natural é que um Service Mesh conecte vários clusters de kubernetes em execução em diferentes nuvens. Um Service Mesh com multi-nuvem tornaria muito mais fácil para os desenvolvedores avançarem para unir os melhores componentes e serviços de diferentes provedores em um único aplicativo ou serviço.

Liang: O padrão de service mesh emergente acrescenta muito valor à implantação de Kubernetes em multi-nuvem. Quando implantamos vários clusters Kubernetes em várias nuvens, o mesmo service mesh do Istio pode abranger esses clusters, fornecendo visibilidade unificada e controle para o aplicativo.

Palladino: A transição para microservices se traduz em um uso mais pesado da rede nos serviços que estamos tentando conectar. Como todos sabemos, a rede é implicitamente insegura e não pode ser confiável, mesmo dentro da rede da organização privada. O Service Mesh é um padrão que tenta tornar confiável nossa rede inerentemente que não é confiável, fornecendo funcionalidades (geralmente implantadas em um proxy sidecar rodando junto com nossos serviços) que permitem comunicação serviço-a-serviço confiável (como roteamento, disjuntores, verificações de integridade e em breve). Em minha experiência trabalhando com grandes organizações corporativas implementando service mesh em seus produtos, o padrão pode ajudar com implementações de multi-nuvens, ajudando a rotear cargas de trabalho em diferentes regiões e centros de dados, e impondo a comunicação segura entre os serviços em diferentes nuvens e regiões.

Kuo: A orquestração do conteiner não é suficiente para executar aplicativos distribuídos. Os usuários precisam de ferramentas para gerenciar esses microservices e suas políticas, e querem que essas políticas sejam dissociadas dos serviços para que as políticas possam ser atualizadas independentemente dos serviços. É aqui que a tecnologia de service mesh entra em ação. O padrão do service mesh é independente de plataforma, portanto, um service mesh pode ser construída entre nuvens e infraestruturas híbridas. Já existem várias soluções de service mesh de código aberto disponíveis hoje. Uma das soluções de service mesh de código aberto mais populares é o Istio. O Istio oferece visibilidade e segurança para serviços distribuídos e garante um desacoplamento entre desenvolvimento e operações. Assim como no Kubernetes, os usuários podem executar o Isio em qualquer lugar que desejarem.

InfoQ: Fornecedores e clientes geralmente seguem a trilha do dinheiro. Vocês podem falar especificamente sobre histórias de sucesso de clientes ou estudos de caso em que o Kubernetes e/ou multi-nuvem importantes?

Liang: O Rancher 2.0 obteve um tremendo sucesso no mercado precisamente porque é capaz de gerenciar vários clusters Kubernetes em várias nuvens. Uma empresa de mídia multinacional usa o Rancher 2.0 para subir e gerenciar clusters do Kubernetes na AWS, no Azure e em seus clusters vSphere internos. Seu departamento de TI é capaz de controlar qual aplicativo é implantado em qual nuvem, dependendo de suas necessidades de conformidade. Em outro caso, a Goldwind, a terceira maior fabricante de turbinas eólicas do mundo, usa o Rancher 2.0 para gerenciar múltiplos clusters Kubernetes no data center central e em centenas de locais de ponta onde as turbinas eólicas são instaladas.

Palladino: Tive o prazer de trabalhar muito de perto com grandes organizações empresariais e ver os desafios pragmáticos que essas organizações estão tentando superar. Em particular, um grande cliente corporativo da Kong decidiu migrar para a multi-nuvem em cima do Kubernetes devido ao grande número de aquisições realizadas nos últimos anos pela organização. Cada aquisição traria novas equipes, produtos e arquiteturas sob o gerenciamento da organização matriz e, com o tempo, você pode imaginar como foi difícil desenvolver as equipes existentes dentro da organização com tanta fragmentação. Portanto, a organização decidiu padronizar como os aplicativos são empacotados (com o Docker) e executados (com o Kubernetes) em um esforço para simplificar as operações em todas as equipes. Embora às vezes sejam muito semelhantes, diferentes fornecedores de nuvem realmente oferecem um conjunto diferente de serviços com qualidade e suporte diferentes, e algumas nuvens são melhores a outras quando se trata de certos casos de uso. Como resultado, muitos aplicativos em execução na organização também eram executados em nuvens diferentes, dependendo dos serviços implementados, e a empresa já era uma realidade com diversas nuvens na época em que decidiu adotar o Kubernetes. Para manter a latência baixa entre os aplicativos e os serviços específicos que esses produtos implementaram de cada fornecedor de nuvem, eles também decidiram iniciar um cluster Kubernetes com multi-nuvens. Não foi de forma alguma uma tarefa simples, mas o custo de manter as coisas fragmentadas foi maior do que o custo de modernizar sua arquitetura para melhor escaloná-la no longo prazo. Em uma grande empresa, tudo depende de escalabilidade - não apenas técnica, mas também organizacional e operacional.

Kuo: Há uma grande variedade de histórias de sucesso de clientes cobertas em estudos de caso da Kubernetes. Minha favorita é na verdade uma das mais antigas - aquela sobre como o Pokémon Go (um jogo móvel que se tornou viral logo após o lançamento) é executado no Kubernetes, que permitia aos desenvolvedores de jogos implementar mudanças ao vivo enquanto serviam milhões de jogadores ao redor do mundo. . As pessoas ficaram surpresas e animadas ao ver um caso de uso real de clusters Kubernetes de larga escala. Hoje, aprendemos sobre muitas histórias de sucesso de clientes da Kubernetes - como as que acabamos de ouvir da Uber e da Airbnb no palco da KubeCon. Casos de uso diversos e empolgantes são agora a norma dentro da comunidade.

InfoQ: A partir de um único ponto de vista de projeto ou solução, é possível que os diferentes componentes ou serviços residam em várias nuvens? Quais são os principais desafios técnicos (se houver) que precisam ser resolvidos antes que o Kubernetes seja realmente multi-nuvem?

Tucker: Sim. O trabalho em uma API de federação dedicada além da API do Kubernetes já está em andamento (veja no Kubernetes e no GitHub). Essa abordagem não se limita aos clusters que residem no mesmo provedor de nuvem. Mas ainda é muito cedo e muitos dos problemas pragmáticos, além dos mais óbvios, como o aumento da latência e as diferentes APIs de serviços em nuvem, ainda estão em discussão.

Liang: Sim, é. Muitos clientes do Rancher implementam esse modelo de deploy. Estamos desenvolvendo uma série de novos recursos no Rancher para melhorar a experiência em multi-nuvens. 1) Um mecanismo para orquestrar aplicativos implantados em vários clusters que residem em várias nuvens. 2) Integração com balanceadores de carga globais e servidores DNS para redirecionar o tráfego. 3) Um mecanismo para encapsular o tráfego de rede entre pods em diferentes clusters. 4) Um mecanismo para replicar o armazenamento em vários clusters.

Palladino: Federação em vários clusters Kubernetes, uma API de plano de controle que pode ajudar a executar vários clusters e segurança (usuários e políticas). A sincronização de recursos em vários clusters também é um desafio, bem como a observação em toda a linha. Alguns desses problemas podem ser resolvidos com a adoção de integrações e soluções de terceiros, mas seria bom se o Kubernetes oferecesse mais suporte pronto para uso nessa direção. Já existe uma versão alfa de uma API de federação experimental para o Kubernetes, mas infelizmente não está madura o suficiente para ser usada em produção (com problemas conhecidos).

Pensar em um Kubernetes multi-nuvem é semelhante a pensar em gerenciar clusters separados do Kubernetes ao mesmo tempo. Todo o ciclo de vida da versão (empacotamento, distribuição, teste e assim por diante) precisa ser aplicado e sincronizado em todos os clusters (ou alguns deles baseados em condições configuráveis), tendo ao mesmo tempo um plano centralizado para monitorar o status de operações em todo o sistema. A segurança de aplicativos e usuários também se torna mais desafiadora em vários clusters. Em tempo de execução, podemos impor o roteamento de várias regiões (para failover) entre um cluster e outro, o que também significa introduzir mais tecnologia (e sobrecarga no plano de dados) para gerenciar esses casos de uso. Todas as funcionalidades que normalmente usamos em um único cluster, como CI/CD, segurança, auditoria, monitoramento de aplicativos e alertas, devem ser repensadas em um ambiente de vários clusters e multi-nuvens - não apenas operacionalmente, mas também organizacionalmente. .

Kuo: O Kubernetes já faz um bom trabalho de abstrair a camada de infraestrutura subjacente para que os serviços de provedor de nuvem, como rede e armazenamento, sejam simplesmente recursos no Kubernetes. No entanto, os usuários ainda enfrentam muita resistência ao executar o Kubernetes em multi-nuvens. Desafios técnicos incluem conectividade entre diferentes regiões e nuvens, descoberta de desastres, registro e monitoramento, precisam ser resolvidos. Precisamos fornecer melhores ferramentas para tornar a experiência do usuário perfeita e a comunidade se dedica a fornecer esses recursos.

InfoQ: Por favor, mantenha isso breve, mas vocês podem falar sobre alguns produtos ou tecnologias que podem não ser mainstream ainda, mas pode ajudar a esclarecer alguns dos problemas que temos discutido até agora e facilitar o desenvolvimento e a implementação em multi-nuvem?

Liang: Nosso principal produto, o Rancher, é projetado especificamente para gerenciar vários clusters do Kubernetes em várias nuvens.

Palladino: Produtos de código aberto como o Kong podem ajudar a consolidar segurança, observabilidade e controle de tráfego para nossos serviços em implantações de múltiplas nuvens, fornecendo um plano de controle híbrido que pode ser integrado a diferentes plataformas e arquiteturas e permitindo que grandes aplicativos legados sejam dissociado e distribuído em primeiro lugar. Os ecossistemas de código aberto, como o CNCF, também fornecem uma ampla variedade de ferramentas que ajudam os desenvolvedores e arquitetos a enfrentar os novos desafios de arquiteturas híbridas e multi-nuvem com as quais a empresa inevitavelmente terá de lidar (Monoliths, SOA, Microservices e Serverless). É muito importante que, à medida que a escala de nossos sistemas aumenta, evitemos a fragmentação de funções críticas (como segurança), aproveitando as tecnologias existentes em vez de reinventar a roda. E o código aberto, mais uma vez, está liderando essa tendência aumentando a produtividade do desenvolvedor e, ao mesmo tempo, criando valor comercial para toda a organização.

Kuo: Um dos padrões comuns que vejo é gerenciar tudo usando a API do Kubernetes. Para fazer isso, você provavelmente precisará personalizar as APIs do Kubernetes, como usar o Kubernetes CustomResourceDefinition. Várias tecnologias construídas em torno do Kubernetes, como o Istio, dependem muito desse recurso. Os desenvolvedores do Kubernetes estão aprimorando o recurso personalizado de APIs do Kubernetes, para facilitar a criação de novas ferramentas para desenvolvimento e implementação em nuvem múltipla.

InfoQ: Pergunta final. Resumindo, onde vocês veem a comunidade do Kubernetes, e quão importante é a multi-nuvem na definição do roteiro? Há quaisquer outros pensamentos aleatórios sobre Kubernetes e Kubecon que desenvolvedores e arquitetos devem se preocupar?

Tucker: A maioria das pesquisas de usuários mostram que as empresas usam mais de um único fornecedor de nuvem e geralmente incluem nuvens públicas e privadas. Então multi-nuvem é simplesmente um fato. O Kubernetes, portanto, fornece uma plataforma comum importante para a portabilidade de aplicativos entre nuvens. A história da computação, no entanto, mostra que nós continuamente construímos camadas de abstração. Quando, portanto, olhamos para multi-nuvem, pode ser que outras "plataformas", como serverless ou uma arquitetura baseada em serviços baseada em kubernetes, possam estar onde estamos realmente indo.

Liang: Multi-nuvem começou como um benefício colateral maravilhoso do Kubernetes. Acredito que a multi-nuvem é agora um requisito essencial quando as pessoas planejam a implantação do Kubernetes. A comunidade está trabalhando em diversas áreas para melhorar o suporte a várias nuvens: conformidade do Kubernetes, multi-cluster da SIG e Federação. Estou muito empolgado com o rumo de todos esses esforços. Encorajo todos vocês a darem uma olhada nesses projetos se estiverem interessados em suporte multi-nuvem para o Kubernetes.

Palladino: Kubernetes e contêineres permitiram que organizações inteiras modernizassem suas arquiteturas e escalassem seus negócios. Como tal, a Kubernetes está bem posicionada para ser o futuro da infraestrutura para qualquer carga de trabalho moderna. À medida que mais e mais desenvolvedores e organizações implementam o Kubernetes em produção, mais madura se tornará a plataforma para lidar com um conjunto maior de cargas de trabalho em execução em diferentes configurações, incluindo várias nuvens. A multi-nuvem é um tópico real e pragmático que toda organização deve planejar para continuar sendo bem-sucedida, pois o número de produtos e equipes - com requisitos e ambientes muito exclusivos - continua crescendo ao longo do tempo. Como um organismo multicelular, a empresa moderna terá que se adaptar a um mundo com várias nuvens, a fim de continuar criando aplicativos escalonáveis e eficientes que, em última instância, ofereçam valor comercial a seus usuários finais.

Kuo: A comunidade do Kubernetes tem um grupo de interesse especial para provedores de nuvem para garantir que o ecossistema do Kubernetes esteja evoluindo de maneira neutra para todos os provedores de nuvem. Já vi muitos usuários do Kubernetes escolherem o Kubernetes para o benefício de várias nuvens. Eu imagino que mais usuários empresariais ingressarão na comunidade do Kubernetes pelo mesmo motivo.

Conclusão

Os palestrantes falaram sobre sua própria experiência pessoal com a comunidade do Kubernetes e sobre como ela permite o desenvolvimento e a implantação da nuvem. Todos os palestrantes concluem que o Kubernetes já é uma realidade na eliminação do bloqueio de fornecedores e na habilitação da portabilidade da nuvem com a escolha de ofertas nas diferentes nuvens. No entanto, eles também reconhecem que multi-nuvem significa mais do que uma plataforma comum em várias nuvens.

Os palestrantes falaram da abordagem pragmática da comunidade Kubernetes para poder resolver pontos problemáticos específicos relacionados ao desenvolvimento e à implantação de aplicativos de uma maneira verdadeiramente aberta e de comunidade. É improvável que essa abordagem comunitária se enquadre no perigo de "abraçar e ampliar" que tem sido a ruína de muitos projetos no passado.

Por fim, os palestrantes falam sobre padrões de aplicativos, como Service Mesh, Istio e assim

por diante, no contexto de alguns exemplos que exigem que o Kubernetes e seu roteiro evoluam para serem verdadeiramente multi-nuvem.

Sobre os palestrantes

Lew Tucker é ex-VP/CTO da Cisco Systems e atuou no conselho de diretores da Cloud Native Computing, OpenStack e Cloud Foundry Foundations. Tem mais de 30 anos de experiência na indústria de alta tecnologia, desde sistemas distribuídos e inteligência artificial até desenvolvimento de software e arquitetura de sistemas paralelos. Antes da Cisco, Tucker foi VP/CTO de Cloud Computing na Sun Microsystems, onde liderou o desenvolvimento da plataforma Sun Cloud. Também foi membro da equipe executiva da JavaSoft, lançou o java.sun.com e ajudou a trazer o Java para o ecossistema de desenvolvedores. Tucker mudou-se para a tecnologia após uma carreira em neurobiologia na escola de medicina da Universidade de Cornell e tem um Ph.D. em ciência da computação.

Marco Palladino é inventor, desenvolvedor de software e empreendedor baseado na Internet em São Francisco. Como CTO e co-fundador da Kong, é co-autor de Kong, responsável pelo design e entrega dos produtos da empresa, além de fornecer liderança técnica em torno de APIs e microservices na Kong e na comunidade de software externa. Antes de Kong, Palladino co-fundou a Mashape em 2010, que se tornou o maior mercado de APIs e foi adquirida pela RapidAPI em 2017.

Janet Kuo é engenheira de software do Google Cloud. É mantenedora do projeto Kubernetes desde 2015. Atualmente, atua como co-presidente da KubeCon+CloudNativeCon.

Sheng Liang é co-fundador e CEO da Rancher Labs. A Rancher desenvolve uma plataforma de gerenciamento de contêineres que ajuda as organizações a adotarem o Kubernetes. Anteriormente, Sheng Liang foi CTO da Cloud Platform na Citrix e CEO e fundador da Cloud.com (adquirida pela Citrix).