Ну, вот нам надо шарить подключения к PostgreSQL, Aerospike, Redis, RabbitMQ. На каждую функцию, что их использует, делать по подключению? Выносить в общие функции и составлять цепочки?

только там все НАСТОЛЬКО плохо, что они даже отключили мусоросборщик в питоне

Стек выбран произвольно, названия сервисов можно поменять. Поинт в том, что нам часто требуется 3+ источников данных и/или кэшей.

ну вообще, идея микросервисов в том, что базы данных наружу не торчат, а торчат API

а у каждого микросервиса своё хранилище, закрытое от других и предоставляющее API для доступа к нему

Верно, но один микросервис это не одна функция

идея да, реальность нам говорит что все не так)

Да пофиг на реальность. Даже у одного микросервиса, даже с одной БД и всего с одним эндпоинтом. как нам шарить коннекшны между запросами, если serverless убивается?

Открытие коннекции к БД это недёшево

Микросервисы overrated

FaaS выглядит круто и интересно, но я вот слабо представляю себе реальные проекты на них с приличной нагрузкой. А уж считать их стоимость...

ну, если мы запаковываем каждый метод API в свой собственный образ контейнера и вот у нас 1 API микросервиса, фасадик, запрос потом дальше ешё к этим контейнерам (ну, сколько у нас их, штук 10-20, по сути 1 метод-функция на 1 образ контейнера), а они уже лезут в хранилище, общее для микросервиса, вот эти 10-20 контейнеров у них у каждого своё подключение, а количество запросов, которое обрабатывается 1 и тем же контейнером, ими можно регулировать, направляя больше или меньше, в случае с Google Cloud Run'ом там от 1 до 80, ну, я писал выше

Честно говоря, не вижу ответа на свой вопрос. Коннекция шарится или каждый раз создаётся заново?

Между реквестами именно

Функция отработала -> реквест завершён -> контейнер тушится
Вроде такая логика в FaaS

если запрос на 1 и тот же метод API (GET /some/collection) и у нас контейнер запускается с возможностью обрабатывать больше 1 запроса, то да

ну по сути это Django/что угодно (любой WSGI/ASGI-фреймворк) с 1 view

внутри контейнера

ЧТо значит "возможность обрабатывать больше 1 запроса"? Я про последовательные запросы только говорил.
Например, так:

for i in range(100): 
  requests.GET("/some/collection")
  time.sleep(1)

Мы 100 раз открываем заново коннект в БД

то есть есть какой-нибудь микросервис может быть таким:
API Gateway (в виде nginx'а) микросервиса (собирает всякие метрики, проверяет JWT на право доступа к методу API),
за ним вот эти 10-20 контейнеров, в каждом по своему Flask'у c обработкой 1 метода API,
на всех 1 общее хранилище