Маленькие радости легаси

Трассировка есть (вернее, теперь есть). Штука что в случае отказа N-ого запроса в цепочке в базе получается сцатая каша, которую потом нормально вычистить можно только руками.

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

Меня больше в крестах веселит вечное желание людей сделать новый тип на пустом месте. С одной стороны это конечно даёт гибкость если надо поменять типы всех связанных переменых, но с другой - ну нахрена этот vasya_int, сложно просто int написать?

Делал такое для map, чтобы был std::unordered_map<UserId, Score> вместо непонятного std::unordered_map<int, int>. Хотя во многих случаях можно обойтись хорошим именем для map, чтобы сразу было понятно, какой смысл у ключа, а какой у значения.

Удваиваю ОП-пост, могу добавить что печёт в целом от клепания слоёв ради самих слоёв, бест-практисы превратились в карго культ и в большинстве проектов только замедляют ими разработку и ухудшают читаемость на ровном месте, конторы на 5 инвалидов внедряют практики как в гугле «потому что так правильно!».

При том вся эта «расширяемость» в 99.999% никогда потом не используется. Я за то чтобы рефакторить код под ООПшную расширяемость только когда она действительно используется и у нас УЖЕ есть хотя бы несколько схожих сущностей, а не давайте сделаем иерархию по 100500 интерфейсов и классов на каждую мелочь, авось когда-нибудь пригодится.

Лорчую, оверинжиниринг такое же зло как и ранняя оптимизация.

Хотя во многих случаях можно обойтись хорошим именем для map

В том и соль. Делал на прошлой неделе интерфейс к крестам для пистона, и вот блин зочем называть тип fmt_int64. Он типа от этого перестаёт быть int64_t? Просто чуть больше боли при написании интерфейса, других различий нет

Я не спорю что иногда это удобно, особенно в мапах, но не когда это превращается в NIH-культ

Просто программисты в целом программировать не умеют. Раньше они ваяли монолит, получалось говно и его решили распиливать на микросервисы. Теперь пишут микросервисы, получается говно и его хотят слепить обратно в одну кучку. Потом ещё будет много-много итераций. А теперь совет: расслабьтесь и постарайтесь получить удовольствие.

Да конечно, за все хочется убить! Эти рукожопые макаки пишут что попало!!!1

А потом git blame myself. Переживать из-за кода признак профнепригодности. Люди пишут лучшее в тех ограничениях, которые существуют на момент написания кода.

в случае отказа N-ого запроса в цепочке в базе получается сцатая каша

Одна БД на все сервисы шоле?

Documentation, mf! Do you speak it?!

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

Поправочка; один из важных проявлений раздувания потребления ресурсов — это нагрузка на сеть. Однако, у большеоблаков внутренняя сеть бесплатная. Или же возьмем банальный ElastiCache, который не особо отличается от обычного редиса. В каком же месте капиталист тебя грабит?

Почему вообще у амазона так долго не было конкуренции? Потому что если тебе нужна высокая нагрузка и репликация — ты неизбежно приходишь к необходимости найма грамотных админов, или хотя бы просто консультанта, который спроектирует тебе систему. Спроси у меня в 2005 — я бы ответил, что AWS никогда не взлетит, потому что для нее нет ниш. В общем-то, объективно у нее до сих пор нет ниш. VPS можно было купить у любого хостера, Мускуль, PHP, Питон, DNS, почту твоему сайту готовые выдадут на виртуальном хостинге, но это еще не AWS. Начинается AWS с как бы безграничной масштабируемости. «Как бы» — потому что ресурсы-то амазон тебе предоставит, а вот сможешь ли ты обслужить своих пользователей на них — большой вопрос.

По состоянию на 2008 год стэк амазона состоял из: EC2, S3 storage, Simple Queue Service, CloudFront CDN, SimpleDB (аналог монги).
https://web.archive.org/web/20081211020004/https://aws.amazon.com/products

