Infraestrutura > Servidores

AWS, Google Cloud ou Microsoft Azure: qual o serverless ideal para sua empresa?

Conheça as principais diferenças entre as ofertas das três gigantes

28 de Março de 2018 - 09h38

Se você já foi acordado às 3 da manhã porque um servidor ficou descontrolado, entenderá o apelo de uma palavra de ordem como "serverless". As máquinas podem levar horas, dias ou às vezes até semanas para serem configuradas, e então precisarão ser atualizado constantemente para corrigir bugs e falhas de segurança. Essas atualizações geralmente trazem dificuldades por conta própria, porque as novas atualizações causam incompatibilidades, forçando outras atualizações em um ad infinitum.

A cadeia infinita de dores de cabeça causadas pela execução de um servidor é uma das razões pelas quais as principais empresas de nuvem adotaram a arquitetura “serverless”. Eles sabem que o chefe ouviu as desculpas - foi o servidor - por muito tempo. Se pudéssemos nos livrar desses servidores...

O serverless é um ótimo termo de vendas, com um único problema, estritamente verdadeiro. Os aplicativos são serverless da mesma forma que os restaurantes não têm cozinha. Se o que você quer está no cardápio e você gosta de como o cozinheiro o prepara, sentar em um restaurante é ótimo. Mas se você quiser um prato diferente, se você quiser especiarias diferentes, bem, é melhor você ter sua própria cozinha.

Amazon, Google e Microsoft são três das maiores empresas que estão lutando para hospedar aplicativos do futuro, aqueles que eles esperam que sejam gravados em sua API serverless e gerenciados através de sua camada de automação. Se as plataformas fizerem o que você quer - e os novos modelos são bem gerais - elas podem ser a maneira mais simples e rápida de criar seu próprio aplicativo web multibilionário. Você escreve apenas os bits cruciais da lógica e a plataforma lida com todos os detalhes.

As funções serverless estão se tornando a linguagem de cola ou de script que liga todos os recursos da nuvem. O mapeamento ou ferramentas de AI que antes eram bastante independentes agora estão vinculados por meio das funções serverless  orientadas a eventos. Mais do seu trabalho pode ser resolvido por pedidos que se propagam e saltam pelos vários cantos de cada nuvem, acionando e sendo acionados por um fluxo de eventos. Se você quiser explorar o Machine Learning e usá-lo para analisar seus dados, uma das maneiras mais rápidas de fazer isso é criar um aplicativo sem servidor e começar a enviar eventos para o canto de aprendizado de máquina da nuvem.

A promessa implícita é que deixar tudo mais fluido torna mais fácil compartilhar recursos na nuvem. No passado, todo mundo estaria criando freneticamente novas instâncias com, digamos, o Ubuntu Server rodando em sua própria máquina virtual. Todo mundo usou o mesmo sistema operacional e foi duplicado um zilhão de vezes na mesma caixa real que estava fingindo ser uma dúzia ou mais de caixas virtuais do Ubuntu. Operações serverless evitam toda essa duplicação, tornando a computação em nuvem drasticamente mais barata, especialmente para trabalhos que são executados esporadicamente e nunca ocupam a caixa antiga instalada em sua sala de servidores com ar condicionado.

Claro que toda essa conveniência tem um custo oculto. Se você quiser sair ou mover seu código para outro site, provavelmente ficará preso reescrevendo a maior parte da pilha. As APIs são diferentes e, embora haja alguma padronização em torno de linguagens populares como o JavaScript, elas são muito semelhantes às proprietárias. Há muitas oportunidades para o aprisionamento.

Para entender o apelo das opções sem servidor, passei algum tempo desenvolvendo algumas funções e vasculhando as pilhas. Não escrevi muito código, mas esse era o ponto. Passei mais tempo clicando nos botões e digitando em formulários da web para configurar tudo. Você se lembra de quando configuramos tudo com XML e, em seguida, JSON? Agora, preenchemos um formulário da web e a nuvem faz isso por nós. Você ainda tem que pensar como um programador, no entanto, para entender o que está acontecendo nos bastidores e além do seu controle.

AWS Lambda
O AWS Lambda está crescendo na camada shell script da nuvem da Amazon. É um sistema básico que permite incorporar funções que respondem a eventos que podem ser gerados por quase qualquer parte da vasta infraestrutura de nuvem da Amazon. Se um novo arquivo é carregado para o S3, você pode ativar uma função que faça algo interessante com ele. Se algum vídeo estiver sendo transcodificado pelo Amazon Elastic Transcoder, você pode ter uma função do Lambda esperando para ser acionada quando terminar. Essas funções, por sua vez, podem acionar outras operações do Lambda ou talvez enviar uma atualização para alguém.

