Tot i que les tecnologies sense servidor han guanyat popularitat ràpidament en els últims anys, encara hi ha moltes idees errònies i pors associades a elles. La dependència del proveïdor, les eines, la gestió de costos, l'arrencada en fred, la supervisió i el cicle de vida del desenvolupament són temes candents quan es tracta de tecnologies sense servidor. En aquest article, explorarem alguns dels temes esmentats, així com compartirem consells i enllaços a fonts d'informació útils per ajudar els principiants a crear aplicacions sense servidor potents, flexibles i rendibles.
Concepcions errònies sobre les tecnologies sense servidor
Molta gent pensa que el processament sense servidor i sense servidor (, FaaS) són gairebé el mateix. Això vol dir que la diferència no és massa gran i val la pena introduir una novetat. Tot i que AWS Lambda va ser una de les estrelles de l'apogeu sense servidor i un dels elements més populars de l'arquitectura sense servidor, aquesta arquitectura és molt més que FaaS.
El principi bàsic de les tecnologies sense servidor és que no us haureu de preocupar per gestionar i escalar la vostra infraestructura, només pagueu pel que feu servir. Molts serveis s'ajusten a aquests criteris: AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase i molts altres. En general, sense servidor significa utilitzar tota la potència de la informàtica en núvol sense necessitat de gestionar la infraestructura i optimitzar-la per escalar-la. També significa que la seguretat a nivell d'infraestructura ja no us preocupa, la qual cosa és un gran benefici donada la dificultat i la complexitat de complir els estàndards de seguretat. Finalment, no cal que compreu la infraestructura que se us ofereix.
Sense servidor es pot considerar un "estat d'ànim": una certa mentalitat a l'hora de dissenyar solucions. Eviteu aproximacions que requereixin manteniment de qualsevol infraestructura. Amb un enfocament sense servidor, dediquem temps a resoldre tasques que afecten directament el projecte i aporten beneficis als nostres usuaris: creem una lògica empresarial sostenible, desenvolupem interfícies d'usuari i desenvolupem API adaptatives i fiables.
Per exemple, si és possible evitar gestionar i mantenir una plataforma de cerca de text lliure, això és el que farem. Aquest enfocament per crear aplicacions pot accelerar molt el temps de llançament al mercat, perquè ja no cal pensar en gestionar una infraestructura complexa. Elimineu les responsabilitats i els costos de la gestió de la infraestructura i centreu-vos a crear les aplicacions i els serveis que necessiten els vostres clients. Patrick Debois va anomenar aquest enfocament , el terme adoptat a la comunitat sense servidor. Les funcions s'han de pensar com un enllaç als serveis com a mòduls desplegables (en lloc de desplegar una biblioteca sencera o una aplicació web). Això proporciona una granularitat increïble per gestionar el desplegament i els canvis a l'aplicació. Si no podeu desplegar funcions d'aquesta manera, pot indicar que les funcions realitzen massa tasques i s'han de refactoritzar.
Alguns es confonen per la dependència del venedor a l'hora de desenvolupar aplicacions al núvol. El mateix passa amb les tecnologies sense servidor, i això no és una idea errònia. Segons la nostra experiència, la creació d'aplicacions sense servidor a AWS, combinada amb la capacitat d'AWS Lambda d'agrupar altres serveis d'AWS, forma part de la força de les arquitectures sense servidor. Aquest és un bon exemple de sinergia, quan el resultat de la combinació és més que la suma dels termes. Intentar evitar la dependència del venedor pot tenir encara més problemes. Quan treballeu amb contenidors, és més fàcil gestionar la vostra pròpia capa d'abstracció entre proveïdors de núvol. Però quan es tracta de solucions sense servidor, l'esforç no pagarà, sobretot si es té en compte la rendibilitat des del principi. Assegureu-vos d'esbrinar com els venedors ofereixen serveis. Alguns serveis especialitzats es basen en punts d'integració amb altres proveïdors i poden oferir connectivitat plug-and-play des de la caixa. És més fàcil proporcionar una trucada Lambda des d'un punt final de l'API de passarel·la que enviar la sol·licitud a algun contenidor o instància EC2. Graphcool proporciona una configuració fàcil amb Auth0, que és més fàcil que utilitzar eines d'autenticació de tercers.
Escollir el proveïdor adequat per a la vostra aplicació sense servidor és una decisió arquitectònica. Quan creeu una aplicació, no espereu tornar algun dia a gestionar servidors. Escollir un venedor de núvol no és diferent de triar utilitzar contenidors o una base de dades, o fins i tot un llenguatge de programació.
Considereu:
- Quins serveis necessiteu i per què.
- Quins serveis ofereixen els proveïdors de núvol i com podeu combinar-los amb la vostra solució FaaS escollida.
- Quins llenguatges de programació són compatibles (amb mecanografia dinàmica o estàtica, compilat o interpretat, quins són els benchmarks, quin és el rendiment a l'arrencada en fred, quin és l'ecosistema de codi obert, etc.).
- Quins són els vostres requisits de seguretat (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Com gestionar els vostres cicles de desenvolupament de programari i CI/CD.
- Quines solucions d'infraestructura com a codi podeu aprofitar.
Si amplieu una aplicació existent i afegiu progressivament una funcionalitat sense servidor, això pot limitar una mica les capacitats disponibles. Tanmateix, gairebé totes les tecnologies sense servidor proporcionen algun tipus d'API (mitjançant REST o cues de missatges) que permet crear extensions independents del nucli de l'aplicació i amb una integració fàcil. Busqueu serveis amb API clares, una bona documentació i una comunitat sòlida, i no us podeu equivocar. La facilitat d'integració sovint pot ser una mètrica clau i és probablement una de les principals raons per les quals AWS ha tingut tant d'èxit des que Lambda es va llançar el 2015.
Quan sense servidor és bo
Les tecnologies sense servidor es poden aplicar gairebé a tot arreu. Tanmateix, els seus avantatges no es limiten a una sola forma d'aplicació. La barrera d'entrada per a la computació en núvol avui és tan baixa gràcies a les tecnologies sense servidor. Si els desenvolupadors tenen una idea, però no saben com gestionar la infraestructura del núvol i optimitzar els costos, no cal que busquen algun tipus d'enginyer per fer-ho. Si una startup vol crear una plataforma però tem que els costos es puguin descontrolar, pot recórrer fàcilment a solucions sense servidor.
A causa de l'estalvi de costos i la facilitat d'escalat, les solucions sense servidor són igualment aplicables tant per a sistemes interns com externs, fins a una aplicació web amb un públic multimilionari. Els comptes es mesuren més que en euros, però en cèntims. Llogar la instància més senzilla d'AWS EC2 (t1.micro) durant un mes costarà 15 €, encara que no hi facis res (a qui no s'ha oblidat mai d'apagar-la?!). En comparació, per assolir aquest nivell de despesa durant el mateix període de temps, hauríeu d'executar una Lambda de 512 MB durant 1 segon unes 3 milions de vegades. I si no utilitzeu aquesta funció, no pagueu res.
Com que sense servidor es basa principalment en esdeveniments, és bastant fàcil afegir una infraestructura sense servidor als sistemes antics. Per exemple, amb AWS S3, Lambda i Kinesis, podeu crear un servei d'anàlisi per a un sistema minorista antic que pot rebre dades mitjançant una API.
La majoria de plataformes sense servidor admeten diversos idiomes. Molt sovint és Python, JavaScript, C#, Java i Go. Normalment no hi ha restriccions a l'ús de biblioteques en tots els idiomes, de manera que podeu utilitzar les vostres biblioteques de codi obert preferides. No obstant això, és aconsellable no abusar de les dependències perquè les vostres funcions funcionin de manera òptima i no anul·lin els beneficis de l'enorme escalabilitat de les vostres aplicacions sense servidor. Com més paquets s'hagin de carregar al contenidor, més temps trigarà l'arrencada en fred.
Un arrencada en fred és quan primer cal inicialitzar el contenidor, el temps d'execució i el gestor d'errors abans d'utilitzar-los. Per això, el retard en l'execució de les funcions pot ser de fins a 3 segons, i aquesta no és la millor opció per als usuaris impacients. Tanmateix, els arrencades en fred es produeixen a la primera trucada després d'uns minuts de funció inactiva. Molts consideren que això és una molèstia menor que es pot solucionar fent ping regularment a la funció per mantenir-la inactiva. O ignoren completament aquest aspecte.
Tot i que AWS va llançarNo obstant això, les bases de dades SQL no són ideals per a aquesta aplicació, ja que depenen de les connexions per realitzar transaccions, que poden convertir-se ràpidament en un coll d'ampolla amb trànsit intens a AWS Lambda. Sí, els desenvolupadors estan millorant constantment Aurora sense servidor, i hauríeu d'experimentar-hi, però avui dia solucions NoSQL com. Tanmateix, no hi ha dubte que aquesta situació canviarà molt aviat.
El conjunt d'eines també imposa moltes restriccions, especialment en el camp de les proves locals. Tot i que hi ha solucions com Docker-Lambda, DynamoDB Local i LocalStack, requereixen un treball dur i una quantitat important de configuració. No obstant això, tots aquests projectes es desenvolupen activament, de manera que és només qüestió de temps que el conjunt d'eines assoleixi el nivell que necessitem.
L'impacte de les tecnologies sense servidor en el cicle de desenvolupament
Com que la vostra infraestructura és només una configuració, podeu definir i desplegar codi mitjançant scripts, com ara shell scripts. O podeu recórrer a solucions de classe de configuració com a codi com . Tot i que aquest servei no proporciona configuració per a totes les àrees, sí que permet definir recursos específics per utilitzar com a funcions Lambda. És a dir, quan CloudFormation us falla, podeu escriure el vostre propi recurs (funció Lambda) que tancarà aquest buit. D'aquesta manera podeu fer qualsevol cosa, fins i tot configurar dependències fora del vostre entorn AWS.
Com que tot és només configuració, podeu personalitzar els vostres scripts de desplegament per a entorns, regions i usuaris específics, especialment si feu servir solucions d'infraestructura com a codi com CloudFormation. Per exemple, podeu desplegar una còpia de la infraestructura per a cada branca del repositori perquè pugueu provar-les completament de manera aïllada durant el desenvolupament. Això accelera dràsticament els comentaris dels desenvolupadors quan volen entendre si el seu codi funciona adequadament en un entorn en directe. Els gestors no s'han de preocupar pel cost de desplegar diversos entorns, ja que només paguen per l'ús real.
DevOps té menys preocupacions, ja que només cal assegurar-se que els desenvolupadors tinguin la configuració correcta. Ja no cal que gestioneu instàncies, equilibradors o grups de seguretat. Per tant, el terme NoOps s'utilitza cada cop més, tot i que encara és important poder configurar la infraestructura, sobretot pel que fa a la configuració d'IAM i l'optimització dels recursos al núvol.
Hi ha eines de supervisió i visualització molt potents com Epsagon, Thundra, Dashbird i IOPipe. Us permeten supervisar l'estat actual de les vostres aplicacions sense servidor, proporcionar registre i traça, capturar mètriques de rendiment i colls d'ampolla de l'arquitectura, realitzar anàlisis i previsions de costos i molt més. No només ofereixen als enginyers, desenvolupadors i arquitectes de DevOps una visió completa del rendiment de les aplicacions, sinó que també permeten als gestors supervisar la situació en temps real, amb costos de recursos per segon i previsió de costos. És molt més difícil organitzar-ho amb una infraestructura gestionada.
Dissenyar aplicacions sense servidor és molt més fàcil perquè no cal desplegar servidors web, gestionar màquines o contenidors virtuals, servidors de pedaços, sistemes operatius, passarel·les d'Internet, etc. Abstraint totes aquestes responsabilitats, una arquitectura sense servidor pot centrar-se en el nucli: la solució, les necessitats empresarials i dels clients.
Tot i que el conjunt d'eines podria ser millor (millora cada dia), els desenvolupadors poden centrar-se a implementar la lògica empresarial i distribuir millor la complexitat de l'aplicació entre diferents serveis dins de l'arquitectura. La gestió d'aplicacions sense servidor es basa en esdeveniments i l'abstraeix el proveïdor del núvol (per exemple, SQS, esdeveniments S3 o fluxos de DynamoDB). Per tant, els desenvolupadors només han d'escriure la lògica empresarial per respondre a determinats esdeveniments i no s'han de preocupar de la millor manera d'implementar les bases de dades i les cues de missatges, o com organitzar el treball òptim amb dades en emmagatzematge de maquinari específic.
El codi es pot executar i depurar localment, com amb qualsevol procés de desenvolupament. Les proves unitàries segueixen sent les mateixes. La capacitat de desplegar tota una infraestructura d'aplicacions amb una configuració de pila personalitzada permet als desenvolupadors obtenir ràpidament comentaris importants sense pensar en el cost de les proves o l'impacte en entorns gestionats cars.
Eines i tècniques per crear aplicacions sense servidor
No hi ha cap manera específica de crear aplicacions sense servidor. Així com un conjunt de serveis per a aquesta tasca. AWS és el líder entre les potents solucions sense servidor actual, però també mireu , и . Si utilitzeu AWS, l'enfocament recomanat per recollir aplicacions és (SAM), especialment quan s'utilitza C#, perquè Visual Studio té una excel·lent eina. La SAM CLI pot fer tot el que Visual Studio pot fer, de manera que no perdreu res si canvieu a un altre IDE o editor de text. Per descomptat, SAM també funciona amb altres idiomes.
Si escriviu en altres idiomes, Serverless Framework és una excel·lent eina de codi obert que us permet configurar qualsevol cosa amb fitxers de configuració YAML molt potents. Serverless Framework també admet diversos serveis al núvol, per la qual cosa el recomanem a aquells que busquen una solució multinúvol. Té una comunitat enorme que ha creat un munt de complements per a qualsevol necessitat.
Per a proves locals, les eines de codi obert Docker-Lambda, Serverless Local, DynamoDB Local i LocalStack són molt adequades. Les tecnologies sense servidor encara es troben en les seves primeres etapes de desenvolupament, igual que les eines per a elles, de manera que quan us configureu per a escenaris de prova complexos, haureu de treballar dur. Tanmateix, simplement desplegar la pila en un entorn i provar-hi és increïblement barat. I no cal que feu una còpia local exacta dels entorns de núvol.
Utilitzeu AWS Lambda Layers per reduir la mida dels paquets desplegats i accelerar les descàrregues.
Utilitzeu els llenguatges de programació adequats per a tasques específiques. Els diferents idiomes tenen els seus propis avantatges i desavantatges. Hi ha molts punts de referència, però JavaScript, Python i C# (.NET Core 2.1+) són els líders pel que fa al rendiment d'AWS Lambda. AWS Lambda va presentar recentment l'API Runtime, que us permet especificar l'idioma i l'entorn d'execució que voleu, així que experimenteu.
Mantingueu les mides dels paquets petites per al desplegament. Com més petits són, més ràpid es carreguen. Eviteu utilitzar biblioteques grans, sobretot si feu servir un parell de funcions d'elles. Si esteu programant en JavaScript, utilitzeu una eina de creació com Webpack per optimitzar la vostra compilació i incloure només el que realment necessiteu. .NET Core 3.0 té QuickJit i la compilació per nivells que millora el rendiment i ajuda molt en els arrencades en fred.
La dependència de les funcions sense servidor en els esdeveniments pot dificultar la coordinació de la lògica empresarial al principi. En aquest sentit, les cues de missatges i les màquines d'estat poden ser increïblement útils. Les funcions Lambda es poden trucar mútuament, però només ho feu si no espereu una resposta ("dispara i oblida"); no voleu que us cobrin per esperar que es completi una altra funció. Les cues de missatges són útils per aïllar parts de la lògica empresarial, gestionar colls d'ampolla d'aplicacions i processar transaccions (utilitzant cues FIFO). Les funcions d'AWS Lambda es poden assignar a les cues SQS com a cues de missatges bloquejades que fan un seguiment dels missatges fallits per a una anàlisi posterior. Les AWS Step Functions (màquines d'estat) són molt útils per gestionar processos complexos que requereixen l'encadenament de funcions. En lloc que una funció Lambda cridi a una altra funció, les funcions Step poden coordinar transicions d'estat, passar dades entre funcions i gestionar l'estat global de les funcions. Això us permet definir les condicions de reintent o què fer quan es produeix un error en particular, una eina molt potent en determinades condicions.
Conclusió
En els últims anys, les tecnologies sense servidor s'han desenvolupat a un ritme sense precedents. Hi ha certes idees errònies associades a aquest canvi de paradigma. Abstraint la infraestructura i la gestió d'escala, les solucions sense servidor ofereixen avantatges importants, des de processos de desenvolupament i DevOps simplificats fins a reduccions massives dels costos operatius.
Tot i que l'enfocament sense servidor no està exempt de inconvenients, hi ha patrons de disseny robustos que es poden utilitzar per crear aplicacions sense servidor robustes o integrar elements sense servidor a les arquitectures existents.
Font: www.habr.com