რჩევები და რესურსები სერვერის გარეშე აპლიკაციების შესაქმნელად

მიუხედავად იმისა, რომ უსერვერო ტექნოლოგიებმა სწრაფად მოიპოვა პოპულარობა ბოლო წლებში, ჯერ კიდევ არსებობს მათთან დაკავშირებული მრავალი მცდარი წარმოდგენა და შიში. მომწოდებლის დამოკიდებულება, ინსტრუმენტები, ხარჯების მენეჯმენტი, ცივი დაწყება, მონიტორინგი და განვითარების სასიცოცხლო ციკლი ყველა აქტუალური თემაა, როდესაც საქმე ეხება უსერვერო ტექნოლოგიებს. ამ სტატიაში ჩვენ განვიხილავთ ზოგიერთ ხსენებულ თემას, ასევე გავაზიარებთ რჩევებს და ბმულებს ინფორმაციის სასარგებლო წყაროებთან, რათა დამწყებთათვის დავეხმაროთ შექმნან ძლიერი, მოქნილი და ეკონომიური აპლიკაციები სერვერის გარეშე.

მცდარი წარმოდგენები სერვერის გარეშე ტექნოლოგიების შესახებ

ბევრი ფიქრობს, რომ სერვერის გარეშე და სერვერის დამუშავება (ფუნქციონირებს როგორც სერვისი, FaaS) თითქმის იგივეა. ეს ნიშნავს, რომ განსხვავება არც თუ ისე დიდია და ღირს სიახლის დანერგვა. მიუხედავად იმისა, რომ AWS Lambda იყო ერთ-ერთი ვარსკვლავი სერვერის გარეშე და სერვერის გარეშე არქიტექტურის ერთ-ერთი ყველაზე პოპულარული ელემენტი, თუმცა, ეს არქიტექტურა ბევრად მეტია ვიდრე FaaS.

სერვერის გარეშე ტექნოლოგიების ძირითადი პრინციპი არის ის, რომ თქვენ არ უნდა ინერვიულოთ თქვენი ინფრასტრუქტურის მართვასა და მასშტაბირებაზე, თქვენ იხდით მხოლოდ იმას, რასაც იყენებთ. ბევრი სერვისი შეესაბამება ამ კრიტერიუმებს - AWS DynamoDB, S3, SNS ან SQS, Graphcool, Auth0, Now, Netlify, Firebase და მრავალი სხვა. ზოგადად, სერვერის გარეშე ნიშნავს ღრუბლოვანი გამოთვლის სრული სიმძლავრის გამოყენებას ინფრასტრუქტურის მართვისა და სკალირების ოპტიმიზაციის გარეშე. ეს ასევე ნიშნავს, რომ უსაფრთხოება ინფრასტრუქტურის დონეზე აღარ არის თქვენი საზრუნავი, რაც უზარმაზარ სარგებელს წარმოადგენს უსაფრთხოების სტანდარტების დაკმაყოფილების სირთულისა და სირთულის გათვალისწინებით. და ბოლოს, თქვენ არ უნდა იყიდოთ თქვენთვის მოწოდებული ინფრასტრუქტურა.

სერვერის გარეშე შეიძლება ჩაითვალოს "გონების მდგომარეობა": გარკვეული მენტალიტეტი გადაწყვეტილებების შემუშავებისას. მოერიდეთ მიდგომებს, რომლებიც საჭიროებენ რაიმე ინფრასტრუქტურის შენარჩუნებას. სერვერის გარეშე მიდგომით, ჩვენ დროს ვხარჯავთ ამოცანების გადაჭრაზე, რომლებიც პირდაპირ გავლენას ახდენს პროექტზე და სარგებელს მოაქვს ჩვენს მომხმარებლებს: ჩვენ ვქმნით მდგრად ბიზნეს ლოგიკას, ვავითარებთ მომხმარებლის ინტერფეისებს და ვავითარებთ ადაპტირებულ და საიმედო API-ებს.

