MS має значний вплив на Canonical і є одним з основних контрибюторів. Але не з чисто альтруїстичною метою, а тому що Ubuntu це базовий лінукс для віртуалок Azure (аналогічно як AL2, який по факту є RedHat, в амазона)

Відкрийте хтось вікно, стало душно. DIY проекти роблять не для того, щоб перевершити масс маркет.

Цікавий проект, лайк за оупенсорс. Питання не заради холівару: чому вибрали саме Atmel MCU? Я тільки починаю в embeded як хоббі, і за пару місяців, щоб визначитись з чим було б цікаво працювати, встиг покрутити Atmel (Atmega328 в подобі ардуіни, attiny13/45), STM(8/32), ESP(8266, 32). Чисто на мою субєктивну думку STM8/STM32 цікавіші і суттєво дешевші за Attiny/Atmega, при чому не лише з порівняння перферії, а і значно комфортніші в розробці (з HAL і програмувати простіше, і код читабельніший), а відладка через SWD в реальному часі з брейкпоінтами одне задоволення (ніяких більше Serial.print чи gdbStub). Ну і форм-фактор чіпа SSOP суттєво менший за SOIC (хоча це може бути і проблемою, паяти ноги 0.65мм хоч і не просто, але під лінзою і з нормальним флюсом можливо). Наприклад, MCU STM32G030 купив 5 штук на півтора долара (зрозуміло, що це китайський клон, але воно працює), там і RTC на борту (до того ж, з можливістю резервного живлення по окремому піну), і споживання в standby настільки незначне, що його не міряє китайський мультиметр.

Не знаю про який саме бардак ви кажете, наведіть конкретні приклади. Бо коли ви кажете «одній тімі треба оптимізувати перфоменс, а іншій чимпошвидше релізнути новий функціонал, незважаючи на створення технічного боргу і потенційних проблем», то не зрозуміло на якому рівні будуть проблеми. Я собі уявляю що дві команди працюють в окремих гіт-гілках і роблять мерджі в головну гілку, коли їм треба. Чому раптом виникають проблеми?

Наприклад, дзвонить Джон Сміт з Legal-відділу і каже, що один з ключових клієнтів занепокоєний, що в модулі Х, який використовує лібу Y версії 1.2.3 у якій виявлено критичний CVE і потрібно терміново фіксити, а щоб пофіксити потірбно оновити лібу до 1.4.0, але 1.4.0 не підтримується у вашій версії платформи/компілятора/фреймворка і вам потрібно апдейтити платформ/компілятор/фреймворк, що, безумовно, заафектить не лише модулі в межах овнершіпа вашої команди, а усю монолітну аппку загалом. А Джесіка Купер з маркетингу панікує, що конкурент анонсував нову фічу і в сусідньої команди приоритет 0 зробити фічу у відповідь у короткий термін і апдейт платформи (навіть якщо це нічого не поламає, як мінімум, потрібно перететстувати весь функціонал) явно не входить в їхні плани. Ось і конфлікт інтересів кількох команд.

Ось це вже справді суттєвий плюс на користь мікросервісів, погоджуюсь. Але на скільки часто таке буває?

Якщо це проект не на першому-другому році життя, а вже почали депрекейтитись його залежності — це прямо коммон кейс.

Ну якщо саме апка гальмує, то ресурси для локалізації, який мікросервіс винен в цьому, також потрібні.

На порядок менше ресурсу потрібно. Як мінімум видно спайки в моніторингу конкретних мікросервісів. Навіть якщо в моноліті є і працює APM це не завжди панацея, бо це удже відносні метрики. А якщо, наприклад, апка починає текти памяттю і вбивається OOM Killer’ом без адекватного кор дампу і стек трейсів — веселі години на інцедент менеджмент мітингу з десятком коман, де всі показують пальцем одні на других.

Думаю що ви це говорите в теорії, а не зі своєї практики.

Саме з досвіду експлуатації як монолітів, так і мікросервісів, яким 5+ років і вони досі в стані активної розробки. Так от траблшутінг мікросервісів значно простіший (принаймі в пошуку овнера баги)

Тобто навпаки розібратись в моноліті значно легше, ніж у мікросервісах, якщо брати аналогічний функціонал і там, і там. Це якщо говорите за весь проект загалом. Якщо говорити про окремий мікросервіс, то окремий модуль в моноліті точно не буде складніший, бо перевага модульного моноліту якраз в тому, що окремі модулі можуть бути на стільки автономними, що їм не треба знати що робиться в інших модулях.

Чим саме легше розібратись в модулі, чим в мікросервісі? Модуль в межах моноліту не є атомарним і, як мінімум, має shared-частину, яку не можна чіпати, бо це афектить інших, і це не завжди очевидно для нових колег. А весь проект знати середньостатистичному мідлу і не потрібно для того, щоб почати перформити в межах свого скоупу

1. Якщо нема конкретного овнершіпа конкретного репозиторію (а якщо кілька команд комітять в одне репо то саме так і буде) — завжди буде бардак і кожен буде тягнутиме ковдру на себе з часто взаємовиключними цілями (бо одній тімі треба оптимізувати перфоменс, а іншій чимпошвидше релізнути новий функціонал, незважаючи на створення технічного боргу і потенційних проблем). Також неясно що робити з edge cases, коли проблема виникає не через конкретний модуль/команду, але афектить аппку загалом — ресурси на «пошук крайнього» і зайва комунікація.
2. Реліз процес, який вимагає погодження не лише від ПМ/ПО, а організаційно на рівень вище зажди буде гальмувати делівері фіч всім командам.
3. Один пакетний менеджер на весь продукт — через кілька років девелопменту виявиться, що певний легасі модуль хоче бібліотеку 1.x.x , а команда почала девелопити новий модуль і хоче 2.х.х, який ламає легасі модуль — або витрачаєте час на рефакторінг легасі (який і так працює і рефакторінг не має жодного бізнес велю), або розробка нового компоненту починається на застарілому стеку.
4. Раптово в продакшені починають зявлятись проблеми з перфоменсом або непередбачувані падіння апки — додаткові ресурси на локалізацію проблемного модуля.
5. Час онбордінгу нового колеги в девелопмент моноліта завжди буде більшим, чим онбордінг в простіший мікросервіс

