Масштабирование не будет - переход от PoC к готовому к производству

Шаги, которые необходимо предпринять, чтобы ваш продукт поступил в производство

Итак, ваш PoC готов и работает, вы успешно доказали бизнесу, что ваша идея работает. "Фантастика!" они говорят: «Давайте развернем его в производство на следующей неделе», они также говорят, и вы внезапно поняли, что они на самом деле не поняли ни одной из ваших слов.

Конечно, это происходит не в каждой ситуации, иногда мы можем правильно сообщить о необходимости рефакторинга и продолжить работу, прежде чем мы действительно сможем внедрить идею в производство. Но бывают ситуации, в которых потенциал настолько велик, что в сознании нетехнического человека возникает единственный вопрос: «Почему бы нам не продать это сейчас, а исправить код позже?».

Как ответственный разработчик программного обеспечения, который заботится о продукте и компании, ваша работа - объяснить, что должно произойти, чтобы часть программного обеспечения была «масштабируемой», и - в некоторых ситуациях - что в данном контексте означает «масштабируемость».

Что мы подразумеваем под масштабируемым?

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

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

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

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

Конечно, это способ масштабирования, но он также сопряжен со своим набором трудностей.

• Разделение нагрузки между серверами. Этого можно добиться с помощью балансировщика нагрузки, который будет централизовать трафик к вашей службе, но будет «балансировать» его между кластером серверов. Это замечательно, если взаимодействие с вашим кодом уже не имеет состояния, но если вы храните информацию о клиенте / пользователе в памяти, то последующие запросы будут попадать на разные серверы. К тому же разные компьютеры не разделяют память друг с другом, поэтому каждый раз, когда приходит новый запрос, это будет похоже на то, как новый пользователь начал использовать ваше программное обеспечение. Конечно, есть способы привязать пользователей к одному экземпляру ваших серверов, но это также уменьшает преимущества балансировщика нагрузки.
• На серверах все еще могут не хватать ресурсов. Если ваше единственное решение - продублировать PoC как можно больше раз, вы все равно можете столкнуться с тем же сценарием нехватки ресурсов, который привел вас сюда в первую очередь. Это может быть признаком того, что ваша монолитная служба может лучше подходить как набор микросервисов, работающих независимо друг от друга.

Масштабирование - непростая задача, но она необходима, если вы хотите, чтобы программа выдержала испытание временем. Если ваш продукт будет успешным, количество ресурсов, которые ему понадобятся, увеличится, потому что количество людей, использующих его, увеличится. Если вы этого не планируете, вы не сможете удовлетворить спрос, и ваши пользователи пострадают от последствий (например, плохой UX, ужасная производительность, отсутствие стабильности и т. Д.).

Как масштабировать PoC?

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

И это совершенно верно, для PoC вы обычно заканчиваете срезание некоторых углов и жесткое кодирование некоторого поведения. В конце концов, вы хотите, чтобы основная идея, стоящая за ним, выделялась, все остальное будет выброшено и перекодировано.

Почему? Посмотрите на сценарий, о котором мы говорили до сих пор: единое программное обеспечение, которое теперь необходимо масштабировать. Это не значит, что вы можете просто сказать: «Давайте разместим его на лямбде AWS» или «Я разверну его в Azure, и он масштабируется».

Все это отличные идеи и фантастические способы масштабирования приложения, но только если это позволяет код. Что в случае одного PoC шанса: не будет.

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

Поймите, где находятся болевые точки вашей системы

Первое, что вам нужно понять, прежде чем вы начнете разбивать PoC на несколько сервисов, - это то, какие его разделы используют больше всего ресурсов. Будь то память, ввод-вывод или процессор, для всего ресурсоемкого, вероятно, потребуется собственный сервер, чтобы он мог использовать все свои ресурсы, не разделяя их с другими разделами.

Вы должны измерять это в стрессовых ситуациях. Другими словами, найдите нагрузочный тестер и доведите свой код до предела. Разберитесь, как выглядит этот предел и почему он доходит до него. Это количество запросов? Или, возможно, количество полученных одновременных запросов? Или, может быть, они просто идут один за другим, но слишком близко друг к другу. Какова бы ни была причина, это даст вам представление о том, какие части вашего приложения страдают больше всего, поэтому их придется извлечь и оптимизировать.

Планируйте свои услуги и их протокол связи

Хорошо, теперь, когда вы понимаете, в чем заключаются проблемы, пора немного повеселиться: разделить вещи на части.

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

И этот код вызвал все те функции, которые были частью вашего локального контекста, но теперь, после вашего анализа, вы пришли к выводу, что и grabALOTOfDataFromTheDataBase, и processTheData должны быть собственным набором сервисов.