მაგალითად, თუ შესაძლებელია თავიდან ავიცილოთ თავისუფალი ტექსტის საძიებო პლატფორმის მართვა და შენარჩუნება, მაშინ ჩვენ ამას გავაკეთებთ. აპლიკაციების შექმნის ამ მიდგომამ შეიძლება მნიშვნელოვნად დააჩქაროს ბაზარზე გასვლის დრო, რადგან აღარ გჭირდებათ რთული ინფრასტრუქტურის მართვაზე ფიქრი. გააუქმეთ ინფრასტრუქტურის მენეჯმენტის პასუხისმგებლობა და ხარჯები და ფოკუსირდით თქვენს კლიენტებს საჭირო აპლიკაციებისა და სერვისების შექმნაზე. პატრიკ დებოისმა ამ მიდგომას უწოდა "მომსახურე", ტერმინი მიღებულია სერვერის გარეშე საზოგადოებაში. ფუნქციები უნდა განიხილებოდეს, როგორც სერვისების ბმული, როგორც განსათავსებელი მოდულები (მთელი ბიბლიოთეკის ან ვებ აპლიკაციის განლაგების ნაცვლად). ეს უზრუნველყოფს წარმოუდგენელ დეტალურობას განლაგებისა და აპლიკაციაში ცვლილებების მართვისთვის. თუ თქვენ არ შეგიძლიათ ამ გზით ფუნქციების დანერგვა, მაშინ ეს შეიძლება მიუთითებდეს, რომ ფუნქციები ასრულებენ ძალიან ბევრ დავალებას და საჭიროებენ რეფაქტორირებას.

ზოგიერთი დაბნეულია გამყიდველზე დამოკიდებულებით ღრუბლოვანი აპლიკაციების შემუშავებისას. იგივე ეხება უსერვერო ტექნოლოგიებს და ეს ძნელად მცდარი წარმოდგენაა. ჩვენი გამოცდილებიდან გამომდინარე, AWS-ზე სერვერის გარეშე აპლიკაციების შექმნა, AWS Lambda-ს სხვა AWS სერვისების ერთად შეკვრის შესაძლებლობასთან ერთად, უსერვერო არქიტექტურის სიძლიერის ნაწილია. ეს სინერგიის კარგი მაგალითია, როდესაც კომბინაციის შედეგი უფრო მეტია, ვიდრე ტერმინების ჯამი. გამყიდველზე დამოკიდებულების თავიდან აცილების მცდელობამ შეიძლება კიდევ უფრო მეტი პრობლემა წააწყდეს. კონტეინერებთან მუშაობისას უფრო ადვილია საკუთარი აბსტრაქციის ფენის მართვა ღრუბლოვან პროვაიდერებს შორის. მაგრამ როდესაც საქმე ეხება სერვერის გარეშე გადაწყვეტილებებს, ძალისხმევა არ გამოდგება, განსაკუთრებით თუ თავიდანვე გათვალისწინებული იქნება ხარჯების ეფექტურობა. დარწმუნდით, რომ გაარკვიეთ, როგორ ახორციელებენ მოვაჭრეები მომსახურებას. ზოგიერთი სპეციალიზებული სერვისი ეყრდნობა ინტეგრაციის წერტილებს სხვა მომწოდებლებთან და შეიძლება უზრუნველყოს plug-and-play კავშირის გარეშე. უფრო ადვილია ლამბდა ზარის მიწოდება კარიბჭის API ბოლო წერტილიდან, ვიდრე მოთხოვნის პროქსი რომელიმე კონტეინერზე ან EC2 მაგალითზე. Graphcool უზრუნველყოფს მარტივ კონფიგურაციას Auth0-ით, რაც უფრო ადვილია, ვიდრე მესამე მხარის ავტორიზაციის ინსტრუმენტების გამოყენება.

სერვერის გარეშე აპლიკაციისთვის სწორი გამყიდველის არჩევა არქიტექტურული გადაწყვეტილებაა. როდესაც ქმნით აპლიკაციას, არ ელით, რომ ერთ დღეს დაუბრუნდებით სერვერების მართვას. ღრუბლის გამყიდველის არჩევა არაფრით განსხვავდება კონტეინერების ან მონაცემთა ბაზის, ან თუნდაც პროგრამირების ენის არჩევისგან.

განიხილეთ:

