Добавлю своих 5 копеек по поводу импортозамещения.
А импортозамещать Virtex 4 никто не собирается?
И ничего что всё это можно запихнуть на две Virtex 6, и дешевле получится, и порезать можно под заказ у Xilinx.
1-2 Achronix'a тоже, думаю, бы прокатило…
Уже много воды с того времени утекло, есть чего добавить, есть что уточнить.
Согласен, в целом статья вышла довольно сумбурной и плохо систематизированной.
Хотел написать о всяком, но не уделил особо внимания контекстам и оформлению.
Сейчас занимаюсь разработкой высоконагруженных решений, да и чаще участвую в fulltime удалёнке нежели в one-shot проектах.
Уже сформировалось понимание blame culture, и навыки решения основных проблем в коллективах.
Получается довольно неплохо мотивировать сотрудников, да и опытом делиться.
Использую уже более года, на ES6. Без тестов ничего не выкатываю из-за этих проблем обратной совместимости, но я не считаю что изменения API в бете слишком уж значительны. В плане архитектуры в бете уже ничего значительно меняться не будет.
Проще взять любой более зрелый фреймворк типа Angular2 / React / Ember и не заморачиваться с этим boilerplate'ом, что собственно и сделала AirBnB в своё время. Там тоже возможны утечки из-за криворукости, но и вероятность накосячить будет на много меньше.
Пример: частенько получается так что есть вложенные вьюшки, родительская внезапно удаляется, и вместо неё создаётся новая с таким же, или большим, количеством потомков, и так с довольно высокой частотой — GC просто не успеет собрать мусор. Да и если с одной вьюшки удалить родительскую другой вьюшки — тоже потечёт. Даже банальный jQuery UI в далёком 2009ом из-за криворукости мог довольно сильно подтекать ...
В своё время для предотвращения выстрелов в ногу был придуман Marionette, но и на нём можно косячить без разбору. Вот, в большинстве случаев, оно так и получается.
Пост #1 о том как Uber слез с PostgreSQL 9.2 на новый мускуль, плакаются что репликации нет и хранилище не эффективное — ну конечно, сидеть на ископаемой винрарщине и плакаться на MVCC, мягко говоря, не серьёзно.
Пост #2 о том как хорошо интернам в Убере менять мир к лучшему, т.е. вброс.
Пост #3 о том как они используют PCA (метод главных компонент) для предотвращения фрода. PCA, Карл! PCA против мошенничества.
Пост #4 о том как они сглаживают ускорения логистической регрессией, т.е. тролейбус с батона.
Пост #5 про абстрактный деплой микросервисов в вакууме, без консенсусов, CRDT и прочих умных штук, просто потому что они магическим образом могут без этой заумной ерунды обойтись.
Прям очень таки познавательные, наукоёмкие и высокотехнологические статьи...
Прям "Перспективный маркетинг бесперспективных продуктов" решает все проблемы бизнеса...
Вы уверены что "хороший маркетинг" должен бороться с "отличной технологией"?
Может он в результате пытается бороться с отлаженным и жизнеспособным процессом разработки в угоду иллюзорной прибыли в краткосрочных перспективах ?
Начинали они с backbone, и переписывали пару раз из-за подтеканий и криворукости разработчиков. Оно переодически отваливалось… потом был вариант вообще без SPA, но он медленно и уверенно был портирован на React. В процессе портирования был разработан ряд подходов к контролю качества, учитывая предыдущий печальный опыт с backbone. В итоге допиливать и поддерживать решение на react'e получилось в ~6 раз дешевле, а по объёму кода оно было почти в 2 раза меньше первоначального.
Да, вот только в 80% проектов с eslint'ом и jscs используется пресет AirBnB, в плане контроля качества они очень сильно преуспели из-за своего фейла с backbone… но это уже совсем другая история.
Вот решения uber'a в плане QA не особо, да и сейчас из-за этого наблюдается плавный переход с node.js на java/go, их существующие решения очень сильно уступают по качеству тому же netflix'у.
Был в пачке сфейляных американских стартапов, работал с airbnb soundcloud uber cloudflare netflix akamai ...
Могу подтвердить что действительно наукоёмкими задачами и оптимальными решениями никто не заморачивается, даже с учётом всех сверхоптимистических ожиданий о росте продукта, получается так что после релиза выходит куча хлама. Опосля, если разработчики успевают допилить этот "Минимально-Нежизнеспособный Продукт", что бы он мог расти и масштабироваться без ущерба для UX, и способны применить QoE практики, то и росту спроса можно соответствовать. В противном случае наблюдается острое недовольство клиентов и различные "параноидальные фьючеризмы" "грибной менеджмент" "говноштормы" "кластерфаки" ...
С психологической точки зрения, со старту самого проекта, можно наблюдать ряд распространённых когнитивных искажений из-за потребности веры в иллюзорные перспективы успеха… "Ореолы" "Бумеранги" и проч. А в попытках объяснения и предложений о принятии дальнейшего решения дальше "Проекций" и "Актуализации" дело не доходит.
В общем банальные амбиции и лень затмевают взор…
Вместо того что бы мерить и принимать решение, люди верят в иллюзорные перспективы абстрактного успеха.
Поставьте эти словечки себе в профиль – и вас сразу начнут осаждать рекрутеры
C глупыми и бесполезными предложениями.
DevOps/Микросервисы — это удел запада, а наши потуги внедрять всё это — довольно посредственны.
Пока не решится вопрос с контролем качества и общей организацией работ, а в 80% случаев их нет, до тех пор и думать про какой-либо DevOps и Микросервисы не то что бесполезно, а просто вредно, и для проектов, и для их руководства.
Firebase был выбран как временное решение, до того как разработаем Kotlin GraphQL стэк на основе Rapidoid'a, и различных патчей к OpenJDK для поддержки DPDK в NIO. Возможно напишем свой http/http2 сервак на Kotlin'e, с шахматами и поэтессами.
В реальных проектах Apollo использовал, полностью отказался в пользу Firebase. Основная цель проекта — предоставить решение для быстрой разработки стартапов на основе MongoDB. Использование любых других СУБД нецелесообразно для авторов проекта, потому что проекту важно срубить инвестиций, сначала для Apollo, потом для Meteor, а потом и для MongoDB… Важен полный Vendor Lock-in на этих решениях, просто потому что они им принадлежат.
О производительности, уместности и/или эффективности речь не идёт, главное обрисовать всё в розовых понях, и используя существующие проекты Fb, типа express-graphql, создать иллюзию вундервафли и сгрести ещё 30 лям вечнозелёных, как это уже было с Meteor пару лет назад, и как это уже было с MongoDB в 2009ом.
Я не говорю что GraphQL это плохо, я говорю что разработчики Apollo просто хотят огрести бабла за обёртку поверх решений Fb.
Что будет потом — покрыто туманом войны, и никаких гарантий поддержки/работоспособности сейчас нет.
Человек наверняка предлагает использовать TypeScript/Flow из-за своих личных предпочтений и религии «что всё остальное — ерунда».
Хотя на самом деле у самого практики разработки не хватает, что бы понимать недостатки этих решений в действительно больших проектах, или «почему в MS/Fb ещё не всё переписано на TypeScript/Flow, и, быстрее всего, никогда и не будет переписываться ?».
Совсем не ясно как обстоят дела с консенсусом (Raft / Paxos) и CRDT структурами для консистентности в конечном счёте (Strong eventual consistency — SEC).
SEC в рамках распределённых хранилищ с кэшированием, довольно очень таки сложен, я очень сомневаюсь что он был решён в рамках предлагаемого решения. Особенно когда речь идёт о сегрегации моделей чтения и записи.
Я не понимаю чем этот Theron лучше того же Firebase, у которого нынче довольно привлекательная ценовая политика и поддержка Google.
Там просто когда таких балансировщиков с плюшками десяток запущено и нужно что бы у них одни и те же состояния были — начинаются проблемы, эти проблемы решаются с помощью решения задачи принятия консенсуса, в случае с тем же Nomad/Kubernetes.
Если есть consul и нужен service discovery с планировщиком и гарантией состояний — надо было внедрять nomad.
Нужно понимать что есть CRDT, а есть консенсус на Raft/Paxos…
Вот в случае с Consul'ом для Health Check используется CRDT c Serf'a.
В статье шла речь о том что вам нужен консенсус и планировщик для гарантий синхронизации — надо было использовать Nomad для этого.
В общем эт уже разработано, надо было чуть глубже вникать в стэк HashiCorp.
Kubernetes тоже прокатит — там Raft вроде как.
Советую ознакомится со способами решения задач синхронизации в распределённых средах и как они ложатся на САР теорему.
По ряду причин netmap совсем с другой оперы, у него нет коммерческой поддержки и поддержки со стороны вендров, он не предназначен для высокодоступных решений.
DPDK корректнее сравнивать с OpenOnload: поставил карту и софтину — тут "внезапно" nginx 38Gbit начал кушать и отдавать. Правда DPDK работает на самом низком уровне, позволяя драйверам сетевого интерфейса выполнятся в userspace, по этому и задержки на много меньше.
А импортозамещать Virtex 4 никто не собирается?
И ничего что всё это можно запихнуть на две Virtex 6, и дешевле получится, и порезать можно под заказ у Xilinx.
1-2 Achronix'a тоже, думаю, бы прокатило…
Уже много воды с того времени утекло, есть чего добавить, есть что уточнить.
Согласен, в целом статья вышла довольно сумбурной и плохо систематизированной.
Хотел написать о всяком, но не уделил особо внимания контекстам и оформлению.
Сейчас занимаюсь разработкой высоконагруженных решений, да и чаще участвую в fulltime удалёнке нежели в one-shot проектах.
Уже сформировалось понимание blame culture, и навыки решения основных проблем в коллективах.
Получается довольно неплохо мотивировать сотрудников, да и опытом делиться.
Использую уже более года, на ES6. Без тестов ничего не выкатываю из-за этих проблем обратной совместимости, но я не считаю что изменения API в бете слишком уж значительны. В плане архитектуры в бете уже ничего значительно меняться не будет.
Проще взять любой более зрелый фреймворк типа Angular2 / React / Ember и не заморачиваться с этим boilerplate'ом, что собственно и сделала AirBnB в своё время. Там тоже возможны утечки из-за криворукости, но и вероятность накосячить будет на много меньше.
Пример: частенько получается так что есть вложенные вьюшки, родительская внезапно удаляется, и вместо неё создаётся новая с таким же, или большим, количеством потомков, и так с довольно высокой частотой — GC просто не успеет собрать мусор. Да и если с одной вьюшки удалить родительскую другой вьюшки — тоже потечёт. Даже банальный jQuery UI в далёком 2009ом из-за криворукости мог довольно сильно подтекать ...
В своё время для предотвращения выстрелов в ногу был придуман Marionette, но и на нём можно косячить без разбору. Вот, в большинстве случаев, оно так и получается.
Пост #1 о том как Uber слез с PostgreSQL 9.2 на новый мускуль, плакаются что репликации нет и хранилище не эффективное — ну конечно, сидеть на ископаемой винрарщине и плакаться на MVCC, мягко говоря, не серьёзно.
Пост #2 о том как хорошо интернам в Убере менять мир к лучшему, т.е. вброс.
Пост #3 о том как они используют PCA (метод главных компонент) для предотвращения фрода.
PCA, Карл! PCA против мошенничества.Пост #4 о том как они сглаживают ускорения логистической регрессией, т.е. тролейбус с батона.
Пост #5 про абстрактный деплой микросервисов в вакууме, без консенсусов, CRDT и прочих умных штук, просто потому что они магическим образом могут без этой заумной ерунды обойтись.
Прям очень таки познавательные, наукоёмкие и высокотехнологические статьи...
Прям "Перспективный маркетинг бесперспективных продуктов" решает все проблемы бизнеса...
Вы уверены что "хороший маркетинг" должен бороться с "отличной технологией"?
Может он в результате пытается бороться с отлаженным и жизнеспособным процессом разработки в угоду иллюзорной прибыли в краткосрочных перспективах ?
Начинали они с backbone, и переписывали пару раз из-за подтеканий и криворукости разработчиков. Оно переодически отваливалось… потом был вариант вообще без SPA, но он медленно и уверенно был портирован на React. В процессе портирования был разработан ряд подходов к контролю качества, учитывая предыдущий печальный опыт с backbone. В итоге допиливать и поддерживать решение на react'e получилось в ~6 раз дешевле, а по объёму кода оно было почти в 2 раза меньше первоначального.
Да, вот только в 80% проектов с eslint'ом и jscs используется пресет AirBnB, в плане контроля качества они очень сильно преуспели из-за своего фейла с backbone… но это уже совсем другая история.
Вот решения uber'a в плане QA не особо, да и сейчас из-за этого наблюдается плавный переход с node.js на java/go, их существующие решения очень сильно уступают по качеству тому же netflix'у.
Был в пачке сфейляных американских стартапов, работал с airbnb soundcloud uber cloudflare netflix akamai ...
Могу подтвердить что действительно наукоёмкими задачами и оптимальными решениями никто не заморачивается, даже с учётом всех сверхоптимистических ожиданий о росте продукта, получается так что после релиза выходит куча хлама. Опосля, если разработчики успевают допилить этот "Минимально-Нежизнеспособный Продукт", что бы он мог расти и масштабироваться без ущерба для UX, и способны применить QoE практики, то и росту спроса можно соответствовать. В противном случае наблюдается острое недовольство клиентов и различные "параноидальные фьючеризмы" "грибной менеджмент" "говноштормы" "кластерфаки" ...
С психологической точки зрения, со старту самого проекта, можно наблюдать ряд распространённых когнитивных искажений из-за потребности веры в иллюзорные перспективы успеха… "Ореолы" "Бумеранги" и проч. А в попытках объяснения и предложений о принятии дальнейшего решения дальше "Проекций" и "Актуализации" дело не доходит.
В общем банальные амбиции и лень затмевают взор…
Вместо того что бы мерить и принимать решение, люди верят в иллюзорные перспективы абстрактного успеха.
Аминь.
C глупыми и бесполезными предложениями.
DevOps/Микросервисы — это удел запада, а наши потуги внедрять всё это — довольно посредственны.
Пока не решится вопрос с контролем качества и общей организацией работ, а в 80% случаев их нет, до тех пор и думать про какой-либо DevOps и Микросервисы не то что бесполезно, а просто вредно, и для проектов, и для их руководства.
О производительности, уместности и/или эффективности речь не идёт, главное обрисовать всё в розовых понях, и используя существующие проекты Fb, типа express-graphql, создать иллюзию вундервафли и сгрести ещё 30 лям вечнозелёных, как это уже было с Meteor пару лет назад, и как это уже было с MongoDB в 2009ом.
Я не говорю что GraphQL это плохо, я говорю что разработчики Apollo просто хотят огрести бабла за обёртку поверх решений Fb.
Что будет потом — покрыто туманом войны, и никаких гарантий поддержки/работоспособности сейчас нет.
Хотя на самом деле у самого практики разработки не хватает, что бы понимать недостатки этих решений в действительно больших проектах, или «почему в MS/Fb ещё не всё переписано на TypeScript/Flow, и, быстрее всего, никогда и не будет переписываться ?».
Совсем не ясно как обстоят дела с консенсусом (Raft / Paxos) и CRDT структурами для консистентности в конечном счёте (Strong eventual consistency — SEC).
SEC в рамках распределённых хранилищ с кэшированием, довольно очень таки сложен, я очень сомневаюсь что он был решён в рамках предлагаемого решения. Особенно когда речь идёт о сегрегации моделей чтения и записи.
Я не понимаю чем этот Theron лучше того же Firebase, у которого нынче довольно привлекательная ценовая политика и поддержка Google.
Нужно понимать что есть CRDT, а есть консенсус на Raft/Paxos…
Вот в случае с Consul'ом для Health Check используется CRDT c Serf'a.
В статье шла речь о том что вам нужен консенсус и планировщик для гарантий синхронизации — надо было использовать Nomad для этого.
В общем эт уже разработано, надо было чуть глубже вникать в стэк HashiCorp.
Kubernetes тоже прокатит — там Raft вроде как.
Советую ознакомится со способами решения задач синхронизации в распределённых средах и как они ложатся на САР теорему.
По ряду причин netmap совсем с другой оперы, у него нет коммерческой поддержки и поддержки со стороны вендров, он не предназначен для высокодоступных решений.
DPDK корректнее сравнивать с OpenOnload: поставил карту и софтину — тут "внезапно" nginx 38Gbit начал кушать и отдавать. Правда DPDK работает на самом низком уровне, позволяя драйверам сетевого интерфейса выполнятся в userspace, по этому и задержки на много меньше.