Как можно раздуть стоимость проекта на 1.5 пользователя? Об AWS, девопсе, контейнерах и микросервисах

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

Потом пришел Kubernetis, и эта идея стала мегапопулярной. Я думаю многие из вас набирали EC2 инстансы и разворачивали на них кластеры. Очень удобно. К примеру, набрал три EC2 инстанса по 16ГБ и 4CPU, и твои 10 микросервисав кубернетис по ним раскатал равномерно. И отказоустойчивость вам, и доступность, и еще и экономия ресурсов за счет шаринга.

Потом AWS сказал, а зачем вам вообще парится с этими EC2 инстансами, которые являются виртуальный машиной по-сути. Мы вам дадим Fargate. Вы нам просто говорите сколько каждому контейнеру(ок, ПОДу) нужно. А дальше мы уж сами разместим их как нужно. Казалось бы, действительно хорошо. У нас на один уровень инфраструктуры стало меньше. Разработчики рады, девопсы пьют пиво. Но заметили ли вы, что мы уже ушли от идеи шаринга ресурсов? Теперь мы каждому контейнеру(хорошо, хорошо ПОДу) выделяем фиксированные ресурсы. И если у вас контейнер потребляет по пол ложки CPU в час, AWS не забудет билить вас за весь CPU.
И вот, изначальная, очень хорошая идея экономии куда-то испарилась.

Теперь вспомним как начинается любой проект: Tech lead становится к доске и рисует микросервисы будущего проекта. Надо по-больше, чтобы в резюме хорошо смотрелось. Да и заказчик, зачастую приходит с запросом навалить ему микросервисов по-больше, ибо модно. И еще не забыть про отказоустойчивость и доступность.

И в итоге, приложение, которым будет пользоваться 35 человек 8ч часов будет крутиться на AWS за 10К USD в месяц.
Это реальный кейс. 35 пользователей и 10k USD в месяц. И никого это не смущает.

Вот и ролик в тему вам под кофеек: https://www.youtube.com/watch?v=nqa_Uyz1pBE

Я считаю что layered architecture — худшее что может случиться с проектом.
Появляется спонтанно, не несет никакой упорядоченности, и в конечно итоге скатывается в big ball of mud. Всегда.
Не сдержался, записался видео на тему https://youtu.be/lvUK92gYrn8

С радостью обсужу в комментариях 😉

Разобрали проблемы Layered Architecture, теперь поговорим о чем-то позитивном. Например о Clean Architecture и как она решает проблемы, созданые Layered Architecture https://www.youtube.com/watch?v=A37crsbFYeo

Почему Hexagonal Architecture лучше Layered Architecture, почему с ней проекты реже превращаются в big ball of mud? Потому что она точнее описывает правила и оставляет меньше возможностей для различной интерпретации. Вот скажите разработчикам “используем Layered architecture” и один сделает зависимости из домена на слой доступа к данным, а другой наоборот. Один решит что можно и пропустить слой домена и вызвать из API сразу Repository, чтобы сохранить несколько тактов процессора. А другой решит что так нельзя. И каждый из них по-своему прав. Слоненка она такая…

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

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

Очень интересно. А мы попытаемся разобраться в причинах.

Я решил подвести итоги по опросу:
70% Layered Architecture превращается в Big Ball of Mud
и только 9% Clean Architecture.

Поделился своими выводами вот здесь https://youtu.be/zl-wsU_Frd4

Господа, продолжение цикла про Clean Architecture. На этот раз рассматриваем на примере. И без кода! https://youtu.be/W6jCUNb3yPg

Реальная история как я ходил на собеседование.

Позвали меня в финтех-стартап местный в Сингапуре пособеседоваться на Principal Engineer. HR говорит все будет easy, приди, вы там с инженером поговорите по-душам о ваших любимых программистах штучках и все. Никакого верчения деревьев на время.

