Хмарні технології: переваги та навички, потрібні для роботи з клаудами

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Всім привіт! Мене звати Андрій Євчак, і я розробник в компанії N-iX. Зараз працюю на проєкті Orbus Software — це британська технологічна компанія, яка розробляє ентерпрайз-рішення для своїх клієнтів по всьому світу. Я спеціалізуюсь на Azure та нещодавно отримав сертифікацію від Microsoft.

Згідно з LinkedIn, станом на серпень 2021, в Україні 11,000 AWS, 5,500 Azure, i 6,100 Google cloud-інженерів. І ринок продовжує рости.

Це — одна з причин, чому я вирішив написати цю статтю і розповісти про свій досвід роботи з хмарою. Я розкажу про основних провайдерів хмари, навички та сертифікації, якими варто володіти програмістам, аби працювати на потужному клауд-проекті, та багато іншого. Оскільки маю найбільше досвіду з Microsoft Azure, то і розповідати про хмару буду з точки зору саме цього провайдера.

Та почнемо з історії :)

Чому я обрав Azure

Azure створено та оптимізовано для роботи як зі старими, так і з новими програмами, розробленими за допомогою .NET фреймворку. Саме тому набагато простіше переносити сервіси Windows у хмару Azure, ніж на AWS або інші. Таким чином, для компаній, які використовують корпоративний софт на основі .NET, Azure є очевидним вибором. Тому як .NET інженер я надаю перевагу Azure.

Також — це підтримка автоматизованого DevOps процесу. У середовища розробки Visual Studio кращі механізми для роботи саме з Azure, тож це суттєво полегшує процес розробки та розгортання аплікацій, якщо немає налаштованого DevOps процесу, оскільки ми можемо публікувати їх у хмару безпосередньо з VS.

Крім Azure, найбільш популярними провайдерами хмари є AWS i GCP. Кожен з них надає безпечне хмарне середовище і ряд інструментів для полегшення роботи. Тому, на мій погляд, у виборі провайдера варто покладатись більше на індивідуальні потреби замовника.

Переваги роботи в хмарі

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

Оптимізація витрат

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

У N-iX ми неодноразово допомагали клієнтам з оптимізацією інфраструктури. Наприклад, один з наших клієнтів — міжнародний стрімінговий сервіс — потребував рішення, яке б витримувало високе навантаження в 36 мільйонів унікальних відвідувачів та понад 10 мільярдів запитів на тиждень і яке б було дешевше утримувати. Ми обрали оптимізацію шляхом створення Kubernetes кластеру у хмарі AWS. Наші розробники створили 30 мікросервісів, утримання яких обходиться клієнту приблизно у 2000 USD щомісяця.

Для порівняння, неоптимізована архітектура, що складалась з EC2 OnDemand instances обходилась нашому в клієнту більше ніж у 38000 USD на місяць.

Ось класичний приклад капітальних та операційних витрат:

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

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

  • Cost Analysis надає детальний розподіл витрат на всі послуги, які використовуються, показуючи подробиці хмарних витрат.
  • Cost Alerts надсилає автоматичні сповіщення, коли витрати перевищують попередньо встановлений поріг. До них відносяться сповіщення про бюджетні та кредитні витрати.
  • Budgets дозволяє створювати бюджет у межах підписки на Azure. Він також допомагає відстежувати хмарні витрати, встановлюючи обмеження та сповіщення.
  • Pricing Calculator надає оцінки вартості Azure сервісів.
  • Azure Advisor аналізує хмарні конфігурації та статистику використання, щоб запропонувати рекомендації щодо використання хмарних ресурсів та скорочення витрат Azure.

Час до виходу на ринок

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

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

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

Хмарні середовища також інтегруються із загальними інструментами DevOps та системами логування, що полегшує моніторинг та виявлення проблем у продакшені.

Масштабування

Легке масштабування — це, мабуть, найбільша перевага хмари.

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

Існує два способи масштабування в хмарі: горизонтальне та вертикальне.

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

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

Хмарні служби мають багато різних варіантів масштабування. Наприклад в Azure є така функція як Azure AutoScale.

Azure AutoScale це вбудована функція, яка налаштовує розподіл ресурсів для сервісів залежно від їхніх обчислювальних вимог. Можна масштабувати свої хмарні служби, віртуальні машини, веб сервіси та інші ресурси згідно з певними критеріями (розмір процесора, пам’ять, пропускна здатність або використання диска). Azure AutoScale — це спосіб більш ефективного використання хмарних ресурсів та оптимізація витрат одночасно. Azure автоматично підвищить обчислювальну продуктивність під час пікових годин роботи та зменшить швидкість роботи тоді, коли навантаження не буде таким інтенсивним. За допомогою автоматичного масштабування Azure не потрібно буде сплачувати за будь-які обчислювальні потужності, які не є потрібними, що істотно економить кошти.

Аварійне відновлення

Що станеться, якщо ви втратите дані клієнта?

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

Azure має інструмент під назвою Azure Site Recovery, який дозволяє компаніям створювати плани відновлення, які включають процедури реплікації та відновлення збоїв. Azure Site Recovery також дозволяє компаніям резервувати IP-адреси, встановлювати та налаштовувати балансування навантаження та інтегрувати Azure Traffic Manager для безперебійного перемикання трафіку.

Безпека

Провайдери хмари зазвичай забезпечують хостинг та сертифікований PCI-DSS, що надзвичайно важливо для дотримання GDPR. Крім того, хмара пропонує розширені заходи безпеки для захисту вашого вебсайту від DDoS-атак або інших загроз.

Ці переваги й сприяють поширенню хмарних технологій на ринку. Все більше компаній шукають досвідчених експертів для розробки хмарних рішень, або міграції з on-premise на клауд.

Мабуть, на кожному проєкті, де працюють з хмарою, є напрацьовані власні підходи до роботи. Проєкт Orbus, на якому працюю я в N-іХ— не виключення. Тому я розгляну, що використовували ми.

Найефективніші практики для роботи з хмарою

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

Microsoft пропонує ряд шаблонів для покращення ефективності роботи з клаудом. Деякі з них дозволили нам розв’язати певні проблеми при розробці хмарних рішень:

Deployment Stamps pattern

Цей шаблон забезпечує підготовку, управління, моніторинг та масштабування ресурсів. Кожна окрема копія називається штампом або одиницею масштабування (scale unit). У середовищі з кількома клієнтами кожен штамп може служити окремому клієнту. Можна розгорнути кілька штампів, щоб розширити аплікацію і обслуговувати більшу кількість клієнтів. Такий підхід може поліпшити масштабованість, дозволяючи розгортати сервіси у кількох регіонах і розділяти дані клієнта.

На проєкті наша команда зіштовхнулися з проблемою повільного доступу до наших веб ресурсів з інших регіонів. Сервіс був розташований у північній Європі, тому оптимізація слабких місць та покращення продуктивності її не вирішило б. Саме тому ми пішли шляхом гео-дистрибуції з допомогою Deployment Stamps pattern.

