Комментарии 3
Вот вы говорите, что Java не заточен работать в облаках.
А какой язык или среда разработке заточена под облака? Go?
Любой язык без JIT-а хотя бы библиотек (уже скомпилированы до машиных кодов), а лучше без JIT-а совсем. Но!
Как часто требуется сервис, время старта и разогрева которого сопоставимо с временем его жизни? Типа старых CGI-программ, которые стартовали и работали ровно на один http-запрос. Как мне кажется, сейчас такое используется гораздо, гораздо реже. Кроме того, есть же всякие мелкие и шустрые JDK для крайних случаев.
Ну к примеру, начнем с
Для этого нужно всего лишь вложить размещаемый сервис в Docker-контейнер, завести под Kubernetes, и все прекрасно заработает.
К примеру возьмем Azure AKS либо AWS EKS. Если не нравится, давайте ваш вариантю. Мы платим за (fixme):
кластер сам по себе поштучно за час
за виртуалки и их размер, также поштучно и за "квант" времени (лениво вспоминать, сикоко там)
за диски
Теперь вопрос, на который у меня нет ответа
Если нам нужно развернуть один экземпляр низконагруженного сервиса – вроде ничего страшного и особо дорогого, но если нам необходимо постоянно разворачивать и тушить сервисы, балансируя нагрузку – уже дороговато. Если же наш сервис должен сразу давать быстрый отклик, и это критично для бизнеса, то нас ждет полный провал.
Зачем постоянно разворачивать/тушить сервисы, они же pods (если я вас правильно понял). Это не влияет на стоимость до тех пор пока вам не на добавить одну ноду, ну либо убрать. Запуск виртуалки же - это не секунды, поэтому это надо делать чуток заранее, ну либо прописать критерии чуток с запасом.
Заниматься "тонким" тюнингом и балансировкой внутри кластера - а зачем? Не, ну можно ... просто это ничего, кроме "гемороя" и нагрузки на сам кластер не добавит. Т.е. понятно, autoscaling нужен, но прям такой супер реактивный - а зачем?
Но возможно я туплю и не могу понять
Java в облаках