Você pode escrever as funções do Lambda em JavaScript ( Node.js ), Python, Java, C # e Go. Dado que essas linguagens podem incorporar muitas outras linguagens, é bem possível executar outros códigos como Haskell, Lisp ou até mesmo C ++.

Escrever funções do Lambda geralmente é muito mais complexo do que o esperado, pois a Amazon oferece muitas opções de configuração e otimização. Embora seja tecnicamente verdade que você pode escrever apenas algumas linhas de código e realizar grandes coisas, eu senti como se tivesse que alocar mais tempo para configurar como o código é executado. Muito disso é realizado pelo preenchimento de formulários no navegador, em vez de digitar em arquivos de texto. Às vezes parece que acabamos de trocar um editor de texto por um formulário web, mas esse é o preço de reter toda a flexibilidade que a Amazon estende ao usuário do Lambda.

Algumas das etapas adicionais se devem ao fato de a Amazon expor mais opções ao usuário e esperar mais do gravador de funções na primeira vez. Uma vez que terminei de escrever uma função no Google ou na Microsoft, eu poderia apontar meu navegador para a URL correta e testá-la imediatamente. A Amazon me fez clicar para configurar o gateway da API e abrir o buraco certo no firewall.

A página de configuração do AWS Lambda permite clicar na origem dos eventos que acionam uma função e no destino de mais eventos.

No final, todo esse clique adiciona uma camada de suporte para a mão que torna o trabalho um pouco mais fácil do que começar com um arquivo de texto. Quando eu estava criando uma função, o navegador enviou um aviso: "Esta função contém bibliotecas externas." Nos dias de Node puro, isso era algo que eu deveria saber, ou que eu aprenderia pesquisando mensagens de erro enquanto cruzava os dedos e esperava que a resposta estivesse lá fora. Agora a nuvem nos auxilia.

A Amazon tem várias outras opções que são praticamente "serverless r" como o AWS Lambda, se considerarmos que serverless também signifique liberá-lo das tarefas de gerenciamento do servidor. Tem ferramentas elásticas como o Amazon EC2 Auto Scaling e o AWS Fargate que acionam e desligam servidores, e o AWS Elastic Beanstalk , que pega o código carregado, implanta-o em servidores da Web e lida com o balanceamento de carga e dimensionamento. Naturalmente, com muitas dessas ferramentas de automação, você ainda é responsável pela criação da imagem do servidor.

Uma das ofertas mais úteis é o AWS Step Functions , uma espécie de ferramenta de fluxograma sem código para criar states machines para modelar o que os arquitetos de software chamam de fluxo de trabalho. Parte da questão é que todas as funções sem servidor devem ser totalmente livres de estado, algo que funciona quando você está impondo lógica de negócios bem básica, mas isso pode ser um pesadelo quando você está lidando com algum cliente através de um lista de verificação ou um fluxograma. Você está constantemente indo para o banco de dados para recarregar as informações sobre o cliente.

Google Cloud Functions e Firebase
Se se livrar do incômodo de configurar servidores é o seu objetivo, a Google Cloud tem vários serviços que oferecem várias liberdades, como a necessidade de uma senha de root ou até mesmo a utilização de uma linha de comando.

Começando com a Google App Engine em 2008, o Google vem adicionando lentamente diferentes opções "sem servidor" com várias combinações de mensagens e transparência de dados. A Google Cloud Pub/Sub oculta a fila de mensagens, portanto, tudo o que você precisa fazer é escrever o código para o produtor e o consumidor de dados. O Google Cloud Functions oferece computação orientada a eventos para muitos dos principais produtos, incluindo algumas marquee tools e APIs. Além disso, há o Google Firebase , um banco de dados que permite combinar o código JavaScript em uma camada de armazenamento de dados que entrega os dados ao seu cliente.

