Puntos clave
- Desde hai varios anos, prometéronnos que a informática sen servidor marcará o inicio dunha nova era sen un sistema operativo específico para executar aplicacións. Dixéronnos que esta estrutura resolvería moitos problemas de escalabilidade. De feito, todo é diferente.
- Aínda que moitos ven sen servidor como unha idea nova, as súas raíces remóntanse a 2006 coa chegada de Zimki PaaS e Google App Engine, que usan arquitectura sen servidor.
- Hai catro razóns polas que se paralizou a revolución sen servidor, que van desde o soporte limitado da linguaxe de programación ata problemas de rendemento.
- A informática sen servidor non é tan inútil. De ningunha maneira. Non obstante, non deben considerarse un substituto directo dos servidores. Para algunhas aplicacións poden ser unha ferramenta útil.
O servidor está morto, viva o servidor!
Este é o berro de batalla da revolución sen servidor. Só unha rápida ollada á prensa do sector dos últimos anos e é fácil concluír que o modelo de servidor tradicional está morto e que dentro duns anos todos usaremos arquitecturas sen servidor.
Como calquera do sector sabe, e como tamén sinalamos no noso artigo sobre , isto está mal. A pesar de moitos artigos sobre os méritos , nunca tivo lugar. De feito, que esta revolución puido chegar a unha vía sen saída.
Certamente, algunhas das promesas dos modelos sen servidor foron realizadas, pero non todas. Non todos.
Neste artigo quero ver as razóns desta condición. Por que a falta de flexibilidade dos modelos sen servidor aínda é unha barreira para a súa adopción máis ampla, aínda que seguen sendo útiles en circunstancias específicas e ben definidas.
O que prometeron os adeptos da computación sen servidor
Antes de entrar nos retos da computación sen servidor, vexamos o que se supón que debería proporcionar. foron numerosos e, ás veces, moi ambiciosos.
Para aqueles que non estean familiarizados co termo, aquí tes unha definición rápida. A informática sen servidor define unha arquitectura na que as aplicacións (ou partes de aplicacións) se executan baixo demanda en ambientes de execución que normalmente están aloxados de forma remota. Ademais, os sistemas sen servidor pódense aloxar na casa. A construción de sistemas sen servidor resistentes foi unha preocupación importante para os administradores de sistemas e as empresas de SaaS nos últimos anos, xa que (se afirma) esta arquitectura ofrece varias vantaxes clave sobre o modelo cliente-servidor "tradicional":
- Os modelos sen servidor non requiren que os usuarios manteñan os seus propios sistemas operativos nin sequera creen aplicacións compatibles con sistemas operativos específicos. No seu lugar, os desenvolvedores crean código compartido, cárgano a unha plataforma sen servidor e ven como se executa.
- Os recursos en marcos sen servidor adoitan facturarse por minuto (ou incluso por segundo). Isto significa que os clientes só pagan polo tempo que realmente executan o código. Isto compárase favorablemente cunha máquina virtual na nube tradicional, onde a máquina está inactiva a maior parte do tempo, pero tes que pagar por iso.
- Tamén se resolveu o problema de escalabilidade. Os recursos en marcos sen servidor asígnanse dinámicamente para que o sistema poida facer fronte facilmente aos aumentos repentinos da demanda.
En resumo, os modelos sen servidor ofrecen solucións flexibles, de baixo custo e escalables. É sorprendente que non se nos ocorrese esta idea antes.
É realmente unha idea nova?
De feito, a idea non é nova. O concepto de permitir que os usuarios paguen só polo tempo que se está a executar o código existe desde que foi introducido por en 2006, e ao mesmo tempo Google App Engine ofreceu unha solución moi similar.
De feito, o que agora chamamos modelo "sen servidor" é máis antigo que moitas tecnoloxías que agora se chaman "nativas da nube" que proporcionan o mesmo. Como se indicou, os modelos sen servidor son esencialmente só unha extensión do modelo de negocio SaaS que existe desde hai décadas.
Tamén vale a pena recoñecer que sen servidor non é unha arquitectura FaaS, aínda que hai unha conexión entre ambas. FaaS é esencialmente a parte centrada na computación dunha arquitectura sen servidor, pero non representa todo o sistema.
Entón, de que vai todo o alboroto? Pois ben, a medida que as taxas de penetración de Internet seguen disparando nos países en desenvolvemento, a demanda de recursos informáticos tamén está aumentando ao mesmo tempo. Por exemplo, moitos países con sectores de comercio electrónico en rápido crecemento simplemente non teñen a infraestrutura informática para aplicacións nestas plataformas. Aquí é onde entran as plataformas sen servidor de pago.
Problemas cos modelos sen servidor
O problema é que os modelos sen servidor teñen... problemas. Non me malinterpretes: non digo que sexan malos per se ou que non aporten un valor significativo a algunhas empresas nalgunhas circunstancias. Pero a principal reivindicación da "revolución" -que a arquitectura sen servidor substituirá rapidamente á arquitectura tradicional- nunca se materializa.
Por iso.
Soporte limitado para linguaxes de programación
A maioría das plataformas sen servidor só permiten executar aplicacións escritas en determinados idiomas. Isto limita seriamente a flexibilidade e adaptabilidade destes sistemas.
Considérase que as plataformas sen servidor admiten a maioría das linguas principais. AWS Lambda e Azure Functions tamén proporcionan un envoltorio para executar aplicacións e funcións en idiomas non compatibles, aínda que isto adoita ter un custo de rendemento. Polo tanto, para a maioría das organizacións, esta limitación non adoita ser un gran problema. Pero aquí está a cousa. Suponse que unha das vantaxes dos modelos sen servidor é que os programas pouco coñecidos e pouco usados pódense usar máis barato porque só pagas polo tempo que se executan. E os programas pouco coñecidos e pouco utilizados adoitan escribirse en... linguaxes de programación pouco coñecidas e pouco usadas.
Isto socava un dos principais beneficios do modelo sen servidor.
Encadernación do vendedor
O segundo problema das plataformas sen servidor, ou polo menos da forma na que están implementadas actualmente, é que normalmente non se parecen entre si a nivel operativo. Practicamente non hai estandarización en canto a funcións de escritura, despregamento e xestión. Isto significa que migrar funcións dunha plataforma a outra leva moito tempo.
A parte máis difícil de pasar a un modelo sen servidor non son as funcións de cálculo, que adoitan ser só fragmentos de código, senón a forma en que as aplicacións se comunican cos sistemas conectados, como o almacenamento de obxectos, a xestión de identidades e as colas. As funcións pódense mover, pero o resto da aplicación non. Este é exactamente o contrario das plataformas baratas e flexibles que se prometen.
Algúns argumentan que os modelos sen servidor son novos e que non houbo tempo para estandarizar o seu funcionamento. Pero non son tan novos, como observei anteriormente, e moitas outras tecnoloxías na nube, como os contedores, xa se fixeron moito máis utilizables grazas ao desenvolvemento e adopción xeneralizada de bos estándares.
Produtividade
O rendemento informático das plataformas sen servidor é difícil de medir, en parte porque os provedores tenden a manter a información privada. A maioría argumenta que as funcións en plataformas remotas sen servidores funcionan tan rápido como as dos servidores internos, con excepción dalgúns problemas de latencia inevitables.
Non obstante, os feitos individuais indican o contrario. As funcións que non se executaron previamente nunha plataforma concreta ou que non se executaron durante algún tempo tardarán en inicializarse. Probablemente, isto débese ao feito de que o seu código foi portado a algún medio de almacenamento menos accesible, aínda que, como ocorre cos puntos de referencia, a maioría dos provedores non che informarán sobre a migración de datos.
Por suposto, hai varias formas de evitar isto. Unha delas é optimizar as funcións para calquera linguaxe de nube no que se estea executando a túa plataforma sen servidor, pero isto socava un pouco a afirmación de que estas plataformas son "áxiles".
Outro enfoque é garantir que os programas críticos para a produtividade se executen regularmente para mantelos actualizados. Este segundo enfoque, por suposto, é un pouco unha contradición coa afirmación de que as plataformas sen servidor son máis rendibles porque só pagas polo tempo que se executan os teus programas. Os provedores de nube introduciron novas formas de reducir os arranques en frío, pero moitos deles requiren "escalar a un", o que socava o valor orixinal de FaaS.
O problema do arranque en frío pódese resolver parcialmente executando sistemas sen servidores na casa, pero isto leva os seus propios custos e segue sendo unha opción de nicho para equipos con ben recursos.
Non pode executar aplicacións enteiras
Finalmente, quizais a razón máis importante pola que as arquitecturas sen servidor non substituirán os modelos tradicionais en breve: (normalmente) non poden executar aplicacións enteiras.
Máis precisamente, é pouco práctico desde o punto de vista dos custos. O teu monolito exitoso probablemente non debería converterse nun conxunto de catro ducias de funcións conectadas por oito pasarelas, corenta colas e unha ducia de instancias de base de datos. Por esta razón, sen servidor é máis adecuado para novos desenvolvementos. Case non se pode migrar ningunha aplicación (arquitectura) existente. Podes migrar, pero tes que comezar de cero.
Isto significa que na gran maioría dos casos, as plataformas sen servidor utilízanse como complemento aos servidores back-end para realizar tarefas de computación intensiva. Isto fainos moi diferentes das outras dúas formas de tecnoloxías na nube (contedores e máquinas virtuais) que ofrecen un xeito holístico de realizar computación remota. Isto ilustra un dos retos de pasar de microservizos a sen servidor.
Por suposto, isto non sempre é un problema. A capacidade de aproveitar periódicamente recursos informáticos masivos sen ter que comprar o seu propio hardware pode traer beneficios reais e duradeiros a moitas organizacións. Pero cando algunhas aplicacións residen en servidores internos e outras en arquitecturas de nube sen servidor, a xestión adquire un novo nivel de complexidade.
Viva a revolución?
A pesar de todas estas queixas, non estou en contra das solucións sen servidor per se. Sinceramente. Os desenvolvedores só precisan entender, especialmente se están a explorar sen servidor por primeira vez, que a tecnoloxía non é un substituto directo dos servidores. En vez diso, consulta os nosos consellos e recursos para e decidir a mellor forma de aplicar o modelo.
Fonte: www.habr.com