Keynote: The Cloud Native Journey @Apple - Alena Prokharchyk, Engenheira de Software, Apple

[0:00] ♪ ♪ Olá a todos, meu nome é Alena e eu trabalho na Apple. Entrei na empresa como engenheira de software há cerca de um ano para trabalhar com Kubernetes e projetos cloud-native. Desde então, muitas pessoas da comunidade open source me perguntaram o que mais me atraiu no meu novo trabalho.

[0:34] E a resposta é fácil. É a escala da infraestrutura de nuvem e a variedade de aplicações rodando nela. Antes, eu me concentrava principalmente no provisionamento de clusters Kubernetes. Achei que olhar as coisas do ponto de vista da aplicação e do usuário final ajudaria a completar o ciclo, então aqui estou. Quando você entra em uma nova equipe ou empresa, conhecer sua história ajuda a entender as decisões e trade-offs atuais. O Mesos tem sido usado na Apple há mais de cinco anos com um orquestrador de contêineres construído internamente chamado Jarvis.

[1:06] Ele tinha uma boa reputação como plataforma de agendamento e escalava bem para suportar múltiplos frameworks para executar uma variedade de serviços como Batch, Stateful e Stateless. Mas o orquestrador de contêineres logo se tornou um gargalo para a delegação de habilidades e responsabilidades, então começamos a considerar outras opções. Além do Mesos, a Apple usava algumas outras soluções para gerenciamento de computação. Junto com a transição, queríamos consolidá-las e fornecer a plataforma unificada para melhor utilização da capacidade.

[1:37] Descobrimos que o Kubernetes era um vencedor óbvio como orquestrador. Sendo o Kubernetes mais genérico e flexível, isso significava que podíamos dividir melhor o trabalho entre as equipes. As decisões sobre qual provedor escolher para componentes centrais como armazenamento, runtime e rede não eram mais decisões de vida ou morte. Sabíamos que era apenas uma escolha de plugin e a escolha sempre poderia ser reavaliada sem refatorar todo o sistema. Outro grande atrativo para os desenvolvedores era a capacidade de estender as APIs e a funcionalidade central do Kubernetes aproveitando CRDs e controladores personalizados.

[2:14] A comunidade Kubernetes foi um enorme ativo para a plataforma. Sua transparência e poder eram tão óbvios e proporcionavam um grande nível de conforto aos desenvolvedores. O objetivo era atender à demanda de uma base de usuários diversificada. Tínhamos equipes que já executavam clusters Kubernetes com sucesso em suas organizações. E tínhamos pessoas que nunca haviam trabalhado com Kubernetes antes, mas confiavam na tecnologia e queriam adotá-la. Quando ocorre uma mudança dessa magnitude, é importante ser honesto sobre os trade-offs que precisam ser feitos para uma migração bem-sucedida.

[2:50] É um fato conhecido que a curva de aprendizado do Kubernetes é íngreme, não apenas para usuários finais, mas também para desenvolvedores de plataforma. Todos os recursos da plataforma que foram construídos no passado tiveram que ser reavaliados. O design atual do recurso está alinhado com as melhores práticas cloud-native? Esse recurso é sequer relevante para a nova plataforma? Fazer e responder a essas perguntas pode ser desconfortável para as pessoas. E software é feito por pessoas. Tivemos que aceitar o fato de que haveria necessidade de mudança nos processos atuais, e as pessoas teriam que se adaptar.

[3:24] Percebemos o impacto da decisão. Estávamos prontos para investir em recursos de treinamento e fornecer suporte total aos desenvolvedores, tudo para tornar a adoção bem-sucedida. Naquele momento, o Kubernetes se tornou nossa escolha de plataforma para gerenciamento de computação na Apple. Nossa meta é fazer com que a maioria das cargas de trabalho da Apple rode em Kubernetes. Queremos manter o foco no usuário final enquanto construímos a plataforma. Isso exigiu que entendêssemos e categorizássemos os usuários da nossa plataforma para estabelecer padrões comuns para o planejamento de infraestrutura de hardware e software.

[4:00] Uma categoria de usuários são desenvolvedores Java, Python, Go que querem testar e executar suas aplicações nos contêineres. Outra categoria são os SREs de aplicações cujo foco é construir fluxos de trabalho de implantação avançados para suas equipes. Outro exemplo são engenheiros de QA de hardware que não têm medo de experimentar coisas novas e explorar soluções criativas usando ferramentas cloud-native. Tudo para facilitar que as equipes de hardware validem dispositivos. Há engenheiros de machine learning e cargas de trabalho em lote que utilizam a plataforma diariamente, executando milhares de jobs em lote que usam CPU e GPUs para treinar modelos de machine learning.

