Сколько вы можете получить от VPS за 4 доллара?

 Виртуализированные предложения работают значительно хуже (см. мои эксперименты 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: httpserriot.ch/projects/parsing_json.html
И не заводи меня на YAML..

Дополнительные затраты на использование облака полностью окупаются для меня наличием управляемых баз данных, автоматических моментальных снимков, размещенных балансировщиков нагрузки, блочного хранилища plug and play и т. д.
Я хочу беспокоиться о том, хорош ли наш продукт, а не о сбоях оборудования посреди ночи, раскручивании нового сервера и его неправильной работе, потому что не было стимула использовать управление конфигурацией с одним блоком, имея единственную неуправляемую задачу. вызвать OOM или полный диск и сломать все, а не только эту виртуальную машину задач, боязнь перезапустить машину, которая работала 1000 дней и т. д.

Для меня привлекательность облака заключается не в какой-то прихоти FAANG с масштабируемостью, когда это не требуется, а в автоматическом исправлении ОС, автоматической балансировке нагрузки, службах NAT, централизованных, анализируемых журналах, службах баз данных, которыми мне не нужно управлять, из пошаговое обновление сервисов, управление крипто-ключами и секретами и, конечно же, хранилище объектов. (Это все, что мы используем в нашем стартапе)
Я бы рискнул и сказал, что выделенные серверы могут быть очень жизнеспособными/рентабельными, когда мы достигнем определенного масштаба, а не наоборот. На данный момент затраты на облако того стоят для моего стартапа.

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

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

Конечно, реальную кучу Go(o), которая управляет ею, можно улучшить (и она действительно улучшается).

Тем не менее, суровая правда заключается в том, что ваш подход является правильным, почти все предприятия (стартапы!) перестраиваются вместо того, чтобы сосредоточиться на обеспечении ценности, определении фактической ниши и т. д. (Да, здесь также есть сторона спроса, поскольку Стартапы, раздутые венчурными деньгами, перестраиваются, они хотят зависеть от третьих сторон, которые могут взять на себя нагрузку, масштабироваться вместе с ними, соглашения об уровне обслуживания и многое другое нужно рекламировать.)
Kubernetes — это фантастика! Всякий раз, когда я вижу, что потенциально конкурирующий бизнес начинает использовать Kubernetes, я сразу же испытываю облегчение, так как знаю, что мне больше не нужно о них беспокоиться. Они вот-вот исчезнут в куче неразрешимых технических проблем, пытаясь решить проблемы, которые невозможно отследить в технологическом стеке невероятной сложности, и обходить ограничения, наложенные системой, предназначенной для предприятий с трафиком в два-три раза больше. Кроме того, их COGS будет намного выше, чем у меня, а это значит, что им нужно будет устанавливать более высокую цену на свой продукт, если только они не прожигают деньги венчурного капитала (в этом случае они просто блестят).

Хорошие вещи вокруг

Ansible императивен, он может работать в статическом состоянии, вот и все. Если он сталкивается с проблемой, он разрывает SSH-соединение, выдает тонны ошибок Python и сдается навсегда. Даже со своим инвентарем это далеко не декларативно
k8s — это один из циклов управления, которые пытаются приблизиться к заявленному состоянию. Сбой не проблема, он попытается повторить. Он будет постоянно проверять свое собственное состояние, у него есть хороший API, чтобы сообщать об этом, и благодаря большому количеству материализованных концепций сложнее иметь странные конфликты между развернутыми компонентами. (В то время как интеграция нескольких плейбуков с Ansible не является тривиальной задачей.)
httpsgithub.com/spantaleev/matrix-docker-ansible-развертывание
И даже если 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/управляемый-сервер Пакеты веб-хостинга также включают 1..неограниченное количество БД (MySQL и PostgreSQL) httpswww.hetzner.com/веб-хостинг/ у него есть автоматическое резервное копирование и отказоустойчивость? >При забронированном ежедневном резервном копировании или резервном копировании, включенном в тип сервера, все данные резервируются ежедневно и хранятся не более 14 дней. Восстановление резервных копий (Restore) возможно через интерфейс администрирования konsoleH  Но у меня сложилось впечатление, что базы данных на управляемых серверах предназначены для использования приложениями, работающими на этом сервере, поэтому на самом деле не существует концепции аварийного переключения.  httpswww.hetzner.com/legal/managed-server/ Отказ одного диска на одном сервере никогда не должен приводить к остановке производства.  Многие проблемы с конфигурацией можно отследить до автономных развертываний. Действительно ли этот файл шрифта или JRE нужно устанавливать на весь сервер или вы можете включить его в свое развертывание?  В наших развертываниях используются локальные цели и цели EC2. Сценарий развертывания ничем не отличается, меняется только IP-адрес хоста.  Теперь я скажу, могу ли я использовать S3 для чего-то, что я сделаю на 100%. Для него нет локальной альтернативы с тем же набором функций.  Суть DevOps — «Скот, а не домашние животные». Ставьте пулю на свой сервер раз в неделю, чтобы найти точки отказа  Я был бы рад, если бы вы заглянули в наш Discord/Slack и рассказали о некоторых проблемах, с которыми вы сталкивались, чтобы мы могли, по крайней мере, сделать работу с Dokku лучше для других. Не стесняйтесь бить меня там (мой ник `savant`)  Позвольте мне в предисловии сказать, что я разработчик приложений и знаю Docker только на практике.Я не очень хорошо разбираюсь в инфраструктуре, и приложение, с которым я столкнулся, имеет специфические параметры развертывания: это приложение Python, которое во время сборки анализирует несколько гигабайтов статических обходов HTML для заполнения базы данных Postgres, статической после сборки. Затем веб-приложение Flask работает с этой базой данных. Синтаксический анализ HTML развивается быстро, поэтому заполненные данные БД должны быть объединены как часть изображений приложения.  IIRC, я изо всех сил пытался структурировать файлы Docker, когда БД не была постоянной, а была просто еще одной временной частью приложения, но это казалось преодолимым. Более серьезная проблема, казалось, заключалась в том, как избежать загрузки редко изменяемых данных из S3 для каждой сборки, когда в идеале они должны быть кэшированы, особенно таким образом, который разумно ведет себя в DigitalOcean и в моей локальной среде. Я предполагаю, что правильное кэширование слоя изображения Docker решит проблему, но я довольно быстро достиг предела своих знаний и терпения.  DX от Dokku отлично подходит для людей, занимающихся обычными делами. :) 0. httpscoolify.io/ Кроме того, кто не хочет играть с новейшей, самой крутой игрушкой за чужие деньги? Определенно есть аргумент в пользу переноса (некоторых) вещей из облака на более позднем этапе пути, когда гибкость (или работа с потоком/поворотом) перестанет быть основным фактором, а масштаб/затраты начнут доминировать.  Конечно, вы можете заставить что-то работать с Hetzner, но будьте готовы ответить на гораздо больше вопросов.  Согласен с вашим последним вопросом о том, что предприятие просит об этом, что опять же просто грустно, что эти бизнес-«требования» диктуют, как спроектировать и разместить ваше программное обеспечение, когда другой способ может быть намного лучше. Аварийное восстановление — очень реальная проблема. Вот почему я регулярно тестирую его. В сценарии выжженной земли я могу настроить и запустить вторичную (промежуточную) систему или терраформированную облачную систему менее чем за час. Для моего бизнеса этого достаточно 
Мы пережили бум роста, и, как и все они раньше, это означало, что многие неопытные люди получили много денег и неотложных ожиданий. Это рецепт культивирования грузов и эксплуататорского маркетинга.

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

