Модуль 0.10: Що таке хмара?

Складність: [QUICK] - Концепції, що легко засвоюються

Час на проходження: 35 хвилин

Передумови: Модуль 0.8 - Сервери та SSH

Що ви зможете зробити

Після цього модуля ви зможете робити практичні порівняння інфраструктури замість того, щоб сприймати «хмару» як модне слово:

Пояснити хмарні обчислення як орендовані обчислювальні ресурси, сховища та мережеві потужності, а не як абстрактне місце, куди потрапляють дані.
Порівняти хмарні обчислення з локальною інфраструктурою (on-premises) та оцінити, які компроміси мають значення для нового робочого навантаження.
Зіставити сервіси обчислень, зберігання, мереж та баз даних із компонентами комп’ютера, які ви вже вивчили в Модулі 0.1.
Діагностувати, чому Kubernetes є корисним, коли застосунок має працювати на багатьох хмарних серверах, а не на одній машині, керованій вручну.

Чому це важливо

Гіпотетичний сценарій: у вашої невеликої команди в п’ятницю демо-версія, і застосунку потрібен сервер, місце для завантажених файлів, публічна URL-адреса та база даних, перш ніж клієнт зможе його спробувати. Якщо кожну частину ваша організація повинна купити, доставити, встановити, підключити, охолодити та оновити, демонстрація стає апаратним проєктом ще до того, як стане програмним. Якщо ті ж самі будівельні блоки можна орендувати у хмарного провайдера, команда може прийняти технічне рішення щодо потужностей сьогодні, спостерігати за реальним використанням завтра та змінити напрямок до того моменту, як прибуло б придбане обладнання.

«Хмара» — одна з найчастіше вживаних фраз у сучасних технологіях, але вона також є однією з найменш корисних, поки ви не пов’яжете її з фізичною реальністю. Немає ніякого туману, ніяких літаючих даних і ніякого магічного другого інтернету, де програмне забезпечення живе без машин. Хмарний сервіс підтримується звичайними комп’ютерами, дисками, кабелями, системами живлення, системами охолодження, будівлями, персоналом, контрактами та control planes; різниця полягає в тому, що ви орендуєте корисну частину цієї системи замість того, щоб володіти кожним рівнем самостійно.

Цей модуль важливий, оскільки Kubernetes зазвичай з’являється в історії після того, як у команди з’являється більше однієї машини для керування. Ви дізналися, що таке комп’ютер, як термінал надсилає команди, як працюють файли та скрипти, і як SSH досягає сервера через мережу. Хмарні обчислення — це міст від «я можу керувати однією віддаленою машиною» до «я можу мислити категоріями сотень або тисяч машин, які з’являються, зникають, виходять з ладу, масштабуються та коштують грошей, поки я за ними не стежу».

Зупиніться та подумайте: Перш ніж читати далі, напишіть пояснення хмари одним реченням своїми словами. Після проходження модуля порівняйте це речення з моделлю орендованих обчислень, сховищ, мереж та керованих сервісів і зверніть увагу на те, які частини стали більш конкретними.

Хмара — це орендована інфраструктура, а не погода

Поширений жарт стверджує, що хмара — це «просто чужий комп’ютер». Це легко запам’ятовується, оскільки розвіює таємничість, і це корисно, бо не дає вам ставитися до хмарних сервісів як до магії. Водночас цей жарт такий же неповний, як і називати готель «чужим ліжком». Ліжко справжнє, але готель також надає прибирання, замки, пожежну сигналізацію, сантехніку, системи реєстрації, програмне забезпечення для бронювання, персонал та бізнес-модель, яка дозволяє вам користуватися номером одну ніч без купівлі будівлі.

Хмарні обчислення працюють так само. Замість того, щоб купувати сервери, масиви зберігання даних, мережеві комутатори, резервне живлення, охолоджувальні установки, стійки, клітки та запасні частини, ви орендуєте корисну інфраструктуру у провайдера, який вже побудував ці рівні у величезних масштабах. Ви все ще вирішуєте, яка потужність вам потрібна, яким операційним системам або керованим сервісам ви довіряєте, які дані де мають знаходитись і які межі безпеки є важливими. Провайдер бере на себе значну частину рутинної роботи, яка в іншому випадку відволікала б вашу команду від застосунку, який ви намагаєтеся запустити.

Найважливішим прихованим інгредієнтом є control plane. Традиційна серверна кімната може вимагати створення заявки, людину з фізичним доступом та контрольний список, перш ніж щось зміниться. Хмарний провайдер надає доступ до інфраструктури через API, тому створення сервера, підключення сховища, додавання правила брандмауера або видалення тестового середовища можна автоматизувати та повторювати. Ось чому хмарні обчислення стали так тісно пов’язані з DevOps, інфраструктурою як кодом (Infrastructure as Code) та Kubernetes: як тільки інфраструктура стає програмованою, команди можуть ставитися до експлуатації як до проблеми проєктування, а не як до набору одноразових ручних завдань.

Аналогія з кухнею — це практичний спосіб чесно оцінити компроміси. Якщо ви володієте будівлею ресторану, ви контролюєте планування кухні, печі, електроживлення та кожне рішення щодо технічного обслуговування, але ви також несете початкові витрати та ризик помилитися з попитом. Якщо ви орендуєте комерційну кухню, ви відмовляєтеся від певної частки контролю, але можете розпочати швидше, користуватися спільними зручностями та платити відповідно до фактичного використання. Жоден із варіантів не є морально кращим; кожен вибір підходить для різних форматів бізнесу.

- Buy a building                        ($$$$$)
- Install commercial ovens, fridges     ($$$$$)
- Set up plumbing and electrical        ($$$$)
- Hire maintenance staff                ($$$)
- Fix things when they break            (ongoing cost)
- If you get MORE customers:
    Build an extension (takes months)
- If you get FEWER customers:
    You still pay for the empty kitchen

Перший варіант схожий на традиційну локальну інфраструктуру (on-premises), яку часто скорочують до «on-prem». Компанія купує або орендує фізичний простір, встановлює обладнання, підключає мережу та вибудовує внутрішні процеси для експлуатації машин. On-prem може бути правильним вибором, коли робочі навантаження є стабільними, вимоги до розміщення даних суворі, потрібне спеціалізоване обладнання або коли організація вже має персонал та потужності для належної роботи серверів. Це стає болючим, коли організації потрібна потужність швидко або коли попит занадто невизначений, щоб виправдати велику покупку.

Володіння інфраструктурою також змінює розмову про збої. Коли виходить з ладу джерело живлення, мережевий комутатор працює з помилками, диск заповнюється або система охолодження не справляється, організація повинна або усунути проблему самостійно, або заплатити фахівцю за це. Такий контроль може бути цінним, особливо в регульованих або спеціалізованих середовищах, але це означає, що планування потужностей стає довгостроковим зобов’язанням. Початківець не повинен сприймати «on-prem» як щось застаріле; сприймайте це як модель власності з сильним контролем та великою відповідальністю.

