Віртуалізовані пропозиції працюють значно гірше (перегляньте мої експерименти 2019 року: httpsjan.rychter.com/enblog/cloud-server-cpu-performance і коштують дорожче. Різниця полягає в тому, що ви можете «масштабувати за вимогою», що, на мою думку, не є необхідним, принаймні в моєму випадку. І якщо мені потрібно масштабуватись, я все ще можу це зробити, просто отримання нових серверів займає години, а не секунди. Ну, мені не потрібно масштабуватись за секунди
У моєму випадку весь мій щомісячний рахунок за повне виробниче середовище та дублююче проміжне/очікувальне середовище є постійним, простим, передбачуваним, дуже низьким порівняно з тим, що мені потрібно було б платити AWS, і я все ще маю великий запас продуктивності
Одна річ, яку варто зазначити, полягає в тому, що я ставлюся до фізичних серверів так само, як до віртуальних: усім керую через ansible, і я можу відтворити все з нуля. Насправді я використовую інше середовище «devcloud» у Digital Ocean, і це середовище створено за допомогою terraform, а потім передано ansible, який виконує решту налаштувань
Я підозрюю, що VendorOps і такі складні інструменти, як kubernetes, віддають перевагу продавцям складності, які з’явилися за останнє десятиліття. Це чудово виглядає в резюме та дає технічним лідерам помилкове відчуття досягнення
Тим часом Stackoverflow, який, мабуть, важливіший за більшість стартапів, працює на виділених машинах
1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Здається, тенденція в цьому просторі полягає в тому, щоб перейти безпосередньо до найвищого рівня абстракції. Пропустіть основи та вкажіть на інструменти, бібліотеки та продукти $buzzword
Ви бачите проблиски цього в різних формах. Один із них – це теми соціальних мереж, які запитують про те, скільки X мені потрібно знати, щоб навчитися Y. Де X є фундаментальною, можливо, дуже стабільною технологією чи сферою діяльності, а Y – це якийсь інструмент, який дає змогу продовжити час, або просто продукт чи послуга.
CORBA належить туди. І, можливо, навіть семантична мережа. Однозначно XML!
XML — це чудово. Якщо ви в це не вірите, можливо, вас зацікавить розбір JSON: httpseriot.ch/projects/parsing_json.html
І не змушуйте мене починати з YAML..
Додаткові витрати на перебування в хмарі цілком варті того, щоб я мав керовані бази даних, автоматичні знімки, розміщені балансувальники навантаження, блокове сховище «plug and play» тощо
Я хочу хвилюватися про те, чи хороший наш продукт, а не про нічні збої апаратного забезпечення, запуск нового сервера, і він не працює належним чином, тому що не було стимулу використовувати керування конфігурацією з єдиним блоком, маючи єдине невдале завдання спричинити OOM або повний диск і зламати все, а не лише ці завдання VM, страх перед перезапуском машини, яка працювала 1000 днів тощо
Для мене привабливість хмари полягає не в моді масштабованості FAANG, коли вона не потрібна, а в автоматичному виправленні ОС, автоматичному балансуванні навантаження, службах NAT, централізованих журналах, які можна аналізувати, службах баз даних, якими мені не потрібно керувати поза межами оновлення служб, керування крипто-ключами та секретами та, звичайно, зберігання об’єктів. (Це все, що ми використовуємо в нашому стартапі)
Я б сказав, що виділені сервери можуть бути дуже життєздатними/рентабельними, коли ми досягнемо певного масштабу, а не навпаки. На даний момент витрати на хмару того варті для мого стартапу
Якщо ви робите конфігурацію свого середовища як код, зрештою, це не має значення, чи є ваша ціль виділеним сервером, віртуальною машиною чи деякими спеціальними налаштуваннями хмари, налаштованими через API
Насправді неважливо, який саме, справа в тому, що у вас є той, який може створити для вас нову коробку або повернути несправну коробку до нормального стану, просто виконавши команду
Звичайно, фактичну купу Go(o), яка керує цим, можна покращити (і вона справді покращується)
Тим не менш, сувора правда полягає в тому, що ваш підхід є правильним, майже всі підприємства (стартапи!) перебудовують, замість того, щоб зосереджуватися на забезпеченні цінності, визначенні фактичної ніші тощо. (Так, у цьому також є сторона попиту, оскільки Роздуті венчурні гроші стартапи надмірно будують, вони хочуть залежати від третіх сторін, які можуть взяти на себе навантаження, масштабуватись разом з ними, SLA та інше потрібно рекламувати.)
Kubernetes фантастичний! Щоразу, коли я бачу, що потенційно конкуруючий бізнес починає використовувати Kubernetes, я одразу відчуваю полегшення, оскільки я знаю, що мені більше не потрібно турбуватися про них. Вони ось-ось зникнуть у купі нерозв’язних технічних проблем, намагаючись вирішити проблеми, які неможливо відстежити в наборі технологій неймовірної складності, і обійти обмеження, накладені системою, розробленою для підприємств із трафіком у два-три рази більшим. Крім того, їхній COGS буде значно вищим, ніж мій, а це означає, що їм потрібно буде встановлювати вищу ціну на свій продукт, якщо тільки вони не витрачають гроші венчурного капіталу (у цьому випадку вони просто блискавка).
Хороші речі навколо
Анзибль є обов’язковим, він може працювати в напрямку статичного стану, і все. Якщо він стикається з проблемою, він скидає своє SSH-з’єднання, видає безліч помилок Python і здається назавжди. Навіть з його інвентарем це далеко не декларативно
k8s — це цикли керування, які намагаються просуватися до свого оголошеного стану. Помилка не є проблемою, буде повторена спроба. Він постійно перевірятиме власний стан, має гарний API, щоб повідомляти про це, і завдяки багатьом уточненим концепціям складніше мати дивні зіткнення між розгорнутими компонентами. (Тоді як інтеграція кількох ігор з Ansible не є тривіальною.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
І навіть якщо k8s надає занадто багато спадщини, є майбутні більш тонкі прояви основних ідей. (Наприклад, httpsgithub.com/aurae-runtime/aurae )
А тепер ви пропонуєте людям використовувати простішу нестандартну реалізацію?
Тож, звичайно, ви можете реалізувати рішення мінімальної складності або можете використати щось «готове»
k8s є складним, і деякі з них точно непотрібні для вашої ситуації, але він також досить загальний, гнучкий, добре підтримується тощо
>Ви пропонуєте людям використовувати простішу нестандартну реалізацію?
Я запропонував, що якщо проект/програмне забезпечення k8s стане занадто великим, щоб вийти з ладу, тоді люди можуть перейти до альтернативи. На щастя, концепції та API k8s мають відкритий вихідний код, тому їх можна реалізувати в інших проектах, і я навів такий приклад, щоб проілюструвати, що вибір k8s не є прив’язкою постачальника, як Oracle
Я завжди чую про всі чудові речі, які ви отримуєте практично безкоштовно від хмарних постачальників. Чи справді цей матеріал такий простий у налаштуванні та використанні? Кожного разу, коли я намагався налаштувати свій стек LAMP у хмарній службі, це був настільки заплутаний і лякаючий процес, що я здавався. Мені цікаво, чи потрібно мені просто натиснути трохи сильніше, і я потраплю до хмарного раю
Можливість сказати: «Мені потрібен кластеризований MySQL із такими специфікаціями» набагато краще (з точки зору часу), ніж робити це самостійно. Оновлення також добре загорнуті в систему, тому я просто кажу «застосуйте останнє оновлення», а не вручну гарантую, що перезавантаження/перезавантаження відбуваються в правильному порядку
Отже, ви платите за спрощення речей, але виграш від цього спрощення з’являється лише у великих проектах. Якщо у вас є щось на одному сервері, яке ви можете перезапустити, поки ваші користувачі отримують сторінку з помилкою, це може бути невартим
Хмара нелегка, але спроба отримати охолодження та енергоефективність невеликої серверної кімнати майже неможлива для публікації в більшості великих центрів обробки даних, як і підключення до Інтернету від багатьох постачальників
З хмарою все це зникає, оскільки нею керує будь-який оператор центру обробки даних, на якому ця хмара працює, але люди забувають, що це також вірно для старомодних служб спільного розміщення, які часто пропонують кращу вартість/вартість, ніж хмара
І хоча керувати такими речами, як AWS або Azure, безумовно, важче, тому що вони пропускають багато абстракцій, які невеликі постачальники vpc приховують від вас, або які ви насправді не отримуєте з одним домашнім сервером, це не складно в масштабі необхідності запускати пару серверів vmware зі сховищем на основі SAN З хмарними речами у вас є більше налаштувань, оскільки йдеться про налаштування віртуальних серверів тощо. Замість того, щоб носити ПК у коробці до кімнати, ви повинні «налаштувати його», щоб він був доступним Бази даних DO мають резервні копії, які ви можете налаштувати на свій смак, зберігайте їх у просторах DO (наприклад, S3). Керувати користувачами БД легко. Є також кеш-сервери для Redis Ви можете додати балансувальник навантаження та підключити його до різних веб-серверів Я думаю, що мені знадобилося близько 30 хвилин, щоб налаштувати 2x веб-сервери, сервер БД, сервер кешу, балансувальник навантаження, сервер зберігання та підключити їх усі за потреби за допомогою кількох простих форм. Не можу перемогти це Якщо у вас є додаткова інформація чи думки, поділіться Багато статей в Інтернеті про посилення безпеки сервера Linux, ті, які я пробував, займають трохи більше 30 хвилин, щоб виконати кроки, набагато довше, якщо я намагаюся насправді вивчити та зрозуміти, що робить кожна річ, чому важливо, яка вразливість лежить в основі, і як мені може знадобитися налаштувати деякі параметри для мого конкретного випадку використання Я впевнений, що ви можете знайти приклади сценаріїв налаштування в Інтернеті (налаштування автоматичних оновлень, брандмауера, програм тощо має відбуватися за допомогою «curl $URL», а потім «chmod +x $FILE» і «bash $FILE». Мені не потрібно було керувати конфігурацією (я використовую службу резервного копіювання свого постачальника, що, на мою думку, є важливим) Щось на зразок цього: httpsraw.githubusercontent.com/potts99/Linux-Post-Install.. (бачено на httpswww.reddit.com/r/selfhosted/comments/f18xi2/ubuntu_d) Очевидно, те саме можна сказати про довготривалі віртуальні машини, і це можна вирішити, якщо мати дисципліновану команду, але я думаю, що це більш імовірно в середовищі з однією довготривалою виділеною машиною Hetzner має все це, крім керованих баз даних httpswww.hetzner.com/managed-server Пакети веб-хостингу також включають 1..необмежену кількість БД (MySQL і PostgreSQL) httpswww.hetzner.com/webhosting/ чи має він автоматичне резервне копіювання та перемикання? >Якщо забронювати щоденне резервне копіювання або резервне копіювання, включене в тип сервера, резервне копіювання всіх даних створюється щодня та зберігається протягом максимум 14 днів. Відновлення резервних копій (Restore) можливе через інтерфейс адміністрування konsoleH Але у мене складається враження, що бази даних на керованих серверах призначені для використання програмами, які працюють на цьому сервері, тому насправді немає концепції відновлення після відмови httpswww.hetzner.com/legal/managed-server/ Збій одного диска на одному сервері ніколи не повинен спричиняти збій у виробництві Багато проблем із конфігурацією можна відстежити в автономному розгортанні. Чи справді цей файл шрифту або JRE потрібно інсталювати на всьому сервері чи ви можете додати його до свого розгортання У наших розгортаннях використовуються локальні цілі та цілі EC2. Сценарій розгортання нічим не відрізняється, лише IP для хоста Тепер я скажу, що якщо я можу використовувати S3 для чогось, я на 100% це зроблю. Для нього немає локальної альтернативи з таким же набором функцій Суть DevOps — «велика рогата худоба, а не домашні тварини». Раз на тиждень перевіряйте свій сервер, щоб знайти точки збою Я був би радий, якби ви перейшли до нашого Discord/Slack і повідомили про деякі проблеми, які ви бачили, щоб ми могли принаймні покращити досвід для інших користувачів Dokku. Не соромтеся вдарити мене там (мій нік «савант») Дозвольте мені передмовити і сказати, що я розробник додатків і маю лише практичні знання Docker.Я не надто досвідчений у інфраверсії, і програма, з якою мені було важко, має особливі параметри розгортання: це програма Python, яка під час збирання аналізує кілька гіґів статичного сканування HTML, щоб заповнити статичну базу даних Postgres після створення.Потім веб-програма Flask обслуговує цю базу даних.Синтаксичний аналіз HTML розвивається швидко, тому заповнені дані БД слід об’єднувати як частину образу(ів) програмиIIRC, мені було важко структурувати Dockerfiles, коли БД не було t постійний, а натомість просто ще одна тимчасова частина програми, але це здавалося подоланим.Здавалося, що більшою проблемою було те, як уникнути витягування кількостей рідко змінених даних із S3 для кожної збірки, коли в ідеалі вони мали б кешуватися, особливо таким чином, щоб поводитись розумно в DigitalOcean і моєму локальному середовищі.Я припускаю, що правильне кешування шару зображень Docker вирішить цю проблему, але я досить швидко досяг кінця своїх знань і терпінняDX Dokku здається чудовим для людей, які роблять звичайні речі .:)0. httpscoolify.io/Крім того, хто не хоче гратися з найновішою, найкрутішою іграшкою за чужі копійки?Безперечно є аргумент перенести (деякі) речі з хмари пізніше в подорожі, коли гнучкість (або робота з потоком/поворотом) стане менш основним фактором, а масштаб/вартість почнуть домінуватиЗвичайно, ви можете отримати щось, що працює на Hetzner, але будьте готові відповісти на багато інших запитаньПогодилися з вашою останньою думкою про це, що знову ж таки просто сумно, що цей бізнес "вимоги» визначають, як проектувати та розміщувати ваше програмне забезпечення, коли інший спосіб може виявитися набагато кращимАварійне відновлення є реальною проблемою.Ось чому я регулярно його тестую.У сценарії випаленої землі я можу запустити вторинну (проміжну) систему або тераформовану хмарну систему менш ніж за годину.Для мого бізнесу цього достатньо
Ми пережили бум зростання, і, як і всі раніше, це означало, що багато недосвідчених людей отримували багато грошей і невідкладних очікувань. Це рецепт культу карго та експлуататорського маркетингу
Але зростання сповільнюється, а гроші дорожчають, тож уповільніть темп і почніть заново вивчати старі уроки за допомогою нових захоплюючих варіацій. (Як тут: керування масштабуванням на голому металі та за допомогою контейнерів і оркестровки)
І весь цикл повториться в наступному бумі. Це поки що наша галузь
Надійний виділений сервер у 99% випадків набагато корисніший, ніж пошкоджений VPS на спільному обладнанні, але він, очевидно, коштує більше, якщо вам не потрібні всі ресурси, які вони надають.
Так, але прагнення «робити те, що зараз роблять усі круті діти» принаймні настільки ж сильне в тих, кого зазвичай називають «менеджерами», аніж у «працівниках».
результат A) величезні витрати на мікросервіси/хмару пішли не так, добре, принаймні, ви дотримувалися найкращих практик, таке трапляється, що ви можете зробити
результат B) ви перейшли на сервер Hetzner, але щось пішло не так, добре, і вам слід було використовувати мікросервіси, насолоджуйтесь пошуками нової роботи
Таким чином заохочуючи менеджерів обирати мікросервіси/хмару. Можливо, це не правильне рішення для компанії, але це правильне рішення для менеджера, і саме він приймає рішення
(Як і бути консультантом, який бажає розширення та написання програмного забезпечення, яке працює, як я з’ясував на важкому шляху.)
Існує розрив між засновниками та всіма іншими
Засновники вірять, що щороку вони збільшуватимуть більше ніж у 10 разів
Реальність така, що ймовірність їх поразки становить 90%.
У 90% випадків ви впораєтеся з невдачею
Деякий % із 10% випадків, коли ви досягаєте успіху, ви все ще добре обходитеся без хмари – принаймні протягом кількох років успіху, достатньо часу, щоб перейти, якщо колись знадобиться
У мене лише одне налаштування ansible, і воно може працювати як для віртуалізованих серверів, так і для фізичних. Без різниці. Єдина відмінність полягає в тому, що віртуалізовані сервери спочатку потрібно налаштувати за допомогою terraform, а фізичні — спочатку замовити та внести їхні IP-адреси у файл конфігурації (інвентар).
Звичайно, я також уникаю залежності від багатьох інших хмарних служб. Наприклад, я використовую VpnCloud (httpsgithub.com/dswd/vpncloud) для зв’язку між серверами. Як додаткову перевагу, це також дає мені можливість будь-коли переходити до будь-якого постачальника інфраструктури
Моя головна думка полягала в тому, що, хоча віртуалізовані пропозиції дійсно мають своє застосування, існує (велика) різниця між хобі-VPS за 10 доларів США на місяць і компанією зі стрімким зростанням бізнесу B2C. Більшість нових компаній насправді потрапляють у цю прогалину: ви не очікуєте експоненціального зростання хокейної ключки у прибутковому B2B SaaS. Ось тут ви повинні поставити під сумнів звичайний вибір за замовчуванням «використовувати AWS». Я дбаю про свій COGS і свою маржу, тому дуже уважно дивлюся на цей вибір
Ви не розробник програмного забезпечення, ви виготовляєте та продаєте Sprockets
Думки тут були б такі: найняти великого англ/ІТ-спеціаліста, щоб «купити та обслуговувати сервери» (PaaS — це погано), а потім, ймовірно, «написати код самостійно» (SaaS — це погано) або будь-що інше, що тут зараз популярно (остання тема тут була «Проштовхування PHP через SFTP без Git, і ви, якщо вам потрібно більше» lol)
Але я вважаю, що компанії повинні робити щось добре й уникати спроб конкурувати (роблячи це вручну) за речі, що не належать до їх основної компетенції. У цьому випадку я б точно вважав, що Sprocket Masters не повинні намагатися керувати своїм власним обладнанням і повинні покладатися на постачальника для вирішення масштабування, безпеки, часу безвідмовної роботи, відповідності та всіх дрібниць. Я також вважаю, що їхнє програмне забезпечення має бути стандартним із якомога меншою кількістю внутрішнього. Вони не є магазином програмного забезпечення і повинні писати якомога менше коду
Насправді Widget Masters могли б керувати цими сайтами з досить невеликим персоналом, якщо вони не вирішили робити все вручну, у такому випадку їм, ймовірно, знадобиться набагато більше персоналу
Однак те, що я також бачу, і те, про що, як мені здається, говорив попередній постер, — це підприємства, де технології є основою бізнесу, і там вони часто мають менший сенс, і замість того, щоб економити час, вони, здається, витрачають час. Є причина, чому існують експерти AWS: це не тривіально. «Справжні» сервери також не тривіальні, але й не обов’язково складніші за хмарні служби
Але ці агентства також не хочуть мати персонал для обслуговування фізичного обладнання.
Але Sprocket Masters все ще повинен мати дорогого хмарного консультанта, щоб просто реагувати на надзвичайні ситуації
Якщо ви збираєтеся мати когось із співробітників, який займатиметься проблемами хмари, ви можете замість цього орендувати сервер
Раніше я особисто використовував виділені сервери для нашого бізнесу, але в міру того, як ми розширювалися та масштабувалися, стало набагато простіше співпрацювати з хмарними постачальниками, щоб швидко надавати різноманітні послуги, навіть незважаючи на зростання витрат. Не кажучи вже про те, що набагато простіше сказати потенційному клієнту, що ви використовуєте «хмару, як AWS», ніж «О, ми орендуємо ці машини в центрі обробки даних, яким керує якась компанія» (що насправді може бути краще, але клієнти здебільшого цього не отримають) . Аудит, комплаєнс та інші
Для багатьох навіть набагато менше. Я запускаю невеликий побічний проект [1], який кілька разів ставав вірусним (приблизно 30 тисяч переглядів за 24 години), і він працює на одноядерному веб-сервері ЦП і керованому Postgres також на одному ядрі ЦП. Він навіть не був близький до повного використання
1: httpsaihelperbot.com/ Чи можу я переключити деякі з них на лямбда-функції? Або перейти на ECS? Або перейти на інший хмарний сервіс du jour? Може бути. Але кількість часу, який я витратив на написання цього коментаря, вже становить приблизно шість місяців економії для такого перемикання. Якщо це складніше, ніж «натисніть кнопку, отримайте послугу зі 100% надійним перекладом», це важко виправдати Частково це також тому, що хмара тепер надає деякі інші служби, які дозволяють такі речі. Мені не потрібно запускати кластер Kafka для базового обміну повідомленнями, усі вони мають шину повідомлень. Я використовую це. Я використовую параметри розміщеної БД. Я використовую S3 або еквівалент тощо. Я вважаю, що те, що залишилося, майже не варте клопоту про те, щоб спробувати втиснути себе в якусь іншу парадигму, коли я плачу однозначну цифру доларів на місяць просто за роботу на екземплярі EC2 Абсолютно так, що не кожен або не кожен проект може це зробити. Я не ставлю це як кінцеву мету. Якщо це не працює, я негайно вживаю відповідних заходів щодо масштабування. Я не пропоную вам перебудувати щось на основі цього. Я просто кажу, що це не варіант, щоб тебе зневажали. У ньому дуже багато гнучкості, а виставлення рахунків досить послідовне (або, інакше кажучи, той факт, що якщо я раптом маю 50-кратний трафік, моя система починає задихатися та відчутно бризкати, а не просто стягувати з мене сотні доларів більше для мене є функцією, а не помилкою), і ви, як правило, не намагаєтеся спотворити якусь парадигму, яка зручна для деяких хмарних служб, але може бути незручною для вас Вам коли-небудь доводилося керувати одним із цих середовищ? Річ у тім, що якщо ви хочете отримати деяку базову масштабованість для більш ніж однієї людини та належну програму devops, тоді вам доведеться перевиділяти суттєвий фактор (можливо, позбавляючи ваших заощаджень) Ви неминуче отримаєте індивідуальне рішення, а це означає, що новим співробітникам буде важче освоїти систему, а значні люди, які залишають компанію, принесуть із собою свої глибокі знання про вашу інфраструктуру. Ви повернулися до домашніх тварин замість худоби. Деякі сервери є особливими, через деякий час автоматизація означає «багато склеювальних сценаріїв оболонки тут і там», а оновлення ОС означає, що або половина infra на деякий час є KO, або ви взагалі не оновлюєте ОС А в щасливому випадку вам доведеться збільшити масштаб. Ви можете зустріти неприємні сюрпризи І ніколи не змушуйте мене починати з мережевого боку. Якщо ви не орендуєте всю стійку та не розміщуєте власне мережеве обладнання, ви отримуєте те, що отримуєте. Що може бути дуже поганим у функціональності чи продуктивності, якщо припустити, що ви не робите нічого фантастичного Якщо ви хочете 100,0000% безвідмовної роботи, звичайно. Але ви зазвичай цього не робите. Компанії, які хочуть такого часу безвідмовної роботи, зазвичай мають команди, які займаються цим І масштабування також добре працює на «голому металі», якщо ви масштабуєте вертикально. Ви хоч уявляєте, яку потужність і пропускну здатність можна отримати від одного сервера? Тривожно постійно чути про "масштабування", коли спікер має на увазі "горизонтальне масштабування" Якщо ваші вимоги "масштабування", то вертикальне масштабування заведе вас далеко Якщо ваші вимоги – «горизонтальне масштабування за вимогою», то, звичайно, хмарні провайдери допоможуть у цьому. Але небагато місць потребують такого масштабування Я не кажу, що 100% безвідмовна робота на голому металі дешева, я кажу, що 100% безвідмовна робота часто не потрібна Оскільки галузь повна людей, які женуться за тенденціями та ключовими словами, і для яких найважливіше додати ці ключові слова до резюме IME, спрямований на масштабованість, є надзвичайно неправильним для більшості служб/програм/що завгодно. І зазвичай ви платите стільки накладних витрат за «масштабовані» рішення, що потім вам потрібно масштабувати, щоб компенсувати це Я дуже сумніваюся в цьому.Єдина тема, яку ви бачите у майже кожного прихильника AWS, — це велика кількість оман щодо того, які гарантії AWS насправді надає вамТак, звичайно.Нікого не звільняють за покупку в IBMЯкби великі компанії мали хоч якусь компетентність у прийнятті рішень, вони були б непереможними, і було б безнадійно працювати над чимось іншим все.Отже, так, це суспільне благоДжерело: майже тридцять років роботиПоки що я не помічав, що витрачаю більше для компанії, що мені також платять більшеотримання еквівалентної надійності за допомогою заліза набагато дорожче, ніж оренда «двох виділених серверів» – тепер вам може підійти один сервер і рішення для резервного копіювання , і це справедливо. але sysad для створення всього цього, навіть за короткого контракту на початкове налаштування та без обслуговування, значно перевершить різницю в ціні хмари, особливо якщо в комплексі є база даних і ви дбаєте про ці даніСьогодні хмара схожа – час виходу на ринок відбувається швидше, оскільки менше рухомих частин.Коли економіка падає, а зростання сповільнюється, лічильники бобів приходять і роблять свою справуЦе відбувається щоразуЦе тільки робить AWS багатшим у компаніях і хмарних командахТривіально надати та скасувати надання екземпляра EC2 автоматично протягом декількох секунд, якщо ваше розгортання потребує збільшення або зменшення масштабу.Ось що принципово відрізняє його від сервера без використання
Тепер я не заперечую, що, порівняно з AWS, може бути рентабельніше надати трохи більше виділених серверів, ніж вам потрібно, але коли у вас справді непередбачуване робоче навантаження, непросто встигати
якщо ви розкручуєте та вимикаєте віртуальні машини, щоб відповідати кривій попиту, щось серйозно не так із вашою архітектурою
Вам коли-небудь приходило в голову, чому stackoverflow використовує ~8 виділених серверів для обслуговування всього світу і йому не потрібно запускати та вимикати віртуальні машини, щоб задовольнити глобальний попит клієнтів?
--
Плануючи обчислювальну інфраструктуру, важливо повернутися до основ і не піддаватися пропаганді хмарних постачальників
Ви самі сказали. Не всі програми повинні обслуговувати весь світ, тому попит буде нижчим, коли люди лягатимуть спати
Навіть щодо глобальних програм існують правила, які вимагають розміщення програм і даних у певних регіонах. Уявіть собі програму, якою користуються клієнти в Європі, Австралії та США. Їх потрібно обслуговувати з регіональних центрів обробки даних, і один кластер буде здебільшого спати, коли інший працює (через часові пояси). З виділеними серверами ви витратите 60-70% своїх ресурсів, а використовуючи щось на зразок EC2/Fargate, ви можете зменшити масштаб майже до 0, коли ваш регіон спить
Є метод до божевілля, тут це називається «розвиток, керований безпекою роботи»
Тому що це загроза їхнім роботам
Є ціла група людей, які мають технічну підготовку для самостійного розміщення або розміщення невеликих випадків для своєї родини/друзів/асоціації/клубу походів. Ця невелика маржа, на яку можна витратити трохи більше, тому що ви хочете зробити це належним чином, але ви не можете виправдати стільки платити та витрачати час на важке обслуговування. Невеликий VPS зі спільним Nextcloud або невеликим веб-сайтом — це все, що потрібно в багатьох випадках
Для цього я навіть використовую маленький Raspberry Pi 400 у своїй спальні
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
Я сам розміщував свої власні речі вже близько десяти років. Ніхто не пробував DDoSing моєї установки, бо навіщо їм? Яку вигоду вони могли б отримати від цього? Я був би майже єдиною людиною, яка постраждала, і як тільки вони припиняться, відновлення не займе багато часу
Практично немає жодного стимулу для DDoS в особистій скриньці, не кажучи вже про рандо в Інтернеті
Ви різко переоцінюєте здібності підлітка
Просто перевірка IP-адреси знову і знову нічого не дасть. Можливо, це DoS-атака, залежно від того, що цільова мережа має з точки зору IPS, але навіть тоді ймовірніше, що вони заразять свої комп’ютери вірусами, перш ніж отримають шанс фактично атакувати вас
Я особисто потрапив під кінець одного з них за якогось чітера в GTA 5. Це точно трапляється, і це не весело
Редагувати: Схоже, це може бути автоматично. Це щось цікаве, на що я повинен трохи придивитися. Можливо, це просто додаткова складність для мого маленького сервера, але я маю на увазі деякі способи використання
Технічно моя домашня лабораторія також працює на статичній загальнодоступній IP-адресі — це була радше вправа «чи зможу я це зробити», ніж «дійсно необхідно», але це все одно круто, і я дуже щасливий
Приблизно єдине зависання полягало в тому, що мені довелося налаштувати Wireguard, щоб підтримувати роботу тунелю, інакше іноді VPS отримував би вхідний трафік, і якби моя лабораторія деякий час не зв’язувалася (навіщо це?), тунель не працював би, і проксі-з'єднання буде. На щастя, це вбудована функція
Отже, схоже, що додати канали RSS/Atom на сайт сторінок jekyll або GitHub досить просто
1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..
3. httpspages.github.com/versions/
atom 2c/4t, 4gb ram, 1tb накопичувач, 100мбіт
Кілька років безвідмовної роботи на даний момент
Якщо безперервно: може знадобитися деяке оновлення.
Оновлення безпеки ядра - це річ
Я виявив, що Atom нестерпно повільний, навіть з Linux. Звичайно, цього достатньо для обслуговування веб-сайтів тощо, але дивно, скільки енергії вони використовують, але не працюють
точно. Ці екземпляри VPS вартістю до 10 доларів чудово підходять для невеликих проектів, де ви не хочете укладати тривалі контракти чи мати справу з керуванням власними серверами
Якщо ви ведете справжню компанію, де маржа надзвичайно мала, і у вас є весь вільний час у світі, щоб вирішувати проблеми з сервером, якщо (коли) вони виникнуть, ці виділені сервери ~50 доларів можуть бути цікавими для вивчення
Але якщо ви ведете справжній бізнес, навіть рахунок AWS у розмірі 10 000 доларів США на місяць буде дешевшим, ніж найняти іншого кваліфікованого розробника, який допоможе керувати вашими виділеними серверами
Це те, що зазвичай упускають у дискусіях про витрати на хмару в таких місцях, як HN: Так, хмара дорога, але найняти навіть одного додаткового системного адміністратора/розробника, щоб допомогти вам керувати спеціальною інфраструктурою, неймовірно дорого та набагато менш гнучко. Ось чому витратити гіпотетичні 5000 доларів США на місяць на рішення, розміщене в хмарі, яке теоретично можна створити на сервері вартістю 50 доларів США на місяць із достатніми інвестиціями часу, усе ще може бути великою ціною. Інженери дорогі, а час обмежений
Ой, вибачте, але скільки ви платите цьому DevOps? Це виглядає як дуже американська перспектива, навіть у долині. В Європі найняти хлопця було б дешевше
Повністю завантажені витрати на працевлаштування значно вищі, ніж те, що ви берете додому у своїй зарплаті. Насправді в Європі гірше. Подивіться на ці діаграми: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Якщо ви платите комусь 1000 євро у Великій Британії, це коштує компанії загалом 1245 євро
Якщо ви заплатите комусь 1000 євро в Румунії, це обійдеться компанії загалом у 1747 євро
Таким чином, повна вартість у 120 000 доларів США може принести лише 68 000 доларів США на зарплату для спеціаліста з ЄС
Але ви не можете мати лише одну людину devops. Вам потрібно принаймні 2, якщо ви хочете дозволити одному з них колись відпочити, або піти у відпустку
Я можу підключити вас приблизно через 3 години
AWS є дуже економічно ефективним для інших служб (S3, SES, SQS тощо), але віртуальні машини не є гарною угодою. Ви отримуєте менше оперативної пам’яті& ЦП, з накладними витратами на віртуалізацію, і платять набагато більше грошей
Особливо для Postgres, якщо ви запустите деякі тести за допомогою pgbench, ви дійсно побачите штраф, який ви платите за віртуалізацію
Можливо, навички системного адміністратора щодо створення власної інфраструктури стають втраченим мистецтвом, інакше я не можу пояснити, чому людям так подобається платити в 5 разів за меншу продуктивність
Hetzner дешевий і надійний у Європі, якщо ви в Північній Америці, подивіться на OVH. Особливо їх економічна альтернатива під назвою SoYouStart. Ви можете придбати 4/8 4,5 ГГц, 64 RAM і накопичувач NVME за 65 доларів США
(Я не маю зв’язку з OVH, я просто клієнт із майже 100 серверами, і це чудово для мене)
Я також зазначу, що я старий, хе-хе, і однією з моїх перших робіт у нас був центр обробки даних пристойного розміру. Робота з мережами SAN, стрічковими накопичувачами (автоматичні обертачі стрічок у той час були серверами тощо) була величезною PITA. Пакування стрічок і відправка їх до іншого офісу для резервування місця завжди було цікавим.
Конкретна програма, якою я керую, дійсно страждає від низького ГГц і не має всіх даних у пам’яті. Я проводив контрольні тести на EC2, деякі звіти, які закінчуються приблизно за 5 секунд, можуть зайняти більше хвилини на порівнянному екземплярі EC2, який коштує приблизно в 10 разів дорожче. Цій програмі дійсно потрібен необроблений процесор. і так, у нас є досить велика команда інженерів, яка оптимізувала всі запити, індекси тощо
Що стосується реплікації, резервного копіювання тощо, я все це налаштував, і, чесно кажучи, це не було великою проблемою. Це кілька коротких розділів у книзі Postgres, які дуже просто пояснюють усе, як налаштувати, постійно (і автоматично) тестувати тощо
Я згоден, що SAN – це кошмар. Ось чому я відправляю всі свої WAL (файли резервного копіювання PG) до S3 (і, зрештою, до Glacier). Таким чином мені не доведеться думати про втрату цих файлів, і це дуже дешево
Я вважаю, що існує помилкова думка, що такі конфігурації надто складні для налаштування одним інженером і потребують нескінченного обслуговування. Насправді ви можете налаштувати все це менш ніж за тиждень, і воно справді потребує обслуговування лише тоді, коли ви хочете оновити Postgres (деякі налаштування можуть бути змінені). За моєю оцінкою, на технічне обслуговування потрібно близько 5 годин на рік
Здається, що інфраструктура самообслуговування стане дедалі життєздатнішою, оскільки ми продовжуємо вдосконалювати доставку «останньої милі» та розширювати доступ до оптоволокна. Чи стане хмара самоканібалістською? Однозначно можливо
Хмара дає вам можливість розташувати свої дані/робоче навантаження прямо в центрі без необхідності укладати спеціальні угоди з місцевим провайдером і з набагато більшою стійкістю, ніж ви б, ймовірно, дозволили, якщо ваш принаймні 20-футовий контейнер не заповнений масштаб серверів обчислювальних потреб
httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Редагувати: якщо хтось зацікавлений у самостійному розміщенні, це просто з cloudflared. У мене є Google Pixelbook 2017 року, на якому працює Ubuntu на власному мікропрограмному забезпеченні, яке обслуговує веб-сайт на основі Flask. Iton мій стіл заряджається під час підключення до гостьової мережі Wi-Fi. Він отримує оцінку Mobile PageSpeed 100/100 і займає 0,8 секунди для повного завантаження
Від DO я отримую всі переваги надійної компанії, масштабованість, автоматичне резервне копіювання тощо. Я б ні за що не змінився
Хмара Хетцнер тепер має дві локації в США. Проте виділених серверів у США все ще немає - це було б справжньою справою. Навіть якщо їхні поточні хмарні пропозиції самі по собі вже становлять ~30% ціни основних хмарних еквівалентів.
Як і ви, я також запускаю свої послуги з орендованого фізичного сервера. Раніше я користувався Versaweb, але їхні машини занадто старі. Мені раніше не подобалися Hetzner, тому що я чув погані речі про те, що вони втручаються у те, чим ви керуєте
Однак я переїхав до них у грудні, коли мій екземпляр Versaweb щойно помер, ймовірно, SSD від старості. Зараз я плачу 50% від того, що заплатив Versaweb, і можу запустити 6 таких екземплярів Postgres
Потім виникає питання, чи варто платити 700 доларів із 800 доларів за керовану послугу з чудовим хмарним інтерфейсом користувача, автоматичними оновленнями та резервним копіюванням тощо.
Я думаю, що ні для шоу з 1 людиною чи невеликого стартапу. Дешевше використовувати доступну службу та створювати резервні копії на S3 або щось дешевше
Компанія, у якій я працював у компанії А, отримувала в чотири рази більше, ніж компанія Б, лише тому, що компанія А хотіла щоквартально надсилати рахунки-фактури у спосіб, який добре вписувався в нашу систему виставлення рахунків. Для компаній економія кількох сотень доларів тут і там часто не вартує клопоту, пов’язаного із запровадженням будь-якого додаткового тертя
Там є непряма вартість. Якщо це лише одна або дві з цих речей, просто скористайтеся керованими послугами
Якщо ви починаєте масштабувати роботу, знайдіть працівника адміністратора, щоб заощадити на цьому
Інакше мені довелося б найняти/укласти контракт з кимось із дуже досвідом або присвятити цілий місяць чи більше свого часу (який був недоступний), просто щоб бути на 100% впевненими, що ми завжди можемо швидко відновити резервні копії журналу PITR
Я можу значно заощадити на витратах на хмару в інших місцях, але надійний керований PostgreSQL був досить простим рішенням (навіть якщо початкова ціна була вищою, ніж ви очікували)
Ранній стартап, який не може дозволити собі втратити годину виробничих даних, імовірно, занадто крихкий, щоб вижити
Це ранній запуск – будуть більші перебої в роботі служби, і будь-які клієнти, які втечуть після одногодинної втрати виробничих даних, просто не оцінять продукт достатньо.
(У конкретному стартапі, про який я думав, у мене вже було кілька гарних автоматичних частих онлайн-дампів бази даних до S3 із примусовим збереженням, але я не вважав, що це достатньо для цього конкретного сценарію. Але я не впевнений, що ми можемо відновити за допомогою PITR/журналування додало б нову точку невдачі на успіх бізнесу, який інакше міг би мати вихід із 9+ цифр за кілька/кілька років, просто щоб заощадити кілька сотень.)
Крім того, я припускаю, що деякі з перших стартапів, які мають менш вибагливі потреби, але невибагливо ставляться до своїх зобов’язань щодо даних клієнтів/користувачів, все ще недбало щодо мінімальних базових практик
Можливо, один інтуїтивно зрозумілий спосіб оцінити: уявіть бізнес-новину на HN, про деякі стартапи, які перебувають у питанні, додавши імена засновників стартапу, і в матеріалі сказано, що вони не мали хороших резервних копій. Тоді один із Співзасновники, які, можливо, не спали, оскільки їхня компанія руйнується навколо них, відповідають: «Дані клієнта не такі важливі на ранньому стартапі; якби вони були, ми були б надто крихкими» (надруковано до того, як співзасновник міг викинути ноутбук цієї людини через кімнату, щоб вони не друкували). Це було б погано
Я розповім про це в кінці
>Уявіть собі бізнес-новину на HN, яка розповідає про деякі стартап-операції, імена засновників стартапу додаються, і в матеріалі сказано, що вони не мали хороших резервних копій
ITYM, і виявилося, що у них не було резервного копіювання за останню годину
Я можу уявити все у вашому сценарії, навіть невідрізані біти, і все це здається нормальним, якщо ви не читаєте «Наші клієнти-стартапи, які користувалися нами протягом місяця, усі одразу пішли, коли ми втратили останню годину їхніх даних».
Я дійсно не можу уявити такий сценарій
Тепер, звичайно, є деякі підприємства, де перевага використання полягає в тому, що немає навіть години втрати даних
IOW, клієнти використовують його, тому що він не втрачає жодних даних: наприклад, онлайн-спільна робота над документами[1][2]. Якщо у вас стався збій, який втрачає годину останніх введених даних, тоді, звичайно, очікуйте, що всі постраждалі поточні користувачі негайно втечуть
[1] Хоча особисто я б зменшив ризик, скопіювавши поточний документ у локальному сховищі під час його редагування
[2] Можливо, фондовій біржі також потрібна система, щоб зберігати останню годину даних? Що ще?
Я думаю, що навіть для великих команд може мати сенс самостійно керувати базами даних, припускаючи, що у вас є відповідні навички. Є так багато речей, які можуть піти не так з керованими службами, і вони не приховують базову реалізацію так, як це роблять такі речі, як блокове сховище або сховище об’єктів
Пікова продуктивність, безумовно, гірша, але мене не надто турбує, якщо щось довше працює. Ви, безумовно, маєте рацію, коли маєте стільки автоматизації в ініціалізації сервера, чого я не робив із фізичним сервером
Раніше я мав кореневий сервер для своїх улюблених проектів, але, чесно кажучи, це не має сенсу. У мене немає великого трафіку, обчислюйте інтенсивні SaaS на своїх машинах. Це просто статичний сайт і кілька проектів. Я скорочуся до 24 щомісячних витрат, які включають ящик для зберігання 1 ТБ для зберігання всіх моїх даних
Основна проблема в будь-якому сценарії, пов’язаному з реальним апаратним забезпеченням, полягає в тому, що вам потрібен персонал, який володіє як апаратним забезпеченням, так і системами Linux/UNIX. Багато стверджують, що є в їхніх резюме, а потім не можуть працювати один раз на роботі (принаймні з мого досвіду). На мій погляд, однією з головних причин вибуху хмарного світу була саме складність створення та фінансова вартість створення таких команд. Крім того, існує дещо природне (і необхідне) протиріччя між розробниками додатків і системниками. Спеціалісти з систем завжди повинні відштовхуватись і наполягати на більшій безпеці, більшій кількості процесів і меншій кількості розгортань. Команда розробників завжди має наполягати на більшій гнучкості, більшій кількості випусків і меншій кількості процесів. Хороший менеджмент має бути середнім шляхом між ними. На жаль, некомпетентні менеджери часто просто вирішують позбутися системних людей і перенести речі на землю AWS
Нарешті, я хотів би лише зауважити, що хмарна архітектура шкідлива для планети, оскільки вимагає надмірного забезпечення з боку хмарних провайдерів, а також вимагає більшої загальної потужності комп’ютера через багато рівнів абстракції. Хоча будь-який проект несе відповідальність за незначну частину цих відходів, уся глобальна хмара як сукупність є дуже марнотратною. Це мене непокоїть і, очевидно, впливає на емоційну упередженість у моїх поглядах (так велика кількість солі для всього вищесказаного)
Можна стверджувати, що ви можете розробити засоби для оренди фізичних серверів до отримання прибутку, а потім, коли це буде доцільно, ви можете використовувати стандартну амортизацію - або - Розділ 179 щодо прямої покупки та/або Розділ 179 оренди
Як приклад, ви можете розгорнути неймовірно ефективну групу, скажімо, з чотирьох абсолютно повністю забезпечених фізичних машин 1U вартістю 100 тис. доларів США в різних кольорах для резервування. Тут є всі види хитрощів для балансування навантаження та відновлення після відмови за допомогою хмарної служби XYZ, DNS, будь-якої передачі, що завгодно. Ви можете працювати з різними центрами обробки даних по всьому світу, відправляти обладнання від постачальника до них, а потім забезпечувати їх Ansible або будь-яким іншим, навіть не бачачи об’єктів і не торкаючись обладнання
Отже, тепер у вас є надлишкове фізичне обладнання, яке буде працювати навколо більшості хмарних постачальників (особливо для вводу-виводу), фіксовані витрати, як-от уся доступна пропускна здатність (яка не має 800% розмітки хмарних служб тощо) – більше не потрібно чекати за неминучий рахунок у хмарі в розмірі 50 тисяч доларів США або спроба відстежити (в паніці), що спричинило перевищення налаштованого хмарного бюджету за день замість місяця. О, до речі, ви не замикаєтеся в безглуздих фірмових API, щоб надавати та навіть використовувати послуги, відмінні від віртуальних машин, які пропонує $BIGCLOUD
Якщо ви виконуєте будь-яку програму машинного навчання, ви можете потренуватися на власному апаратному забезпеченні чи (або випадковій хмарі) і виконувати висновки 24/7 за допомогою таких речей, як NVIDIA A10. Безперервна оренда хмари для екземплярів графічного процесора неймовірно дорога, а рентабельність інвестицій у придбання апаратного забезпечення зазвичай становить кілька місяців (або майже відразу з Розділом 179). Як приклад, нещодавно я провів порівняльний тест із Nvidia A10 для моделі, яку ми обслуговуємо, і він може виконати понад 700 запитів на висновок/с у FP32 із затримкою менше 10 мс. З одним A10 на шасі в чотирьох справних екземплярах це 2800 запитів/с (і, ймовірно, може бути налаштовано додатково)
Тоді, якщо ви станете ДІЙСНО великими, ви зможете почати встановлювати шафи та більше. З точки зору апаратних збоїв, як уже згадувалося, все, що я можу сказати, це подвійний PS RAID-вихід, тощо, апаратне забезпечення (з мого досвіду) надзвичайно надійне. У минулому було кілька повних апаратних шаф, збоїв апаратного забезпечення було небагато, і апаратне забезпечення постачальники включатимуть неймовірні SLA для заміни. Ви сповіщаєте їх про невдачу, вони надсилають техніка< вісім годин безпосередньо в колокольничний центр і замініть диск, PS тощо з миготливим світлом
Мій досвід показує, що один (хороший) ресурс FTE може легко керувати цим до масштабу кількох кабінетів. На вашу думку, поточна проблема полягає в тому, що багатьох із цих людей пограбували великі хмарні провайдери та замінили (на ринку) ресурсами, які можуть переміщатися через граничну безглуздість використання десятків (якщо не більше) продуктів/послуг від $ BIGCLOUD
Я також виявив, що ця конфігурація НАБАГАТО надійніша за більшість $BIGCLOUD. Більше не потрібно думати, що відбувається з відключенням $BIGCLOUD, про який вони навіть не визнають (і яке ви абсолютно не можете контролювати). Оскільки я працював у сфері телекомунікацій та охорони здоров’я, для мене абсолютно дивно, як час безвідмовної роботи насправді став набагато гіршим із хмарними провайдерами. Зазвичай ви можете просто сказати клієнтам: «О, сьогодні проблеми з Інтернетом», тому що вони, ймовірно, побачать заголовки про це, але для багатьох програм це абсолютно неприйнятно, і ми повинні очікувати кращого
[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Якщо я хочу запустити новий проект або спробувати розмістити щось нове, це займає кілька хвилин, і я маю сценарії. Розгортання відбувається швидко, обслуговування невелике, і я маю набагато більше за свої гроші
Для всіх, хто цікавиться, це приблизний розріз того, що я використовую:
* Можливість керувати всім
* Трохи терраформування для деяких записів DNS, які я можу колись замінити
* restic для резервних копій, знову ж таки під контролем ansible
* tailscale для vpn (у мене вдома працює кілька pi, нічого особливого, окрім tailscale, це легко та безпечно)
* docker-compose майже для всього іншого
Основною програмою є Clojure, тому я запускаю рідну JVM. База даних повністю розподілена, RethinkDB, зараз працює над переходом до FoundationDB
Важливо не керувати нічим вручну, напр. ставитися до фізичних серверів так само, як до будь-якого іншого хмарного сервера. Немає значення, фізичний він чи віртуалізований
Я бачив багато менш досвідчених людей, які переплачували за Hetzner і подібні речі, коли 5-10 доларів США за секунду спрацювали б
Так, на даний момент ви підтримуєте власне обладнання. Ні, це не сильний головний біль
Найбільша додаткова вартість – це оренда більшої кількості адрес IPv4, яку Hetzner стягує дуже дорого, оскільки їх так мало доступних
Усе, що ви створите, почнеться з 0 користувачів, і ціла реальна машина є абсолютно надмірною для цього 0 навантаження, яке ви отримаєте. Ви оновлюєте свій VPS до пари реальних машин, потім до невеликого орендованого кластера, а потім до центру обробки даних (якщо хтось не підриває його). Усі вони мають передбачувані рахунки та найвищу продуктивність за свою ціну
Усе, що у вас є в коло, також буде більше на місяць. Коли у мене були з’єднання, за які я міг платити за статичну IP-адресу, це зазвичай становило 5 доларів США на місяць
Зараз я орендую досить недорогий сервер, але це 30 доларів на місяць. Набагато все, що мені потрібно, але це приємно. І вони не припинили підтримку моєї ОС, підвищивши ціни, щоб покращити підтримку чи щось подібне. (Хоч у мене було спочатку несправне обладнання, яке потрібно було замінити)
як ви зазначили, голий метал – це шлях. це працює протилежно хмарі – трохи більше роботи на початку, але набагато менше витрат у кінці
Більше інформації httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
Налаштувати Postgres і керувати ним – справа непроста. Було б непогано мати простіший спосіб зробити все правильно
1. Робить конфігурацію відтворюваною, оскільки віртуальні машини вимикаються
2. Ви можете отримати великі знижки на AWS, які зменшують біль
3. Інші речі, до яких ви маєте доступ на вершині віртуальних машин, що дешевше/швидше, коли ваші речі вже знаходяться в хмарі
4. Легше мати задокументовану конфігурацію системи (наприклад, документи AWS), ніж навчати людей/документувати, які особливі речі у вас є всередині. Особливо корисно під час найму нових людей
5. Вам не потрібне місце або резервне живлення/інтернет/тощо на території. Достатньо, щоб люди могли запускати свої ноутбуки
До цього я користувався VPS, але зупинився та перейшов на фізичний, оскільки це була краща угода, і ми не зіткнулися з обмеженнями ЦП
Хоча моніторинг диска не надто складний. Для жорстких дисків запускайте smartctl раз на годину, сповіщайте, коли перерозподілені або очікувані сектори швидко зростають або досягають 100. Для SSD схрестіть пальці; з мого досвіду роботи з кількома тисячами, вони, як правило, чудово працюють, поки не зникнуть з автобуса, щоб їх більше ніколи не побачити. Майте план відновлення даних, який не передбачає зберігання даних на тих самих моделях пристроїв із дуже однаковою потужністю увімкнено.
Зрештою, у Hetzner є API для замовлення виділених серверів, а також API для встановлення ОС (або для перезавантаження для відновлення та перепрошивки будь-якого зображення, яке ви хочете)
Гадаю, якби я досліджував комерційні варіанти, я б відсортував «багажник» в офісі з комерційним рішенням провайдера, статичною IP-адресою, можливо, хорошим ІТ-обладнанням, але з того, що я знаю на даний момент, якщо клієнту потрібен був хостинг, я б d завжди переходити відразу до оренди vps
У той час я був скоріше молодшим розробником, тож, можливо, й був, але я зовсім не сумую за цим. Теоретично я погоджуюся з тим, що ви говорите, але розгорнути Dockerfile у щось на зразок Google Cloud Run набагато простіше. Так, я плачу більше, ніж керував би власним VPS, але я думаю, що це з лишком компенсується заощадженими годинами розробників
- фізичне обладнання має проблеми, напр. збій вентилятора ->мою віртуальну машину в реальному часі перенесено на інший хост, я не помічаю та не хвилююсь
- фізичне обладнання вибухає ->моя віртуальна машина перезапускається на іншому хості, я можу помітити, але мені байдуже
Планування на випадок лиха набагато простіше з віртуальними машинами (навіть з домашніми тваринами, а не з худобою)
Для новачка найдешевші зроблять роботу
Я впевнений, що з розвитком хмарних обчислень ці пропозиції стають все більш поширеними
Є ще один аспект хмарних обчислень. Середні та великі корпорації розраховують хмарні обчислення як однозначні відсотки у своїх розрахунках витрат. Це означає, що рішення, прийняті менеджерами та командами, часто шукають надійність і масштабованість (щоб розмістити їх у своїх презентаціях), а не "моє налаштування дороге чи дешеве"Мій роботодавець прийняв хмару як бізнес/фінансову гру, а не релігійну. Ми часто розміщуємо нові збірки в хмарі та переносимо їх до центру обробки даних пізніше
Встановлені програми коштують приблизно на 40% дешевше. Програми, які економічно ефективніші в хмарі, залишаються там
Я вважаю, що AWS/GCP/Azure не є дуже конкурентоспроможними пропозиціями в Європі. Я не бачу доказів цього для США
для тієї ж специфікації, звичайно. Я вважаю, що віртуальні об’єкти мають сенс з обох сторін – або динамічна масштабованість для великого N важлива, або вам потрібна лише невелика частка фізичної коробки. Платити 45/місяць за те, що працює find на 5/міс також нерозумно, і це дає вам більше гнучкості, щоб не об’єднувати речі разом лише для використання вашого сервера
Зберігайте резервні копії в будь-якому випадку. Бажано в іншого провайдера або принаймні в іншому фізичному місці. І, звичайно, перевірити їх
І якщо ви керуєте хорошим режимом резервного копіювання та все одно відстежуєте свої дані/програму, чи є моніторинг дисків значними додатковими труднощами?
--
[1] насправді, якщо ви автоматизуєте процес відновлення в іншому місці, що я роблю для кількох своїх бітів, тоді ви можете просто натиснути цю кнопку та оновити DNS після завершення, і, можливо, виділити трохи більше оперативної пам’яті та ядер (мій тест дзеркала менші за живі віртуальні машини, оскільки їм не потрібно обслуговувати шаблони реального використання)
Саме те, що я роблю для себе та своїх клієнтів. Економить тонни дошу
Навіть якби я захотів оновити, це просто витягнення останньої версії в шаблон докер-компонування та повторний запуск ansible playbook. Очевидно, якщо для оновлення потрібно більше, нехай так і буде, але це не відрізняється від будь-якої іншої роботи з налаштування
Ймовірно, єдине, що мені _потрібно_ зробити вручну, це перевірити свої резервні копії. Але у мене є сценарій для кожного проекту, який це робить, тому я просто вмикаю SSH, запускаю одностроковий код, перевіряю результат і готово. Я роблю це приблизно раз на місяць або близько того, але я також отримую електронні листи, якщо резервне копіювання не вдається
Так що часу взагалі не може бути. Зазвичай це, мабуть, 1-2 години на місяць, якщо я отримую оновлення на напіврегулярній основі. Але це буде масштабуватися з більшою кількістю речей, які ви розміщуєте та керуєте
Іншими словами, єдина різниця полягає в тому, звідки походить файл інвентаризації ansible. Або це статичний список IP-адрес, або він походить від terraform
Якщо вам потрібна оперативна пам’ять ECC, це, здається, 60 на місяць, а також посилюється до більш потужного 8-ядерного ЦП
Незважаючи на це, якщо ми говоримо про «повне виробниче середовище та дубльоване проміжне/очікувальне середовище» (якщо цитувати особу, якій ви відповіли), то 60/місяць * (2 або 3) все ще дуже дешево порівняно з AWS будь-якого стартапу. рахунок, який я бачив
Випадки використання відрізняються, але я погоджуюсь, що AWS/GCP/Azure не є відповіддю на всі проблеми
Для тих, хто може розмістити свою програму на VPS вартістю 4 долари, це, очевидно, буде дешевше, ніж будь-що з голого металу, але масштабування хмари в багатьох випадках коштує дуже дорого. Голий метал також не є відповіддю на всі проблеми, але багато людей у галузі, здається, не розуміють, коли це може бути правильною відповіддю.
ВІРТУАЛЬНІ ПРИВАТНІ СЕРВЕРИ №120