Надежный выделенный сервер в 99% случаев гораздо полезнее, чем хромой VPS на общем оборудовании, но очевидно, что он обходится дороже, если вам не нужны все ресурсы, которые они предоставляют.

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

Результат А) огромные расходы на микросервисы/облако идут не так, ну, по крайней мере, вы следовали передовым методам, такие вещи случаются, что вы можете сделать

результат B) вы выбрали сервер Hetzner, но что-то пошло не так, ну, вы должны были использовать микросервисы, наслаждайтесь поиском новой работы.

Таким образом побуждая менеджеров выбирать микросервисы/облако. Это может быть неправильным решением для компании, но это правильное решение для менеджера, и именно менеджер принимает решение.

(Как и быть консультантом, желающим получить расширение и написать работающее программное обеспечение, как я понял на собственном горьком опыте.)
Существует разрыв между основателями и всеми остальными

Основатели считают, что они будут >10x каждый год

Реальность такова, что они с вероятностью 90% потерпят неудачу.

90% времени - вы ничего не терпите

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

У меня есть только одна настройка ansible, и она может работать как для виртуализированных серверов, так и для физических. Нет разницы. Единственная разница в том, что виртуальные серверы сначала нужно настроить с помощью terraform, а физические — сначала заказать, а их IP-адреса внести в конфигурационный файл (инвентарь).

Конечно, я также стараюсь не зависеть от многих других облачных сервисов. Например, я использую VpnCloud (httpsgithub.com/dswd/vpncloud) для связи между серверами. В качестве дополнительного преимущества это также дает мне возможность переключаться на любого поставщика инфраструктуры в любое время.
Моя главная мысль заключалась в том, что, хотя у виртуализированных предложений есть свое применение, существует (огромный) разрыв между VPS для хобби за 10 долларов в месяц и компанией с быстрорастущим бизнесом B2C. Большинство новых предприятий фактически попадают в этот разрыв: вы не ожидаете экспоненциального роста хоккейной клюшки в прибыльной B2B SaaS. Вот где вы должны подвергнуть сомнению обычный выбор по умолчанию «использовать AWS». Я забочусь о своих себестоимости и марже, поэтому я очень внимательно отношусь к этому выбору.

Вы не софтверная компания, по сути, вы производите и продаете Sprockets.

