​​100 EKS кластеров в одном регионе для тех, кто так и не освоил #multi_account_strategy:

https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-eks-increases-limits-to-100-clusters-per-region/

#EKS

Я правда искренне не понимаю, кому может понадобиться 100 кластеров куба в одном аккаунте.

Мало того, что это невероятно дорого (один час обслуживания кластера со стороны Амазона стоит 20 центов в час. 100 кластеров это 20 доллара в час, 480 в день, или порядка 14600 долларов в месяц - и это только расходы на мастеров!), так еще и усложняет в стократ использование таких методик, как Service Mesh.

Впрочем, пусть люди сами соберут все грабли и возьмутся за консолидацию.

Дорогие читатели, запись моего доклада для Highload++ 2019 - https://youtu.be/BEZKub1BYCE

Пересматривая свой доклад, заметил, что в одном моменте говорю: «Курсы и сертификация по Амазону стоят гораздо дороже, чем часовая ставка амазоновского эксперта.»

Испанский стыд, конечно.

Часовая ставка амазонщика в Нидерландах начинается от 100 евро в час. 3 месяца подписки Linux Academy обойдутся в 120+- евро, а сам экзамен Architect Associate - 150 долларов. Инвестиции в себя отбиваются с лихвой, как для вас, так и для конторы.

Надеюсь аудитория восприняла все правильно.

#нет_это_не_реклама

Тут LinuxAcademy завез немало халявы: https://linuxacademy.com/blog/announcements/free-courses-at-linux-academy-december-2019/

От себя добавлю, что курс по CloudFormation точно стоящий (остальные не трогал).

Амазонщики из Минска, Питера и Москвы - внимание.

Первое: в Питере 11 декабря в 19:00 в офисе компании JetBrains пройдет митап "re:Invent 2019 reCap". https://www.meetup.com/AWSRus/events/266825735/

Обсудим новинки с главной конференции AWS!

Помимо рекапа, Александр Изюмов, архитектор из AWS, расскажет доклад на тему: «Построение безопасных и защищенных окружений и инфраструктуры на AWS - лучшие практики для всех!»

Адрес мероприятия можно найти по ссылке выше.

Второе: прекрасный человек и менеджер сообщества AWSMsk (https://www.meetup.com/awsmsk) Петр Сальников, готов активно помогать нам в https://www.meetup.com/aws-ru и конечно же в нашем чате @aws_ru

Москва не остается в стороне! 17 декабря в SkyEng в 19:00 пройдет митап нашего сообщества! Будут доклады на следующие темы:

1. "AWS EKS - кубик-рубика"
Что предлагает Амазон для кубернетеса: варианты запуска, особенности использования, опыт из проектов.

2. "AWS EKS + SpotFleet - режем бюджет в два раза"
Для каких случаев подходит, откуда такой профит, как сохранить отказоустойчивость.

3. Валерий Коробейников
«Что нужно знать ИТ-шнику об архитектуре предприятия?»

У нас будет трансляция и запись (а так же небольшие подарки от SkyEng)!
Как пройти и проехать: http://it.skyeng.ru/skyhome

И третье, в Минске митап пройдет 18 декабря в 18:00 на Фабрициуса 4
Подробности будут в https://www.meetup.com/AWS-Meetup-Minsk/events/266783772/

1. Роман Воронин - «Миграция организации на Amazon EKS»
2. Пётр Сальников от @aws_ru - «SSM - как автоматом менеджить и патчить 800+ инстансов»
3. Роман Севко - «Мульти-аккаунт стратегия - плюсы, минусы, подводные камни»
4. Виктор Николаев - «Amazon EKS + Terraform как платформа для разработки и эксплуатации»

Ждем всех и до скорой встречи!

Если объединить все «недостатки» нидерландцев как работников, можно придти к выводу, что работать с ними просто невозможно.

Некоторые моменты действительно очень мешают в работе, поэтому мне приходилось применять принцип «Ask for forgiveness, not permission».

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

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

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

Ну и проворачивать такое в enterprise секторе точно не стоит. Нравятся ли вам цепочки принятия решений из десятков человек или нет - они там не просто так.

У Сысоева и его команды все будет хорошо.
Устроившие эту катавасию люди крайне недальновидны.

It is Friday, my dudes.

Получил оценку и отзывы по своему докладу на HL++.

Хочу поблагодарить всех смотревших и присутствовавших за конструктивную (и неконструктивную) критику. Все замечания будут приняты в работу без исключений.

Если среди слушателей были мои читатели - отзовитесь! Я буду признателен, если вы напишете, чтобы вы хотели от меня увидеть и услышать в будущем - обозримом или далеком.

Попросили прокомментировать позицию вокруг Nginx.

Ок.

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

Поэтому, опять же, вкратце.

1) Если все слухи и домыслы верны, это дело по громкости возможно встанет в один ряд с “отжатием” ВК у Павла Дурова.
2) Вне зависимости от результатов этого дела:
а) Рамблер и Сбер получили серьезный удар по имиджу, как работодатели.
б) Россия, как страна для инвестиций в сектор ИТ, получила удар по имиджу.
в) Россия, как страна для развития индустрии ИТ (речь про Small&Medium Business), получила удар по имиджу.
3) У Рамблера нет ресурсов, чтобы бодаться с F5.
4) Этот случай может спровоцировать отток «идейных» мозгов из страны.

