AWS или смерть
На #HighLoad кроме большого количества хороших докладов, есть реально крутая вещь - возможность организовывать свои собственные тематические митапы в специально отведенных для такого аудиториях.
Один из таких, с незамысловатым названием "AWS и все-все-все", где удалось не только нахаляву разжиться бесплатными стикерами и послушать Василия Пантюхина (архитектор AWS) — стал причиной такому радикальному заголовку данного поста.
Точней не сам митап, а тема, которую подняли новосибирские коллеги из AWS@NSK и которую очень часто приходится слышать в других местах. Она характеризуется популярными тезисами типа: как жить дальше, сколько можно терпеть и прочие доколе - когда же, наконец, AWS придёт и порядок наведёт. В Россию, конечно же. Хотя актуально для всей восточноевропейской части и зауралья.
Если коротко, то ответ на этот животрепещащий вопрос остался на митапе и остаётся здесь всё тем же - типа держитесь там и прочих благ.
Постановка вопроса некорректная, потому и ответ можно расценить злорадным.
Противопоставление или-или некорректно. Любой проект в области IT в современной реальности глобален сам по себе. Если же в вашем случае это не так, то AWS не ваш выбор, ведь его плюсы особо проявляются для активно растущих проектов, в том числе географически.
Если же это так, но важно иметь и локальное присутствие, а до ближайшего датацентра Амазона многие тысячи километров, в то время как сетевые задержки из-за этого недопустимы в вашем проекте — меняйте архитектуру. Используйте для глобальных вещей AWS, а локальные реализуйте другими средствами - своими или локальных провайдеров.
Например, Яндекс.Облако и MCS (Mail.ru Cloud Solutions) имеют полностью S3-совместимый протокол работы со своими сервисами Object Storage. У Яндекс.Облако есть провайдер для Terraform. Все нонче уже имеют свои managed-Kubernetes сервисы.
Набор таких возможностей позволяет совместить глобальную инфраструктуру, которую может предложить AWS и локальную, которую не может предложить AWS. Будь то из-за специфики требований или просто из-за неудовлетворительных значений latency.
Ещё один подход - грамотно построенная архитектура на Амазоне обязательно должна иметь рабочий в жизни (а не только в документации) DR (Disaster Recovery) план. Имея такой инструмент (DR-plan) и вышеперечисленные средства позволят получить (должны получить) относительно быструю и безболезенную миграцию в облако нового провайдера, чтобы проверить насколько оно удовлетворяет вашим потребностям.
Вкладывайтесь в эту часть (DR) - это не только залог безопасности вашего проекта в AWS, но и упрощение использования локальных провайдеров когда и для чего они вам подойдут. Multi-cloud уже не только маячит на горизонте, а реальность как раз для подобных случаев.
Итого, что хотелось бы сказать по этой теме: противопоставление или-или неуместно. Уместно и-и.
#AWS #проповедь
На #HighLoad кроме большого количества хороших докладов, есть реально крутая вещь - возможность организовывать свои собственные тематические митапы в специально отведенных для такого аудиториях.
Один из таких, с незамысловатым названием "AWS и все-все-все", где удалось не только нахаляву разжиться бесплатными стикерами и послушать Василия Пантюхина (архитектор AWS) — стал причиной такому радикальному заголовку данного поста.
Точней не сам митап, а тема, которую подняли новосибирские коллеги из AWS@NSK и которую очень часто приходится слышать в других местах. Она характеризуется популярными тезисами типа: как жить дальше, сколько можно терпеть и прочие доколе - когда же, наконец, AWS придёт и порядок наведёт. В Россию, конечно же. Хотя актуально для всей восточноевропейской части и зауралья.
Если коротко, то ответ на этот животрепещащий вопрос остался на митапе и остаётся здесь всё тем же - типа держитесь там и прочих благ.
Постановка вопроса некорректная, потому и ответ можно расценить злорадным.
Противопоставление или-или некорректно. Любой проект в области IT в современной реальности глобален сам по себе. Если же в вашем случае это не так, то AWS не ваш выбор, ведь его плюсы особо проявляются для активно растущих проектов, в том числе географически.
Если же это так, но важно иметь и локальное присутствие, а до ближайшего датацентра Амазона многие тысячи километров, в то время как сетевые задержки из-за этого недопустимы в вашем проекте — меняйте архитектуру. Используйте для глобальных вещей AWS, а локальные реализуйте другими средствами - своими или локальных провайдеров.
Например, Яндекс.Облако и MCS (Mail.ru Cloud Solutions) имеют полностью S3-совместимый протокол работы со своими сервисами Object Storage. У Яндекс.Облако есть провайдер для Terraform. Все нонче уже имеют свои managed-Kubernetes сервисы.
Набор таких возможностей позволяет совместить глобальную инфраструктуру, которую может предложить AWS и локальную, которую не может предложить AWS. Будь то из-за специфики требований или просто из-за неудовлетворительных значений latency.
Ещё один подход - грамотно построенная архитектура на Амазоне обязательно должна иметь рабочий в жизни (а не только в документации) DR (Disaster Recovery) план. Имея такой инструмент (DR-plan) и вышеперечисленные средства позволят получить (должны получить) относительно быструю и безболезенную миграцию в облако нового провайдера, чтобы проверить насколько оно удовлетворяет вашим потребностям.
Вкладывайтесь в эту часть (DR) - это не только залог безопасности вашего проекта в AWS, но и упрощение использования локальных провайдеров когда и для чего они вам подойдут. Multi-cloud уже не только маячит на горизонте, а реальность как раз для подобных случаев.
Итого, что хотелось бы сказать по этой теме: противопоставление или-или неуместно. Уместно и-и.
#AWS #проповедь