Не, шляпы я не продаю - я по другой части.
На самом деле в основе там всё просто, как эта самая шляпа.
Дъявол в деталях, как всегда.Хорошо, пройдём по шагам. Пусть их будет четыре.
1) Что обозначает модное "cloud-native" на практике?
Это означает, что все (или большая часть) функций приложения распилена на микросервисы, которые общаются друг с дружкой по заранее оговоренному API.
Там ещё много всякого, но это вот основная черта таких приложений.
2) Что это нам даёт?
Это нам даёт две вещи:
а) головную боль, потому удержать в голове всю лапшу взаимодействий становится сложнее. Это рекламная неправда, что идёт упрощение приложения. Где-то упрощается, а где-то понимать становится сложнее.
б) Возможность динамически распределять функции приложения по значительному количеству узлов используя возможности оркестратора
3) На практике это означает важную штуку, что настроив планирование приоритетов и правила масштабирования оркестратора мы будем платить только за те возможности облака, которые реально требуются в данный момент. Ненужные рабочие узлы будут исчезать, а в случае роста нагрузки они будут появляться.
4) Строго говоря, мы можем написать вот это вот самое облачное приложение не для контейнеров, а для виртуалок, и даже просто железных машинок.
Если с такими псевдоподами нам позволяет работать оркестратор.
Но при этом подходе возникает такая штука, как "крупная гранулярность".
В переводе с рекламного на русский это значит, что нарезать нагрузку оркестратор станет гораздо большими кусками, чем в случае с контейнерами.
Что влечёт за собой то обстоятельство, что много ресурсов начнёт уходить в обрезки.
То есть платить за эти ресурсы придётся - но вот работать они толком не будут.
А недоутилизированные оплаченные мощности - это крайне скучная история.