- Walk in and start cooking             (pay hourly)
- Ovens, fridges already there          (included)
- Plumbing, electrical already done     (included)
- Maintenance handled by the landlord   (included)
- If you get MORE customers:
    Rent a bigger kitchen (takes minutes)
- If you get FEWER customers:
    Downsize to a smaller kitchen, pay less

Цей другий варіант — це хмарна модель. Провайдер вже побудував центри обробки даних (data centers) та системи керування, тому ви запитуєте потужності через вебконсоль, API, інструмент командного рядка або робочий процес інфраструктури як коду. Привабливість полягає не лише в тому, що сервери містяться десь в іншому місці; привабливість полягає в тому, що провайдер перетворює інфраструктуру на те, що ви можете запитувати, вимірювати, змінювати в розмірі, автоматизувати та перестати за це платити, коли вам це більше не потрібно.

Оренда також змінює те, як команди навчаються. Студент, стартап або внутрішня команда платформи може створити невелике середовище, протестувати ідею, зібрати дані та видалити середовище, перш ніж переходити до більшого проєкту. Цей короткий цикл зворотного зв’язку є однією з причин, чому хмарні платформи поширені в сучасній інженерній освіті. Ризик полягає в тому, що швидкість може приховувати слабке мислення, тому відповідальні команди поєднують швидке розгортання з угодами про іменування (naming conventions), межами облікових записів, перевірками доступу та письмовими очікуваннями щодо очищення.

Зупиніться та подумайте: Якщо тестове середовище використовується лише в робочі години, яка модель дозволяє легше припинити платити вночі за потужності, що простоюють, і яку операційну звичку потрібно виробити команді, щоб економія дійсно відбулася?

Будувати чи орендувати: операційні компроміси

Хмара існує, оскільки купівля інфраструктури має три вперті проблеми: це повільно, це дорого ще до того, як ви дізнаєтеся, чи буде проєкт успішним, і це змушує вас вгадувати потужність заздалегідь. Ці проблеми мають значення навіть для роботи початкового рівня. Для особистого вебсайту може знадобитися лише невеликий сервер, але той самий шаблон прийняття рішень виникає у професійних системах, які обслуговують клієнтів, обробляють дані, розміщують внутрішні інструменти або підтримують запуск продукту.

Перша проблема — це час очікування (lead time). Фізичні сервери не створюються командою; хтось повинен затвердити бюджет, замовити обладнання, дочекатися доставки, встановити машини в стійку, підключити кабелі, встановити операційні системи, налаштувати мережу, застосувати оновлення та підключити моніторинг. Великі організації можуть оптимізувати це, але закони фізики та процес закупівель все одно спричиняють затримки. Хмарні провайдери зменшують цю затримку, тримаючи об’єднані потужності напоготові та надаючи доступ до них через програмні інтерфейси.

Company: "We need 10 servers for our new project."
IT department: "OK. We need to:
  - Get budget approval (2 weeks)
  - Order the hardware (4 weeks)
  - Ship it to our data center (1 week)
  - Rack and cable it (3 days)
  - Install the OS (1 day)
  - Configure networking (2 days)
  Total: about 2 months."

Company: "But we need to launch next week..."

Контраст полягає не в тому, що хмарні провайдери ігнорують інженерію. Вони виконали інженерні роботи раніше, в масштабі, а потім обгорнули результат у control plane, що дозволяє клієнтам запитувати його частину. Цей control plane є причиною того, чому хмарна інфраструктура відчувається інакше, ніж віддалений доступ до одного сервера. Ви не просите одну машину виконувати більше роботи; ви просите платформу виділяти машини, диски, IP-адреси, правила брандмауера, ідентифікатори та пов’язані з ними сервіси за запитом.

Engineer: "We need 10 servers."
*types a command*
Cloud: "Here are your 10 servers. They're ready now."
Time elapsed: about 2 minutes.

Друга проблема — це вгадування потужностей. Якщо ви купите занадто мало обладнання, успішний запуск перетвориться на збій (outage), оскільки сайт не зможе впоратися з попитом. Якщо ви купите занадто багато обладнання, капітал простоюватиме, тоді як фінансовий відділ все одно рахуватиме його як реальні витрати. Хмарні потужності не усувають планування, але вони змінюють ціну помилки, оскільки ви можете почати з малого, виміряти, змінити розмір і автоматизувати масштабування на основі реальних сигналів, а не припущень, зроблених місяці тому.

Гіпотетичний сценарій: невелика гра запускається зі скромними оцінками аудиторії, а потім у суботу популярний стример несподівано показує її. Команда, прив’язана до фіксованої локальної (on-premises) потужності, може не мати швидкого способу додати машини, тому гравці стикаються з помилками, поки команда чекає на закупівлю або пробує ризиковані екстрені зміни. Команда, що використовує хмарні потужності, все ще має вирішувати питання обмежень застосунку, але зазвичай вона може додати обчислення, пропускну здатність сховища або пропускну здатність мережі швидше, ніж змогла б придбати нове фізичне обладнання.

Третя проблема — технічне обслуговування. Сервери потребують живлення, охолодження, фізичної безпеки, резервування мережі, запасних частин, оновлень мікропрограм, виправлень операційної системи (patching), планування резервних копій та процедур на випадок збоїв. Хмара не змушує ці обов’язки зникнути; вона перекладає багато з них на провайдера і залишає вам інший набір обов’язків. Ви все ще відповідаєте за проєктування застосунку, налаштування ідентифікації, вибір методів захисту даних, політики доступу, контроль витрат і рішення щодо розумного використання керованих сервісів.

Хмарні команди часто описують це як модель спільної відповідальності (shared responsibility model). Провайдер несе відповідальність за безпеку та надійність хмари (of the cloud): об’єкти, фізичні хости (hosts), базова мережа та фундаментальні сервіси. Ви несете відповідальність за безпеку та надійність у хмарі (in the cloud): облікові записи, дозволи, доступність з мережі (network exposure), класифікація даних, резервні копії, конфігурація застосунку та те, як ви комбінуєте сервіси. Пам’ятаючи про цю відмінність, ви уникнете типової помилки початківців: припущення, що орендована інфраструктура означає, що хтось інший також правильно експлуатує ваш застосунок.

Ідея спільної відповідальності також пояснює, чому хмарні навички — це більше, ніж просто натискання кнопок у консолі. Якщо бакет (bucket) сховища є публічним, тоді як він має бути приватним, це не обов’язково є провиною провайдера; можливо, клієнт неправильно налаштував доступ. Якщо база даних не має придатної до використання резервної копії, керований сервіс все ще може працювати точно так, як налаштовано. Хмарна грамотність означає запитувати, де є кожна зона відповідальності, як ви доведете, що з нею впоралися, і які докази попередять вас до того, як помилка стане збоєм або витоком даних (exposure).

