Как построить правильную архитектуру на AWS для веб-приложений?
Привет. Serverless-нора оказалась очень глубока, 200+ сервисов амазона сбивают с толку.
Цель: задеплоить приложение на AWS, написанное на Vue3 (плюс нативный SSR, либо nuxt), выполнять "бекенд" функции в Lambda и в качестве базы данных использовать также один из сервисов амазона. При этом хочется иметь адекватный CI/CD.
Варианты, обнаруженные мной:
S3, CloudFront. Изи, все туториалы и схемы говорят об этом. Залил свой билд, всё работает. Однако, после каждого коммита делать ручную работу по деплою не хочется. Здесь приходят на помощь либо сервисы амазона по доставке кода, либо AWS Amplify. Но стоит ли его использовать?
Так же есть опции с EC2, AWS VPC, тысячи их.
Как найти лучшее решение из всего? Повторюсь, нужно просто собирать фронт, который использует SSR, а этот фронт, в свою очередь, будет работать с другими сервисами амазона. Хочется делать это быстро, безопасно и недорого (по возможности). Сейчас глаза разбегаются, в каком направлении вообще смотреть, куча материала, куча сервисов, куча мнений и столько же абсолютно неочевиднейших моментов.
Для теста хочу сделать serverless SSR версию блога, который посещают 5 человек в месяц (хаха), особой нагрузки не будет, но опыт интересный. Блог будет рендериться на сервере, данные хочется получать с использованием API Gateway, Lambda и DocumentDB.
Буду благодарен за любую помощь, тема очень интересная.
Иван Шумов
@inoise Куратор тега Amazon Web Services
Если коротко то SSR на serverless делается не так как мы привыкли. ВООБЩЕ не так. Что до адекватного cicd то тут есть разные опции. Amplify это вполне нормально, но если ставить автоматизацию то вылезает очень много подводных камней. Так что могу предложить тебе двигаться последовательно в твоих изысканиях. Постучись ко мне лично, я через многие боли уже проходил и делал подобные проекты
Забавно, когда то так же загорелся облаками, в итоге спустя год большая часть проектов крутится на VPS от DO с их некоторыми фичами и CI/CD от bitbucket.
Ivan Yakushenko, да, у меня сейчас на DO вертится блог, по большому счету нет проблем, залил/забыл, раннер от гитхаба крутится, по коммиту всё пересобирает, ценник фиксированный - для бложека без гостей идеально и самое оно.
Но в облака полез, потому что хочется освоить что-то новое и всё это выглядит довольно удобным, особенно в вопросах масштабирования и скорости загрузки и прочее-прочее.
Расскажи, почему ты загорелся и почему оставил эту идею?
У меня лично парадоксальное чувство одновременного недостатка и переизбытка информации, от которого закипает мозг
Расскажи, почему ты загорелся и почему оставил эту идею?
Мотивация была прям 1 в 1 как у тебя, но и по работе нужно было немного освоиться в облаках. Но стеной стало осознание того, что чем дальше лезу - тем больше нужно. В итоге для каких-то мелко-средних задач облака всё только усложняют, залить на обычный vps и прикрутить вообще любой cd гораздо проще и быстрее, а для крупных проектов нужно четкое понимание что и как использовать, к сожалению в моем случае мне не хватило мотивации продолжать всё это изучать, так как я разработчик и мне это не особо то и нужно. Хотя да, есть задачи, которые ну прям нереально идеально решаются теми же функциями.
Добавлю еще что в облаках есть опасность влететь на деньги если недочитал документацию по автомасштабирующимся сервисам - есть много историй как недоглядели и влетели на лишние 100 - 100.000$
На это можно посмотреть с двух точек зрения - практической и учебной. Если цель научиться чему-то новому, то начинайте потихоньку. Я бы начал в frontend, его проще задеплоить в S3, чем изучать serverless. Заработает - добавить Cloudfront. Заработает - добавить CI/CD, проще всего на основе GitHub.
Спасибо! Даже не ожидал такого позитивного фидбека на такой, казалось бы, тупой вопрос. Аж приятно)
S3 + Cloudfront для SPA дался относительно легко, на в первый день удалось залить и заставить работать.
Тут дело в том, что количество инструментов огромное, плюс куча сторонних фреймворков - хрен его знает, что лучше использовать в той или иной ситуации, одну задачу можно решить множеством подходом, а без знания, как правильно, это заведомо будет неоптимальное решение.
Андрей,
Да, с 200 сервисами амазона легко потеряться. Мой совет как практика - идите от своих знаний-потребностей. Нет единственного правильного пути.
Насчет бэкенда - выбирайте из моего списка, составлен в порядке "от классики - к модному". Если цель научиться, то попробуйте все. Если цель - запустить свою апликацию чтобы стабильно работала - советую EC2 или Beanstalk.
- EC2 (== VPS)
- Beanstalk
- Docker on EC2 or Fargate
- Kubernetes - managed or unmanaged, on EC2 or Fargate
- Serverless
Vitaly Karasik, благодарю, но интересует как раз последний, самый "модный" шаг)
Т.к. архитектура на VPS в целом ясна и ничего нового я для себя не открою, просто новый инструмент для того, что уже делал. Хотя я понимаю, что AWS позволяет сделать и это гораздо удобнее
Андрей,
Тогда пробуйте. :-)
Server side - Lambda + API Gateway
Database - depends. DocumentDB (noSQL, even in practice it's on top of Postgres) or Aurora RDS (MySQL | Postgres)
Средний
Простой
