Подтверждаю. Работая в сфере предоставления услуг DevOps as Service прекрасно понимаю о чём речь. Для бизнеса это вроде бы и хорошо, потому что создаёт много работы для нормальных DevOps'ов :), но в целом печально и тратит время.
Хуже когда такой "DevOps" возглавляет отдел/направление DevOps в компании.
Я с вами согласен, что при грамотной архитектуре и процессах в компании в большинстве случаев мало DevOps'ов могут держать большой прод. Мне бросилось в глаза именно то, что я написал про DevOps и SRE и SRE никуда не отпочковывались, просто у некоторых компаний нагруженный прод и они своих DevOps'ов называют SRE.
Мне как раз нравится концепция "очередного WeChat", но таки более понятного для нас и более быстрого.
Ton вполне жив и развивается, а на этой неделе он подорожал процентов на 30-40, т.к. Ton Space запустили, обмен TON/USDT возможен и судя по всему Ton вот вот начнёт торговаться на Binance и ещё несколько факторов.
прогер его поднимет у себя на локалхосте одной доцкер-командой за 3 минуты
девопсь его поднимет в хетцнере одной командой ансибля. ну и вообще, у него в хетцнере кубер развернут )
Вы продолжаете игнорировать мои аргументы.
У любого сервиса есть цикл жизни. Вы почему то рассматриваете только "поднять", хотя нужно ещё обсуживать, масштабировать, патчить, разбираться с сетевыми проблемами и т.д. т.к. в Hetzner брокер очередей - это не managed сервис.
Для того, чтобы что-то поднять ансиблом одной командой у вас уже должен быть написан плейбук и в концов настроен ансибл, тогда как в случае с AWS разработчик может не имея вообще ничего (включая DevOps'а) с околонулевыми затратами времени накликопсить, после чего это можно импортировать в терраформ (например когда DevOps появится). Видел множество стартапом с такой не очень красивой ситуацией, но уже работающих в проде, т.е. приносящих необходимую им пользу, а иногда и реальные деньги от клиентов.
> это не похоже на "падение датацентра минимум на 2 дня"
мимо тазика, это были не preemptible узлы
у гугла и остальных аварии случаются достаточно часто, надо разбаниться в гугле уже.
Описанная вами ошибка не говорит о падении датацентра, и вы удобно проигнорировали всё, что я написал в том числе про зоны/регионы и девятки в доступности. Кратко перефразирую: вы можете реализовать вашу архитектуру так, что при падании одного из дц ваше приложение корректно отработает эту ситуацию и не повлияет на клиентов. В AWS часто это можно настроить из коробки. В Hetzner это гораздо сложнее.
За сим считаю бессмысленным продолжать дискуссию, потому что вы игнорируете мои аргументы.
опять рекламный поток... Именно "надежность и моментальную масштабируемость при резких наплывах" это то, что подавляющему большинству стартапов не нужно.
Читайте внимательнее, в этом абзаце я писал не про стартапы.
Я, кстати, AWS не использовал, но...
Как говорится "не читал, но осуждаю"? Я не писал, что всем нужно только в AWS и что Hetzner плох. Но :) вот, например, понадобился вам брокер очередей и в Hetzner вы пойдете заниматься его установкой, настройкой и дальнейшей поддержкой и не забудьте про скейлинг инфраструктуры, если это должно работать под какой-то нагрузкой), тогда как в AWS вы очень быстро создаете, например, SQS, причем сразу по экземпляру на каждое окружение, пилите фичи, прогоняете по окружениям, катите в прод. Для тех.же стартапов скорость релизов бывает очень даже критична.
Статья про AWS, а не всех облачных провайдеров, и мои комментарии в целом тоже. Но всё же отмечу, что "ты тыкаешь start vm, а тебе в ответ - нет ресурсов" - это не похоже на "падение датацентра минимум на 2 дня".
Далее, даже при достаточно высокой надёжности AWS проблемы случаются везде и как и везде вам необходимо самостоятельно решать насколько много ресурсов вы готовы потратить на лишние девятки в доступности вашего приложения. Это относится как к созданию инфраструктуры в нескольких зонах доступности/регионах (отказал один дц/зона/регион, ваши пользователи это не ощутят), так и продумыванию использования конкретных технологий, вроде spot instances, у которых есть свои нюансы by design (именно поэтому они и дешевле). Например вы решили поднять всё на спотах в одной зоне доступности, но не учли, что споты могут и закончиться (в терминологии Google Cloud - Preemptible instances?). К слову в связке с AWS spot instances очень неплохо работает spot.io или Karpenter, у каждого из которых свои плюсы и минусы и которые позволяют реализовывать порой даже очень stateful нагрузки на спотах.
По итогу AWS даёт вам возможность реализовать желаемое, потратив на это минимум человекочасов и управляя всем этим правильно и очень гранулярно (например AWS IAM очень хорош, хоть и не прост для новичков) : git + terraform + CICD и т.д., а для большинства кейсов для Terraform ещё и community модули есть.
Что из перечисленного мной вы считаете "смузихренью" и можете ли вы обосновать ваше мнение? Вы видели, что используют что то и это на самом деле не нужно? Вопросы не к AWS, а к тому, у кого вы видели. AWS предоставляет возможности.
стартап стартапу рознь, все мечтают стать единорогом
о том, чтобы стать единорогом мечтает 100% стартапов, не обманывайте себя, если думаете по-другому. Это бизнес и все мечтают зарабатывать как можно больше.
остальные делают overkill
Для стартапов обычно крайне важно иметь возможность быстро изменить продукт в угоду спросу/потенциальным клиентам и в AWS это сделать легче всего, потому что есть готовые сервисы очень много для чего, на поднятие и обслуживание которых нужно тратить значительно меньше времени команды и соответственно денег на зп и найм. Да в AWS можно и накрутить лишнего, но если это нужно, то есть такая возможность. А ещё стартапам предоставляют консультации архитекторов AWS и много другого полезного, чтобы знать как делать правильно.
Я вам больше скажу: есть вполне себе не стартапы, а компании имеющие миллионы клиентов, которые прямо сейчас в проде под высокой нагрузкой используют перечисленные мной сервисы и не переезжают из AWS в том числе потому, что AWS дает им недоступную где либо ещё надежность и моментальную масштабируемость при резких наплывах трафика.
И это не отменяет остального сказанного мной выше.
Ставить DO в один ряд с Azure не серьёзно, а уж с AWS и подавно: DO беден по функционалу и экосистеме сервисов и менее надёжен и в этих условиях смысла использовать их программу для стартапов вместо AWS, в большинстве случаев, нет.
Например, events like S3 triggering Lambda or SQS и т.д., сама Lambda, API Gateway + XRay, KMS, Opensearch, multi region PG (Aurora) и другие сервисы крайне полезны стартапу в целом и разработке могут пригодиться в любой момент и это поднимаются в AWS в production ready конфигурации за минуты и по большей части не требует обслуживания (конечно кроме Aurora и то, если она под высокой нагрузкой и т.п.).
Все комментаторы, которые пишут что-то вроде "не используйте AWS", используйте Hetzner/Digitalocean и т.п. в том числе просто до конца не понимают насколько удобна его экосистема и насколько быстрее эти удобства позволяют выкатывать новый бизнес функционал в прод, который и приносит прибыль позволяющую в том числе оплачивать счета AWS. И да, это не для всех подходит.
Стартапам поначалу AWS может вообще ничего не стоить, т.к. AWS может выдать 100 тысяч долларов на старт.
К тому же AWS - серьёзное облако с большим количеством нюансов и возможностей для оптимизации расходов и заезжать в него и платить реальные деньги при этом не разбираясь и потому говорить, что дорого - это ... странный подход.
Можете привести пример такой задачи, где вы "имея хорошую базу и опыт работы с данным стеком", "тупили бы над задачей неделю" через, скажем, три месяца (что больше двух, но вполовину меньше полугода) после начала работы на проекте, но закрыли бы её за полдня через полгода?
Полгода в лучшем случае, при условии что у тебя есть хорошая база и опыт работы с данным стеком
Не соглашусь с вами. Конечно проект может быть сложный, но если есть "хорошая база и опыт работы с данным стеком", то имхо ваша оценка сильно завышена. Пара месяцев от силы.
Подтверждаю. Работая в сфере предоставления услуг DevOps as Service прекрасно понимаю о чём речь. Для бизнеса это вроде бы и хорошо, потому что создаёт много работы для нормальных DevOps'ов :), но в целом печально и тратит время.
Хуже когда такой "DevOps" возглавляет отдел/направление DevOps в компании.
Не должны. Но в некоторых компаниях и админов освоивших кубер DevOps'ами называют.
Я с вами согласен, что при грамотной архитектуре и процессах в компании в большинстве случаев мало DevOps'ов могут держать большой прод. Мне бросилось в глаза именно то, что я написал про DevOps и SRE и SRE никуда не отпочковывались, просто у некоторых компаний нагруженный прод и они своих DevOps'ов называют SRE.
WeChat'ом таки пользуются и это крайне удобно, да и Тиньковым с Яндексом тоже, слава Богу вас не спросили :)
DevOps держащий прод и есть SRE, а вы написали, что SRE особо не нужны. Вы имеете ввиду их не нужно много?
Мне как раз нравится концепция "очередного WeChat", но таки более понятного для нас и более быстрого.
Ton вполне жив и развивается, а на этой неделе он подорожал процентов на 30-40, т.к. Ton Space запустили, обмен TON/USDT возможен и судя по всему Ton вот вот начнёт торговаться на Binance и ещё несколько факторов.
Телега очень хороша, но, видимо, не на ваш вкус.
Крипта вполне себе жива и развивается, а кошелёк телеги с p2p очень удобен.
?
SRE implements DevOps https://sre.google/workbook/how-sre-relates/
При хорошей автоматизации и понимании этих инструментов EKS + karpenter + EC2 (можно и чисто на spot instances или микс) часто гораздо лучше ECS.
Вы продолжаете игнорировать мои аргументы.
У любого сервиса есть цикл жизни. Вы почему то рассматриваете только "поднять", хотя нужно ещё обсуживать, масштабировать, патчить, разбираться с сетевыми проблемами и т.д. т.к. в Hetzner брокер очередей - это не managed сервис.
Для того, чтобы что-то поднять ансиблом одной командой у вас уже должен быть написан плейбук и в концов настроен ансибл, тогда как в случае с AWS разработчик может не имея вообще ничего (включая DevOps'а) с околонулевыми затратами времени накликопсить, после чего это можно импортировать в терраформ (например когда DevOps появится). Видел множество стартапом с такой не очень красивой ситуацией, но уже работающих в проде, т.е. приносящих необходимую им пользу, а иногда и реальные деньги от клиентов.
Описанная вами ошибка не говорит о падении датацентра, и вы удобно проигнорировали всё, что я написал в том числе про зоны/регионы и девятки в доступности. Кратко перефразирую: вы можете реализовать вашу архитектуру так, что при падании одного из дц ваше приложение корректно отработает эту ситуацию и не повлияет на клиентов. В AWS часто это можно настроить из коробки. В Hetzner это гораздо сложнее.
За сим считаю бессмысленным продолжать дискуссию, потому что вы игнорируете мои аргументы.
Читайте внимательнее, в этом абзаце я писал не про стартапы.
Как говорится "не читал, но осуждаю"? Я не писал, что всем нужно только в AWS и что Hetzner плох. Но :) вот, например, понадобился вам брокер очередей и в Hetzner вы пойдете заниматься его установкой, настройкой и дальнейшей поддержкой и не забудьте про скейлинг инфраструктуры, если это должно работать под какой-то нагрузкой), тогда как в AWS вы очень быстро создаете, например, SQS, причем сразу по экземпляру на каждое окружение, пилите фичи, прогоняете по окружениям, катите в прод. Для тех.же стартапов скорость релизов бывает очень даже критична.
Статья про AWS, а не всех облачных провайдеров, и мои комментарии в целом тоже. Но всё же отмечу, что "ты тыкаешь start vm, а тебе в ответ - нет ресурсов" - это не похоже на "падение датацентра минимум на 2 дня".
Далее, даже при достаточно высокой надёжности AWS проблемы случаются везде и как и везде вам необходимо самостоятельно решать насколько много ресурсов вы готовы потратить на лишние девятки в доступности вашего приложения. Это относится как к созданию инфраструктуры в нескольких зонах доступности/регионах (отказал один дц/зона/регион, ваши пользователи это не ощутят), так и продумыванию использования конкретных технологий, вроде spot instances, у которых есть свои нюансы by design (именно поэтому они и дешевле). Например вы решили поднять всё на спотах в одной зоне доступности, но не учли, что споты могут и закончиться (в терминологии Google Cloud - Preemptible instances?). К слову в связке с AWS spot instances очень неплохо работает spot.io или Karpenter, у каждого из которых свои плюсы и минусы и которые позволяют реализовывать порой даже очень stateful нагрузки на спотах.
По итогу AWS даёт вам возможность реализовать желаемое, потратив на это минимум человекочасов и управляя всем этим правильно и очень гранулярно (например AWS IAM очень хорош, хоть и не прост для новичков) : git + terraform + CICD и т.д., а для большинства кейсов для Terraform ещё и community модули есть.
Что из перечисленного мной вы считаете "смузихренью" и можете ли вы обосновать ваше мнение? Вы видели, что используют что то и это на самом деле не нужно? Вопросы не к AWS, а к тому, у кого вы видели. AWS предоставляет возможности.
о том, чтобы стать единорогом мечтает 100% стартапов, не обманывайте себя, если думаете по-другому. Это бизнес и все мечтают зарабатывать как можно больше.
Для стартапов обычно крайне важно иметь возможность быстро изменить продукт в угоду спросу/потенциальным клиентам и в AWS это сделать легче всего, потому что есть готовые сервисы очень много для чего, на поднятие и обслуживание которых нужно тратить значительно меньше времени команды и соответственно денег на зп и найм. Да в AWS можно и накрутить лишнего, но если это нужно, то есть такая возможность. А ещё стартапам предоставляют консультации архитекторов AWS и много другого полезного, чтобы знать как делать правильно.
Я вам больше скажу: есть вполне себе не стартапы, а компании имеющие миллионы клиентов, которые прямо сейчас в проде под высокой нагрузкой используют перечисленные мной сервисы и не переезжают из AWS в том числе потому, что AWS дает им недоступную где либо ещё надежность и моментальную масштабируемость при резких наплывах трафика.
И это не отменяет остального сказанного мной выше.
Ставить DO в один ряд с Azure не серьёзно, а уж с AWS и подавно: DO беден по функционалу и экосистеме сервисов и менее надёжен и в этих условиях смысла использовать их программу для стартапов вместо AWS, в большинстве случаев, нет.
Например, events like S3 triggering Lambda or SQS и т.д., сама Lambda, API Gateway + XRay, KMS, Opensearch, multi region PG (Aurora) и другие сервисы крайне полезны стартапу в целом и разработке могут пригодиться в любой момент и это поднимаются в AWS в production ready конфигурации за минуты и по большей части не требует обслуживания (конечно кроме Aurora и то, если она под высокой нагрузкой и т.п.).
Спасибо за статью.
Все комментаторы, которые пишут что-то вроде "не используйте AWS", используйте Hetzner/Digitalocean и т.п. в том числе просто до конца не понимают насколько удобна его экосистема и насколько быстрее эти удобства позволяют выкатывать новый бизнес функционал в прод, который и приносит прибыль позволяющую в том числе оплачивать счета AWS. И да, это не для всех подходит.
Стартапам поначалу AWS может вообще ничего не стоить, т.к. AWS может выдать 100 тысяч долларов на старт.
К тому же AWS - серьёзное облако с большим количеством нюансов и возможностей для оптимизации расходов и заезжать в него и платить реальные деньги при этом не разбираясь и потому говорить, что дорого - это ... странный подход.
ebpf + https://cilium.io/use-cases/service-map/
Выдайте этому человеку НадСениора, пожалуйста!
Можете привести пример такой задачи, где вы "имея хорошую базу и опыт работы с данным стеком", "тупили бы над задачей неделю" через, скажем, три месяца (что больше двух, но вполовину меньше полугода) после начала работы на проекте, но закрыли бы её за полдня через полгода?
Не соглашусь с вами. Конечно проект может быть сложный, но если есть "хорошая база и опыт работы с данным стеком", то имхо ваша оценка сильно завышена. Пара месяцев от силы.
Следующий шаг, конечно, https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
Если это какой-то перевод или кусок от него, то стоит это указать и проверить.