Aínda que as tecnoloxías sen servidores gañaron rapidamente popularidade nos últimos anos, aínda hai moitos equívocos e preocupacións asociadas a elas. A dependencia dos provedores, as ferramentas, a xestión de custos, o inicio en frío, o seguimento e o ciclo de vida do desenvolvemento son temas moi debatidos cando se trata de tecnoloxías sen servidor. Neste artigo, exploraremos algúns dos temas mencionados, así como compartiremos consellos e ligazóns a recursos útiles para axudar aos principiantes a crear aplicacións sen servidor potentes, flexibles e rendibles.
Conceptos erróneos sobre tecnoloxías sen servidor
Moita xente cre que o procesamento de datos sen servidor e sen servidor (, FaaS) son case o mesmo. Isto significa que a diferenza non é demasiado grande e paga a pena introducir un novo produto. Aínda que AWS Lambda foi unha das estrelas do auxe da tecnoloxía sen servidor e un dos elementos máis populares da arquitectura sen servidor, hai máis nesta arquitectura que FaaS.
O principio fundamental de sen servidor é que non tes que preocuparte por xestionar ou escalar a túa infraestrutura; só pagas polo que usas. Moitos servizos cumpren estes criterios: AWS DynamoDB, S3, SNS ou SQS, Graphcool, Auth0, Now, Netlify, Firebase e moitos outros. En xeral, sen servidor significa utilizar todas as capacidades da computación na nube sen necesidade de xestionar e optimizar a infraestrutura para escalar. Tamén significa que a seguridade a nivel de infraestrutura xa non é o teu problema, o que supón un enorme beneficio dada a dificultade e complexidade de cumprir os estándares de seguridade. Finalmente, non tes que comprar a infraestrutura que che proporciona.
Sen servidor pódese considerar un "estado de ánimo": unha certa mentalidade á hora de deseñar solucións. Evite abordaxes que requiran mantemento de calquera infraestrutura. Cun enfoque sen servidor, pasamos tempo resolvendo problemas que afectan directamente ao proxecto e aportan valor aos nosos usuarios: creando unha lóxica de negocio sólida, desenvolvendo interfaces de usuario e desenvolvendo API fiables e sensibles.
Por exemplo, se é posible evitar xestionar e manter unha plataforma de busca de texto libre, iso é o que faremos. Este enfoque para crear aplicacións pode acelerar drasticamente o tempo de comercialización porque xa non tes que pensar en xestionar infraestruturas complexas. Libérese das responsabilidades e custos da xestión da infraestrutura e concéntrese na creación das aplicacións e servizos que necesitan os seus clientes. Patrick Debois chamou a este enfoque , este termo é aceptado na comunidade sen servidor. As funcións deben ser pensadas como o pegamento que une os servizos como módulos despregábeis (en lugar de implementar unha biblioteca ou unha aplicación web completa). Isto proporciona unha granularidade incrible para xestionar a implantación e os cambios na aplicación. Se non pode implementar funcións deste xeito, pode indicar que as funcións están a facer demasiadas cousas e deben ser refactorizadas.
Algunhas persoas están confundidas pola dependencia dos provedores ao desenvolver aplicacións na nube. O mesmo ocorre coas tecnoloxías sen servidor, e é improbable que isto sexa o resultado dunha idea errónea. Na nosa experiencia, a creación de aplicacións sen servidor en AWS, xunto coa capacidade de AWS Lambda para agregar outros servizos de AWS, é parte do que fai que as arquitecturas sen servidor sexan tan xeniais. Este é un bo exemplo de sinerxía, cando o resultado dunha combinación é maior que só a suma das súas partes. Intentar evitar o bloqueo do vendedor pode provocar aínda máis problemas. Cando se traballa con contedores, é máis doado xestionar a súa propia capa de abstracción entre provedores de nube. Pero cando se trata de solucións sen servidor, o esforzo non pagará os seus froitos, especialmente se se considera a rendibilidade desde o principio. Asegúrese de descubrir como os provedores ofrecen servizos. Algúns servizos especializados dependen de puntos de integración con outros provedores e poden proporcionar conectividade plug-and-play. É máis fácil proporcionar unha chamada Lambda desde un punto final da API de pasarela que enviar a solicitude a algún contedor ou instancia EC2. Graphcool permite unha configuración sinxela usando Auth0, que é máis fácil que usar ferramentas de autenticación de terceiros.
Elixir o provedor axeitado para a súa aplicación sen servidor é unha decisión a nivel arquitectónico. Cando creas unha aplicación, non esperas volver algún día á xestión dos servidores. Elixir un provedor na nube non é diferente que elixir usar contedores ou unha base de datos, ou mesmo unha linguaxe de programación.
Considere:
- Que servizos necesitas e por que.
- Que servizos ofrecen os provedores de nube e como pode combinalos usando a solución FaaS que elixa.
- Que linguaxes de programación son compatibles (escritos, compilados ou interpretados de forma dinámica ou estática, cales son os puntos de referencia, cal é o rendemento do arranque en frío, cal é o ecosistema de código aberto, etc.).
- Cales son os teus requisitos de seguridade (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Como xestionar os seus ciclos de desenvolvemento de software e CI/CD.
- Que solucións de infraestrutura como código podes aproveitar?
Se está ampliando unha aplicación existente e engadindo funcións sen servidor de forma incremental, isto pode limitar algo as capacidades dispoñibles. Non obstante, case todas as tecnoloxías sen servidor ofrecen algún tipo de API (mediante REST ou cola de mensaxes) que permite crear extensións independentes do núcleo da aplicación e cunha integración sinxela. Busca servizos con API claras, boa documentación e unha comunidade sólida, e non te podes equivocar. A facilidade de integración adoita ser unha métrica clave e é probablemente unha das principais razóns polas que AWS tivo éxito desde que Lambda saíu en 2015.
Cando é útil sen servidor?
As tecnoloxías sen servidor pódense usar case en calquera lugar. Non obstante, as súas vantaxes non se limitan só aos métodos de aplicación. A barreira de entrada para a computación na nube é tan baixa hoxe precisamente por mor das tecnoloxías sen servidor. Se os desenvolvedores teñen unha idea, pero non saben como xestionar a infraestrutura na nube e optimizar os custos, entón non necesitan buscar algún enxeñeiro para facelo. Se unha startup quere construír unha plataforma pero lle preocupa que os custos poidan saírse de control, pode recurrir facilmente a solucións sen servidor.
Grazas ao aforro de custos e á facilidade de escalado, as solucións sen servidor son aplicables por igual a sistemas internos e externos, ata unha aplicación web cunha audiencia multimillonaria. As contas mídense en céntimos en lugar de euros. Alugar a instancia AWS EC2 máis sinxela (t1.micro) durante un mes custará 15 €, aínda que non fagas nada con ela (¿quen se esqueceu algunha vez de apagala?!). En comparación, para acadar este nivel de gasto durante o mesmo período de tempo, tería que executar un Lambda de 512 MB durante 1 segundo aproximadamente 3 millóns de veces. E se non utilizas esta función, non pagas nada.
Dado que sen servidor está dirixido principalmente a eventos, é bastante sinxelo engadir infraestrutura sen servidor aos sistemas legados. Por exemplo, usando AWS S3, Lambda e Kinesis, pode crear un servizo de análise para un sistema de venda polo miúdo herdado que pode recibir datos a través dunha API.
A maioría das plataformas sen servidor admiten varios idiomas. A maioría das veces son Python, JavaScript, C#, Java e Go. Normalmente, todos os idiomas non teñen restricións no uso das bibliotecas, polo que podes usar as túas bibliotecas favoritas de código aberto. Non obstante, é recomendable non abusar das dependencias para que as súas funcións funcionen de forma óptima e non anulen os beneficios da enorme escalabilidade das súas aplicacións sen servidor. Cantos máis paquetes hai que cargar no contedor, máis tempo tardará o arranque en frío.
Un arranque en frío é cando cómpre inicializar o contenedor, o tempo de execución e o controlador de erros antes de utilizalos. Por iso, o atraso na realización das funcións pode ser de ata 3 segundos, e esta non é a mellor opción para usuarios impacientes. Non obstante, os arranques en frío ocorren na primeira chamada despois duns minutos de inactividade. Moitos consideran que isto é un inconveniente menor que se pode solucionar facendo ping regularmente á función para mantelo inactivo. Ou ignoran este aspecto por completo.
Aínda que AWS lanzouNon obstante, as bases de datos SQL non son ideais para este tipo de uso porque dependen de conexións para realizar transaccións, que poden converterse rapidamente nun pescozo de botella cando hai moito tráfico en AWS Lambda. Si, os desenvolvedores están a mellorar constantemente Aurora sen servidor, e deberías experimentar con ela, pero hoxe as solucións NoSQL como. Non obstante, non cabe dúbida de que esta situación cambiará moi pronto.
O conxunto de ferramentas tamén impón moitas limitacións, especialmente no ámbito das probas locais. Aínda que hai solucións como Docker-Lambda, DynamoDB Local e LocalStack, requiren un traballo minucioso e unha cantidade importante de configuración. Non obstante, todos estes proxectos están a desenvolverse activamente, polo que só é cuestión de tempo que as ferramentas cheguen ao nivel que necesitamos.
O impacto das tecnoloxías sen servidor no ciclo de desenvolvemento
Dado que a súa infraestrutura é simplemente unha configuración, pode definir e implementar código mediante scripts, como scripts de shell. Ou pode recorrer a solucións de clase de configuración como código como . Aínda que este servizo non proporciona configuración para todas as áreas, si permite definir recursos específicos para o seu uso como funcións Lambda. É dicir, onde CloudFormation falla, podes escribir o teu propio recurso (función Lambda) que pechará este oco. Deste xeito, pode facer calquera cousa, incluso configurar dependencias fóra do seu contorno AWS.
Como é só configuración, podes parametrizar os teus scripts de implementación para contornas, rexións e usuarios específicos, especialmente se estás a usar solucións de infraestrutura como código como CloudFormation. Por exemplo, pode implantar unha copia da infraestrutura para cada rama do repositorio para poder probalas completamente de forma illada durante o desenvolvemento. Isto acelera radicalmente o tempo en que os desenvolvedores reciben comentarios cando queren comprender se o seu código funciona adecuadamente nun ambiente en directo. Os xestores non teñen que preocuparse polo custo de implementar varios ambientes porque só pagan polo uso real.
DevOps ten menos de que preocuparse xa que só precisan asegurarse de que os desenvolvedores teñan a configuración correcta. Non máis xestionar instancias, equilibradores ou grupos de seguranza. Polo tanto, o termo NoOps úsase cada vez máis, aínda que aínda é importante poder configurar a infraestrutura, especialmente no que se refire á configuración de IAM e á optimización dos recursos da nube.
Hai ferramentas de monitorización e visibilidade moi potentes como Epsagon, Thundra, Dashbird e IOPipe. Permítenche supervisar o estado actual das aplicacións sen servidor, proporcionar rexistros e rastrexos, capturar métricas de rendemento e pescozos de botella arquitectónicos, realizar análises de custos e previsións e moito máis. Non só ofrecen aos enxeñeiros, desenvolvedores e arquitectos de DevOps unha visión completa do rendemento das aplicacións, senón que tamén permiten aos xestores obter visibilidade sobre o gasto de recursos segundo a segundo e a previsión de custos en tempo real. É moito máis difícil organizalo cunha infraestrutura xestionada.
Deseñar aplicacións sen servidor é moito máis sinxelo porque non tes que despregar servidores web, xestionar máquinas ou contedores virtuais, servidores de parches, sistemas operativos, pasarelas de Internet, etc. Abstraer todas estas responsabilidades permite que a arquitectura sen servidor se centre no que máis importa: a solución. necesidades empresariais e dos clientes.
Aínda que as ferramentas poden ser mellores (mellora cada día), os desenvolvedores poden centrarse na implementación da lóxica empresarial e na forma de distribuír mellor a complexidade da aplicación en diferentes servizos dentro da arquitectura. A xestión de aplicacións sen servidor baséase en eventos e abstrae o provedor de nube (por exemplo, eventos SQS, S3 ou fluxos de DynamoDB). Polo tanto, os desenvolvedores só precisan escribir a lóxica de negocio para reaccionar ante certos eventos e non teñen que preocuparse sobre a mellor forma de implementar as bases de datos e as colas de mensaxes, ou como traballar de forma óptima cos datos en almacenamentos de hardware específicos.
O código pódese executar e depurar localmente, como ocorre con calquera proceso de desenvolvemento. As probas unitarias seguen sendo as mesmas. A capacidade de implantar unha infraestrutura de aplicacións completa mediante unha configuración de pila personalizada permite aos desenvolvedores obter rapidamente comentarios importantes sen preocuparse polo custo das probas ou polo impacto en entornos xestionados caros.
Ferramentas e técnicas para a creación de aplicacións sen servidor
Non hai unha forma específica de crear aplicacións sen servidor. Así como un conxunto de servizos para esta tarefa. O líder entre as potentes solucións sen servidor hoxe é AWS, pero preste atención , и . Se está a usar AWS, podemos recomendarlle como método para recoller aplicacións (SAM), especialmente cando se usa C#, porque Visual Studio ten excelentes ferramentas. A CLI de SAM pode facer todo o que pode facer Visual Studio, polo que non perderás nada se cambias a un IDE ou editor de texto diferente. Por suposto, SAM tamén funciona con outros idiomas.
Se escribes noutros idiomas, Serverless Framework é unha excelente ferramenta de código aberto que che permite configurar calquera cousa usando ficheiros de configuración YAML moi potentes. Serverless Framework tamén admite varios servizos na nube, polo que recomendámosllo a aqueles que busquen unha solución multinube. Ten unha enorme comunidade que creou unha morea de complementos para calquera necesidade.
Para probas locais, as ferramentas de código aberto Docker-Lambda, Serverless Local, DynamoDB Local e LocalStack son moi adecuadas. As tecnoloxías sen servidor aínda están nunha fase inicial de desenvolvemento, así como as ferramentas para elas, polo que terás que traballar duro á hora de configurar escenarios de proba complexos. Non obstante, simplemente implementar a pila no ambiente e probala alí resulta incriblemente barata. E non precisa facer unha copia local exacta dos seus ambientes de nube.
Use AWS Lambda Layers para reducir o tamaño dos paquetes despregados e acelerar os tempos de carga.
Use as linguaxes de programación adecuadas para tarefas específicas. As diferentes linguas teñen as súas propias vantaxes e desvantaxes. Hai moitos puntos de referencia, pero JavaScript, Python e C# (.NET Core 2.1+) son os líderes en canto ao rendemento de AWS Lambda. AWS Lambda presentou recentemente unha API en tempo de execución que che permite especificar o idioma e o ambiente de execución que desexas, así que proba.
Mantén os tamaños dos paquetes de implementación pequenos. Canto máis pequenos son, máis rápido cargan. Evite usar bibliotecas grandes, especialmente se usa un par de funcións delas. Se estás a programar en JavaScript, utiliza ferramentas de compilación como Webpack para optimizar a túa compilación e incluír só o que realmente necesitas. .NET Core 3.0 inclúe QuickJit e Tired Compilation, que melloran o rendemento e axudan moito cos arranques en frío.
A dependencia dos eventos das funcións sen servidor pode dificultar a coordinación da lóxica empresarial nun primeiro momento. As colas de mensaxes e as máquinas de estado poden ser incriblemente útiles neste sentido. As funcións Lambda poden chamarse entre si, pero só faino se non espera unha resposta ("disparar e esquecer"); non quere que se lle cobre por esperar a que se complete outra función. As colas de mensaxes son útiles para illar pezas da lóxica empresarial, xestionar os pescozos de botella das aplicacións e procesar transaccións (usando colas FIFO). As funcións de AWS Lambda pódense asignar ás colas SQS como colas de mensaxes atascadas que rastrexan as mensaxes con erro para a súa posterior análise. As funcións AWS Step Functions (máquinas de estado) son moi útiles para xestionar procesos complexos que requiren encadeamento de funcións. En lugar de que unha función Lambda chame a outra función, as funcións Step poden coordinar transicións de estado, pasar datos entre funcións e xestionar o estado global das funcións. Isto permítelle definir condicións de reintento ou que facer cando se produce un erro específico, unha ferramenta moi poderosa en determinadas condicións.
Conclusión
Nos últimos anos, as tecnoloxías sen servidor desenvolvéronse a un ritmo sen precedentes. Hai certos conceptos erróneos asociados a este cambio de paradigma. Ao abstraer a infraestrutura e xestionar a escalabilidade, as solucións sen servidor ofrecen importantes beneficios, desde procesos simplificados de desenvolvemento e DevOps ata grandes reducións dos custos operativos.
Aínda que o enfoque sen servidor non está exento de inconvenientes, hai patróns de deseño fiables que se poden usar para crear aplicacións sen servidor robustas ou integrar elementos sen servidor en arquitecturas existentes.
Fonte: www.habr.com