Josh Evans fala sobre o mundo caótico e colorido dos microsserviços da Netflix, começando pelo básico: a anatomia dos microsserviços, os desafios associados aos sistemas distribuídos e seus benefícios. Com base nessa base, ele explora as práticas culturais, arquitetônicas e operacionais que levam ao domínio dos microsserviços.
Diferentemente da deriva operacional, a introdução de novas linguagens para internacionalização de serviços e novas tecnologias como containers são decisões conscientes para agregar nova complexidade ao ambiente. Minha equipe de operações padronizou o melhor roteiro tecnológico para Netflix, que foi incorporado às melhores práticas predefinidas baseadas em Java e EC2, mas à medida que o negócio crescia, os desenvolvedores começaram a adicionar novos componentes, como Python, Ruby, Node-JS e Docker.
Estou muito orgulhoso de termos sido os primeiros a defender que nosso produto funcionasse perfeitamente sem esperar pelas reclamações dos clientes. Tudo começou de forma bastante simples - tínhamos programas operacionais em Python e alguns aplicativos de back-office em Ruby, mas as coisas ficaram muito mais interessantes quando nossos desenvolvedores web anunciaram que abandonariam a JVM e migrariam a web aplicação para a plataforma de software Node.js. Após a introdução do Docker, as coisas ficaram muito mais complexas. Seguimos a lógica e as tecnologias que criamos tornaram-se realidade quando as implementamos para os clientes porque faziam muito sentido. Eu vou te dizer por que isso acontece.
Na verdade, o API Gateway tem a capacidade de integrar ótimos scripts que podem atuar como endpoints para desenvolvedores de UI. Eles converteram cada um desses scripts de forma que, após fazer as alterações, pudessem implantá-los na produção e depois nos dispositivos do usuário, e todas essas alterações foram sincronizadas com os endpoints executados no gateway da API.
No entanto, isso repetiu o problema de criação de um novo monólito onde o serviço API estava sobrecarregado com código de tal forma que ocorreram vários cenários de falha. Por exemplo, alguns endpoints foram removidos ou scripts geraram aleatoriamente tantas versões de algo que as versões ocuparam toda a memória disponível do serviço API.
Era lógico pegar esses endpoints e retirá-los do serviço de API. Para fazer isso, criamos componentes Node.js que rodavam como pequenos aplicativos em contêineres Docker. Isso nos permitiu isolar quaisquer problemas e travamentos causados por esses aplicativos de nó.
O custo dessas mudanças é bastante elevado e consiste nos seguintes fatores:
- Ferramentas de produtividade. O gerenciamento de novas tecnologias exigiu novas ferramentas porque a equipe de UI, usando scripts muito bons para criar um modelo eficiente, não precisou gastar muito tempo gerenciando a infraestrutura, apenas teve que escrever scripts e verificar sua funcionalidade.
Insight e classificação de oportunidades - Um exemplo importante são as novas ferramentas necessárias para descobrir informações que impulsionam o desempenho. Era necessário saber o quanto o processador estava ocupado, como a memória estava sendo utilizada, e a coleta dessas informações exigia diferentes ferramentas. - Fragmentação de imagens de base – a AMI de base simples tornou-se mais fragmentada e especializada.
- Gerenciamento de nós. Não existe nenhuma arquitetura ou tecnologia pronta para uso que permita gerenciar nós na nuvem, por isso criamos o Titus, uma plataforma de gerenciamento de contêineres que fornece implantação de contêineres escaláveis e confiáveis e integração na nuvem com Amazon AWS.
- Duplicação de uma biblioteca ou plataforma. Fornecer novas tecnologias com a mesma funcionalidade central da plataforma exigiu duplicá-la em ferramentas de desenvolvedor Node.js baseadas em nuvem.
- Curva de aprendizado e experiência industrial. A introdução de novas tecnologias cria inevitavelmente novos desafios que devem ser superados e com os quais devemos aprender.
Assim, não podíamos limitar-nos a uma “estrada pavimentada” e tivemos que construir constantemente novas formas de fazer avançar as nossas tecnologias. Para manter os custos baixos, limitamos o suporte centralizado e nos concentramos na JVM, em novos nós e no Docker. Priorizamos o impacto efetivo, informamos as equipes sobre o custo de suas decisões e as incentivamos a procurar maneiras de reutilizar as soluções de alto impacto que já haviam desenvolvido. Usamos essa abordagem ao traduzir o serviço para idiomas estrangeiros para entregar o produto a clientes internacionais. Os exemplos incluem bibliotecas cliente relativamente simples que podem ser geradas automaticamente, de modo que é bastante fácil criar uma versão Python, uma versão Ruby, uma versão Java, etc.
Estávamos constantemente em busca de oportunidades para usar tecnologias comprovadas e comprovadas em um local e em outras situações semelhantes.
Vamos falar sobre o último elemento – mudanças ou variações. Veja como o consumo do nosso produto varia de forma desigual por dia da semana e por hora ao longo do dia. Pode-se dizer que 9h é o horário mais difícil para a Netflix, quando a carga do sistema atinge o máximo.
Como podemos alcançar alta velocidade de implementação de inovações de software, ou seja, realizar constantemente novas alterações no sistema, sem causar interrupções na prestação de serviços e sem criar transtornos aos nossos clientes? A Netflix conseguiu isso através do uso do Spinnaker, uma nova plataforma global de gerenciamento e entrega contínua (CD) baseada em nuvem.
Fundamentalmente, o Spinnaker foi projetado para integrar nossas melhores práticas para que, à medida que implantamos componentes na produção, possamos integrar a saída diretamente em nossa tecnologia de distribuição de mídia.
Conseguimos incorporar duas tecnologias que valorizamos muito em nosso pipeline de entrega: análise canário automatizada e implantação em etapas. A análise canário significa que direcionamos uma parte do tráfego para a nova versão do código e passamos o restante do tráfego de produção pela versão antiga. Em seguida, verificamos como o novo código lida com a tarefa - melhor ou pior que o existente.
Uma implementação escalonada significa que, se uma implementação em uma região apresentar problemas, passaremos para uma implementação em outra região. Neste caso, o checklist acima mencionado deve ser incluído no pipeline de produção. Economizarei seu tempo e recomendo que você confira minha palestra anterior, Engineering Global Netflix Operations in the Cloud, se estiver interessado em se aprofundar neste tópico. A gravação em vídeo do discurso pode ser visualizada no link na parte inferior do slide.
Ao final da palestra, falarei brevemente sobre a organização e arquitetura da Netflix. No início tínhamos um esquema chamado Electronic Delivery, que foi a primeira versão do streaming de mídia NRDP 1.x. O termo “backstream” pode ser usado aqui porque inicialmente o usuário só poderia baixar conteúdo para posterior reprodução no dispositivo. A primeira plataforma de entrega digital da Netflix, em 2009, era mais ou menos assim.
O dispositivo do usuário continha o aplicativo Netflix, que consistia em interface UI, módulos de segurança, ativação e reprodução de serviços, baseado na plataforma NRDP – Netflix Ready Device Platform.
Naquela época, a interface do usuário era muito simples. Ele continha o que foi chamado de Queque Reader, e o usuário iria ao site para adicionar algo ao Queque e depois visualizaria o conteúdo adicionado em seu dispositivo. O lado positivo foi que a equipe de front-end e a equipe de back-end pertenciam à mesma organização de Entrega Eletrônica e tinham uma relação de trabalho estreita. A carga útil foi criada com base em XML. Ao mesmo tempo, foi criada a API Netflix para o negócio de DVD, o que incentivou aplicações de terceiros a direcionar o tráfego para o nosso serviço.
Porém, a API Netflix estava bem preparada para nos ajudar com uma interface de usuário inovadora, contendo metadados de todo o conteúdo, informações sobre quais filmes estavam disponíveis, o que criou a capacidade de gerar listas de observação. Tinha uma API REST genérica baseada no esquema JSON, código de resposta HTTP, o mesmo usado na arquitetura moderna, e um modelo de segurança OAuth, que era o que era necessário na época para uma aplicação front-end. Isso possibilitou passar de um modelo público de entrega de conteúdo em streaming para um modelo privado.
O problema da transição foi a fragmentação, pois agora nosso sistema operava dois serviços baseados em princípios de operação completamente diferentes - um em Rest, JSON e OAuth, outro em RPC, XML e um mecanismo de segurança do usuário baseado no sistema de token NTBA. Esta foi a primeira arquitetura híbrida.
Havia essencialmente um firewall entre nossas duas equipes porque inicialmente a API não se adaptava muito bem ao NCCP e isso gerava atritos entre as equipes. As diferenças estavam em serviços, protocolos, circuitos, módulos de segurança, e os desenvolvedores muitas vezes tinham que alternar entre contextos completamente diferentes.
A este respeito, tive uma conversa com um dos engenheiros seniores da empresa, a quem fiz a pergunta: “Qual deveria ser a arquitetura certa a longo prazo?” e ele fez a contra-pergunta: “Você provavelmente está mais preocupado sobre as consequências organizacionais - o que acontece se integrarmos essas coisas e elas quebrarem o que aprendemos a fazer bem? Esta abordagem é muito relevante para a Lei de Conway: “Organizações que projetam sistemas são limitadas por um design que replica a estrutura de comunicação dessa organização”. Esta é uma definição muito abstrata, por isso prefiro uma mais específica: “Qualquer software reflete a estrutura organizacional que o criou”. Aqui está minha citação favorita de Eric Raymond: "Se você tiver quatro equipes de desenvolvedores trabalhando em um compilador, você acabará com um compilador de quatro passagens." Bem, a Netflix tem um compilador de quatro passagens e é assim que trabalhamos.
Podemos dizer que neste caso o rabo está abanando o cachorro. Nossa primeira prioridade não é a solução, mas a organização; é a organização que impulsiona a arquitetura que temos. Gradualmente, de uma miscelânea de serviços, passamos para uma arquitetura que chamamos de Blade Runner, porque aqui estamos falando de serviços de ponta e da capacidade do NCCP de ser separado e integrado diretamente no proxy Zuul, gateway API e funcionalidade correspondente. “peças” foram transformadas em novos microsserviços com recursos mais avançados de segurança, reprodução, classificação de dados, etc.
Assim, pode-se dizer que as estruturas departamentais e a dinâmica da empresa desempenham um papel importante na definição do design do sistema e são um factor que promove ou impede a mudança. A arquitetura de microsserviços é complexa e orgânica, e sua saúde é baseada na disciplina e no caos introduzido.
Um pouco de publicidade
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com