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

Начиная с лета 2013 года компания ClearBlade возглавила создание платформы, достаточно мощной для поддержки корпоративных подключений во всех возможных формах — от Интернета вещей (IoT) до корпоративных систем записи. Хотя мы рассмотрели ряд различных инструментов для работы, Go быстро показал себя как единственный вариант платформы, ориентированной на производительность, для решения этих новых вариантов использования для предприятия. Мы не были уверены, стоит ли делать ставку на новый язык, но это решение уже окупилось так, как мы не ожидали.

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

Данные — возможность хранить данные в масштабируемом облаке; или подключиться к существующим базам данных

Обмен сообщениями — возможность мгновенно общаться через несколько приложений и платформ.

Код — возможность писать логику в масштабируемом облаке или обращаться к существующим уровням обслуживания.

Хотя Python был нашим первоначальным выбором для создания модуля данных, он быстро начал отставать от требований к обмену сообщениями, которые мы к нему предъявляли. Поддержка параллелизма в Python не соответствовала требованиям гибкости, масштабируемости и производительности облака. Мы просто не могли рисковать производительностью при использовании Python для обработки сотен тысяч сообщений в секунду, которыми обмениваются в мобильном мире предприятия и государственные учреждения.

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

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

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

Scala был языком, который, как мы были уверены, идеально подойдет. Он используется Twitter, поэтому его способность масштабироваться как облачный язык доказана. Многие разработчики даже считают Scala следующей версией Java, которую будет легко внедрить в корпоративную среду. Общий размер и раздутость Scala сделали затраты на разработку и внедрение слишком высокими для нас. Добавьте к этому стоимость виртуализации этих виртуальных машин, и это станет немного пугающим.

Итак, мы, наконец, обратили внимание на Go, развивающийся язык, который поначалу не решался рассматривать. Однако казалось, что он удовлетворяет всем нашим требованиям, поэтому мы рискнули и решили погрузиться в него. Мы написали наш брокер сообщений, реализующий протокол MQTT, самый популярный выбор для маломощных M2M-коммуникаций, которые олицетворяют варианты использования Интернета вещей. , для нашего продукта.

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

Мы были настолько впечатлены Go, что использовали его для всей платформы. Мы написали модуль RPC для передачи информации между модулями из входных данных REST, написали модуль аналитики для сбора сведений о каждом взаимодействии в системе и перекодировали модуль данных с Python на Go. Все это было сделано командой инженеров ClearBlade менее чем за пять месяцев. Оказывается, наши опасения по поводу работы на новом языке были совершенно необоснованными.

Лучше всего то, что модуль данных, который мы переписали на Go, теперь обрабатывает запросы в 5 раз быстрее, чем наша пилотная реализация. Иногда мы принимаем удачные решения, иногда мы принимаем обоснованные решения. Мы позаботились о счастливой части — и призываем вас принять взвешенное решение взглянуть на Go.