Прихожу:
- Привет
- Привет
- (и с порога) Что ты можешь сказать о коллекциях в Java?
Тут мне показалось что хорошего диалога не выйдет. Ну, оказалось что не казалось
- Ну говорю, чего там у нас Collection, который вроде как Iteratable, и Map в стороне сиротливо стоит. Ну и вот от коллекшена унаследованы, List, Set, Queue и что там еще
- а еще там Стек есть.
- Круто, да.

- Ну ок, а расскажи как HashSet работает
⁃ Я говорю черт его знает, надо будет — посмотрю исходники. Но название намекает на то что внутрях то используется HashMap. Вот ключ явно Хеш, а значение… хим, может сам объект, может Список а может еще что
⁃ Знаешь, а там вот дерево используется
⁃ Круто. Рад за них

⁃ Как реализована SyncronizedHashMap?
⁃ Ну говорю, в жизни не видел, так как она вроде устарела еще до моего рождения, но намекает что наверное ацессоры синхронизированы.
⁃ Мммм, ну там не сам аццессор синхронизирован, а бакет внутри мапы.
⁃ Круто, расскажи мне еще про бакеты 🙂

И вот так мы беседовали час. Ну думаю, либо я сейчас уйду и меня будут считать полным идиотом, или я все таки попробую перевернуть эту ситуацию. И говорю:
- То есть, у вас в проекте используется вся эта асинхронщина каждый день?
⁃ Нет, какой там.
⁃ Ну то есть планируете использовать в будущем
⁃ Ну может быть когда-нибудь, но до этого далеко
⁃ Хорошо, а какие у вас сейчас проблемы?
⁃ Ну у нас нет ни тестов, ни архитектуры. А как оно работает мы сами не до конца понимаем (я вот не шучу сейчас).
⁃ То есть мы с тобой потратили час времени на то, чтоб говорить о вещах, которые совершенно не релевантны проекту, но зато не поговорили действительно о том что вам нужно, и на что у меня даже есть бесплатный курс?
Молчание было мне ответом….

Мне очень хотелось сказать: Вот тут мое мнение, что нужно спрашивать на собеседованиях. Если не согласен — напиши комментарий. И лайкнуть не забудь.
Но меня же мама с папой учили что грубить людям нельзя, поэтому я, видимо остался без нового подписчика 🙂

На контрасте. Еще одно собеседование из моей жизни

Опять собеседуюсь на Principle Software Engineer (Lead Team Lead’ов) в один финансовый стартап.

Этап технического собеседования. И мне предлагают вот какую задачу:
Наше приложение принимает много транзакций о покупках пользователей от разных источников. Кто-то отсылает в режиме реального времени, кто-то засылает батчами до 10к транзакции за раз.
Мы уже сделали этот функционал, и хотели бы посмотреть как ты спроектируешь его.

Мы с ними интересно пообщались: я узнал у них реальные не функциональные требования, предложил решения их болей из моего опыта. И мы вместе нарисовали диаграмму to-be системы.

Очевидно что ребята знали как делать эту штуку лучше меня, они долго обсуждали как именно ее сделать и сделали. Но эта задача им позволила узнать
- насколько им комфортно со мной обсуждать задачу
- насколько глубоко я могу проработать проблему
- беру ли в расчет нефункциональные требования; и какие; и как они реализовывются “во плоти”
- как мы будем это все тестировать
- насколько удобно это будет разрабатывать на локали.
- А вот какой в конечном итоге получилось решения мне кажется их не сильно волновало. Но, кстати, получилось почти как у них.

Вот на мой взгляд это пример очень хорошего подхода к собеседованиям!

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

Кстати, как вам подход? Напишите в комментариях какие ваши любимые подходы к собеседованию и почему. Обсудим!

Амазон Prime Video сократил стоимость инфраструктуры на 90% перейдя с микросервисов на монолит.

Сразу оговорюсь, не весь Amazon Prime, а конкретное подразделение, следящие за качеством видеопотока на наших с вами ноутбуках, мобильниках, и где мы там еще смотрим видео.

Сейчас на пальцах объясню что произошло:

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