Рамблер и Сбер - компании из рода too big to fall, эта ситуация их не потопит, даже если все ИТшники уволятся одним днем и все разом. Однако в долгосрочной перспективе это снизит их конкурентоспособность, как игрока на рынке.

Именно поэтому действия истца (истцов?) крайне недальновидны, кто бы им(-и?) ни был(-и?).

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

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

Однако к обозначенному выше добавляются еще и расходы на сотрудников. Дескать раз подсел на иглу Безоса, будь добр еще нанять очень дорогого специалиста за «300 кк/нс».

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

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

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

Во-вторых, если вы имеете свои вычислительные мощности в ЦОДах, то у вас наверняка есть инженеры-«железячники», сетевики, системные инженеры и прочий персонал, обслуживающий физический уровень вашей инфраструктуры.

Не знаю, как в РФ и СНГ, но в Нидерландах человек уровня CCIE стоит гораздо дороже человека со всеми проф. сертификациями AWS.

Ваше пятничное зрелище - доклад несравненного @apple_rom на тему Multi-Account Strategy в AWS.


https://www.youtube.com/watch?v=Au1MGWiriGM

Вместо информационных сообщений, хочу чтобы мониторинг отправлял мне это в случае аварии. ^

Повезло посетить офис Яндекса. Никаких сюрпризов или фокусов - просто приятели пригласили "на экскурсию".

Что можно сказать: офис на Льва Толстого очень крутой. Большой, красивый, самодостаточный и запутанный. Красивые переговорки, стекла кабинетов либо замутнены, либо закрыты занавеской. Внутри начала потихоньку снедать тоска по "энтерпрайзу".

Показали Иконостас. Не уверен, что могу рассказывать, что это, но кто в теме - поймут.

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

1. Все странные названия сервисов и технологий, которые гуляют в интернете про Яндекс, на самом деле очень логичны (особенно когда тебе рассказывают, почему они так называются).
2. В Яндексе (ну и не только - любой технологический крупняк этим страдает) набирают людей, проверяя только фундаментальные знания в области CS. Никому ваши знания куба и авса не нужны. Разворачивайте дерево и рассказывайте про inode. Причины просты - в Яндексе все свое, и это "свое" всегда нужно учить с нуля. Высокий грейд выбивается хадкорными навыками программирования и знаниями сетей, ОС и т.д.
3. В Яндексе все свое не потому, что людям нравится писать инфраструктурщину. Просто проблемы, которые большинство решает, найдя хороший OS проект, к Яндексу приходят задолго до появления оного. Почему LinkedIn разработал Kafka? Потому что Kafka тогда не существовала.
4. По этой же причине в Яндексе, по слухам, несколько реализаций MapReduce. Нет, люди не любят каждый раз с нуля писать MR. Просто "тот" MR под задачи конкретной команды не ложится, приходится делать свой. В итоге эволюционным путем все консолидируется в один, эталонный MR. Или нет.