Нарвался тут недавно на канал “Архитектор_говорит” (@architect_says).
О том, как я туда попал (и благодаря кому попал, и что я там прочитал) я расскажу позже. (Спойлер: там хаят мои любимые микросервисы, и я просто не могу молчать.)

С автором канала я лично не знаком, наши пути вряд ли когда-то пересекутся, и это хорошо - мы думаем и смотрим на вещи совсем по-разному.
И если я готов игнорировать его мнение про “Монолит против Микросервисов”, последнее (на момент написания этого поста) сообщение я игнорировать не могу.

Итак, прямая цитата:
“У меня между делом спросили, почему это канал так называется.
Ответ очень простой - как понять, что архитектор занят работой? У него губы шевелятся.
Рот закрыл - рабочее место убрал.”

Здесь могла бы быть ваша шутка про работу ртом, но ее не будет.

Я с точностью могу сказать одно: я не пройду собеседование у господина @meowthsli, а он не пройдет его у меня (даже если мы будем разговаривать по темам из TOGAF, игнорируя конкретику вроде построения вычислительных систем на базе Java + Oracle или AWS).

Не нужно читать множественные job desctiption’ы и описания вакансий ИТ архитекторов, Solutions архитекторов, системных архитекторов, да каких угодно, чтобы знать, что архитектор, в первую очередь, проектировщик, исследователь, и в некоторых случаях, прораб и исполнитель.
Почему вы никогда не видели и не увидите junior архитекторов? Потому что их не существует. Эта должность, титул или роль зарабатывается очень много времени, за которое нужно проделать огромный пласт работы, побывав на обеих сторонах баррикад (Ops и Dev разумеется), обладая экспертизой не в одной, но нескольких областях.

Когда вы назначаетесь на проект архитектором, вы должны не только спроектировать, спрототипировать и собрать “скелет” будущего продукта, но и донести до всех (ВСЕХ) stakeholder’ов, исполнителей (разрабов и админов), до бизнеса, если понадобится, почему надо именно так и никак иначе. И это - первая и единственная часть, которая реализуется ртом (а еще с помощью Visio/Lucidchart и несколькими написанными заранее версиями будущего продукта). После этого вы будете продолжать общаться с людьми, но уже по конкретным вопросам и часто меняя структуру продукта по разным причинам.

Считать после этого, что архитектор работает ртом, а его главные job tools это переговорка, листки с бумажками, ментальные шаблоны и прочая менеджерская шушера как минимум странно, как максимум - абсурд.

Есть должности, в которых софт скиллз важнее хард скиллз, но архитекторская не среди них.

Впрочем, мы с Говорящим Архитектором совсем из разных эпох, миров и прочего, и этот пост не несет в себе цели кого-то оскорбить. Автор “братского” канала приглашается к дискуссии, если конечно мой пост до него долетит.

Как говорится: “Мама, я в телевизоре!”

https://twitter.com/FelixTheBest/status/1055024780594823169

Знаете, почему я люблю Телегу? Потому что тут нет built-in комментариев.
Нравится - читаешь, не нравится - не читаешь.

Очень жаль, конечно, что Огуречный газ, вместо грамотного ответа, написал пару строк в твиттере, в то время как Амбассадоры и чувачки с драконами на аватарках ловят с меня лулзы.

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

А посмотрите выступление моего коллеги по основам мониторинга!
Будет полезно тем, кто специализируется на стеке Микрософта: https://livestream.com/gaelcolas/PSConfAsia/videos/182076933

Коллеги по цеху попросили пояснить за Serverless.

Поясняю: https://telegra.ph/Serverless-10-26

Ну что, доступно пояснил, или остались вопросы?

Если вам что-то не понравилось или непонятно - смело пишите, отвечу на все вопросы по возможности.

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

С Димой я знаком лично, зная насколько он мозговит, хочу видеть в его канале не только репостики, но и авторский контент. Давайте его растормошим.

Дима, я знаю, что тебе есть что рассказать.