Мнения здесь будут такими: нанять большой инженерный/ИТ-персонал для «покупки и обслуживания серверов» (PaaS — это плохо), а затем, вероятно, «самостоятельно написать код» (SaaS — это плохо) или что-то еще, что в настоящее время популярно здесь (последняя тема здесь была «Проталкивание PHP через SFTP без Git, и вам нужно больше», лол)
Но я считаю, что предприятия должны делать «Одно дело хорошо» и избегать попыток конкурировать (делать это вручную) в вещах, выходящих за рамки их основной компетенции. В этом случае я определенно думаю, что Sprocket Masters не должны пытаться управлять своим собственным оборудованием и должны полагаться на поставщика для решения проблем масштабирования, безопасности, времени безотказной работы, соответствия и всех мелких деталей. Я также думаю, что их программное обеспечение должно быть стандартным и иметь как можно меньше внутренних ресурсов. Они не магазин программного обеспечения и должны писать как можно меньше кода.

Реально Widget Masters могли бы управлять этими сайтами с довольно небольшим персоналом, если бы они не решили делать все это вручную, и в этом случае им, вероятно, потребовался бы гораздо больший персонал.

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

Но эти агентства также не хотят иметь персонал для обслуживания физического оборудования.

Но Sprocket Masters по-прежнему должен иметь дорогого консультанта по облачным вычислениям просто для того, чтобы реагировать на чрезвычайные ситуации.

Если вы собираетесь иметь кого-то в штате для решения проблем с облаком, вы можете вместо этого арендовать сервер.

Раньше я лично запускал выделенные серверы для нашего бизнеса, но по мере того, как мы расширялись и масштабировались, стало намного проще обращаться к облачным провайдерам для быстрого предоставления различных услуг, даже несмотря на то, что затраты выросли. Не говоря уже о том, что гораздо проще сказать потенциальному клиенту, что вы используете «облако, подобное AWS», чем «О, мы арендуем эти машины в центре обработки данных, которым управляет какая-то компания» (что на самом деле может быть лучше, но клиенты в основном этого не поймут). . Аудит, комплаенс и другие

Для многих даже намного меньше. Я запускаю небольшой побочный проект [1], который несколько раз становился вирусным (30 тысяч просмотров за 24 часа или около того), и он работает на одноядерном веб-сервере ЦП и управляемом Postgres на одном ядре ЦП. Он даже не был близок к полному использованию
1: httpsaihelperbot.com/Могу ли я переключить некоторые из них на лямбда-функции?Или перейти на ECS?Или перейти на другой облачный сервис в ближайшее время?Возможно.Но количество времени, которое я потратил на написание этого комментария, уже составляет примерно шестимесячную экономию на такой переход.Если это сложнее, чем "нажми кнопку, получи услугу со 100% надежным переводом", это трудно оправдатьЧастично это также потому, что облако теперь предоставляет некоторые другие услуги, которые позволяют такие вещи.Мне не нужно запускать кластер Kafka для базового обмена сообщениями, все они поставляются с шиной сообщений.Я использую это.Я использую параметры размещенной БД.Я использую S3 или аналогичный и т. д.Я считаю, что то, что осталось, едва ли стоит хлопот, связанных с попытками втиснуть себя в какую-то другую парадигму, когда я плачу однозначную цифру. долларов в месяц только за то, чтобы работать на экземпляре EC2Совершенно верно, что не каждый или каждый проект может это сделать.Я не зацикливаюсь на этом как на конечной цели.Когда это не работает, я немедленно предпринимаю соответствующие действия по масштабированию.Я не предлагаю вам что-либо перепроектировать на основе этого.Я просто говорю, что пренебрегать этим нельзя.В нем много гибкости, и биллинг вполне консистентный (или, говоря по-другому, тот факт, что если у меня вдруг в 50 раз больше трафика, моя система начинает довольно заметно захлебываться и чихать чем просто брать с меня дополнительные сотни долларов, для меня это фича, а не баг), и вы, как правило, не напрягаетесь, чтобы извратиться в какую-то парадигму, удобную для какого-то облачного сервиса, но может быть неудобную для васПриходилось ли вам когда-нибудь управлять одной из этих сред?Дело в том, что если вы хотите получить некоторую базовую масштабируемость более чем для одного человека и надлежащую devops, вам придется значительно увеличить запасы (возможно, лишив ваших сбережений)Вы неизбежно получите индивидуальное решение, а это означает, что новым сотрудникам будет труднее освоить систему, а важные люди, покидающие компанию, принесут с собой свои глубокие знания вашей инфраструктуры. их.Вы вернулись к домашним животным вместо крупного рогатого скота.Некоторые серверы особенные, через некоторое время автоматизация означает "множество скриптов клеевой оболочки тут и там", а обновление ОС означает, что либо половина инфры какое-то время не работает, либо вы не обновляете ОС в любое время. всеИ, в лучшем случае, вам нужно масштабироваться. Вас могут ожидать неприятные сюрпризыИ никогда не получить я начал на стороне сети.Если вы не арендуете всю стойку и не размещаете собственное сетевое оборудование, вы получаете то, что получаете.Который может быть очень беден как с точки зрения функциональности, так и производительности. Если предположить, что вы не делаете ничего необычногоЕсли вы хотите 100,0000% времени безотказной работы, конечно.Но обычно это не так.Компании, которые хотят такой продолжительности безотказной работы, обычно имеют специальные команды для этогоИ масштабирование также хорошо работает на «голом железе», если вы масштабируете вертикально — Вы хоть представляете, сколько энергии и пропускной способности можно получить от одного сервера?Постоянно слышать о "масштабировании", когда говорящий имеет в виду "горизонтальное масштабирование"Если вы требуете "масштабирование", то вертикальное масштабирование будет увести вас далекоЕсли ваши требования - "горизонтальное масштабирование по требованию", то, конечно, облачные провайдеры помогут в этом.Но мало где требуется такое масштабированиеЯ не говорю, что 100% время безотказной работы на голом железе дешево, я говорю 100% время безотказной работы часто не требуетсяПотому что в отрасли полно людей, которые гонятся за тенденциями и ключевыми словами, и для которых самое главное добавить эти ключевые слова в резюмеIME, стремящийся к масштабируемости, крайне неверен для большинства сервисов/приложений/чего угодно.И обычно вы платите так много накладных расходов за «масштабируемые» решения, что затем вам нужно масштабировать, чтобы компенсировать этоЯ действительно сомневаюсь в этом. .Единственная тема, которую вы видите почти у каждого сторонника AWS, — это большое количество заблуждений относительно того, какие гарантии AWS на самом деле предоставляет вамДа, конечно.Никого не увольняют за покупку у IBMЧто ж, если бы крупные компании обладали компетенцией в принятии решений, они были бы непобедимы, и было бы безнадежно работать над чем-то еще в все.Итак, да, это общественное благоИсточник: почти тридцать лет работыПока я не заметил, что если я потрачу больше для компании, в которой мне тоже платят большеполучение эквивалентной надежности с железом намного дороже, чем аренда «двух выделенных серверов» - теперь вам может хватить одного сервера и решения для резервного копирования , и это справедливо. но системный администратор для создания всего этого, даже с коротким контрактом на первоначальную настройку и отсутствие обслуживания, выйдет далеко за рамки разницы в цене облака, особенно если в миксе есть база данных, и вы заботитесь об этих данныхСегодня облачные технологии аналогичны — время выхода на рынок сокращается, поскольку в них меньше движущихся частей.Когда экономика падает и рост замедляется, приходят счетчики бобов и делают свое делоЭто происходит каждый разЭто только делает AWS богаче в компаниях и облачных командахАвтоматически инициализировать и отменить инициализацию инстанса EC2 в течение нескольких секунд, если развертывание необходимо увеличить или уменьшить, тривиально.Это то, что принципиально отличает его от сервера на «голом железе»
Теперь я не отрицаю, что по сравнению с AWS может быть более экономически выгодно выделить несколько дополнительных выделенных серверов, чем вам нужно, но когда у вас действительно непредсказуемые рабочие нагрузки, не так просто идти в ногу.