Щоб уникнути таких проблем в майбутньому, ми згрупували усі необхідні ресурси, які використовувала аплікація, в незалежну дистрибутивну одиницю (scale unit). Далі почали DevOps процес.

Для того, аби відчути усі переваги цього шаблону, потрібно описати інфраструктуру у вигляді програмного коду (infrastructure as code). Його побудова зараз має декілька альтернатив, наприклад, JSON Azure Resource Manager Тemplates (ARM templates), Terraform, AWS Cloud​Formation та інші. Оскільки наші сервіси розміщені в хмарі Azure і в нас у команді вже була певна експертиза з ARM templates — ми вирішили вибрати цю технологію. Створили шаблонний файл для усіх ресурсів аплікації та по одному файлу з параметрами для кожного регіону. Для маршрутизації трафіку між регіонам використали Azure traffic manager, адже його функції покривали усі наші потреби. Інтегрували шаблони з Azure Pipelines для координації розгортання в кожному регіоні.

І як результат, отримали більш стабільну веб аплікацію з швидким доступом до неї з різних регіонів.

Competing Consumers Pattern

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

Circuit Breaker Pattern

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

Retry Pattern

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

Saga Distributed Transactions Pattern

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

Використання готових шаблонів значно полегшує і пришвидшує роботу з хмарою.

Які сертифікації потрібні для роботи в клауді?

Існує ряд сертифікацій, які допомагають покращити навички роботи в хмарі. У N-iX є цілий підрозділ — Software Development Office, який запровадив ініціативу підготовчих груп до сloud-сертифікацій. Вони зібрали та структурували матеріали для ефективної підготовки. Також, спеціалісти всередині груп обмінюються своїм досвідом та інформацією, яка допомогла їм успішно скласти екзамен.

Як результат підготовчих груп, у N-iX сформувалася спільнота сloud-спеціалістів, де ми обмінюємося знаннями. Власне, одна з таких груп і допомогла мені отримати Microsoft- сертифікацію.

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

Azure має 4 рівні сертифікації: Fundamentals, Associate, Expert та Specialty.

Наприклад, сертифікати Microsoft Azure для початківців (Fundamentals). Жоден з них не допоможе отримати будь-який вищий сертифікат Azure, але вони, на мою думку, ідеальний початок для тих, хто не знайомий з хмарними сервісами або Azure зокрема.

Є 3 сертифікації цього рівня:

● Azure Fundamentals (AZ-900)

● Azure Data Fundamentals (DP-900)

● Azure AI Fundamentals (AI-900)

Associate

Якщо ви вже добре знайомі з Azure, вам може бути комфортно починати з таких сертифікацій:

● Azure Administrator Associate (AZ-104)

● Azure Security Engineer Associate (AZ-500)

● Azure Database Administrator Associate (DP-300)

● Azure Developer Associate (AZ-204)

● Azure AI Engineer Associate (AI-100)

● Azure Data Engineer Associate (DP-200, DP-201)

● Azure Data Scientist Associate (DP-100)

Expert

Якщо у вас є хороші технічні знання та досвід і вас вважають «Мілорд інженером», то ви можете бути готові до сертифікацій експертного рівня. Сертифікат Associate (або Azure Developer Associate, чи Azure Administrator Associate) необхідний для Azure DevOps Engineer Expert.

До цього рівня належать такі сертифікації:

● Azure Solutions Architect Expert (AZ-303, AZ-304)

● Azure DevOps Engineer Expert (AZ-400)

Specialty

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

● Azure IoT Developer Specialty (AZ-220)

● Azure for SAP Workloads Specialty (AZ-120)

Є багато шляхів до тієї, чи іншої сертифікації, але я б радив завжди починати з Azure Fundamentals. Для початківців — це хороший варіант для здобуття нових базових навичок, а для більш досвідчених працівників — це хороша можливість протестувати свої знання.

Навички, які вам знадобляться

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

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

● Архітектори: професіонали, які приймають критичні рішення стосовно архітектури;

● Техлід: відповідає за технічну частину та підтримку архітектурних рішень;

● Розробники: відповідальні за розробку коду;

● DevOps-професіонали: відповідальні за інфраструктуру, безпеку тощо;

● QA-професіонали, що відповідають забезпечення якості продукту.

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

1. Досвід з ключовими провайдерами хмари

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

Зазвичай, якщо продукт створений в екосистемі Microsoft, то провайдером хмари вибирають саме Azure, оскільки це надає можливість нативно використовувати стек Microsoft. Якщо ж на проєкті використовуються мови Java та Javascript (стек Node.js), то в основному використовують хмару AWS чи Google Cloud.

2. Досвід міграції даних на хмару

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

3. Експертиза у різних моделях хмарних сервісів (IaaS, PaaS i SaaS)

Поняття інфраструктури як послуги (IaaS), платформи як послуги (PaaS) та програмного забезпечення як послуги (SaaS) мають вирішальне значення для розміщення ваших даних у хмарі. І ось чому:

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

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

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

Віртуальні машини Azure — це IaaS.

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

Головна перевага PaaS — можливість швидко запускати додатки, в тому числі для невеликих команд. Крім того, використовуючи хмарні сервіси, розробники можуть збирати статистику по роботі свого ПЗ, аналізувати та приймати оптимальні для бізнесу рішення.

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

Наприклад, служба Azure Web Apps надає середовище для розміщення вебпрограм, без необхідності звертатися до віртуальної машини та операційної системи. База даних SQL Azure є повністю керованою платформою, яка обробляє більшість функцій управління базами даних (оновлення, виправлення, резервне копіювання та моніторинг) без участі користувачів.

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

Експерти N-iX надавали SaaS-рішення багатьом клієнтам. Наприклад, міжнародній інженерно-технологічній компанії, що входить до списку Global Fortune 100. Щоб покращити логістику між 400+ складами у більш ніж 60 країнах, наш клієнт запровадив внутрішню логістичну платформу, яка була неефективною через свою монолітну архітектуру. Саме тому вони вирішили почати співпрацю з N-iX.

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

Для успішної роботи в хмарі потрібно мати значний досвід роботи з IaaS, PaaS та SaaS.

4. DevOps-експертиза

Для роботи на хмарних проєктах необхідна і DevOps-експертиза. Команді потрібно:

● розуміти, які ресурси використовуються;

● проаналізувати, що можна оптимізувати і як це зробити;

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

5. Досвід з контейнеризацією

Такі технології, як Open Container Initiative (OCI), RedHat CoreOS Rkt або Docker, допоможуть зробити додаток портативним. Контейнери можна, за незначними винятками, запускати на будь-якій платформі без налаштування середовища.