И вот где возникает проблема и почему масштабирование не так просто, как «я заставлю его работать на лямбде». Вы использовали локальную память для перемещения данных и параметров от одной функции к другой. Вы извлекали данные из базы данных и сохраняли их в локальной памяти (то есть в переменной bigDataSet), а затем передавали эту память функции processTheData в качестве параметра. Так больше не может происходить, потому что, как только вы превратите эти функции во внешние службы, вам придется иметь дело с отправкой данных по сети.

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

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

• Задержка. Насколько это важно для вашей службы? Некоторые протоколы связи тяжелее других. Использование REST через HTTP - это не то же самое, что использование двух сервисов через веб-сокеты.
• Сериализация данных. Вернитесь к примеру, который я показал выше, переменная bigDataSet может быть чем угодно, это может быть объект класса DataSet, который имеет несколько методов и другие несериализуемые свойства. Однако этот набор данных должен будет пройти по сети до созданной вами новой службы. Как ты собираешься это сделать?
• Десериализация данных. То же, что и раньше, но в противоположном направлении. Если вы получите результаты от новой службы для grabALOTOfDataFromTheDataBase, эта служба не сможет отправить вам объект набора данных по сети, но вашему коду потребуется, чтобы он был объектом. Таким образом, вам нужно знать, как превратить этот набор данных в объект.
• Локальные файлы. Вы используете локальные файлы для чего-либо на своем PoC? Это обычный угол, который мы склонны сокращать, потому что для PoC мы можем иметь дело с локальным CSV вместо полноценной базы данных, но теперь мы не можем. Нам нужен эффективный способ загрузки данных, а дисковый ввод-вывод - не один. Так что подумайте о том, чтобы переместить все эти локальные тяжелые файлы на подходящий носитель.

Вы, вероятно, сможете подумать о еще парочке проблем, если начнете работать над своим собственным проектом. Это может быть настоящей головной болью, и хотя это, вероятно, один из немногих способов надежно преобразовать PoC в состояние готовности к производству, это также требует много работы.

Убедите бизнес уделять вам больше времени и ресурсов

Последний шаг перед внедрением - получение одобрения компании. Помните, они хотели начать производство с вашим PoC? И теперь, после тщательного измерения производительности и планирования новой архитектуры и усилий по рефакторингу, у вас есть предлагаемый график.

Пора продать. И здесь начинается самое интересное, потому что, если вы не разбираетесь в деловой беседе, вы потратите 10 минут на то, чтобы понять, почему ваше решение настолько технически надежно и идеально подходит для того, чего они хотят, и никто не будет вас слушать. Они могут сказать что-то вроде «Я не понимаю» или «Почему мы не можем беспокоиться о том, что код будет хорошо выглядеть после этого?» и хотя это может вызвать у вас ощущение, будто вы все это время разговаривали с кирпичной стеной; это не их вина, это твоя.

Они не глупы, нет, нет, не делайте этой ошибки. У них просто разные цели. В то время как ваша задача - обеспечить техническую надежность решения, их задача - обеспечить, чтобы компания зарабатывала деньги, и, по их мнению, у вас есть совершенно хороший продукт, который вы уже продемонстрировали, и теперь вы не хотите развертывать его, пока не сделаете это ». идеально".

Я был в таких разговорах и поверь мне, я понимаю твое разочарование.

Первое, что вам нужно понять, это то, что вам нужно идти на компромисс. Ваш план не может быть похожим на план типа «давайте построим это в течение 6 месяцев, а потом побеспокоимся о развертывании». Это означает, что они не видят никаких реальных преимуществ в течение длительного времени, вместо этого пытаются спланировать более итеративный подход, спланировать сначала наиболее важные изменения и развернуть текущий код с идеей замены его немного лучшей версией в 2–2. 3 недели.

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

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

И вы сделали! Если вы сделали это и успешно продали план реализации бизнесу, не пора вкладывать деньги в дела и писать код.

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

Приходилось ли вам когда-нибудь проходить через это раньше? Что ты сделал? Удалось ли продать идею и план реализации? Оставляйте свои комментарии ниже и поделитесь своим опытом!

Автономные команды строят вместе

Создание монолитных приложений означает, что все работают вместе, в одной кодовой базе и над одной раздутой версией. Это часто делает разработку болезненной и медленной при масштабировании.

Но что, если вместо этого вы сначала создаете независимые компоненты, а затем составляете приложения? Автономные команды, строим вместе!

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

Инструменты OSS, такие как Bit, предлагают мощный опыт разработчика именно для этого. Многие команды начинают с создания своих дизайн-систем или микро-интерфейсов через компоненты. Попробуйте →

Учить больше