{"id":55881,"date":"2020-01-31T00:00:00","date_gmt":"2020-01-30T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sovety-i-istochniki-informatsii-dlya-sozdaniya-besservernyh-prilozhenij"},"modified":"2020-02-18T14:04:02","modified_gmt":"2020-02-18T11:04:02","slug":"sovety-i-istochniki-informatsii-dlya-sozdaniya-besservernyh-prilozhenij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sovety-i-istochniki-informatsii-dlya-sozdaniya-besservernyh-prilozhenij","title":{"rendered":"Tips og kilder til oprettelse af serverl\u00f8se applikationer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Tips
\nSelvom serverl\u00f8se teknologier hurtigt er blevet popul\u00e6re i de senere \u00e5r, er der stadig mange misforst\u00e5elser og bekymringer forbundet med dem. Afh\u00e6ngighed af leverand\u00f8rer, v\u00e6rkt\u00f8jer, omkostningsstyring, kold start, overv\u00e5gning og udviklingslivscyklus \u2013 disse emner diskuteres ofte, n\u00e5r det kommer til serverl\u00f8se teknologier. I denne artikel vil vi se p\u00e5 nogle af de n\u00e6vnte emner samt dele tips og links til nyttige informationskilder, som nybegyndere kan bruge til at bygge kraftfulde, fleksible og omkostningseffektive serverl\u00f8se applikationer.
\n<\/a><\/noindex><\/p>\n

Misforst\u00e5elser omkring serverl\u00f8se teknologier<\/h2>\n

\nMange tror, at serverl\u00f8se og serverbaserede databehandling (Functions as a Service<\/a><\/noindex>, FaaS) n\u00e6sten betyder det samme. Det betyder, at forskellen ikke er s\u00e5 stor, og det er v\u00e6rd at implementere nyheden. Selvom AWS Lambda var en af 'stjernerne' i fremgangen af serverl\u00f8se teknologier og et af de mest popul\u00e6re elementer i serverless arkitekturen, er denne arkitektur dog mere end bare FaaS.<\/p>\n

Det grundl\u00e6ggende princip for serverl\u00f8se teknologier er, at du ikke beh\u00f8ver at bekymre dig om at administrere og skalere infrastrukturen; du betaler kun for det, du bruger. Mange services opfylder disse kriterier \u2013 AWS DynamoDB, S3, SNS eller SQS, Graphcool, Auth0, Now, Netlify, Firebase og mange andre. Generelt indeb\u00e6rer serverl\u00f8shed at udnytte alle mulighederne inden for cloud computing uden behov for at administrere infrastrukturer og optimere dem for skalering. Det betyder ogs\u00e5, at sikkerhed p\u00e5 infrastrukturelt niveau ikke l\u00e6ngere er dit problem, hvilket er en stor fordel, givet kompleksiteten og udfordringerne ved at overholde sikkerhedsstandarder. Endelig beh\u00f8ver du ikke at k\u00f8be den infrastruktur, der er stillet til r\u00e5dighed for dig.<\/p>\n

Serverl\u00f8shed kan betragtes som en 'tankegang': en bestemt mentalitet ved design af l\u00f8sninger. Undg\u00e5 tilgange, der kr\u00e6ver vedligeholdelse af nogen infrastruktur. Med den serverl\u00f8se tilgang bruger vi tid p\u00e5 at l\u00f8se opgaver, der direkte p\u00e5virker projektet og giver fordele for vores brugere: vi skaber robust forretningslogik, udvikler brugergr\u00e6nseflader og designer tilpassede og p\u00e5lidelige API'er.<\/p>\n

For example, if we can avoid managing and maintaining a free-text search platform, that's exactly what we will do. This approach to application assembly can significantly speed up the time to market since you no longer need to think about managing complex infrastructure. Get rid of the responsibilities and costs of infrastructure management and focus on creating the applications and services that your customers need. Patrick Debois referred to this approach \u2018servicefull\u2019<\/a><\/noindex>, this term is accepted in the serverless community. Functions should be viewed as a connecting link for services in the form of deployable modules (instead of deploying an entire library or web application). This provides incredible granularity in managing deployments and changes within the application. If you cannot deploy functions this way, it may indicate that the functions are taking on too many tasks and need to be refactored.<\/p>\n

Nogle bliver forvirrede over afh\u00e6ngigheden af leverand\u00f8ren ved udviklingen af skyapplikationer. Det samme g\u00e6lder for serverl\u00f8se teknologier, og det er n\u00e6ppe en fejltagelse. Efter vores erfaring er oprettelsen af serverl\u00f8se applikationer p\u00e5 AWS sammen med AWS Lambdas evne til at integrere andre AWS-tjenester alt sammen med til at forme fordelene ved serverl\u00f8se arkitekturer. Det er et godt eksempel p\u00e5 synergi, hvor resultatet af sammenslutningen bliver st\u00f8rre end blot summen af delene. Hvis du fors\u00f8ger at undg\u00e5 afh\u00e6ngighed af leverand\u00f8ren, kan du st\u00f8de p\u00e5 endnu st\u00f8rre problemer. N\u00e5r du arbejder med containere, er det lettere at styre dit eget abstraktionsniveau mellem skyudbydere. Men hvad ang\u00e5r serverl\u00f8se l\u00f8sninger, vil indsatsen ikke betale sig, is\u00e6r hvis man allerede fra starten tager hensyn til \u00f8konomisk effektivitet. S\u00f8rg for at finde ud af, hvordan udbyderne leverer deres tjenester. Nogle specialiserede tjenester er afh\u00e6ngige af integrationspunkter med andre leverand\u00f8rer og kan ud af boksen tilbyde plug-and-play-forbindelse. Det er lettere at kalde Lambda fra en API Gateway-endepunkt end at proxye en anmodning til en hvilken som helst container eller EC2-instans. Graphcool tilbyder nem konfiguration med Auth0, hvilket er lettere end at bruge tredjeparts autentifikation.<\/p>\n

Valget af den rigtige leverand\u00f8r til din serverl\u00f8se applikation er en beslutning p\u00e5 arkitekturniveau. N\u00e5r du opretter en applikation, forventer du ikke at skulle vende tilbage til serveradministration. Valget af skyudbyder adskiller sig ikke fra valget af at bruge containere eller databaser, eller endda programmeringssprog. <\/p>\n

Overvej:<\/p>\n