Олег Стрекаловский

Всем привет.

Решил для себя систематизировать список литературы, которые прочитал по теме распределённых систем и, в частности, микросервисов. Единственная тема, которая осталась не до конца изученной – это SRE и инструменты деплоймента. Скорее всего напишу отдельный пост по этой теме.

Основная проблема микросервисов в том, что люди часто начинают их строить не до конца осознавая какие проблемы им придётся решать.

Один из больнючих вопросов – это консистентность данных, наличие которой надо доказывать с математической жестокостью к себе, чуть ли не по шагам анализируя все сценарии, которые могут произойти после каждого действия. Обработка отказов – ещё один черт из табакерки, который начнёт выпрыгивать из разных непредсказуемых мест. Ну и на сладкое – это копание в кишочках всяких оркестраторов, чтобы понять какие гарантии насчёт zero downtime они вам дают. А потом вы начнёте задумываться как делать миграции баз данных и бэкапы в условиях распределённых систем …

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

Сразу оставим за скобками вопросы понимания того как работают сети, Linux, Docker, как профилировать окружение (диск, сеть, память, cpu) с помощью разных тулов. Без этих знаний дальше лучше вам вообще не читать, ну или вернуться к этой замечательной статье, как только изучите этот необходимый минимум, который вам обязательно пригодится когда ваша система уйдёт в прод.

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

Дальше »

Всем привет.

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

Дальше »

Интересное замечание: периоды чтения книг и спокойной жизни у меня подозрительно часто совпадают. Если перестаёшь читать – значит на твоём пороге уже появился пушной зверёк значительных размеров, который того и гляди пропишется тут на постоянку. Гони его и продолжай «точить свою пилу»!

Всем привет.

Несколько дней назад прошла вологодская региональная конференция разработчиков DevParty 2018. В этом году помимо работы со спикерами и над сайтом, я организовывал участие нашей компании в ней и выступал с докладом. В общем, это комбо получилось неплохо, но вытянуло абсолютно все силы и нервы. Больше так делать не буду и вам не советую.

В этом посте я хотел бы поделиться опытом участия компании в конференции: зачем это делать, каким образом и почему именно так.

Дальше »

Всем привет.

Читая рассылку блога Мартина Фаулера, наткнулся на его предисловие к недавно вышедшей книге коллег из ThoughtWorks – «Building Evolutionary Architectures».

Книга посвящена проблеме, с которой сталкиваются многие разработчики: развитие архитектур программных продуктов, или как задизайнить систему так, чтобы всё было ок при условии постоянно меняющихся требований к системе. Где же лежит тот crystal ball, который покажет нам будущее и что делать, если у вас его таки нет 😄

Дальше »

Отрицание, или «Ты помнишь, как всё начиналось»

Современная профессиональная разработка ПО настолько комплексное занятие, что часто приходится выходить из зоны комфорта чтобы посмотреть в каких ещё направлениях работают другие люди чтобы улучшить продукт. Программы, в которых основная работа выполняется без участия человека, зачастую всё равно не обходятся без создания web UI (например интерфейс для управления и настройки).

Раньше в Java мире проблему создания таких web UI силами backend разработчиков решали фреймворками (например Vaadin, GWT), которые позволяли не зная CSS и JS описывать UI на Java. И оно даже стабильно работало, если приложение – просто прослойка для работы с БД.

Ожидаемо интерфейсы выглядели как под копирку, были слабо кастомизируемы, тратили ресурсы серверов на динамическую генерацию html, и выглядели по-энтерпрайзному уныло (разработчикам было пофиг, да и задачи «сделать хорошо» не ставилось). Иногда вишенкой на торте было то, что попытка интегрировать код UI-фреймворков с кучей магии, в которую никто не вникал, в многопоточное и динамическое окружение сложного backend-а приводила к появлению race conditions, которые обязательно что-то ломали на продакшене, и к утечкам памяти. Нет, авторы этих фреймворков не идиоты. Но мощь и гибкость этих вещей иногда играла злую шутку с теми, кто думал: «Ну оно ведь и так должно работать. Это же почти как в том примере из документации!»

Дальше »