https://panorama.pub/25978-iskusstvennyj-intellekt.html

Люблю начинать неделю с таких новостей.

P.S. Я надеюсь, все понимают, что это шутка?

Представьте такую ситуацию.

Вы нидерландец, воспитанный по принципу normaal doen (будь нормальным, как все), при этом имеете то самое зерно индивидуализма, от которого отказываться совсем не хотите.

Как выпячивать свою индивидуальность в жизни и работе, при этом оставаясь «своим»?

Вопрос, конечно, риторический.

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

Недавно со мной приключился один кейс. Разработчик, нанятый контрактор, попросил настроить site2site между его GCP и нашим AWS.

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

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

Чтобы не саботировать процесс (проект очень важный), пошел навстречу. Настроил VPN соединение, отплевался от GCP, создал сертификаты для аутентификации, все чин чином.

Позже спросил у контрактора, зачем он вообще полез в GCP, да еще и в Kubernetes. Ответ был шикарный: я в AWS не разобрался, а у GCP простой и понятный интерфейс.

Стоит ли добавить, что в GCP и Kubernetes он тоже совсем не разбирался, и я рассказывал ему их внутренности?

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

В мелких же можно устроить соревнования по фаллометрии. Итог все равно один - зовут меня делать нормально.

Кстати, CFN полез в multi-cloud (термин и подход, запрещенный в AWS): https://aws.amazon.com/about-aws/whats-new/2019/11/now-extend-aws-cloudformation-to-model-provision-and-manage-third-party-resources/

Зачем теперь нужен Terraform?

С ребятами из LinkMeUp записали небольшой “шот”.

А вот и новый шот с 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, эта ситуация их не потопит, даже если все ИТшники уволятся одним днем и все разом. Однако в долгосрочной перспективе это снизит их конкурентоспособность, как игрока на рынке.

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