Контейнер також збільшує щільність робочого навантаження. У порівнянні з віртуальними машинами (VM) контейнери набагато ефективніше використовують обчислювальні ресурси, що оптимізує витрати та час.

6. Досвід з оркестрацією

Без оркестрації, контейнеризація не була б настільки цінною. Існує чимало популярних платформ, які можуть запускати контейнерні робочі навантаження для різних видів інфраструктури, включаючи публічну хмару IaaS, приватні хмари або on-prem: Cloud Foundry, DC/OS (розподілена хмарна операційна система), Docker Swarm, Hashicorp Nomad, та Kubernetes, який став промисловим стандартом.

Отже, щоб успішно працювати з хмарою, варто використовувати вже готові шаблони, які надають провайдери хмари, вміти мігрувати дані, мати досвід з різними хмарними моделями (IaaS, PaaS, SaaS), та мати DevOps експертизу. Крім того, бажано мати клауд-сертифікацію. У нас в N-iX є багато клауд-проєктів, де Ви можете розвивати всі ці навички. Так що приєднуйтесь до нашої клауд комм’юніті!

Якщо є питання — ставте в коментарях!

👍НравитсяПонравилось5
В избранноеВ избранном5
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Клауды чем плохи, так это тем что разработчики леняццо. Нафига оттачивать алгоритмы-структуры данных, если можно просто по щелчку 100500 инстанцов запустить. Платит то всеравно не девелопер. Особенно с вот этим тайм-то-маркет, когда говнеру можно обосновать, что мол алгоритмы это 2мес времени, а 100500 инстанцев это вот прям щас.

бегите из этого проекта, оно того не стоит. Так далеко не везде.

Критичні недоліки клаудів — неадекватні ціни, спробуйте зробити розрахунок 3 рашбері серваків на лінуксі по 40$ і потім розрахувати такі ж потужності на клауді. Вони розраховують що без ажур це буде 15000$ за рік і пропонують всього за 8000$. Будь-який реальний бізнесмен який вміє рахувати гроші ніколи не заапрувить це, навіть після консультацій з сертифікованими AZ-304 спеціалістами. Інший недолік — дуже мале ком‘юніті. На стековерфлоу майже немає питань/відповідей по ажуру. Немає реальних користувачів. Причина в тому що мс не надає безкоштовних дев акаунтів, тільки на місяць. досвід набути — тільки на проді або за свої бакси. Реєстрація тільки з банківською картою. Як навчитись користуватись технологією за місяць, особливо якщо ти працюєш фулл тайм або студент? Питання риторичне. Мій прогноз — майкрософт не зможе набрати реальних користувачів технології, коли хайп клаудів спаде — азур помре.

Причина в тому що мс не надає безкоштовних дев акаунтів, тільки на місяць ...або за свої бакси. Реєстрація тільки з банківською карто

$29 в месяц. Совершенно неподъемная сумма для девелопера, который хочет быть в тренде. А банковская карта — о ужос — это же доступно только олигархам. Вы точно не в 1994 году живете?

Мій прогноз — майкрософт не зможе набрати реальних користувачів технології,

Примерно 20% рынка с уверенным трендом роста, впереди только AWS

3 рашбері серваків на лінуксі по 40$

C какой именно спецификацией?

... такі ж потужності на клауд ... пропонують всього за 8000$.

Открываем Azure calculator, смотрим что можно взять за $8K в год — тыкаем практически первое попавшееся — West US, Linux, 8vCPU, 32G RAM, 64G disk, при резервировании на 1 год. — $231/мес. 3 таких сервера — $8316/год. При резервировании на 3 года -$5300/год. При этом это public цены — обычно при крупных договорах там еще дополнительные скидки.

$29 в месяц.

звідки сумма? підписка pay on the go яку пропонують мс значить що ти платиш за те що використовуєш. Ти можеш і на 299999$ в місяць використати. Система цін зроблена максимально заплутано, і відповідальність лежить на тому хто використовує. Я би заплатив 29$ але знаю це буде бар’єром для входу для інших людей. Екосистеми не буде.

Примерно 20% рынка с уверенным трендом роста, впереди только AWS

для мене кількість коментарів stackoverflow більш наглядний показник. Враховуючи скільки ресурсів витрачається на рекламу і такий маленький вихід — явно немає стільки клієнтів щоб оплачувати це. Я ставлю що те буде як windows phone — не вийде на прибуток і через рік два перерахують і виявиться що 20% ріст = −30% ROI

C какой именно спецификацией?

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

3 таких сервера — $8316/год. При резервировании на 3 года -$5300/год. При этом это public цены — обычно при крупных договорах там еще дополнительные скидки.

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

звідки сумма?

$29 в месяц — это Developer support, если есть желаниe, без которого можно легко обойтис — тогда будет вообще только за ресурсы. Кстати рекомендую ознакомиться:
azure.microsoft.com/...​us/pricing/free-services

и можеш і на 299999$ в місяць використати.

Бюджеты и алерты в помощь

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

Вполне себе нормальный калькулятор и advisor

відповідальність лежить на тому хто використовує

D
Вообще не понял этой мысли. А на ком еще??

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

Google: Azure Revenue. Первый же результат:

Microsoft reported its Q4 2021 performance with revenue of $46.2 billion, net income of $16.5 billion, up 47% from last year, and earnings per share of $2.17, up 49% and beating analyst estimates of $1.91.

16 млрд дохода за квартал — некому оплачивать, да

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

Совсем не понял этого предложения. При чем тут электрика к облаку? Я изначально просто хотел ради интереса утончить спецификацию

3 рашбері серваків на лінуксіпо 40$

, чтобы понимать что с чем сравнивать

вот это интересно
Azure SQL Database Hyperscale?
youtu.be/Z9AFnKI7sfI

на домашнем сервере задолбаешься такое мутить
и даже макбук про не поможет

Щось я не зрозумів.

«сертифікати Microsoft Azure для початківців (Fundamentals). Жоден з них не допоможе отримати будь-який вищий сертифікат Azure»

А далі на картинці все тільки з них і починається.

Это предполагаемый путь развития, на каждый сертификат есть один или несколько экзаменов, можно хоть сразу идти на эксперта сдавать.
Короче лучше просто выбрать интересующий и посмотреть требования на офф сайте.

можно хоть сразу идти на эксперта сдавать.

можна але не дадуть сертифыкат без ще одного екзамена

Так я же говорю

на каждый сертификат есть один или несколько экзаменов,

Типо как AZ-303 и AZ-304, понятно что нужно оба)
Я о том что одна сертификация (Associate) не нужна для другой (Expert).

ну як же
продати сніг ескімосам та чукчам
тобто окучити ринок нетехнічних спеціалістів та менеджерів
для того хто йде далі сенсу в них ніякого

Должен остаться только один

клауд

Дункан Маклауд!

