Здесь я расскажу вам историю, как хорошо продуманная архитектура, могла погубить весь проект.
Ситуция
Фирме, занимающейся автоматизацией паркингов выпал золотой билет: они разработали концепцию полностью автоматизированного проезда, которой заинтересовались существующие клиенты и большая российская IT-компания.
Еще лучше то, что для этого оказалось достаточно всего одной презентации и общения с существующими клиентами.
Поскольку фирма занималась разработкой систем проезда уже несколько лет и имела свой IT-штат, они решили реализовать архитектуру своими силами и просто привлечь разработчиков для реализации.
Меня они нашли на moikrug.ru и хотели привлечь как руководителя этого проекта и Senior Golang разработчика.
У меня есть опыт, как самостоятельной реализации софта и железа, так и создание своего IoT проекта и опыт руководства отделом разработки в Мегафон IoT.
Но для начала я предложил проверить их архитектуру и ТЗ и только после говорить о каком-либо партнерстве.
Я взял кейс
На первый взгляд все было хорошо. Это был набор сервисов на PHP и Golang, которые был размещен в экосистеме Amazon AWS и хорошенько обвязан их сервисами: транспорт, интерфейсы доступа, аутентификация, нотификации, контейнеры, vpn и прочее.
Это была неплохая верхнеуровневая архитектура, которая использовала лучшее от экосистемы AWS, но я чувствовал, что что-то идет не так…
Проблемы
Тут было несколько очевидных проблем:
- Во-первых, в России AWS часто блокируют. И я говорю не просто про историю с Роскомнадзором, такое просто часто происходит.
- Во-вторых, в России практически нет специалистов, которые умеют готовить AWS, поэтому DevOps и разработчиков, которые смогут на нем что-то правильно развернуть найти сложно
- Российское правительство очень не любит, когда данные о гражданах (особенно их ФИО, номера машин, передвижение и особенно паспортные данные) выходили за пределы российских серверов. AWS серверов в России не имеет.
А это только технические проблемы. Дальше идут уже бизнес-проблемы, которых ни разработчик, ни предприниматель не увидели.
Потеря половины рынка
Фирма предоставляет СКУДы (системы контроля и учета доступа), а я уже занимался продвижения проекта на этом рынке и знал, что большая часть заказчиков требует локальную версию системы. То есть версию, которую можно развернуть полностью у себя на сервере и управлять всеми данными.
И это абсолютно нормальное условие: СКУДы это система безопасности, поэтому такие данные слишком сенситивны.
Если мы полностью завяжемся на AWS, то потеряем добрую долю рынка.
И представьте себе, даже не это основная проблема.
Потеря всего проекта
Когда вы делаете стартап, чаще всего у вас 2 варианта дальнейшего развития:
- Оставить его себе, развивать и масштабировать. Тогда ваша задача — это начать получать с этого проекта прибыль и предыдущая глава сразу же погубила бы проект.
- Продать его другой компании. Такая цель может стоять с самого начала существования проекта. Тогда прибыль может быть не нужна. Вам будут нужны другие метрики, о которых вы договариваетесь с фирмой, которая вас выкупит.
Подробнее это опишу эти пункты в другой статье.
Поэтому я задал логичный вопрос: «А какая у вас стратегия?»
Как я и думал… Оказалось, что стратегия – продать этот стартап другой гигантской российской IT-фирме.
Вот тут самое главное о чем не подумал Заказчик: в жизни крупный представитель российского IT не купит технологию, находящуюся на серверах Amazon.
Мы позвонили менеджеру, который был выделен со стороны данной фирмы, задали вопрос и после консультации с IT-специалистами они подтвердили, что использование Amazon для нас запрещено.
Слава богу
Да, конечно, сделав проект на Amazon и после этого узнав, что его нельзя использовать, можно было бы переписать проект. Но тут несколько «НО»:
- В России нет реально качественных альтернатив сервисам AWS (чего один AWS IoT стоит).
- В Open Source нет реально качественных альтернатив AWS.
- Стоимость и время могли съесть столько бюджета, что конкуренты (а они были) могли нас опередить и продать свое решение раньше.
Что решили делать
Отказываться совсем от облачных технологий не хотелось, поэтому мы решили следующее:
- Будем делать на технологиях, которые не зависят от облака и можно развернуть локально: Docker, Golang, PHP, PostgreSQL, VerneMQ, Graylog, Gitlab, Ansible и подобное.
- Будем использовать MCS (Mail Cloud Solutions) или Яндекс.Облако
По итогу взяли MCS. Я лично развернул весь стэк на сервера, БД и графический процессор. Это было быстро, легко и приятно. Только техническая поддержка очень медленная, поэтому многое приходится делать самому.
Лайфхак по Docker и MCS: дольше всего я не разбирался почему есть доступ внутрь контейнеров, но нет изнутри во вне инфраструктуры MCS (запросы отваливаются по timeout), оказалось, что нужна вот эта настройка MTU. Они даже удалили мной гневный комментарий.
Я перерисовал архитектуру, сделал ТЗ, набрал разработчиков, развернул всю структуру, CI/CD, написал несколько Golang модулей и постил проект в свободное плавание.
Запомните!
Я часто говорю это:
CTO должен в-первую очередь понимать специфику ведения бизнеса, и уже предпринимательским взглядом смотреть на архитектуру.
Даже самый опытный программист может допустить фатальные ошибки, о которых несведущий в технологиях предприниматель даже не сможет догадаться. Это погубило много проектов и чуть не погубило проект моего клиента.
Если вы хотите убедиться, что ваш текущий стек, ТЗ или план реализации не погубит ваш проект в будущем, напишите мне, я проанализирую что у вас есть и подскажу, что с этим делать.