Я помню я начинал в 2005 с .Net 1.1
Это была достаточно серьезная боль, которая закончилась с появлением версии фреймворка 3.0 (третья революция в .Net, как я считаю… Где первая — это сам .Net, вторая — это ThreadPool+AsyncProgrammingModel+Generics версии 2.0, а четвертая — .Net core).
Но даже тогда асинхроность была ибо это принцип многозадачности операционных систем.
Поэтому не могу разделить патетики.
Писать на Линукс — основная ли это цель платформы? Не уверен.
Но то что .Net core решила проблему многоплатформенности — это факт.
Но… это практически и все «обезболивающее» :)
P.S. оптимизация garbage collector и оптимизация ресурсов (используемой памяти и быстродействия) с .Net Core имеет слабую связь. Основное было сделано, по-моему, или в 4.6.2 или в 4.7 .Net Framework
Полностью согласен с первой частью комментария.
Что касается «оторванности от реалий» — она неизбежна в любом случае если мы перестанем валидировать окружающий нас контекст (организационный в данном случае — интеграцию с другими командами/организациями).
Связанность команд/организаций контрактами никуда не девается. Сторонние микросервисные команды связаны и сверху (потребителями микросервиса) и снизу (платформой). Платформенная же команда зависит и как от consumers (обратная связь от микросервисных команд) так и от своих стратегических целей.
Риск «появления дармоедов» присущ любому коллективу. Тут, скорее, вопрос культуры в организации и командах. Но необходимость наличия платформенных команд мне кажется очевидной по мере роста сложности тех «меж-командных» concerns, которые проиллюстрированы выше. Особенно, если организация предоставляет свою платформу как продукт на рынок (в том или ином виде). И чем выше прогнозируемая сложность, тем ранее должен быть решен вопрос владения платформой.
Спасибо за Ваш комментарий!
По поводу рисунка. Я хотел просто проиллюстрировать связь между продуктовыми и платформенными командами через определенных представителей, входящих в состав продуктовых комманд. А кто будут эти представители — обсуждаемо и зависит от конкретного контекста :)
Принципиальна сама разница между этим вариантом и вариантом «Платформа как продукт», где непосредственная коммуникация между продуктовыми и платформенной коммандами не предусмотрена, хотя, конечно, может (и должна) существовать опосредованно. Да и тема не исчерпывается только этими двумя вариантами, они приведены для примера.
Спасибо за Ваш комментарий!
Это была достаточно серьезная боль, которая закончилась с появлением версии фреймворка 3.0 (третья революция в .Net, как я считаю… Где первая — это сам .Net, вторая — это ThreadPool+AsyncProgrammingModel+Generics версии 2.0, а четвертая — .Net core).
Но даже тогда асинхроность была ибо это принцип многозадачности операционных систем.
Поэтому не могу разделить патетики.
Писать на Линукс — основная ли это цель платформы? Не уверен.
Но то что .Net core решила проблему многоплатформенности — это факт.
Но… это практически и все «обезболивающее» :)
P.S. оптимизация garbage collector и оптимизация ресурсов (используемой памяти и быстродействия) с .Net Core имеет слабую связь. Основное было сделано, по-моему, или в 4.6.2 или в 4.7 .Net Framework
Что касается «оторванности от реалий» — она неизбежна в любом случае если мы перестанем валидировать окружающий нас контекст (организационный в данном случае — интеграцию с другими командами/организациями).
Связанность команд/организаций контрактами никуда не девается. Сторонние микросервисные команды связаны и сверху (потребителями микросервиса) и снизу (платформой). Платформенная же команда зависит и как от consumers (обратная связь от микросервисных команд) так и от своих стратегических целей.
Спасибо за Ваш комментарий!
Принципиальна сама разница между этим вариантом и вариантом «Платформа как продукт», где непосредственная коммуникация между продуктовыми и платформенной коммандами не предусмотрена, хотя, конечно, может (и должна) существовать опосредованно. Да и тема не исчерпывается только этими двумя вариантами, они приведены для примера.
Спасибо за Ваш комментарий!