Какие конфигурации серверов вы используете в своих проектах? Стоит ли полагаться на Amazon Web Services для всего: EC2, S3, RDS и Cloudfront? Или лучше использовать отдельные сервисы, например, только S3 от Amazon, Discourse на Digital Ocean и, возможно, Fastly в качестве CDN?
Мне бы хотелось узнать, как вы управляете этим форумом, а также другими существующими сообществами, чтобы понять, что следует делать.
Заранее спасибо всем!
Это действительно зависит от ваших целей и требований.
Запуск всего на $5 droplet отлично подходит и достаточно для большинства любительских сообществ. Существуют очень крупные сайты Discourse, работающие на одном сервере, просто масштабируясь вертикально по мере необходимости.
Корпоративные и бизнес-сайты могут выбрать более сложную конфигурацию с использованием публичных облачных сервисов для достижения строгого SLA или передать хостинг профессиональному провайдеру, например, Discourse pricing | Discourse - Civilized Discussion
Для своего сайта я использую DO-сервер за $20, перед ним стоит Cloudflare, а на бэкенде — хранилище S3. Согласно данным Google Analytics, на моём сайте в общей сложности около 400 тысяч публикаций, а среднее количество сессий в день составляет примерно 10 тысяч.
Я новичок в этом сообществе, но у меня есть опыт веб-разработки. Однако я человек, который любит делать всё качественно и управлять процессами наилучшим образом. Я мыслю масштабно! И мне кажется, что идея раздельного управления базой данных и загрузками действительно хороша. Но мне трудно решить, стоит ли управлять всем с помощью продуктов AWS. Например, проблема привязки к вендору (Vendor Lock-In). Очевидно, что если использовать EC2 со стандартным дистрибутивом Linux, например Ubuntu, и RDS для базы данных PostgreSQL, то проблем нет. Но с S3 или при использовании других стандартов и функций вендора, таких как Lambda, это может стать проблемой при миграции на любой другой хостинг.
Есть и другие поддерживаемые провайдеры S3: Использование объектного хранилища для загрузки файлов (S3 и аналоги).
Исходя из того, что вы сказали, я рекомендую начать с одного экземпляра EC2, чтобы разобраться во всех деталях. Если позже вы захотите перейти на RDS (и ElastiCache) и S3, вы сможете сделать это по мере роста ваших потребностей и в соответствии с бюджетом.
Последний вопрос. Для использования S3 нужен CDN, верно? Но использовать ли тот же CDN, что и для сайта, или следует настроить отдельный CDN специально для данных, загружаемых в S3?
Позже. У CDN сайта и CDN S3 разные «Источники».
Например, Fastly для форума и Amazon CloudFront для S3. Я прав?
Я бы использовал для обоих случаев либо Cloudfront, либо Fastly. Использование нескольких провайдеров для одного и того же продукта в рамках одного экземпляра кажется излишне сложным.
Когда мы говорим «другой CDN», мы имеем в виду другую «распространённую CDN» или «экземпляр CDN». Не буквально другую компанию CDN.
О, хорошо, спасибо за объяснение.
Я не полагаюсь на Amazon ни в чём.
Я никогда не стану использовать решение, которое не считается стандартом и поэтому не может быть легко перенесено в другое место.
Традиционный виртуальный сервер отлично справляется с задачей. Если захочу, я смогу легко сменить провайдера в будущем.
Какие альтернативы EC2, S3, RDS и ElastiCache вы бы порекомендовали? Имеются в виду стандартные решения, чтобы избежать, как вы говорите, проблемы привязки к вендору (Vendor Lock-In).
Например, Linode или DigitalOcean?
Я управлял веб-приложениями на всех трёх платформах (AWS, Linode и Digital Ocean). Я предпочитаю Linode и DO. Они оказались недорогими, очень надёжными и, что самое главное, проще в управлении. Я был единственным техническим специалистом в крошечной компании, поэтому для меня эти факторы имели решающее значение.
Перенести Discourse на другую платформу действительно несложно: даже если вы используете все инструменты AWS, можно создать резервную копию и восстановить её на любой установке Discourse.
DO и Linode (наряду с сотнями аналогичных по цене конкурирующих облачных провайдеров) значительно более экономичны (по моему опыту, примерно в 10 раз дешевле), чем AWS или MS Azure, при сопоставимых услугах, и гораздо реже требуют построения решений на основе их проприетарных API и интерфейсов, что затрудняет переход к другому провайдеру хостинга общего назначения. Я настоятельно рекомендую оставаться независимым от вендоров и избегать AWS и MS Azure.