Destes, o Firebase é o mais intrigante para mim. Alguns sugerem que os bancos de dados eram o aplicativo sem servidor original, abstraindo as estruturas de dados e as tarefas de armazenamento em disco para fornecer todas as informações por meio de uma porta TCP-IP. O Firebase leva essa abstração ao extremo, adicionando também código JavaScript e mensagens para fazer quase tudo o que você pode querer fazer com a infraestrutura do lado do servidor, incluindo a autenticação. Tecnicamente é apenas um banco de dados, mas é um que pode lidar com grande parte da lógica de negócios e mensagens para sua pilha. Você pode se safar com um pouco de HTML, CSS, JavaScript e Firebase.

O código Firebase é escrito em JavaScript por isso vai ser executado em uma versão local do Node.js . Você pode incorporar grande parte da lógica de negócios nessa camada porque o mundo do Node já está cheio de bibliotecas para lidar com esse fluxo de trabalho. Além disso, você estará aproveitando os prazeres do código isomórfico que é executado no cliente, no servidor e agora no banco de dados.

A parte que chamou minha atenção foi a camada de sincronização incorporada ao Firebase. Ele sincroniza cópias de objetos do banco de dados em toda a rede. O truque é que você pode configurar seu aplicativo cliente como apenas outro nó de banco de dados que assina todas as alterações para os dados relevantes (e apenas os dados relevantes). Se os dados mudarem em um lugar, mudarão em todos os lugares. Você pode evitar todos os aborrecimentos das mensagens e se concentrar apenas em escrever as informações no Firebase, pois o Firebase irá replicá-las onde precisar.

O Google Firebase fornece um console de erros que mostra uma linha do tempo para bons e maus eventos à medida que eles se desdobram.

Você não precisa se concentrar apenas no Firebase. O mais básico da Google Cloud Functions é uma abordagem mais simples para incorporar código personalizado em toda a nuvem do Google. No momento, a Cloud Functions é, em grande parte, apenas uma opção para gravar o código Node.js que será executado em um ambiente Node pré-configurado. Embora o restante da Google Cloud Platform suporte uma ampla variedade de idiomas, de Java e C # até Go, Python e PHP, a Cloud Functions é estritamente limitado a JavaScript e Node. Há indícios de que outras opções de idiomas estão chegando e eu não ficaria surpreso se elas aparecerem em breve.

A Google Cloud Functions não atinge tão profundamente a Google Cloud quanto a AWS Lambda chega ao AWS, pelo menos neste momento. Quando analisei a criação de uma função para interagir com o Google Docs, descobri que provavelmente teria que usar a API REST e escrever o código em algo chamado Apps Script. Em outras palavras, o mundo do Google Docs tem sua própria API REST que era sem servidor muito antes da palavra-chave ser inventada.

Vale a pena notar que a Google App Engine continua forte. No começo, ela oferecia apenas aplicativos Python para atender à demanda de qualquer um que chegasse ao site, mas foi estendida ao longo dos anos para lidar com vários tempos de execução de linguagem diferentes. Depois que você agrupa seu código em um executável, a Google App Engine dispara o processo de iniciar nós suficientes para lidar com seu tráfego, aumentando ou diminuindo à medida que os usuários enviam solicitações.

Há alguns obstáculos deve ter em mente. Assim como noa Cloud Functions, seu código deve ser gravado de forma relativamente sem estado e deve concluir cada solicitação em um período de tempo limitado. Mas a App Engine não afasta todo a estrutura ou esquece tudo entre os pedidos. A App Engine é uma peça importante da revolução sem servidor e continua sendo a mais acessível para aqueles que mantêm um pé no antigo método de construir sua própria pilha em Python, PHP, Java, C # ou Go.

Microsoft Azure Functions
A Microsoft, é claro, está trabalhando da mesma maneira que os outros para garantir que as pessoas possam fazer todas essas coisas inteligentes sem servidor com a nuvem Azure. A empresa criou suas próprias funções básicas para eventos - as Azure Functions - e criou algumas ferramentas sofisticadas que são ainda mais acessíveis aos programadores.

A maior vantagem que a Microsoft pode ter pode ser sua coleção de aplicativos Office, os antigos executáveis ​​de área de trabalho que estão lenta mas seguramente migrando para a nuvem. De fato, uma recente contabilização das receitas da Microsoft na nuvem a colocou à frente da Amazon, em parte incluindo algumas das receitas do Office na rubrica efêmera da “nuvem”.