[4:39] O setor financeiro também é um usuário da plataforma, pois é uma grande parte das decisões de posicionamento e planejamento de capacidade. Todos esses usuários querem adotar ferramentas cloud-native para melhor depuração, registro, monitoramento e rastreamento de seus aplicativos. Nossa responsabilidade como desenvolvedores de plataforma é fornecer uma camada de orquestração escalável com isolamento seguro de recursos e agendamento confiável. Construir abstrações de alto nível e ferramentas de CLI também é necessário para o sucesso e a adoção da plataforma.

[5:11] Então temos esse grande pool de infraestrutura de recursos de computação e armazenamento gerenciado pelo Kubernetes. Fornecê-lo aos usuários pode ser feito de duas maneiras: cluster como serviço e namespace como serviço. Namespace como Serviço é nosso modelo principal hoje. O SRE gerencia clusters Kubernetes multi-inquilino e o usuário opera em um ou vários namespaces. Dessa forma, os usuários não têm a sobrecarga do gerenciamento de infraestrutura e podem se concentrar na implantação e no desenvolvimento de aplicações. No entanto, percebemos que, no mundo em que o provisionamento de clusters foi comoditizado, algumas equipes ainda podem querer cluster como serviço.

[5:54] Com o objetivo de controle centralizado de capacidade, tivemos que abstrair o gerenciamento de recursos para seu próprio sistema. Queríamos torná-lo o mais genérico possível para simplificar a solução para a nuvem híbrida no futuro. O sistema faria um balanceamento dinâmico entre clusters, prioridade, uso e limites para encontrar o melhor posicionamento para a aplicação do usuário. O isolamento de recursos seria tratado atribuindo prioridade e cota a cada carga de trabalho. No entanto, ainda tínhamos que abordar as preocupações de privacidade e segurança de executar aplicações em clusters multi-inquilino.

[6:29] Isso tinha que ser feito tanto nos níveis de configuração quanto de runtime. Mesmo com a restrição de namespace como serviço, queríamos que os usuários tivessem a liberdade de escolher ferramentas cloud-native para executar em seus namespaces. Algumas dessas ferramentas exigem CRDs, um recurso de nível de cluster. Temos que pensar em um fluxo adequado de gerenciamento de CRDs para tornar essa implantação possível. Resolver esses desafios técnicos não teria sido possível sem a ampla variedade de ferramentas cloud-native. Aquelas que usamos no nível da plataforma e aquelas que recomendamos aos desenvolvedores de aplicações.

[7:04] Esta lista não está completa e continua crescendo à medida que avaliamos constantemente novos projetos e encontramos mais áreas para desenvolvimento e integração. Com todo o planejamento cuidadoso, apenas executar as coisas em escala poderia revelar certos problemas. Escolhemos a ferramenta de carregamento de cluster open source Kubernetes PerfTest. para desafiar nossas classes 3s. Os desenvolvedores sempre podem escrever seu próprio framework, mas achamos o Cluster Loader bastante poderoso. Queríamos nos engajar mais com a comunidade e investir tempo corrigindo e expandindo a ferramenta existente que poderia ser usada por outros.

[7:40] Outra área de foco imediato era o agendamento. Executamos tipos mistos de cargas de trabalho no Kubernetes, incluindo cargas em lote, e queremos manter uma utilização razoável de recursos. Participar do SIG scheduling e contribuir de volta é muito importante para nós, pois queremos ficar o mais próximo possível do upstream. Para algumas pessoas da nossa equipe, foi a primeira experiência contribuindo com o Kubernetes Upstream, passando pelo processo de ingressar no SIG para discussões. Abrir os primeiros issues no Kubernetes e reconhecer as várias maneiras de ajudar a comunidade foi tudo novo e empolgante.

[8:16] Gostaria de compartilhar algumas de nossas prioridades atuais. Em um ambiente multi-inquilino, as cargas de trabalho de muitos clientes rodam na mesma máquina. Para atender aos requisitos de segurança e fornecer isolamento entre níveis mistos de confiança, um padrão comum é aproveitar a defesa em profundidade. Estamos buscando habilitar esse nível de isolamento com microVMs. Com isso, vários inquilinos não confiáveis podem rodar nos mesmos nós e compartilhar o mesmo plano de controle, enquanto continuam a fornecer duas camadas de isolamento: máquina virtual e contêiner.

