Comments 18
Это какой-то тренировочный проект «собрать продукт без единого гвоздя на сервисах»?
Я не понимаю, чем эта сложная архитектура лучше виртуалки за 5 баксов при такой нагрузке.
Я не понимаю, чем эта сложная архитектура лучше виртуалки за 5 баксов при такой нагрузке.
Это не тренеровочный проект. Мы ориентируемся на масштабируемость и пытаемся не создавать свои велосипеды, а использовать существующие зарекомендовавшие себя решения. Запуск «виртуалки» за $5 может в текущем варианте заменить разве что Heroku. При этом Heroku позволяет нам полностью избежать настройки сервером и сфокусироваться на коде. Даже если мы говорим о такой простой вещи как база данных — работа с сервисом, который за нас делает масштабирование, бэкапы и т.д. — очень удобно. Полагаю что ответ на ваш вопрос — это весь контент статьи.
У heroku есть минус по сравнению с aws elasticbeanstalk, с heroku сложно спрыгнуть, если вам потребуется больше гибкости в настройке инфраструктуры. С EB проще переехать на clouformation, codedeploy, и прочую aws инфраструктуру, т.к. по сути EB — это всего лишь надстройка над этими вещами, а устройство heroku — дело темное.
PS Ну и цена — тоже немаловажный фактор.
PS Ну и цена — тоже немаловажный фактор.
На виртуалке за 5$ есть cron — это ведь как Heroku task scheduler?
И там можно поставить СУБД, даже не только MySQL. Вопрос с бэкапами в 2015-м году, вроде бы, понятно как решать. Кроме того, восстановление из бэкапов — это в любом случае не так легко, т.к. есть отдельные бэкапы на базу и файлы.
Django debug toolbar, известный любому Django-разработчику, решает вопрос с отслеживанием таймлайна запросов к БД.
В качестве журнала ошибок я обычно Sentry использую. Там есть интерфейсы практически для всего (и бэкенд, и фронтенд).
Да, вы избежали настройки сервера, но получили настройку шести сервисов и зависимость от них. Хотелось бы понять, много ли на этом можно выиграть/проиграть.
Масштабирование — это хорошо, но вы считали, сколько будет стоить эта инфраструктура при нормальной нагрузке?
И там можно поставить СУБД, даже не только MySQL. Вопрос с бэкапами в 2015-м году, вроде бы, понятно как решать. Кроме того, восстановление из бэкапов — это в любом случае не так легко, т.к. есть отдельные бэкапы на базу и файлы.
Django debug toolbar, известный любому Django-разработчику, решает вопрос с отслеживанием таймлайна запросов к БД.
В качестве журнала ошибок я обычно Sentry использую. Там есть интерфейсы практически для всего (и бэкенд, и фронтенд).
Да, вы избежали настройки сервера, но получили настройку шести сервисов и зависимость от них. Хотелось бы понять, много ли на этом можно выиграть/проиграть.
Масштабирование — это хорошо, но вы считали, сколько будет стоить эта инфраструктура при нормальной нагрузке?
Я бы не сказал, что тут совсем уж без гвоздей обошлось. Все таки как минимум два приложения крутится. У меня, кстати, была идея собрать какой-нибудь простенький проект исключительно на сервисах AWS (api, lambda, s3, и т.д.). Мне кажется, неплохая идея для статьи :)
молодцы, что разобрались с такой кучей всего
но 10000 визитов за 36 часов — это 4.62 визита в минуту, это как бы не та нагрузка, чтобы задумываться о масштабировании
но 10000 визитов за 36 часов — это 4.62 визита в минуту, это как бы не та нагрузка, чтобы задумываться о масштабировании
Спасибо! 10 000 визитов за 36 часов пришли не равномерно (поэтому не 4.62 в минуту). В любом случае я полностью согласен что это не серьезный уровень нагрузки. В любом случае тогда у нас возникали ситуации, когда 90 человек одновременно пользовались сайтом и поступало довольно много запросов (при этом все равно конкурентность запросов в секунду была не высока).
мы тоже активно пользуемся сторонними сервисами в проекте, но главный принцип, база и код — у себя, не потому что там не секурно и проч, а в первую очередь при возникновении каких либо нештатных ситуаций всегда можно зайти под рутом, грепнуть лог рестартануть демон, большая свобода для конфигурирования и экспериментов.
а все остальное — без проблем, datadoghq.com — для мониторинга серверов, rollbar.com — для мониторинга ошибок, power bi для отчетов и т.п.
а все остальное — без проблем, datadoghq.com — для мониторинга серверов, rollbar.com — для мониторинга ошибок, power bi для отчетов и т.п.
Хороший совет по БД и коду. Спасибо большое за обзор ваших сервисов — смотрю их сейчас. powerbi.microsoft.com — очень интересно — не знал о нем, мы искали подобный ресурс!
подскажите как разработчик убедил вас в этом
«но нанятый front-end разработчик убедил нас реализовывать на React»
Спасибо
«но нанятый front-end разработчик убедил нас реализовывать на React»
Спасибо
Технически front-end Codesign.io можно реализовать на Angular, React, Ember или любом другом фреймворке. Наш интерфейс не настолько сложен, что какие-то подошли бы принципиально лучше других. Выбор был между Angular и React. На тот момент готовилась к выходу новая версия Angular, которая значительно отличается от предыдущей что потенциально вело к тому, что для того, чтобы быть на последней версии фреймфорка нам бы пришлось значительно переделать код. У меня были сомнения касательно community — я считал что она больше у Angular, ибо в тот момент я не был сильно знаком с React. Оказалось что community у React не меньше и растет быстрее. Дальнейшие консультации со знакомыми топовыми front-end разработчиками так же сыграли в пользу React.
Спасибо за статью, я тоже наблюдаю, как всё больше компаний уходит в облака, чтобы не заниматься поддержкой серверов, бэкапов и так далее, а сконцентрироваться только на фичах. Хотя мне это не всегда понятно, т.к. стоимость (в данном случае з/п) установки и интеграции некоторых OpenSource решений вполне сопоставима с годовой стоимостью сервисов. Но с точки зрения индустрии это объяснимо — не всегда есть деньги купить экспертизу или время на выращивание эксперта.
В связи с этим вопрос, Вы, наверняка, делали какие-то вычисления стоимости использования различных сервисов, в зависимости от базы пользователей, не могли бы поделиться с сообществом?
В связи с этим вопрос, Вы, наверняка, делали какие-то вычисления стоимости использования различных сервисов, в зависимости от базы пользователей, не могли бы поделиться с сообществом?
Прекрасный вопрос. Мы исходили из идеологии, что нам нужно создать архитектуру, которая поможет проекту выйти на определенный уровень. Мы не надеялись, что текущая архитектура будет актуальна при 1 млн пользователей, но нам было важно, чтобы текущая архитектура позволила нам без больших проблем обслуживать 50 -100 тыс пользователей. При этом в самом начале стоимость сервисов очень не высока — около 50$ за все (для того чтобы начать). В настоящий момент (почти 4000 пользователей) мы тратим на сервисы около 220$. Сейчас у нас пока нет сторонних денег и нам требуется развиваться очень экономно. Далее когда у нас будет 10000 пользователей у нас так же будут сторонние деньги на то, чтобы платить за более дорогие тарифы и наши расходы на сервисы составят 500$+. При 50 000 пользователях расходы будут чуть менее 1000$. Должен уточнить, что эти суммы не напрямую связаны с количеством пользователей а с нашей платежеспособностью. Если сейчас мы пока не платим за Github и пользуемся моим студенческим аккаунтом аспиранта — далее нам придется за него платить. Если сейчас мы не создаем ряда приложений в heroku для тестирования отдельных фич, а имеем только одно приложение для тестирования всего, то позже мы будем готовы расширить нашу инфраструктуру. В будущем нам нужно будет создать реплики серверов в США и Японии для того, чтобы был хороший пинг вне зависимости от того, где находится пользователь. Важно помнить что не все сервисы напрямую связаны с развертыванием. Сейчас половина денег, которую мы платим за сервисы это Intercom — для общения с пользователями.
Не знаю, насколько это вам поможет, но я прочитал codesign как code-sign, а не как co-design.
Sign up to leave a comment.
Codesign.io – архитектура которая работает