https://t.me/count0_digest

Нет худа без добра.

Среди shit шторма в Твиттере, нашел бриллиантик. Пожалуй, единственный весомый камень-аргумент в огород мамкиных амазонщиков (к коим я и себя отношу, чего уж там).

Прямая цитата: “Путь таких aws-архитекторов заканчивается, когда в конце энного года наконец-то задается простой вопрос: почему мы тратим на aws 10m в год?”

Это очень правильное замечание. Я писал раньше (а может и не писал ^^), что любой переезд с платформы на платформу должен приносить преимущества, а не недостатки.

Если вы уехали, уезжаете или планируете уехать в облако, делаете это не своими силами, а силами посторонних людей или организаций, то вот краткий чек-лист, при котором человека/организацию надо гнать в шею:
- Если TCO (total cost of ownership) после переезда стал неадекватно выше, чем до (к этому еще добавьте расходы на обслуживание инфраструктуры).
- Если приложение или приложения стали валиться чаще после переезда (без существенных изменений в самих приложениях)

Про расходы все просто. Одно дело, когда продукт растет, и с объемами и новыми требованиями появляются новые расходы. Другое - когда нанятый человечек тупо назаказал огромных тачек, даже не приложив усилий к изменению структуры ИС.
Про падающие приложения надо сказать отдельно. Ни один облачный провайдер не будет гарантировать вам 100% uptime. Какие бы сервисы вы там не подняли, Амазон оставляет за собой право взять и перезагрузить вашу тачку. Если внедренец-мигратор не построил вашу структуру хотя бы вокруг ELB + AutoScaling, то его компетенции вызывают очень много вопросов.

Другое дело, что такие косяки всплывают, когда контракт закрыт, дела переданы, претензий не предъявить. Именно поэтому я всегда рекомендую переезжать своими силами.

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

P.S. Буду рад, если со мной свяжется представитель или сотрудник той конторы, которая стала внезапно тратить на AWS 10 миллионов в год (не важно RUR или USD). Если только цифры взяты не от балды, разумеется. 😉

Возвращаясь к разговору “Монолиты против Микросервисов”. Дошли глаза прочитать оригинальную заметку “Microservices are something you grow into, not begin with”, которую перевели на Хабре.
Оригинал - https://nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with
Хабр (перевод) - https://habr.com/post/427215/

Краткий конспект:
1. Не надо бежать за гуглом.
2. Shopify поднимает много денег, сидя на монолите.
3. Микросервисы, по мнению автора, всего-лишь очередной уровень абстракции.
4. Не стоит начинать с микросервисов, пока вы не написали хотя бы одной строчки кода, потому что на этом уровне вы еще не знаете, что вы пишете. (Што?)
5. Микросервисы надо начинать осваивать, когда решит ваша команда.
6. Переход на микросервисы имеет свои проблемы и нюансы. (You don’t say!)

Ух ты. Ладно.

Монолитные приложения быстрее микросервисных. Неважно, насколько сложно их обновить, какой при этом грозит даунтайм или сколько подписей нужно собрать, что выкатить новый релиз. Один метод, вызывающий другой, будет всегда быстрее, чем один контейнер, отправляющий API вызов к другому. Поэтому, если вы пишете HFT системы, АБС, кредитные конвейеры, процессинг, который должен работать чуть медленнее Visa/Mastercard, но быстрее Bitcoin, или что-то еще, где важна каждая миллисекунда - монолит.

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

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

В-четвертых, написать прототип на микросервисах, гораздо трудозатратнее (не сложнее!), чем на монолите.

Вот эти моменты гораздо важнее абстрактных “да зачем тебе микросервисы, братишка, пили монолит, че ты” и “ты че гугол?”.

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

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

Что мне очень нравится в SRE, так это то, что каждый это внедряет по-своему и не ориентируется на старшего брата Гугла.

То есть опытные ребята взяли базовые вещи (SLO, требования по мониторингу и реакции на инциденты и т.д.), но при этом не применяют правило “+1 SRE, -1 Dev” и “SRE может покинуть команду, если “задолбался”.