При том что сервера сами по себе стоят уже достаточно дешево

Сервери самі по собі не несуть жодної користі хай вони хоч і безкоштовні будуть. Так само, як і freeware. А от сервіси на базі freeware, що виконуються на серверах, вже мають цінність. І підтримка цього коштує грошей. І для бізнесу managed-сервіси від клауд-провайдерів обходяться дешевше, чим підтримка in-house командою на своїх чи «дешевих» серверах в ДЦ.

Где открытое ПО для облачных решений?

Всюди.

В будь-якого телекома клауди — це лише білінг і метадані, а 95% сервісу — це комутатори (які, якщо їх хакнули чи флашнули конфігурацію, можна переконфігуровувати лише з фізичною присутністю)

Ні не скажуть. Якщо маєш Computer sience/engineering диплом навіть українського провінційного вузу — для багатьох кастомерів це сильно збільшує твої шанси відносно тих, хто його не має.

Якщо працювати на українську галеру чи клієнта то так, але якщо піти на інтерв’ю до кастомера з старої Європи чи США, то 95% з них запитають про освіту.

Якщо вимоги до reliability близькі до нуля, тоді і клауд-рішень не треба, за ціною нормальної шавухи можна на місяць взяти віртуалку на хейнері.

Не погоджусь. Якщо порівнювати з ECS, Kubernetes (у вигляді EKS) сам по собі мало придатний для прод-вокрклоаду, і потребує як мінімум:
1. Моніторинг ресурсів кластера і система алертінгу
2. Log-агрегатор типу ELK/EFK
3. Ingress (по-дефолту ніби і є ALB Ingress, але потребує доопрацювання напилком)
4. Маппінг IAM to k8s RBAC.
5. Вже згаданий cert-manager

Саме тому кілька сусідніх команд проекту хостяь сервіси в ECS, який ready to go (де все це або уже реалізовано cloud-native штуками типу CloudWatch, або реалізовується в кілька рядків терраформу через додаткові нативні сервіси), так і кажуть, що нема експертизи в k8s.

Серйозно? 47 баксів коштуватиме для клієнта приблизно одна година роботи одного сенйор-інженера, тому двозначні цифри в monthly bill за хостінг це взагалі останній аргумент для кастомера.

Це хибне судження від спеціаліста, що давно подолав поріг входження в кубер (за собою таке ж помітив, що хочеться кубер зі всіма його плюшками там, де його точно не треба), обєктивно для простих проектів на 3-5 мікросервісів managed-рантайм контейнеризації (типу ECS + Fargate) більш придатне і дешевше в плані operations рішення, чи навіть VM-ки + аутоскейлінг.

А в чому, власне, проблема? Бухгалтери, лікарі і вчителі масово теж працюють як ФОПи (не на державні установи, звісно ж)

Згоден, сенйор — це не той, хто знає, як треба (таких багато), а той, хто знає як НЕ треба, хто має багаж факапів і зроблених з них висновків.

маєте на увазі нюанси через лінуксовий енв?

В основному, танці з бубном навколо ліб, які мають системні залежності (.so файли)

про той pay-as-you-go думав, якщо хайлоад, то там і хайгешефт.

Хайлоад == хайгешефт хіба B2B сегменті, де стейкхолдер продає своєму клієнту одиничні дорогі транзакції. В B2C ж навпаки, дуже багато дешевих транзакцій (конверсія інтернет-магазинів чи подібних ресурсів в приклад), тому інфраструктура може влетіти в копієчку. А тут вже виграє, наприклад, EKS, який коштує практично в ціну EC2 (а за EC2 дешевшого compute-ресурсу нема), але дорогий в обслуговуванні (на відміну від лямбди). Тому, калькуляцію треба робити враховуючи особливості конкретного продукту.

Lambda — для малих проектів. Нюанси з використанням сторонніх бібліотек. Warm-up довго, час респонсу високий. Vendor-locked. Деплоїться швидко і легко, не потребує великої кількості додаткових компонентів та експертизи (Api Gateway + ALB і погнали). Дешево в малому масштабі, дорого при хайлоаді.

Docker — гнучко, універсально, швикдо. Широкий вибір способів запуску (VM з будь-яким дистрибутивом, Kubernetes, ECS/Fargate, ACA і т.п.). Vendor agnostic. Практично завжди потребує додаткових налаштувань середовища виконання (навіть у випадку managed services). Обійдеться дорого при невеликому ворклоаді. Відносно дешево в хайлоаді.

Аналогічно. З моїх спостережень 40% прийшли з девелопмента (Software engineer, на якого скидали задачі по розгортанню інфраструктури і автоматизації SDLC, а з ростом проекту вони почали цим займатись фул-тайм), решта з Infrastructure engineering, які навчились в білди, автоматизацію і т.п.

Девопс інженера не існує

Щось схоже на погляди плоскоземельщиків. Скрам — це теж процес. Як і Quality Assurance. Існування скрам-мастерів і QA-інженерів теж заперечуєте?

Саме тому я і відокремлюю в своїх твердженнях DevOps і DevOps engineer. Як і QA — це теж про підхід, а QA engineer — це фахівець, який цим займається.