если вы запускаете и выключаете виртуальные машины, чтобы удовлетворить кривую спроса - что-то серьезно не так с вашей архитектурой

Вам никогда не приходило в голову, почему stackoverflow использует ~8 выделенных серверов для обслуживания всего мира и не требует запуска и отключения виртуальных машин для удовлетворения глобального спроса клиентов?
--
При планировании вычислительной инфраструктуры важно вернуться к основам и не поддаваться пропаганде поставщиков облачных услуг.
Ты сам это сказал. Не все приложения должны обслуживать весь мир, поэтому спрос будет ниже, когда люди ложатся спать.

Даже с глобальными приложениями существуют правила, которые требуют, чтобы вы размещали приложения и данные в определенных регионах. Представьте себе приложение, которым пользуются клиенты в Европе, Австралии и США. Они должны обслуживаться из региональных центров обработки данных, и один кластер будет в основном спать, когда другой работает (из-за часовых поясов). С выделенными серверами вы бы потратили впустую 60-70% своих ресурсов, а используя что-то вроде EC2/Fargate, вы можете масштабироваться почти до 0, когда ваш регион спит.

Есть метод безумия, здесь он называется «развитие, ориентированное на безопасность работы».

Потому что это угроза их работе

Есть целая группа людей, у которых есть технические возможности для самостоятельного размещения или проведения небольших мероприятий для своей семьи/друзей/ассоциации/туристического клуба. Это небольшая маржа, когда вы можете потратить немного больше, потому что хотите сделать это правильно, но вы не можете оправдать платить так много и тратить время на тяжелое техническое обслуживание. Небольшой VPS с общим Nextcloud или небольшим веб-сайтом — это все, что нужно во многих случаях.

Для этого я даже использую маленькую Raspberry Pi 400 в своей спальне.

httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..

Я сам размещал свои собственные вещи уже почти десять лет. Никто не пробовал использовать DDoS для моей установки, потому что зачем им это? Какую пользу они извлекут из этого? Я был бы почти единственным затронутым человеком, и как только они остановятся, восстановление не займет много времени.

Практически нет стимула для DDoS-атак в личном ящике, не говоря уже о интернет-рандо.

Вы резко переоцениваете способности подростка

Простое пингование IP снова и снова мало что даст. Может быть, DoS-атака, в зависимости от того, что имеет целевая сеть с точки зрения IPS, но даже в этом случае более вероятно, что они заразят свои компьютеры вирусами, прежде чем у них появится шанс на самом деле атаковать вас.

