Человек и машина

Ваше пятничное зрелище - доклад несравненного @apple_rom на тему Multi-Account Strategy в AWS. https://www.youtube.com/watch?v=Au1MGWiriGM

Противники публичных облаков нередко выступают с очень валидной аргументацией, а именно - ценой. Лукавить не стану - с учетом девальвации, облака большой тройки выглядят неприемлемо дорого, а аренда физических мощностей в colocation в России обойдется на порядок дешевле (даже с учетом накладных расходов). Однако к обозначенному выше добавляются еще и расходы на сотрудников. Дескать раз подсел на иглу Безоса, будь добр еще нанять очень дорогого специалиста за «300 кк/нс». Во-первых, нанимать отдельно выделенного амазонщика, чья работа будет заключаться только в обслуживании самого AWS, как минимум дорого, как максимум - неэффективно. Если контора совсем не умеет в AWS, то на старте условный амазонщик нужен, чтобы заложить фундамент и проводить необходимое внутреннее обучение. В дальнейшем подразумевается, что амазонщик может выступать в качестве специалиста по этому домену, но если оставить AWS его единственной вотчиной... очень необоснованная трата денег. Амазонщик в конторе, повторюсь, где все набили руку и знают как и что поднимать - документация с руками и ногами, ему уже нет смысла заниматься только AWS. Напротив, этот человек может и должен принимать участие в проекте в качестве системного инженера или разработчика. Если вы давно сидите на игле публичного облака, но у вас все еще есть отдельный человек, или того хуже, целая команда по AWS - вы что-то делаете не так. Во-вторых, если вы имеете свои вычислительные мощности в ЦОДах, то у вас наверняка есть инженеры-«железячники», сетевики, системные инженеры и прочий персонал, обслуживающий физический уровень вашей инфраструктуры. Не знаю, как в РФ и СНГ, но в Нидерландах человек уровня CCIE стоит гораздо дороже человека со всеми проф. сертификациями AWS.

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

Получил оценку и отзывы по своему докладу на HL++. Хочу поблагодарить всех смотревших и присутствовавших за конструктивную (и неконструктивную) критику. Все замечания будут приняты в работу без исключений. Если среди слушателей были мои читатели - отзовитесь! Я буду признателен, если вы напишете, чтобы вы хотели от меня увидеть и услышать в будущем - обозримом или далеком.

It is Friday, my dudes.

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

Если объединить все «недостатки» нидерландцев как работников, можно придти к выводу, что работать с ними просто невозможно. Некоторые моменты действительно очень мешают в работе, поэтому мне приходилось применять принцип «Ask for forgiveness, not permission». Как ясно из названия, такой подход подразумевает «наплевательское» отношение к субординации, цепочке принятия решений и всем прочим практикам в индустрии, придуманным и обкатанным задолго до рождения прогрессивных гибких менеджеров и разработчиков. Проще говоря, вместо того, чтобы лишний раз проговорить и проверить гипотезу с коллегами, stakeholder’ами и руководством, вы просто берете и делаете. Нюанс в том, что большинство решений и действий всегда можно «откатить» назад (в конце концов вы просто специалист, а не СХО), а если идея и впрямь хороша и работает, то никто вам по шапке не даст - скорее, демонстративно пригрозят пальчиком, но подмигнут. Понятное дело, для таких фокусов надо обладать толстым кредитом доверия и о-го-го какой экспертизой, иначе вы с большой долей вероятности знатно обосретесь. Ну и проворачивать такое в enterprise секторе точно не стоит. Нравятся ли вам цепочки принятия решений из десятков человек или нет - они там не просто так.

Первое: в Питере 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 как платформа для разработки и эксплуатации» Ждем всех и до скорой встречи!

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

#нет_это_не_реклама Тут LinuxAcademy завез немало халявы: https://linuxacademy.com/blog/announcements/free-courses-at-linux-academy-december-2019/ От себя добавлю, что курс по CloudFormation точно стоящий (остальные не трогал).

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

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

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

​​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

Собственно в чем была проблема. Мы объявили кластер БД и в качестве свойства присвоили ему идентификатор SG. Мы объявили SG и всвойстве ее правила поставили атрибут кластера БД. Ни один из ресурсов еще не создан, и CFN не может выстроить граф зависимостей, чтобы принять решение, какой ресурс создать первым. Решение задачи гуглится на раз-два по тексту ошибки, но экспертный эксперт сразу смекнет: в AWS все есть API и, чаще всего, все есть ресурс. Правило SG, будь оно на входящий или исходящий трафик, также является отдельным ресурсом типа

AWS::EC2::SecurityGroup[Ingress,Egress]

Чтобы решить эту проблему, достаточно создать “пустую” SG и добавить еще один ресурс ниже (или выше):

SecurityGroupRule:
  Type: “AWS::EC2::SecurityGroupIngress
  Properties:
    IpProtocol: tcp
    FromPort: !GetAtt Db.Endpoint.Port
    ToPort: !GetAtt Db.Endpoint.Port
    GroupId: !Ref Sg

В копилку вопросов на собеседование амазонщиков. Уровень сложности: 400 Ситуация: у вас имеется CFN шаблон с двумя ресурсами: RDS DB Cluster и EC2 Security Group. Шаблон выглядит следующим образом:

Sg:
  Type: “AWS::EC2::SecurityGroup”
  Properties:
    # some props...
    SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: !GetAtt Db.Endpoint.Port
        ToPort: !GetAtt Db.Endpoint.Port

Db:
  Type: "AWS::RDS::DBCluster"
  Properties:
    # some props...
    VpcSecurityGroupIds:
      - !Ref Sg

При валидации этого шаблона вы получите следующую ошибку:

An error occurred (ValidationError) when calling the ValidateTemplate operation: Circular dependency between resources: [Db,Sg]

Что говорит нам о том, что два ресурса имеют блокирующие зависимости друг от друга. Вопрос: как решить эту ситуацию, при условии что: 1) Разносить SG и кластер БД в разные шаблоны нельзя. 2) Хардкодить порт базы нельзя. P.S. Завтра выложу ответ.

А вот и новый шот с Highload++ 2019. Карен Товмасян сотоварищи помогает разобраться нам, почему же думать о бэкенде надо даже больше, чем о фронтенде и при чём здесь AWS. https://www.patreon.com/posts/31693261 А вот и ссылочка на канал Карена @manandthemachine