Третья часть "Истории одного стартапа" задерживается из-за внезапно случившихся праздников (кто не читал — здесь начало), вот вам пока набор вредных советов. С "Историей ..." они никак не связаны, просто наблюдения за разными проектами в которых довелось поучавствовать мне, или моим коллегам.
Совет №1. Берите вычислительных мощностей с запасом. Ведь ваше приложение — это прорыв в индустрии, и количество посетителей будет зашкаливать через два часа после релиза на Google Market / App Store. Берите сервер под рекламный сайт и сервер под контроллер Ansible, а также следуйте рекомендациям производителей программного обеспечения о том, что деплой на меньше, чем три сервера — это не продакшн-уровень.
Совет №2. Пользуйтесь как можно большим количеством SaaS. Желательно — с отсутствием простого механизма переезда с этого SaaS на собственный . Идеально — решение должно быть платным с некоторым ознакомительным периодом, после которого отключается большая часть функционала. Ведь приложение "уже-почти-вот-вот-готово", размещение в Google Market / App Store занимает пару часов, а потом вы сразу заработаете столько денег, что хватит на оплату всех аккаунтов, и на пиво останется.
Совет №3. Пользуйтесь облачными вычислительными мощностями. Ведь когда у вас приложение в облаке — вам не нужен ни архитектор, ни DevOps, в облаке приложение будет само масштабироваться, что уменьшит ваши эксплуатационные расходы.
Совет №4. Когда выяснится, что не так всё просто с облаками — выдайте программистам задачу спроектировать архитектуру приложения с учётом масштабирования, и автоматизировать развёртывание. Не слушайте их робкие намёки на то, что было бы неплохо взять в команду хоть какого-нибудь админа — у вас же всё в облаке, там сервера сами знают, когда нужно стартануть, когда остановиться, и где хранятся данные вашего приложения. А если не знают — есть Ansible, для использования которого вообще не нужно знать о том, что такое "системное администрирование". Знай, конфиги на YAML шлёпай.
Совет №5. Сделайте неотключаемый мониторинг исключений в коде. Ведь вам всегда будет очень важно знать, сколько именно push-сообщений не было доставлено за период "в этот день, час, минуту и секунду два года назад". Данные складывайте в облачный SaaS сервис со своим API — ведь хранить такой объём в обычных файлах это прошлый век и дорого.
Совет №6. Никогда не реализуйте мониторинг на уровне операционной системы. Ведь если перестанет работать приложение — вы это и так увидите (оно ведь запущено у вас на телефоне / во вкладке браузера 24 часа в сутки), а графики загрузки процессора и использования памяти можно посмотреть в веб-интерфейсе управления вашим облаком.
Совет №7. Когда кто-то из команды аккуратно намекнёт на ненужность 60% телодвижений уже сделаных в проекте, и что "может ну его, давайте для начала поселимся на виртуалке пожирней" — отмахнитесь, а то и перестаньте работать с человеком, ибо он некомпетентен. Помните, без High Availability, Big Data и Scalability не выживает ни один стартап.
Ну и делитесь своими вредными советами в комментариях, что-ли...
Автор: br0ziliy
