Как сэкономить 120 000 $ в год на инфраструктуре? Просто возьмите старый проверенный EC2

Ситуация: клиент попросил оценить, не слишком ли много тратить 240 000 $ в год на инфраструктуру приложения, которое обслуживает 35 пользователей с 9:00 до 18:00.

Что мы нашли под капотом:
— 6 микросервисов, потому что модно и молодёжно
— по 2 инстансы каждого, потому что отказоустойчивость
— по 2 инстанса БД на каждый сервис, см. пункт выше
— деплой на AWS Fargate

Стоило это все 8000 $ в месяц на боевом сервере + столько же на UAT-стенде с зеркалом, который должен был быть у клиента по требованию регулятора.

Что мы изменили

1. Смёржили всё в два сервиса.

Микросервисы — отличная технология, когда вам нужно независимо масштабировать сервисы, устойчивость к отказам и независимый деплоймент сервисов. Но это при условии, что у вас микросервисы независимы и у вас зрелые Devops-практики. У нашего же клиента был типичный Distributed big ball of mud, который сводил все преимущества микросервисов в ноль.

2. Перевели деплой с AWS Fargate на EC2.

У AWS есть 2 варианта деплоя контейнеров:
— традиционный EC2. Вам выделяется виртуальная машина или несколько, в каждую машину напихивается столько контейнеров, сколько влезет.
— новый-молодежный Fargate, в котором кубернетису не нужно думать, раскидывать контейнеры по виртуалкам. Просто указываем, сколько каждому контейнеру нужно CPU и памяти, а тёмные электрические силы Амазона дальше сами всё делают.

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

EC2 стоил 3000 $ вместо 8000 $ за Fargate, получилось 60 тысяч экономии в год. Столько же удалось сэкономить на UAT-стенде. Итого те самые 120 тысяч в год из заголовка.

Наткнулся на неплохой мануал с примерами по spring-security и oauth

Как известно, в spring-security сам черт ногу сломит, а если туда oauth добавить, то, вообще, никогда в жизни не разберёшься. В мануале автор неплохо объясняет, как что устроено с точки зрения спринга.

Я тут систематизировал стратегии как я торговался за оффер в Thoughtworks 4 года назад. 🙂 https://www.youtube.com/watch?v=jtu_FdNDxNc

Кстати, а как вы обычно выбиваете на собеседованиях зарплату по-больше?

Небольшая заметка о том, как гарантированно заехать в дурку, находясь в айтишечке

Собрали у своих коллег истории чего необычного они находили в самописных библиотеках.

Нашлись
- Конфигурации Спринга,
- Override Бинов,
- Хабернейт.
Но победителем посчитали либу со @SpringBootApplication внутри.

А вы что находили в либах?

Привет, зазываем на курс!

15 сентября — старт новой группы по практическому курсу Разработка Enterprise-приложений без боли и сожалений.

Самое время учиться: кризис в индустрии свирепствует, СhatGPT душит Stack Overflow. Скоро нейросети научатся перекидывать JSON в DTO, и многие кодеры окажутся не нужны, как знатоки Drupal. Чтобы остаться востребованным, нужно начинать мыслить не инструментами, а методологиями проектирования.

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

До 1 сентября курс стоит 90 000 ₽
Со 2 сентября — 140 000 ₽

Подайте заявку и сэкономьте 30% Изи мани, рил ток

Господа, давно не рекомендовали вам хорошей литературы. Хотим исправиться.

Не секрет, что мы с Сережей нежно любим котлин и еще нежнее - его отдельные концепции, такие как корутины. Если вы ими никогда не пользовались (но всегда хотели) или пользовались мало (и не заценили), то рекомендуем обратить внимание на книжку Kotlin Coroutines, Deep Dive за авторством Marcin Moskał. Разжевано хорошо, много картиночек и иллюстраций. Нет сложных концепций, хорошо это или плохо решайте сами, но читается точно легко.

Я только что вернулся из командировки из Китая.
И хочу поделится впечатлениями, особенно тем что касается разработки. И китайских девочек.
Приятного пятничного просмотра под кофеек!
https://youtu.be/RZlpDhtR7lU

Хочу порекомендовать 3 классические книги молодым коллегам. Составил Top 2, нужен ваш совет по 3ей.

1.Clean Code by Robert Martin Или Code Complete by Book by Steve McConnell. (На мой взгляд они рассказывают об одно и том же)
Они научат писать понятный и поддерживаемый код на базовом уровне: Как думать объектами, а не процедурами, как называть переменные, когда нужно бросать исключения и пр. Мой путь к профессиональному разработчику начался именно с этих книг. Приучили к горшку, так сказать.