На этот момент у фейсбука было 100 млн, у ютьюба — 300 млн, myspace — 70, livejournal — 15-20. Всего по миру было где-то 500+ млн пользователей соцсеток, и ничто не предвещало беды. У амазона было примерно 85 млн пользователей. При этом, стэк фейсбука и ЖЖ был проще пареной репы: PHP, MySQL, Memcached.
https://www.infoq.com/presentations/Facebook-Software-Stack/

Да, там было уже около 10 тыс серверов, из них две тысячи — мускуль. Там был Scribe для логов и некоторых асинхронных операций, вроде рассылки последних пользовательских сообщений на серверы кэшей. Там был Thrift для межсервисов, были службы написанные на C++, То есть, если вам нужно пожать картинки, а пых не справляется — вы пишете сервис сжатия картинок на FPGA, как это сделал vkontakte. К слову, 48:10 — индус рассказывает, что сервисы нужно создавать только если по другому задачу нельзя выполнить.

Так вот, «AWS» или любой другой другой облачный хостер здесь — это те самые люди «тысячи серверов» из коробки. Зачем кому-то в 2022 (да пусть и в 2010) может резко понадобиться тысячи серверов? Один готовый 4U сервер от Backblaze может хранить 500 ТБ данных, в 2010 аналогичный сервак хранил только 60 ТБ — куда вам столько данных? По памяти — нынче довольно рядовой сервер может нести терабайт оперативной памяти. Очевидно, что предел по вертикальному масштабированию нынче пробить не так просто.

AWS МОЖЕТ быть полезен мелким сервисам, но тут, опять же, мы вспоминаем, что наиболее виртуальные хостинги под наиболее распрострененные нужды уже есть. Зачем мелком сервису амазонова кафка? DynamoDB? S3? SQS?

Одна БД на все сервисы шоле?

Хуже. БД разные, а вот сущности крайне связанные

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

Ты только частично прав. Например ты сервак админить можешь? Не на уровне админа локалхоста, а адекватно, с бэкапом, обновлениями и прочим? На это нужен человек. Или скажем ты сможешь полностью продумать стратегию деплоя и доставки кода до сервера? Нужен ещё человек. Или вот базы - ты хорошо умеешь тот же мускул админить? Ещё человек.

Уже три человека на поддержку, а можно еще хранилище вспомнить, mq и прочее. А у стартапа зачастую всего трое или четверо разрабов. Бигклауд позволяет тупо решить деньгами то что можно решить человеческим ресурсом, при том решить стандартным (что крайне важно) путём. Без «приходящего админа Васи», без «под заказчика», готовый стандартный продукт

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

Условный RDS или нечто подобное — это обычно скорее хорошо, если под рукой админа с уклоном в БД нет, я тут спорить не буду.

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

Все так, но всё-таки это немного зависит от сути сервисов. Скажем сервис обработки картинок склеивать с гейтом не очень круто, можно тупо сожрать проц и уйти в DoS. А вот разделять скажем бизнес-логику на 4 сервиса - за такое да, убивать.

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

Видимо, linux kernel писали одни только профнепригодные люди?

Например ты сервак админить можешь? Не на уровне админа локалхоста, а адекватно, с бэкапом, обновлениями и прочим? На это нужен человек. Или скажем ты сможешь полностью продумать стратегию деплоя и доставки кода до сервера? Нужен ещё человек. Или вот базы - ты хорошо умеешь тот же мускул админить? Ещё человек.

Деплой сервиса в AWS ничем не отличается от деплоя в bare metal. Облака тут берут скорее практикой инфра-как-код (на железном сервере тоже можно накостылять приблизительно похожее, но сложно). Но для адекватной реализации этой практики тоже нужен отдельный человек. Средний разработчик среднего стартапа не вывезет.