И они очень логично решили, что один сервис будет нарезать видео на кадры, складывать их в Amazon S3 (файлохранилище), а толпа других (анализаторы) будет из S3 читать скриншоты и искать дефекты.
Плюшки подхода:
- они могут масштабировать сервисы независимо друг от друга
- использовать amazon Lambda
- они легко могут добавлять новые анализаторы и старые ничего об этом не узнают.
И тут все очень логично. Я не могу их обвинить в злоупотреблении микросервисами. Ей богу, я бы сам так же сделал!

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

В итоге:
Они решили что обмен данными внутри процесса будет намного дешевле и слепили эти микросервисы в монолит, попутно выпилив S3, так как скриншот передается теперь просто в памяти.

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

Вот так… 90% экономия на инфраструктуре. Впечатляет!

Расскажите в комментариях, что вы сами думаете о микросервисной архитектуре, приходилось ли вам видеть проект написанный на микросервсиах ради микросервисов?

Пруф: https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

10 июня стартует обучение новой группы по практическому курсу "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

С сегодняшнего дня объявляем предзапись на курс. Тем, кто оплатит курс до конца месяца, делаем скидку в 5000 рублей. Цена со скидкой 85 000 руб. Есть рассрочка.

Чтобы воспользоваться скидкой, надо "застолбить место" на сайте howto.stringconcat.com/enterprise и оплатить до 30 мая часть курса. Бронь места идёт в счёт тарифа (НЕ допом к тарифу).

На весь курс набираем всего 25 человек. 7 мест уже занято. (Если вы договаривались о записи раньше, то скидка будет автоматом)

В отличие от тарифов «экспресс» и «базовый» в "максимальной прокачке":

- практические занятия через ZOOM (живое человеческое общение), возможность задавать любые вопросы и сразу получать ответы.
- общение с авторами курса в Telegram
- дополнительные материалы/встречи, которые Евгений и Сергей дают специально под уровень группы по ходу обучения
- доступ в закрытое сообщество выпускников, где наши ученики вместе с авторами поддерживают друг друга и обмениваются опытом применения полученных знаний на практике при внедрении в команду.

Что ожидать от курса?
(При условии, что вы посмотрите все лекции, сделаете практику, будете активно участвовать во всех живых встречах и прочтёте хотя бы часть из списка литературы)

1. Систематизация знаний и преодоление синдрома самозванца. Изучение принципов и основных граблей энтерпрайза.
2. Полное руководство по созданию энтерпрайз-приложений.
3. Анализ, что не так с вашим приложением, и разработка плана по его улучшению.
4. Подготовка к собеседованиям в крупные компании, после которой вас не поставят в тупик вопросы про SOLID

Для записи переходите на сайт и выбирайте тариф «максимальная прокачка»: howto.stringconcat.com/enterprise

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

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

Петя, из-за тебя релиз вышел на три дня позже срока и всем пришлось работать до ночи. Заказчик был очень недоволен. Разве сложно написать три строчки кода, чтобы покрыть изменения после фикса бага?

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

Как это исправить? Для этого умные люди придумали SCARF-модель, которая построена на удовлетворении 5 критически важных для мозга социальных потребностях: статус, определенность, автономность, принадлежность и справедливость.

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

Опустим закадровое желание побить Петю и посмотрим, что дает такая формулировка:
🔹+2 к статусу ("без тебя не смогли", "нам важна твоя работа")
🔹+1 к определенности (ты, конечно, налажал, но мы тебя не выгоняем)
🔹0 про автономность (увы)
🔹+1 к принадлежности ("команда")
🔹+1 к справедливости (ты что-то сделал, оно привело к таким-то последствиям, вот что тебе нужно сделать, чтобы исправить ситуацию).
Итого: 5 баллов.

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

ArchDays

27-го октября пройдет конференция ArchDays. Мы начинаем отбор выступлений.

Темы выступлений:
- Процессы проектирования
- Практики проектирования
- Инструменты проектирования
- Обучение архитектуре
- Собственная разработка

В предстоящей конференции есть желание сделать упор на практическую деятельность: порешать архитектурные кейсы, провести архитектурную Ката, собрать архитектурное видение новых концепций архитектуры.

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

