ბოლო ათწლეულის ტექნოლოგიების მიმოხილვა

Შენიშვნა. თარგმნაეს Medium-ის ჰიტ-სტატია წარმოადგენს პროგრამირების ენების სამყაროში და მასთან დაკავშირებულ ტექნოლოგიურ ეკოსისტემაში (განსაკუთრებული ფოკუსირებით Docker-სა და Kubernetes-ზე) მიმდინარე ძირითადი (2010-2019) ცვლილებების მიმოხილვას. მისი თავდაპირველი ავტორია სინდი სრიდჰარანი, რომელიც სპეციალიზირებულია დეველოპერულ ინსტრუმენტებსა და განაწილებულ სისტემებში — კერძოდ, მან დაწერა წიგნი „განაწილებული სისტემების დაკვირვებადობა“ — და საკმაოდ პოპულარულია ინტერნეტ სივრცეში IT პროფესიონალებს შორის, განსაკუთრებით დაინტერესებულნი არიან ღრუბლოვანი ტექნოლოგიების თემით.

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

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

ტიპიზაცია უკან იხევს

2010-იანი წლების ერთ-ერთი ყველაზე დადებითი ტენდენცია სტატიკურად ტიპირებული ენების აღორძინება იყო. მიუხედავად იმისა, რომ სტატიკურად ტიპირებული ენები არასდროს გამქრალა (C++ და Java დღესაც მოთხოვნადია; ისინი ათი წლის წინ დომინანტური იყო), დინამიურად ტიპირებული ენების პოპულარობა მნიშვნელოვნად გაიზარდა 2005 წელს Ruby on Rails მოძრაობის გაჩენის შემდეგ. ეს ზრდა პიკს 2009 წელს მიაღწია Node.js-ის ღია კოდით გამოშვებამ, რამაც სერვერზე Javascript-ის გამოყენება რეალობად აქცია.

დროთა განმავლობაში, დინამიურმა ენებმა სერვერის მხარესთან მიმართებაში მიმზიდველობა დაკარგეს. Go, რომელიც კონტეინერების რევოლუციით გახდა პოპულარული, უფრო შესაფერისი ჩანდა მაღალი ხარისხის, რესურსების ეფექტური სერვერების შესაქმნელად პარალელური დამუშავებით (რომლითაც ვეთანხმები თავად Node.js-ის შემქმნელი).

2010 წელს წარდგენილ Rust-ში შედიოდა მიღწევები ტიპის თეორიები უსაფრთხო და აკრეფილ ენად გადაქცევის მცდელობისას. ათწლეულის პირველ ნახევარში Rust შედარებით პოპულარული იყო ინდუსტრიაში, მაგრამ მისი პოპულარობა მნიშვნელოვნად გაიზარდა მეორე ნახევარში. Rust-ის აღსანიშნავი გამოყენება მოიცავს მის გამოყენებას Magic Pocket Dropbox-ზე, Firecracker AWS-ისგან (ჩვენ მასზე ვისაუბრეთ ეს მუხლი - დაახლ. თარგმანი.), ადრეული WebAssembly კომპილატორი ლუსეტი Fastly-სგან (რომელიც ამჟამად bytecodealliance-ის ნაწილია) და სხვებისგან. იმ სიტუაციაში, როდესაც Microsoft ოპერაციული სისტემის ზოგიერთი ნაწილის გადაწერას განიხილავს Windows რასტ, თამამად შეგვიძლია ვთქვათ, რომ ენას 2020-იან წლებში ნათელი მომავალი აქვს.

დინამიურმა ენებმაც კი შეიძინეს ახალი ფუნქციები, როგორიცაა არჩევითი ტიპები (არასავალდებულო ტიპები)ისინი პირველად TypeScript-ში იქნა დანერგილი, ენაზე, რომელიც საშუალებას გაძლევთ შექმნათ აკრეფილი კოდი და კომპილაცია გაუკეთოთ JavaScript-ს. PHP-მ, Ruby-მ და Python-მა შეიძინეს საკუთარი, სურვილისამებრ, აკრეფის სისტემები (ჩემი, Hack), რომლებიც წარმატებით გამოიყენება წარმოების.

SQL-ის დაბრუნება NoSQL-ში

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