Один готовый 4U сервер от Backblaze может хранить 500 ТБ данных, в 2010 аналогичный сервак хранил только 60 ТБ — куда вам столько данных? По памяти — нынче довольно рядовой сервер может нести терабайт оперативной памяти. Очевидно, что предел по вертикальному масштабированию нынче пробить не так просто.

Закладываться на один большой сервер рискованно по ряду причин. Например тебе будет сложно расползтись на несколько серверов в случае [внезапного] увеличения нагрузки, особенно на сеть. Потому что твой софт и все процессы компании были завязаны на один сервер. В случае любых проблем с железным сервером или датацентром ты судорожно разворачиваешь бэкап на резервном сервере, с пятой попытки все заводится. Роллинг-апгрейд: если для своего софта ты его ещё сможешь накостылить, то обновить сам сервер уже может быть проблемой. Вдруг появилось много клиентов в Шанхае, из которого пинг до твоего сервера 200ms. В общем по совокупности причин твой SLA будет в жопе, перед пацанами стыдно.

Видимо, linux kernel писали одни только профнепригодные люди?

Главный переживатель уже пропил курс таблеточек и теперь спокоен, как слон. Завидуйте, берите пример.

а что с ядром линукса не так

а что с ядром линукса не так

«Дякую тобi боже, що я не крестовик». Это я про

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

Или скажем ты сможешь полностью продумать стратегию деплоя и доставки кода до сервера?

Маршал Жуков «Стратегия и тактика деплоя на сервере». Почему-то в моих случаях это сводится к «запустить башскрипт, доставить недостающие пакеты по необходимости, запустить еще раз».

Или вот базы - ты хорошо умеешь тот же мускул админить? Ещё человек

Если речь идет про полноценного DBA, который будет расставлять права приложениям, мигрировать схемы, исправлять затыки по производительности, то я боюсь, что девопса с такими навыками ты не найдешь. Если масштаб маленький, то этим занимается сам разраб. Собственно, я и есть тот самый разраб, если что. Посмотри на пример фейсбука — у них, действительно, были отдельные DBA. Аж два человека на смену и две тысячи серверов.

Бигклауд позволяет тупо решить деньгами то что можно решить человеческим ресурсом, при том решить стандартным (что крайне важно) путём

А еще можно прийти в аутсорсилку/бодишоп и точно так же кинут чемодан денег на стол. Причем, есть ненулевой шанс, что таким образом тебе решат именно твою задачу, а не «стандартную». Это я как бы про вот это:

а нужны ли мне эти ваши docker-контейнеры? (комментарий)

В самом простом случае у нас есть несколько виртуалок и БД. На виртуалки надо заходить, значит надо управлять пользователями, значит берём IAM users/groups/roles/policies. Как-то сервисы должны обмениваться трафиком, соответственно VPC, subnets, security-groups. В большинстве типовых конфигураций нам понадобится балансировщик нагрузки, веб-сервера с ssl-терминацией и обновлением сертификатов ELB/ALB/NLB, ASM, про логи, мониторинг, оповещения, резервные копии и восстановление из них, мы уже говорили, для общения с заказчиками вам может понадобиться AWS SES или SMS, новые версии нужно как-то раскатывать, там по разному можно сделать но тоже пяток наименований задействовано будет

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

Условный RDS или нечто подобное — это обычно скорее хорошо, если под рукой админа с уклоном в БД нет, я тут спорить не буду

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

За все, от форматирования и именования до архитектурных решений.

Два чая этому господину

база RDS лежать при апдейтах будет как родная.

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

Я со временем пришёл к пониманию, что на «качество» кода насрать. Если его control flow и data flow просты и понятны

Разве это не одно и то же? Мне забавно слушать, что, оказывается «качество кода» — это не просто и понятность при неизменной выполняемой функциональности, а четыре пробела отступа, или префикс в наименованиях, или dependency inversion, или еще какая муть от человека, который о программировании знает только по книжкам, но уже написал свою книжку, где учит кодеров «хорошему коду». Он-то мудак, с ним понятно — а вот к вам вопрос: почему вы всерьез слушаете их и возражаете им? Вы вот когда идете мимо пьяного обоссаного бомжа, и он вам начинает что-то кричать — тоже отвечаете, поясняете, что он не прав, что он слишком поверхностно судит?

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

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