Я лично был на стороне одного из тех, кто каким-то образом отключил читер в GTA 5. Такое определенно случается, и это не весело.
 Изменить: похоже, это может быть автоматическим. Это что-то интересное, я должен изучить немного. Вероятно, это просто дополнительная сложность для моего маленького сервера, но у меня есть несколько вариантов использования.

Технически моя домашняя лаборатория также находится на статическом общедоступном IP-адресе — это было больше упражнением в «могу ли я это сделать», чем «на самом деле необходимо», но это все еще круто, и я очень счастлив

Единственным зависанием было то, что мне пришлось настроить Wireguard, чтобы поддерживать туннель в рабочем состоянии, иначе иногда VPS получал бы входящий трафик, и если бы моя лаборатория не связалась некоторое время (что, с чего бы это?), туннель не работал, и прокси-соединение будет. К счастью, это встроенная функция

Итак, кажется, что добавление каналов RSS/Atom на сайт jekyll или GitHub pages довольно просто.

1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..

3. httpspages.github.com/versions/
атом 2с/4т, 4гб ОЗУ, 1тб диск, 100мбит
Несколько лет безотказной работы на данный момент
Если не прерывается: может потребоваться некоторое обновление.
Обновления безопасности ядра — это вещь


Я обнаружил, что Atoms невыносимо медленный, даже с 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 в ЕС.

Но у вас не может быть только одного devops-специалиста. Вам нужно как минимум 2, если вы хотите, чтобы один из них когда-либо делал перерыв, ге или уезжал в отпуск.

Я могу подключить вас примерно через 3 часа

AWS очень экономичен для других сервисов (S3, SES, SQS и т. д.), но виртуальные машины не очень выгодны. Вы получаете меньше оперативной памяти& ЦП, с накладными расходами на виртуализацию, и платить намного больше денег

Специально для Postgres, если вы запустите несколько тестов с pgbench, вы действительно увидите штраф, который вы платите за виртуализацию.

Возможно, умение системного администратора создавать собственную инфраструктуру становится утраченным искусством, иначе я не могу объяснить, почему люди так любят платить в 5 раз меньше за меньшую производительность.

Hetzner дешев и надежен в Европе, если вы находитесь в Северной Америке, посмотрите на OVH. Особенно их экономичная альтернатива под названием SoYouStart. Вы можете получить 4/8 4,5 ГГц, 64 ОЗУ и диск NVME за 65 долларов.

(Я не имею никакого отношения к OVH, я просто клиент с почти 100 серверами, и у меня это отлично сработало)
Я также отмечу, что я стар, хе-хе, и одной из моих первых работ у нас был центр обработки данных приличного размера на месте. Работа с SAN, ленточными накопителями (автоматическими ротаторами лент в то время, серверами и т. д.) была огромным PITA. Упаковывать ленты и отправлять их в другой офис для резервирования местоположения всегда было весело.

Конкретное приложение, которым я управляю, действительно страдает от низкой частоты ГГц и отсутствия всех данных в памяти. Я провел тесты на EC2, некоторые отчеты, которые завершаются примерно через 5 секунд, могут занять больше минуты на сопоставимом экземпляре EC2, который стоит примерно в 10 раз дороже. Это приложение действительно нуждается в необработанном процессоре. и да, у нас есть довольно большая команда инженеров, которая оптимизировала все запросы, Ãndices и т. д.

Что касается репликации, резервного копирования и т. д. Я все это настроил, и, честно говоря, это не имело большого значения. Это пара коротких глав в книге Postgres, в которых все очень просто объясняется, как настраивать, непрерывно (и автоматически) тестировать и т. д.

Я согласен, что SAN — это кошмар. Вот почему я отправляю все свои WAL (файлы резервных копий PG) на S3 (и, в конечном итоге, на Glacier). Таким образом, мне не нужно думать о потере этих файлов, и это очень дешево.

Я думаю, что существует ошибочное мнение, что такие конфигурации слишком сложны для настройки одним инженером и требуют бесконечного обслуживания. На самом деле вы можете настроить все это менее чем за неделю, и оно действительно нуждается в обслуживании только тогда, когда вы хотите обновить Postgres (некоторые настройки могли измениться). По моим оценкам, на техническое обслуживание уходит около 5 часов в год.

Инфраструктура самообслуживания, вероятно, станет все более жизнеспособной, поскольку мы продолжаем улучшать доставку последней мили и расширять доступ к оптоволокну. Станет ли облако самоуничтожающимся? Безусловно, может быть

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

httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..

Редактировать: Если кто-то заинтересован в самостоятельном размещении, это просто с облачным хостингом. У меня есть Google Pixelbook 2017 года с Ubuntu на специальной прошивке, которая обслуживает веб-сайт на основе Flask. Мой рабочий стол заряжается при подключении к гостевой сети Wi-Fi. Он получает 100/100 баллов Mobile PageSpeed ​​и занимает 0,8 секунды для полной загрузки.

От DO я получаю все преимущества надежной компании, масштабируемость, автоматическое резервное копирование и т. д. и т. д. Я бы ни за что не изменился

Облако Hetzner теперь имеет два офиса в США. Тем не менее, выделенных серверов в США нет — это было бы реально. Даже если сами их текущие облачные предложения уже составляют примерно 30% от цены основных облачных эквивалентов.

