Serverless não se trata da ausência física de servidores. Este não é um destruidor de contêineres ou uma tendência passageira. Esta é uma nova abordagem para a construção de sistemas na nuvem. No artigo de hoje abordaremos a arquitetura de aplicativos Serverless, vamos ver qual o papel do provedor de serviços Serverless e dos projetos de código aberto. Finalmente, vamos falar sobre os problemas do uso do Serverless.
Quero escrever uma parte de servidor de um aplicativo (ou até mesmo uma loja online). Pode ser um chat, um serviço de publicação de conteúdo ou um balanceador de carga. De qualquer forma, haverá muitas dores de cabeça: você terá que preparar a infraestrutura, determinar as dependências da aplicação e pensar no sistema operacional host. Então você precisará atualizar pequenos componentes que não afetam a operação do restante do monólito. Bem, não vamos esquecer o dimensionamento sob carga.
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 estão isolados uns dos outros e do sistema operacional host? Dividiremos o monólito em microsserviços, cada um dos quais pode ser atualizado e dimensionado independentemente dos outros. Ao colocar o código nesse contêiner, posso executá-lo em qualquer infraestrutura. Já melhor.
E se você não quiser configurar contêineres? Não quero pensar em dimensionar o aplicativo. Não quero pagar por contêineres ociosos quando a carga do serviço é mínima. Eu quero escrever código. Concentre-se na lógica de negócios e leve produtos ao mercado na velocidade da luz.
Tais pensamentos me levaram à computação sem servidor. Sem servidor, neste caso, significa não a ausência física de servidores, mas a ausência de dores de cabeça no gerenciamento da infraestrutura.
A ideia é que a lógica da aplicação seja dividida em funções independentes. Eles têm uma estrutura de eventos. Cada função executa uma “microtarefa”. Tudo o que é exigido 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 sob demanda em um contêiner preparado automaticamente e pagarei apenas pelo tempo de execução.
Vamos ver como será o processo de desenvolvimento de aplicativos agora.
Do lado do desenvolvedor
Anteriormente começamos a falar sobre um aplicativo para uma loja online. Na abordagem tradicional, a lógica principal do sistema é executada por uma aplicação monolítica. E o servidor com o aplicativo está em constante execução, mesmo que não haja carga.
Para migrar para o serverless, dividimos o aplicativo em microtarefas. Escrevemos nossa própria função para cada um deles. As funções são independentes umas das outras e não armazenam informações de estado (stateless). Eles podem até ser escritos em idiomas diferentes. Se um deles “cair”, todo o aplicativo não irá parar. 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 o ideal é que uma função execute uma. Vamos imaginar que a tarefa seja coletar estatísticas e exibi-las a pedido do usuário. Na abordagem de microsserviços, uma tarefa é executada por um serviço com dois pontos de entrada: escrita e leitura. Na computação sem servidor, essas serão duas funções diferentes que não estão relacionadas entre si. O desenvolvedor economiza recursos de computação se, por exemplo, as estatísticas forem atualizadas com mais frequência do que baixadas.
As funções serverless devem ser executadas em um curto período de tempo (timeout), que é determinado pelo provedor de serviços. Por exemplo, para AWS o tempo limite é de 15 minutos. Isso significa que funções de longa duração terão que ser alteradas para atender aos requisitos – é isso que distingue o Serverless de outras tecnologias populares atualmente (contêineres e Plataforma como Serviço).
Atribuímos um evento a cada função. Um evento é um gatilho para uma ação:
Evento
A ação que a função executa
Uma imagem do produto foi carregada no repositório.
Compacte a imagem e carregue em um diretório
O endereço da loja física foi atualizado no banco de dados
Carregue um novo local nos mapas
O cliente paga pelas mercadorias
Iniciar o processamento do pagamento
Os eventos podem ser solicitações HTTP, streaming de dados, filas de mensagens e assim por diante. As fontes de eventos são alterações ou ocorrências de dados. Além disso, as funções podem ser acionadas por um temporizador.
A arquitetura foi elaborada e o aplicativo quase ficou sem servidor. Em seguida, vamos ao provedor de serviços.
Do lado do provedor
Normalmente, a computação sem servidor é oferecida por provedores de serviços em nuvem. Eles são chamados de forma diferente: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Usaremos o serviço por meio do console do provedor ou da conta pessoal. O código da função pode ser baixado de uma das seguintes maneiras:
- escrever código em editores integrados por meio do console da web,
- baixe o arquivo com o código,
- trabalhar com repositórios git públicos ou privados.
Aqui configuramos os eventos que chamam a função. Os conjuntos de eventos podem diferir para diferentes provedores.
O provedor construiu e automatizou o sistema Function as a Service (FaaS) em sua infraestrutura:
- O código de função acaba armazenado no lado do provedor.
- Quando ocorre um evento, os contêineres com ambiente preparado são implantados automaticamente no servidor. Cada instância de função possui seu próprio contêiner isolado.
- Do armazenamento, a função é enviada para o container, calculada e retorna o resultado.
- O número de eventos paralelos está crescendo – o número de contêineres está crescendo. O sistema é dimensionado automaticamente. Caso os usuários não acessem a função, ela ficará inativa.
- O provedor define o tempo ocioso dos contêineres - se durante esse tempo as funções não aparecerem no contêiner, ele será destruído.
Dessa forma, tiramos o Serverless da caixa. Pagaremos pelo serviço usando o modelo pré-pago e apenas pelas funções que forem utilizadas e apenas pelo tempo em que foram utilizadas.
Para apresentar o serviço aos desenvolvedores, 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, os fundos ou o consumo de energia.
A principal vantagem de trabalhar com um provedor é a possibilidade de não se preocupar com infraestrutura (servidores, máquinas virtuais, containers). Por sua vez, o provedor pode implementar FaaS tanto usando seus próprios desenvolvimentos quanto usando ferramentas de código aberto. Vamos falar mais sobre eles.
Do lado do código aberto
A comunidade de código aberto tem trabalhado ativamente em ferramentas Serverless nos últimos anos. Os maiores players do mercado também contribuem para o desenvolvimento de plataformas serverless:
- Google oferece aos desenvolvedores sua ferramenta de código aberto - . IBM, RedHat, Pivotal e SAP participaram do seu desenvolvimento;
- IBM trabalhei em uma plataforma Serverless , que então se tornou um projeto da Fundação Apache;
- Microsoft abriu parcialmente o código da plataforma .
Desenvolvimentos também estão em andamento na direção de estruturas sem servidor. и implantado em clusters Kubernetes pré-preparados, funciona com Kubernetes e Docker Swarm. A estrutura atua como uma espécie de controlador - mediante solicitação, ela prepara um ambiente de tempo de execução dentro do cluster e, em seguida, inicia uma função lá.
As estruturas deixam espaço para configurar a ferramenta de acordo com suas necessidades. Assim, no Kubeless, um desenvolvedor pode configurar o tempo limite de execução da função (o valor padrão é 180 segundos). A Fission, na tentativa de resolver o problema da partida a frio, sugere manter alguns contêineres funcionando o tempo todo (embora isso implique custos de inatividade de recursos). 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 dos frameworks. Trabalhar com eles requer um pouco mais de habilidade do que trabalhar com um provedor - esta é pelo menos a capacidade de iniciar um cluster Kubernetes por meio da CLI. No máximo, inclua outras ferramentas de código aberto (por exemplo, o gerenciador de filas Kafka).
Independentemente de como trabalhamos com Serverless - por meio de um provedor ou usando código aberto, receberemos uma série de vantagens e desvantagens da abordagem Serverless.
Do ponto de vista das vantagens e desvantagens
Serverless desenvolve as ideias de uma infraestrutura de contêiner e uma abordagem de microsserviço, na qual as equipes podem trabalhar em modo multilíngue sem estarem vinculadas a uma plataforma. Construir um sistema é simplificado e os erros são mais fáceis de corrigir. A arquitetura de microsserviços permite adicionar novas funcionalidades ao sistema com muito mais rapidez do que no caso de um aplicativo monolítico.
Serverless reduz ainda mais o tempo de desenvolvimento, permitindo que o desenvolvedor se concentre exclusivamente na lógica de negócios e na codificação do aplicativo. Como resultado, o tempo de colocação no mercado dos desenvolvimentos é reduzido.
Como bônus, temos escalonamento automático para carga, e pagamos apenas pelos recursos utilizados e apenas no momento em que são utilizados.
Como qualquer tecnologia, Serverless tem desvantagens.
Por exemplo, tal desvantagem pode ser o tempo de inicialização a frio (até 1 segundo em média para linguagens como JavaScript, Python, Go, Java, Ruby).
Por um lado, na realidade, o tempo de arranque a frio depende de muitas variáveis: a linguagem em que a função é escrita, o número de bibliotecas, a quantidade de código, a comunicação com recursos adicionais (as mesmas bases de dados ou servidores de autenticação). Como o desenvolvedor controla essas variáveis, ele pode reduzir o tempo de inicialização. Mas por outro lado, o desenvolvedor não pode controlar o tempo de inicialização do contêiner - tudo depende do provedor.
Uma inicialização a frio pode se transformar em uma inicialização a quente quando uma função reutiliza um contêiner iniciado por um evento anterior. Esta situação surgirá em três casos:
- se os clientes utilizam o serviço com frequência e o número de chamadas para a função aumenta;
- se o provedor, plataforma ou framework permite manter alguns containers rodando o tempo todo;
- se o desenvolvedor executar funções em um cronômetro (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 atraso de um segundo no início nem sempre é crítico para uma aplicação comercial, mas pode se tornar crítico para serviços médicos. Neste caso, a abordagem sem servidor provavelmente não será mais adequada.
A próxima desvantagem do Serverless é o curto tempo de vida de uma função (tempo limite durante o qual a função deve ser executada).
Mas, se você tiver que trabalhar com tarefas de longa duração, poderá usar uma arquitetura híbrida – combinar Serverless com outra tecnologia.
Nem todos os sistemas poderão funcionar usando o esquema Serverless.
Alguns aplicativos ainda armazenarão dados e estado durante a execução. Algumas arquiteturas permanecerão monolíticas e alguns recursos terão vida longa. No entanto (como as tecnologias de nuvem e os contêineres), Serverless é uma tecnologia com um grande futuro.
Nesse sentido, gostaria de passar suavemente à questão do uso da abordagem Serverless.
Do lado do aplicativo
Para 2018, a porcentagem de uso sem servidor . Entre as empresas que já implementaram a tecnologia em seus serviços estão gigantes do mercado como Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Ao mesmo tempo, você precisa entender que Serverless não é uma panacéia, mas uma ferramenta para resolver uma certa gama de problemas:
- Reduza o tempo de inatividade de recursos. Não há necessidade de manter constantemente uma máquina virtual para serviços que possuem poucas chamadas.
- Processe dados em tempo real. Comprima imagens, recorte fundos, altere a codificação de vídeo, trabalhe com sensores IoT, execute operações matemáticas.
- “Colar” outros serviços. Repositório Git com programas internos, chat bot no Slack com Jira e calendário.
- Equilibre a carga. Vamos dar uma olhada mais de perto aqui.
Digamos que existe um serviço que atrai 50 pessoas. Abaixo dela há uma máquina virtual com hardware fraco. De tempos em tempos, a carga do serviço aumenta significativamente. Então o hardware fraco não aguenta.
Você pode incluir um balanceador no sistema que distribuirá a carga, digamos, entre três máquinas virtuais. Nesta fase, não podemos prever com precisão a carga, por isso mantemos uma certa quantidade de recursos funcionando “na reserva”. E pagamos a mais pelo tempo de inatividade.
Nessa situação, podemos otimizar o sistema por meio de uma abordagem híbrida: deixamos uma máquina virtual atrás do balanceador de carga e colocamos um link para o Serverless Endpoint com funções. Se a carga exceder o limite, o balanceador inicia instâncias de função que assumem parte do processamento da solicitação.
Assim, Serverless pode ser usado onde é necessário processar um grande número de solicitações, não com muita frequência, mas de forma intensiva. Neste caso, executar diversas funções durante 15 minutos é mais rentável do que manter uma máquina virtual ou servidor o tempo todo.
Com todas as vantagens da computação sem servidor, antes da implementação, você deve primeiro avaliar a lógica do aplicativo e entender quais problemas o Serverless pode resolver em um caso específico.
Sem servidor e Selectel
Na Selectel já estamos através do nosso painel de controle. Agora estamos construindo nossa própria plataforma FaaS. Queremos que os desenvolvedores possam resolver seus problemas usando Serverless por meio de uma interface conveniente e flexível.
Se você tem ideias sobre qual deveria ser a plataforma FaaS ideal e como deseja usar Serverless em seus projetos, compartilhe-as nos comentários. Teremos em conta os seus desejos ao desenvolver a plataforma.
Materiais utilizados no artigo:
Fonte: habr.com