Ссылка: https://archdays.ru

Если кого-то хотите увидеть на конференции, пишите в тред, отправлю персональное приглашение.

Увидимся на ArchDays!

Продолжаем (а может даже завершаем) цикл телеперерач о чистой артихектуре. Теперь с кодом! https://www.youtube.com/watch?v=q6NPKBek-BE

В прошлом посте https://news.1rj.ru/str/stringconcat/142 мы объявили о старте предзаписи на курс "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

Сегодня расскажем о программе курса. Курс затрагивает такие темы:

1. Разработка и управление требованиями
Разработка требований — самый важный этап в жизненном цикле ПО. Если вы думаете, что требования нужны только аналитикам, то сильно заблуждаетесь, ведь если неправильно разработать требования, то о качественном продукте можно забыть.

О чем ты узнаешь:
- Какие бывают требования и какую роль они выполняют
- Как подстраиваться под постоянное изменение требований
- Различие в водопадном подходе и Agile с точки зрения требований
- В чем разница между UseCase и UserStory, что из этого и когда использовать
- Как разрабатывать требования и не утонуть в неопределенности
Практика: Разработка требований через построение карт пользовательских историй

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

О чем ты узнаешь:
- Что такое CI на самом деле
- Зачем в современном мире нужен trunk-based development
- Когда правильно организовывать репозитории
- Всегда ли нужны code-review
Практика: построение процесса непрерывной интеграции

3. Архитектура: с высоты птичьего полета
Архитектура — основа всей системы. Именно она определяет успех предприятия, а не то, сколько новомодных фреймворков напихано в проект. Поначалу на нее не обращают внимания, а когда вспоминают, то проект уже идет ко дну.

О чем ты узнаешь:
- Что такое архитектурные характеристики и стили. Откуда они берутся
- Какие архитектуры бывают и какими свойствами обладают
- Как фиксировать архитектурные решения
- Как поддерживать приложение в соотвествии с выбранными характеристиками постоянно, а не время от времени
Практика: Разработка архитектурных характеристик для выбраных систем

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

О чем ты узнаешь:
- Какие основные проблемы сопровождают проект на уровне кода
- Какие метрики кода существуют и зачем они нужны
- Что такое SOLID на самом деле и зачем он нужен
- Как организовывать модульность и какие способы ее оценки существуют
- Как защитить свою архитектуру
Практика: разбор проекта на основе метрик

5. Эволюция проекта: от MVC до Clean Architecture
На небольшом примере рассматриваем эволюцию проекта, какие кризисы он переживает и зачем все это нужно. Узнайте, на каком этапе развития находится ваш проект и что его ждет, если ничего не предпринять.

6. Sensible defaults
Практики, которые используются в приличных заведениях и чтобы от них отступить нужны веские причины.

О чем ты узнаешь:
- Как экстремальное программирование помогает справиться с неопределенностью
- Разработка через тестирование (TDD) — что это такое и почему тесты всего лишь побочный эффект методологии.
- Как парное программирование экономит время
Практика: парное программирование по TDD

7. Domain-Driven Design
Самая сложная часть курса и мозг вашего приложения. Разбираемся, почему разработчикам так тяжело понимать заказчиков и пользователей, а добавление одной кнопки требует 5 человеко-месяцев.

О чем ты узнаешь:
- Как работают стратегические паттерны и зачем они нужны
- Из каких строительных блоков состоит модель предметной области
- Почему так важно понимать что ты разрабатываешь
- Как коммуникация между бизнесом и технарями влияет на успех проекта
Практика: EventStorming и разбор примера кода на основе тактических паттернов

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

О чем ты узнаешь:
- Как понять действительно ли вам нужны микросервисы
- Каких проблем добавляют микросервисы
- Основные паттерны и антипаттерны при построении микросервисных архитектур
- Где находятся границы микросервисов и причем тут Domain-Driven Design

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

