кубер все-таки больше про инфраструктуру, а акка это про бэкенд и рама походу тоже
актор это не сервис
https://doc.akka.io/libraries/akka-core/current/typed/actors.html
Точно также и Рама это больше про построение систем, а не про программирование с акторами. Таким образом, код на Rama даже не линейный, а в форме графика, и функция может возвращать потенциально бесконечное количество значений.
Существуют бэкэнды на Elixir/Erlang (девять девяток аптайма — гордость OTP). Они используют акторную модель, которая вшита в виртуальную машину BEAM (в отличие от JVM). Тем не менее, бэкенды на них пишутся также склеивая разные технологии не предназначенные для совместной работы, у каждой из которых свой собственный особенный ❄️ способ хранения данных (реляционный, документный, графовый, time-series, column-oriented и т.п.), под которых нужно адаптировать бизнес-логику. Это вызывает проблемы. Нужно денормализовывать базы данных, а это боль. Нужно создавать ad-hoc кэши через Редис, Мемкэш и прочее и прочее, а они ad-hoc именно потому что это целые отдельные сервисы, созданные просто чтобы имитировать мапку или слайс.
Таким образом, акторная модель, а следовательно и Акка, не преодолевает те проблемы, которые преодолевает Rama. А преодолеть их легко — создавай БД под нужды бизнеса, а не адаптируй нужды бизнеса под столбцы или строки из БД. Универсальные БД с любой схемой, реляционные, документные, графовые, а может и реляционно-графовые с кусочком документового хранилища, любые вообще модели БД можно создавать на лету в Rama с несколькими строками, контролировать собственноручно что именно в БД индексируется и т.п. Это называется PState (Partitioned state, партиционированное состояние), и PState может иметь любую модель данных