Как и вы, я запускаю свои сервисы с арендованного физического сервера. Раньше я использовал Versaweb, но их машины слишком старые. Раньше мне не нравился Hetzner, потому что я слышал плохие отзывы о том, что они мешают тому, что вы делаете.

Однако я перешел на них в декабре, когда мой инстанс Versaweb только что умер, наверное, SSD от старости. Теперь я плачу 50% от того, что я заплатил Versaweb, и я могу запустить 6 таких экземпляров Postgres.

Тогда возникает вопрос, стоит ли платить 700 из 800 долларов за управляемую услугу с причудливым облачным интерфейсом, автоматическими обновлениями и резервными копиями и т. д.

Для шоу из 1 человека или небольшого стартапа, я думаю, нет. Дешевле воспользоваться доступным сервисом и скидывать бэкапы на S3 или что-то подешевле

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

Там есть неявная стоимость. Если это только одна или две из этих вещей, просто возьмите управляемые услуги.

Если вы начнете масштабироваться, получите администратора типа сотрудника, чтобы сэкономить на этом
В противном случае мне пришлось бы нанять / нанять кого-то очень опытного или посвятить целый месяц или больше своего времени (которого не было), просто чтобы быть на 100% уверенным, что мы всегда можем быстро восстановить журналируемые резервные копии PITR.

Я могу сэкономить на облачных затратах в других местах, но надежный управляемый PostgreSQL был довольно простым вызовом (даже если ценник начального уровня был больше, чем вы ожидали)

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

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

(В конкретном запуске, о котором я думал, у меня уже было несколько хороших автоматических частых дампов DB-online на S3 с принудительным хранением, но я не думал, что это достаточно хорошо для этого конкретного сценария. Но я не был уверен, что мы сможем восстановить с помощью PITR/журналирование добавит новую единственную точку отказа в ставке на успех бизнеса, который в противном случае мог бы иметь 9-значный выход через несколько/несколько лет, просто чтобы сэкономить несколько сотен.)
Кроме того, я полагаю, что некоторые из ранних стартапов, которые имеют менее требовательные потребности, но небрежно относятся к своим обязательствам в отношении данных клиентов/пользователей, все еще небрежно относятся к минимальным базовым практикам.

Может быть, один интуитивный способ оценить: представьте себе новость о бизнесе на HN, о некоторых операциях по запуску, брошенных мячом, с прикрепленными именами основателей стартапа, и история говорит, и оказывается, что у них не было хороших резервных копий. Затем один из соучредители, которые, возможно, не спали много, поскольку их компания терпит крах, отвечают: «Данные о клиентах не так важны на раннем этапе стартапа; если бы это было так, мы были бы слишком хрупкими» (напечатано до того, как соучредитель смог бросить ноутбук этого человека через всю комнату, чтобы они не печатали). Это было бы не очень хорошо

Я обращусь к этому в конце

>Представьте себе новость о бизнесе на HN, о некоторых операциях со стартапами, с прикрепленными именами основателей стартапов, и в статье говорится, и оказывается, что у них не было хороших резервных копий.

ITYM, и оказалось, что у них не было резервной копии последнего часа
Я могу представить все в вашем сценарии, даже неотрезанные биты, и все это кажется нормальным, если только вы не прочтете «Наши стартап-клиенты, которые использовали нас в течение месяца, все сразу же ушли, когда мы потеряли последний час их данных»

Я действительно не могу представить этот сценарий

Теперь, конечно, есть некоторые предприятия, где преимущество его использования заключается в том, что нет даже часа потерянных данных.
IOW, клиенты используют его, потому что он не потеряет никаких данных: например, совместная работа над документами в Интернете[1][2]. Если у вас произошел сбой, который потерял час последних введенных данных, то, конечно, ожидайте, что все затронутые текущие пользователи немедленно сбегут.

[1] Хотя лично я бы снизил риск, продублировав текущий документ в локальном хранилище, пока он редактируется.

[2] Может быть, фондовой бирже тоже нужна система для хранения данных за последний час? Что еще?
Я думаю, что даже для больших команд может иметь смысл самостоятельно управлять базами данных, если у вас есть компетентность, чтобы делать это хорошо. Есть так много вещей, которые могут пойти не так с управляемыми службами, и они не скрывают базовую реализацию, как это делают такие вещи, как блочное хранилище или хранилище объектов.

Пиковая производительность, безусловно, хуже, но меня не слишком беспокоит, если что-то все равно работает дольше. Вы, безусловно, правы в том, что у вас такая же автоматизация при подготовке сервера, чего я не делал с физическим сервером.

Раньше у меня был корневой сервер для моих домашних проектов, но, честно говоря, это не имеет смысла. Я не пользуюсь большим трафиком, интенсивные вычисления SaaS на моих машинах. Это просто статический сайт и несколько проектов. Я сократил ежемесячные расходы до 24, включая хранилище объемом 1 ТБ для хранения всех моих данных.

