"Обратный" подход тоесть contract first становится предпочтительней и важне как только вы подымаете голову из одного конкретного сервиса и смотрите на ваш сервисный ландшафт. Например если вы архитектор или проэктный мэнеджер или решате подобные задачи в любой другой роли.
Тоесь сначала вы пишите технический контракт API а потом уже реализацию. Очень верятно что это будет цикл: получил фидбек — улучшил.
Я например в какой-то момент задолбался обьяснять слишком удаленным от меня программерам (в nearshoring) что нельзя просто так взятъ и поменять api. Теперь им из Open API генерится библиотека содержащая Java Interafaces in Value Objects, все версионированно. Ошибки конечно ещё можно сделать но хотябы тип возвращаемого или поличемого обьекта не меняется больше без предупреждения и т.д.
Но Куда важнее другая тема. Имея представление о API в техническом формате мы смогли ускорить разработчиков клиентского приложения. Их команда смогла на 6-9 месяцев раньше начать писать их приложение и давать нам фидбек к нашему API которое которое на тот момент сущёствовало только как Open API без написаных сервисов.
Этот ваш "я как-то продал" и есть фактически определяющая штука микросервисной архитектуры. Независимые release/deployment цыклы сервисов. Это то чем микросервисный подход отличаются от модульного монолита например.
Ну в таком сценарии надо ставить, да. Идея хорошая если истио так и так стоит. У нас пока нет меш-подобных.
Вы как пользуетесь если не секрет? Какие задачи мешом решаете? не ради логгинга же?
https://de.wikipedia.org/wiki/Stromgestehungskosten
*Kernenergie — атом
Photovoltaik Kleinanlage (DE) — фотовольтаика малого типа (видимо на частных домах в германии)
Photovoltaik Großkraftwerk — фотовольтаика, большая
Ну camunda это когда-то форк от jBMPM, который нормально допили во всех аспектах (за последними набурками уже давно не слежу).
Он был изначально девелоперфрендли и запустить его можно хоть в спринге (отвязали от jboss давно, когда я ещё консалтил).
Дописали куцу тулов, красивых едиторов и таскменеджеров, платных и бесплатных. От комьюнити тоже были.
А главное эти ребята консалтят и уже как лет 10 имеют полный цыкл, внедряют (пеимущёственно в немецкие) фирмы всех размеров и опыт отдают назад в код.
Прогресс не сотоит на месте, они накппив опыты решили сделать даже горизонтально распределяемую альтернативу камунде, https://zeebe.io/.
но мне не довелось попробовать...
Так и есть. И это аргумент против этой ерунды с обфускацией или переносом портов (если перенос порта не решает другой проблемы)
Лучше не создавать илюзии безопасности и не говорить о ней а честно оценивать риски. Если шеф говорит пока нет риска и вы говорите "у нас нет никакой безопасности" это понятно и открыто. И ситуация может заставить вас занятся "нормальной" безопасностью. Ежели вы начинаете коммуникацию типа ну это не надежно но у нас уже есть "обфускация", то ваша организация особенно далекие от темы люди могут решить, что кое какие меры таки приняты и ваша задница кое-как да прикрыта (Но это не так!), тем самым откладывая настояще выделение ресурсов на решение проблемы… Я лично сталкивался с этом и думаю в этом основной АНТИПЭТТЕРН или покрайней мере не малый его аспект.
Спасибо.
Я вот тоже подошел вплотную к Аксон. Но это скорее сайд проджект пока. Ходил пока только вокруг да почитывал.
Выглядит у них все очень интересно и Event Sourcing и CQRS продуманы и осознанны — мне так верится из их сторитейлинга покрайней мере.
А также их сервер осознаное и правильное решение. Но! он ещё достаточно свеж, комьюнити не большое (но может и сильное! знаю пару людей от туда).
И если у меня нет претензий к фреймворку у меня есть некая настороженость к лицензионной моделеи сервера. Не люблю я, когда кластеринг за деньги (а деньги там большие).
Как вы смотрите на этот вопрос? Будет интересно узнать.
Ещё как я понял фреймворк имплицитно создает схему эвентов. Мне бы хотелось эйксплицитно (например как-то с Apache Avro) вы как-то с этим заморачивались?
Тоже было бы интересно...
Я 15 лет в немецком ИТ. Немецкий очень важен! И только последние лет 5 было "прозрение" (особенно в Берлине) что мол хрен сним с немецким. Я сам удивился в какой-то момент. С хедхантерами общаюсь чуть ли не ежденевно.
У меня с немецким все Ок.
В Германии крупные компании все меньше интересуются каким-то Реакт или прочей узкой специализацией…
Да и многие мелкие тоже. К CV инностранцев могут вполне настороженно относитя лиш потому что, что-то по не ожданному шаблону.
Немцам опыт в других непонятных им странах мало что говорит.
"Обратный" подход тоесть contract first становится предпочтительней и важне как только вы подымаете голову из одного конкретного сервиса и смотрите на ваш сервисный ландшафт. Например если вы архитектор или проэктный мэнеджер или решате подобные задачи в любой другой роли.
Тоесь сначала вы пишите технический контракт API а потом уже реализацию. Очень верятно что это будет цикл: получил фидбек — улучшил.
Я например в какой-то момент задолбался обьяснять слишком удаленным от меня программерам (в nearshoring) что нельзя просто так взятъ и поменять api. Теперь им из Open API генерится библиотека содержащая Java Interafaces in Value Objects, все версионированно. Ошибки конечно ещё можно сделать но хотябы тип возвращаемого или поличемого обьекта не меняется больше без предупреждения и т.д.
Но Куда важнее другая тема. Имея представление о API в техническом формате мы смогли ускорить разработчиков клиентского приложения. Их команда смогла на 6-9 месяцев раньше начать писать их приложение и давать нам фидбек к нашему API которое которое на тот момент сущёствовало только как Open API без написаных сервисов.
Где эту анимашечку можно покрутить?
спасибо. не очень много, если появится четкая идея зачем это нужно, то какой-то "спейсрутер" можно наверняка прикрутить
Сами себя переписывают при изменении функционала?
Зачем это дорогостоящая во всех смысла лишня latency на спутнике? Какую задачу должно решить?
Какая максимальня теоритическака пропускная способность (совакупная Bandwidth по всем возможным каналам) получается у такого спутника?
П.С. С Большими свичами и рутороми и на земле пробелемы технические есть.
Вполне.
Но многим ли предприятиям это надо в век клауда?
Этот ваш "я как-то продал" и есть фактически определяющая штука микросервисной архитектуры. Независимые release/deployment цыклы сервисов. Это то чем микросервисный подход отличаются от модульного монолита например.
Ну в таком сценарии надо ставить, да. Идея хорошая если истио так и так стоит. У нас пока нет меш-подобных.
Вы как пользуетесь если не секрет? Какие задачи мешом решаете? не ради логгинга же?
хм…
Тогда единственное что мне не нравится в этом подходе это то что сервис должен знать о логстеш и даже его адрес.
Что проистходит если логстеш временно недоступен?
Так себе достижение, смотрите реальные (на сколько могли посчитали) себестоимость в Европе по источникам:
Атом(2015) 3,6–8,4 евроцента
Фотовольтаика (2018) 3,71–8,46
P.S. Только в немецком варианте, но просто:
https://de.wikipedia.org/wiki/Stromgestehungskosten
*Kernenergie — атом
Photovoltaik Kleinanlage (DE) — фотовольтаика малого типа (видимо на частных домах в германии)
Photovoltaik Großkraftwerk — фотовольтаика, большая
Ну camunda это когда-то форк от jBMPM, который нормально допили во всех аспектах (за последними набурками уже давно не слежу).
Он был изначально девелоперфрендли и запустить его можно хоть в спринге (отвязали от jboss давно, когда я ещё консалтил).
Дописали куцу тулов, красивых едиторов и таскменеджеров, платных и бесплатных. От комьюнити тоже были.
А главное эти ребята консалтят и уже как лет 10 имеют полный цыкл, внедряют (пеимущёственно в немецкие) фирмы всех размеров и опыт отдают назад в код.
Прогресс не сотоит на месте, они накппив опыты решили сделать даже горизонтально распределяемую альтернативу камунде,
https://zeebe.io/.
но мне не довелось попробовать...
и верифицированные блог аппендится "в конец" цепочки…
что не так?
Спасибо, вы раскрыли то на что я намекнул
Но мой камент не об этом.
Намучались? ;)
Так и есть. И это аргумент против этой ерунды с обфускацией или переносом портов (если перенос порта не решает другой проблемы)
Лучше не создавать илюзии безопасности и не говорить о ней а честно оценивать риски. Если шеф говорит пока нет риска и вы говорите "у нас нет никакой безопасности" это понятно и открыто. И ситуация может заставить вас занятся "нормальной" безопасностью. Ежели вы начинаете коммуникацию типа ну это не надежно но у нас уже есть "обфускация", то ваша организация особенно далекие от темы люди могут решить, что кое какие меры таки приняты и ваша задница кое-как да прикрыта (Но это не так!), тем самым откладывая настояще выделение ресурсов на решение проблемы… Я лично сталкивался с этом и думаю в этом основной АНТИПЭТТЕРН или покрайней мере не малый его аспект.
Спасибо.
Я вот тоже подошел вплотную к Аксон. Но это скорее сайд проджект пока. Ходил пока только вокруг да почитывал.
Выглядит у них все очень интересно и Event Sourcing и CQRS продуманы и осознанны — мне так верится из их сторитейлинга покрайней мере.
А также их сервер осознаное и правильное решение. Но! он ещё достаточно свеж, комьюнити не большое (но может и сильное! знаю пару людей от туда).
И если у меня нет претензий к фреймворку у меня есть некая настороженость к лицензионной моделеи сервера. Не люблю я, когда кластеринг за деньги (а деньги там большие).
Как вы смотрите на этот вопрос? Будет интересно узнать.
Ещё как я понял фреймворк имплицитно создает схему эвентов. Мне бы хотелось эйксплицитно (например как-то с Apache Avro) вы как-то с этим заморачивались?
Тоже было бы интересно...
Я 15 лет в немецком ИТ. Немецкий очень важен! И только последние лет 5 было "прозрение" (особенно в Берлине) что мол хрен сним с немецким. Я сам удивился в какой-то момент. С хедхантерами общаюсь чуть ли не ежденевно.
У меня с немецким все Ок.
В Германии крупные компании все меньше интересуются каким-то Реакт или прочей узкой специализацией…
Да и многие мелкие тоже. К CV инностранцев могут вполне настороженно относитя лиш потому что, что-то по не ожданному шаблону.
Немцам опыт в других непонятных им странах мало что говорит.