Це також є причиною того, чому на хмарних діаграмах зазвичай зображують межі. Одна межа відділяє об’єкти провайдера від облікових записів клієнта. Інша межа відділяє публічний трафік від приватних сервісів. Третя межа відділяє користувачів-людей від автоматизованих сервісних ідентифікаторів (service identities). Вам ще не потрібно досконало володіти цими діаграмами, але ви повинні почати помічати питання, на які вони відповідають. Де входить трафік, де зберігаються дані, хто може змінити систему, і яка частина все одно буде проблемою вашої команди під час інциденту?

Велика трійка провайдерів та послуги, які вони продають

На ринку публічних хмар домінують три основні провайдери: Amazon Web Services, Microsoft Azure та Google Cloud. Рейтинги частки ринку з часом змінюються, а точні відсотки відрізняються залежно від методології аналітиків, але AWS, Azure та Google Cloud стабільно залишаються найбільшими платформами публічних хмар у нещодавніх галузевих звітах. Вам не потрібно обирати одну з них сьогодні, і вам не потрібно запам’ятовувати кожну назву продукту; на цьому етапі мета полягає в тому, щоб усвідомити, що ті самі базові категорії зустрічаються у різних провайдерів під різними назвами.

AWS запустив свої перші послуги публічної хмари у 2006 році і став орієнтиром для багатьох хмарних концепцій, які інженери використовують і досі. Він має широкий каталог, велику екосистему та довгу історію роботи зі стартапами й підприємствами. Спочатку назви його продуктів можуть здаватися дивними, але багато з них чітко відповідають концепціям, які ви вже знаєте: EC2 означає віртуальні сервери, S3 — об’єктне сховище, VPC — приватні мережі, а RDS — керовані реляційні бази даних.

- The first major cloud provider (launched 2006)
- AWS is generally the largest public cloud by revenue, with Microsoft Azure and Google Cloud the other two leaders
- The "original" -- many companies' first cloud platform
- Kitchen analogy: The biggest chain, the one everyone knows

Microsoft Azure з’явився пізніше, але став особливо важливим для організацій, які вже інвестували в систему ідентифікації Microsoft, Windows Server, SQL Server, Office та корпоративні контракти. Це не означає, що Azure призначений лише для робочих навантажень Microsoft, але пояснює, чому багато компаній природно розглядають його, коли вони вже використовують інструменти Microsoft у своєму бізнесі. В аналогії з кухнею, Azure — це мережа комерційних кухонь, яка може інтегруватися з великою кількістю обладнання, що вже є у власності компанії.

- Launched 2010
- Commonly ranked among the top cloud providers
- Popular with companies already using Microsoft products
- Kitchen analogy: The chain that integrates with your existing equipment

Google Cloud відображає досвід Google у сфері великомасштабної інфраструктури, систем обробки даних та машинного навчання. Він також має історичне значення для Kubernetes, оскільки Kubernetes виріс із досвіду Google щодо внутрішнього запуску контейнеризованих робочих навантажень. Ця історія походження має значення, оскільки Kubernetes — це не випадковий інструмент, прикручений до хмарного світу; це відповідь на операційну проблему планування, масштабування та відновлення застосунків на багатьох машинах.

- Launched 2008 (public in 2011)
- Commonly ranked among the top cloud providers
- Known for data analytics and machine learning
- Fun fact: Kubernetes was INVENTED at Google
- Kitchen analogy: The chain with the fanciest kitchen technology

Менші провайдери також мають значення. DigitalOcean, Linode у складі Akamai, Hetzner, OVHcloud та регіональні провайдери можуть бути дешевшими, простішими, ближчими до конкретних користувачів або краще відповідати потребам команди. Пастка для початківців полягає в тому, щоб ставитися до вибору провайдера як до приналежності до бренду, а не як до інженерного рішення. Спочатку вивчіть категорії, а потім оцінюйте провайдера на основі форми робочого навантаження, бюджету, вимог до комплаєнсу, операційних навичок, моделі підтримки та послуг, якими ваша команда може відповідально керувати.

Портативність тут заслуговує на ретельне та реалістичне визначення. Базові концепції переносяться добре: обчислення виконують код, сховище зберігає дані, мережа з’єднує системи, ідентифікація контролює доступ, а спостережуваність повідомляє вам, що відбувається. Конкретні послуги не завжди переносяться без проблем, оскільки кожен провайдер має власні API, обмеження, моделі ціноутворення, функції керованих баз даних, поведінку балансувальників навантаження та структури облікових записів. Kubernetes може зменшити деякі відмінності при розгортанні застосунків, але він не усуває хмаро-специфічні рішення щодо мережі, сховища, ідентифікації або виставлення рахунків.

Мислення, незалежне від провайдера, все ж варто практикувати, оскільки воно не дає вашій ментальній моделі перетворитися на каталог продуктів. Коли ви бачите назву нової послуги, запитайте, яку роботу вона виконує, перш ніж питати, чи вона вражає. Вона виконує код, зберігає дані, з’єднує системи, захищає доступ, спостерігає за поведінкою чи автоматизує операції? Ця звичка дозволяє вам глибоко вивчити одного провайдера, не стаючи безпорадними перед документацією іншого. Вона також готує вас до читання документації Kubernetes, де така сама дисципліна зіставлення назв з обов’язками є надзвичайно важливою.

Зупиніться та подумайте: Якщо підприємство вже активно використовує систему ідентифікації Microsoft, адміністрування Windows та служби Office, якого провайдера, ймовірно, оцінять у першу чергу, і що ще потрібно буде перевірити перед прийняттям рішення?

Зіставлення хмарних сервісів з комп’ютерними компонентами

Найкращий спосіб демістифікувати хмарні сервіси — це зіставити їх зі звичайними комп’ютерними компонентами, які ви вже розумієте. Віртуальна машина — це все ще комп’ютер з точки зору програмного забезпечення: вона має потужність процесора (CPU), пам’ять, сховище, мережевий інтерфейс, операційну систему та процеси. Об’єктне сховище — це все ще місце для зберігання байтів, але воно оптимізоване для файлів та об’єктів, доступ до яких здійснюється через API, а не для локальної файлової системи, змонтованої в одному ноутбуці.

Обчислення (Compute) — це категорія хмари для виконання коду на орендованих обчислювальних потужностях. Коли ви створюєте віртуальну машину (VM) або інстанс, ви обираєте розмір, який представляє комбінацію процесора, пам’яті, мережевих можливостей, а іноді й спеціалізованого обладнання, такого як графічні процесори (GPU). Ви можете встановлювати на ній програмне забезпечення, підключатися до неї через SSH, запускати веб-сервер або підключати її до автоматизації. Компроміс полягає в тому, що ви все одно керуєте значною частиною машини, якщо тільки не оберете більш керований обчислювальний сервіс.