Він і так один, попробуйте злізти з цього самого ейжа, навіть не зважаючи на такі ідіотські рішення MS як OMIGOD affected боти, які MS знає як втулити вам без вашого відома, але не знає як залатати дірки. Last year HPE CEO Antonio Neri compared the public cloud to the „Hotel California” in an interview with Protocol: As the Eagles might have put it, your data can check out any time it likes, but it can never leave.

И еще, большой вопрос с облаками — это ответственность вендора. Какая ответственность в денежном эквиваленте того же MS в случае например services down в течение часа? двух? дня? В случае серьезного e-commerce, это могут быть миллионы недополученной выгоды.

Ну по-перше там SLA прописано. По-друге onprem падає аж бігом також. Навіть ще крутіше ніж клайди. По третє для хоча б 3-х дев’яток треба резервування і винесенний DR location. А от це вже дешевше і зручніше в клауді.

Ну по-перше там SLA прописано

«В случае недоступности региона в течение 2 часов мы оплачиваем недополученную выгоду» ? — может наверное применяться per client basis в зависимости от калибра, но никогда такого не слышал и ооочень сильно сомневаюсь. Обычно это что-то типа скидки в X% в месячном счете, не более того — цифры совервшенно другого порядка

По-друге onprem падає аж бігом також. Навіть ще крутіше ніж клайди

А у вас негров вешают, да. Разница в том, что когда падает onprem, обычно понятно кто-виноват-куда-бежать-что-делать. А получая масштабные сбои в аутентификации сервисов в облаке, из-за криво накаченного патча на AAD, как-то не очень.

По третє для хоча б 3-х дев’яток треба резервування і винесенний DR location. А от це вже дешевше і зручніше в клауді.

Тоже не все так однозначно. В смысле того, что если рассматривать 3 девятки для каждого отдельного сервиса — это одно. Полностью же переключиться на другой регион, как для комплексного решения — это весьма и весьма нетривиальная задача

P.S. Быстро просмотрел — стандартный SLA от MS:

<99.x% — 10% service credit (x — depends on service)
<99% — 25% service credit

То есть, строго говоря если твои core сервисы были недоступны в течение 5 дней из месяца, максимум на что можно рассчитывать — на 25% скидку. Такая себе компенсация

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

То есть, строго говоря если твои core сервисы были недоступны в течение 5 дней из месяца, максимум на что можно рассчитывать — на 25% скидку. Такая себе компенсация

А хто і скільки платить коли падає онпрем? А? Від того що зрозуміло хто винен легше не стає. Я знаю, я відповідав за availability :).

Полностью же переключиться на другой регион, как для комплексного решения — это весьма и весьма нетривиальная задача

Я знаю. Я це робив. Для stateful mission critical service. Але
а) мати DR location в клауді дешевше. Хоча б тому що не платиться за інстанси які не працюють.
б) в будь якому випадку треба будувати дубльовану інфраструктуру.

А получая масштабные сбои в аутентификации сервисов в облаке, из-за криво накаченного патча на AAD, как-то не очень.

Якщо не зав’язувати свій сервіс на сервіси провайдера то подібні збої не впливають на доступність основного сервісу, а rrsiurce provisioning як правило не має бути mission critical. У єкоммерца так точно :).

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

SLA который не подтвержден деньгами — не более чем реклама/декларация о намерениях

Якщо не зав’язувати свій сервіс на сервіси провайдера

Не совсем понял. Есть например Azure Service Bus/Cosmos с аутентификацией через AAD, которые активно используются в приложениями — что значит не завязывать свой сервис на сервисы провайдера?

Ну ми наприклад використовуємо тільки IaaS рівень — віртуальні хости, нетворкінг. В GCP вони не зав’язані на ту саму аутентифікацію для своєї роботи.

Ну наверное для ваших задач так лучше, вам виднее. Просто как по мне максимальный бенефит в треугольнике время-усилия-результат дают как раз PaaS сервисы, поэтому удивился

PaaS це досить сильний vendot lock. Ну і стара істина, що serverless не означає що серверу нема, просто не ти його контролюєш :).

PaaS це досить сильний vendot lock.

Ну смотря что юзать, service bus использует стандартный amqp например. А Cosmos DB вообще 5 видов api из которых только Tables API специфичный.
Но авторизацию при переезде конечно придется переписать.

Я з Ажуром тісно не працював, але досвіт виковирювання з application сервісів AWS для того щоб зробити сервіс cloud neutral був. Девам прийшлося повозитися.

service bus использует стандартный amqp например

Но при этом у них есть 3 проприетарных полностью разных клиента, которые они переделывают раз в пару лет и депрекейтят старые, которые заюзав в коде без доп абстракций при переходе на rabbit прийдется полностью переписывать. Rabbit клиент тоже не видел что бы они использовали — толку там от этого amqp..

А Cosmos DB вообще 5 видов api из которых только Tables API специфичный.

Срака полная — помню года 2 назад у них даже клиенты, что пишут в одну базу были несовместимыми -mongo api/sql api хотя оба предназначены для работы с json документами один не мог прочитать документ созданный другим клиентом. И это было недокумментированно. Дичь полная.

Но при этом у них есть 3 проприетарных полностью разных клиента,

Я бы сказал что там есть SDK, который естественно развивается.

толку там от этого amqp..

Это да, amqp там глубоко внутри

mongo api/sql api хотя оба предназначены для работы с json документами один не мог прочитать документ созданный другим клиентом

Естественно и вполне ожидаемо, странно не понимать таких простых вещей.

Естественно и вполне ожидаемо, странно не понимать таких простых вещей.

Так устроено все клиент-серверное программирование, что клиент имплементирует протокол сервера, а не определяет его. Странно не знать этого и ожидать обратного поведения — что клиент будет диктовать протокол серверу и влиять на совместимость с остальными клиентами оперируя одним и теми же наборами информации.

мати DR location в клауді дешевше. Хоча б тому що не платиться за інстанси які не працюють.

а вот это уже профанация
для заявленного выше

stateful

платить нужно именно, что — ровно те же деньги, за ровно те же ресурсы
так что извините, но — или к красивым или к умным
и для on-prem точно так же есть масса реализаций у ряда вендоров, когда DR-сайт обходится дешевле, включая железо, ресурсы которого будут активироваться лицензиями, перемещенными с основного сайта

платить нужно именно, что — ровно те же деньги, за ровно те же ресурсы
так что извините, но — или к красивым или к умным

Ні, тільки за сторадж. За інстанси платити не треба, їх піднімають у випадку катастрофічної відмови основного location. У випадку з залізяками вони просто гріють повітря чекаючи коли на них перейдуть.

, їх піднімають у випадку катастрофічної відмови основного location

Залежить від архітектупи і конкретного інстансу.
Маленькі аплікейшмни -може.
DR можливо
Величезну базу і зразу і без втрат . Нуну

Є таке слово «реплікація»

За інстанси платити не треба, їх піднімають