• რა სერვისები გჭირდებათ და რატომ.
• რა სერვისებს აწვდიან ღრუბლოვანი პროვაიდერები და როგორ შეგიძლიათ დააკავშიროთ ისინი თქვენს მიერ არჩეულ FaaS გადაწყვეტასთან.
• რა პროგრამირების ენებია მხარდაჭერილი (დინამიური ან სტატიკური აკრეფით, კომპილირებული ან ინტერპრეტირებული, რა არის ბენჩმარკები, როგორია შესრულება ცივ დაწყებაზე, როგორია ღია კოდის ეკოსისტემა და ა.შ.).
• როგორია თქვენი უსაფრთხოების მოთხოვნები (SLA, 2FA, OAuth, HTTPS, SSL და ა.შ.).
• როგორ მართოთ თქვენი CI/CD და პროგრამული უზრუნველყოფის განვითარების ციკლები.
• რომელი ინფრასტრუქტურის კოდის გადაწყვეტილებებით შეგიძლიათ ისარგებლოთ.

თუ გააფართოვებთ არსებულ აპლიკაციას და თანდათან დაამატებთ სერვერის გარეშე ფუნქციონირებას, ამან შესაძლოა რამდენადმე შეზღუდოს ხელმისაწვდომი შესაძლებლობები. თუმცა, თითქმის ყველა უსერვერო ტექნოლოგია უზრუნველყოფს რაიმე სახის API-ს (REST ან შეტყობინებების რიგების საშუალებით), რომელიც საშუალებას გაძლევთ შექმნათ გაფართოებები აპლიკაციის ბირთვისგან დამოუკიდებლად და მარტივი ინტეგრაციით. მოძებნეთ სერვისები მკაფიო API-ებით, კარგი დოკუმენტაციით და ძლიერი თემით და ვერ შეცდებით. ინტეგრაციის სიმარტივე ხშირად შეიძლება იყოს საკვანძო მეტრიკა და, ალბათ, ეს არის ერთ-ერთი მთავარი მიზეზი იმისა, თუ რატომ იყო AWS ასეთი წარმატებული მას შემდეგ, რაც Lambda გამოვიდა 2015 წელს.

როდესაც სერვერის გარეშე კარგია

სერვერის გარეშე ტექნოლოგიების გამოყენება შესაძლებელია თითქმის ყველგან. თუმცა, მათი უპირატესობები არ შემოიფარგლება მხოლოდ ერთი მეთოდით. ღრუბლოვანი გამოთვლებისთვის შესვლის ბარიერი დღეს იმდენად დაბალია სერვერის გარეშე ტექნოლოგიების წყალობით. თუ დეველოპერებს აქვთ იდეა, მაგრამ არ იციან როგორ მართონ ღრუბლოვანი ინფრასტრუქტურა და ოპტიმიზაცია გაუწიონ ხარჯებს, მაშინ მათ არ სჭირდებათ რაიმე სახის ინჟინრის ძიება ამის გასაკეთებლად. თუ სტარტაპს სურს შექმნას პლატფორმა, მაგრამ შიშობს, რომ ხარჯები შეიძლება გამოვიდეს კონტროლიდან, მათ შეუძლიათ ადვილად მიმართონ სერვერის გარეშე გადაწყვეტილებებს.

ხარჯების დაზოგვისა და სკალირების სიმარტივის გამო, სერვერის გარეშე გადაწყვეტილებები თანაბრად გამოიყენება როგორც შიდა, ასევე გარე სისტემებისთვის, მრავალმილიონიანი აუდიტორიის მქონე ვებ აპლიკაციამდე. ანგარიშები იზომება და არა ევროში, არამედ ცენტებში. AWS EC2-ის უმარტივესი ეგზემპლარის (t1.micro) დაქირავება ერთი თვის განმავლობაში ეღირება 15 ევრო, მაშინაც კი, თუ მას არაფერი გააკეთებთ (ვის არასოდეს დაავიწყდა მისი გამორთვა?!). შედარებისთვის, დროის ერთსა და იმავე პერიოდში დახარჯვის ამ დონეს რომ მიაღწიოთ, დაგჭირდებათ 512 MB ლამბდას გაშვება 1 წამში დაახლოებით 3 მილიონჯერ. და თუ ამ ფუნქციას არ იყენებთ, მაშინ არაფერს იხდით.

იმის გამო, რომ სერვერის გარეშე, ძირითადად, მოვლენებზეა ორიენტირებული, საკმაოდ მარტივია უსერვერო ინფრასტრუქტურის დამატება ძველ სისტემებში. მაგალითად, AWS S3, Lambda და Kinesis-ის გამოყენებით, შეგიძლიათ შექმნათ ანალიტიკური სერვისი ძველი საცალო სისტემისთვის, რომელსაც შეუძლია მონაცემების მიღება API-ის მეშვეობით.