бест-практисы превратились в карго культ

«Превратились»? Молодой человек, вы давно в кодинге? Дейкстра в 80-х писал то же самое, с тех пор в индустрии почти ничего не поменялось, разве что пару-тройку языков в 90-х появилось. Микросервисы на Коболе бабушки еще в 70-х писали так-то.

Закладываться на один большой сервер рискованно по ряду причин. Например тебе будет сложно расползтись на несколько серверов в случае [внезапного] увеличения нагрузки, особенно на сеть

А я разве утверждал, что нужно иметь только один сервер? Конечно же и второй, на случай отказа первого.

Вдруг появилось много клиентов в Шанхае, из которого пинг до твоего сервера 200ms

Поднять еще один сервер on-premises или в датацентре поближе к заказчику.

к вам вопрос: почему вы всерьез слушаете их и возражаете им? Вы вот когда идете мимо пьяного обоссаного бомжа, и он вам начинает что-то кричать — тоже отвечаете, поясняете, что он не прав, что он слишком поверхностно судит?

В процитированном тобой тексте (и вообще во все комментарии) нет ни намёка на то, что я докапываюсь до бомжей…

В процитированном тобой тексте (и вообще во все комментарии) нет ни намёка на то, что я докапываюсь до бомжей…

Ну а с кем ты тогда спорил? Вот сейчас в треде 9 из десяти человек скажут «да, хороший код — это про простоту», но ты споришь с кем-то про какую-то «архитектуру». С кем ты споришь? С обоссаными бомжами.

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

Если у тебя есть вопрос по существу, я с удовольствием отвечу :)

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

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

То есть ты это выражение принял будто оно адресовано против кого-то в этом треде? Нет, я просто знаю людей, много, да я и сам таким был, кто любит переусложнить архитектуру ради мнимой «расширяемости» и продать эту идею руководству. Сейчас я вижу, что эта расширяемость не пригождается, а часто даже создаёт проблемы, потому что расширяться программе нужно совсем не в ту сторону, о которой думал разработчик 5 лет назад. В итоге чересчур тесные связи или попытка сделать все единообразно под общим интерфейсом или обобщить похожие проблемы, все это в итоге аукается тем, что для реального расширения приходится рвать старые связи, отменять обобщающие алгоритмы и т.д.

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

я просто знаю людей, много, да я и сам таким был, кто любит переусложнить архитектуру ради мнимой «расширяемости» и ПРОДАТЬ ЭТУ ИДЕЮ РУКОВОДСТВУ

Я могу только завидовать таким людям, потому что они умеют продавать: https://habr.com/post/593167/

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

Если я вижу на ревью, что разработчик решает глобальную проблему всего в своём коде вместо того, что от него просят, я очень мягонько заворачиваю всю эту его инициативу

Кстати, мне интересно твое «ревью» по поводу:

а нужны ли мне эти ваши docker-контейнеры? (комментарий)

В самом простом случае у нас есть несколько виртуалок и БД. На виртуалки надо заходить, значит надо управлять пользователями, значит берём IAM users/groups/roles/policies. Как-то сервисы должны обмениваться трафиком, соответственно VPC, subnets, security-groups. В большинстве типовых конфигураций нам понадобится балансировщик нагрузки, веб-сервера с ssl-терминацией и обновлением сертификатов ELB/ALB/NLB, ASM, про логи, мониторинг, оповещения, резервные копии и восстановление из них, мы уже говорили, для общения с заказчиками вам может понадобиться AWS SES или SMS, новые версии нужно как-то раскатывать, там по разному можно сделать но тоже пяток наименований задействовано будет

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

Глубже погружаться в ваш спор я не хочу :)