Комментарии 4
По поводу AWS, если кратко, используйте только те облачные сервисы, с которых легко перейти в другое облако. Мир меняется, кто знает, что будет дальше. Не привязывайтесь к одному облаку. Проверено на практике.
Тут я с вами не соглашусь, так как у меня довольно большой опыт работы с другими облачными провайдерами, а именно: Digital Ocean, GCP, Yandex Cloud. Какие-то недостатки есть у каждого, но и плюсы свои тоже есть. Например, Digital Ocean предлагает очень понятную ценовую политику. А Яндекс просто дешевле.
На мой взгляд, AWS реально очень выгодно использовать, если:
решение уже зрелое, понятна текущая потребность в ресурсах, а так же прогноз на ближайшие 1-3 года, тогда предоплаченные планы делают AWS самым дешевым решением из всех
есть потребность в специальных инструментах, например, AWS Athena или что-то подобное, чего нет у конкуретнов / работает хуже
небольшие стартапы, тогда AWS Free Tier может немного сэкономить денег
Тут, насколько я понимаю, речь идет не о достоинствах или недостатках конкретного облачного провайдера. А о том, что этот самый провайдер может в какой-то момент заблокировать или вообще удалить Вашу инфраструктуру по каким-то своим соображениям.
Лично я бы даже используя AWS использовал бы Terraform для развертывания инфрастурктуры. CloudFormation и AWS CDK поянтное дело предоставляют больше возможностей. Но с Terraform будет гораздо проще перейти куда-то еще. Плюс Terrafrom позволяет не только с облаками работаеть, но и с сервисом логов Sumo Logic, к примеру, или Grafana.
За статью - спасибо! Познавательно
Спасибо, я не совсем так вопрос понял.
Действительно, при разработке решений я стараюсь не привязываться к конкретному облачному провайдеру, более того, желательно иметь возможность запустить все решение в тестовой / демо версии на обычном голом железе без каких-либо технологий со стороны облачного провайдера, используя только open-source решения. В идеале, чтобы можно было все запустить из обычного docker compose.
Например:
Lambda могут быть завернуты в свои docker контейнеры с разными триггерами ( cron, sqs consumer, http server и т д) -- фактически получается имитация лямбды функции
SQS можно заменить на ElasticMQ
S3 можно заменить на minio
Вместо Congnito можно использовать Keycloak
и т.д.
Localstack при этом я не использую, чтобы точно отмежеваться от AWS.
Это добавляет больше работы, вопросов с тестированием и т.д., но есть 2 больших плюса:
легко разрабатывать локально
нет зависимости от облачного провайдера
Далее в существующий код уже добавляется обвязка для конкретных сервисов, например, реальные Lambda с триггерами по http и т.д.
В результате решение может быть перенесено на любую платформу.
Касательно, Terraform. В целом согласен, как мне кажется, было бы хорошо, чтобы остался только Terraform как стандарт. Но я думаю, что для этого еще надо несколько лет. AWS CDK более зрелое решение, уже вторая версия, пусть и только под AWS. Terrafrom еще только 0.19.0. Хотя возможно, что все будет так как и с react-native, где релизной версии полноценной нет, но cотни тысяч приложений уже разработаны и давно хорошо работают.
Освоение AWS CDK: настройка пользовательского домена для вашего HTTP-шлюза