Você provavelmente ouviu (muitas vezes) que uma das maiores vantagens da computação serverless é que você não gerencia a infraestrutura da aplicação, dando liberdade para se concentrar nas regras de negócio sem se preocupar com segurança de back-end ou provisionamento de servidores, por exemplo.
Isso, contudo, pressupõe que você não se preocupa compulsivamente por performance e confiabilidade das aplicações. Para alguns de nós, a preocupação é uma natureza secundária. Se dissermos que não temos de nos preocupar com certas tarefas porque “alguém está cuidando disso”, imediatamente passamos a nos preocupar com o responsável por esse cuidado. Como eles estão cuidando da tarefa? Eles estão fazendo um bom trabalho? Eu poderia fazer melhor? E se eles negligenciarem uma pequena questão, porém importante, que resulta em um enorme desastre ou imprevistos no futuro? Quem são essas pessoas misteriosas e por que devo confiar a elas essa tarefa tão importante?
No post anterior, falamos sobre a arquitetura da computação serverless ser uma grande escolha para aplicações 5G e os motivos para isso. Escolher o provedor de computação serverless certo é importante devido ao seu grande impacto na performance e na segurança da aplicação, fora os custos para executá-la. Então, hoje, daremos uma olhada por trás da nossa plataforma de computação serverless a fim de mostrar como os aplicativos são executados nela – fornecendo a você alguma garantia de que os nossos produtos não são apenas mais baratos e fáceis de usar do que provedores de cloud, mas proporcionam mais desempenho e segurança.
Azion Cells
Com o Azion Edge Functions, os clientes podem executar funções de computação serverless orientadas a eventos em nossa rede de Edge. Isso permite que desenvolvedores criem aplicações nativas de Edge ou adicionem funcionalidades às aplicações de origem. Assim que uma função é implantada, ela é instalada em nossa rede global e gerenciada pelo Azion. Nossa equipe cuida da infraestrutura, fornecendo segurança, escalabilidade e garantindo que, quando acionada, a função seja executada para os usuários finais pelo Edge Node mais próximo a eles.
Sob o capuz do Edge Functions está uma stack de software construída em quatro camadas. Escolhemos o V8 como um runtime comumente usado com recursos de sandbox, que fornecem a segurança necessária para arquitetura de computação serverless. Nossa implementação do V8 é escrita em Rust, e evita o node.js, engine normalmente usado para incorporar o V8. É uma solução mais moderna, simples e segura. O Azion Cells, nossa tecnologia principal, suporta JavaScript e em breve terá suporte para WebAssembly, permitindo aos desenvolvedores escreverem em qualquer linguagem usando WebAssembly para compilação.
Embora V8 e JavaScript sejam amplamente usados em outras soluções de computação serverless e baseados em contêiner, nossas opções de Rust e engine são muito menos comuns. Acreditamos que essas escolhas nos diferenciam de outras soluções, fornecendo o melhor desempenho possível, consumo de recursos e economia – três características essenciais para aplicações da próxima geração.
Rust
O Azion Cells é escrito em Rust, uma linguagem de programação ideal para aplicações com rigorosos requisitos para performance e consumo de recursos. Eficiência e simplicidade é muito importante para qualquer desenvolvedor de software ou empresa, e a performance é crucial para aplicações ultra-low latency, onde cada milissegundo faz diferença. Além disso, a confiabilidade terá vital importância, pois 5G e MEC (multi-access edge computing) permitem mais automação e dispositivos de missão crítica.
Talvez a vantagem mais significativa do Rust para construir componentes importantes de software seja sua confiabilidade. Mesmo bugs pequenos podem ser desastrosos em casos de uso como veículos autônomos, mas um dos problemas que oferecem mais riscos, os bugs de memória, pode ser difícil de encontrar. Como esses bugs são complexos e imprevisíveis, também pode ser difícil testá-los. Como resultado, eles podem permanecer por anos no código sem que sejam percebidos, apenas esperando para causar estragos. O Rust protege contra esse tipo de desastre com um compilador rígido que verifica cada variável e acesso à memória a fim de provar que o código esteja correto e evitar que os engenheiros cometam erros potencialmente perigosos.
O Rust é vantajoso, também, para a próxima geração de aplicações por conta de sua velocidade e uso de memória. Em vez de fornecer segurança às custas de funções que consomem tempo e recursos, como garbage collection, o Rust permite que os programadores armazenem dados tanto na stack quanto em heap. Se a memória não é mais necessária quando o código é compilado, a sua limpeza é automática, permitindo um consumo eficiente. Além disso, o Rust é tipado e compilado estaticamente, possibilitando mais velocidade e otimização.
Azion Cells Engine
Em vez de node.js, o engine que AWS, Google e outros provedores usam, nossa implementação foi escrita do zero em Rust e se beneficia de todas as suas vantagens de segurança, confiabilidade e velocidade. Mais do que isso, ele é capaz de executar JavaScript sem subir um container ou ativar um processo de node.js. Como resultado, ele é mais rápido, simples e barato que soluções baseadas em node.js, propiciando melhor desempenho usando menos recursos.
Além disso, nossa implementação também é capaz de melhorar alguns dos problemas que surgiram com node.js desde sua criação em 2009. Ryan Dahl, autor original do node.js, discutiu extensivamente esses problemas, citando o uso de módulos no node.js como sua maior falha de design, citando sua distribuição centralizada e supercomplexidade. Contudo, em 2019, módulos ES (EcmaScript) foram introduzidos como um sistema de módulo padronizado em JavaScript; o nosso engine utiliza módulos de ES exclusivamente para criar um sistema simples, descentralizado e compatível com o browser.
Por fim, nosso engine oferece segurança adicional sobre node.js por meio do uso de sandbox de segurança do V8 para multi-tenancy e uma série de mecanismos adicionais. Se você leu nossa postagem sobre segurança zero trust, se lembrará que, em termos de segurança moderna, é importante conceder a cada usuário somente acesso às partes de um sistema que cada usuário precisa. Este é um problema existente no node.js, que não foi desenvolvido com multi-tenancy em mente, tornando tudo acessível a todos, o que requer o uso de Containers. Nossa implementação adiciona uma forte segregação de usuários e limita as operações privilegiadas de acesso, tornando-o seguro para executar códigos de terceiros.
Como a Azion se compara ao AWS Lambda
Como o Edge Functions da Azion, o AWS Lambda oferece aos clientes a capacidade de construir funções orientadas a eventos que são gerenciadas pelo provedor e cobradas conforme o uso. Ao contrário da Azion, porém, cada função do AWS Lambda é executada em um contêiner separado. Desenvolvedores devem decidir com antecedência quanta memória alocar cada função com base em suas dependências de código; a AWS, então, aloca CPU, largura de banda e I/O de disco proporcionais. Os contêineres são executados quando a função é disparada e minimizados após a função ficar ociosa por um tempo. Após esse período de inatividade, o contêiner e o node.js devem iniciar para que a função seja executada, resultando em cold start de aproximadamente meio segundo e exigindo muitos recursos para escalar – dois grandes problemas para latência e aplicações de alto throughput, inclusive 5G.
Por outro lado, a Azion oferece melhor desempenho com menos hardware, usando um ambiente multi-tenant em que cada função é isolada em um sandbox seguro. Isso requer muito menos RAM do que armazenar cada função em um contêiner separado e, consequentemente, é muito mais econômico. Além disso, multi-tenancy é muito mais rápido. Como o Azion Edge Functions é executado em todos os nossos pontos de presença, quando uma solicitação chega, a função só precisa ser carregada de nossos discos NVME para a memória, o que leva apenas alguns milissegundos (em oposição às poucas centenas que seriam necessárias para girar um todo recipiente). Isso resulta em menor latência e desempenho mais consistente. Para obter algo assim no Lambda, os clientes precisam pagar taxas adicionais antecipadamente para reservar contêineres dedicados em uma região específica, levando a recursos subutilizados ou problemas de desempenho se a função atingir seu limite de simultaneidade naquela região.
Conclusão
Conforme discutido em nosso post anterior, as aplicações 5G devem atender a padrões incrivelmente altos, com baixa latência, desempenho confiável e eficiência de recursos entre eles. Cumprir essas métricas de desempenho é uma preocupação muito grande, principalmente para aqueles que já tendem a se preocupar muito. Pensamos muito na melhor maneira de entregar essas métricas, construindo nossa stack de software desde o início para atender aos requisitos severos de aplicações da próxima geração, fornecendo uma solução que é 100x mais eficaz do que os provedores de cloud por uma fração do custo.
