А вот и новый шот с Highload++ 2019. Карен Товмасян сотоварищи помогает разобраться нам, почему же думать о бэкенде надо даже больше, чем о фронтенде и при чём здесь AWS.

https://www.patreon.com/posts/31693261

А вот и ссылочка на канал Карена @manandthemachine

В копилку вопросов на собеседование амазонщиков.
Уровень сложности: 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. Завтра выложу ответ.

Собственно в чем была проблема.

Мы объявили кластер БД и в качестве свойства присвоили ему идентификатор 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

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

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