тут треба уточнити реплікація чого і куди
інстансу ж нема ще (читай вище)
значить реплікація дисків чи щось таке

За інстанси платити не треба, їх піднімають у випадку катастрофічної відмови основного location

тогда это НЕ stateful

Application server is stateful. Тобто не можна було мати 2 активних інстанси одночасно.

Application server is stateful. Тобто не можна було мати 2 активних інстанси одночасно.

Это несвязанные вещи в общем случае (stateful и 1 инстанс). Это говорит только о том, что конкретно у вашего решения именно такая архитектура.

їх піднімають у випадку катастрофічної відмови основного location

Это значит что вы можете позволить себе какое-то время простоя, так как этот процесс не мгновенный

А хто і скільки платить коли падає онпрем? А?

і яка тоді різниця? а?

Надійність IaaS набагато вища від on-premise просто за рахунок розподіленої інфраструктури.

<99% — 25% service credit
То есть, строго говоря если твои core сервисы были недоступны в течение 5 дней из месяца

Може року?

ага
прокидається умовний індус і починає апдейти накачувати
при тому що всі автоапдейти відключені

я 2 тижні бодався кому яйця вкоротити
кругова порука і всьо

Небольшой комментарий — упомянутые паттерны (кромe Deployment Stamps) неспицифичны для Azure, да и для клаудов в целом тоже. Соответсвенно, Azure не предоставляет практически никаких тулов для их имплементации (кроме, возможно, retry встроенного в APIM и различные SDK) — это все остается на ответственности девелоперов

У клаудів є ложка дьогтю: для організації хмаринок беруть все найдешевше, які б казки не розповідали у рекламі. Тому, коли ваша тучка злетить в пекло через яке-небудь непофіксане бажество типу Spectre і тому подібне «оптимізоване» щастя, чи ваші дані скажуть «Ізя всьо» через жлобський рейд — більшість із вас повірить, що це просто «нє повєзло», а не тупо тому що на ваших проектах зекономили пару баксів.

І при цьому цінник входу в хмари зазвичай такий самий, як і підіймати все самим. Бо тільки в рекламі все гарно, а як до діла доходить — то гнилий RTFM, писаний чукча-письменниками і ще більш тухлий сапорт із індійської трущоби.

Ідея клаудів гарна. Але це ринок лимонів. Хмари гарні, щоб спробувати злетіти. Але щоб літати постійно, треба мати або девопса, який цими хмарками керуватиме, або девопса, який тупо керуватиме чесним залізом. Звичайно, краще мати і те, і інше, просто для постійних задач свою архітектуру, а хмари — як аутсорс, наприклад для CDN.

Замечаю, что как раз продуктовые компании не доверяют особо клаудам, а размещают на своих серверах. Зато в аутсорсе аж бегом всю инфраструктуру там и разворачивают.

Ні, це дуже не так. Продуктові компанії залюбки використовують клауди. І навпаки бачив аутсорсний проект onpremise :).

Именно так. Бочка мёда + ложка дёгтя. Потому, чем ценнее данные, тем дороже обходятся именно риски клауда. И ключевой из них — банальнейшее стремление владельцев сэкономить каждый цент, потому что этот цент умножается на объём, и получаются миллионы баксов чистого профита — ну кто ж перед таким устоит. А для клиента этот цент экономии может вылететь в десятки тысяч баксов потерь деньгами и жопу в репутации — клауд при этом потеряет от силы на оплату девочки в индийском колл-центре.

Это как с хорошим вином — вы не станете покупать его в третьесортном баре. И в первосортном супермаркете. А хотите очень хорошее вино — храните его у себя или у тех, кого знаете лично, что будут соблюдать условия.

И если с вином это больше вопрос элитарности понтов, то с данными в 21 веке можно себе позволить перестраховаться как минимум 4-5 из 10 проектов, и переплатить либо за качественный клауд (в том числе заплатить временем за его поиск и поиск того, кто фактически будет его обслуживать, разумеется за соответствующую денежку), либо за честное железо в коллокейшене (и вот тут уже трижды переплатить временем за поиск). И разумеется не хоститься в Украине и ей подобных феодальных тьмутараканях, где датацентр могут ограбить «свои» же мусора.

Клауды были бы хороши, если бы были механизмы обратной связи, когда за про@bы была бы жёсткий финансовый кнут, чтобы в случае потери данных клауд терял деньгами больше, чем клиент. А пока владелец клауда ничем не рискует кроме известности (которую легко компенсировать рекламой) — клауд остаётся второсортным решением.

Разумеется, риски клаудов возможно перестраховывать бэкапами. Но если делать по уму, то это дополнительные расходы. В том числе на вечный контроль того, что происходит на самом деле после того, как казалось бы настроены алгоритмы. Мелочи, но на этих мелочах ой-как любит экономить руководство, ибо АВОСЬ — наше всё.

Клауды были бы хороши, если бы были механизмы обратной связи, когда за про@bы была бы жёсткий финансовый кнут, чтобы в случае потери данных клауд терял деньгами больше, чем клиент. А пока владелец клауда ничем не рискует кроме известности (которую легко компенсировать рекламой) — клауд остаётся второсортным решением.

Золотые слова. Полностью поддерживаю

Ні, Ви помиляєтеся. Я займаюся клаудами десь з 2007 року. Ця модель вигідніша, зручніша і безпечніша ніж аналогічна інфраструктура розгорнута on-premise.

Два з трьох Ваших стверджень дуже спірні :) Ви точно маєте відношення до сек’юріті, чи все ж більше до продажів клаудів? :)))

Я маю найпряміше відношення до секьюріті. Скільки буде коштувати забезпечення фізичної охорони датацентру, виконання процедур фізичного знищення медіа, забезпечення доступності одного датацентру та підтримка декількох географічно рознесених датацентрів для забезпечення off-site backup і disaster recovery? І це я тільки навскидку найбільш помітні речі.
Повторюся — я в клаудах з 2007 року — в опс mission critical SaaS service і т.п. Клауди (при правильному звичайно використанні) надійніші і безпечніші ніж on-premise.

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

Оххх...
ОК, давайте ВИ мені розкажете про СВІЙ особистий досвід побудови інфраструктури для критичного сервісу. І поясните свою тезу що

Два з трьох Ваших стверджень дуже спірні

. А Фейсбук з його абсолютно окремою історією давайте залишимо у спокої.

Давайте, звичайно розкажу. Я колишній пресейл і солюшн архітект серверного департаменту одного з найбільших інтеграторів України. Ми були платінум/голд партнери MS та всіх інших вендорів, які представлені в Україні. Я проектував і будував багато різних серверних рішень + все те, про що Ви писали: секьюріті, DR, Backups, etc. Тому чудово розумію, скільки вони коштують і наскільки складно і дорого (чи не дуже) це імплементувати. Останні 10 років як ДевОпс консультант займаюся практичною міграцією проектів (або їх неміграцією через певні причини) між датацантрами та різними клаудами в різних країнах, серед них Netherlands, UK, та USA.