"I need a computer that runs 24/7."

Cloud service: Virtual Machine (VM) / Instance
  - AWS calls it: EC2 (Elastic Compute Cloud)
  - Azure calls it: Virtual Machines
  - GCP calls it: Compute Engine

Kitchen analogy: Renting a cooking station.
  You choose the size (small burner or industrial oven)
  and pay by the hour.

Сховище (Storage) — це категорія хмари для збереження даних після зупинки процесу. Об’єктне сховище є поширеним для зображень, резервних копій, журналів (логів), ресурсів статичних веб-сайтів, експортів та великих файлів, оскільки воно є надійним, керованим через API та відокремленим від будь-якого окремого сервера. Блокове та файлове сховища також існують, але об’єктне сховище є найпростішою ментальною моделлю для початківців: ви розміщуєте іменовані об’єкти в кошик (bucket) або контейнер, встановлюєте правила доступу та платите за збережені дані плюс операції та передачу.

"I need to store files, images, backups."

Cloud service: Object Storage
  - AWS calls it: S3 (Simple Storage Service)
  - Azure calls it: Blob Storage
  - GCP calls it: Cloud Storage

Kitchen analogy: Renting pantry shelves.
  You pay per shelf used, per month.

Мережі (Networking) — це категорія хмари для безпечного з’єднання ресурсів. Віртуальна мережа дозволяє вам вирішувати, які машини можуть спілкуватися приватно, який трафік може надходити з інтернету, які порти є відкритими та куди балансувальники навантаження спрямовують запити. Термінологія відрізняється, але концепція знайома з попередніх модулів: комп’ютерам потрібні адреси, маршрути та правила, щоб трафік досягав потрібного сервісу без відкриття всього для всіх.

"My servers need to talk to each other and to the internet."

Cloud service: Virtual Networks, Load Balancers
  - AWS calls it: VPC (Virtual Private Cloud)
  - Azure calls it: Virtual Network
  - GCP calls it: VPC

Kitchen analogy: Renting the delivery drivers and route planning.
  Your kitchens need roads between them and routes to customers.

Бази даних — це те, де хмара починає демонструвати більш тонку перевагу. Ви можете самостійно запустити базу даних на віртуальній машині, але багато команд віддають перевагу керованим базам даних, оскільки резервне копіювання, встановлення патчів, реплікація, хуки для моніторингу та поведінка при збоях частково обробляються провайдером. “Керований” не означає відсутність рішень; ви все одно обираєте розміри, версії, схеми, засоби контролю доступу, вікна для резервного копіювання, терміни зберігання та межі витрат. Це просто означає, що ви орендуєте експлуатовану систему бази даних, а не збираєте кожну операційну деталь самостійно.

"I need to store and query structured data."

Cloud service: Managed Databases
  - AWS calls it: RDS (Relational Database Service)
  - Azure calls it: Azure SQL Database
  - GCP calls it: Cloud SQL

Kitchen analogy: A managed filing system for all your recipes,
  orders, and inventory. Someone else maintains the filing cabinets.

Перш ніж рухатися далі, перевірте це зіставлення замість того, щоб запам’ятовувати назви продуктів. AWS S3 найтісніше відповідає сховищу, оскільки він зберігає такі об’єкти, як файли та резервні копії. GCP Compute Engine відповідає обчисленням, оскільки він надає вам віртуальні машини з процесором (CPU) та оперативною пам’яттю (RAM). Azure Virtual Network відповідає мережам, оскільки він визначає межі зв’язку та маршрути. Якщо ви можете виконати це зіставлення, ви зможете вивчати нові хмарні сервіси, не будучи перевантаженими брендингом.

Є ще одна категорія, з якою початківці часто зустрічаються на ранніх етапах: управління ідентифікацією та доступом (IAM). Вона не зіставляється чітко з окремою деталлю ноутбука, оскільки відповідає на інше запитання: кому або чому дозволено виконувати яку дію? У хмарі кожній людині, скрипту автоматизації, віртуальній машині, керованому сервісу та компоненту Kubernetes можуть знадобитися дозволи. Ставтеся до ідентифікації як до системи замків і ключів для орендованої будівлі. Потужний сервер із недбалими дозволами — це не сильна архітектура; це дорогий спосіб створити ризик.

Спостережуваність (Observability) — це ще одна допоміжна категорія, яка стає важливою, щойно в системи з’являються користувачі. Журнали (логи) повідомляють вам, про що звітувало програмне забезпечення, метрики показують, як система поводилася з плином часу, трасування можуть показати шлях одного запиту через кілька сервісів, а сповіщення (алерти) кажуть людям, коли потрібна увага. Ці інструменти не замінюють обчислення, сховище або мережі, але вони роблять ці ресурси придатними для експлуатації. Хмарна система, за якою ви не можете спостерігати, схожа на орендовану кухню без термометрів, чеків або записів про перевірки.

Оплата за фактом використання змінює бюджет та характер збоїв

Ціноутворення у хмарі часто базується на використанні, що означає, що ви можете платити за потужності під час їх використання замість того, щоб купувати максимально очікувану потужність наперед. Це є потужним інструментом, оскільки робить експерименти дешевшими, а масштабування швидшим, але водночас створює новий операційний ризик. Залишений увімкненим сервер, великий диск, який зберегли після тестування, система логування з неконтрольованим обсягом або схема передачі даних, якої ніхто не помітив, — усе це може перетворитися на реальні рахунки.

Example:
  A small server costs about $0.01/hour on AWS
  Running it 24/7 for a month: $0.01 x 24 x 30 = $7.20

  Need it only 8 hours a day for testing?
  $0.01 x 8 x 22 workdays = $1.76/month

  Need 100 servers for 2 hours for a big processing job?
  $0.01 x 100 x 2 = $2.00

Цифри у цьому прикладі навмисно спрощені, це не цінова пропозиція. Реальне ціноутворення залежить від регіону, сімейства інстансів, операційної системи, моделі зобов’язань, типу сховища, передачі даних, податків, знижок та змін з боку провайдера. Урок полягає у формі прийняття рішення: змінний попит добре підходить для орендованих потужностей, оскільки ви можете вмикати ресурси, змінювати їхній розмір або зупиняти їх, коли роботу виконано. Стабільний попит все ще може сприяти використанню власної інфраструктури або хмарних знижок за умови довгострокових зобов’язань, якщо робоче навантаження є достатньо передбачуваним.

Гіпотетичний сценарій: ваша команда створює середовище для тестування продуктивності з багатьма серверами для двогодинного бенчмарку, а потім забуває видалити його перед вихідними. Хмара зробила бенчмарк легким, оскільки потужності з’явилися швидко, але та сама легкість зробила помилку дорогою, оскільки ресурси продовжували працювати, тоді як ніхто не готував на кухні. Контроль витрат, бюджети, теги, процедури очищення, сповіщення та мітки власності — це не паперова робота; це частина відповідальної експлуатації хмарних систем.