პირველ რიგში, NoSQL მოდელი, სქემის, ტრანზაქციების და სუსტი თანმიმდევრულობის გარანტიების გარეშე, უფრო რთული განსახორციელებელი აღმოჩნდა, ვიდრე SQL მოდელი. ბლოგ პოსტი სათაურით „რატომ უნდა მიანიჭოთ უპირატესობა მკაცრ თანმიმდევრულობას, როდესაც ეს შესაძლებელია“ (რატომ უნდა აირჩიოთ ძლიერი თანმიმდევრულობა, როდესაც ეს შესაძლებელია) Google წერს:

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

მეორე მიზეზი დაკავშირებულია „მასშტაბირებადი“ განაწილებული SQL მონაცემთა ბაზების ზრდასთან (მაგალითად, ღრუბლის შემცველი и AWS Aurora) საჯარო ღრუბლოვან სივრცეში, ასევე ღია კოდის ალტერნატივებში, როგორიცაა CockroachDB (ჩვენ ასევე ვისაუბრეთ მასზე писали - დაახლ. თარგმანი.), რომლებიც წყვეტენ მრავალ ტექნიკურ პრობლემას, რომლებიც ხელს უშლიდა ტრადიციული SQL მონაცემთა ბაზების მასშტაბირებას. MongoDB-ც კი, რომელიც ოდესღაც NoSQL მოძრაობის ერთ-ერთი მთავარი წარმომადგენელი იყო, ახლა შეთავაზებები განაწილებული ტრანზაქციები.

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

სრული სტრიმიფიკაცია

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

უწყვეტი ინტეგრაცია (და ნაკლებად უწყვეტი განლაგება)

უწყვეტი ინტეგრაცია ბოლო 10 წლის განმავლობაში ახალი კონცეფცია არ არის, მაგრამ ბოლო ათწლეულის განმავლობაში ის უფრო გავრცელებული გახდა. ასეთ მასშტაბზე გავრცელდა, რომელიც სტანდარტული სამუშაო პროცესის ნაწილი გახდა (ტესტების გაშვება ყველა pull request-ზე). GitHub-ის, როგორც კოდის შემუშავებისა და შენახვის პლატფორმის გაჩენა და, რაც მთავარია, სამუშაო პროცესის შემუშავება, რომელიც დაფუძნებულია GitHub ნაკადი ნიშნავს, რომ ტესტების გაშვება მასტერში pull request-ის მიღებამდე არის ერთი შემუშავების სამუშაო პროცესი, რომელიც ნაცნობია იმ ინჟინრებისთვის, რომლებმაც კარიერა ბოლო ათწლეულში დაიწყეს.

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

კონტეინერები

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

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

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

უსაფუძვლო

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

ავტომატიკა

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

უნივერსალური API-იფიკაცია

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

გარდა ამისა, API-იფიკაცია არის პირველი ნაბიჯი ზოგიერთი ფუნქციონალურობის ან ინსტრუმენტის SaaS-იფიკაციისკენ. ეს ტენდენცია ასევე დაემთხვა მიკროსერვისების აღზევებას: SaaS გახდა კიდევ ერთი სერვისი, რომელზეც წვდომა შესაძლებელია API-ს საშუალებით. ამჟამად არსებობს მრავალი SaaS და FOSS ინსტრუმენტი ისეთ სფეროებში, როგორიცაა მონიტორინგი, გადახდები, დატვირთვის დაბალანსება, უწყვეტი ინტეგრაცია, შეტყობინებები, ფუნქციონალურობის გადართვა. (ფუნქციის მონიშვნა), CDN, ტრაფიკის ინჟინერია (მაგ. DNS) და ა.შ., რომლებმაც ბოლო ათწლეულის განმავლობაში აყვავდა.

დაკვირვებადობა

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