უსერვერო პლატფორმების უმეტესობა მხარს უჭერს მრავალ ენას. ყველაზე ხშირად ეს არის Python, JavaScript, C#, Java და Go. როგორც წესი, არ არსებობს შეზღუდვები ბიბლიოთეკების გამოყენებაზე ყველა ენაზე, ასე რომ თქვენ შეგიძლიათ გამოიყენოთ თქვენი საყვარელი ღია კოდის ბიბლიოთეკები. თუმცა, მიზანშეწონილია არ გამოიყენოთ დამოკიდებულებების ბოროტად გამოყენება, რათა თქვენი ფუნქციები ოპტიმალურად შესრულდეს და არ უარყოთ თქვენი სერვერის გარეშე აპლიკაციების უზარმაზარი მასშტაბურობის უპირატესობები. რაც უფრო მეტი პაკეტი უნდა ჩაიტვირთოს კონტეინერში, მით უფრო დიდხანს გაგრძელდება ცივი დაწყება.

ცივი დაწყება არის ის, როდესაც პირველად გჭირდებათ კონტეინერის, გაშვების და შეცდომების დამმუშავებლის ინიციალიზაცია მათ გამოყენებამდე. ამის გამო, ფუნქციების შესრულების შეფერხება შეიძლება იყოს 3 წამამდე და ეს არ არის საუკეთესო ვარიანტი მოუთმენელი მომხმარებლებისთვის. თუმცა, ცივი გაშვება ხდება პირველი ზარის დროს უმოქმედო ფუნქციის რამდენიმე წუთის შემდეგ. ასე რომ, ბევრი მიიჩნევს, რომ ეს უმნიშვნელო გაღიზიანებაა, რომლის მოგვარებაც შესაძლებელია ფუნქციის რეგულარულად პინგით, რათა ის უმოქმედო იყოს. ან საერთოდ უგულებელყოფენ ამ ასპექტს.

მიუხედავად იმისა, რომ AWS გამოვიდა სერვერის გარეშე SQL მონაცემთა ბაზა სერვერის გარეშე Auroraთუმცა, SQL მონაცემთა ბაზები არ არის იდეალური ამ აპლიკაციისთვის, რადგან ისინი დამოკიდებულნი არიან კავშირებზე ტრანზაქციების შესასრულებლად, რაც შეიძლება სწრაფად იქცეს ბოსტნეულად მძიმე ტრაფიკით AWS Lambda-ზე. დიახ, დეველოპერები მუდმივად აუმჯობესებენ სერვერის ავრორას და თქვენ უნდა ექსპერიმენტი გააკეთოთ, მაგრამ დღეს NoSQL გადაწყვეტილებები, როგორიცაა დინამოდბ. თუმცა, ეჭვგარეშეა, რომ ეს მდგომარეობა ძალიან მალე შეიცვლება.

ინსტრუმენტთა ნაკრები ასევე აწესებს უამრავ შეზღუდვას, განსაკუთრებით ლოკალური ტესტირების სფეროში. მიუხედავად იმისა, რომ არსებობს გადაწყვეტილებები, როგორიცაა Docker-Lambda, DynamoDB Local და LocalStack, ისინი საჭიროებენ შრომას და კონფიგურაციის მნიშვნელოვან რაოდენობას. თუმცა, ყველა ეს პროექტი აქტიურად არის შემუშავებული, ასე რომ, მხოლოდ დროის საკითხია, სანამ ინსტრუმენტთა ნაკრები მიაღწევს ჩვენთვის საჭირო დონეს.

სერვერის გარეშე ტექნოლოგიების გავლენა განვითარების ციკლზე

იმის გამო, რომ თქვენი ინფრასტრუქტურა მხოლოდ კონფიგურაციაა, შეგიძლიათ განსაზღვროთ და განათავსოთ კოდი სკრიპტების გამოყენებით, როგორიცაა shell სკრიპტები. ან შეგიძლიათ მიმართოთ კონფიგურაციის კოდის კლასის გადაწყვეტილებებს, როგორიცაა AWS ღრუბლის ფორმირება. მიუხედავად იმისა, რომ ეს სერვისი არ იძლევა კონფიგურაციას ყველა ზონისთვის, ის საშუალებას გაძლევთ განსაზღვროთ კონკრეტული რესურსები, რომ გამოიყენოთ როგორც ლამბდა ფუნქციები. ანუ იქ, სადაც CloudFormation ვერ შეგიშლით, შეგიძლიათ დაწეროთ თქვენი საკუთარი რესურსი (ლამბდა ფუნქცია), რომელიც დახურავს ამ ხარვეზს. ამ გზით თქვენ შეგიძლიათ გააკეთოთ ყველაფერი, თუნდაც თქვენი AWS გარემოს გარეთ დამოკიდებულებების კონფიგურაცია.