Хотя наверняка есть те, кто строго по книжке все делает, чего уж там.

Дима таки разразился авторским контентом! Пусть и затронул такую классную тему как Crontab в продакшоне.

Мне, конечно, дико стыдно признавать, что я использую Cron на работе (в основном не mission critical workloads, подчистить то, что нельзя стандартными средствами), но, как по мне, крон не так уж плох.

Здорово иметь централизованный планировщик задач, но отталкиваться все же стоит от задачи, нежели от решения, ведь в том же кроне можно запускать не только баш. Можно написать что-нибудь на питоне или Go. Хотите знать, если задача не отработала? Необязательно заморачиваться с exception handeling, можно просто отправлять event notification в мониторинг (тот же DataDog например) или банальный sendmail.

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

Друзья, не сказать, что у меня творческий кризис, но дел очень много что на работе, что не на работе. На данный момент пытаюсь собраться с силами и написать пост в Medium про мои приключения с AWS Database Migration Service. Из всяких приколов на работе рассказать особо нечего, бОльшая часть (как правило самый сок) попадает не только под NDA, но и strictly confidential.

Но если у вас есть какие-то пожелания, о чем почитать - напишите мне (@ThomasStorm) (Только не просите про Infra-as-Code, все что хотел рассказать, уже рассказал). Расскажите обо мне друзьям и коллегам. Больше читателей, больше мотивации, больше вопросов и, как результат, больше интересного контента.

Дорогие коллеги, а есть ли в стане амазонщики, желающие переехать в страну велосипедов и легальной травы?

Наша контора в скором времени откроет позицию инженера-архитектора AWS.
Из buzzwords, которые надо знать: Docker, DC/OS, TeamCity, AWS.
Как сказал мой шеф - бумажки не важны, важны навыки, но наличие амазоновских сертификатов сделает вас более привлекательным для моего работодателя. 😉

Свое резюме отправляйте мне на почту: thomas.storm@protonmail.com
Вопросы сюда - @ThomasStorm

Между делом книжку, на которую мне все было жалко денег (Database Reliability Engineering), и много других раздают за сущие копейки: https://www.humblebundle.com/books/dev-ops-oreilly?hmb_source=navbar&hmb_medium=product_tile&hmb_campaign=tile_index_3

Десктопный клиент телеги теряет отступы и тем огорчает меня. Скоро верну пост.

Опечатался, что ваш Трамп с cofveve. :))

У меня сейчас будет даже не пост БОЛИ, но скорее вопрос с коллегам из разработки.
Я писал раньше о своих приключениях с Graphite-Statsd. Так вот, наш Statsd слушает на udp. Это удобно, если по каким-то причинам коннект к машине отвалится на небольшой срок, это не будет иметь никакого эффекта на приложения, отправляющие метрики.

Однако наши ребята используют connected UDP, что означает, что приложение будет отправлять дейтаграммы через открытое соединение (если, конечно, я правильно понял, как оно работает). Что означает, что временная (даже секундная) недоступность Statsd или разрыв соединения приведет к необработанному исключению в нашем коде Scala, потому что библиотека не умеет в reconnect, а разрабы не написали обработчик, пересоздающий соединение в случае отказа.

И вот к чему это я. Вопрос к аудитории: в чем смысл использовать connected UDP, а не TCP? Поскольку получается, что мы используем UDP без преимущества UDP. Но прежде чем косплеить Лаврова (“Дебилы, бл*ть!”), хочу убедиться, что я не упорот.

Всем “вижу” и хороших выходных.

Автор ушел на перерыв аггрегировать советы читателей и разбираться в этом вашем Connected UDP и, наконец-то, вернулся.