До речі, Facebook це не едина компанія, яка працює на реальному залізі :) Ви це знаєте?

Прекрасно! Тобто Ви хочете сказати що 2 географічно рознесених on-premise датацентри створити і утримувати дешевше ніж розмістити інстанси в двох регіонах скажімо GCP? Що додати потужності до таких on-premise датацентрів легко просто і швидко і не треба планувати на півроку (мінімум) вперед?
PS
З Фейсбуком все досить просто — коли вони виникли і розкрутилися не було IaaS

Прекрасно! Тобто Ви хочете сказати що 2 географічно рознесених on-premise датацентри створити і утримувати дешевше ніж розмістити інстанси в двох регіонах скажімо GCP? Що додати потужності до таких on-premise датацентрів легко просто і швидко і не треба планувати на півроку (мінімум) вперед?

Что такое on-prem в вашем понимании?
Именно свое железо или VPS у хостинг провайдера?
Если первое то согласен, клауд дешевле, если второе — когда я смотрел цены то виртуалка в ажуре раза в 3-4 дороже почти любого дедика.На счет сложности поддержки — ну наверное да, если нужны аналоги availability zone и критичен аптайм.
Мне не особо повезло и все проекты где я работал можно было бы закинуть в VPS и сэкономить тысячи баксов в месяц. Да и падали они от деплоя кривого чаще чем упала бы машинка в дц=) На одном проекте тоже погнались за хайпом, переехали в aws и косты вырости так что по мощностям ппц пришлось ужиматься чтобы топ менеджмент не задавал вопросы по «оптимизации».

Ну и еще по поводу поддержки и расширения мощностей — лучше найти девопс лида на 6к который будет всякими терраформами/кубернетесами заниматься. И проблем сразу станет меньше.

Ееее... VPS це virtual private server? І чим це НЕ клауд?

VPS обычно выделенные сервера 24/7, клауды обычно предлагают политику «плати за то что используешь».
Но при этом клауды включают в себя возможность предоставить выделенные мощности с помесячной оплатой.

ОК, давайте тоді повернемося до визначення клауду. Воно не канонічне але використати можна. По ходу поставимо + або мінус чи попадає VPS під нього.
Згідно NIST клауд сервіс це сервіс який має такі ознаки:
— On-demand self-service. («+„)
— Broad network access. (“+»)
— Resource pooling. («+» адже VPS це віртуальні сервери які дільть залізо з іншими тенантами)
— Rapid elasticity. («±» — тут все залежить від того наскільки швидко можна провіжинити хост)
— Measured service. («+»)
Я б ще додав
— абстрагує користувача від нижчих рівнів реалізації, наприклад від заліза у випадку IaaS (чи VPS +)
Ну тобто з моєї точки зору, і НІСТ я думаю зі мною згодні :), VPS це таки клауд, Так би мовити IaaS на на мінімалках. Великі IaaS просто надають більше сервісів, дають більше можливостей в реалізації правил мережі, аутентифікації і т.п.

Broad network access

Не всегда

Measured service.

Этот пункат включает измерение ресурсов для последующей оптимизации провайдером, например IOPS или RU/s. В общем случае просто чтобы

«плати за то что используешь».

А простой мониторинг CPU, disk, ram, network будет даже на голой железке если прикрутить туда DataDog.

Це не я придумав — це визначення NIST. National Institute of Standards and Technology. nvlpubs.nist.gov/...​ialpublication800-145.pdf
Можете їм написати що Ви не згодні з цим документом :).

Так я с ними согласен, это Вы не так поняли:)
Cloud systems automatically control and optimize resource use by leveraging a metering capability.

Ну и еще по поводу поддержки и расширения мощностей — лучше найти девопс лида на 6к который будет всякими терраформами/кубернетесами заниматься.

Ну так це все має бути на якійсь базі? Залізяки чиї тоді?

Так, в розрахунку на довгу перспективу залізо виходить дешевше. Якщо залізо на датацентр коштує 1М USD, і це на 5 років, то за таку саме потужність в клауді Ви будете викладати по 1М USD в рік. Так, клауд трохи зручніший для тих, хто кляцає мишкою. Бо для всіх інших є Chef, OpenStack, та купа іншого, і куди деплоїти Вашу систему CI/CD пайплайнам — повірте, пофігу абсолютно. Головне, вийти за рамки 1 фізичного сервера і бути поближче до Big Data рішень, які скалюються легко, записують дані по багатьом серверам в декілька копіях і мають скажену пропускну здатність.

Ми робили розрахунок і практичні заміри по перенесенню 2 шкафів 42″ з датацентру в GCP. По-перше, просто перекласти 1 в 1 по disk-cpu-memory не працює — коли написано 1 vCPU, це не завжди повний core від якогось там зазначеного CPU, це може бути лише половинка. Теж саме по диску — трансфер і IOPS мають обмеження. А про швидкість роботи пам’яті теж є питання. В результаті практичного вимірювання з’ясувалося, що на 2 шкафи серверів (близько 60 штук) витрати будуть становити в 12 разів більші в клауді, щоб забезпечити таку саме пропускну здатність _системи_

ФБ розкрутився після 2007. Клауди вже були, вони бачили всі «+» і «-» клаудних рішень. Великі компанії, які в клауді, купують там bare metal, а не IaaS :)

Ми робили розрахунок і практичні заміри по перенесенню 2 шкафів 42″ з датацентру в GCP.

Це в одному реки. Значить у резервному мають бути ці самі 2 реки. (НЕ-прод не рахуємо, його резервувати не треба). При чому в звичайному стані вони нічого не роблять, просто гарячий резерв. За який ми все ще платимо як за основний датацентр.
В 2007-му році не було ще комерційно доступного нормального клауду. ВМ тільки розкручувалися і коштували диких грошей. Я добре це памйятаю бо як раз в цей період будував сервіс в 3-х датацентрах рознесених по світу.

З такою методикою розрахунків — гарячий DC, холодний DC — всі бюджети будуть вилітати в трубу. Тільки distributed systems! Це вже років з 10 як в тренді. Я навів приклад з 2 шкафами лише для розуміння методики розрахунку і коєфіцієнтів, які треба keep in mind при міграції в клауд.

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

А, о, ще згадав одну штуку. Коли працюють на одного клієнта та в Україні то про це не задумаються але клієнти в різних країнах потребують своїх location як для мінімізації лагу (Автралія наприклад) так і через вимоги регуляторних органів — Європа. Звичайно можна ставити залізо в collocation але клауди набагато зручніші і дешевші.

за таку саме потужність в клауді Ви будете викладати по 1М USD в рік

тут можель бізнесу та архітектура така що це закладено в ціну що платять клієнти
тоді дійсно зручно перерозподіляти не своє