Мислення щодо витрат у хмарі — це також підготовка до роботи з Kubernetes. Kubernetes може запитувати більше потужностей, запускати кілька копій застосунку, підключати сховище, відкривати доступ до сервісів та переміщувати робочі навантаження після збоїв. Такі дії є корисними, але за кожною автоматизованою дією стоїть фактор вартості. Досвідчений оператор вчиться ставити як питання надійності, так і питання бюджету: скільки копій нам потрібно, де вони працюють, що відбувається, коли попит різко зростає, і що сигналізує нам про необхідність зменшення масштабу?

Видимість витрат — це технічна практика, а не лише бухгалтерська. Інженери впливають на вартість, коли обирають розміри інстансів, обсяг логування, класи сховища, шляхи передачі даних, поведінку повторних спроб (retries) та пороги масштабування. Фінансовий відділ може отримувати рахунок, але рахунок створює архітектура. У здорових хмарних командах дашборди витрат, теги ресурсів, бюджети та перевірки очищення є частиною того самого робочого ритму, що й моніторинг та розгляд інцидентів, оскільки всі вони описують, чи поводиться система так, як передбачалося.

Корисна звичка для початківців — запитувати, що має відбуватися, коли ресурсом ніхто не користується. Продакшн-база даних може потребувати постійної доступності, але тренувальна віртуальна машина, тимчасовий тест навантаження, середовище попереднього перегляду або одноразовий кошик (bucket) для зберігання — ймовірно, ні. Хмарні платформи дозволяють легко створювати ці ресурси, тому правило очищення має бути розроблене ще до того, як середовище з’явиться. Ця звичка матиме значення пізніше, коли Kubernetes буде створювати ресурси опосередковано, оскільки видалення об’єкта застосунку може призвести, а може й не призвести до видалення кожного хмарного ресурсу, прикріпленого до нього.

Зупиніться та подумайте: Ваш новий застосунок отримує в десять разів більше трафіку у вихідні, ніж у будні. Які ресурси ви б розглянули для збільшення масштабу на вихідні, які залишили б стабільними, і який сигнал підказав би вам, що можна безпечно зменшити масштаб?

Де місце Kubernetes

Kubernetes перебуває наприкінці цього шляху для початківців, оскільки він керує складністю, яка з’являється, коли одного сервера стає недостатньо. Один сервер може запускати невеликий застосунок, але професійні системи часто потребують кількох копій для надійності, додаткових потужностей під час пікових навантажень, поступових оновлень без простоїв та відновлення у разі збою машин. Люди можуть керувати частиною цього вручну певний час, але ручне розміщення стає крихким, коли кількість сервісів і серверів зростає.

Module 0.1: You learned about one computer (one kitchen)
Module 0.3: You learned to give commands to that kitchen
Module 0.5: You learned to write instructions (recipes/scripts)
Module 0.8: You learned to connect to remote kitchens (servers and SSH)
Module 0.9: You learned to install software and manage packages on those kitchens
Module 0.10: You learned that the cloud has THOUSANDS of kitchens for rent

NOW: Kubernetes is the system that manages all of those kitchens.

Kubernetes, який часто записують як K8s, оскільки між літерами K та s є вісім літер, був створений на основі досвіду Google з експлуатації великих парків контейнеризованих робочих навантажень, і зараз є незалежним від постачальників проєктом з відкритим вихідним кодом під егідою Cloud Native Computing Foundation. Його завдання — не замінити хмарних провайдерів. Його завдання — надати вам декларативну систему керування для запуску застосунків на доступних машинах, незалежно від того, чи ці машини надані AWS, Azure, Google Cloud, іншим провайдером чи вашим власним дата-центром.

Без Kubernetes інженер може обрати конкретний сервер і розмістити там застосунок вручну. Це може працювати, поки система крихітна, але операційне навантаження швидко зростає. Інженер повинен помічати збої, вирішувати, де перезапустити застосунок, переконуватися, що новий сервер має достатньо потужностей, оновлювати маршрутизацію та уникати поломки інших застосунків. Проблема не в тому, що інженери неуважні; проблема в тому, що люди — погані планувальники для інфраструктури, яка постійно змінюється.

Engineer: "Deploy the app to server-42."
*server-42 crashes at 3 AM*
Engineer's phone: *RING RING*
Engineer: "Ugh... let me move it to server-43 manually."

З Kubernetes інженер описує бажаний стан: наприклад, підтримувати роботу трьох копій цього застосунку. Kubernetes спостерігає за фактичним станом і вживає заходів, коли фактичний стан відхиляється від бажаного. Якщо один сервер виходить з ладу, кластер може розмістити копію на заміну деінде, залежно від доступних потужностей та політик. Важливе ментальне зрушення полягає в тому, що ви припиняєте мислити лише командами до окремих машин і починаєте мислити деклараціями до системи, яка узгоджує реальність.

Engineer: "I need 3 copies of this app running."
Kubernetes: "Done. Running on server-42, server-67, and server-91."
*server-42 crashes at 3 AM*
Kubernetes: "Server-42 is down. Moving that copy to server-15. Done."
Engineer: *sleeping peacefully*

Ось чому концепції хмари мають значення перед концепціями Kubernetes. Якщо ви не розумієте орендованих обчислювальних ресурсів, сховищ, мереж та потужностей з оплатою за фактом використання, Kubernetes може здатися купою дивних об’єктів та команд. Якщо ви розумієте хмарну модель, Kubernetes стає простіше позиціювати: це менеджер ресторану, який координує багато кухонь, а не сама будівля кухні. Він вирішує, де має виконуватися робота, стежить за збоями та допомагає командам експлуатувати застосунки в таких масштабах, де ручне розміщення є надто повільним.

Керовані сервіси Kubernetes роблять цей взаємозв’язок ще зрозумілішим. Провайдери можуть керувати частинами площини управління Kubernetes замість вас, тоді як ви все одно вирішуєте, які робочі навантаження розгортати, які дозволи надавати, який рівень мережевої доступності є прийнятним і скільки потужностей потребує кластер. Цей поділ відповідає тій самій моделі спільної відповідальності, яку ви вже бачили. Керований кластер зменшує частину операційної роботи, але він не приймає архітектурних, безпекових чи фінансових рішень від імені вашої команди.

Kubernetes також демонструє, чому абстракція є корисною, але ніколи не буває безкоштовною. Deployment може описувати три копії застосунку, не називаючи точних машин, що набагато простіше, ніж вибирати сервери вручну. Під цією абстракцією все ще існують реальні процесори, пам’ять, диски, мережеві маршрути, балансувальники навантаження та облікові дані. Коли щось ламається, оператори часто переміщуються між рівнями: вони перевіряють об’єкт Kubernetes, потім вузол, потім хмарний ресурс, а потім журнали застосунку. Хмарна ментальна модель допомагає вам не загубитися під час цього переміщення.

