 Oi, pessoal! Obrigado por me juntar. Netflix run uma plataforma Node.js que empurra todas as interfaces de usuário de devices. Como o negócio se desenvolve, a plataforma está crescendo para servir outros casos de uso, como as aplicações de web que suportam a produção de conteúdo. Meu nome é Guilherme Hermeto e eu sou um engenheiro e Netflix é um time-time team de Node.js. Eu explico a nossa plataforma revolvente enquanto maximizando a utilizabilidade de code. Para te dizer onde estamos indo, eu posso começar do início. Netflix começou usando Node.js no final de 2013 e a primeira aplicação de Node.js recebeu produção de trafico no ano de 2014, em que o trabalho de antes se desenvolveu para ser o seu currently serverless Node.js platform chamado Nodecork. A Nodecork service vive em um container que é aplicado em uma plataforma de manejamento de container chamado Titus e sinta por trás de um gato de aplicação level 7, chamado ZOO, que é responsável por autenticar, validar e routar regras dos clientes diversos para o serviço de Node.js. Ao recebendo um regras, o serviço de Node.js vai fazer um ou mais regras para os APIs de metade e formatar as respostas para enviar para o cliente.Both ZOO e Titus são projetos de Netflix open-source. Eu sugiro que você chegue agora no GitHub. A plataforma de Node.js o main goal foi para proporcionar uma experiência manejante onde clientes da rede poderiam criar experiências custom API feitas para seus específicos devices. Por exemplo, o Android Team poderia criar um API que melhor seria para o design do cliente. Sabe para iOS, TVY e outros clientes. Em outras palavras, o FF ou o Backend para o Frontend. Com a plataforma, o cliente pode se concentrar no seu objetivo enquanto abstraimos a infraestrutura complexa de oferecimentos e Netflix. Então, isso é o que você precisa para um serviço de Node.js. É um file de JSON de Node.js e um regras-regras. É isso. É tudo o que você precisa para ter um serviço de produção red. O file de Handler Rob pode retornar um regras-regras de funções. E você pode também especificar o Midoware ou Node.js. A plataforma será responsável para três áreas principais. Observabilidade Metrics, Distributor Tracing, Helping Dashboard e Centralized Logging. A bugabilidade com manegamento de excepção e funções diagnósticas. Exemplos de funções diagnósticas são grafes de flamengo e profissionais de heap. E, finalmente, disponibilidade com configuração, alertas, registração de serviço e cobertividade. Basicamente, tudo o que você espera para um serviço de produção red. Na plataforma decorada temos um aplicativo REST FI com o module REST both REST FI e o module REST são open source. Check them out on GitHub. O module REST é responsável para ler o file de JSON da aplicação custom e usar isso para localizar todos os Handlers. Quando lançamos uma versão da plataforma nós estamos publicando uma imagem docker com a run-time platform NodeCore e quando um cliente publica uma nova versão do serviço nós layermos essas imagens copiando a aplicação para a imagem da plataforma. Nós, como plataforma somos responsáveis para monitorar e mitigar os problemas com o processo de running. Quando a imagem da aplicação está aplicada o serviço está pronto para receber a aplicação de produção. Esse modelo permite para os clientes para construir aplicações que recebem grandes quantidades de aplicação e suporte de 182 milhões de subscritores. NodeCore é muito optimizado para esse caso de uso. Quando o negócio se desenvolve para empurrar um tipo diferente de aplicação como os que suportam os processos de produção de conteúdo e essas aplicações têm diferentes caracteristicas. Quando o streaming tem mais de 100 aplicações com grande footprint e às vezes requerem milhares de containers e servem dozens de milhões de usuários produtos de conteúdo têm um grande número de aplicações com uma pequena footprint e uma base muito limita de usuários. A segurança também é diferente quando um usuário streaming tem acesso a seus próprios accountos e todo o library de conteúdo produtos de conteúdo têm um jeito mais de uma autenticação e autorização. Nós temos que autenticar o serviço, os seus clientes e decidir o nível de acesso que cada usuário tem. E mesmo que ambos os tipos de serviços requerem distribuição, treinamento e login centralizado sample e retention não são os mesmos. Por exemplo em aplicações de streaming samplemos 0.1% de requerções enquanto em aplicações de produção faz sentido para samplemos 100%. E enquanto é só costa efetiva para continuar streamando logs rádiosamente disponíveis durante as últimas 24 horas provavelmente queremos aumentar a rendência de log para as outras aplicações em, digamos, um mês. As aplicações são diferentes, mas também compartilham muitas preocupações sobre a observabilidade com que o método realmente importa a divulgabilidade. Como eu rapidamente encontro o que é errado com o meu serviço? E a configuração. Como eu configuro a melhor configuração para running um serviço em produção? Isso é importante também. Afortunadamente a arquitetura original tinha suas limitações. O design original fez um monte de assuntos sobre a infraestrutura e outros casos eram apenas não no topo do ponto. E a estabilidade foi uma grande preocupação. Deixe-me expender isso. Então, a nossa equipe tenta realmente difícil não para romper Netflix em novas relícias platformas. É um processo low. Cada relícia platforma requer que ela possa marcar as mudanças, em vários serviços, comparando-se com a baseline. Se há any issues or performance degradation we search for the root cause we fix it then we rinse and repeat until we get a performance that is desirable. This model just won't fit well for the fast-paced new applications that we aim to support. It creates risk on one side and reduces velocity on the other. And one added piece of complexity. So when we took a step back and look at the whole customer base we saw that we have more differences than just content production and streaming applications. Some of those applications rely on Fallcore, some on REST, and most of the new ones, GraphQL. When I analyzed all the puzzle pieces I got to the conclusion that the best approach moving forward was to extract all those components from the platform into self-contained modules or plugins. Yeah, I went there, plugins. And what plugins solve our problem? How do they solve our problem? Well, plugins allow us to remove the fast-evolving pieces of the platform source code creating a much-needed stability for the streaming applications. And most of them can be reusing almost all applications with maximized code reusability and minimize our support burden. So we are going even further further than that. We are making everything plugins. Like everything. Except a tiny little piece of platform code that load plugins everything else is a plugin. Even the server. And that gives us a lot of flexibility. Right now our code is very intertwined with RESTFI. But if the server is a plugin with a stable interface it enables us to experiment with other application frameworks. Like FESTFI. When we were designing the plugins we researched a lot of other plugins. We researched different plugins implementations including how happy and FESTFI implement plugins. And we decided that we need a little bit more structure. So while happy and FESTFI plugins you pass application server back to the plugin. And let the plugin would find a server. We chose a format where the plugin actually provide hooks. And the platform control how and when those hooks are called. For comparison this is a FESTFI plugin pretty simple. And this is how an old quark plugin looks like. So it's pretty simple too. This is the interface that I'm working with. Let's go check that out. In addition to the startup and shutdown hooks the plugins also provide the following life cycle hooks. Before request pre parsing pre routing after request on air. These hooks are called during the different stages of the request life cycle. We chose this structure to give us control now and provide the flexibility for the future. For instance in the future we might have a plugin which has different dependencies as startup and during the request life cycle. The plugins are also responsible to provide a debug interface and a mock interface. The debug interface is used by the platform debug server which runs in parallel with the customer servers and provide real time health information for that instance. The mock interface allows our customers to mock a plugin during unit or integration test. And lastly the route keys allow us to register platform defined routes. For instance a GraphQL or Apollo plugin could define a slash GraphQL route saving the user the trouble. This plugable architecture enable us to create another abstraction which we call application profiles. Application profiles are type of applications with similar characteristics meaning they use the same plugins. So an application profile can be seen as a list of plugins to load for a given application. We actually design it as a module that imports the plugins and export an array of loaded plugins. In the future that will allow us to use the profiles to require different versions of plugins. We're not there yet we'll hope to be there soon. So since profiles only load specific plugins it reduces the risk of a plugin built for content production to break an application on the streaming path. For example if I just load the security for content production and I change that plugin very often as the profiles for streaming applications don't load that particular plugin it's fine that that plugin evolves fast. And not even limited to plugins so the concept of application profiles can now be leveraged through the platform. We can use it to load different dashboards, register different alerts and even load different sidecars or demons for each profile. As we remove all the moving pieces from the core platform its source code becomes very very stable and rarely needs to change. This allows us in the future to shift of focus from platform releases to profile releases. Currently our tooling relies on platform versions but as we break the platform into smaller pieces it becomes less important in relation with the profile versions. Onde vamos de aqui? Bem, para nós o próximo passo é para permitir que os equipamentos possam criar profissionais de aplicação e dar para seus clientes ajudando eles a virtualmente construir plataformas no topo de uma plataforma. A interface que eu mostrei é privada para o nosso time neste momento mas a plana de relevar isso para os equipamentos nos próximos meses agora tentamos testar, validar e solidificar antes de fazer uma interface publica para eles. E é tudo muito open-ended mas muito emocionante então muito emocionante ver onde isso vai. E até além de BFFs estamos agora procurando graus federados e aplicações renderas Então possibilidades, possibilidades, possibilidades Hoje eu toco alguns subjetos como distributed tracing, centralized logging e Metrics Algumas das coisas que usamos na Netflix são internas então eu não posso recomendar tudo o que você usa mas se você precisa de um lugar para começar eu tenho opções que eu personally gostaria de recomendar e que são open source Para Metrics e Alerting há atlas que usam na Netflix e Prometheus que é muito bem conhecido Para o login centralizado sempre gostaria de fluir e algumas das produtas elásticas especialmente os FILE BEATS para enviar os logs para a search elástica Para o Distributor Request Tracing Zipkin é definitivamente a maneira para ir Para os diagnósticos tem a escala de flamês que você usa Linux Perf Então você pode usar o package Linux Perf disponível na NPM nós usamos o mesmo package em Nodecork E, por último para a recepção de maneiras o centro é muito bem conhecido e fácil de usar e eu também sempre gostaria de curtir Obrigado muito por estar aqui com eu hoje e para me compartilhar ou trabalhar com você Eu vejo você na QA