განაწილებული ტრასირება კიდევ ერთი ტექნოლოგია იყო, რომელიც მეინსტრიმში 2010-იან წლებში შევიდა, ისეთი ინიციატივების წყალობით, როგორიცაა OpenTracing (და მისი მემკვიდრე OpenTelemetry). მიუხედავად იმისა, რომ ტრასირების განხორციელება ჯერ კიდევ საკმაოდ რთულია, ბოლოდროინდელი მოვლენები იმედს იძლევა, რომ მის ნამდვილ პოტენციალს 2020-იან წლებში გამოვავლენთ. (მთარგმნელის შენიშვნა: ასევე წაიკითხეთ სტატიის თარგმანი"Distributed Tracing: ჩვენ არასწორად გავაკეთეთ„იმავე ავტორის მიერ.“)

მომავლისკენ ხედვა

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

მურის კანონის პრობლემის გადაჭრა

დენარდის მასშტაბირების კანონის დასასრული და მურის კანონთან ჩამორჩენა ახალ ინოვაციას მოითხოვს. ჯონ ჰენესი მისი ლექცია განმარტავს, თუ რატომ არიან პრობლემური დამოკიდებულები (დომენის სპეციფიკური) ისეთი არქიტექტურები, როგორიცაა TPU, შეიძლება იყოს ერთ-ერთი გამოსავალი მურის კანონის ჩამორჩენის პრობლემისთვის. ისეთი ინსტრუმენტები, როგორიცაა MLI Google-ისგან უკვე კარგი ნაბიჯი ჩანს ამ მიმართულებით:

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

CI / CD

მიუხედავად იმისა, რომ CI-ის აღზევება 2010-იანი წლების ერთ-ერთი უდიდესი ტენდენცია იყო, ჯენკინსი CI-ის ოქროს სტანდარტად რჩება.

ამ სივრცეს სასწრაფოდ სჭირდება ინოვაცია შემდეგ სფეროებში:

• მომხმარებლის ინტერფეისი (DSL კოდირების ტესტის სპეციფიკაციებისთვის);
• განხორციელების დეტალები, რომლებიც მას ნამდვილად მასშტაბირებადს და სწრაფს გახდის;
• სხვადასხვა გარემოსთან (ეტაპობრივი, პროდიფიკაცია და ა.შ.) ინტეგრაცია ტესტირების უფრო მოწინავე ფორმების შესასრულებლად;
• უწყვეტი ტესტირება და განლაგება.

დეველოპერის ინსტრუმენტები

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

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

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

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

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

კომპიუტერული ტექნოლოგიები (PaaS-ის მომავალი)

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

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

ამ ღრუბლოვანი გადაწყვეტილებების მომხმარებლები შურის ღირსნი არიან. თეორიულად, ღრუბლოვანი Kubernetes-ის შეთავაზებები (GKE, EKS, EKS Fargate-ზე და ა.შ.) სამუშაო დატვირთვების გასაშვებად ღრუბელზე დამოუკიდებელ API-ებს გვთავაზობენ. თუ ასეთ პროდუქტებს იყენებთ (ECS, Fargate, Google Cloud Run და ა.შ.), სავარაუდოდ, უკვე იყენებთ სერვისის პროვაიდერის მიერ შემოთავაზებულ ყველაზე საინტერესო ფუნქციებს. გარდა ამისა, ახალი პროდუქტების ან გამოთვლითი პარადიგმების გაჩენასთან ერთად, მიგრაცია, სავარაუდოდ, მარტივი და უპრობლემო იქნება.

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

თუ ხელმისაწვდომს გადახედავთ დღეს გამოთვლითი შესაძლებლობების გათვალისწინებით, ცხადი ხდება, რომ საკუთარი PaaS-ის მხოლოდ Kubernetes-ზე აგება საკუთარი თავის კუთხეში მოქცევას უტოლდება (არც ისე პროგრესული მიდგომაა, არა?). მაშინაც კი, თუ ვინმე დღეს Kubernetes-ზე კონტეინერული PaaS-ის აგებას გადაწყვეტს, რამდენიმე წელიწადში ის ღრუბლოვან შესაძლებლობებთან შედარებით მოძველებულად გამოიყურება. მიუხედავად იმისა, რომ Kubernetes თავდაპირველად ღია კოდის პროექტად შეიქმნა, მისი წინაპარი და შთაგონების წყარო Google-ის შიდა ინსტრუმენტია. თუმცა, ის თავდაპირველად 2000-იანი წლების დასაწყისში/შუა პერიოდში შემუშავდა, როდესაც გამოთვლითი ლანდშაფტი ძალიან განსხვავებული იყო.

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

საბოლოოდ, მგონია, რომ ინდუსტრიის მხრივ ცოტა უკან დავიხიეთ ურთიერთქმედების გამოცდილება (UX). Heroku 2007 წელს გამოვიდა და დღემდე ერთ-ერთი ყველაზე მარტივი გამოსაყენებელი პლატფორმები. უდავოა, რომ Kubernetes გაცილებით მძლავრი, გაფართოებადი და პროგრამირებადია, მაგრამ მენატრება, რამდენად მარტივია მისი დაწყება და Heroku-ზე განთავსება. მის გამოსაყენებლად მხოლოდ Git-ის ცოდნაა საჭირო.

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

უმაღლესი დონის სწორი API

Docker შესანიშნავი მაგალითია იმისა, თუ რამდენად საჭიროა პრობლემების უკეთ გამიჯვნა, უმაღლესი დონის API-ის სწორი იმპლემენტაცია.

Docker-ის პრობლემა ის იყო, რომ (ყოველ შემთხვევაში) პროექტის თავდაპირველი მიზნები ზედმეტად გლობალური იყო: ყველაფერი თავსებადობის პრობლემის („ის ჩემს მანქანაზე მუშაობს“) კონტეინერული ტექნოლოგიის დახმარებით გადასაჭრელად. Docker იყო გამოსახულების ფორმატი, საკუთარი ვირტუალური ქსელით გაშვების დრო, CLI ინსტრუმენტი, root-ის ქვეშ მომუშავე დემონი და ბევრი სხვა. ნებისმიერ შემთხვევაში, შეტყობინებები იყო მეტი დამაბნეველია, რომ აღარაფერი ვთქვათ „მსუბუქი ვირტუალური მანქანების“, cჯგუფების, სახელთა სივრცეების, მრავალი უსაფრთხოების პრობლემისა და ფუნქციის შესახებ, რომელიც შერეულია მარკეტინგულ სლოგანთან „შექმენი, გაუშვი და გაუშვი ნებისმიერი აპლიკაცია ნებისმიერ ადგილას“.

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

Kubernetes-ს Docker-ის მსგავსი პრობლემების უმეტესობა აქვს. მაგარ და კომპოზიტირებად აბსტრაქციაზე ამდენი საუბრის მიუხედავად, სხვადასხვა დავალებების ფენებად დაყოფა არ არის კარგად კაფსულირებული. თავისი არსით, ეს არის კონტეინერის ორკესტრი, რომელიც მართავს კონტეინერებს სხვადასხვა მანქანების კლასტერზე. ეს საკმაოდ დაბალი დონის ამოცანაა, რომელიც გამოიყენება მხოლოდ კლასტერის ოპერირების ინჟინრებისთვის. მეორეს მხრივ, Kubernetes ასევე უმაღლესი დონის აბსტრაქცია, CLI ინსტრუმენტი, რომელთანაც მომხმარებლები ურთიერთქმედებენ YAML-ის საშუალებით.

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

Dockerfile და CLI პროგრამა docker უნდა იყოს კარგი „მაღალი დონის მომხმარებლის ინტერფეისის“ შექმნის მაგალითი. საშუალო დეველოპერს შეუძლია Docker-თან მუშაობა დაიწყოს სირთულეების შესახებ არაფერი იცოდეს. იმპლემენტაციები, რომლებიც ხელს უწყობენ ოპერაციულ გამოცდილებას, როგორიცაა სახელთა სივრცეები, cჯგუფები, მეხსიერებისა და CPU-ს ლიმიტები და ა.შ. საბოლოო ჯამში, Dockerfile-ის დაწერა დიდად არ განსხვავდება shell სკრიპტის დაწერისგან.

Kubernetes შექმნილია სხვადასხვა სამიზნე ჯგუფისთვის:

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

Kubernetes-ის მიერ გამოყენებული ერთი API-ს ყველასთვის შესაფერისი მიდგომა წარმოადგენს არასაკმარისად ინკაფსულირებულ „სირთულის მთას“, რომელსაც არ აქვს მისი მასშტაბირების ინსტრუქცია, რაც იწვევს ზედმეტად ხანგრძლივ სწავლის მრუდს. როგორ წერს ადამ ჯეიკობი, „Docker-მა მომხმარებლისთვის ტრანსფორმაციული გამოცდილება შესთავაზა, რომელსაც ჯერ კიდევ ვერავინ შეედრება. ჰკითხეთ ყველას, ვინც K8-ს იყენებს, სურს თუ არა, რომ ის მათი პირველი docker runპასუხი დადებითი იქნება“:

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

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

საცალო

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

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

ჟურნალისტიკა

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

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

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

სოციალური ქსელის

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

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

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

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

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

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

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «დოკერის ტრანსფორმაცია: Docker Enterprise-ის გაყიდვა Mirantis-ზე და განახლებული გზა";
• «Docker-ის და სხვა კონტეინერების გაშვების წარსული, აწმყო და მომავალი Kubernetes-ზე";
• «ახალი CNCF სტატისტიკა კონტეინერებზე, ღრუბელზე და Kubernetes-ზე";
• «რამდენი დეველოპერი ფიქრობს, რომ უწყვეტი ინტეგრაცია არ არის საჭირო?".

წყარო: www.habr.com