ძირითადი პუნქტები

• უკვე რამდენიმე წელია გვპირდებიან, რომ სერვერის გარეშე გამოთვლა (სერვერის გარეშე) გახსნის ახალ ეპოქას აპლიკაციების გასაშვებად კონკრეტული ოპერაციული სისტემის გარეშე. გვითხრეს, რომ ასეთი სტრუქტურა მასშტაბურობის ბევრ პრობლემას გადაჭრის. სინამდვილეში, ყველაფერი სხვაგვარადაა.
• მიუხედავად იმისა, რომ ბევრი უსერვერო ტექნოლოგიას ახალ იდეად თვლის, მისი ფესვები შეიძლება 2006 წლიდან მოყოლებული იყოს Zimki PaaS-ით და Google App Engine-ით, რომლებიც ორივე სერვერის არქიტექტურას იყენებს.
• არსებობს ოთხი მიზეზი, რის გამოც სერვერის გარეშე რევოლუცია შეჩერდა, დაწყებული პროგრამირების ენის შეზღუდული მხარდაჭერით და დამთავრებული შესრულების საკითხებამდე.
• სერვერის გარეშე გამოთვლა არც ისე უსარგებლოა. Შორს. თუმცა, ისინი არ უნდა განიხილებოდეს როგორც სერვერების პირდაპირი შემცვლელი. ზოგიერთი აპლიკაციისთვის, ისინი შეიძლება იყოს მოსახერხებელი ინსტრუმენტი.

სერვერი მოკვდა, გაუმარჯოს სერვერს!

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

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

სერვერის გარეშე მოდელების ზოგიერთი დაპირება ნამდვილად შესრულდა, მაგრამ არა ყველა. Ყველა არა.

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

რასაც დაპირდნენ სერვერის გარეშე გამოთვლების ადეპტები

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

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

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

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

ეს მართლა ახალი იდეაა?

სინამდვილეში იდეა ახალი არ არის. კონცეფცია, რომელიც საშუალებას აძლევს მომხმარებლებს გადაიხადონ მხოლოდ კოდის რეალურად გაშვების დრო, არსებობს მას შემდეგ, რაც ის დაინერგა Zimki PaaS 2006 წელს და დაახლოებით იმავე დროს, Google App Engine-მა მოიფიქრა ძალიან მსგავსი გადაწყვეტა.

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

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

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

პრობლემები სერვერის მოდელებთან

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

Ამიტომაც.

პროგრამირების ენების შეზღუდული მხარდაჭერა

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

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

ეს ძირს უთხრის სერვერის გარეშე მოდელის ერთ-ერთ მთავარ უპირატესობას.

სავალდებულოა გამყიდველთან

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

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

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

მოქმედება

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

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

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

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

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

თქვენ არ შეგიძლიათ მთელი აპების გაშვება

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

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

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

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

გაუმარჯოს რევოლუციას?

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

წყარო: www.habr.com