Речь не про отношение к коду и даже не про стартапы. В крупных организациях запросто может быть сотня команд, которые живут очевидно своей жизнью. Как бы вы не следили за ними, они живут в разных локациях, с разной квалификацией и разными задачами. Говнокод тут не диагноз, а принятие несовершенства мира и объективной сложности систем. Вы просто не сможете синхронизировать работы в такой структуре для обеспечения единства всего. Тут плюшки микросервисов и начинают работать в полный рост. Кто-то написал код быстро и плохо. Отмасштабировали и он работает, пока техдолг не закрыли.
Очевидно, что если техдолгом не управлять, все развалится. Но это невероятно проще, чем в монолите.
Краткий ответ — изоляция «говнокода». Модульность перестаёт работать в тот момент, когда объём команды перерастает возможность контролировать ее код 1-2 людям, которые владеют всей полнотой информации об архитектуре и договоренностях по стандартам разработки. Вы перестаёте следить за всеми, появляются отклонения и код становится местами лапшой. В итоге «легаси проще переписать». Микросервисы сводят эту проблему к размеру сервиса. Можно наговнокодить отдельный сервис как угодно при помощи людей любой квалификации и это будет хорошо, пока он держит нагрузку и выполняет свои задачи. И тут как раз помогает раздельное масштабирование. При этом говнокод в одном из сервисов не затрагивает другие сервисы и команды. Profit.
Микросервисы решают не столько проблему масштабирования приложения, сколько масштабирования организации. Независимая кодовая база позволяет вносить одновременные изменения существенно большему количеству разработчиков с меньшим количеством усилий, чем монолит. Это позволяет добиваться улучшения святого Грааля современных организаций — time to market и разблокирует всякие приятные плюшки типа непрерывной поставки. С монолитом тоже можно, но очень дорого.
Редко пишу комментарии, но такого замеса тёплого с мягким не видел уже давно. Микросервисы перепутаны с микрофронтендом в половине текста, DevOps вообще хз кто, называем так всех, кого можем и т.д., и т.п.
В итоге, из интересного отраслевого кейса, получилась полная каша. Понимаю, что блог корпоративный, но технарям надо давать вычитывать.
До ожидаемого коллапса осталось вырасти до 100-150 человек. Где-то с этого размера коллектива издержки на p2p коммуникации в команде начинают съедать всю пользу. Люди просто не будут знать соседей по имени, а то и в лицо.
Проблема построения таких организаций именно в масштабируемости. До 10 человек все тривиально, т.к. даже у самого деспотичного руководителя физически хватит времени следить за всеми или у команды будет хватать времени общаться внутри себя. При росте ещё на порядок наступает предел естественного языка и скорости коммуникаций, а также восьмичасового рабочего дня.
А ещё, рано или поздно, наступает замечательный момент, когда внезапно необходимо всем командам сделать скоординированные изменения в сжатые сроки и вся демократия вообще начинает сыпаться.
Сам прохожу подобный переход как руководитель. Подобные статьи отдают некоторой наивностью и замалчиванием.
Возможно, что с точки зрения фич особо преимущества и нет, но то, что есть в VS работает раз в 10 приятнее. Активно пользуюсь студией с 2005-й версии. Продуктами JB последние полтора года. Так вот, писать код в студии нереально комфортней. Ничего не тормозит, шрифты масштабируются под 4к без проблем, интеллисенс субъективно умнее. Для меня ощущение от студии, как от пользования хорошим профессиональным инструментом, пусть и с разумным минимумом функций. От JB инструментов, как от пылесоса с влажной уборкой и парогенератором. Сухую уборку делать можно, но неудобно таскать из-за габаритов и кучи ненужных функций, которые вообще не будешь использовать.
Это все про js. Не знаю, как с поддержкой Java в IDEA, но после работы с C# в студии, на остальные IDE смотреть вообще не хочется. Просто разница лет в 10.
Естественно все это имхо и не претендует на объективность.
Если мне не изменяет память, шифрование по ГОСТ никаким боком не относится к openssl. Могу ошибаться, т.к. работал с ним давно. В любом случае, именно шифрование по ГОСТ актуальная задача для отечественного CPU, а не любой другой алгоритм, поэтому в данной части ваши замечания не совсем корректны.
На счет тестирования в целом, полностью согласен, что оно не особо репрезентативно. Многоядерность толком и не тестировали. С другой стороны, а как корректно тестировать 2 абсолютно разные архитектуры кроме как в синтетике? В любом случае, других тестов Эльбруса я вообще не видел.
Эмм. А не пробовали памяти больше 2ГБ под Win7/8 ставить? Разница между HDD/SSD даже для работы не всегда очевидна, если системе хватает памяти для активного кэшировнаия. Единственное, что отличается кардинально — время загрузки системы. Поэтому бы я не был так категорически настроен, что невозможно перейти. Дома SSD, на работе HDD. Принципиальной разницы в скорости работы не ощущается.
Это очень сильно зависит от задачи, на самом деле. Грубо говоря, данные можно поделить на 2 категории: доменные, которые живут постоянно и описываются атомами, и контекстно-зависимые. Соотношение очень сильно зависит от типа системы. В корпоративном приложении или b2c системах, типа яндекс денег, практически не будет контекстных данных. В соц. сетях, наоборот, 90% времени это просмотр чужих страниц, котиков и т.п., которые существуют только в рамках текущего запроса пользователя. Их просто бессмысленно кэшировать и, более того, это прямой путь к неработоспособности на слабых клиентах. В любом случае, тут разумно использовать совершенно другие механизмы кэширования с меньшими издержками по памяти и производительности.
Речь не про отношение к коду и даже не про стартапы. В крупных организациях запросто может быть сотня команд, которые живут очевидно своей жизнью. Как бы вы не следили за ними, они живут в разных локациях, с разной квалификацией и разными задачами. Говнокод тут не диагноз, а принятие несовершенства мира и объективной сложности систем. Вы просто не сможете синхронизировать работы в такой структуре для обеспечения единства всего. Тут плюшки микросервисов и начинают работать в полный рост. Кто-то написал код быстро и плохо. Отмасштабировали и он работает, пока техдолг не закрыли.
Очевидно, что если техдолгом не управлять, все развалится. Но это невероятно проще, чем в монолите.
Краткий ответ — изоляция «говнокода». Модульность перестаёт работать в тот момент, когда объём команды перерастает возможность контролировать ее код 1-2 людям, которые владеют всей полнотой информации об архитектуре и договоренностях по стандартам разработки. Вы перестаёте следить за всеми, появляются отклонения и код становится местами лапшой. В итоге «легаси проще переписать». Микросервисы сводят эту проблему к размеру сервиса. Можно наговнокодить отдельный сервис как угодно при помощи людей любой квалификации и это будет хорошо, пока он держит нагрузку и выполняет свои задачи. И тут как раз помогает раздельное масштабирование. При этом говнокод в одном из сервисов не затрагивает другие сервисы и команды. Profit.
Микросервисы решают не столько проблему масштабирования приложения, сколько масштабирования организации. Независимая кодовая база позволяет вносить одновременные изменения существенно большему количеству разработчиков с меньшим количеством усилий, чем монолит. Это позволяет добиваться улучшения святого Грааля современных организаций — time to market и разблокирует всякие приятные плюшки типа непрерывной поставки. С монолитом тоже можно, но очень дорого.
Редко пишу комментарии, но такого замеса тёплого с мягким не видел уже давно. Микросервисы перепутаны с микрофронтендом в половине текста, DevOps вообще хз кто, называем так всех, кого можем и т.д., и т.п.
В итоге, из интересного отраслевого кейса, получилась полная каша. Понимаю, что блог корпоративный, но технарям надо давать вычитывать.
Проблема построения таких организаций именно в масштабируемости. До 10 человек все тривиально, т.к. даже у самого деспотичного руководителя физически хватит времени следить за всеми или у команды будет хватать времени общаться внутри себя. При росте ещё на порядок наступает предел естественного языка и скорости коммуникаций, а также восьмичасового рабочего дня.
А ещё, рано или поздно, наступает замечательный момент, когда внезапно необходимо всем командам сделать скоординированные изменения в сжатые сроки и вся демократия вообще начинает сыпаться.
Сам прохожу подобный переход как руководитель. Подобные статьи отдают некоторой наивностью и замалчиванием.
Есть еще вариант:
Мало Выпьешь, Трудно Учиться
Много Выпьешь, Тут же Уволят
МГТУ, к сожалению, веселых народных расшифровок известных мне не имеет((
Фото классные. В мой выпуск 2009 большей части всего еще не было.
Это все про js. Не знаю, как с поддержкой Java в IDEA, но после работы с C# в студии, на остальные IDE смотреть вообще не хочется. Просто разница лет в 10.
Естественно все это имхо и не претендует на объективность.
На счет тестирования в целом, полностью согласен, что оно не особо репрезентативно. Многоядерность толком и не тестировали. С другой стороны, а как корректно тестировать 2 абсолютно разные архитектуры кроме как в синтетике? В любом случае, других тестов Эльбруса я вообще не видел.
Вопрос, что в этом плохого? Как работает ваша реализация атомов? Изменения распространяются синхронно без отложенных вызовов?
Вы про UI, я про обертку над API. По сути, с вами согласен, если говорить именно про UI слой.