створити і утримувати

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

їх можна і орендувати і свої залізяки туди завезти

Оренда коштує гроші. Залізяки коштують гроші. Керування конфігурацією коштує гроші. Я відповідав за 3 датацентри на 2-х континентах . Таке собі задоволення.

все коштує
ажур клауд не економить гроші
по іншому розподіляє витрати і час швидше

Да что уж там. Некоторые боятся даже код в приватных репозиториях Гитхаба сохранять, а тут Клауды)

Реклама те саме каже. Але ложка дьогтя. Воно все «вигідно» — коли це чужі активи, і їхню втрату із кишені покриєш не ти.

Це як армія в Україні: професійна вигідніша. Але призовна нібито дешевша, тому що ресурс «дармовий». А чому територія окупована, а військом правлять свинарчуки — то секрет «клауда».

Вибачте фігня. Маю досвід підтримки mission critical service на власних залізяках і в клаудах. On-premise і дорожче і гірше. Prіvate cloud це варіант але він коштує ще більших грошей.

ще більш тухлий сапорт із індійської трущоби

Не совсем так, зависит от уровня контракта

В переводе на русский, индивидуальный подход к каждому клиенту aka лохотронский маркетинг.

Не знаю что там с маркетингом, но у нас на проекте саппорт от MS 100% USA, включая людей из их дев. команд при необходимости. Правда там бюджет измеряется 8значными цифрами, насколько я знаю.

из с ша и белыми гражданами по рождению?

На 100% из US и на 70% по рождению, по крайней мере судя по именам и фамилиям. Оттенки кожи, пардон, через аудиоканал определить трудно

не знаю каким клаудом дяди Васи вы пользовались, но если рассматривать крупных игроков, то написанное — это сферическое заблуждение, чтоб не сказать бред, бред не имеющий ничего общего с реальностью

Продавцы облаков конечно же стремятся обеспечить лучшую надёжность, не жалея средств, а совсем даже не подешевле купить — подороже продать. Блаженны верующие

я работал в двух провайдеров мирового уровня, не понаслышке знаю как там все устроено, так вот все что ты написал полный бред и ничего не имеет общего с реальностью.
Потеря данных недопустима, никто никогда не будет экономить за счет даже маленького риска потерять данные.
не уверен это у тебя искреннее заблуждение или идиотизм в стиле «земля плоская» и «чипование вакциной».

я наївний був і думав їх стратегія буде порахувати скільки вони зможуть зекономити за рахунок масштабу і поділитися цим ’зекономлемим’ з клієнтами і всі ми будемо разом жити в раю за рахунок масштабу і економії. Але скоріш їх стратегія — порахувати витрати і помножити на 15.

ХЗ, последние неск лет сплошной авс и эйжур, сейчас куда не глянь облака на проектах просто стандарт. Лично у меня проекты еще с 15 года сплошные клауды, хот я в них нихера и не отдупляю.
Я думаю бизнесу лучше видно, что выгоднее.

Получается там где выбирают AWS для .NET — разработок — дешевизна по сравнению с Azure? И ведь странно, когда вот вам Майкрософт чуть ли не насильно при .NET — разработке предлагает именно Azure. Пусть экономят тогда дальше, потом с багами и другими проблемами бороться дольше. Ну вообще бывает чисто политический интерес в компании, когда у нее реальное партнерство с Amazon, но это немного убивает здравый смысл все же.

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

Після появи .NET Core, який дозволив легко і доступно контейнеризуватися, AWS-спеців тепер серед дотнетчиків десь до половини, і навіть GCP є.

Дякую автору за гарну статтю. Думаю, що вона буде дуже корисною для розробників, які починають роботу з клаудами

Яку сертифікацію здавали? Дамп є?

Там же есть Practice Test от мелкомягких, он бесплатный.
Мне на реальном экзамене AZ-303 даже пару вопросов попалось оттуда.

На Udemy были курсы, что-то до $20, по факту практически дамп ответов объемом процентов в 60

whizlab ще
юдемі теж непогано
тільки дивися коли у екзамена оновлення
індусам час треба щоб все обновити...

інша справа екзамен лінукс або кубернетіс
там складніше

Андрій здав і 303 і 304 (ми з ним в одній компанії і навіть будинку ;-) )

Круто, я не здав 304 (576 балів всього), бо там окрім Azure купа питань з Active Directory і тих питань, з яких треба мати практичний досвід адміністрування AD. В мене такого немає — я Linux guy, і завжди обходив стороною AD :)

і завжди обходив стороною AD

В AZ-303 они тоже будут, особенно способы интеграции Azure AD + on-prem AD через AD Connect.
А еще Azure Migrate для миграции VMWare и Hyper-V.
Ну и Powershell.
Так что надо стать немножко виндовс guy :)

там окрім Azure купа питань з Active Directory і тих питань, з яких треба мати практичний досвід адміністрування AD.

Там по факту есть просто несколько паттернов связанных с AD, которые надо выучить для себя, типа вижу упоминание SmartCard — значит в ответе Federation Services ,

Читав, бачив помилки, стримував себе. Дочитався до

Провайдери хмари зазвичай забезпечують хостинг та сертифікований PCI-DSS, що надзвичайно важливо для дотримання GDPR.

Випав в осадок. Хтось може пояснити про що тут? Чому PCI DSS став раптом важливим для GDPR!?

Стаття дуже загально-оглядова, можуть бути лакуни в конкретних речах.

Лакуни? Та це речення взагалі немає ніякого сенсу.

Пару років тому розбирався з цим для проєкта пов’язаного з пройомом платежів. Вже не все пам’ятаю, але якщо не помиляюся, то в цьому нема помилки. Для проєктів, які зберігають або хоч якось маніпулюють номерами карток, рухунків, тощо, на бекенді, наявніть PCI-DSS використовується як стандарт імлементації data security, що є вимогою GDPR, і без цього сертифікацію не пройти.

Ні, ні, ні і ще раз ні. PCI DSS немає ніякого відношення до GDPR. Повірте людині яка як зараз в черговому PCI DSS аудиті.

Ок, я вам охоче вірю. Але ж як ви будете доводити інспектору з GDPR що у вас чутливі дані добре захищені? Вам треба використати імплементацію якогось стандарту (краще популярного), щоб це довести. Де юре так, вони звичайно не пов’язані.

Я проходжу сертифікацію SOC2 і PCI DSS. Це окремі процеси і вони не заміняють один одного. Сертифікації по GDPR поки не проходили але думаю там якщо щось і буде то аналогічно іншим фреймворкам — абсолютно окремий процес.
PCI DSS взагалі дуже специфічний і вузький стандарт який стосується тільки даних платіжних карт. Ті системи та процеси де платіжних карт нема просто знаходяться за скоупом.

Сертифікації по GDPR поки не проходили але думаю там якщо щось і буде то аналогічно іншим фреймворкам — абсолютно окремий процес.

