Este ano,
traduzimos um artigo sólido sobre o conceito Serverless: o autor mostrou em seus dedos o que é e por quê. Também sabemos e lembramos que nossos parceiros europeus batizaram nossa plataforma como
CPaaS sem servidor - para confirmar explicitamente isso, nosso CEO Alexei Aylarov falou na conferência
API Days em Amsterdã, em 16 de outubro. Alexey explicou por que o CPaaS sem servidor em breve será onipresente e como foi constatado que o Voximplant - de repente - desde o início personificou essa abordagem. Abaixo do recorte, você encontrará uma adaptação em texto do discurso, trechos da apresentação em anexo. Bem vindo!
Costumava ser melhor (c)
Antes do CPaaS, os negócios eram obrigados a fazer muito trabalho preparatório: para começar, era necessário escolher uma operadora de telecomunicações. Você deve escolher um back-end e criar uma infraestrutura para tudo isso (por exemplo, pegue o PBX e o arquivo do software Asterisk / FreeSWITCH). Para ajudar esse PBX também a aumentar o back-end no node.js condicional ... E somente depois disso, decida onde e como a lógica de negócios será implementada e, em seguida, implante-a, configure o monitoramento e garanta que ela não trava durante o trabalho. Pode levar meio ano ou mais para lançar uma solução pronta para uso.
O CPaaS tornou possível pular as etapas de baixo nível e iniciar imediatamente a lógica de negócios: para isso, o cliente precisava estudar a plataforma de comunicação e, em seguida, ... infraestrutura, implantação, monitoramento. Por um lado, você não precisa pensar em qual será o back-end e procurar um operador de telecomunicações. Devido a isso, o tempo de inicialização é reduzido sem perda de qualidade. Por outro lado, ainda há muito a ser feito de lado.
Bem-vindo sem servidor
E então sem servidor aconteceu. E aqui precisamos nos concentrar no ponto principal - por que menos? Os cálculos precisam ser feitos em algum lugar.
Sem servidor significa não a ausência de servidores, mas a ausência deles no lado do cliente.
O conceito envolve um monte de provedor de computação + devops no lado do cliente. O cliente não precisa manter sua própria infraestrutura, basta pagar o provedor de computação para ... computação :) Ou seja, só existem custos quando há necessidade de computação - é muito mais lucrativo do que, por exemplo, pagar aluguel de servidor 24 horas por dia, 7 dias por semana, quando não há necessidade real use esses servidores 24/7. A falta de infraestrutura leva à segunda vantagem importante da abordagem: você não pode pensar em escalabilidade, porque O provedor fornece escalonamento automático.
Para desenvolvedores, eles geralmente usam uma estrutura sem servidor (por exemplo,
Projeto Fn ou
sem servidor - ah, ironia), que simplifica o desenvolvimento e a montagem de aplicativos. Além disso, a estrutura pode fornecer identificadores para eventos; isso é conveniente porque sem servidor é apenas um conceito baseado em evento (exemplos de telefonia: uma chamada chegou - este é um evento, atendeu uma chamada - este é um evento etc.).
Adicione recursos sem servidor ao CPaaS e obtenha Voximplant condicional. Como resultado, a etapa de "infraestrutura" desaparece - a empresa estuda um CPaaS específico sem servidor, implementa a lógica de negócios e monitora silenciosamente como funciona, sem se preocupar em comprar racks, servidores, encontrar uma sala para uma sala de servidores etc. Obviamente, esse é um caso ideal e cada solução é única: é possível que o cliente precise de algum tipo de hardware do seu lado, mas o Serverless faz todos os esforços para garantir que os clientes não tenham essas necessidades.
Melhorando a experiência do usuário
Às vezes, as plataformas sem servidor fazem o chamado As funções são intermediárias entre o cliente e outros serviços (conceito
FaaS ). Por exemplo, as Funções podem ser instruídas a aceitar solicitações HTTP e fornecer uma resposta ou interagir via HTTP com serviços de terceiros. Webhooks e interações específicas de telecomunicações também podem ser processados aqui.
No entanto, essa camada tem limitações:
- prazo de entrega limitado;
- contexto imutável (apátrida);
- o processamento de chamadas é separado do tempo de execução da plataforma porque a comunicação é feita por HTTP.
Desde o início, a arquitetura Voximplant tornou o tempo de execução acessível aos clientes, portanto, o controle de chamadas é feito usando scripts JS, em vez de HTTP seco. O tempo de execução integrado oferece várias vantagens:
- Os scripts Cloud JS suportam o padrão de idioma mais recente - ECMA2018;
- scripts usam a API da plataforma nativa ;
- controle em tempo real: o processamento de eventos e a execução de funções ocorrem instantaneamente;
- é possível usar um depurador com uma quebra e estados;
- Você pode anexar qualquer coisa ao tratamento de erros, incluindo alertas de voz para uma pessoa. Um exemplo de tratamento de erros com base em eventos:
function onHttpRequestFailed() { call.say(“Unfortunately, we couldn't process your request, please try again later”, Language.US_ENGLISH_FEMALE) call.addEventListener(CallEvents.PlaybackFinished,(e) => { if (destroy) VoxEngine.terminate() else tryAgain() }) }
Baseado em eventos é especialmente importante porque a) essa é uma abordagem unificada b) adiciona flexibilidade. Qualquer ação pode ser interpretada como um evento e processada em um script JS baseado em nuvem: atenda a chamada com síntese de voz, reconheça o correio de voz e desligue, encaminhe a chamada para SIP, notificação por push, etc.
Como resultado, nossa plataforma sem servidor reduz a latência, melhora a experiência do usuário e, por fim, reduz o tempo de lançamento do produto acabado o máximo possível: se na "era pré-CPaaS'nuyu", isso pode levar seis meses, então com o Voximplant você pode
conhecer 1 mês ( incluindo todas as aprovações e reuniões, o tempo de desenvolvimento imediato é ainda menor).
O futuro
As plataformas de comunicação baseadas em servidor serão cada vez mais demandadas porque a demanda por esses serviços está crescendo, bem como a funcionalidade das próprias plataformas. Em breve, o CPaaS sem servidor poderá oferecer armazenamento de dados, profunda integração com sistemas externos (nosso
Dialogflow Connector é um bom exemplo), funcionalidade do servidor da web, finalmente :) As perspectivas são boas, só podemos monitorar a implementação e aproveitar o progresso do conceito sem servidor.