Bot Style

Всё изменилось, когда я сменил работу. Попал в ситуацию, где соотношение сервисов к количеству разработчиков было 3-4 к 1. И, конечно, всё это называлось «сервисной» архитектурой, а при продумывание того, как нам делать новую функциональность люди ориентировались на непонятные мне каноны микросервисов и «облачную архитектуру».

Что вообще я знал про микросервисы из статеек в интернете:

• Всегда есть противопоставление некоему «монолиту»
• Есть понимание, что «монолит» - енто некий сервис с API, который крутит внутри себя кучу фоновых процессов
• Выделяем фоновые процессы в самостоятельные сущности, получаем микросервисы
• Разбиваем большое сложное API на логически связанные разделы, уносим в самостоятельные сущности, и вуаля микросервисы

Что я вообще понимал под термином «микросервис»:

• Технически это сайт или служба/демон, который имеет простой и понятный API
• Инкапсулирует в себе некую атомарную часть «бизнес-логики» (кавычки потому, что адепты микросервисов чому-то редко употребляют ентот термин)

Какие я видел плюсы подобного подхода:

• Настоящее разграничение и изолированность (грабли в сервисе А, не долетают до всех от него зависимых, технически невозможно доступиться до условного синглтона)
• Простота архитектуры и реализации (чем проще задача, тем меньше надо инфраструктурных наворотов)
• Масштабируемость по людям (раз уж мы все сегментировали даже технически, то можно нагонять ораву)
• Разнообразность технологий (если потребителям видно только API, то похуй как оно врутри сделано)
• Простота тестирования (меньше логики и внутренних инфраструктурных сложностей – проще писать тесты)

Что на практике:

• Пересечение логических зон ответственности нескольких микросервисов (самое страшное, имхо, тому что не понять, куда впиливать фичу)
• Сложный и плохо формализуемый граф зависимостей (если в условном монолите, написанном на популярном языке, можно легко посмотреть граф, кто от кого зависит и пробежаться по конкретным примерам использования, то в миросервисах енто все крайне затруднено)
• Дисбаланас функционалисти (один сервисы делаю дохуя, другие реально «микро»)
• Дисбаланс нагрузки (следствие предыдущих 2 пунктов, то есть от одного сервиса зависят 100500 других и, значит, его будут  нагружать)
• Невероятная сложность тестирования (из-за того, что зависимости стали «физическими», тк реально разные приложения работают, то находить несостыковки можно только интеграционными тестами, а они сами по себе в 1000 раз более долгие чем юнит-тесты, а «моки» на таком уровне – енто сложнее чем вся фича)
• Замедление разработки (если фича требует поддержки от 2 или более сервисов, то надо общаться с людьми, а потом синхронизировать процесс деплоя и тестирования)
• К любой вообще логике добавляется A/B тестирование (как следствие предыдущего пункта, тому что при количестве сервисов более определенного порога,  просто невозможно поднимать согласованное окружение на одной машине, а тестироваться полными окружениями в облаке ради 2-3 сервисов невероятно дорого).
• Усложнение формальных процессов, тому что даже автотесты через A/B предполагают хотя бы наличие веток в разных репозитариях с единым названием (или любой подобный механизм согласования)
• Невероятно сложные релизы, тому что заказчик хочет в проде «вон те 2 фичи», которые невероятно сложно отодрать от общего потока разработки

Резюмируя. Сам по себе переход на микросервисную архитектуру не решает ни одну проблему вообще. Максимум, что он дает – это много боли, через которую, можно дойти до достаточно удобной инфраструктуры управления всем ентим зверинцем. Те же самые выстраданные A/B-тесты -- большой профит. Да и то, это реально только в условиях ГОМОГЕННОЙ инфраструктуры, когда для одних и тех же вещей, используется одна и та же технология и общие библиотеки для них. В противном случае, можно весело смотреть, как при появлении нового микросервиса пишется клиент для него на первом ЯП, потом втором и так далее. Это все идиотская трата времени. При гетерогенной инфраструктуре теряется экспертиза, потому что вот эти все разговоры типо «вот тут у на MySql, а вот тут возьмем PostgreSQL, у нас же микросервисы», ведут лишь к снижению уровня требований по работе с каждой конкретной технологией. Кроме того, очень сильно падает уровень вовлеченности. Люди знают, что отвечают за свои 3.5 сервиса и им поебать, чо там происходит в остальных. Я могу допустить, что есть некий уровень сложности, где подобных подход решает, без него никак. Но если подобная дичь творицца лишь потому, что в интернетах зафорсили как «последнее слово техники», то нахуй нахуй.

Cat tries virtual reality (h/t @Sa_Thero) pic.twitter.com/4yLPiGSurd

— SecuriTay (@SwiftOnSecurity) 15 марта 2016 г.

( Read more... )

metaclass

def obj = new(name = "anon", age = 10, created = DateTime.Now);

[Record] class AnonType[name, age, created] {
    public name    : name;
    public age     : age;
    public created : created;
}

( Read more... )

    <ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>