[8:51] O Cluster como Serviço traz consigo o custo de maior gestão de segurança, ineficiência na utilização de recursos e sobrecarga operacional. nas empresas da escala da Apple. Como resultado, começamos a explorar modelos alternativos, como clusters virtuais. Com o Cluster Virtual, Usuário, Autoatendimento, Plano de Controle e Dados do Kubernetes Virtualizado, sobre uma infraestrutura Kubernetes compartilhada. Ele elimina a maioria das preocupações de segurança e operacionais. Com o crescimento da pegada de implantação e a distribuição entre data centers, surge a demanda por gerenciamento de cargas de trabalho multicluster. Estamos pesquisando soluções de proxy de API para oferecer melhor autocorreção, eficiência de utilização, obstruções de alto nível e experiências de fluxo de trabalho para desenvolvedores para equipes que gerenciam cargas de trabalho em vários clusters.

[9:42] Queremos reduzir a complexidade da plataforma para desenvolvedores e operadores. Ao mesmo tempo, queremos manter altos padrões de segurança e baixa utilização de recursos. Por isso, estamos investindo em uma solução de função como serviço, aproveitando o web assembly do lado do servidor para resolver isso. Com as constantes adições de novos recursos e cargas de trabalho dos usuários, a observabilidade se torna uma das principais prioridades. Queremos manter o gerenciamento da plataforma sensato à medida que a plataforma cresce. A produtividade e a satisfação do usuário final são nosso objetivo final. Estamos sempre buscando maneiras de melhorá-la com CI/CD atraente e ferramentas para desenvolvedores.

[10:19] Adotar novas tecnologias em escala tão grande costuma vir junto com mudanças organizacionais. Você precisa mudar tudo e todos, desde gerentes e finanças até equipes técnicas e você mesmo. É um longo caminho com muitas dores de crescimento. Nossa equipe de segurança cresceu e assumiu responsabilidades extras. A segurança de seguros em cluster multi-atendente não é uma tarefa trivial. Tivemos que ter uma separação clara de responsabilidades entre a segurança de aplicações e a segurança da plataforma Kubernetes para manter um modelo de responsabilidade compartilhada.

[10:54] Um de nossos objetivos era repensar o planejamento de capacidade. Ter uma equipe dedicada de gerenciamento de recursos trabalhando próxima ao departamento financeiro era necessário. Algumas novas equipes foram formadas, algumas cresceram em tamanho e responsabilidades, e algumas desenvolveram um novo conjunto de prioridades. A equipe de SRE costumava ser mais operacional e focada em sistemas. Agora ela tem ênfase em engenharia e uma voz muito mais forte no design arquitetônico da plataforma. Ter uma plataforma sólida e estável tornou possível manter o foco nas necessidades do cliente e inovar mais rápido.

[11:30] A inovação é impossível sem colaboração. Formar um conselho de revisão técnica interequipes para projetos baseados em cloud-native foi inestimável para nós. É um lugar seguro para obter feedback de colegas com diferentes origens. Alguns têm mais experiência com o desenvolvimento de recursos para Kubernetes, e alguns têm profunda expertise em um domínio técnico específico, como segurança. Obter a contribuição combinada deles é extremamente útil durante a fase de design. Com uma plataforma compartilhada, compartilhar informações se torna uma necessidade. Temos a sorte de ter uma equipe dedicada gerenciando iniciativas de inner source e open source aqui na Apple.

[12:06] A equipe se concentra em treinamentos internos sobre Cloud Native e Kubernetes, aconselha pessoas que querem começar a fazer suas primeiras contribuições open source e apoia aqueles que já contribuem para o open source há algum tempo. A equipe ajuda a conectar pessoas e a crescer colaborações internas e externas. A transformação em andamento deixa muito pouco tempo para reflexão, mas a reflexão é sempre necessária. A migração não é algo que todo mundo quer fazer.

[12:37] Mas aqueles que investem na modernização de suas aplicações e plataformas se beneficiam no futuro ao adotar mais tecnologias cloud-native sobre a fundação. A migração em escala nos ensinou a abraçar as melhores práticas da comunidade e os aprendizados compartilhados. Queríamos retribuir e percebemos que o engajamento vem de muitas formas: escrever código, atuar no conselho do TOC para a CNCF, ajudar a equipe de lançamento do Kubernetes, melhorar a documentação, abrir issues e muito mais.

[13:08] A inovação é impulsionada pelo compartilhamento e pela colaboração. Compartilhar com uma comunidade mais ampla no open source, compartilhar com outra equipe na sua empresa por meio do inner source, ajuda a permitir a reutilização de soluções existentes e a minimizar a redundância. Mesmo uma pequena mudança pode começar a tornar realidade uma mudança cultural maior. Percebemos que, no final, a migração muda não apenas a stack técnica, mas as pessoas envolvidas nela. Entre em contato conosco se tiver alguma dúvida. Obrigado.