Ви також досягли тієї точки, де шлях «З нуля до термінала» перетворюється на роботу з хмарними технологіями. Наступні модулі познайомлять вас із контейнерами, основами Docker, базовими концепціями Kubernetes і, зрештою, з навичками, орієнтованими на сертифікацію. Ці теми додадуть нові команди та об’єкти, але фундамент залишається незмінним: програмне забезпечення працює на комп’ютерах, комп’ютери потребують сховищ і мереж, а надійні системи вимагають продуманих операційних моделей.

Zero to Terminal (YOU ARE HERE -- almost done!)
  ✓ Understand computers
  ✓ Use the terminal
  ✓ Edit files
  ✓ Understand servers and SSH
  ✓ Understand cloud computing
  → Capstone next: Module 0.11 (Your First Server)

        ↓

Cloud Native 101 (after Zero to Terminal)
  → What are containers?
  → Docker fundamentals
  → What is Kubernetes?
  → The cloud-native ecosystem

        ↓

Kubernetes Basics
  → Your first cluster
  → kubectl basics
  → Pods, Deployments, Services

        ↓

CKA Certification Track
  → Certified Kubernetes Administrator
  → Your first professional credential

        ↓

Platform Engineering
  → SRE, GitOps, DevSecOps, MLOps
  → Building platforms that other developers use

Коли це не застосовується

Хмарні обчислення не є автоматично найкращою відповіддю для кожного робочого навантаження. Якщо робоче навантаження має вкрай стабільний попит, суворі вимоги до фізичного контролю, особливі апаратні обмеження, незвичні умови ліцензування або команду, яка вже керує ефективними дата-центрами, локальна інфраструктура може бути раціональним вибором. Питання не в гаслі «хмара чи не хмара»; питання в тому, яка модель дає організації достатньо швидкості, контролю, надійності, відповідності вимогам та передбачуваності витрат для виконання поставленої роботи.

Така ж обережність застосовується і всередині хмари. Віртуальна машина може бути кращою за керовану платформу, коли команді потрібен низькорівневий контроль, тоді як керований сервіс може бути кращим, коли команда хоче, щоб провайдер займався рутинними операціями. Об’єктне сховище може бути чудовим для завантажених файлів та резервних копій, але воно не є заміною реляційній базі даних, коли застосунок потребує структурованих транзакцій. Хороша інженерія часто полягає не стільки в пошуку наймоднішого сервісу, скільки у відповідності межі сервісу до межі проблеми.

Корисним патерном є запуск невизначених робочих навантажень у хмарі, оскільки орендовані потужності знижують вартість навчання. Ранні прототипи, навчальні середовища, тимчасові тестові системи, імпульсивні завдання з обробки даних та застосунки з невідомим попитом зазвичай отримують вигоду від швидкого надання ресурсів та легкого згортання. Міркування щодо масштабування — це дисципліна: коли експерименти стають постійними, команда повинна додати теги власності, бюджети, моніторинг, резервні копії та огляди архітектури, щоб дешевий експеримент не перетворився на некеровану виробничу систему.

Інший патерн — використання керованих сервісів, коли операційна діяльність не є тим, що вирізняє ваш продукт. Якщо ваша цінність походить від застосунку, а не від ручної підтримки реплік бази даних, керована база даних може бути кращим шляхом для навчання і кращим бізнес-рішенням. Компромісом є залежність від поведінки провайдера, ціноутворення, лімітів та функцій. Хороші команди роблять цю залежність видимою, документують, чому вона є прийнятною, і уникають ілюзій, що керований сервіс завжди означає портативність.

Головний антипатерн — це впровадження хмари через хайп. Команди іноді переносять робочі навантаження, оскільки провайдер є популярним, виступ на конференції прозвучав переконливо, або конкурент оголосив про міграцію. Це пропускає інженерну роботу. Кращою альтернативою є опис профілю робочого навантаження, потреб у даних, стійкості до збоїв, очікуваного трафіку, питань відповідності вимогам, навичок команди та моделі витрат перед вибором платформи. Хмара — це інструмент, а не знак зрілості.

Іншим антипатерном є ставлення до першого робочого налаштування як до остаточної архітектури. Хмарні платформи дозволяють легко створити сервер, відкрити порт, підключити сховище та оголосити про перемогу. Це чудово для навчання, але продакшен вимагає другого підходу: прибрати публічний доступ, який не потрібен, задокументувати власність, додати резервне копіювання, налаштувати моніторинг, протестувати відновлення та зробити витрати прозорими. Версія цієї звички для початківців є простою: щоразу, коли ви створюєте ресурс, запитуйте, хто ним володіє, скільки він коштує, з якими даними він працює та як він буде видалений.

Коли ви б використовували це замість альтернатив

Використовуйте хмарні обчислення, коли вам швидко потрібні потужності, коли попит може змінитися, коли експерименти мають бути дешевими для запуску та зупинки, або коли керовані сервіси знімають роботу, на якій ваша команда не намагається спеціалізуватися. Використовуйте локальну інфраструктуру, коли довготривалий передбачуваний попит, фізичний контроль, спеціалізоване обладнання, наявні приміщення або нормативні обмеження роблять володіння більш доцільним. Використовуйте гібридну модель, коли організація має реальні причини тримати деякі системи поруч, водночас використовуючи хмарні потужності для пікових навантажень, розробки, аналітики або новіших платформ застосунків.

Вибираючи між провайдерами, починайте з категорій сервісів, а не з назв брендів. Запитайте, де виконується код застосунку, де зберігаються довготривалі дані, як користувачі отримують до них доступ, як оператори проходять автентифікацію, як працює резервне копіювання, як відстежуються витрати та що відбувається під час збою. Потім порівняйте провайдерів за деталями, які впливають на ці питання. Правильною відповіддю для вправи початківця часто є той провайдер, який має найзрозумілішу документацію щодо безкоштовного рівня та найнижчий ризик для навчання; правильна відповідь для компанії включає контракти, відповідність вимогам, підтримку, кадрове забезпечення, інтеграцію та стратегію виходу.

Простий фреймворк для прийняття рішень полягає у відокремленні оборотних рішень від «липких» (невідворотних). Створення тимчасової віртуальної машини для лабораторної роботи зазвичай є оборотним рішенням, оскільки ви можете видалити її та спробувати іншого провайдера пізніше. Вибір пропрієтарної функції бази даних, вбудовування специфічних для провайдера сервісів подій по всьому застосунку або побудова мережі навколо складної структури акаунтів є більш «липкими» рішеннями, оскільки пізніша міграція зачепить код, дані, операції та людей. Оборотні рішення — це хороше місце для швидкого навчання; «липкі» рішення заслуговують на повільніший розгляд та чіткішу документацію.

