Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.
Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.
Да, к сожалению, наш контроль над нашими же смартфонами далек от полного… И пользовательские соглашения для приложений все больше напоминают историю: «соглашайтесь на всё или никакого сервиса не получите».
Внешних карт памяти у меня нет. Все, что я сделал после покупки нового телефона, — это вошел с него в аккаунт Google и воспользовался функцией восстановления приложений. Контакты и настройки приложений — это единственно, что у меня бэкапится в облако. Все остальные бэкапы (в том числе и на уровне приложений) запрещены.
Думаю, работа «в склад» действительно может случаться на некоторых производствах при определенной конъюнктуре. Там, где остановка производственных мощностей очень дорого обходится. Например, остановка (и обратный запуск) нефтяной скважины — дело очень затратное.
Поэтому если в краткосрочном периоде цена уходит ниже себестоимости, возможно, есть смысл поработать в хранилище.
Но в большинстве случаев такого, конечно, не бывает.
С DRAM как раз ситуация обратная. В этом году цены практически на все компы выросли из-за недостатка памяти на рынке. Производители памяти знали о ситуации, но предпочли не инвестировать в дополнительное производство. Вместо этого взвинтили цены. Отсюда и подорожание всего остального, в чем есть память. Но это длинная история. Там много интересных моментов. Вот для затравочки:
http://www.dramexchange.com/WeeklyResearch/Post/2/4563.html
http://www.dramexchange.com/WeeklyResearch/Post/2/4618.html
По-моему, это мертвая тема.
Хотя, несомненно, заслуженная :)
DAOS использовался в самой первой реализации Burst Buffer'ов совместно с EMC и HDF Group в 2012 году. Эту работу проспонсировал американский Department of Energy.
Насколько мне известно, до продуктизации DAOS дело никогда не доходило. Только экспериментальные наработки…
Верно, этот вопрос я не рассмотрел.
Пока я не вижу широкого использования FPGA или ASIC в HPC. И у меня, к сожалению, нет пока интуиции в этом вопросе.
Хотя, вроде бы, для некоторых направлений HPC FPGA могут быть полезны. Например, в геномике. Вот, например, контора, которая пошла дальше FPGA и предлагает ASIC'и для стандартных геномных алгоритмов: http://www.edicogenome.com/dragen_bioit_platform/
Однако мне неизвестно, насколько хорошо у них идут дела.
Как думаете, какой будет стратегия Интела (и других игроков) в отношении FPGA? И как вся тема будет развиваться?
Тут комментарий по почте прислали. Скопирую-ка я его сюда. Далеко не со всеми моментами согласен. Но это это мнение. И пусть оно будет здесь.
«Майкрософт воспринимает в качестве угрозы именно опен-сорсные операционные системы, а не пиратов. Выходя на российский рынок, компания не сильно заботилась о нарушении своих прав — главным было выдавить с рынка производителей отечественных операционных систем. В то время у нас даже компьютера не было, но существовали российские ОС, лучшие по функциональности, и Майкрософт их выдавил. Компания большая и может пережить небольшую потерю выручки. Главное для них было „подсадить“ пользователя на свой продукт. Когда все дома стали использовать виндоуз, когда предприятия стали использовать виндоуз, когда не осталось конкурентов — тут и начались рейды (в 2000-х). Теперь угроза исходит со стороны свободных ОС, но пользователи крепко „сидят“ на Виндоуз: есть программные пакеты, форматы данных и т.п. В документе, созданном на Либре-офис, например, плывёт форматирование, если его открывать Вордом. Это означает, что ты не можешь обмениваться документами — у большинства ведь Виндоуз. Этот барьер по-научному формулируется как „сетевой эффект“: с каждым новым участников сети возрастает ценность продукты для уже присоединившихся. Так что реальный пример для твоей гипотетической ситуации существует, и бесплатный продукт является в чистом виде агрессией по отношению к конкуренту. Совсем как в заголовке статьи, на которую ты сослался»
А как решается проблема недобросовестной конкуренции?
Вообще говоря, никак. Конкуренция здесь была бы вполне добросовестной. И компания готова на нее пойти.
Во-первых, ее продукт почти не продается. Поэтому борьба идет хоть за какой-то шанс.
Во-вторых, сторонним компаниям не так-то просто будет войти на рынок (если раньше они на нем играли). Потому что для этого нужны ресурсы, каналы продаж и пр.
В-третьих, основная экспертиза относительно продукта все равно остается на стороне той компании, которая его создала. Это дополнительное преимущество.
И еще один момент… Мне пока неизвестно, может ли такая модель приводить к успеху. Я вижу, что ее пытаются использовать, но суперрезультатов еще нет. Хотелось бы узнать какие-то еще примеры, помимо тех, которые мне уже известны. Чтобы расширить круг наблюдения. Надеялся, что публика подскажет :)
Ну и небольшой пример, чтобы проиллюстрировать, как это могло бы работать.
Yahoo! является основным разработчиком Хадупа. Но коммерциализирует его (через отдельно созданный стартап) наравне со многими другими игроками. Здесь надо иметь в виду, что модель здесь все-таки другая, отличная от сценария "освежения тухлого продукта". Хадуп изначально разрабатывался как Open source.
Это уже слишком общО.
Если говорить о сегодняшнем дне, то сейчас у нас экономика не плановая. И «лишний» проект никто душить не будет из-за соображений «денег есть только на один». Нашел деньги — делай, прорывайся на рынок (или даже в оборонку). В этом смысле, никто не мешает создавать в России нормальную конкурентную среду, с нормальными деловыми отношениями. (Если совсем начистоту, то мешают. Но если на этом постоянно зацикливаться, то уж точно ничего не получится).
Так можно было бы сказать про любую отрасль, будь на нее брошены усилия всей страны. Они были брошены на ракеты. И это польностью результат административных мер.
Надеюсь, это не троллинг. Поэтому отвечу на полном серьезе.
Для потребительского рынка Эльбрусу еще очень, нет — ОЧЕНЬ, далеко. И скорее всего, Эльбрус, основанный на широкой команде, его никогда не увидит.
На мой взгляд, Эльбрус сейчас существует, по большей части, для решения вопросов нацбезопасности. Это как Автоваз или УАЗ. Потребители на них ездить не хотят. Однако в военное время оба завода легко могут переключиться на производство танковых шасси, а УАЗы могут использоваться как универсальные вездеходы.
То же самое с Эльбрусами. Они (+ российских софт) позволяют избегать использования зарубежных изделий на стратегических направлениях. Благодаря им, можно не бояться «закладок» в оборудовании и программах, используемых для управления ракетами, например.
Чтобы выйти на потребительский рынок, нужна во-первых, другая архитектура, уже динамическая. Ее нельзя получить инкрементальным развитием широкой команды. Ее надо делать почти с нуля. Для этого нужны частные инвестиции и совсем другая оргструктура. Сейчас МЦСТ больше похож на НИИ. А должен выглядеть как коммерческая корпорация. В частности, это требует совсем другого менеджмента.
Считаю, что при должных вложениях, за несколько лет возможно выработать адекватную архитектуру. Soft Machines здесь неплохой пример (хотя машины на их архитектуре еще не продаются и не факт, что будут).
Главное для России, как я это вижу, не концентрироваться на железе. Как можно больше функциональности надо переложить на софт. Тогда у нас есть шанс.
Если резюмировать, то проблем очень много. На каждый шаг в нужном направлении нужно ценить.
Не имеет значения, где зарегистиррована компания. Это вопрос привлечения инвестиций, а также оптимизации налогообложения, экономических и политических рисков
Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.
Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.
Поэтому если в краткосрочном периоде цена уходит ниже себестоимости, возможно, есть смысл поработать в хранилище.
Но в большинстве случаев такого, конечно, не бывает.
http://www.dramexchange.com/WeeklyResearch/Post/2/4563.html
http://www.dramexchange.com/WeeklyResearch/Post/2/4618.html
Вы занимаетесь системами хранения?
Хотя, несомненно, заслуженная :)
DAOS использовался в самой первой реализации Burst Buffer'ов совместно с EMC и HDF Group в 2012 году. Эту работу проспонсировал американский Department of Energy.
Насколько мне известно, до продуктизации DAOS дело никогда не доходило. Только экспериментальные наработки…
Спасибо, что вспомнили о нем!
Пока я не вижу широкого использования FPGA или ASIC в HPC. И у меня, к сожалению, нет пока интуиции в этом вопросе.
Хотя, вроде бы, для некоторых направлений HPC FPGA могут быть полезны. Например, в геномике. Вот, например, контора, которая пошла дальше FPGA и предлагает ASIC'и для стандартных геномных алгоритмов: http://www.edicogenome.com/dragen_bioit_platform/
Однако мне неизвестно, насколько хорошо у них идут дела.
Как думаете, какой будет стратегия Интела (и других игроков) в отношении FPGA? И как вся тема будет развиваться?
«Майкрософт воспринимает в качестве угрозы именно опен-сорсные операционные системы, а не пиратов. Выходя на российский рынок, компания не сильно заботилась о нарушении своих прав — главным было выдавить с рынка производителей отечественных операционных систем. В то время у нас даже компьютера не было, но существовали российские ОС, лучшие по функциональности, и Майкрософт их выдавил. Компания большая и может пережить небольшую потерю выручки. Главное для них было „подсадить“ пользователя на свой продукт. Когда все дома стали использовать виндоуз, когда предприятия стали использовать виндоуз, когда не осталось конкурентов — тут и начались рейды (в 2000-х). Теперь угроза исходит со стороны свободных ОС, но пользователи крепко „сидят“ на Виндоуз: есть программные пакеты, форматы данных и т.п. В документе, созданном на Либре-офис, например, плывёт форматирование, если его открывать Вордом. Это означает, что ты не можешь обмениваться документами — у большинства ведь Виндоуз. Этот барьер по-научному формулируется как „сетевой эффект“: с каждым новым участников сети возрастает ценность продукты для уже присоединившихся. Так что реальный пример для твоей гипотетической ситуации существует, и бесплатный продукт является в чистом виде агрессией по отношению к конкуренту. Совсем как в заголовке статьи, на которую ты сослался»
Вообще говоря, никак. Конкуренция здесь была бы вполне добросовестной. И компания готова на нее пойти.
Во-первых, ее продукт почти не продается. Поэтому борьба идет хоть за какой-то шанс.
Во-вторых, сторонним компаниям не так-то просто будет войти на рынок (если раньше они на нем играли). Потому что для этого нужны ресурсы, каналы продаж и пр.
В-третьих, основная экспертиза относительно продукта все равно остается на стороне той компании, которая его создала. Это дополнительное преимущество.
И еще один момент… Мне пока неизвестно, может ли такая модель приводить к успеху. Я вижу, что ее пытаются использовать, но суперрезультатов еще нет. Хотелось бы узнать какие-то еще примеры, помимо тех, которые мне уже известны. Чтобы расширить круг наблюдения. Надеялся, что публика подскажет :)
Ну и небольшой пример, чтобы проиллюстрировать, как это могло бы работать.
Yahoo! является основным разработчиком Хадупа. Но коммерциализирует его (через отдельно созданный стартап) наравне со многими другими игроками. Здесь надо иметь в виду, что модель здесь все-таки другая, отличная от сценария "освежения тухлого продукта". Хадуп изначально разрабатывался как Open source.
Если говорить о сегодняшнем дне, то сейчас у нас экономика не плановая. И «лишний» проект никто душить не будет из-за соображений «денег есть только на один». Нашел деньги — делай, прорывайся на рынок (или даже в оборонку). В этом смысле, никто не мешает создавать в России нормальную конкурентную среду, с нормальными деловыми отношениями. (Если совсем начистоту, то мешают. Но если на этом постоянно зацикливаться, то уж точно ничего не получится).
Но для экономики в целом конкуренция необходима.
Для потребительского рынка Эльбрусу еще очень, нет — ОЧЕНЬ, далеко. И скорее всего, Эльбрус, основанный на широкой команде, его никогда не увидит.
На мой взгляд, Эльбрус сейчас существует, по большей части, для решения вопросов нацбезопасности. Это как Автоваз или УАЗ. Потребители на них ездить не хотят. Однако в военное время оба завода легко могут переключиться на производство танковых шасси, а УАЗы могут использоваться как универсальные вездеходы.
То же самое с Эльбрусами. Они (+ российских софт) позволяют избегать использования зарубежных изделий на стратегических направлениях. Благодаря им, можно не бояться «закладок» в оборудовании и программах, используемых для управления ракетами, например.
Чтобы выйти на потребительский рынок, нужна во-первых, другая архитектура, уже динамическая. Ее нельзя получить инкрементальным развитием широкой команды. Ее надо делать почти с нуля. Для этого нужны частные инвестиции и совсем другая оргструктура. Сейчас МЦСТ больше похож на НИИ. А должен выглядеть как коммерческая корпорация. В частности, это требует совсем другого менеджмента.
Считаю, что при должных вложениях, за несколько лет возможно выработать адекватную архитектуру. Soft Machines здесь неплохой пример (хотя машины на их архитектуре еще не продаются и не факт, что будут).
Главное для России, как я это вижу, не концентрироваться на железе. Как можно больше функциональности надо переложить на софт. Тогда у нас есть шанс.
Если резюмировать, то проблем очень много. На каждый шаг в нужном направлении нужно ценить.