Третя частина «» Історії одного стартапу «» затримується через раптові події свят (хто не читав - тут початок), ось вам поки набір шкідливих порад. З "Історією"... "вони ніяк не пов'язані, просто спостереження за різними проектами в яких довелося взяти участь мені, або моїм колегам.
Порада № 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 не виживає жоден стартап.
Ну і діліться своїми шкідливими порадами в коментарях, чи що...