Чи знали ви?

AWS запустив свої перші загальнодоступні інфраструктурні сервіси у 2006 році, саме тому багато хмарних термінів та ментальних моделей досі використовують приклади AWS, навіть коли така ж ідея існує деінде.
Національний інститут стандартів і технологій (NIST) опублікував Спеціальну публікацію 800-145 у 2011 році, і його визначення хмарних обчислень досі лежить в основі багатьох формальних дискусій про самообслуговування на вимогу, широкий мережевий доступ, об’єднання ресурсів у пули, швидку еластичність та вимірюваний сервіс.
Kubernetes у перекладі з грецької означає «керманич», що добре пасує до логотипа у вигляді штурвала та ідеї керування багатьма контейнерами у парку машин.
Kubernetes версії 1.35 є цільовою для цієї навчальної програми, тому пізніші модулі з Kubernetes використовуватимуть актуальну поведінку команд, а не приклади, заморожені на старіших випусках кластерів.

Типові помилки

Помилка	Чому це трапляється	Як це виправити
Ставлення до хмари як до магії, а не як до фізичної інфраструктури	Інтерфейсом є програмне забезпечення, тому початківці забувають, що під ним містяться реальні машини, диски, мережі, живлення та охолодження	Продовжуйте зіставляти кожен сервіс із обчисленнями, зберіганням, мережею, даними або операційними обов’язками
Припущення, що хмара завжди дешевша	Оплата за фактом використання звучить недорого, але стабільні робочі навантаження та забуті ресурси можуть коштувати більше, ніж очікувалося	Порівняйте профіль робочого навантаження, встановіть бюджети, вимикайте тимчасові системи та переглядайте витрати як частину звичайних операцій
Вибір провайдера лише через його популярність	Впізнаваність бренду може приховувати невідповідність навичок команди, потреб у дотриманні вимог, регіонів, підтримки або лімітів сервісів	Оцініть AWS, Azure, Google Cloud та альтернативи відповідно до реального робочого навантаження та обмежень організації
Спроба вивчити всі сервіси відразу	Великі провайдери пропонують сотні сервісів, і їхній каталог може перевантажити базову ментальну модель	Почніть з обчислень, зберігання, мережі, управління ідентичністю та одного варіанту бази даних, а потім додавайте сервіси, коли вони знадобляться в реальному дизайні
Забування про спільну відповідальність	Орендована інфраструктура може здаватися повністю керованою, тому команди можуть ігнорувати контроль доступу, резервне копіювання, моніторинг або рішення щодо патчів	Чітко розділяйте те, чим керує провайдер, і те, що ваша команда налаштовує, чим володіє, що тестує та перевіряє
Ігнорування прив’язки до постачальника, поки міграція не стане болючою	Керовані сервіси зручні, але глибокі дизайнерські рішення, специфічні для провайдера, можуть зробити пізніші переходи дорогими	Свідомо вирішуйте, де прив’язка того варта, віддавайте перевагу відкритим інтерфейсам, коли важлива портативність, і документуйте цей компроміс
Масштабування без сигналу про витрати	Автоматизація може додавати потужності швидше, ніж люди помітять рахунок	Поєднуйте правила масштабування з бюд budgets, сповіщеннями, завданнями очищення, тегами власності та регулярним переглядом невикористаних ресурсів

Контрольні запитання

1. Вашій команді потрібен сервер для демонстрації клієнту цього тижня, але купівля обладнання займе тижні. Як би ви пояснили, чому хмарні обчислення є дієвою альтернативою?

Хмарні обчислення є дієвою альтернативою, оскільки вони дозволяють команді орендувати обчислювальні ресурси, сховище та мережу у провайдера, який вже побудував фізичну інфраструктуру. Головна перевага полягає не в тому, що комп’ютери є чимось таємничим; вона полягає в тому, що потужності можна швидко запросити через програмне забезпечення і платити за них відповідно до використання. Купівля обладнання все ще може мати сенс для передбачуваних довгострокових потреб, але вона не підходить для швидкого експерименту з невизначеним попитом. Хороша відповідь має згадувати як швидкість, так і відповідальність за керування конфігурацією, доступом та витратами.

2. Сайт роздрібної торгівлі потребує набагато більше потужностей під час святкового розпродажу, ніж у звичайні тижні. Яка модель інфраструктури відповідає такому патерну попиту, і яким ризиком команда все ще має керувати?

Хмара зазвичай підходить для раптових сплесків попиту, оскільки команда може додати потужності для розпродажу та зменшити їх після нього, замість того, щоб купувати достатньо обладнання для річного піку. Це перетворює бюджет з великої фіксованої покупки на більш гнучкі операційні витрати. Ризик полягає в тому, що ресурси можуть продовжувати працювати, занадто сильно масштабуватися або переміщувати дані дорогими способами, якщо ніхто не встановить контроль. Команді слід поєднувати масштабування з бюджетами, моніторингом, процедурами очищення та чітким відповідальним за перегляд витрат.

3. Ваша компанія вже активно використовує системи ідентифікації Microsoft та адміністрування Windows. Чи означає це автоматично, що Azure є правильним провайдером для кожного нового робочого навантаження?

Azure, ймовірно, має отримати серйозну оцінку, оскільки наявна інтеграція з Microsoft може спростити процеси ідентифікації, адміністрування, закупівель та підтримки. Але цей вибір не є автоматично правильним, оскільки робоче навантаження може потребувати регіонів, керованих сервісів, ціноутворення, переносимості або операційних патернів, де інший провайдер є сильнішим. Правильне рішення порівнює фактичні вимоги, а не обирає за впізнаваністю бренду. Зріла відповідь визнає, що відповідність провайдера залежить від контексту та має включати як технічні, так і організаційні обмеження.

4. Стартапу потрібно запускати код застосунку, зберігати завантажені відео, маршрутизувати публічний трафік та зберігати записи облікових записів клієнтів. Як би ви зіставили ці потреби з категоріями хмарних сервісів?

Код застосунку потребує обчислювальних ресурсів, таких як віртуальні машини, контейнери або інше середовище виконання, що надає CPU та пам’ять. Завантаженим відео потрібне сховище, швидше за все, об’єктне сховище, оскільки великі файли не повинні залежати від локального диска одного сервера. Публічному трафіку потрібна мережа, включаючи віртуальні мережі, правила брандмауера, DNS та, можливо, балансувальник навантаження. Записам облікових записів клієнтів потрібна база даних, і керована база даних може бути доречною, якщо команда хоче, щоб провайдер взяв на себе частину операційного навантаження.

