34-წუთიანი სამუშაო სესია იმაზე, თუ რა არის სინამდვილეში "ღრუბელი" — სერვისის მოდელები, სამშენებლო ბლოკები (გამოთვლა, საცავი, ქსელი), ვინ არის პასუხისმგებელი უსაფრთხოებაზე, როგორ გროვდება ანგარიში სინამდვილეში და როგორ ედრება ერთმანეთს სამი დიდი პროვაიდერი, როცა არჩევანის გაკეთება გიწევთ.
მარკეტინგს რომ ჩამოაცილებთ, ღრუბელი მარტივი გარიგებაა: სერვერების ყიდვისა და მათით სავსე ოთახის მოვლის ნაცვლად, ინტერნეტით ქირაობთ სიმძლავრეს პროვაიდერისგან და იხდით მხოლოდ იმაში, რასაც იყენებთ. ნამდვილი კითხვა ის არაა, გამოიყენოთ თუ არა — არამედ ის, სტეკის რა ნაწილის მართვა გინდათ თავად.
ხაფანგი: კომფორტს ფასი აქვს, ვენდორზე მიბმა რეალურია და უყურადღებო კონფიგურაციამ შეიძლება ანგარიში გაბეროს ან მონაცემები გაჟონოს. ყველაფერი, რაც წინ არის, იმაზეა, როგორ დახარჯოთ ეს კომპრომისი გონივრულად.
რაც უფრო მარჯვნივ მიდიხართ, მით მეტ ნაწილს იბარებს პროვაიდერი. თქვენთან ყოველთვის რჩება ის სამუშაო, რაც ნამდვილად თქვენი საქმეა.
ქირაობთ სუფთა სამშენებლო ბლოკებს — ვირტუალურ მანქანებს, დისკებს, ქსელებს — და მართავთ OS-ს და ყველაფერს, რაც მის ზემოთაა. მაქსიმალური კონტროლი, მაქსიმალური პასუხისმგებლობა.
აგზავნით კოდს; პლატფორმა უშვებს მას — თავად უვლის OS-ს, რანტაიმს, პატჩებსა და მასშტაბირებას. ნაკლები კონტროლი, ბევრად ნაკლები ოპერაციები.
უბრალოდ იყენებთ მზა პროგრამას ვებით — Gmail, Slack, Salesforce. ყველაფერს პროვაიდერი უშვებს; თქვენ მხოლოდ თქვენს მონაცემებსა და მომხმარებლებს მართავთ.
გამოთვლა არის ის, სადაც თქვენი კოდი რეალურად სრულდება. ღრუბელი მთელ სპექტრს გთავაზობთ: იქირავეთ მთელი ვირტუალური მანქანა და თავად მართეთ, შეფუთეთ აპლიკაცია მსუბუქ კონტეინერში, ან გადაეცით პროვაიდერს ერთი ფუნქცია და სერვერები საერთოდ დაივიწყეთ. ყოველი ნაბიჯი მარჯვნივ ნიშნავს ნაკლებ კონტროლს, სამაგიეროდ — ნაკლებ საოპერაციო ტვირთს.
ერთი და იგივე კოდი სამივეზე გაეშვება — არჩევანი ისაა, მანქანის რა ნაწილზე გინდათ ფიქრი.
// serverless: you ship ONLY this — no server, no OS export async function handler(event: { query: { name?: string } }) { const name = event.query.name ?? "world" return { status: 200, body: `hello, ${name}`, } } // idle? it scales to zero. spike? the platform adds copies.
არც main(), არც მისაბმელი პორტი, არც ფლოტის ზომის შერჩევა — პროვაიდერი ამას მოთხოვნისამებრ უშვებს და ყოველ გამოძახებაზე გიწერთ.
გჭირდებათ კონკრეტული OS ან ბირთვი, ლეგაცი პროგრამა, GPU-ები, ან გაქვთ სტაბილური, პროგნოზირებადი დატვირთვა, სადაც მუდამ ჩართული ყველაზე იაფია.
გინდათ პორტატულობა, სწრაფი დეპლოი და მჭიდრო შეფუთვა — დღეს ეს ნაგულისხმევი არჩევანია მიკროსერვისებისა და ვებ-ბექენდების უმეტესობისთვის.
ტრაფიკი მკვეთრად ცვალებადი ან დაბალია, ან საქმე შემაერთებელ კოდს ეხება: ვებჰუკები, cron-ამოცანები, მოვლენების დამმუშავებლები, მსუბუქი API-ები ეჯზე.
ყველა საცავი ერთნაირი არაა. არასწორი ტიპის არჩევა გავრცელებული და ძვირი შეცდომაა — ამიტომ ღირს იცოდეთ სამი პრიმიტივი, რომელსაც ყველა ღრუბელი გთავაზობთ, და ზუსტად რისთვისაა თითოეული: ობიექტური — ფაილებისთვის მასშტაბში, ბლოკური — დისკებისთვის, ფაილური — საზიარო დირექტორიებისთვის.
იაფი, პრაქტიკულად უსასრულო, HTTP-ით გასაღებით ხელმისაწვდომი. ადგილზე რედაქტირება არ არის — მთელ ობიექტს ცვლით. გამოიყენეთ — სურათები, ვიდეო, სარეზერვო ასლები, ლოგები, სტატიკური საიტები, მონაცემთა ტბები. S3 · Cloud Storage · Azure Blob
იქცევა როგორც ფიზიკური მყარი დისკი: დააფორმატებთ, დაამაუნთებთ, ბლოკებს კითხულობთ და წერთ. ერთდროულად ერთ ინსტანსზეა მიბმული. გამოიყენეთ — VM-ის ჩამტვირთავი დისკი, მონაცემთა ბაზები, ყველაფერი, რასაც დაბალშეყოვნებიანი შემთხვევითი ჩაწერა სჭირდება. EBS · Persistent Disk · Azure Disk
მართული ქსელური ფაილური სისტემა (NFS / SMB), რომელსაც ბევრი მანქანა ერთდროულად ამაუნთებს და ერთსა და იმავე დირექტორიების ხეს იზიარებს. გამოიყენეთ — საზიარო რესურსები, lift-and-shift აპლიკაციები, რომლებიც POSIX ბილიკს ელოდებიან, კონტენტის დირექტორიები. EFS · Filestore · Azure Files
ნაგულისხმევად აირჩიეთ ობიექტური საცავი — ის ყველაზე იაფია და უსაზღვროდ მასშტაბირდება. ბლოკურს მიმართეთ მხოლოდ მაშინ, როცა ერთ მანქანას დისკი სჭირდება (მონაცემთა ბაზა, ჩამტვირთავი ვოლუმი), ხოლო ფაილურს — მხოლოდ მაშინ, როცა რამდენიმე მანქანამ ერთი ფაილური სისტემა უნდა გაიზიაროს. საცავს ასევე აქვს დონეები: ცხელი ხშირი წვდომისთვის, ცივი/არქივი კი იშვიათად წასაკითხი მონაცემებისთვის — ძველი მონაცემების უფრო ცივ დონეზე გადატანა ანგარიშის შემცირების ერთ-ერთი უმარტივესი გზაა.
ღრუბლოვანი რესურსები რაღაც ფიზიკურ ადგილას ცხოვრობენ და ვირტუალური ქსელით საუბრობენ, რომელსაც თქვენ აკონტროლებთ. ოთხი იდეა თითქმის ყველაფერს ფარავს: რეგიონები და ხელმისაწვდომობის ზონები (გეოგრაფია), VPC (თქვენი კერძო ქსელი) და დატვირთვის ბალანსერი (ტრაფიკის მარეგულირებელი). დაბალი დონის ქსელური საფუძვლები აქ არის: ქსელები.
ერთი VPC, ორ ზონაზე გადაჭიმული. დატვირთვის ბალანსერი მოთხოვნებს ორივეზე ანაწილებს, ამიტომ მთელი დატა-ცენტრის დაკარგვა უბრალოდ სამიზნეების ნახევარს აკლებს.
იმუშავეთ ≥2 ზონაზე დატვირთვის ბალანსერის უკან და ერთი დატა-ცენტრის მწყობრიდან გამოსვლა უმნიშვნელო ამბავი გახდება. ეს ღრუბელში საიმედოობის ყველაზე იაფი მოგებაა.
გამოთვლა მომხმარებლებთან ყველაზე ახლო რეგიონში განათავსეთ. CDN სტატიკურ კონტენტს მსოფლიოს გარშემო edge-ლოკაციებზე აქეშირებს, რომ ის ახლოდან იტვირთოს.
ქსელები სწრაფად რთულდება. აღწერეთ ისინი კოდად Infrastructure as Code-ის საშუალებით, რომ განხილვადი და გამეორებადი იყოს.
ღრუბელში უსაფრთხოების ყველაზე მნიშვნელოვანი იდეა იმის ცოდნაა, სად მთავრდება პროვაიდერის საქმე და სად იწყება თქვენი. ეს ხაზი რომ არასწორად გაავლოთ, კარს ღიად ტოვებთ. ინსტრუმენტი, რომლითაც ყველაფერს კეტავთ, IAM-ია — და იქ წესი ერთ სიტყვაში ეტევა: მინიმალური პრივილეგია.
ზუსტი ხაზი სერვისის მიხედვით იძვრება — რაც უფრო მართულია (PaaS, SaaS), მით მეტი გადადის პროვაიდერზე — მაგრამ თქვენი მონაცემები და წვდომა ყოველთვის თქვენი დასაცავია.
მიეცით მინიმუმი და გააფართოვეთ მხოლოდ მაშინ, როცა რაღაც ნამდვილად ტყდება. დაიწყეთ აკრძალვიდან, და არა ყველაფრის დაშვებიდან.
დატვირთვებს მიეცით მოკლევადიანი როლის წვდომის მონაცემები და არა კოდში ჩაშენებული ხანგრძლივი გასაღებები.
მრავალფაქტორიანი ავთენტიფიკაცია ადამიანის ყოველ შესვლაზე; მონაცემები დაშიფრეთ როგორც შენახვისას, ისე გადაცემისას — ეს ხშირად ერთი ჩამრთველია.
წვდომის ლოგირება ადრევე ჩართეთ. ვერ გამოიძიებთ ინციდენტს, რომელიც არასოდეს ჩაგიწერიათ.
ღრუბლის ანგარიში გამოყენებაზეა მიბმული: გამოთვლაში იხდით წამობრივად, საცავში — გიგაბაიტ-თვეზე და — ეს ის ნაწილია, რომელიც ყველას ჩასაფრებული ხვდება — გამავალ ტრაფიკზე გიგაბაიტობით. გამოთვლის ყიდვის ოთხი გზისა და იმის ცოდნა, სად იმალება ფარული ხარჯები, ანგარიშს გონივრულ ფარგლებში ატოვებინებს.
ბაიტები უფასოდ შემოდის და ფასად გადის — აქ egress თავად სერვერს ჩრდილავს.
იხდით წამობრივად, ვალდებულების გარეშე, და ნებისმიერ დროს წყვეტთ. ნაგულისხმევი არჩევანი — შესანიშნავია არაპროგნოზირებადი ან ხანმოკლე დატვირთვებისთვის.
დაპირდით 1–3 წლის გამოყენებას მკვეთრი ფასდაკლების სანაცვლოდ (ხშირად 40–70%). საუკეთესოა თქვენი სტაბილური, მუდამ ჩართული ბაზისური დატვირთვისთვის.
იყიდეთ თავისუფალი სიმძლავრე ~90%-მდე ფასდაკლებით — მაგრამ პროვაიდერს მისი უკან წაღება რამდენიმეწუთიანი გაფრთხილებით შეუძლია. გამოდგება შეცდომებისადმი მდგრადი, ხელახლა გაშვებადი სამუშაოსთვის.
მცირე, სამუდამოდ უფასო ლიმიტი პლუს დროებითი კრედიტები. შესანიშნავია სასწავლად — მაგრამ დააყენეთ ბიუჯეტის გაფრთხილება, რომ შეცდომამ ზვავად არ იქცეს.
AWS, Google Cloud და Microsoft Azure ერთსა და იმავე საფუძვლებს გთავაზობენ სხვადასხვა სახელით. სამშენებლო ბლოკები, რომლებიც ახლახან ისწავლეთ, პირდაპირ გადადის — იცვლება მხოლოდ იარლიყები. აირჩიეთ ერთი და ჩაუღრმავდით; ადრეულ ეტაპზე multi-cloud-ის დევნა ჩვეულებრივ სირთულეს ყიდულობს და არა თავისუფლებას.
EC2 VM-ებისთვის · ECS / EKS კონტეინერებისთვის.
Compute Engine VM-ებისთვის · GKE კონტეინერებისთვის.
Virtual Machines · AKS კონტეინერებისთვის.
S3 (ობიექტური) · EBS (ბლოკური) · EFS (ფაილური).
Cloud Storage · Persistent Disk · Filestore.
Blob Storage · Managed Disks · Azure Files.
RDS / Aurora (SQL) · DynamoDB (NoSQL).
Cloud SQL / Spanner · Firestore (NoSQL).
Azure SQL · Cosmos DB (NoSQL).
Lambda (ფუნქციები) · Fargate (სერვერლეს კონტეინერები).
Cloud Functions · Cloud Run (კონტეინერები).
Azure Functions · Container Apps.
ხუთი სწრაფი კითხვა სერვისის მოდელებზე, გამოთვლაზე, საცავზე, უსაფრთხოებასა და ფასწარმოქმნაზე — მყისიერი პასუხი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში