IBM cloud безусловно далеко до AWS, хотя вы можете найти какие-то статьи, где IBM cloud где-то в чём-то впереди. Генеральным директором всего Amazon не зря стал бывший генеральный директор AWS.
Добавьте ко всему мной сказанному то, что для создания/поддержки инфраструктуры на AWS очень легко найти очень качественную команду инженеров с десятилетиями опыта, чего точно нельзя сказать про IBM cloud, а это расходы и расходы также не маленькие.
Вы пытаетесь переизобрести FinOps? Не нужно, он уже существует. Очень и очень много параметров влияют на итого. И это далеко не только константность/динамичность нагрузок на сервера. Не стоит недооценивать неумение неспециалиста в вопросе без специально заточенных под это инструментов и десятилетий опыта (а сейчас уже такое накопилось да) просчитать всю картину в целом. В серьезных компаниях для оценки таких миграций нанимаются специально обученные люди + косты режутся на регулярной основе, а не один раз.
Интересно было бы использовать инструмент из статьи для гораздо более сложных кейсов и добавить туда разные хостинги и т.д. посмотреть на вывод.
IBM может быть сколько угодно серьезной компанией, но в этом бизнесе им до AWS как до луны, поэтому у IBM bare metal и дешевле AWS bare metal.
Некоторые из причин, почему AWS в чём-то дороже условного IBM/Oracle & etc:
прогнозируемая, испытанная, проверенная и проверяемая годами надёжность
богатая несравнимая ни с одной другой экосистема. У них есть managed практически что угодно и это позволяет не тратить разного рода ресурсы. Например вместо HA Patroni Postgres берёте RDS (которым тоже естественно нужно уметь правильно пользоваться)
наличие отличных top tier дц во многих зонах по миру. Не говорим про Россию т.к. с финансовой точки зрения этот рынок, к сожалению, не интересен
очень качественное api и наличие нескольких хорошо поддерживаемых инструментов для него
очень хорошая техническая поддержка
commit to upstream including Kubernetes, Elasticsearch/OpenSearch & etc
При всем вышеперечисленным настаиваю на том, что в большинстве случаев при правильном подходе к оптимизации и планированию расходов их можно держать на уровне если не ниже, то вполне сравнимом с другими провайдерами/хостингами.
Не знаю что вы видели, я работаю с большим количеством компаний разного размера и вижу это каждый день.
Очевидно я рассматриваю кейсы с каким-либо трафиком/с каким либо взаимодействием с пользователем, а не сферического коня в вакууме, которого не трогают годами. Там ещё тоже смотря как не трогают. Если вызывают изредка, то может и лямбдой и тп можно заменить :) Нагрузка же в случаях наличия пользовательского трафика априори не константа, а значит имеет смысл масштабировать инфраструктуру под нагрузку.
Вопрос аутсорса обслуживания части инфраструктуры в облаках это конечно вопрос о дельный, но его точно стоит учитывать и добавлять к общей стоимости на инфраструктуру и в этом облако сильно впереди bare metal. Есть топовые компании с достаточно большой инфраструктурой которую обслуживает очень мало людей.
Вы видимо берёте и сравниваете "в лоб" некую базовую цену сервера, которая, например в AWS в случае использования трехгодичной подписки + spot instances + других техник совершенно не та, что on demand.
При чём тут вообще количество неких deployment events я не понял? Хоть каждую минуту деплойте и инфру и приложения, цена от этого не поменяется :)
Если огромное количество кейсов, когда облака также более выгодны и для small и для medium и для large компаний. Взять и описать всё в двух предложениях, как пытаетесь вы, невозможно, каждый кейс индивидуален и переменных влияющих на итоговую цифру много (включая расходы на персонал)
Чаще всего компании, которые боятся облаков и говорят, что там дорого просто не умеют правильно проектировать и использовать то, что я перечислил в предыдущем сообщении.
Единственное что никак не побороть в AWS/GCP/Azure это цена трафика, что не для всех компаний критично. Для кого очень очень критично часть нагрузок таки держат в каком-нибудь DO.
У bare metal настолько много минусов, что при любой возможности его не использовать, не используйте.
И далеко не во всех случая совокупная стоимость владения bare metal ниже cloud и ни о каких "кратно дороже" и речи быть не может, просто вы не умеете в FinOps.
При использовании определенных техник возможно значительно(!) снизить расходы на облако: если подписываться брать у них машины в течении года/нескольких лет + spot instances + такие сервисы как https://spot.io/ + использование VPC endpoints + всякие https://www.infracost.io/ и ещё много что. Знаю многих, кто сходу тратил кучу денег в облаках не умея это правильно просчитать и не умея использовать правильные технологии.
А ещё, например, стартапный план Амазона (если у любого серьёзного облака) позволяет получить бюджет в 100 тысяч долларов, чего для начала хватит очень многим.
Если не планируете локально запускать несколько кластеров, что может K3D, то хватит и K3S https://k3s.io/ управляется systemd, один бинарник, легковесный и полностью поддерживает Kubernetes api, т.к. CNCF certified Kubernetes.
curl -sfL https://get.k3s.io | sh -
# Check for Ready node, takes maybe 30 seconds
k3s kubectl get node
Я понимаю, что вы использовали инструмент, который знаете, но Docker Swarm всё же не рабочий и мертвый для Production инструмент, не нужно использовать его для такого.
Одна из крутых фишек k3D заключается в возможности одновременного запуска нескольких Kubernetes кластеров на одной машине.
Это, например, позволяет прогонять несколько полноценных e2e тестов одновременно на одном ci/cd runner'е (например для нескольких PR/MR одновременно) и полностью уйти от использования для этого dind docker-compose и ваши тесты становятся ещё ближе к реальной инфраструктуре.
Всё вышеописанное прекрасно взлетает как на Minikube, так и на любых других K8s локально, нужно только правильно написать requests/limits и настройки памяти для Elasticsearch (java такая java), если у вас конечно не совсем мало ресурсов в системе.
Для локальной машины разработчика рекомендую K3s или K3d, жрут минимально, хорошо работают и ставятся элементарно.
Про Яндекс cloud ничего не знаю от слова совсем.
Если будет возможность/желание рассмотреть топ 3 облаков, то обращайтесь, а так даже и прокомментировать не особо могу.
IBM cloud безусловно далеко до AWS, хотя вы можете найти какие-то статьи, где IBM cloud где-то в чём-то впереди. Генеральным директором всего Amazon не зря стал бывший генеральный директор AWS.
Добавьте ко всему мной сказанному то, что для создания/поддержки инфраструктуры на AWS очень легко найти очень качественную команду инженеров с десятилетиями опыта, чего точно нельзя сказать про IBM cloud, а это расходы и расходы также не маленькие.
Вы пытаетесь переизобрести FinOps? Не нужно, он уже существует. Очень и очень много параметров влияют на итого. И это далеко не только константность/динамичность нагрузок на сервера. Не стоит недооценивать неумение неспециалиста в вопросе без специально заточенных под это инструментов и десятилетий опыта (а сейчас уже такое накопилось да) просчитать всю картину в целом. В серьезных компаниях для оценки таких миграций нанимаются специально обученные люди + косты режутся на регулярной основе, а не один раз.
Интересно было бы использовать инструмент из статьи для гораздо более сложных кейсов и добавить туда разные хостинги и т.д. посмотреть на вывод.
Есть причины по которым AWS дороже.
IBM может быть сколько угодно серьезной компанией, но в этом бизнесе им до AWS как до луны, поэтому у IBM bare metal и дешевле AWS bare metal.
Некоторые из причин, почему AWS в чём-то дороже условного IBM/Oracle & etc:
прогнозируемая, испытанная, проверенная и проверяемая годами надёжность
богатая несравнимая ни с одной другой экосистема. У них есть managed практически что угодно и это позволяет не тратить разного рода ресурсы. Например вместо HA Patroni Postgres берёте RDS (которым тоже естественно нужно уметь правильно пользоваться)
наличие отличных top tier дц во многих зонах по миру. Не говорим про Россию т.к. с финансовой точки зрения этот рынок, к сожалению, не интересен
очень качественное api и наличие нескольких хорошо поддерживаемых инструментов для него
очень хорошая техническая поддержка
commit to upstream including Kubernetes, Elasticsearch/OpenSearch & etc
При всем вышеперечисленным настаиваю на том, что в большинстве случаев при правильном подходе к оптимизации и планированию расходов их можно держать на уровне если не ниже, то вполне сравнимом с другими провайдерами/хостингами.
"каком-нибудь DO" = хостинг вроде DO второго третьего и т.д. порядка не из первой тройки.
Не знаю что вы видели, я работаю с большим количеством компаний разного размера и вижу это каждый день.
Очевидно я рассматриваю кейсы с каким-либо трафиком/с каким либо взаимодействием с пользователем, а не сферического коня в вакууме, которого не трогают годами. Там ещё тоже смотря как не трогают. Если вызывают изредка, то может и лямбдой и тп можно заменить :) Нагрузка же в случаях наличия пользовательского трафика априори не константа, а значит имеет смысл масштабировать инфраструктуру под нагрузку.
Вопрос аутсорса обслуживания части инфраструктуры в облаках это конечно вопрос о дельный, но его точно стоит учитывать и добавлять к общей стоимости на инфраструктуру и в этом облако сильно впереди bare metal. Есть топовые компании с достаточно большой инфраструктурой которую обслуживает очень мало людей.
Вы видимо берёте и сравниваете "в лоб" некую базовую цену сервера, которая, например в AWS в случае использования трехгодичной подписки + spot instances + других техник совершенно не та, что on demand.
При чём тут вообще количество неких deployment events я не понял? Хоть каждую минуту деплойте и инфру и приложения, цена от этого не поменяется :)
Если огромное количество кейсов, когда облака также более выгодны и для small и для medium и для large компаний. Взять и описать всё в двух предложениях, как пытаетесь вы, невозможно, каждый кейс индивидуален и переменных влияющих на итоговую цифру много (включая расходы на персонал)
Чаще всего компании, которые боятся облаков и говорят, что там дорого просто не умеют правильно проектировать и использовать то, что я перечислил в предыдущем сообщении.
Единственное что никак не побороть в AWS/GCP/Azure это цена трафика, что не для всех компаний критично. Для кого очень очень критично часть нагрузок таки держат в каком-нибудь DO.
У bare metal настолько много минусов, что при любой возможности его не использовать, не используйте.
И далеко не во всех случая совокупная стоимость владения bare metal ниже cloud и ни о каких "кратно дороже" и речи быть не может, просто вы не умеете в FinOps.
При использовании определенных техник возможно значительно(!) снизить расходы на облако: если подписываться брать у них машины в течении года/нескольких лет + spot instances + такие сервисы как https://spot.io/ + использование VPC endpoints + всякие https://www.infracost.io/ и ещё много что. Знаю многих, кто сходу тратил кучу денег в облаках не умея это правильно просчитать и не умея использовать правильные технологии.
А ещё, например, стартапный план Амазона (если у любого серьёзного облака) позволяет получить бюджет в 100 тысяч долларов, чего для начала хватит очень многим.
Спасибо за статью.
Интересный инструмент!
Kind - это Kubernetes IN Docker
K8s это сокращённое название Kubernetes, и обычно не означает какого-то конкретного дистрибутива Kubernetes.
Для Kubernetes в докере рекомендую K3D https://k3d.io/
Если не планируете локально запускать несколько кластеров, что может K3D, то хватит и K3S https://k3s.io/ управляется systemd, один бинарник, легковесный и полностью поддерживает Kubernetes api, т.к. CNCF certified Kubernetes.
Я понимаю, что вы использовали инструмент, который знаете, но Docker Swarm всё же не рабочий и мертвый для Production инструмент, не нужно использовать его для такого.
Чтобы сэкономить время и ничего не поднимать локально есть managed Kubernetes кластеры, для которых к тому же в первую очередь и пишут самые популярные Helm чарты, т.к. сейчас всё в облаках. Например https://github.com/zalando/postgres-operator/tree/master/charts/postgres-operator
Хотя там же и пример с нормальным локальным инструментом k3D тоже есть.
Одна из крутых фишек k3D заключается в возможности одновременного запуска нескольких Kubernetes кластеров на одной машине.
Это, например, позволяет прогонять несколько полноценных e2e тестов одновременно на одном ci/cd runner'е (например для нескольких PR/MR одновременно) и полностью уйти от использования для этого dind docker-compose и ваши тесты становятся ещё ближе к реальной инфраструктуре.
А у k3S есть опция
--flannel-backend=wireguardhttps://rancher.com/docs/k3s/latest/en/installation/network-options/#flannel-options
OpenSearch не забыт, но не является для меня достаточно проверенным временем для production, хотя это и форк.
Лично мне весь стек beats не нравится, а тот же fluentd в том числе частенько рекомендуется такими облачными провайдерами, как AWS, Google & etc
Но в целом log shippers можно выбирать по своему вкусу, главное, чтобы cpu/ram не текли и подходили под имеющиеся в вашей системе ресурсы.
Всё вышеописанное прекрасно взлетает как на Minikube, так и на любых других K8s локально, нужно только правильно написать requests/limits и настройки памяти для Elasticsearch (java такая java), если у вас конечно не совсем мало ресурсов в системе.
Для локальной машины разработчика рекомендую K3s или K3d, жрут минимально, хорошо работают и ставятся элементарно.
Не люблю и рекомендую избегать TICK стек. И ресурсы любит кушать и в целом запросы там не такие оптимальные и готовых дэшбордов меньше.
Оптимальное и production ready решение (если не рассматривать облачные): VictoriaMetrics stack (вместо Prometheus & etc) + Grafana + node_exporter.
А вместо ELK предпочитаю EFK.
Имел достаточно негативный опыт работы с git crypt в команде.
Какой-нибудь Mozilla SOPS гораздо лучше и более DevOps yaml friendly, если цель шифрование yaml/json секретов.
Так и хабр вроде ресурс не совсем уж для каждого?
К тому же Wireguard есть в ядре каждого современного ядра Linux и его даже не нужно устанавливать.
Windows для такого фу
Описание выглядит интересно, попробуем. Спасибо!