AS
Не может быть она решена таким образом так как лежит несколько в другой плоскости
Size: a a a
2017 May 25
RK
Так ведь была ж -- ускорили релизы
AS
В смысле полностью решена
RK
Если бизнес устраивает, то значит решена с достаточной степенью полноты
IK
Как только скорость увеличивается значительно, можно начинать пересматривать подход к системе. По факту это и есть одна из задач архитектуры - обеспечивать цели бизнеса через технологии. Возросшая скорость изменений влечет повышение требований к модифицируемости и адаптивности (как пример), и один из способов их обеспечения - измерение архитектуры в сторону чего-то микросервисо-подобного. В общем, противоречий не вижу, если честно. ))
Я про то в общем, что не только бизнес драйвит ИТ, но ИТ в свою очередь задает бизнесу новую скорость - например, за счет отказа от делания чего-то ненужного. Или делания чего-то иначе. То есть конечно меняется не только метрика (скорость), но и способ организации системы, что позволяет менять построенной на системе бизнес (без инициативы бизнеса). По крайней мере, я в это верю )
AS
Так и я о том же :) Есть организации где и релиз раз в год устраивает. Благо админ ресурс помогает не заботиться о конкуренции.
RK
Нет, мы с вами о разном
RK
Я -- про то, что задача ускорения была решена изменением процесса
RK
Без всякой MSA
AS
Бизнесу стало легче это хорошо. Но конкуренты энтерпрайзов в ближайшем будущем это яндексы и гуглы. И тут одним канбаном не обойдешься.
RK
Не могу удержаться, но без деталей, сорри -- я знаю пару важных яндексовых внутренних сервисов, которые обслуживают кучу внешних клиентских сервисов, которые развиваются без всяких микросервисов и даже без канбана :) Поэтому не обобщайте плиз.
AS
Я про то в общем, что не только бизнес драйвит ИТ, но ИТ в свою очередь задает бизнесу новую скорость - например, за счет отказа от делания чего-то ненужного. Или делания чего-то иначе. То есть конечно меняется не только метрика (скорость), но и способ организации системы, что позволяет менять построенной на системе бизнес (без инициативы бизнеса). По крайней мере, я в это верю )
+1
RK
Бизнесу стало легче это хорошо. Но конкуренты энтерпрайзов в ближайшем будущем это яндексы и гуглы. И тут одним канбаном не обойдешься.
В общем, давайте без визионерства, а поближе к земле:)
AS
В общем, давайте без визионерства, а поближе к земле:)
Как это без визионерства? А зачем вообще нужны архитекторы?
2017 May 26
RK
Проблемы 'монолитных приложений', которые все озвучивают, во всей красоте есть только у сферических монолитных приложений в вакууме. В реальности все не так однозначно. Для начала таки нет чисто монолитных приложений -- так что в одном было все. Приложений обычно несколько, даже обычно много у кровавого ынтерпрайза особенно, они друг с другом интегрируются как-то, часто через шину. И возникающие проблемы с развитием могут быть решены без революционного перехода на MSA. Например, организационно.
RK
Как это без визионерства? А зачем вообще нужны архитекторы?
Бизнс развивают не архитекторы, сорри. Они отвечают на потребности наилучшим образом выбирая решение, планируя на каком то горизонте. Факт того, что большинство компаний не Гугл и даже не Убер находится вне зоны компетенции архитекторов. Поэтому не надо пытаться считать свою компанию тем, кем она не является и предлагать ей сходу чужие решения.
GK
Не могу удержаться, но без деталей, сорри -- я знаю пару важных яндексовых внутренних сервисов, которые обслуживают кучу внешних клиентских сервисов, которые развиваются без всяких микросервисов и даже без канбана :) Поэтому не обобщайте плиз.
Именно. В сложном ИТ- ландшафте есть и будут решения, которые нерационально делать в соответствии с MSA. Если говорить строго, то архитектурный стиль выбирается на основе архитектурно значимых требований. MSA - один из стилей, не серебряная пуля. Иногда, даже не иногда, 3 Tipe подходит лучше.
GK
Что касается MolithFirst. Видел решения, которые MonolithLast. То есть когда решение задумывается как Service Based, так и дизайнится, но не расщепляется, потому что потребности не возникает. Нужно из реальных потребностей исходить, а не упражняться в технологиях и гнаться за модой.
MS
Забавная заметка о том как менеджеры распределяют задачи по продуктам https://medium.com/@navdanina_1810/%D1%8D%D1%82%D0%BE%D0%BC%D1%83-%D0%B4%D0%B0%D0%BB%D0%B0-%D1%8D%D1%82%D0%BE%D0%BC%D1%83-%D0%B4%D0%B0%D0%BB%D0%B0-%D0%B0-%D1%8D%D1%82%D0%BE%D0%BC%D1%83-%D0%BD%D0%B5-%D0%B4%D0%B0%D0%BB%D0%B0-%D0%B8%D0%BB%D0%B8-%D0%BA%D0%B0%D0%BA-%D0%B2%D0%BF%D0%B8%D1%85%D0%BD%D1%83%D1%82%D1%8C-%D0%BD%D0%B5%D0%B2%D0%BF%D0%B8%D1%85%D1%83%D0%B5%D0%BC%D0%BE%D0%B5-%D0%B2-%D1%81%D0%B2%D0%BE%D0%B9-%D0%B1%D1%8D%D0%BA%D0%BB%D0%BE%D0%B3-dd0e77113235
E
Сколько интересного интересного пропустил. Заметка интересна прежде всего тем, что это реальный практический опыт. Ну а глобально это не только о задачах и продуктах - в целом, как организоваться, если задач слишком много - это и для команды верно и для отдельных людей.