Основная проблема в любом сценарии, связанном с реальным оборудованием, заключается в том, что вам нужен персонал, компетентный как в аппаратном обеспечении, так и в системах Linux/UNIX. Многие утверждают, что они указаны в их резюме, а затем не могут работать ни разу на работе (во всяком случае, по моему опыту). На мой взгляд, одной из основных причин взрыва облачного мира была именно сложность построения и финансовые затраты на создание таких команд. Кроме того, существуют естественные (и необходимые) разногласия между разработчиками приложений и системщиками. Системщики всегда должны возражать и настаивать на большей безопасности, большем количестве процессов и меньшем количестве развертываний. Команда разработчиков всегда должна добиваться большей гибкости, большего количества релизов и меньшего количества процессов. В таком случае хороший менеджмент должен найти срединный путь между ними. К сожалению, некомпетентные менеджеры часто просто решают избавиться от системных специалистов и перенести все на землю AWS.

Наконец, я хотел бы только отметить, что облачная архитектура вредна для планеты, поскольку она требует чрезмерного выделения ресурсов облачными провайдерами и требует большей компьютерной мощности в целом из-за множества уровней абстракции. В то время как любой проект несет ответственность за небольшую часть этих отходов, все глобальное облако как совокупность очень расточительно. Это беспокоит меня и, очевидно, может быть причиной эмоциональной предвзятости в моих взглядах (так много соли для всего вышеперечисленного).
Можно привести аргумент, что вы можете разработать средство для аренды физических серверов до получения дохода, а затем, когда это имеет смысл, вы можете либо использовать стандартную амортизацию, либо Раздел 179 для прямых покупок и/или аренду Раздела 179.

Например, вы можете развернуть невероятно мощную группу, скажем, из четырех абсолютно полностью выделенных физических машин стоимостью 100 000 долларов США 1U в разных помещениях для резервирования. Здесь есть всевозможные хитрости для балансировки нагрузки и аварийного переключения с облачным сервисом XYZ, DNS, anycast, чем угодно. Вы можете использовать различные объекты colo, которые управляют центрами обработки данных по всему миру, доставлять им оборудование от поставщика, а затем предоставлять им Ansible или что-то еще, чем вы занимаетесь, даже не видя объекта и не касаясь оборудования.

Итак, теперь у вас есть избыточное физическое оборудование, которое будет абсолютно работать с большинством облачных провайдеров (особенно для ввода-вывода), фиксированные затраты, такие как все, что вы можете использовать в полосе пропускания (у которой нет 800% наценки облачных сервисов и т. д.) - больше не нужно ждать за неизбежный счет за облако в размере 50 тысяч долларов или попытку отследить (в панике), что заставило вас превысить настроенный облачный бюджет за день, а не за месяц. О, кстати, вы не запираете себя в глупых проприетарных API для предоставления и даже использования услуг, отличных от виртуальных машин, предлагаемых $BIGCLOUD.

Если вы занимаетесь машинным обучением, вы можете тренироваться на своем собственном оборудовании или (или иногда в облаке) и запускать вывод 24/7 с такими вещами, как NVIDIA A10. Непрерывная аренда облачных вычислений для экземпляров GPU невероятно дорога, а окупаемость покупки оборудования обычно составляет несколько месяцев (или намного опережает почти сразу в соответствии с разделом 179). Например, я недавно провел тест с Nvidia A10 для модели, которую мы обслуживаем, и она может выполнять более 700 запросов на вывод в секунду в FP32 с задержкой менее 10 мс. С одним A10 на шасси в четырех исправных экземплярах это составляет 2800 запросов в секунду (и, вероятно, может быть дополнительно настроено)

Затем, если вы станете ДЕЙСТВИТЕЛЬНО большим, вы можете начать приобретать шкафы и не только. Что касается сбоев оборудования, как уже упоминалось, все, что я могу сказать, это двойной RAID-массив PS и т. Д., Аппаратное обеспечение (по моему опыту) чрезвычайно надежно. Имея в прошлом несколько полных аппаратных шкафов, аппаратные сбои были немногочисленны и редки. поставщики будут включать невероятные SLA для замены. Вы уведомляете их о сбое, они отправляют техника< восемь часов прямо в центр и заменить диск, PS и т. д. с помощью мигающей лампочки

Мой опыт показывает, что один (хороший) ресурс FTE может легко справиться с этим в масштабе до нескольких кабинетов. По вашему мнению, текущая проблема заключается в том, что многие из этих людей были схвачены крупными облачными провайдерами и заменены (на рынке) ресурсами, которые могут преодолевать пограничную нелепость использования десятков (если не больше) продуктов/услуг от $ БОЛЬШОЕ ОБЛАКО

Я также обнаружил, что эта конфигурация НАМНОГО более надежна, чем большинство $BIGCLOUD. Больше не нужно задаваться вопросом, что происходит с отключением $BIGCLOUD, которое они даже не признают (и над которым у вас нет абсолютно никакого контроля). Исходя из опыта работы в телекоммуникациях и здравоохранении, меня совершенно дико удивляет, как время безотказной работы на самом деле стало намного хуже с облачными провайдерами. Обычно вы можете просто сказать клиентам: «о, у Интернета сегодня проблемы», потому что они, вероятно, увидят заголовки об этом, но для многих приложений это совершенно неприемлемо — и мы должны ожидать лучшего.