იმის გამო, რომ ეს ყველაფერი მხოლოდ კონფიგურაციაა, შეგიძლიათ თქვენი განლაგების სკრიპტების მორგება კონკრეტული გარემოებისთვის, რეგიონებისთვის და მომხმარებლებისთვის, განსაკუთრებით თუ იყენებთ ინფრასტრუქტურის კოდის გადაწყვეტილებებს, როგორიცაა CloudFormation. მაგალითად, თქვენ შეგიძლიათ განათავსოთ ინფრასტრუქტურის ასლი თითოეული ფილიალისთვის საცავში, რათა შეძლოთ მათი გამოცდა მთლიანად იზოლირებულად განვითარების დროს. ეს მკვეთრად აჩქარებს გამოხმაურებას დეველოპერებისთვის, როდესაც მათ სურთ გაიგონ, მუშაობს თუ არა მათი კოდი ადეკვატურად ცოცხალ გარემოში. მენეჯერებს არ სჭირდებათ ფიქრი მრავალი გარემოს განლაგების ხარჯზე, რადგან ისინი იხდიან მხოლოდ რეალურ გამოყენებას.

DevOps-ებს ნაკლები საზრუნავი აქვთ, რადგან მათ მხოლოდ უნდა დარწმუნდნენ, რომ დეველოპერებს აქვთ სწორი კონფიგურაცია. თქვენ აღარ გჭირდებათ ინსტანციების, ბალანსირების ან უსაფრთხოების ჯგუფების მართვა. ამიტომ, ტერმინი NoOps სულ უფრო ხშირად გამოიყენება, თუმცა მაინც მნიშვნელოვანია ინფრასტრუქტურის კონფიგურაციის შესაძლებლობა, განსაკუთრებით მაშინ, როდესაც საქმე ეხება IAM კონფიგურაციას და ღრუბლოვანი რესურსების ოპტიმიზაციას.

არსებობს ძალიან ძლიერი მონიტორინგისა და ვიზუალიზაციის ინსტრუმენტები, როგორიცაა Epsagon, Thundra, Dashbird და IOPipe. ისინი საშუალებას გაძლევთ აკონტროლოთ თქვენი სერვერის გარეშე აპლიკაციების ამჟამინდელი მდგომარეობა, უზრუნველვყოთ აღრიცხვა და მიკვლევა, აღბეჭდოთ შესრულების მეტრიკა და არქიტექტურის შეფერხებები, შეასრულოთ ხარჯების ანალიზი და პროგნოზირება და სხვა. ისინი არა მხოლოდ აძლევენ DevOps ინჟინრებს, დეველოპერებს და არქიტექტორებს აპლიკაციის მუშაობის ყოვლისმომცველ ხედვას, არამედ საშუალებას აძლევს მენეჯერებს რეალურ დროში აკონტროლონ სიტუაცია, წამში რესურსის ხარჯებით და ხარჯების პროგნოზით. გაცილებით რთულია ამის ორგანიზება მართული ინფრასტრუქტურით.

სერვერის გარეშე აპლიკაციების შექმნა ბევრად უფრო ადვილია, რადგან თქვენ არ გჭირდებათ ვებ სერვერების დაყენება, ვირტუალური მანქანების ან კონტეინერების მართვა, პატჩ სერვერები, ოპერაციული სისტემები, ინტერნეტ კარიბჭეები და ა.შ. გადაწყვეტა ბიზნესისა და მომხმარებლის საჭიროებები.

