Pontos chave
- Por vários anos, prometemos que a computação sem servidor dará início a uma nova era sem um sistema operacional específico para a execução de aplicativos. Disseram-nos que essa estrutura resolveria muitos problemas de escalabilidade. Na verdade, tudo é diferente.
- Embora muitos vejam a tecnologia sem servidor como uma ideia nova, suas raízes podem ser rastreadas até 2006, quando Zimki PaaS e o Google App Engine foram introduzidos, ambos os quais usam uma arquitetura sem servidor.
- Existem quatro razões pelas quais a revolução sem servidor estagnou, desde o suporte limitado para linguagens de programação até problemas de desempenho.
- A computação sem servidor não é tão inútil. De modo nenhum. No entanto, eles não devem ser vistos como uma substituição direta dos servidores. Para alguns aplicativos, eles podem ser uma ferramenta útil.
O servidor está morto, viva o servidor!
Este é o grito de guerra dos adeptos da revolução sem servidor. Com uma rápida olhada na imprensa do setor nos últimos anos, é fácil concluir que o modelo de servidor tradicional está morto e que em alguns anos estaremos todos usando arquiteturas sem servidor.
Como qualquer pessoa do setor sabe, e também apontamos em nosso artigo sobre o estado da computação sem servidor , esse não é o caso. Apesar de muitos artigos sobre os méritos da revolução sem servidor , ela nunca se materializou . Na verdade, pesquisas recentes sugerem que essa revolução pode ter chegado a um impasse.
Algumas das promessas para modelos sem servidor, sem dúvida, foram cumpridas, mas não todas. Nem todos.
Neste artigo, quero considerar as razões dessa condição. Por que a falta de flexibilidade dos modelos sem servidor ainda é um obstáculo para sua adoção mais ampla, embora continuem úteis em circunstâncias específicas e bem definidas.
O que os defensores da computação sem servidor prometeram
Antes de entrar nos problemas de computação sem servidor, vamos ver o que eles têm a oferecer. As promessas de uma revolução sem servidor foram inúmeras e - às vezes - muito ambiciosas.
Para aqueles que não estão familiarizados com o termo, aqui está uma definição rápida. A computação sem servidor define uma arquitetura na qual os aplicativos (ou partes dos aplicativos) são executados sob demanda em ambientes de tempo de execução que geralmente são hospedados remotamente. Além disso, sistemas sem servidor podem ser hospedados. Nos últimos anos, construir sistemas resilientes sem servidor tem sido uma grande preocupação para administradores de sistemas e empresas de SaaS, pois (supostamente) essa arquitetura oferece várias vantagens importantes sobre o modelo cliente / servidor "tradicional":
- , , . , .
- ( ). , , . VM, , .
- . , .
Resumindo, os modelos sem servidor fornecem soluções flexíveis, de baixo custo e escalonáveis. É incrível que não tenhamos tido essa ideia antes.
Esta é realmente uma ideia nova?
Na verdade, a ideia não é nova. O conceito de permitir que os usuários paguem apenas pelo tempo que o código realmente é executado existe desde que foi introduzido como parte do Zimki PaaS em 2006, e na mesma época o Google App Engine oferecia uma solução muito semelhante.
Na verdade, o que agora chamamos de modelo "sem servidor" é mais antigo do que muitas das tecnologias agora chamadas de tecnologias de "nuvem nativa", que oferecem praticamente o mesmo. Conforme observado, os modelos sem servidor são essencialmente apenas uma extensão do modelo de negócios SaaS que existe há décadas.
Também é importante reconhecer que o modelo sem servidor não é uma arquitetura FaaS, embora haja uma conexão entre eles. FaaS é essencialmente uma peça orientada a computação de uma arquitetura sem servidor, mas não representa o sistema inteiro.
Então, por que tanto barulho? Bem, à medida que a velocidade de penetração da Internet nos países em desenvolvimento continua a disparar, a demanda por recursos de computação cresce ao mesmo tempo. Por exemplo, muitos países com setores de comércio eletrônico em rápido crescimento simplesmente não possuem infraestrutura de computação para aplicativos nessas plataformas. É aqui que entram as plataformas sem servidor pagas.
Problemas de modelo sem servidor
O problema é que os modelos sem servidor têm ... problemas. Não me entenda mal: não estou dizendo que eles próprios sejam ruins ou que não agreguem valor significativo para algumas empresas em algumas circunstâncias. Mas a principal reivindicação da "revolução" - que a arquitetura sem servidor substituirá rapidamente a arquitetura tradicional - nunca se materializa.
É por isso.
Suporte limitado para linguagens de programação
A maioria das plataformas sem servidor permite que aplicativos escritos em determinados idiomas sejam executados. Isso limita severamente a flexibilidade e adaptabilidade desses sistemas.
Acredita-se que as plataformas sem servidor suportam a maioria dos principais idiomas. O AWS Lambda e o Azure Functions também fornecem um wrapper para a execução de aplicativos e funções em linguagens sem suporte, embora isso geralmente esteja associado a custos de desempenho. Portanto, para a maioria das organizações, essa limitação geralmente não importa. Mas é o seguinte. É sugerido que uma das vantagens dos modelos sem servidor é que programas pouco conhecidos e raramente usados podem ser usados mais barato porque você paga apenas pelo tempo de execução. E programas pouco conhecidos e raramente usados são freqüentemente escritos em ... linguagens de programação pouco conhecidas e raramente usadas.
Isso prejudica um dos principais benefícios do modelo sem servidor.
Vinculação do fornecedor
O segundo problema com as plataformas sem servidor, ou pelo menos a maneira como são implementadas atualmente, é que geralmente não têm a mesma aparência em nível operacional. Praticamente não há padronização em termos de funções de escrita, implantação e gerenciamento. Isso significa que a migração de recursos de uma plataforma para outra consome muito tempo.
A parte mais difícil de mudar para um modelo sem servidor não são as funções computacionais, que normalmente são apenas pedaços de código, mas como os aplicativos se relacionam com os sistemas conectados, como armazenamento de objetos, gerenciamento de identidade e filas. As funções podem ser movidas, mas o resto do aplicativo não. Isso é exatamente o oposto das plataformas flexíveis e de baixo custo prometidas.
Alguns argumentam que os modelos sem servidor são novos e não houve tempo para padronizar como eles funcionam. Mas eles não são tão novos, como observei acima, e muitas outras tecnologias de nuvem, como contêineres, já se tornaram muito mais utilizáveis por meio do desenvolvimento e da adoção generalizada de bons padrões.
atuação
O desempenho computacional de plataformas sem servidor é difícil de medir, em parte porque os fornecedores tendem a manter as informações privadas. A maioria argumenta que a funcionalidade em plataformas remotas sem servidor é tão rápida quanto em servidores internos, exceto por alguns problemas de latência inevitáveis.
No entanto, alguns fatos sugerem o contrário. As funções que não foram executadas anteriormente em uma plataforma específica ou que não foram executadas por algum tempo levam algum tempo para inicializar. Isso provavelmente se deve ao fato de que seu código foi portado para algum meio de armazenamento menos acessível, embora - como no caso de benchmarks - a maioria dos fornecedores não fale sobre a transferência de dados.
Existem, é claro, várias maneiras de contornar isso. Uma é otimizar a funcionalidade para qualquer linguagem de nuvem em que sua plataforma sem servidor seja executada, mas isso prejudica um pouco a alegação de que essas plataformas são "flexíveis".
Outra abordagem é garantir que os programas de desempenho crítico sejam executados regularmente para mantê-los atualizados. Essa segunda abordagem, é claro, contradiz a noção de que as plataformas sem servidor são mais econômicas, é claro, porque você paga apenas pelo tempo de execução de seus programas. Os provedores de nuvem introduziram novas maneiras de reduzir as partidas a frio, mas muitos deles exigem “escala para um”, o que prejudica o valor original do FaaS.
O problema da inicialização a frio pode ser parcialmente resolvido executando sistemas sem servidor internamente, mas isso tem um custo e continua sendo uma opção de nicho para equipes com bons recursos.
Você não pode executar aplicativos inteiros
Finalmente, talvez a razão mais importante pela qual as arquiteturas sem servidor não substituirão os modelos tradicionais tão cedo: elas (geralmente) não podem executar aplicativos inteiros.
Mais precisamente, não é rentável. Seu monólito de sucesso provavelmente não deveria ser transformado em um conjunto de quatro dúzias de funções vinculadas por oito gateways, quarenta filas e uma dúzia de instâncias de banco de dados. Por esse motivo, sem servidor é mais adequado para novos desenvolvimentos. Quase nenhum aplicativo (arquitetura) existente pode ser migrado. Você pode migrar, mas deve começar do zero.
Isso significa que, na grande maioria dos casos, as plataformas sem servidor são usadas para complementar os servidores de back-end para realizar tarefas de computação intensiva. Isso é muito diferente das outras duas formas de computação em nuvem, contêineres e máquinas virtuais, que oferecem uma maneira holística de realizar computação remota. Isso ilustra um dos desafios de mudar de microsserviços para sistemas sem servidor.
Claro, isso nem sempre é um problema. A capacidade de usar recursos de computação massivos periodicamente sem comprar seu próprio hardware pode trazer benefícios reais e duradouros para muitas organizações. Mas se alguns aplicativos estiverem em servidores internos e outros em arquiteturas de nuvem sem servidor, o gerenciamento está atingindo um novo nível de complexidade.
Vida longa à revolução?
Apesar de todas essas reclamações, não sou contra as soluções sem servidor em si. Honestamente. É que os desenvolvedores precisam entender - especialmente se estiverem explorando modelos sem servidor pela primeira vez - que essa tecnologia não é uma substituição direta dos servidores. Em vez disso, verifique nossas dicas e recursos para construir aplicativos sem servidor e veja como melhor aplicar este modelo.