Nas publicações anteriores, nós olhamos para o 5G de uma perspectiva de redes: como elas começaram a ser implantadas, o que a implementação implica e como o MEC (Multi-access Edge Computing) pode ajudar os prestadores de serviço a implementar 5G e atingir os padrões de performance 5G.
Contudo, a maneira como a maioria das pessoas usufruirá do 5G não será em função das capacidades que essas redes teoricamente oferecem, mas da performance de aplicações e dispositivos executados nelas. Hoje, mudaremos as perspectivas e olharemos para o 5G do ponto de vista de aplicações.
Este artigo discutirá uma série de aspectos acerca de aplicações modernas: o que significa executá-las no Edge? Como elas são criadas? Quais as possibilidades de implantação? Como aplicações serverless rodam na Plataforma Azion pelo Edge Functions e pela nossa tecnologia central, o Azion Cells.
Executando aplicações no Edge
Atualmente, aplicações nativas de Edge e dispositivos estão abastecendo cidades, redes elétricas e casas inteligentes, e ajudando a transformar as indústrias automotivas, manufatura, varejo e saúde. Se essa lista soa familiar para você é porque ela abrange muitos dos serviços que o 5G está preparado para entregar.
Um dos motivos que levam Edge Computing e 5G a funcionarem tão bem juntos é o propósito dessas tecnologias para resolver os mesmos problemas:
- batalhão de dispositivos móveis e IoTs que cresce sem parar;
- a necessidade de intercomunicação entre máquinas; e
- o anseio por aplicações com cada vez menos latência e mais velocidade de carregamento.
Ao descarregar workloads da nuvem para o edge, desenvolvedores podem assegurar que suas aplicações e dispositivos são capazes de acessar dados com o máxima velocidade, eficiência e eficácia de custos.
Porém, Edge Computing não significa substituir cloud computing, mas complementá-la. O relatório State of the Edge 2020, publicado pela Linux Foundation, prevê que $700 bilhões em investimentos de capital serão aplicados na próxima década com a criação de instalações de data center e edge.
Até 2028, o consumo energético coletivo dessas instalações deverá chegar a 102.000 MW, mas esses megawatts de energia não estarão localizados de forma central como estão com as empresas de nuvem. Em vez disso, infraestruturas de edge e data centers trocarão dimensão por proximidade, dispersando o poder computacional e armazenamento por meio de data centers distribuídos pelo mundo todo para que usuários finais sejam alcançados rapidamente.
Pelo fato de os edge data centers serem muito menores em relação a data centers de cloud hiperescalados, as aplicações hospedadas neles precisam ser incrivelmente leves, usando as menores quantidades de memória e CPU possíveis.
Evolução do desenvolvimento de apps
Inicialmente, se quisesse criar uma aplicação, você precisava ter os seus próprios servidores. Visto que não havia como os servidores demarcarem diferentes aplicações, hospedar múltiplas delas em um mesmo servidor seria um pesadelo para controlar recursos e reforçar segurança. Resultado: cada aplicação necessitava de um próprio servidor, que era assombrosamente caro e deixava muitos recursos ociosos.
A virtualização resolveu esse problema ao isolar aplicações em máquinas virtuais (virtual machines - VMs), permitindo que múltiplas aplicações fossem executadas no mesmo CPU do servidor e levando a melhor aproveitamento dos recursos, custos de hardware menores e mais escalabilidade. VMs são emulações de sistemas computacionais; cada VM abriga não apenas uma aplicação, mas, separadamente, os seus sistemas operacionais próprios. Para economizar energia e custos, duas grandes preocupações com aplicações 5G , as VMs são interrompidas quando a aplicação não está em execução – e reativadas quando solicitada.
Por outro lado, reativar uma VM demanda minutos. Essa é uma grande melhoria em relação aos meses que um novo servidor leva para ser implantado, mas girar as VMs para cima e para baixo só é eficaz para dimensionar e lidar com padrões de uso maiores; fazer isso entre cada solicitação seria desastroso.
Os usuários de hoje abandonam uma página da web que carrega segundos mais lentamente, quanto mais em minutos. Isso para não mencionar os requisitos de latência de apps da próxima geração. Além disso, VMs não foram construídas para lidar com a complexidade de aplicações modernas, que dividem as funcionalidades em componentes pequenos e independentes, chamados microsserviços.
Cada microsserviço é projetado com um único propósito; por exemplo, o Facebook tem microsserviços diferentes para chat, formação de grupos e pagamento de fornecedores terceirizados. Sem ocupar muito espaço em um único servidor, as empresas podem:
- distribuir o trabalho com mais eficácia;
- adicionar recursos;
- corrigir problemas rapidamente; e
- separar processos em vários servidores.
Como as VMs são estritamente segmentadas umas das outras, cada microsserviço tem de ser hospedado em VM separada, resultando nos mesmos problemas de dimensionamento e utilização de recursos que elas foram projetadas para resolver.
Para criar, implantar e dimensionar aplicações com a eficiência e o custo-benefício necessários para 5G, os desenvolvedores devem utilizar soluções modernas e ágeis, como contêineres ou arquiteturas serverless.
Arquitetura baseada em contêiner
Os contêineres são um meio mais leve de implementar virtualização. Eles também são muito mais rápidos para implantar do que VMs, levando segundos para rodar, não minutos. Em vez de empacotar cada aplicação (ou pior, cada microsserviço) com o seu próprio sistema operacional, os contêineres têm propriedades de isolamento que viabilizam sistemas operacionais compartilhados.
Cada microsserviço obtém uma parcela compartilhada de CPU, memória e espaço em disco, resultando em uma unidade completamente funcional que pode ser implantada e gerenciada de forma independente. Entretanto, gerenciar contêineres é uma tarefa complicada, a qual seria frustrante e ineficiente de desempenhar manualmente.
Para evitar essas dores de cabeça, muitos desenvolvedores usam Kubernetes, uma plataforma aberta para gerenciamento de workloads e serviços conteinerizados. Esse orquestrador de contêiner garante que as aplicações funcionem como devem funcionar, mesmo que microsserviços sejam adicionados ou substituídos.
Arquitetura serverless
Aplicações serverless são muito mais leves do que contêineres, dividindo as aplicações em funções que são hospedadas (ironicamente, em servidores) por um provedor. Em vez de hospedar o código e todas as suas dependências, apenas o código em si é armazenado, e ele não precisa ser executado constantemente.
Pelo contrário, funções são ativadas somente quando necessário e implantadas em milissegundos, com o fornecedor cuidando de todos os serviços de backend e cobrando os desenvolvedores utilizando o modelo pay-as-you-go.
O modelo pay-as-you-go é radicalmente diferente do modelo de negócio de contêineres e outros métodos de implantação, os quais requerem desenvolvedores para provisionar recursos. Por exemplo, com contêineres, cada contêiner pode ser movido facilmente e implantado em uma nova máquina e utiliza o seu sistema operacional.
Embora contêineres possam ser movidos facilmente e implantados em uma nova máquina em questão de segundos, os próprios desenvolvedores devem determinar onde os recursos são necessários e pagar por eles antecipadamente. Em contrapartida, funções serverless não são dedicadas a um servidor em particular. Com isso, aplicações podem ser provisionadas pelo fornecedor de forma dinâmica, executando funções conforme a necessidade.
Serverless vs. contêineres
Tanto contêineres quanto serverless são úteis para MEC, porque eles requerem muito menos infraestrutura em comparação a VMs, reduzindo custos e aumentando eficiência. Além disso, ambas as arquiteturas são úteis para aplicações de hoje, dividindo-as em componentes menores. No entanto, quando falamos em escalabilidade, eficiência, custos, facilidade de uso e segurança, há várias diferenças entre eles.
Serverless
As arquiteturas serverless são mais leves do que contêineres, fragmentando ainda mais as aplicações em funções individuais. A implantação é mais rápida, demandando milissegundos em vez de segundos, permitindo aos desenvolvedores escalar ou atender grandes picos de solicitações instantaneamente, criando novas funcionalidades e patches imediatamente, e conservar recursos ao iniciar e parar funções para entregar a requisição conforme necessário.
Além disso, esse gerenciamento de back-end é feito pelo fornecedor de serverless, permitindo que os desenvolvedores se concentrem na funcionalidade da aplicação e assegurando que não se paguem pelo que não utilizam. Por último, os custos iniciais são significativamente reduzidos, pois os desenvolvedores não precisam pagar por recursos dedicados antes da implantação.
Contêineres
Em relação à arquitetura serverless, os contêineres concedem mais controle aos desenvolvedores. Uma vez que o código é empacotado com todas as respectivas dependências, é possível determinar linguagens e bibliotecas por conta própria, facilitando a migração das aplicações de provedores de cloud.
Tamanho controle sobre os serviços de back-end também previne a possibilidade de lock-in de algum fornecedor específico. Diferentemente de funções serverless, contêineres rodam o tempo todo, o que os tornam melhores para processos longos e, dependendo do provedor, pode garantir uma performance mais confiável, pois, quando desligadas por um longo período de tempo, as funções serverless precisam inicializar (processo conhecido como “cold start”).
Por fim, contêineres podem oferecer mais segurança do que a arquitetura serverless se o fornecedor está hospedando um código de múltiplos clientes em um mesmo servidor e não toma as medidas para evitar a exposição de dados entre eles.
Soluções serverless para a próxima geração de aplicações
Quando comparamos os benefícios entre contêineres e serverless para a próxima geração de aplicações, é importante considerar o que é necessário para MEC e 5G. Aplicações têm de ser incrivelmente leves para rodar em infraestruturas de Edge e data centers.
Aplicações 5G, por sua vez, requerem alta mobilidade, sendo executáveis de todo e qualquer lugar com baixa latência e performance consistente, e devem ser econômicas para operar e escalar, considerando a quantidade de dados que serão processados e transmitidos.
Segurança é, também, fator extremamente importante, pois indústrias como a de saúde se beneficiarão de 5G e MEC, possibilitando que pacientes e doutores compartilhem dados médicos instantaneamente.
Dadas essas considerações, serverless tem várias vantagens sobre contêineres: consomem menos recursos, são mais econômicos e operam em todos os lugares, com implantação e escalonamento em milissegundos. Contudo, comparado a contêineres, serverless podem apresentar quedas de performance com cold starts, e hospedando mais de um código de cliente no mesmo servidor pode resultar em problemas de segurança.
Arquitetura serverless sem desvantagens
A nossa solução serverless, o Azion Edge Functions, fornece as vantagens do serverless sem as desvantagens da arquitetura. Nós prevenimos problemas de segurança serverless por meio de sandboxing, que propicia um ambiente seguro para executar funções mesmo quando há muitos inquilinos (exemplo: mais de um cliente) hospedados no mesmo servidor.
Processos que passam por sandbox operam separadamente para que cada pedaço de código não afete ou interaja com os demais. Além disso, o nosso stack de software usa Chrome V8, o motor de JavaScript open-source do Google, que otimiza a execução de JavaScript e garante que o sandboxing não afete a performance. E mais: a nossa tecnologia central, o Azion Cells, é livre de cold start, assegurando que o código seja executado perfeitamente o tempo todo.
No próximo post, mergulharemos profundamente no stack de software da Azion a fim de mostrar a você as decisões que tomamos para garantir que a nossa plataforma serverless forneça mais performance, segurança e flexibilidade.
