AWS-მა Elastic Beanstalk აპლიკაციების მართვის სერვისად გადააკეთა

The New Stack-მა 22 სექტემბერს AWS-ის სპონსორებული სტატია გამოაქვეყნა, რომლის მთავარი არგუმენტია, რომ ღრუბლოვანი პლატფორმებისთვის პრობლემა სირთულე კი არა, ოპერაციული პასუხისმგებლობის მფლობელია. ტექსტის ავტორები არიან AWS-ის პროდუქტის მარკეტინგის მენეჯერი საბარი სავანტი და ანალიტიკოსი ჯანაკირამ MSV. სტატია აღწერს, როგორ გადააკეთა AWS-მა Elastic Beanstalk აპლიკაციების მართვის სერვისად, რომელიც პასუხისმგებელია აპლიკაციის ქვეშ არსებულ ყველა ფენაზე.

ღამის სამი საათის ტესტი

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

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

ოთხი წარუმატებლობის ნიმუში

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

ჯანაკირამ MSV თვლის, რომ ეს ხარვეზი სტრუქტურულია: cloud native-მა ინფრასტრუქტურის ფენა კონტეინერებისა და Kubernetes-ის გარშემო სტანდარტიზაცია მოახდინა, თუმცა არ დაარეგულირა ოპერაციული საზღვარი აპლიკაციის გუნდსა და მის ქვეშ არსებულ ინფრასტრუქტურას შორის. CNCF-ის კვლევა SlashData-სთან ერთად: ორგანიზაციათა 28%-ს ცალკე platform engineering გუნდი ჰყავს, 41% ამ ფუნქციებს გუნდებს შორის ანაწილებს, 3%-ს კი ფორმალური მიდგომა საერთოდ არ აქვს — სწორედ ამ კატეგორიაშია საშუალო ინჟინერული ორგანიზაციების უმეტესობა.

Standard და Cluster რეჟიმები

Elastic Beanstalk ახლა ორ რეჟიმში მუშაობს, რაც წინა ერთგარემოიანი არქიტექტურიდან ცვლილებაა. Standard რეჟიმი სრულ ოპერაციულ პასუხისმგებლობას იძლევა ერთი აპლიკაციისთვის, მათ შორის Windows-ისა და .NET Framework-ის დატვირთვებისთვის. Cluster რეჟიმი იმავე მოდელს მთელ პორტფელზე ავრცელებს საერთო ინფრასტრუქტურითა და კოდიდან წარმოებამდე განლაგებით; მერვე აპლიკაცია ხარჯებს პირველ შვიდთან იზიარებს.

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