Прежде чем открывать портал в ад, надо сделать небольшое замечание - наш backend работает на Akka.
Для отправки метрик в Statsd используется форк akka-statsd (https://github.com/NewMotion/akka-statsd).

Внутри него настройка соединения построена по методу Connected UDP (https://doc.akka.io/docs/akka/2.5.3/scala/io-udp.html#connected-udp)
Итак, Connected UDP работает по схожей с Bind-and-Send модели. Единственная существенная разница в том, что JVM Java SecurityManager (если включен) закеширует security check после соединения один раз, что уменьшает нагрузку на ЦПУ и увеличивает производительность (при Bind-and-Send security check проходит каждый раз).
Внутри Connected UDP идет Bind к удаленному адресу и порту. Метод, создающий соединение тут (https://github.com/NewMotion/akka-statsd/blob/master/akka-statsd-core/src/main/scala/transport/udp/SingleAddressConnection.scala#L24).

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

def working(initiator: ActorRef, socket: ActorRef): Receive = {
    case Deliver(msg) =>
      log debug s"UDP delivery of stats message $msg"
      socket ! Send(ByteString(msg))
    case CommandFailed(Send(payload, _)) =>
      val msg = payload.utf8String
      log warning s"Unable to deliver message: $msg to $remoteAddress"
      sender ! DeliveryFailed(msg)
  }

Тут я перестаю косплеить ДиКаприо из “Начало” и останавливаю исследование.
Что известно на данный момент: CommandFailed это исключение, получаемое от методов Akka UDP, то есть, где-то под капотом Akka.
Внутри Akka, как сообщили коллеги, при недоступности порта даже на мельчайший срок, происходит IOException, который выдает наверх CommandFailed. Работать это начинает только после рестарта приложения, работающего с akka-statsd.

Мозгом я понимаю, зачем использовать Connected UDP. Этот способ может худо бедно гарантировать доставку трафика, не нагружая систему как с TCP, но, как выяснилось, у нас не используется JAVA SecurityManager. То есть смысла использовать именно Connected UDP нет.

Требование гарантировать доставку метрик отпало, как минимум год назад, еще до моего устройства в контору, и понадобилось пару downtime’ов, чтобы разрабы запилили UnConnected UDP и стали потихоньку обновлять приложения. Почему нельзя реализовать пересоздание connect, для меня остается тайной.

Живем дальше. Отдельное спасибо @sakalr и @Civiloid за пояснение.

Вчера на очередном собрании департамента парни из Core команды продемонстрировали новую “фичу” нашего продукта. Новое поколение зарядок способно определять пользователя в тот момент, когда он подключает свою Тезлу (и не только) к зарядной станции, автоматически запуская зарядку и тарификацию. Пользователю больше нет необходимости иметь при себе токен или карточку, чтобы запуститься. Как тебе такое, Илон Маск?

Самое интересное в таких демо сессиях, когда ты знаешь, как работает изнанка. И самое страшное, когда ты знаешь о ее проблемах.

В последние 2 недели я был занят перетаскиванием трафика на наши вебсервисы со старого балансировщика (ELB Classic) на новый (ALB), и пока я перенастраивал DNS имена), я решил поковыряться в одной проблеме, которая мучает наших разрабов уже как полгода.

Есть некоторые зарядные станции, которые по непонятным причинам переподключаются к зарядной сети. Мы не до конца понимаем, где проблема, связана ли она с некорректной прошивкой зарядки, проблемами на зарядной или вычислительной сетке. Но как это обычно бывает, разраб сетует на компьютерные сети, и я решил проверить, решает ли вопрос замена балансировщика на более оптимизированный под WSS.

Это не помогло, глаз у меня и у разраба горел, и мы стали ковыряться глубже. И чем глубже мы залезали в этот омут, тем больше косяков вылезало.
Мы выяснили, что:
- Не все логи попадают в ElasticSearch, часть буквально теряется.
- Приложение, отслеживающее статус зарядных станций, теряет половину трафика.
- Версия Traefik в нашем продакшене, имеет кучу известных багов в работе с WSS. Последний известный из них был пофиксен в версии, срелизенной месяц назад.
- Некоторые кнопки на внутреннем портале зарядной сети выдают ошибки при работе с “проблемными” станциями.

И что самое ужасное - статус страница говорит, что все приложения feel fine. Перетащив часть приложений из prod я не получил ни одной весточки от разрабов с аномалиями.

И когда я смотрел, как наши корабли бороздят просторы вселенной, у меня перед глазами была лишь картинка из Doom Eternal, где среди полчищ демонов и щупалец торчали наши Lolo3.

Нарвался тут на обсуждения про допустимость ошибок в ИТ индустрии. Дескать, во многих сферах из-за ошибок и косяков гибнут люди, а в ИТ часто косячить это нормально.

Во-первых, далеко не в каждом бизнесе встречается толерантность к косякам со стороны ИТ. Одна из причин “медленного” производства ИТ продуктов в таких компаниях, как банки, госсектор, добыча ресурсов, фин сектор, трейдинг, оборонка, космическая и авиационная отрасль и т.д., в том, что обновления софта проходят (либо должны проходить) многодневную скрупулезную проверку качества поставляемого продукта. Иными словами, там полный ITIL/ITSM с change management’ом, когда под малейший патч подписывается огромное количество ЛПР.
Во-вторых, похожим образом ведут себя разработчики криптовалют из топ 5, в частности разрабы Bitcoin. На кону не только их репутация, как спецов, но и репутация самого битка, которая и так страдает от нападок экономистов из общего сектора классических фин. инструментов.

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

Те, кто меня давно читает, помнят мою историю, когда я облажался с настройкой DHCP серверов, задав неправильные октеты CIDR в Puppet. Тогда это проверилось serverspec’ом и code review, но косяк все равно прошел и обрушил половину серверов в продакшене. Я отделался лишь тем, что с позорным лицом (не хватало еще тетки с колокольчиком из Игры Престолов) ходил с печеньями от комнаты к комнате, раздавая их и рассказывая, что я наделал и почему так больше не буду.

Впрочем не я первый и не я последний, кто ломал прод в этой конторе. В employee handbook для сотрудников Coolblue Tech фигурировала строчка: Fail more often.
Agile Coach, проводивший для меня и других новичков тренинг по Scrum, говорил: “Если вы боитесь что-то трогать в текущей инфраструктуре, например, обновлять ОС на серверах СУБД - делайте это чаще.”

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

Уставы ICAO (Международная Организация Гражданской Авиации) написаны кровью. Каждый разбившийся самолет, каждый сбитый малайзийский боинг служат поводом для пересмотра и обновления правил, которым следуют (и должны следовать) все авиаперевозчики.

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

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

https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/

Machine learning здорового человека. Больше не придется руками возиться с scheduled scaling policies.

Попался на глаза проект LocalStack, фреймворк, эмулирующий API Амазона на локальной машине.
Идея проекта - облегчить жизнь разработчикам, разрабатывающим и тестирующим свои приложения, тесно взаимодействющие с AWS.

Проект активно развивается и в будущем планирует поддерживать не только больше сервисов Амазона, но и сервисы других облачных провайдеров.
Из того, что ну очень понравилось - можно не только эмулировать соединение к ресурсам, но и создавать ресурсы и объекты внутри них. То есть, можно создать S3 bucket локально и загрузить туда файлики. Тоже самое касается очередей SQS и таблиц DynamoDB.

На данный момент к установке доступно Base Edition, поддерживающее определенный набор сервисов, а в будущем разрабы обещают махровый enterprise-edition за деньги, но с официальной поддержкой со всеми вытекающими.

Подробнее про проект можно почитать тут (https://localstack.cloud/), а репозиторий проекта доступен здесь - https://github.com/localstack/localstack

https://aws.amazon.com/about-aws/whats-new/2018/11/s3-batch-operations/

2018-ый год подходил к концу, Амазон наконец-то внедрил batch операции в S3.

Минутка оффтопа: в докер завезли третьих героев https://hub.docker.com/r/bmst/h3demo/

(Поправка: завезли его туда уже давно)