существенного профита относительно текущего подхода нам это не даст, поэтому пока не стали переделывать
А почему если не секрет вы такое предположение делаете? Кмк проще сразу новые данные по событию записать чем узнать из него что что-то "протухло" и прийти за новыми данными? )
Пардон за занудство, но все таки soap это протокол (в оглавлении) или архитектурный стиль (по тексту)?
К слову, нередкий вопрос на собесах аналитиков, важно помнить что rest(ful) это стиль проектирования апи (который часто не соблюдается в http api), а soap, grpc и далее по списку - протоколы, то бишь инструменты. При остром желании можно soap over http api даже сделать :)
Честно говоря, определение MSA спорное) А главная проблема MSA, на мой взгляд, - пихать ее во все места. Не понимая области применимости, плюсов минусов, которые она несет ) И ни логированием хорошим, ни api gateway'ем этого не решить как ни старайся)
Вы абсолютно правы. Redis - вообще не "база данных", как утверждает автор. Это "in-memory data structure store". Так что в целом сравнение выглядит немного странно - если изначально нужен был in-memory key-value storage, то выбор хазла изначально был прям скажем неочевиден ))
Такой вариант возможен и даже работает, но не всегда ) Условно, заказчик с БА решают что надо пользователю уведомления слать через пуши. Требования отдают солюшну, тот рисует квадратик "пуш гейта", sdk в прикладе и счастливо отдает в реализацию. Только вот проблема что нет и гейта, ни sdk. И надо выбирать, внедрять, адаптировать.
На этом месте наверняка захочется сказать - да делов то, на файрбейсе сейчас приляпаем за пару дней. Однако хотел бы напомнить, что это просто пример создания IT capability с нуля, который может быть трудоемок прежде всего процессом согласования.
Возвращаемся к нашему сценарию. Итак, мы потратили 2-3 месяца чтобы все это сделать, внедрили. И тут оказалось что бизнес-гипотеза не сработала и все наши месяцы работы не окупяться в ближайшее время, мы в минусе.
А как можно по другому? А можно было на этапе обсуждения клиентского пути вместе с заказчиком и БА сказать: "Гайз, короче пушей сейчас нет, делать их примерно вот столько времени и денег. Но можем взять email уведомления с диплинками. Это уже сейчас работает. Да, клиентский опыт чуть хуже, но зато базовые параметры гипотезы позволит проверить без больших затрат. И уже только если гипотеза выстрелила - сделать нормально.
Важно! В данном случае не сам солюшн может придумать обходной маневр, это может предложить любой участик обсуждения. Важно чтобы заказчик и БА понимали "зрелость" ит решений и подстраивали итоговый клиентский путь с их учетом. Понимая цены риска каждого из вариантов реализации и выбирая вместе оптимальный.
Если позволите, немного обратной связи от коллеги)
Вы справедливо заметили что навыки презентации и продажи чертовски важны для роли SA. Но сама статья по структуре получилось рыхлая - без вводной, проблематизации, тезисов и поддержки, краткого резюме. Визуал имхо не очень подкрепляет материал. Нет акцентов по тексту, структура сливается в поток мыслей.
В качестве верхней булки "бутерброда" - опыт интересный, спасибо. Продолжайте делиться, удачи на вечном пути к совершенству формы и содержания)
Касаемо участия солюшнов в пресейлах и помощи в продаже - могу сказать по своему опыту что для вендоров это вполне обычная практика. Собсно, а почему бы и нет? Если у человека хорошо получается, то флаг в руки имхо.
На мой взгляд, вопрос таксономии архитекторов не раскрыт ) Даже быстрый просмотр статьи википедии дает понимание, что единого мнения/определения нет. Да что уж там, в разных компаниях одной отрасли эта роль часто может иметь разный набор обязанностей)) Отсюда и недопонимание о сроках возникновения роли кмк.
Спасибо за статью, одна из самых интересных на мой взгляд за последнее время. Подскажите, не планируете компоненты платформы, например, тот же warden опенсорсить? )
В качестве рекомендации, если позволите - чтобы избавиться от ручного заполнения табличных представлений, можно попробовать какой-то EA Tool (со всеми вытекающими в части реф. модели, процессов и т.п.) или хотя бы автоматизировать формирование таблицы из атрибутов объектов схемы
Тут вопрос наверное в том кто потребители этой информации и цели ее формализации в виде артефакта. Вот есть неФТ, надо под некий SLA спроектировать отказо- и катастрофоустойчивое решение. Вы балансировку шардов субд, инстансы приложения покажете на одном вью, а размещение их на условном бэйрбоне и раунд-робин балансир по IP на другом вью? не кажется ли вам что могут возникнуть вопросы с совмещением информации в единую картину на разных уровнях OSI?
Подождите, но эта информация по функционалке где-то должна быть. Аргумент "командам для старта хватит" - ну такое, с ньюансами. В целом команды и без этого наверное могли побежать ) Чтоб бизнес-аналитик - встречал такое, но обычно после формулирования БТ и проработки инф. архитектуры.
Важно всегда в контексте server driven ui упоминать и ограничения. А их довольно много, и подход этот хорош для формирования довольно однообразных форм. Главное не пытаться через такой подход делать все экраны, иначе вы получите ситуацию, которую я видел в одной компании: описалки экрана на 1-2 мегабайта и отдельная субпрофессия аналитика/json-разработчика )
Не планируете ли в опенсурс? Область достаточно горячая, конкурентов много и набрать коммьюнити будет тяжело кмк, если будет только в вашем облаке и он-премис.
А почему если не секрет вы такое предположение делаете? Кмк проще сразу новые данные по событию записать чем узнать из него что что-то "протухло" и прийти за новыми данными? )
я имел в виду json over http с попыткой использования методов как глаголов, но при этом без соблюдения арх паттерна rest(ful).
Пардон за занудство, но все таки soap это протокол (в оглавлении) или архитектурный стиль (по тексту)?
К слову, нередкий вопрос на собесах аналитиков, важно помнить что rest(ful) это стиль проектирования апи (который часто не соблюдается в http api), а soap, grpc и далее по списку - протоколы, то бишь инструменты. При остром желании можно soap over http api даже сделать :)
Честно говоря, определение MSA спорное) А главная проблема MSA, на мой взгляд, - пихать ее во все места. Не понимая области применимости, плюсов минусов, которые она несет ) И ни логированием хорошим, ни api gateway'ем этого не решить как ни старайся)
Также можно на dragonfly посмотреть еще - тоже выглядит интересно как замена редису.
Вы абсолютно правы. Redis - вообще не "база данных", как утверждает автор. Это "in-memory data structure store". Так что в целом сравнение выглядит немного странно - если изначально нужен был in-memory key-value storage, то выбор хазла изначально был прям скажем неочевиден ))
В любом распределенном хранилище strong consistency недостижима насколько я знаю. максимум eventual
Такой вариант возможен и даже работает, но не всегда ) Условно, заказчик с БА решают что надо пользователю уведомления слать через пуши. Требования отдают солюшну, тот рисует квадратик "пуш гейта", sdk в прикладе и счастливо отдает в реализацию. Только вот проблема что нет и гейта, ни sdk. И надо выбирать, внедрять, адаптировать.
На этом месте наверняка захочется сказать - да делов то, на файрбейсе сейчас приляпаем за пару дней. Однако хотел бы напомнить, что это просто пример создания IT capability с нуля, который может быть трудоемок прежде всего процессом согласования.
Возвращаемся к нашему сценарию. Итак, мы потратили 2-3 месяца чтобы все это сделать, внедрили. И тут оказалось что бизнес-гипотеза не сработала и все наши месяцы работы не окупяться в ближайшее время, мы в минусе.
А как можно по другому? А можно было на этапе обсуждения клиентского пути вместе с заказчиком и БА сказать: "Гайз, короче пушей сейчас нет, делать их примерно вот столько времени и денег. Но можем взять email уведомления с диплинками. Это уже сейчас работает. Да, клиентский опыт чуть хуже, но зато базовые параметры гипотезы позволит проверить без больших затрат. И уже только если гипотеза выстрелила - сделать нормально.
Важно! В данном случае не сам солюшн может придумать обходной маневр, это может предложить любой участик обсуждения. Важно чтобы заказчик и БА понимали "зрелость" ит решений и подстраивали итоговый клиентский путь с их учетом. Понимая цены риска каждого из вариантов реализации и выбирая вместе оптимальный.
Если позволите, немного обратной связи от коллеги)
Вы справедливо заметили что навыки презентации и продажи чертовски важны для роли SA. Но сама статья по структуре получилось рыхлая - без вводной, проблематизации, тезисов и поддержки, краткого резюме. Визуал имхо не очень подкрепляет материал. Нет акцентов по тексту, структура сливается в поток мыслей.
В качестве верхней булки "бутерброда" - опыт интересный, спасибо. Продолжайте делиться, удачи на вечном пути к совершенству формы и содержания)
Касаемо участия солюшнов в пресейлах и помощи в продаже - могу сказать по своему опыту что для вендоров это вполне обычная практика. Собсно, а почему бы и нет? Если у человека хорошо получается, то флаг в руки имхо.
На мой взгляд, вопрос таксономии архитекторов не раскрыт ) Даже быстрый просмотр статьи википедии дает понимание, что единого мнения/определения нет. Да что уж там, в разных компаниях одной отрасли эта роль часто может иметь разный набор обязанностей)) Отсюда и недопонимание о сроках возникновения роли кмк.
Спасибо за статью, одна из самых интересных на мой взгляд за последнее время. Подскажите, не планируете компоненты платформы, например, тот же warden опенсорсить? )
В качестве рекомендации, если позволите - чтобы избавиться от ручного заполнения табличных представлений, можно попробовать какой-то EA Tool (со всеми вытекающими в части реф. модели, процессов и т.п.) или хотя бы автоматизировать формирование таблицы из атрибутов объектов схемы
Тут вопрос наверное в том кто потребители этой информации и цели ее формализации в виде артефакта. Вот есть неФТ, надо под некий SLA спроектировать отказо- и катастрофоустойчивое решение. Вы балансировку шардов субд, инстансы приложения покажете на одном вью, а размещение их на условном бэйрбоне и раунд-робин балансир по IP на другом вью? не кажется ли вам что могут возникнуть вопросы с совмещением информации в единую картину на разных уровнях OSI?
А разделы 3.3 и 3.4 точно разные? Табличные представления руками заполняете или используете какие-то тулы?
Подождите, но эта информация по функционалке где-то должна быть. Аргумент "командам для старта хватит" - ну такое, с ньюансами. В целом команды и без этого наверное могли побежать ) Чтоб бизнес-аналитик - встречал такое, но обычно после формулирования БТ и проработки инф. архитектуры.
Небольшое замечание - все же высокоуровневый дизайн обычно называют HLD, HAL обычно используют для hardware abstraction level
Важно всегда в контексте server driven ui упоминать и ограничения. А их довольно много, и подход этот хорош для формирования довольно однообразных форм. Главное не пытаться через такой подход делать все экраны, иначе вы получите ситуацию, которую я видел в одной компании: описалки экрана на 1-2 мегабайта и отдельная субпрофессия аналитика/json-разработчика )
Кажется, стоит начать с того что rest и rpc это паттерн, а soap протокол )
Не планируете ли в опенсурс? Область достаточно горячая, конкурентов много и набрать коммьюнити будет тяжело кмк, если будет только в вашем облаке и он-премис.