Це абсолютно окремий процес. До вас прийде інспектор і буде питати з різних аспектів GDPR. Одна з вимог GDPR — data security. Він вам скаже: ваш проект зберігає номери платіжних карт. Як ви переконуєтесь що вони зберігаються безпечно? А ви йому скажете: ось ми пройшли сертифікацію PCI DSS, ось документи. Він скаже: питань більше нема, поїхали далі.

Це Ви по досвіду чи просто придумали? Бо повторюся — SOC2 і PCI DSS працюють інакше. Ну і для GDPR платіжні карти це далеко не все.

Ну і для GDPR платіжні карти це далеко не все.

Звичайно це далеко не все, і вам потрібно буде доводити безпеку усіх елементів системи. Але коли ви використовуєте AWS, у вас багато чого є або цілком із коробки (як наприклад вже сертифікована фізична безпека дата-центрів, енергопостачання в них, і т.п.), або не дуже складно налаштувати. Я розумію прекрасно, що PCI DSS це цілком окремий процес. Але сама наявніть цієї сертифікації буде використана як один із (багатьох) аргументів для інспекції.

Це Ви по досвіду чи просто придумали?

Мій досвід обмежений, бо той проект закрили до того як ми реально почали будь-які сертифікації. Тому як вже сказав, на 100% істину не претендую. Але я пам’ятаю що тоді я взнавав для клієнта, що без вже пройденої PCI DSS ми по факту не сможемо дотриматись GDPR.
GDPR ДУЖЕ занудний і вибагливий. Інша компанія, де я працював, займалась AdTech і нам треба було зберігати device ID (унікальний номер смартфона), то нам навіть із цього настільки промили мізки, що керівництво думало зупинити діяльність в ЄС. Що вже казати про номера карток.

я пам’ятаю що тоді я взнавав для клієнта, що без вже пройденої PCI DSS ми по факту не сможемо дотриматись GDPR.

Ні, це не правда. Ці два стандарти повністю різні. Наприклад PCI DSS по барабану географія, а GDPR вимагає щоб все було в Європі або довірених країнах.
Під час аудиту обов’язково виясняють чи є сертифікації по іншим фреймворкам але до уваги приймають тільки факти виключень :). Тобто питають чи були якісь виключення і як ви мітигували це. А так все йде назалежно.

Іще раз: я НЕ сперечаюся, що це цілком незалежно. Більше того, ви можете вже рік мати запущений бізнес наприклад як пеймент гейтвей. Ви маєте там, банк еквайр і домовленість із Visa / MasterCard і випускаєте свої gift cards (а ви краще за мене знаєте, що без PCI-DSS з вами з цього ніхто й розмовляти не стане). І тільки потім, через рік, проходити аудит на GDPR (але звичайно раніше краще).

GDPR вимагає щоб все було в Європі або довірених країнах

По-перше, це не зовсім корректно:
www.twilio.com/...​ocation-requirements.html

The general principle for transfers is outlined in Article 44, which can be summed up as saying, if you transfer EU personal data out of the EU, make sure that this data still enjoys the same level of protection it gets under GDPR.

, що може бути досягнено різними шляхами.

По-друге, це лише один (не самий великий) аспект. GDPR базується на 7 принципах, шостий з яких — Integrity and confidentiality: blog.ipswitch.com/gdpr-eu-personal-data

Цей пункт — конкретно про безпеку зберігання персональних даних. Як дуже добре каже ця сама стаття щодо того пункту:

The call for the use of „appropriate technical or organizational measures” is a little fuzzy, and it’s likely that GDPR’s author were purposefully vague in mandating security steps, as these technologies and best practices are in a constant state of change.

Without being too specific, the principle nevertheless encourages the use of well established best practices for cybersecurity — things like encrypting data in transit and at rest, using 2FA, and using tamper-evident logging to track who accesses data.

Тож як ви докажете, що ваші заходи із зберігання номерів карток — „appropriate technical or organizational”? Відповідь: тільки через уже наявні сертиіфікати імплементації відповідних всесвітньо визнаних стандартів.

По-перше, це не зовсім корректно:

В мене нема часу все розписувати.

Тож як ви докажете, що ваші заходи із зберігання номерів карток — «appropriate technical or organizational»?

Точно так само як і для всіх аудитів — демонструвати архітектуру, політики і процедури, evidences по списку :). Я проходжу аудити 2 рази на рік. Я це все бачу ;).

Я проходжу аудити 2 рази на рік. Я це все бачу ;).
Сертифікації по GDPR поки не проходили

???? Ну так, два аудити — PCI DSS і SOC2. Що не зрозуміло?

Так до чого тут аудити PCI DSS і SOC2? Я вам кажу про GDPR. Щоб довести «appropriate technical or organizational measures» для GDPR compliance конкретно в аспекті карток, легш за все вам буде показати вже пройдену сертифікацію PCI DSS, яка визнається в усьому світі і для якої ви вже зібрали evidences, інакше ви б її не пройшли.

Так, звичайно це не є явною вимогою. Але це зарахується як великий плюс і один великий evidence. І оскільки AWS надає велику частину з коробки, то з цим буде вже набагато легше стати GDPR compliant особливо для маленької фірми. Саме це намагався сказати автор статті.

Ну по-перше автор «статті» пише про Azure а не AWS:).
По-друге я Вам на прикладі SOC2 і PCI DSS вже цілу купу коментарів пояснюю що вони один одному ніяк не допомагають. Так само PCI DSS не має ані найменшого відношення до GDPR :).

В мене досвід з AWS, у автора з Azure. Втім, не думаю що один провайдер гірше за іншого саме в цьому питанні.

Я також цілу купу комнтарів пояснюю, яким саме чином вони пов’язані з GDPR, але ви не хочете мене почути.

У будь-якому разі, ми обоє говоримо про compliance, який жоден із нас проходив на практиці конкретно з даними про картки, і ми не можемо знати, чи їх проходив автор. Так що сперечатися далі немає сенсу.

Що не зрозуміло?

ото б я так клієнту сказав

GDPR не требует, чтобы безопасность обработки данных платежных карт особ EU была реализована с помощью PCI DSS

У вас у обоих формулировки расплывчатые, но по сути речь о необходимых и достаточных признаках.

Провайдери хмари зазвичай забезпечують хостинг та сертифікований PCI-DSS, що надзвичайно важливо для дотримання GDPR.
якщо не помиляюся, то в цьому нема помилки. Для проєктів, які зберігають або хоч якось маніпулюють номерами карток, рухунків, тощо, на бекенді, наявніть PCI-DSS використовується як стандарт імлементації data security, що є вимогою GDPR, і без цього сертифікацію не пройти
GDPR не требует, чтобы безопасность обработки данных платежных карт особ EU была реализована с помощью PCI DSS

расплывчатые формулировки? хм

Подписаться на комментарии