2.вторая не менее важная The Pragmatic Programmer: Your Journey To Mastery, которая рассказывает что происходит в разработке, если немного оторваться от кода. Что делать надо не то что вам сказали, а нужно думать “зачем” это нужно и “кому”. Да и вообще она о философии разработчика: как прожить долгую и счастливую программерскую жизнь.

3.А какую третью книгу вы бы порекомендовали разработчику с 1-2годами опыта? Какая книга на вас повлияла больше всего?

Про курсы. Осталось 5 мест на сентябрьский поток курса по энтерпрайзу. До 2 сентября цены старые, потом вырастут. Налетай-поторопись!

Иногда мы с Сережей пишем в блог. В основном про жизу, но не обязательно. Если вы с нами недавно, то рекомендуем почитать

Как поехать кукухой в айти. Рецепт для лида

Как я дважды выгорел дотла и восстал из пепла

Как остаться в айти, когда уже приуныл, но на пенсию ещё рано

Как я попал в ThoughtWorks или образцовое интервью

ВНЕЗАПНО, технический пост. Небольшая заметка о некоторых особенностях контрактов, которые на первый взгляд выглядят ерундой, а по факту сжирают кучу времени и нервов.

Студенты тут поделились жизой

В приличных заведениях за такие выкрутасы можно и пером в бочину получить на код-ревью

Рекомендуем: Unit Testing: Principles, Practices and Patterns by Vladimir Khorikov

В начале автор душно описывает фундамент: что такое Unit Тест, Code Coverage, Пирамида тестирования и прочие основы. Но за знакомыми терминами кроется ворох заблуждений, которые искажают смысл до противоположного. Автор собрал такие заблуждения и объяснил кто и где не прав. Например, Code Coverage не показывает, где ваш код покрыт тестами, а Моки не библиотека, а целое направление «заместителей».

Книга затрагивает деликатную тему: войну Лондонской и Классической школ тестирования. Автор по полочкам разбирает их общность и различие, в итоге убеждаясь, что коренное различие — не подходы к тестированию, а определение Unit’а. Для лондонцев — это класс, а для ортодоксов — бизнес-сценарий.

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

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

В книге представлено огромное количество практических советов по юнит-тестам: от правильного именования и использования моков — двойников, до написания сложных e2e-тестов.

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

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

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

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

Скоро выйдет перевод важной книги — Изучаем DDD – предметно ориентированное проектирование

Зачем читать. Изучаем DDD — актуальный сборник знаний по предмету. Со времён Эванса индустрия шагнула вперёд, появились события, микросервисы и другие ништяки. Автор рассматривает DDD не в академическом вакууме, а в контексте применения на современных проектах.

Кому читать. Да всем, собственно. Книга рассказывает простым языком о базовых концепциях: Bounded Context, Ubiquitous Language, Aggregate Root и прочих. Постепенно автор переходит к вопросам практики: какие конкретно паттерны использовать, как правильно поделить приложение на микросервисы.

Не только теория. Книга не оставит вас один на один с кучей теории. В ней описаны практические эвристики, которые помогут принимать решения. Заодно сможете доказать коллегам, что DDD — это не про Entity, Managers и Domain Service, а в первую очередь метод эффективного управления сложностью предметной области.

К переводу приложил руку и я (Женя). Книжку пришлось несколько раз вдумчиво прочитать, поэтому могу смело её вам рекомендовать.

Книжка ещё не в продаже, но мы сообщим, как откроется предзаказ.

🇯🇵 Почетное первое место в номинации «Самый поехавший процесс разработки» занимают японские IT-компании. 🇯🇵

Мой коллега-китаец проработал год у японцев и сбежал оттуда с криком «да там нет места для творчества!»” А, поверьте мне, креативность и творчество — это не самая сильная черта китайской нации… Далее рассказываю с его слов.

Окрестности Токио, 2020 год. Компания работает по водопадной модели. Но так как это японцы, то водопадная модель возведена в абсолют, до уровня религиозной догмы.

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

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

Документация — истина в последней инстанции. Если документация вам кажется нелогичной, то вам просто кажется. Немыслимо написать код, который не соответствует документации.

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

А теперь представьте, сколько времени занимает проектирование и написание этой документации! Какая уж тут быстрая обратная связь.

P.S. Теперь я понимаю, почему не знаю ни одной большой софтины из Японии. Но я не понимаю, как они умудряются таким образом все таки писать актуальные прошивки для фотокамер Fuji, Canon и Nikon.

P.P.S. А ещё попробуйте представить, что будет, когда в Японии дойдут до аджайла со скрамом, которые они реализуют буквально и со своим звероподобным рвением.

Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming»

Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂

Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.

Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).

Like/Share 🙂

Сережа Баранов мутит встречу по ES, рекомендуем заглянуть!