მიუხედავად იმისა, რომ ხელსაწყოების ნაკრები შეიძლება უკეთესი იყოს (ის დღითიდღე უკეთესი ხდება), დეველოპერებს შეუძლიათ ფოკუსირება მოახდინონ ბიზნეს ლოგიკის განხორციელებაზე და აპლიკაციის სირთულის საუკეთესოდ განაწილებაზე სხვადასხვა სერვისებში არქიტექტურაში. სერვერის გარეშე აპლიკაციის მართვა ხდება მოვლენებზე დაფუძნებული და აბსტრაქტული ღრუბლის პროვაიდერის მიერ (მაგ. SQS, S3 მოვლენები ან DynamoDB ნაკადები). ამიტომ, დეველოპერებს მხოლოდ ბიზნეს ლოგიკის დაწერა სჭირდებათ გარკვეულ მოვლენებზე რეაგირებისთვის და არ უნდა ინერვიულონ იმაზე, თუ როგორ უკეთესად განახორციელონ მონაცემთა ბაზები და შეტყობინებების რიგები, ან როგორ მოაწყონ ოპტიმალური მუშაობა მონაცემებთან კონკრეტულ ტექნიკის საცავებში.

კოდის გაშვება და გამართვა შესაძლებელია ადგილობრივად, როგორც განვითარების ნებისმიერ პროცესში. ერთეულის ტესტირება იგივე რჩება. აპლიკაციის მთელი ინფრასტრუქტურის განლაგების შესაძლებლობა მორგებული სტეკის კონფიგურაციით, დეველოპერებს საშუალებას აძლევს სწრაფად მიიღონ მნიშვნელოვანი გამოხმაურება ტესტირების ხარჯებზე ან ძვირად მართულ გარემოზე ზემოქმედების გარეშე.

ინსტრუმენტები და ტექნიკა სერვერის გარეშე აპლიკაციების შესაქმნელად

არ არსებობს კონკრეტული გზა სერვერის გარეშე აპლიკაციების შესაქმნელად. ასევე ამ ამოცანისთვის სერვისების კომპლექტი. AWS დღეს ლიდერია სერვერის გარეშე მძლავრ გადაწყვეტილებებს შორის, მაგრამ შეხედეთ ასევე Google Cloud, დრო и Firebase. თუ იყენებთ AWS-ს, მაშინ რეკომენდებულია აპლიკაციების შეგროვების მიდგომა სერვერის აპლიკაციის მოდელი (SAM), განსაკუთრებით C#-ის გამოყენებისას, რადგან Visual Studio-ს აქვს შესანიშნავი ინსტრუმენტები. SAM CLI-ს შეუძლია გააკეთოს ყველაფერი, რისი გაკეთებაც Visual Studio-ს შეუძლია, ასე რომ თქვენ არაფერს დაკარგავთ, თუ სხვა IDE-ზე ან ტექსტურ რედაქტორზე გადახვალთ. რა თქმა უნდა, SAM მუშაობს სხვა ენებთანაც.

თუ თქვენ წერთ სხვა ენებზე, Serverless Framework არის შესანიშნავი ღია კოდის ინსტრუმენტი, რომელიც საშუალებას გაძლევთ დააკონფიგურიროთ ყველაფერი ძალიან ძლიერი YAML კონფიგურაციის ფაილებით. Serverless Framework ასევე მხარს უჭერს სხვადასხვა ღრუბლოვან სერვისებს, ამიტომ ჩვენ გირჩევთ მას, ვინც ეძებს მრავალ ღრუბლოვან გადაწყვეტას. მას აქვს უზარმაზარი საზოგადოება, რომელმაც შექმნა დანამატების თაიგული ნებისმიერი საჭიროებისთვის.

ადგილობრივი ტესტირებისთვის, ღია კოდის ინსტრუმენტები Docker-Lambda, Serverless Local, DynamoDB Local და LocalStack კარგად არის შესაფერისი. სერვერის გარეშე ტექნოლოგიები ჯერ კიდევ განვითარების ადრეულ ეტაპზეა, ისევე როგორც მათთვის ინსტრუმენტები, ასე რომ, რთული ტესტის სცენარებისთვის დაყენებისას, თქვენ მოგიწევთ შრომა. თუმცა, უბრალოდ სტეკის განლაგება გარემოში და იქ ტესტირება წარმოუდგენლად იაფია. და თქვენ არ გჭირდებათ ღრუბლოვანი გარემოს ზუსტი ლოკალური ასლის გაკეთება.

გამოიყენეთ AWS Lambda Layers განლაგებული პაკეტების ზომის შესამცირებლად და ჩამოტვირთვის დასაჩქარებლად.