О чем ты узнаешь:
- Какие есть способы взаимодействия программных систем
- Чем они характеризуются
- Как выбрать подходящую модель взаимодействия
- Какие организационно-технические средства помогут сделать процесс интеграции менее болезненным
Практика: изучение паттернов на примере кода

10. Тесты и тестирование
Писать тесты или нет? Если да, то для чего? И почему наши тесты снова "протухли"? Ставим точку в этих вопросах.

О чем ты узнаешь:
- Какие виды тестов существуют
- Чем они характеризуются и для чего нужны
- Что такое пирамида тестирования и почему именно пирамида, а не ромб или квадрат
- Как поддерживать отслеживать качество тестов и поддерживать их в надлежащем виде
- Зачем на самом деле нужен тестировщик
Практика: разбор пирамиды тестирования на примере проекта

Старт новой группы – 10 июня!
Для записи переходите на сайт и выбирайте тариф «максимальная прокачка»: howto.stringconcat.com/enterprise

Почему я (Сергей) решил учить английский

Шел 2016 год, стартап, в котором я работал, банкротится и мы всей командой разработчиков идем на onside собеседование Crossover(Это американский бодишоп на который можно работать удаленно и получать не самую высокую зарплату по меркам США, но очень приличную по любым другим меркам). К слову зарплата маячила в районе 8-10k USD в месяц. Я прохожу несколько этапов coding-challenge, коллеги постепенно отваливаются. И вот остается человек 5 из 30+ и последний этап — собеседование на английском. После которого мне говорят: ты, конечно, парень умный, но приходи к нам как подтянешь немного английский. Вот так из-за английского от меня уплыли 10к USD в 2016 году в провинциальной России…

Но это дало мне нешуточную мотивацию учить английский и в конечном итоге оказаться в Сингапуре

Мой товарищ написал очень хороший гайд по тому, как ему удалось выучить английский до уровня C2.
Если вы решили что английский вам нужен — приятного чтения: https://howto.stringconcat.com/blog/how-to-learn-english

Мне очень интересно узнать что лично вас мотивировало начать учить английский, с какими трудностями вы столкнулись и какой совет дали бы тем, кто-только учит?

Инсайды собеседования в Thoughtworks
Нужно провести собеседование, а вы не хотите давать задачки на кручение деревьев? Тогда у меня есть, что вам предложить.

На мой скромный взгляд, процесс собеседования в Thoughtworks один из лучших в мире.
Как я говорил в одном видео, Thoughtworks провел хорошую работу по выяснению функциональных и нефункциональных требований к кандидатам. А потом подумал, как именно их можно проверить. А не смалодушничал и не дал очередные задачи с leetcode 🙂

Требования к программистам простые:
- уметь читать написанный код
- отличать плохий код от хорошого
- обязательно уметь писать тесты до кода
- немножечко уметь писать код хотя бы на одном языке
- и уметь рефлексировать над своими провалами

Теперь посмотрим как это имплементируется в собеседованиях:

Этап 0. Собеседование с HR
Достаточно быть более-менее адекватным: не пускать слюни на интервью, более-менее понимать что тебя спрашивают по-английски. Хотя надо признать, что даже HR’ы наврят ли пропустят кандидата после фразы «а я без тестов в прод деплою прям с ноута».

Этап 1. Coding Challenge (1,5 часа)
Вам заранее высылают маленький проект на вашем любимом языке и дают ознакомится с кодом.
На самом собеседование вас обязательно спросят, что понравилось в коде, а что бы вы улучшили.
Бывали случаи, когда ребята с 5+ годами опыта говорили, что все хорошо, но лучше использовать 2 отступа вместо 4 и комментарии добавить. Тут, конечно, можно уже и не кодить. Я лично, по крайней мере от Лидов, ожидаю критику архитектуры.

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

По секрету скажу, что к этой задаче достаточно немного порефактрить и написать 5 строчек продакшен-кода. И тесты, куда же без них.

Кстати, напишите в комментариях, а что бы вы исправили вот в этом тестовом проекте. Можете выбрать любой язык 😉

Продолжение следует…