was successfully added to your cart.

Корзина

Почему CTO должен знать больше о бизнесе, чем о технологиях или «не грози IoT, попивая сок у себя в вебе»

Здесь я расскажу вам историю, как хорошо продуманная архитектура, могла погубить весь проект.

Ситуция

Фирме, занимающейся автоматизацией паркингов выпал золотой билет: они разработали концепцию полностью автоматизированного проезда, которой заинтересовались существующие клиенты и большая российская IT-компания.

Еще лучше то, что для этого оказалось достаточно всего одной презентации и общения с существующими клиентами.

Поскольку фирма занималась разработкой систем проезда уже несколько лет и имела свой IT-штат, они решили реализовать архитектуру своими силами и просто привлечь разработчиков для реализации.

Меня они нашли на moikrug.ru и хотели привлечь как руководителя этого проекта и Senior Golang разработчика.

У меня есть опыт, как самостоятельной реализации софта и железа, так и создание своего IoT проекта и опыт руководства отделом разработки в Мегафон IoT.

Но для начала я предложил проверить их архитектуру и ТЗ и только после говорить о каком-либо партнерстве.

Я взял кейс

На первый взгляд все было хорошо. Это был набор сервисов на PHP и Golang, которые был размещен в экосистеме Amazon AWS и хорошенько обвязан их сервисами: транспорт, интерфейсы доступа, аутентификация, нотификации, контейнеры, vpn и прочее.

Это была неплохая верхнеуровневая архитектура, которая использовала лучшее от экосистемы AWS, но я чувствовал, что что-то идет не так…

Проблемы

Тут было несколько очевидных проблем:

  1. Во-первых, в России AWS часто блокируют. И я говорю не просто про историю с Роскомнадзором, такое просто часто происходит.
  2. Во-вторых, в России практически нет специалистов, которые умеют готовить AWS, поэтому DevOps и разработчиков, которые смогут на нем что-то правильно развернуть найти сложно
  3. Российское правительство очень не любит, когда данные о гражданах (особенно их ФИО, номера машин, передвижение и особенно паспортные данные) выходили за пределы российских серверов. AWS серверов в России не имеет.

А это только технические проблемы. Дальше идут уже бизнес-проблемы, которых ни разработчик, ни предприниматель не увидели.

Потеря половины рынка

Фирма предоставляет СКУДы (системы контроля и учета доступа), а я уже занимался продвижения проекта на этом рынке и знал, что большая часть заказчиков требует локальную версию системы. То есть версию, которую можно развернуть полностью у себя на сервере и управлять всеми данными.

И это абсолютно нормальное условие: СКУДы это система безопасности, поэтому такие данные слишком сенситивны.

Если мы полностью завяжемся на AWS, то потеряем добрую долю рынка.

И представьте себе, даже не это основная проблема.

Потеря всего проекта

Когда вы делаете стартап, чаще всего у вас 2 варианта дальнейшего развития:

  1. Оставить его себе, развивать и масштабировать. Тогда ваша задача — это начать получать с этого проекта прибыль и предыдущая глава сразу же погубила бы проект.
  2. Продать его другой компании. Такая цель может стоять с самого начала существования проекта. Тогда прибыль может быть не нужна. Вам будут нужны другие метрики, о которых вы договариваетесь с фирмой, которая вас выкупит.

Подробнее это опишу эти пункты в другой статье.

Поэтому я задал логичный вопрос: «А какая у вас стратегия?»

Как я и думал… Оказалось, что стратегия – продать этот стартап другой гигантской российской IT-фирме.

Вот тут самое главное о чем не подумал Заказчик: в жизни крупный представитель российского IT не купит технологию, находящуюся на серверах Amazon.

Мы позвонили менеджеру, который был выделен со стороны данной фирмы, задали вопрос и после консультации с IT-специалистами они подтвердили, что использование Amazon для нас запрещено.

Слава богу

Да, конечно, сделав проект на Amazon и после этого узнав, что его нельзя использовать, можно было бы переписать проект. Но тут несколько «НО»:

  1. В России нет реально качественных альтернатив сервисам AWS (чего один AWS IoT стоит).
  2. В Open Source нет реально качественных альтернатив AWS.
  3. Стоимость и время могли съесть столько бюджета, что конкуренты (а они были) могли нас опередить и продать свое решение раньше.

Что решили делать

Отказываться совсем от облачных технологий не хотелось, поэтому мы решили следующее:

  1. Будем делать на технологиях, которые не зависят от облака и можно развернуть локально: Docker, Golang, PHP, PostgreSQL, VerneMQ, Graylog, Gitlab, Ansible и подобное.
  2. Будем использовать MCS (Mail Cloud Solutions) или Яндекс.Облако

По итогу взяли MCS. Я лично развернул весь стэк на сервера, БД и графический процессор. Это было быстро, легко и приятно. Только техническая поддержка очень медленная, поэтому многое приходится делать самому.

Лайфхак по Docker и MCS: дольше всего я не разбирался почему есть доступ внутрь контейнеров, но нет изнутри во вне инфраструктуры MCS (запросы отваливаются по timeout), оказалось, что нужна вот эта настройка MTU. Они даже удалили мной гневный комментарий.

Я перерисовал архитектуру, сделал ТЗ, набрал разработчиков, развернул всю структуру, CI/CD, написал несколько Golang модулей и постил проект в свободное плавание.

Запомните!

Я часто говорю это:

CTO должен в-первую очередь понимать специфику ведения бизнеса, и уже предпринимательским взглядом смотреть на архитектуру.

Даже самый опытный программист может допустить фатальные ошибки, о которых несведущий в технологиях предприниматель даже не сможет догадаться. Это погубило много проектов и чуть не погубило проект моего клиента.

Если вы хотите убедиться, что ваш текущий стек, ТЗ или план реализации не погубит ваш проект в будущем, напишите мне, я проанализирую что у вас есть и подскажу, что с этим делать.

Гораздо больше контента и развлечений в Telegram-канале