Академически качественный доклад на #HighLoad по Design for Failure от архитектора AWS Василия Пантюхина.
https://www.youtube.com/watch?v=7cqS4zAlU50&t=19188s
Основные тезисы:
• какое звание было у Э.Мерфи
• known unknowns vs unknown unknowns
• приоритезация эвентлога
• о пользе постоянной работы
• деньги на риски
• о мудрости пчёл
• оптом дешевле
• малый флот рулит большим
• обогрев воздуха с помощью brownout
Рекомендуется к обязательному просмотру (пересматривал пару раз под запись - это просто концентрат рекомендаций). Актуально условно и для архитекторов, и для девопсов, и для разработчиков (что подтверждают важные ответы на вопросы после доклада).
#design #must_see
https://www.youtube.com/watch?v=7cqS4zAlU50&t=19188s
Основные тезисы:
• какое звание было у Э.Мерфи
• known unknowns vs unknown unknowns
• приоритезация эвентлога
• о пользе постоянной работы
• деньги на риски
• о мудрости пчёл
• оптом дешевле
• малый флот рулит большим
• обогрев воздуха с помощью brownout
Рекомендуется к обязательному просмотру (пересматривал пару раз под запись - это просто концентрат рекомендаций). Актуально условно и для архитекторов, и для девопсов, и для разработчиков (что подтверждают важные ответы на вопросы после доклада).
#design #must_see
highload.ru
Василий Пантюхин на HighLoad++ ( 7 докладов )
Начинал Unix-админом. Потом 6 лет занимался большими железками Sun Microsystem и преподавал технические курсы. 11 лет проповедовал дата-центричность мира в EMC. Дизайнил и реализовывал проекты от Кейптауна до Осло. Окончательно убедившись, что ИТ подходы…
К сведению пассажиров!
Завтра в Москве на HighLoad один гражданин будет раздавать вполне себе круглые значки с изображением того, что вы видите здесь слева.
#HighLoad
Завтра в Москве на HighLoad один гражданин будет раздавать вполне себе круглые значки с изображением того, что вы видите здесь слева.
#HighLoad
highload.ru
Конференция разработчиков высоконагруженных систем HighLoad++ 2019
Fargate for EKS
На анонсе EKS и Fargate два года назад на re:Invent 2017, мне врезалась в память фраза, что #Fargate будет работать на базе #EKS под капотом. И до этого времени я пребывал в наивной уверенности, что это так и есть - под капотом у Fargate в реальности EKS.
Однако сегодня первый день на #HighLoad прошёл не зря - я заблуждался и с подачи умных людей узнал правду, что это были лишь планы, который оными и остались на сегодняшний день (см. картинку). Мало того, всё идёт к тому, что это (Fargate for EKS) так и останется лишь планами в роадмэпе.
Теперь и вы это знаете, и если тоже так думали - значит тоже теперь мучайтесь, как я.
#what_i_learned_today
На анонсе EKS и Fargate два года назад на re:Invent 2017, мне врезалась в память фраза, что #Fargate будет работать на базе #EKS под капотом. И до этого времени я пребывал в наивной уверенности, что это так и есть - под капотом у Fargate в реальности EKS.
Однако сегодня первый день на #HighLoad прошёл не зря - я заблуждался и с подачи умных людей узнал правду, что это были лишь планы, который оными и остались на сегодняшний день (см. картинку). Мало того, всё идёт к тому, что это (Fargate for EKS) так и останется лишь планами в роадмэпе.
Теперь и вы это знаете, и если тоже так думали - значит тоже теперь мучайтесь, как я.
#what_i_learned_today
Академически качественный доклад на #HighLoad по Design for Failure от архитектора AWS Василия Пантюхина.
https://www.youtube.com/watch?v=7cqS4zAlU50&t=19188s
Основные тезисы:
• какое звание было у Э.Мерфи
• known unknowns vs unknown unknowns
• приоретизация эвентлога
• о пользе постоянной работы
• деньги на риски
• о мудрости пчёл
• оптом дешевле
• малый флот рулит большим
• обогрев воздуха с помощью brownout
Рекомендуется к обязательному просмотру (пересматривал пару раз под запись - это просто концентрат рекомендаций). Актуально условно и для архитекторов, и для девопсов, и для разработчиков (что подтверждают важные ответы на вопросы после доклада).
#design #must_see
https://www.youtube.com/watch?v=7cqS4zAlU50&t=19188s
Основные тезисы:
• какое звание было у Э.Мерфи
• known unknowns vs unknown unknowns
• приоретизация эвентлога
• о пользе постоянной работы
• деньги на риски
• о мудрости пчёл
• оптом дешевле
• малый флот рулит большим
• обогрев воздуха с помощью brownout
Рекомендуется к обязательному просмотру (пересматривал пару раз под запись - это просто концентрат рекомендаций). Актуально условно и для архитекторов, и для девопсов, и для разработчиков (что подтверждают важные ответы на вопросы после доклада).
#design #must_see
highload.ru
Василий Пантюхин на HighLoad++ ( 7 докладов )
Начинал Unix-админом. Потом 6 лет занимался большими железками Sun Microsystem и преподавал технические курсы. 11 лет проповедовал дата-центричность мира в EMC. Дизайнил и реализовывал проекты от Кейптауна до Осло. Окончательно убедившись, что ИТ подходы…
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 #проповедь