Um dos melhores exemplos da documentação do Azure Functions mostra como uma função de nuvem pode ser acionada quando alguém salva uma planilha no OneDrive. De repente, os pequenos elfos da nuvem ganham vida e fazem coisas na planilha. Isso certamente será uma dádiva para as áreas de TI que apoiam equipes que adoram suas planilhas do Excel (ou outros documentos do Office). Eles podem escrever as Azure Functions para fazer praticamente qualquer coisa. Muitas vezes pensamos que o HTML e a Web são a única interface para a nuvem, mas não há razão para que isso não possa ser feito por meio de formatos de documentos como o Microsoft Word ou o Excel.

O Logic Apps do Azure chamou minha atenção como uma das ferramentas que permite preencher formulários, em vez de se preocupar com semântica e sintaxe. Você ainda precisa pensar como um programador e tomar decisões inteligentes sobre abstrações e dados, mas pode se convencer de que não está escrevendo “código” e sim preenchendo formulários.

Como as AWS Step Functions, o Logic Apps destina-se a codificar “fluxos de trabalho”, uma palavra de ordem que é um pouco mais complexa do que a “função” média que é discutida, graças à disponibilidade de algum estado. Você ainda pode escrever uma lógica que ligue várias funções e conectores de uma forma semelhante a um fluxograma, mas você não a soletra tanto em uma linguagem tradicional.

A grande vantagem dos Logic Apps são os “conectores” pré-construídos que exploram alguns dos maiores aplicativos da Microsoft e de terceiros que estão por aí. Você pode efetivamente enviar ou extrair dados para e de seus aplicativos lógicos, como Salesforce, Twitter e Office 365. Essas conexões serão muito valiosas para os funcionários de TI da empresa que agora podem vincular ferramentas externas ao escrever aplicativos lógicos da mesma forma como criavam shell scripts no passado.

Outra parte intrigante do Azure é o Azure Cosmos DB , um banco de dados NoSQL e SQL ao mesmo tempo. A Microsoft duplicou as APIs do Cassandra e do MongoDB para que você possa inserir e retirar informações sem reescrever o código do Cassandra ou do MongoDB. Ou se você quiser escrever SQL, você pode fazer isso também. O Cosmos DB mantém tudo em ordem e constrói índices para para manter tudo funcionando rapidamente. Isso faz com que seja um nexo central intrigante se você tiver muitos códigos SQL e NoSQL que deseja colocar trabalhando juntos. Ou talvez você só queira deixar a porta aberta para diferentes abordagens no futuro.

Comparação das plataformas 
Qual plataforma sem servidor é ideal para você? Escrever funções básicas é praticamente igual em todos os três silos, mas existem diferenças. As mais óbvias podem ser os idiomas disponíveis, porque cada uma tem seus idiomas favoritos depois de terminar o suporte ao Node.js e ao JavaScript. Não é surpreendente que você possa escrever C # para o Azure da Microsoft, mas seu suporte para F # e TypeScript é exclusivo. A Amazon abrange Java, C # e Python. No momento, a Google está estritamente limitada ao JavaScript por suas funções básicas, embora ela ofereça suporte a muitos outros idiomas no App Engine.

A parte mais difícil de comparar as nuvens sem servidor é obter um controle sobre preço e velocidade, porque muito mais está oculto sob o capô. Muitas vezes me senti como um gastador louco quando lidava com instâncias de VM que foram cotadas em centavos por hora. Agora os provedores estão fatiando o salame tão finamente que você pode obter centenas de milhares de chamadas de função por menos de um dólar. Você vai estar jogando em torno da palavra "milhões", como o Dr. Evil nos filmes "Austin Powers".

É claro que esse aparente baixo custo logo engana a parte racional e consciente do orçamento de nosso cérebro, como quando estamos de férias em um país estranho com denominações de moeda bastante diferentes. Em breve, você estará pedindo mais um milhão de chamadas de banco de dados, assim como você comprou uma rodada de bebidas no bar em Cancun, porque você não conseguiu descobrir o custo real a tempo.

Quando a nuvem apenas vendia uma máquina virtual, você podia adivinhar oquanto pagaria observando a quantidade de memória RAM e a potência da CPU, mas no mundo sem servidor você não tem a menor ideia do que está acontecendo.

Vale a pena notar que o modelo sem servidor praticamente obriga você a esconder dados no banco de dados da nuvem local, porque você não tem permissão para manter qualquer estado com seu código. Você tem que confiar nesses fins. Sua função deve ser executada sem nenhum caching ou configuração local porque outras versões estão sempre sendo criadas e destruídas. Assim, o código de cola de banco de dados preenche seu código como aquelas videiras em Upside Down em "Stranger Things".

