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

Среди 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/

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

Пятничное от @theaftertimes

Амазон в этом году в ударе, но есть два новшества, вызывающие у меня сомнения.

Ground Station, сервис по сборке телеметрии со спутников на орбите, может выглядеть «прикольным» для маленьких студенческих проектов, но я слабо представляю, как NASA или, прости Господи, Роскосмос и ESA будут пропускать данные через «агентов госдепа».

AWS Outposts выглядит более «приземленным». Если вкратце - вы заказываете у Амазона оборудование, устанавливаете его в своем ЦОД и управляете им через консоль и API. Это выглядит интересно для организаций, которые по ряду требований должны хостить что-либо у себя «дома», однако это убивает главное преимущество Амазона, когда о твоей инфраструктуре печется кто-то другой. Другое дело, что этот сервис должен конкурировать со схожим сервисом от Azure и предназначен скорее для кровавых энтерпрайзов, которые держат все внутри.

Но я не могу представить себе кровавый энтерпрайз, который ну очень сильно хочет в Амазон, НО - у себя дома. Тем более при условии, что Амазон берет на себя управление этими машинами (установка обновление и обслуживание), что уже говорит о том, что у «левых дядек» есть доступ к инфраструктуре, а значит и к данным.

Помимо этого Outposts пока что поддерживают только запуск инстансов ЕС2. В будущем планируется внедрить поддержку RDS, ECS, EKS, SageMaker и EMR. Как по мне, локальные S3 и DynamoDB выглядели б гораздо интереснее.

О бывшем работодателе либо хорошо, либо NDA.

Все почитали статью “We need to kill DevOps”?

Если нет, то вот вам оригинал (http://ageofpeers.com/2017/09/14/we-need-to-kill-devops/) и перевод (https://realitsm.ru/2017/11/my-dolzhny-ubit-devops/)
Я читаю оригинал, так что за качество перевода не ручаюсь.

Во-первых, желтушные заголовки это то, что я жду от криптожурналистов из CNBC или авторов контента на всяких BuzzFeed и прочих HuffingtonPost, но никак не от коллег по цеху.
Во-вторых, считать, что DevOps виноват в том, что люди “неправильно” его внедрили, запилив DevOps инженеров и DevOps команды, то же самое, что обвинять Sinterklaas’а в том, что белые дети в школах дразнят черных детей Zwarte Piet’ами. Проблема расизма в школе это проблема расизма, а не псевдоистории (кстати, офигенной истории!), превратившейся в детский праздник. Проблема все еще живого Silo в DevOps это проблема внедрения культуры, а не самой культуры.

Предложение заменить все должности в разработчиков (т.е. разработчик приложений, разработчик БД, инфраструктурный разработчик) тоже не решение - можно назвать утку карасем, но она не перестанет крякать.

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

Есть два простейших способа сделать у себя DevOps без выноса мозга и бессмысленных ребрендингов.

1. Берем условных Ops, они создают foundation и предоставляют свои сервисы именно как СЕРВИСЫ. Если разраб хочет виртуалочку - два клика на условном портале. Если разраб хочет мониторинг - два клика на условном портале. Хочет развернуть приложение - два клика (ну ладно, три). Все запросы от разработчиков либо идут через самообслуживание, либо решаются сами благодаря автоматизации.
2. Разбиваем Ops и Dev на условные продуктовые команды, внутри которых уже есть нужное количество Ops, Dev, QA и кого бы вы туда не захотели поставить. Заодно решаем проблему “свободы”, когда команда А хочет писать на .NET, команда B хочет запускать свои приложения в k8s, а команда C хочет юзать Java и Oracle.

Серьезно, коллеги, 2018 год приходит к концу, культуре уже почти 10 лет, а мы до сих пор не разобрались как ее “правильно” готовить, потому что в условном кровавом энтерпрайзе ее “приготовили” “неправильно”. Виновата в этом, разумеется, культура.

Порадуйте фаната DOOM, сделайте мне 666. ^^