А вот и завезли.

В продолжение https://news.1rj.ru/str/manandthemachine/468.

Когда я по дурости посетил интеграционный тренинг, британка, живущая в Нидерландах последние лет n-цать, рассказывала о своей дочке. Школьница однажды принесла домой тройку и на недовольную реакцию матери сказала следующее: «Ну маааам, все нормально, у нас в классе все так написали контрольную!»

В Нидерландах очень интересно смешиваются две повесточки: индивидуализм и «будь как все».

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

Ноги хоть и растут оттуда, но в результате у вас может получиться очень интересный диалог с руководителем, если вы захотите выбить себе повышение, аргументировав это количеством Х закрытых задач или Y успешно завершенных проектов, руководитель вам на это скажет, что другие тоже работают на максимум, и поднять зарплату всем он не может. То, что работающие на максимум не делают и трети того, что делаете вы, будет игнорироваться. Они же стараются!

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

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

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

При этом я прекрасно понимаю, что не будь у нас S.M.A.R.T. целей, человек мог бы расчитывать на неплохую прибавку. Результаты неважны, важен процесс.

Так что делать вид, что ты невероятно занят, бегая из одного места в другое, иметь календарь полный afspraak’ов - здесь это навроде национального вида спорта.

Супруга говорила, что французы работают точно так же, так что есть подозрение, что эта хворь идет по всей Европе, если не везде.

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.