Sem servidor não é sobre a ausência física de servidores. Este não é um “matador” de contêineres e não é uma tendência passageira. Essa é uma nova abordagem para criar sistemas na nuvem. No artigo de hoje, abordaremos a arquitetura dos aplicativos sem servidor, veremos o papel do provedor de serviços sem servidor e dos projetos de código aberto. No final, falaremos sobre o Serverless.
Eu quero escrever o lado do servidor do aplicativo (sim, mesmo uma loja online). Pode ser um bate-papo, um serviço para publicação de conteúdo ou um balanceador de carga. De qualquer forma, haverá muitas dores de cabeça: você precisará preparar a infraestrutura, determinar as dependências do aplicativo e pensar no sistema operacional host. Então você precisa atualizar pequenos componentes que não afetam o trabalho do resto do monólito. Bem, não vamos esquecer o dimensionamento sob carga.
Mas e se pegarmos contêineres efêmeros nos quais as dependências necessárias já estão pré-instaladas e os próprios contêineres são isolados um do outro e do SO host? Dividiremos o monólito em microsserviços, cada um dos quais pode ser atualizado e dimensionado independentemente dos outros. Depois de colocar o código em um contêiner, posso executá-lo em qualquer infraestrutura. Já está melhor.
E se você não deseja configurar contêineres? Não quero pensar em dimensionar o aplicativo. Não quero pagar por contêineres ociosos quando a carga no serviço é mínima. Eu quero escrever código. Concentre-se na lógica de negócios e no mercado de produtos na velocidade da luz.
Tais pensamentos me levaram à computação sem servidor. Sem servidor, neste caso,
não significa a
ausência física de servidores, mas a ausência de dor de cabeça para gerenciar a infraestrutura.A idéia é que a lógica do aplicativo se decomponha em funções independentes. Eles têm uma estrutura de eventos. Cada uma das funções executa uma "microtask". Tudo o que é necessário do desenvolvedor é carregar as funções no console fornecido pelo provedor de nuvem e correlacioná-las com as fontes de eventos. O código será executado mediante solicitação em um contêiner preparado automaticamente e pagarei apenas pelo tempo de execução.
Vamos ver como será o processo de desenvolvimento de aplicativos.
Do desenvolvedor
Anteriormente, começamos a conversar sobre o aplicativo da loja online. Na abordagem tradicional, a lógica principal do sistema é realizada por uma aplicação monolítica. E o servidor com o aplicativo está em execução constante, mesmo se não houver carga.
Para mudar para sem servidor, dividimos o aplicativo em microtarefas. Sob cada um deles, escrevemos nossa própria função. As funções são independentes uma da outra e não armazenam informações de estado. Eles podem até ser escritos em diferentes idiomas. Se um deles travar, o aplicativo inteiro não será interrompido. A arquitetura do aplicativo ficará assim:
A divisão em funções no Serverless é semelhante ao trabalho com microsserviços. Mas um microsserviço pode executar várias tarefas e, idealmente, uma função deve executar uma. Imagine que a tarefa é coletar estatísticas e exibir a pedido do usuário. Na abordagem de microsserviço, a tarefa é executada por um serviço com dois pontos de entrada: gravação e leitura. Na computação sem servidor, essas serão duas funções diferentes que não estão interconectadas. Um desenvolvedor economiza recursos de computação se, por exemplo, as estatísticas forem atualizadas com mais frequência do que baixadas.
As funções sem servidor devem ser executadas em um curto período de tempo (tempo limite), determinado pelo provedor de serviços. Por exemplo, para a AWS, o tempo limite é de 15 minutos. Isso significa que as funções de longa duração (de longa duração) terão que ser alteradas para atender aos requisitos - esse servidor sem servidor difere de outras tecnologias populares atualmente (contêineres e plataforma como serviço).
Atribuímos um evento para cada função. Um evento é um gatilho para uma ação:
Os eventos podem ser solicitações HTTP, dados de streaming, filas de mensagens e assim por diante. Fontes de eventos são a alteração ou aparência dos dados. Além disso, as funções podem ser executadas pelo timer.
A arquitetura funcionou e o aplicativo quase ficou sem servidor. Em seguida, vamos ao provedor de serviços.
Do provedor
A computação sem servidor geralmente é oferecida por provedores de serviços em nuvem. Eles chamam de maneira diferente: Funções do Azure, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Usaremos o serviço através do console ou da conta pessoal do provedor. O código da função pode ser baixado de uma das seguintes maneiras:
- escreva código em editores internos por meio do console da web,
- Faça o download do arquivo com o código,
- trabalhe com repositórios públicos ou privados do git.
Aqui, configuramos os eventos que chamam a função. Fornecedores diferentes podem ter conjuntos de eventos diferentes.
O provedor em sua infraestrutura criou e automatizou o sistema Função como Serviço (FaaS):
- O código da função chega ao repositório no lado do provedor.
- Quando ocorre um evento, os contêineres com o ambiente preparado são implantados automaticamente no servidor. Cada instância da função possui seu próprio contêiner isolado.
- A partir do armazenamento, a função é enviada para o contêiner, calculado, retorna o resultado.
- O número de eventos paralelos está aumentando - o número de contêineres está aumentando. O sistema é dimensionado automaticamente. Se os usuários não acessarem a função, ela ficará inativa.
- O provedor define o tempo ocioso dos contêineres - se durante esse período as funções não aparecerem no contêiner, ele será destruído.
Portanto, tiramos o Serverless da caixa. Pagaremos pelo serviço de acordo com o modelo de pagamento conforme o uso e somente pelas funções utilizadas, e somente pelo tempo em que foram utilizadas.
Para apresentar aos desenvolvedores o serviço, os provedores oferecem até 12 meses de testes gratuitos, mas limitam o tempo total de computação, o número de solicitações por mês, dinheiro ou consumo de energia.
A principal vantagem de trabalhar com um provedor é a capacidade de não se preocupar com infraestrutura (servidores, máquinas virtuais, contêineres). Por sua vez, o provedor pode implementar o FaaS tanto em seus próprios desenvolvimentos quanto usando ferramentas de código aberto. Falaremos mais sobre eles.
De código aberto
Nos últimos anos, a comunidade de código aberto vem trabalhando ativamente nas ferramentas sem servidor. Em particular, os maiores players do mercado contribuem para o desenvolvimento de plataformas sem servidor:
- O Google oferece aos desenvolvedores sua ferramenta de código aberto - Knative . Seu desenvolvimento envolveu IBM, RedHat, Pivotal e SAP;
- A IBM trabalhou na plataforma OpenWhisk Serverless, que se tornou o projeto Apache Foundation;
- A Microsoft abriu parcialmente o código da plataforma Azure Functions .
Também estão sendo realizados desenvolvimentos na direção de estruturas sem servidor.
O Kubeless e o
Fission são implantados em clusters pré-preparados do Kubernetes, o
OpenFaaS trabalha com o Kubernetes e o Docker Swarm. A estrutura atua como um tipo de controlador - mediante solicitação, prepara o tempo de execução dentro do cluster e executa uma função lá.
As estruturas deixam espaço para a configuração da ferramenta para atender às suas necessidades. Portanto, no Kubeless, o desenvolvedor pode definir o tempo limite para a função ser executada (o valor padrão é 180 segundos). A fissão, na tentativa de resolver o problema das ofertas de partida a frio, mantém parte dos contêineres funcionando o tempo todo (embora isso implique no custo do tempo de inatividade). E o OpenFaaS oferece um conjunto de gatilhos para todos os gostos e cores: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs e outros.
As instruções para começar podem ser encontradas na documentação oficial das estruturas. Trabalhar com eles implica um pouco mais de habilidades do que trabalhar com um provedor - essa é pelo menos a capacidade de iniciar um cluster Kubernetes através da CLI. No máximo, inclua outras ferramentas de código aberto (por exemplo, o gerenciador de filas do Kafka).
Independentemente de como trabalhamos com o Serverless - por meio de um provedor ou usando código aberto, obtemos várias vantagens e desvantagens da abordagem sem servidor.
Do ponto de vista das vantagens e desvantagens
A Serverless desenvolve as idéias de infraestrutura de contêiner e abordagem de microsserviço, nas quais as equipes podem trabalhar no modo multilíngue, sem estarem vinculadas a uma plataforma. A construção de um sistema é simplificada e a correção de erros se torna mais fácil. A arquitetura de microsserviço permite adicionar novas funcionalidades ao sistema muito mais rapidamente do que no caso de um aplicativo monolítico.
O servidor sem servidor reduz ainda mais o tempo de desenvolvimento, permitindo que o desenvolvedor se concentre apenas na lógica e codificação de negócios do aplicativo. Como resultado, o tempo de colocação no mercado para desenvolvimento é reduzido.
Como bônus, obtemos o dimensionamento automático da carga e pagamos apenas pelos recursos utilizados e somente no momento em que são utilizados.
Como qualquer tecnologia, o Serverless tem desvantagens.
Por exemplo, essa desvantagem pode ser um horário de início frio (até 1 segundo em média para idiomas como JavaScript, Python, Go, Java, Ruby).Por um lado, de fato, o tempo de partida a frio depende de muitas variáveis: o idioma em que a função é escrita, o número de bibliotecas, a quantidade de código, a comunicação com recursos adicionais (os mesmos bancos de dados ou servidores de autenticação). Como o desenvolvedor controla essas variáveis, ele pode reduzir o horário de início. Mas, por outro lado, o desenvolvedor não pode controlar o tempo de inicialização do contêiner - tudo depende do provedor.
Uma partida a frio pode se tornar quente quando a função reutilizar o contêiner iniciado pelo evento anterior. Esta situação ocorrerá em três casos:
- se os clientes costumam usar o serviço e o número de chamadas para a função está aumentando;
- se o provedor, plataforma ou estrutura permitir que você mantenha parte dos contêineres em execução o tempo todo;
- se o desenvolvedor executar funções de timer (digamos, a cada 3 minutos).
Para muitas aplicações, uma partida a frio não é um problema. Aqui você precisa desenvolver o tipo e as tarefas do serviço. Um início atrasado por um segundo nem sempre é crítico para um aplicativo de negócios, mas pode se tornar crítico para serviços médicos. Provavelmente, nesse caso, a abordagem sem servidor não será mais adequada.
A próxima desvantagem do Serverless é a curta vida útil da função (o tempo limite para o qual a função deve ser executada).Mas, se você precisar trabalhar com tarefas de longa duração, poderá usar uma arquitetura híbrida - combine o Serverless com outra tecnologia.
Nem todos os sistemas poderão funcionar de acordo com o esquema sem servidor.Alguns aplicativos ainda armazenam dados e status em tempo de execução. Algumas arquiteturas permanecerão monolíticas e algumas funções terão vida longa. No entanto (como costumavam ser as tecnologias em nuvem e depois os contêineres), o Serverless é uma tecnologia com um grande futuro.
Nesse sentido, gostaria de passar sem problemas à questão da aplicação da abordagem sem servidor.
No lado da aplicação
Em 2018, a porcentagem de uso sem servidor
aumentou uma vez e meia . Entre as empresas que já implementaram a tecnologia em seus serviços, existem gigantes do mercado como Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Ao mesmo tempo, você precisa entender que o Serverless não é uma panacéia, mas uma ferramenta para resolver uma certa variedade de tarefas:
- Reduza os recursos de tempo de inatividade. Você não precisa manter constantemente a máquina virtual sob serviços que não são muito acessados.
- "On the fly" processa os dados. Comprima imagens, corte o fundo, altere a codificação de vídeo, trabalhe com sensores de IoT, execute operações matemáticas.
- Cole outros serviços. Repositório Git com programas internos, bot de bate-papo no Slack com Jira e com um calendário.
- Equilibre a carga. Aqui nós moramos com mais detalhes.
Digamos que exista um serviço ao qual 50 pessoas venham. Abaixo dela, há uma máquina virtual com hardware fraco. Periodicamente, a carga no serviço aumenta significativamente. Então o ferro fraco não aguenta.
Você pode incluir um balanceador no sistema que distribuirá a carga, por exemplo, para três máquinas virtuais. Nesse estágio, não podemos prever com precisão a carga, por isso mantemos uma certa quantidade de recursos em execução "em reserva". E pague demais pelo tempo de inatividade.
Nessa situação, podemos otimizar o sistema por meio de uma abordagem híbrida: para o balanceador de carga, deixamos uma máquina virtual e colocamos um link para o Serverless Endpoint com funções. Se a carga exceder o limite, o balanceador lança instâncias de funções que participam de parte do processamento da solicitação.
Assim, o Serverless pode ser usado onde não é muito frequente, mas para processar um grande número de solicitações intensivamente. Nesse caso, executar várias funções por 15 minutos é mais rentável do que manter uma máquina ou servidor virtual o tempo todo.
Com todas as vantagens da computação sem servidor, antes de implementá-la, você deve primeiro avaliar a lógica do aplicativo e entender quais tarefas o Serverless pode resolver em um caso específico.
Sem servidor e Selectel
Na Selectel, já
facilitamos o trabalho com o Kubernetes em uma
nuvem virtual privada através do nosso painel de controle. Agora estamos construindo nossa própria plataforma FaaS. Queremos que os desenvolvedores consigam resolver seus problemas com o Serverless por meio de uma interface conveniente e flexível.
Deseja acompanhar o processo de desenvolvimento da nova plataforma FaaS? Assine o boletim informativo Selectel "Cloud Functions"
na página de serviço . Falaremos sobre o processo de desenvolvimento e anunciaremos o lançamento fechado do Cloud Functions.
Se você tiver alguma idéia de qual deve ser a plataforma FaaS ideal e como deseja usar o Serverless em seus projetos, compartilhe-os nos comentários. Nós levaremos em consideração seus desejos ao desenvolver a plataforma.
Materiais utilizados no artigo: