Системная аналитика возможна только когда человек является экспертом в каком то домене, а не вся эта хрень с бесполезным Rest и тупыми вопросами про Кафку.
Абсолютно не согласен. Во-первых экспертиза не возникает на пустом месте, а во-вторых основы функционирования и принципы проектирования информационных систем универсальны и плюс-минус едины относительно любого домена.
Судя по статье никто не понимает что за хрень вся эта системная аналитика. В 80% случаях вообще ничего из описанного не пригодится.
В заголовке статьи указано, что она является обзорной и вводной статьей из запланированной мной серии, поэтому ваши реакционные выводы слишком поспешны, на мой взгляд.
С "системной аналитикой", к сожалению, действительно все очень печально обстоит в индустрии. По крайней мере в РФ. Специалистов не хватает, а компании предлагают довольно существенные з/п на этой позиции.
Литературы минимально, в ВУЗах на это если и учат, то крайне избирательно (в целом позиция СА на мой взгляд - это скорее набор хард/софт навыков, нежели специализация), а завеса тумана, особенно для новичков, присутствует.
Именно поэтому я и пытаюсь изложить свои знания, чтобы помочь другим получить представление о профессии или узнать что-то новое.
К тому же невозможно расти в замкнутой среде, поэтому статьи на Хабр - один из способов профессионального развития и для меня в том числе.
На уровне реализации можно с любым запросом поработать асинхронно. Например: с использованием того же REST отправили запрос с клиента на сервер о генерации какого-либо отчета, получили ответ - запрос в обработке; поместили сообщение в очередь, обработали и прислали результат. Почему так не может быть?
Вы полностью правы, именно такой подход я и имел в виду, когда отвечал о вариантах с коллбэками на предыдущий комментарий выше. Дополню статью этой выкладкой.
В статье я указывал, что примером синхронного взаимодействия может быть REST или gRPC, там есть слова, явно об этом говорящие.
Привязка конкретных технологий/протоколов к понятию синхронности/асинхронности действительно имеющий место быть вопрос. Но на мой взгляд, удобнее и логичнее использовать технологии по их прямому назначению, нежели изобретать велосипед, оборачивая синхронные взаимодействия во что-либо еще. Опять же - это архитектурный вопрос компромиссов и рисков.
откуда вы взяли, что у вас пакеты ходят на каждом уровне? Понятие пакеты относится только к сетевому уровню - IP.
Я этого и не утверждал
информация разделяется на пакеты, каждый из которых получает свой уникальный IP-адрес, указывающий на конечную точку доставки" - это вообще нонсенс :)
Слово "пакет" в контексте абзаца использовалось исключительно как обозначение некой структуры данных. Но спасибо, что обратили внимание, я исправил, дабы не вносить смуту.
Если вы имеете в виду картинки с абстрактным примером распределённой системы, то, на мой взгляд, они имеют прямое отношение к работе системного аналитика, поскольку хороший аналитик помимо выявления и описания требований к разработке (как своей прямой задачи) может и должен уметь проектировать солюшен архитектуру или хотя бы HLD.
А этими картинками я как раз и хотел продемонстрировать этот артефакт работы аналитика, поскольку предполагаю, что многих заинтересует как может выглядеть архитектура абстрактной системы.
Остальные картинки просто являются иллюстрацией тех или иных теоретических выкладок.
С тем, что для «новичков» это может быть сложно для восприятия я полностью согласен, но это лишь первая обзорная статья из запланированной мной серии.
Абсолютно не согласен. Во-первых экспертиза не возникает на пустом месте, а во-вторых основы функционирования и принципы проектирования информационных систем универсальны и плюс-минус едины относительно любого домена.
В заголовке статьи указано, что она является обзорной и вводной статьей из запланированной мной серии, поэтому ваши реакционные выводы слишком поспешны, на мой взгляд.
С "системной аналитикой", к сожалению, действительно все очень печально обстоит в индустрии. По крайней мере в РФ. Специалистов не хватает, а компании предлагают довольно существенные з/п на этой позиции.
Литературы минимально, в ВУЗах на это если и учат, то крайне избирательно (в целом позиция СА на мой взгляд - это скорее набор хард/софт навыков, нежели специализация), а завеса тумана, особенно для новичков, присутствует.
Именно поэтому я и пытаюсь изложить свои знания, чтобы помочь другим получить представление о профессии или узнать что-то новое.
К тому же невозможно расти в замкнутой среде, поэтому статьи на Хабр - один из способов профессионального развития и для меня в том числе.
Вы полностью правы, именно такой подход я и имел в виду, когда отвечал о вариантах с коллбэками на предыдущий комментарий выше. Дополню статью этой выкладкой.
В статье я указывал, что примером синхронного взаимодействия может быть REST или gRPC, там есть слова, явно об этом говорящие.
Привязка конкретных технологий/протоколов к понятию синхронности/асинхронности действительно имеющий место быть вопрос. Но на мой взгляд, удобнее и логичнее использовать технологии по их прямому назначению, нежели изобретать велосипед, оборачивая синхронные взаимодействия во что-либо еще. Опять же - это архитектурный вопрос компромиссов и рисков.
Я этого и не утверждал
Слово "пакет" в контексте абзаца использовалось исключительно как обозначение некой структуры данных. Но спасибо, что обратили внимание, я исправил, дабы не вносить смуту.
excalidraw.com
Потому что выполнение вызывающей процедуры приостанавливается с момента запроса и возобновляется только после возврата из вызываемой процедуры.
Можно конечно изобретать асинхронные варианты с коллбэками, но тут уже вопрос целесообразности.
Согласен с тем, что модель OSI и TCP/IP это сугубо теория, но в статье и говорится о том, что это «база», которую необходимо знать.
Как минимум для того, чтобы потом не спроектировать какой-нибудь стриминговый сервис, который будет работать по TCP ;-)
Если вы имеете в виду картинки с абстрактным примером распределённой системы, то, на мой взгляд, они имеют прямое отношение к работе системного аналитика, поскольку хороший аналитик помимо выявления и описания требований к разработке (как своей прямой задачи) может и должен уметь проектировать солюшен архитектуру или хотя бы HLD.
А этими картинками я как раз и хотел продемонстрировать этот артефакт работы аналитика, поскольку предполагаю, что многих заинтересует как может выглядеть архитектура абстрактной системы.
Остальные картинки просто являются иллюстрацией тех или иных теоретических выкладок.
С тем, что для «новичков» это может быть сложно для восприятия я полностью согласен, но это лишь первая обзорная статья из запланированной мной серии.
Спасибо за предложение, я обязательно запланирую выход такой статьи, с разбором какого-нибудь практического кейса.