Яндекс хочет быть как FAANG и стремится по кол-ву велопипедов к ним ) За всю жизнь наибольшую концентрацию велосипедов видел только в Amazon (brazil, bb, свой ci/cd, ужасный самописный аналог bitbucket или gitlab, свой самописный и грусный task tracker, вместо gradle что-то самописное и причем скрыто максимально от инженера, вообще непонятно что происходит под капотом, ноль артефактов, тест раннеры свои, confluence самописный и плохим поиском, code review и pr смотреть тоже в чем-то самописном, я удивляюсь почему slack используют а не свой messenger, хотя свой pager есть). Инфра тоже самописная по максимому, но хоть на маке заводится
Из интересных примеров про то, какие достаточно хорошие законы в ТК РФ:
в РФ например отпуска не сгорают, можно хоть 100 дней неотгуленных отпусков накопить и конвертнуть их в деньги
В Ирландии отпуска сгорают, было сюрпризом когда-то.
или
FANG платит в каждой стране по рынку (никто не будет платить зп уровня Калифорнии в Индии - это приводило даже к казусам когда Middle из Калифорнии зарабатывал существенно больше своего наставника/buddy/сеньора из Индии/Испании)
Политика sign-in бонусов разная. В РФ обычно его сразу дают, в FANG просят вернуть назад если не отработал 2 года
Документция, это так больно :) Сейчас планируем собрать отдельную команду тех писателей у которых цель: ходить докапываться до всех и собрать единую документацию
Это антипаттерн, когда два микросервиса имеют доступ к одному ресурсы. У нас встречается это, то только как переходное состояние (из тысячи миксросервисов может быть в 1-2 местах есть и везде описан план, как будем развязывать общие ресурсы)
By default в микросервис работает только со своей базой данных/кешами/sphinx etc. В чужую базу данных из коробки даже сходить нельзя, и доступы закрыты на уровне платформы.
да я согласен, что микросервисы сложно и дорого (ресурсы и человекочасы). На мой взгляд в чистые микросервисы стоит идти только если штат 500+ инженеров
да, каждый инстанс сервиса это nginx + php-fpm + pgBouncer (если есть зависимость база данных) + haproxy (если есть зависимости до внешнего redis) + enoy + служебные контейнеры по метрикам/статус чекам
Но обычные инженеры ничего этого не настраивают и не конфигурируют. Когда создаем новый сервис указываем что он на php+ему нужна база данных и все автоматически создается и разворачивается в prod/dev/staging/local окружениях.
Это для примера. Теоретически можно использовать как очень быстрый in-memory cache на уровне каждой реплики (да они не синхронизируются между собой)
Конечно можно подключить готовые библиотеки с реализаций, например, LRU в golang приложение. Но если сервис написан например на php - то можно рядом дополнительный кеш поднять. И это не замена централизованному общему кешу
paas сильно помогает. Удобный каталог и навигация по сервисам, каталог библиотек всех сервисов. Автоматически генерируемые PR на обновления, графы зависимостей. Но это все требует вложений
Помогите понять пожалуйста.
Если я работаю в какой-то компании. Получаю зп. Делаю вспомогательный тех проект. Потом все рабочее время его делаю. Привлекаю на помощь коллег (тестирование например)
Могу ли я этот тех. проект продать сторонним компаниям?
не в этом ли суть спора?
В Индии проводят эксперимент в одном из штатов по отказу от налички (можно на BBC пару репортажей найти)
Далеко не все гладко, но и плюсов множество
Та же борьба с коррупцией (взятку через онлайнбанк переводить палево, а наличку насобирать простым гражданам достаточно трудно, хоть курами и помидорами с инспекторами полиции расплачивайся)
Хотя это надо всем делать, будут обналичивать в долларах или в евро
Вопросы меняются от сессии к сессии. Сдавал еще когда только только вышла версия 3.0 и было куча вопросов на различия между 2.6 и 3.0. Про фичи wiredtiger vs mmapv1. Кто недавно сдавал из моих знакомых, говорят что такого уже нет.
Яндекс хочет быть как FAANG и стремится по кол-ву велопипедов к ним ) За всю жизнь наибольшую концентрацию велосипедов видел только в Amazon (brazil, bb, свой ci/cd, ужасный самописный аналог bitbucket или gitlab, свой самописный и грусный task tracker, вместо gradle что-то самописное и причем скрыто максимально от инженера, вообще непонятно что происходит под капотом, ноль артефактов, тест раннеры свои, confluence самописный и плохим поиском, code review и pr смотреть тоже в чем-то самописном, я удивляюсь почему slack используют а не свой messenger, хотя свой pager есть). Инфра тоже самописная по максимому, но хоть на маке заводится
Из интересных примеров про то, какие достаточно хорошие законы в ТК РФ:
в РФ например отпуска не сгорают, можно хоть 100 дней неотгуленных отпусков накопить и конвертнуть их в деньги
В Ирландии отпуска сгорают, было сюрпризом когда-то.
или
FANG платит в каждой стране по рынку (никто не будет платить зп уровня Калифорнии в Индии - это приводило даже к казусам когда Middle из Калифорнии зарабатывал существенно больше своего наставника/buddy/сеньора из Индии/Испании)
Политика sign-in бонусов разная. В РФ обычно его сразу дают, в FANG просят вернуть назад если не отработал 2 года
Документция, это так больно :)
Сейчас планируем собрать отдельную команду тех писателей у которых цель: ходить докапываться до всех и собрать единую документацию
все микросервисы развернуты в staging окружении (и там автоматически собраны обфусцированные семплы prod данных)
из local окружения работают со staging
Это антипаттерн, когда два микросервиса имеют доступ к одному ресурсы. У нас встречается это, то только как переходное состояние (из тысячи миксросервисов может быть в 1-2 местах есть и везде описан план, как будем развязывать общие ресурсы)
By default в микросервис работает только со своей базой данных/кешами/sphinx etc. В чужую базу данных из коробки даже сходить нельзя, и доступы закрыты на уровне платформы.
да я согласен, что микросервисы сложно и дорого (ресурсы и человекочасы). На мой взгляд в чистые микросервисы стоит идти только если штат 500+ инженеров
да, каждый инстанс сервиса это nginx + php-fpm + pgBouncer (если есть зависимость база данных) + haproxy (если есть зависимости до внешнего redis) + enoy + служебные контейнеры по метрикам/статус чекам
Но обычные инженеры ничего этого не настраивают и не конфигурируют. Когда создаем новый сервис указываем что он на php+ему нужна база данных и все автоматически создается и разворачивается в prod/dev/staging/local окружениях.
Да, микросервисы приносят много новых вызовов и проблем тоже. Но пока плюсов больше для нас
Да конечно.
Redis чисто для примера для тех языков, где нет возможности из коробки завести in-memory cache.
Тут чисто гипотетический пример )
Это для примера. Теоретически можно использовать как очень быстрый in-memory cache на уровне каждой реплики (да они не синхронизируются между собой)
Конечно можно подключить готовые библиотеки с реализаций, например, LRU в golang приложение. Но если сервис написан например на php - то можно рядом дополнительный кеш поднять. И это не замена централизованному общему кешу
Извините, нужно больше контекста в вопросе
paas сильно помогает. Удобный каталог и навигация по сервисам, каталог библиотек всех сервисов. Автоматически генерируемые PR на обновления, графы зависимостей. Но это все требует вложений
Если я работаю в какой-то компании. Получаю зп. Делаю вспомогательный тех проект. Потом все рабочее время его делаю. Привлекаю на помощь коллег (тестирование например)
Могу ли я этот тех. проект продать сторонним компаниям?
не в этом ли суть спора?
сказал бы что ты русский хакер
то же самое что внутри транзакции сделать update на таблице без поддержки транзакционных механизмов
Далеко не все гладко, но и плюсов множество
Та же борьба с коррупцией (взятку через онлайнбанк переводить палево, а наличку насобирать простым гражданам достаточно трудно, хоть курами и помидорами с инспекторами полиции расплачивайся)
Хотя это надо всем делать, будут обналичивать в долларах или в евро