Очевидно, прирост производительности и улучшение иных характеристик должно быть не менее, чем на 34%, не так ли?
С хрена ли? (простите мне мой французский...)
Собственно нужно оказывается понимать два момента:
1. Что цены на длительном периоде технического прогресса имеют тенденцию к снижению.
2. Краткосрочные флуктуации не исключают рост не только на 34%, но и 2х-3х кратный.
Лично мне облака как сервис не нравятся, комментарии по этому поводу можно найти далеко не в единственном числе.
Но здесь и сейчас я о конкретной статье.
Ребята задали очень хорошую планку того как действительно нужно считать целесообразность.
Да, есть упущения (то ли в виду сложности, вы и так жалуетесь на объем информации, то ли в целях создания позитивного образа — в данном контексте не суть).
Но в целом статья заметно выделяется на общем уровне принятия решений и оценки необходимости облаков. И выделяется в лучшую сторону
Вот не совсем заслуженно накинулись. Да в статье есть углы, которые обошли.
Но вы оцените сам уровень и подход. Ребята явно старались комплексно оценить. И, сравнивая с другими публикациями этой же тематики на хабре, — статья отличная.
И, да, пока что на горизонте я для себя IaaS пока не вижу разумным :)
the Core i9-9900K is set to cost $488 (источник гугл)
http://processortimeline.info/proc1980.htm
80286 в 1982 стоил 360$, что в текущий момент составляет 360*2.6 = 940
Может хватит ныть по обывательски и все же включить мозг?
Тогда мне тем более не понятен ваш фанатизм в отстаивании вашей узкой картины мира.
Попробуйте изучить нормы более чем одной культуры, чтобы подняться до уровня понимания неоднозначности норм. И о том что "хорошо" — оно для всех разное.
Кому-то, кому по моему мнению, эта польза необходима.
Ваше мнение, как референсное, для определения ценностей остальных малость попахивает завышенным самомнением в лучшем случае. А в худшем — намеренным причинением вреда другим путем навязывания своей точки зрения личностям со слабоустойчивой психикой.
И, на всякий случай, см.выше — нормы они разные. То что какие-то нормы близки мне или вам не означает их всеобщую эффективность, полезность и догматическую правильность.
Законы и нормы слишком неоднозначные понятия.
Почему вы «своим» считаете общество, например, США, но не, скажем, Ирана.
Ведь ни там, ни там вы фактически не живёте и не воспитывались.
Так почему же нормы и законы насаждаемые (но не принятые повсеместно и всеми) движениями феминисток и геев вам лично ближе, чем норма забивания камнями?
Бездоказательно.
Равно как и само наличие права у кого-либо.
И даже если это записано в каких-либо скрижалях это не становится законом сродни числу пи и т.п.
Она в общем и целом и есть слабостью.
Вы слабы и поэтому вы вынуждены прогибаться (быть вежливым в чужих глазах) под мнение собеседника, общества и т.п… Ибо не дай бог вдруг что…
Устранение проблем с ошибками схемы в среднем занимало 1-2 инциндента по 0.1-0.5 часа на 4 двухнедельных релиза.
Т.е. за год работы не более 6.5 часов
Парсинг и анализ чистых SQL из кода больше трех дней занял у разработчика насколько я помню.
Анализ запросов формируемых QueryBuilder и DQL в общем случае не взлетел и решили не продолжать после чистого SQL.
1. Отвратительно работает с сетью при сколь-либо значимых нагрузках.
2. И крайне чувствителен к ее качеству. Ровно настолько, что в реальном случае была одна «мигающая» машина (вина тоже скорее всего traefik, но так как это не было доказано на 100%, то опустим), которую traefik с некоторой периодичностью переставал видеть. После чего начиналась перестройка маршрутизации у него и на это время ложились все машины.
А поскольку та, самая «мигающая» до завершения перестройки маршрутизации объявлялась вновь… То… Процесс повторялся.
Для тех целей где он себя позиционирует — это недопустимо.
В деве же использовать его удобно — да. Но дев как раз лучше держать близким к продакшену по конфигурации.
а потом начал загоняться по всяким там возможностям выводить типы, верифицировать запрос (даже по частям) на соответствие схеме без необходимости запуска оного
Блин, а зачем так упарываться?
Я вот объективно не видел систем такой сложности где это бы требовалось и было в хоть сколько-то окупаемом виде.
Зря ведёте дискуссию.
Ваш оппонент плавает в темах, что монолита, что микросервисов.
Причём ужасно плавает.
С хрена ли? (простите мне мой французский...)
Собственно нужно оказывается понимать два момента:
1. Что цены на длительном периоде технического прогресса имеют тенденцию к снижению.
2. Краткосрочные флуктуации не исключают рост не только на 34%, но и 2х-3х кратный.
https://habr.com/company/activecloudru/blog/415483/#comment_18853179
Просто для общей картины.
Лично мне облака как сервис не нравятся, комментарии по этому поводу можно найти далеко не в единственном числе.
Но здесь и сейчас я о конкретной статье.
Ребята задали очень хорошую планку того как действительно нужно считать целесообразность.
Да, есть упущения (то ли в виду сложности, вы и так жалуетесь на объем информации, то ли в целях создания позитивного образа — в данном контексте не суть).
Но в целом статья заметно выделяется на общем уровне принятия решений и оценки необходимости облаков. И выделяется в лучшую сторону
Вот не совсем заслуженно накинулись. Да в статье есть углы, которые обошли.
Но вы оцените сам уровень и подход. Ребята явно старались комплексно оценить. И, сравнивая с другими публикациями этой же тематики на хабре, — статья отличная.
И, да, пока что на горизонте я для себя IaaS пока не вижу разумным :)
Вот просто с кондачка за несколько минут…
the Core i9-9900K is set to cost $488 (источник гугл)
http://processortimeline.info/proc1980.htm
80286 в 1982 стоил 360$, что в текущий момент составляет 360*2.6 = 940
Может хватит ныть по обывательски и все же включить мозг?
И как там сервера на ARM у вас в продакшене?
Это не только напоминание.
Никто вас не ограничивает использовать пайплайны в рамках внутренней механики вашего MVC.
Это будет несколько проще чем пытаться внедрить сценарии. Тем более с условиями и ветвлениями
Условия противоречат принципу пайплайна.
Вы или обрабатываете запрос или просто передаёте управление дальше.
Если очень хочется ветвлений, то можно посмотреть в сторону Symfony workflow, но мне он не очень нравится
docs.zendframework.com/zend-expressive/v3/getting-started/quick-start/#piping
Ок. Принято.
Тогда мне тем более не понятен ваш фанатизм в отстаивании вашей узкой картины мира.
Попробуйте изучить нормы более чем одной культуры, чтобы подняться до уровня понимания неоднозначности норм. И о том что "хорошо" — оно для всех разное.
Ваше мнение, как референсное, для определения ценностей остальных малость попахивает завышенным самомнением в лучшем случае. А в худшем — намеренным причинением вреда другим путем навязывания своей точки зрения личностям со слабоустойчивой психикой.
И, на всякий случай, см.выше — нормы они разные. То что какие-то нормы близки мне или вам не означает их всеобщую эффективность, полезность и догматическую правильность.
Почему вы «своим» считаете общество, например, США, но не, скажем, Ирана.
Ведь ни там, ни там вы фактически не живёте и не воспитывались.
Так почему же нормы и законы насаждаемые (но не принятые повсеместно и всеми) движениями феминисток и геев вам лично ближе, чем норма забивания камнями?
Бездоказательно.
Равно как и само наличие права у кого-либо.
И даже если это записано в каких-либо скрижалях это не становится законом сродни числу пи и т.п.
Почему вы свои иллюзии выдаете за реальность?
Вы слабы и поэтому вы вынуждены прогибаться (быть вежливым в чужих глазах) под мнение собеседника, общества и т.п… Ибо не дай бог вдруг что…
Когда прод 5.3, а тестовая 7.1, то нужно брать гвозди двухсотки и идти забивать их в голову девопсам и тимлидам.
Так нельзя работать и разрабатывать.
В конечном счёте есть Docker, который обещает равное окружение хотя бы на уровне версий пхп.
Устранение проблем с ошибками схемы в среднем занимало 1-2 инциндента по 0.1-0.5 часа на 4 двухнедельных релиза.
Т.е. за год работы не более 6.5 часов
Парсинг и анализ чистых SQL из кода больше трех дней занял у разработчика насколько я помню.
Анализ запросов формируемых QueryBuilder и DQL в общем случае не взлетел и решили не продолжать после чистого SQL.
2. И крайне чувствителен к ее качеству. Ровно настолько, что в реальном случае была одна «мигающая» машина (вина тоже скорее всего traefik, но так как это не было доказано на 100%, то опустим), которую traefik с некоторой периодичностью переставал видеть. После чего начиналась перестройка маршрутизации у него и на это время ложились все машины.
А поскольку та, самая «мигающая» до завершения перестройки маршрутизации объявлялась вновь… То… Процесс повторялся.
Для тех целей где он себя позиционирует — это недопустимо.
В деве же использовать его удобно — да. Но дев как раз лучше держать близким к продакшену по конфигурации.
Блин, а зачем так упарываться?
Я вот объективно не видел систем такой сложности где это бы требовалось и было в хоть сколько-то окупаемом виде.
Глючное поделие.
Дополнительная секунда