5. Застосунок працює на одному хмарному сервері, і кожен збій сервера вимагає, щоб людина переміщувала його вручну вночі. Яку проблему вирішує Kubernetes у цій ситуації?

Kubernetes усуває розрив між бажаним станом і фактичним станом на кількох машинах. Замість того, щоб наказувати одному конкретному серверу запускати застосунок вічно, команда вказує Kubernetes, скільки копій має існувати, і дозволяє площині управління розміщувати ці копії на доступних вузлах. Коли вузол виходить з ладу, Kubernetes може запланувати роботу із заміни в іншому місці, якщо залишається достатньо потужностей. Це не усуває потребу в хорошому дизайні застосунку, але зменшує обсяг ручної роботи з розміщення та відновлення.

6. Команда каже: "Ми повинні перенести все в хмару, тому що хмара — це сучасно". Як би ви конструктивно піддали сумніву цей план?

Я б запитав про характер робочого навантаження, модель витрат, вимоги до даних, обмеження щодо відповідності нормативним вимогам, цілі щодо надійності та навички команди, перш ніж приймати план. Хмара може бути правильним вибором для швидкості, еластичності та керованих сервісів, але ці переваги не є автоматичними для кожної системи. Деякі стабільні або спеціалізовані робочі навантаження можуть працювати краще на власній інфраструктурі, а деякі міграції в хмару зазнають невдачі, оскільки команди не планують межі відповідальності. Конструктивний сумнів перетворює гасло на інженерне порівняння.

Практична вправа: Дослідіть безкоштовні рівні хмар

Ця вправа полягає в читанні документації провайдера очима інженера з експлуатації, а не в реєстрації облікового запису. Програми безкоштовних рівнів з часом змінюються, і поточні правила можуть залежати від віку облікового запису, регіону, сімейства машин, тарифного плану сервісу, пробного кредиту або місячних лімітів використання. Ваше завдання — проаналізувати структуру пропозицій і пов’язати кожну пропозицію з концепціями обчислювальних ресурсів, сховища та мережі з уроку.

Крок 1: Відвідайте поточні сторінки безкоштовних рівнів

Відкрийте ці сторінки у своєму браузері та ставтеся до них як до живої документації, а не як до статичних обіцянок з цього модуля:

Документація AWS Free Tier: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-free-tier.html
Документація Google Cloud Free Program: https://cloud.google.com/free/docs/free-cloud-features
Поширені запитання про безкоштовний обліковий запис Azure: https://azure.microsoft.com/en-us/free/free-account-faq/

Читайте сторінки достатньо повільно, щоб відрізнити пробний кредит від щомісячного завжди безкоштовного використання. Ця відмінність має значення, оскільки пробний кредит діє як тимчасовий бюджет, тоді як завжди безкоштовна квота зазвичай прив’язана до постійних лімітів та умов. Не припускайте, що заголовок стосується кожного регіону, кожного облікового запису, кожного сімейства віртуальних машин або кожного класу сховища.

Крок 2: Шукайте ці конкретні речі

На кожній сторінці спробуйте знайти ті самі три категорії, щоб ваші нотатки порівнювали пропозиції провайдерів замість копіювання розрізненої маркетингової мови:

Безкоштовні обчислювальні ресурси: Скільки безкоштовного серверного часу вони пропонують? Шукайте EC2 на AWS, Compute Engine на Google Cloud та Virtual Machines на Azure.
Безкоштовне сховище: Скільки безкоштовного сховища вони описують? Шукайте S3 на AWS, Cloud Storage на Google Cloud та Blob Storage на Azure.
Відповідність вимогам та тривалість: Які переваги є пробним кредитом, які є пропозиціями з обмеженим часом, які є завжди безкоштовними, і які умови щодо дати створення облікового запису, регіону, плану або сімейства віртуальних машин застосовуються?

Крок 3: Запишіть те, що ви знайшли

Відкрийте термінал і створіть файл для нотаток, щоб після вправи залишився невеликий артефакт, який ви зможете переглянути пізніше:

nano ~/cloud-notes.txt

Запишіть те, що ви знайшли, в єдиному форматі, використовуючи сторінки провайдерів як єдине джерело істини для поточних лімітів та умов:

My Cloud Research Notes
=======================
Date: <today's date>

AWS Free Tier:
- Compute: record the current EC2 offer, including whether your account creation date changes the eligible VM families
- Storage: record the current S3 allowance and any time limits

GCP Free Tier:
- Compute: record the current Compute Engine offer, including any region restrictions
- Storage: record the current Cloud Storage allowance and whether it is tied to trial credit or always-free usage

Azure Free Tier:
- Compute: record the current VM or credit-based offer, including any signup or plan conditions
- Storage: record the current Blob Storage allowance and whether it comes from credit, a limited-time offer, or an always-free limit

Notes:
- These offers are time-sensitive and full of conditions
- Some benefits depend on account age, region, plan, or eligible machine families
- Always check the current limits, regions, and account eligibility rules

Збережіть та вийдіть за допомогою Ctrl + O, Enter, потім Ctrl + X. Вам не потрібно створювати жодних хмарних облікових записів для цієї вправи, і ви не повинні вводити платіжні реквізити лише для того, щоб завершити модуль. Мета полягає в тому, щоб попрактикуватися критично читати хмарну документацію та побачити, як провайдери представляють обчислювальні ресурси, сховище та відповідність облікового запису вимогам.

Крок 4: Перевірте свої нотатки

cat ~/cloud-notes.txt

Перегляньте свої нотатки та позначте, чи кожен провайдер чітко розділив обчислювальні ресурси, сховище, відповідність вимогам і тривалість. Якщо сторінка здається незрозумілою, це корисна інформація, а не помилка. Справжня робота з хмарою включає уважне читання умов, перевірку поточної документації провайдера і запитання, що означає обіцянка в конкретному регіоні, для конкретного облікового запису і сервісу, які ви плануєте використовувати.

Критерії успіху

Ви відвідали принаймні одну сторінку безкоштовного рівня провайдера та визначили, чи включала пропозиція обчислювальні ресурси, сховище, чи і те, і інше.
Ви записали принаймні одну умову, яка впливає на відповідність вимогам, як-от вік облікового запису, регіон, пробний кредит або сімейство сервісів.
Ви зіставили одну специфічну для провайдера назву сервісу з категоріями обчислювальних ресурів, сховища, мережі або бази даних.
Ви зберегли свої нотатки у ~/cloud-notes.txt і перевірили їх за допомогою cat.
Ви можете пояснити, чому сторінки безкоштовних рівнів корисні для навчання, але їх не слід розглядати як постійні цінові обіцянки.

Джерела

Наступний модуль

Модуль 0.11: Ваш перший сервер продовжує шлях до підсумкового проєкту, збираючи все докупи: навички роботи в терміналі, віддалені машини, файли та хмарне мислення перетворюються на ваш перший розгорнутий вебсайт.