A única maneira real de comparar custos é criar seu aplicativo em todas as plataformas, um desafio assustador. É possível mover um pouco do código entre os três porque todos eles executam o Node.js , mas mesmo assim você encontrará diferenças.

A boa notícia é que você não precisa ser tão paranóico. Nos meus experimentos, muitos aplicativos básicos usaram quase nenhum recurso e você pode percorrer um longo caminho nas camadas gratuitas que todos os três oferecem para atrair desenvolvedores ruins. O modelo serverless realmente está nos poupando de alguma sobrecarga. A menos que você seja do tipo que executava seus servidores quase todo o tempo, é provável que você acabe economizando um bom dinheiro migrando para uma abordagem sem servidor. Você estará economizando tanto dinheiro que não vai querer discutir se o custo será um dólar por milhão de chamadas ou 1,50.

Existe um problema mais profundo. Se você se cansar o suficiente de qualquer uma dessas nuvens, você está praticamente preso. Não é fácil retirar o código e executá-lo em um servidor comum em outro lugar, algo que você pode fazer com um contêiner Docker preenchido com seu próprio código. Se tiver sorte, você pode duplicar a mesma arquitetura bruta e as funções básicas do JavaScript, mas depois disso você estará reescrevendo o código de cola do banco de dados em tqualquer lugar. Todas as três empresas têm suas próprias camadas proprietárias de armazenamento de dados.

Também não está claro o que acontece quando as coisas dão errado. Executar seu próprio servidor significa que, bem, seu chefe pode sufocar seu pescoço quando ele não funciona. Não está tão claro o que acontece neste espaço. Uma página no Google contém este aviso benigno: "Esta é uma versão beta da Google Cloud Functions. Essa API pode ser alterada de maneira incompatível com versões anteriores e não está sujeita a nenhum SLA ou política de suspensão. ”

Os termos de serviço da Amazon ficaram melhores do que quando entraram no ar pela primeira vez, mas ainda incluem avisos para se lembrar de qu eles podem “excluir, com um aviso prévio de 30 dias e sem responsabilidade de qualquer tipo, qualquer um dos seus conteúdos carregado para o AWS Lambda se ele não tiver sido executado por mais de três (3) meses. ”Verifique se o seu código é executado se você quiser mantê-lo por perto. Avisos como este são certamente justos (eu sei que minhas funções antigas do Lambda nunca serão usadas novamente), mas mostra como você está cedendo algum controle.

A Microsoft oferece um contrato de acordo de nível de serviço para o Azure que promete compensação financeira por tempo de inatividade por meio de créditos de serviço. Isso se aplicará quando suas funções caírem? Talvez - desde que você não passe por uma área beta do serviço. Vale a pena gastar um pouco de tempo prestando atenção a esses detalhes se você estiver criando algo mais importante do que uma sala de bate-papo para crianças.

Na maioria dos casos, a comparação real que você deseja fazer é entre os outros recursos e serviços das nuvens Amazon, Google e Microsoft, não a camada de função. A capacidade de acionar Azure Functions com arquivos do Office no OneDrive será uma grande atração se você oferecer suporte a pessoas que adoram seus aplicativos do Office. O Google Firebase facilita o uso de funções para fornecer serviços de suporte, como mensagens e autenticação para aplicativos da web. O AWS Lambda usa tantos serviços da Amazon que faz realmente parecer que o céu é o limite.

É tecnicamente possível misturar e combinar todas essas nuvens e funções, pois todas elas falam a mesma linguagem PUT e GET das chamadas HTTP API. Não há nenhuma razão para você não conseguir juntar um aplicativo com microsserviços que misture o melhor das três nuvens. Mas você acabará com uma latência maior à medida que os pacotes deixem as nuvens locais e percorram a vastidão da Internet aberta. E depois haverá pequenas diferenças na análise e na estrutura.

Por isso, provavelmente faz sentido ficar na seção segura de uma única nuvem, pelo menos quando se trata de aplicativos bastante interconectados. Você realmente gosta do Google Maps e quer usá-lo para o seu projeto? Então, você também pode usar a Google Cloud Functions, mesmo que, no fundo, prefira usar o F # com as Funções do Azure da Microsoft. O mesmo vale para o reconhecimento de voz da Amazon ou para a API de análise de imagens do Google ou para qualquer um das dezenas de diferentes serviços e APIs de Machine Learning. As funções não são tão importantes - é o que elas conectam que realmente importa.