გამოიყენეთ სწორი პროგრამირების ენები კონკრეტული ამოცანებისთვის. სხვადასხვა ენას აქვს თავისი დადებითი და უარყოფითი მხარეები. ბევრი საორიენტაციო ნიშანი არსებობს, მაგრამ JavaScript, Python და C# (.NET Core 2.1+) ლიდერები არიან AWS Lambda შესრულების თვალსაზრისით. AWS Lambda-მ ცოტა ხნის წინ წარმოადგინა Runtime API, რომელიც საშუალებას გაძლევთ მიუთითოთ სასურველი ენა და გაშვების გარემო, ამიტომ ექსპერიმენტი.

შეინახეთ პაკეტის ზომები მცირე განლაგებისთვის. რაც უფრო პატარაა ისინი, მით უფრო სწრაფად იტვირთება. მოერიდეთ დიდი ბიბლიოთეკების გამოყენებას, განსაკუთრებით თუ მათგან რამდენიმე ფუნქციას იყენებთ. თუ პროგრამირებთ JavaScript-ში, გამოიყენეთ build ინსტრუმენტი, როგორიცაა Webpack თქვენი კონსტრუქციის ოპტიმიზაციისთვის და მხოლოდ ის, რაც ნამდვილად გჭირდებათ. .NET Core 3.0-ს აქვს QuickJit და Tiered Compilation, რომელიც აუმჯობესებს შესრულებას და ბევრს ეხმარება ცივ დაწყებაში.

უსერვერო ფუნქციების დამოკიდებულება მოვლენებზე შეიძლება გაართულოს თავიდან ბიზნეს ლოგიკის კოორდინაცია. ამ მხრივ, შეტყობინებების რიგები და სახელმწიფო მანქანები შეიძლება წარმოუდგენლად სასარგებლო იყოს. ლამბდას ფუნქციებს შეუძლიათ დაურეკონ ერთმანეთს, მაგრამ გააკეთეთ ეს მხოლოდ იმ შემთხვევაში, თუ არ ელით პასუხს („ცეცხლი და დაივიწყეთ“) - არ გსურთ სხვა ფუნქციის დასრულების მოლოდინის გადახდა. შეტყობინებების რიგები სასარგებლოა ბიზნეს ლოგიკის ნაწილების იზოლირებისთვის, აპლიკაციების შეფერხებების მართვისა და ტრანზაქციების დასამუშავებლად (FIFO რიგების გამოყენებით). AWS Lambda ფუნქციები შეიძლება მიენიჭოს SQS რიგებს, როგორც შეტყობინებების რიგები, რომლებიც აკონტროლებენ წარუმატებელ შეტყობინებებს შემდგომი ანალიზისთვის. AWS Step Functions (state machines) ძალიან სასარგებლოა რთული პროცესების სამართავად, რომლებიც საჭიროებენ ფუნქციების ჯაჭვობას. იმის ნაცვლად, რომ Lambda ფუნქცია გამოიძახოს სხვა ფუნქცია, Step ფუნქციებს შეუძლიათ კოორდინაცია გაუკეთონ მდგომარეობებს, გადასცენ მონაცემები ფუნქციებს შორის და მართონ ფუნქციების გლობალური მდგომარეობა. ეს საშუალებას გაძლევთ განსაზღვროთ განმეორებითი ცდის პირობები, ან რა უნდა გააკეთოთ, როდესაც კონკრეტული შეცდომა ხდება - ძალიან ძლიერი ინსტრუმენტი გარკვეულ პირობებში.

დასკვნა

ბოლო წლებში უპრეცედენტო ტემპით ვითარდება უსერვერო ტექნოლოგიები. არსებობს გარკვეული მცდარი წარმოდგენები, რომლებიც დაკავშირებულია ამ პარადიგმის ცვლილებასთან. ინფრასტრუქტურის აბსტრაქტირებისა და სკალირების მენეჯმენტის საშუალებით, სერვერის გარეშე გადაწყვეტილებები გვთავაზობენ მნიშვნელოვან სარგებელს, გამარტივებული განვითარებისა და DevOps პროცესებიდან დაწყებული საოპერაციო ხარჯების მასიური შემცირებით.
მიუხედავად იმისა, რომ სერვერის გარეშე მიდგომა ნაკლოვანებების გარეშე არ არის, არსებობს მძლავრი დიზაინის შაბლონები, რომლებიც შეიძლება გამოყენებულ იქნას ძლიერი სერვერის გარეშე აპლიკაციების შესაქმნელად ან სერვერის გარეშე ელემენტების არსებულ არქიტექტურაში ინტეგრირებისთვის.

წყარო: www.habr.com