[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Если я хочу раскрутить новый проект или попробовать разместить что-то новое, это займет пару минут, и у меня есть сценарии. Развертывание быстрое, обслуживание низкое, и у меня есть гораздо больше за мои деньги

Для всех, кто заинтересован, это черновой вариант того, что я использую:
* Ansible, чтобы управлять всем
* Небольшой терраформ для некоторых записей DNS, которые я когда-нибудь заменю.
* restic для резервных копий, опять же под управлением ansible
* tailscale для vpn (у меня дома работает несколько пи, ничего особенного, но 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. Для твердотельных накопителей скрестите пальцы; по моему опыту с несколькими тысячами, они, как правило, отлично работают, пока не исчезают из автобуса, и их больше никогда не видят. Имейте план восстановления данных, который не включает хранение данных на устройствах той же модели с очень похожей мощностью в часах, коррелированные ошибки прошивки в часах реальны.

В конце концов, у Hetzner есть API для заказа выделенных серверов и API для установки ОС (или для перезагрузки для восстановления и прошивки любого образа, который вы хотите)
Думаю, если бы я рассматривал коммерческие варианты, я бы отсортировал «магистраль» в офисе с коммерческим решением для интернет-провайдера, статическим IP-адресом, может быть, хорошим ИТ-оборудованием, но из того, что я знаю на данный момент, если клиенту нужен хостинг, я бы d всегда переходите сразу к аренде vps

В то время я был скорее младшим разработчиком, так что, может быть, и был, но я совсем по этому не скучаю. Теоретически я согласен с тем, что вы говорите, но развертывание Dockerfile в чем-то вроде Google Cloud Run намного проще. Да, я плачу больше, чем за управление своим собственным VPS, но я думаю, что это более чем компенсируется сэкономленными часами разработки.

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

Для новичка самые дешевые сделают работу

Я уверен, что по мере развития облачных вычислений эти предложения станут более распространенными.

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

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

Локальные приложения стоят примерно на 40% меньше. Приложения, которые являются более экономичными в облаке, остаются там

Я думаю, дело в том, что AWS/GCP/Azure не очень конкурентоспособны по цене в Европе. То, что я не вижу, является доказательством этого для США.

для той же спецификации, конечно. Я думаю, что виртуальные устройства имеют смысл с обеих сторон — важна либо динамическая масштабируемость для больших N, либо вам действительно нужна лишь небольшая часть физической коробки. Платить 45 в месяц за что-то, что работает с поиском 5 в месяц, также неразумно, и дает вам больше гибкости, чтобы не объединять вещи только для использования вашего сервера.

Сохраняйте резервные копии на всякий случай. Желательно у другого провайдера или хотя бы в другом физическом месте. И, конечно же, протестировать их

И если вы управляете хорошим режимом резервного копирования и в любом случае отслеживаете свои данные / приложение, создает ли мониторинг значительные дополнительные трудности?
--
[1] на самом деле, если вы автоматизируете процесс восстановления в другое место, что я делаю для пары своих битов, тогда вы можете просто нажать эту кнопку и обновить DNS после завершения и, возможно, выделить немного больше оперативной памяти + ядер (мой тест зеркала меньше, чем живые виртуальные машины, поскольку им не нужно обслуживать модели реального использования)

Именно то, что я делаю для себя и своих клиентов. Экономит тонны доша

Даже если бы я хотел обновить, это просто случай загрузки последней версии в шаблон docker-compose и повторного запуска ansible playbook. Очевидно, что если для обновления требуется больше, пусть будет так, но это ничем не отличается от любой другой работы по настройке.

Вероятно, единственное, что мне _нужно_ сделать вручную, это проверить свои резервные копии. Но у меня есть сценарий для каждого проекта, который это делает, поэтому я просто включаю SSH, запускаю однострочник, проверяю результат и готово. Я делаю это примерно раз в месяц или около того, но я также получаю электронные письма, если резервная копия не удалась.
Так что времени может и не быть. Обычно это, вероятно, 1-2 часа в месяц, если я получаю обновления на полурегулярной основе. Но это будет масштабироваться по мере увеличения количества вещей, которые вы размещаете и которыми управляете.

Другими словами, единственная разница заключается в том, откуда берется файл ansible inventory. Либо это статический список IP-адресов, либо он исходит от terraform

Если вам нужна оперативная память ECC, то это 60 в месяц, а также более мощный 8-ядерный процессор.

Несмотря на это, если мы говорим о «полной производственной среде и дублированной промежуточной/резервной среде» (цитируя человека, которому вы ответили), то 60 в месяц * (2 или 3) по-прежнему очень дешево по сравнению с AWS любого стартапа. счет, который я видел

Варианты использования различаются, но я склонен согласиться с тем, что AWS/GCP/Azure — не решение всех проблем.

Для того, кто может разместить свое приложение на VPS за 4 доллара, это, очевидно, будет дешевле, чем что-либо на голом железе, но во многих случаях масштабирование облака обходится очень дорого. Голое железо также не является решением всех проблем, но многие люди в отрасли, похоже, не ценят, когда это может быть правильным решением.