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

Я могу начать с того, что поделюсь с вами кое-чем немного секретным — слайдом из нашей презентации по сбору средств.

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

Принципы

Принципы нашей инфраструктуры основаны на Двенадцати факторах. Это входит в список рекомендованных к прочтению, вроде Дисков острова разработчиков? (Извините). Мы считаем, что это самые важные части.

Инфраструктура как код / ​​одноразовость / домашние животные против крупного рогатого скота

Настройка инфраструктуры с помощью уродливого интерфейса AWS может показаться самым простым способом приступить к работе (и, вероятно, так оно и есть), но что произойдет, если эти службы перестанут работать? Гораздо лучше иметь одну команду для повторного развертывания всего стека в новой среде или для замены прерванного производства в 3 часа ночи субботним клубным вечером. Мы относимся к инфраструктуре как к скоту, а не к домашним животным: когда они заболеют, вы получите еще одного.

В частности, все наши сервисы работают в контейнерах Docker на Rancher. Мы можем перезапускать и откатывать неверные выпуски с помощью команд Docker за считанные секунды и запускать новый хост Rancher менее чем за минуту.

Создавайте, выпускайте, запускайте

Мы обеспечиваем невозможность внесения изменений в код во время выполнения путем создания сервисов независимо от того, где они выполняются. В частности, мы отправляем созданные образы Docker в Google Container Registry на GCP и запускаем их на Rancher в DigitalOcean за управляемым балансировщиком нагрузки.

Процессы без сохранения состояния

Наши бэкэнд-сервисы — это докеризированные приложения node.js без сохранения состояния, которые общаются по HTTP (классический подход к микросервисам). Их можно свободно перезапускать и масштабировать, поскольку они не записываются на диск и не имеют общей памяти.

Соотношение разработки и производства

Наши среды разработки и производства практически идентичны, и мы можем запускать все службы локально в виде контейнеров Docker. Мы используем ngrok для тестирования таких вещей, как Apple Pay, которые должны запускаться из безопасного источника (веб-страницы HTTPS). Ngrok также позволяет третьим сторонам отправлять настоящие веб-перехватчики в наши среды разработки. Мы используем ngrok в коммерческих целях (мы платим за это), поскольку у каждого сервиса есть туннель ngrok.

Швы

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

Stickyretail — наше флагманское приложение. Мы часто проводим аналогию между Stickyretail и Sticky, как Microsoft Office для Windows: это отличный пример того, что можно построить на Windows, и любой может создать что-то вроде Office, если у него есть время и энергия. Microsoft создала Office так, чтобы никому не пришлось этого делать, и потому что он добавил ценность Windows, но любой мог создать и продать его, а также добавить ценность Windows.

Точно так же, как Office — это просто набор приложений, работающих в Windows, Stickyretail — это просто приложение, работающее на Sticky. У нас нет привилегированного положения, чтобы создать Stickyretail — вы тоже можете создать его с помощью React и нашего SDK. Нет никакого «особого случая» или чего-то незадокументированного, что делает возможным Stickyretail. Вы так же активны, как и мы.

Создание Stickyretail таким образом было очень важно для нас. Это заставило нас убедиться, что SDK достаточно хорош для создания серьезных приложений корпоративного уровня, и это помогло нам создать отличный опыт для разработчиков. Мы были разработчиками в нашей собственной экосистеме, или, другими словами, мы ели свою собачью еду. И мы сделали это вкусно.

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

Мне очень нравится наблюдать за «потоками» других компаний. Они напоминают мне классический вопрос на собеседовании: «Что происходит, когда я набираю google.com в своем веб-браузере?». Имея опыт работы с C и программированием для чипов ARM, я всегда интересовался этим вопросом, говоря, что есть системный вызов, прерывание клавиатуры и т. д. и т. д. и т. д., что, безусловно, раздражало некоторых менеджеров по найму. Так или иначе. Что происходит, когда кто-то использует Stickyretail? Что такое «поток»? Я потратил пару часов, рисуя его в Sketch.

Что произойдет дальше?

Мы гибки со строчными и прописными буквами A, что означает сохранение опциональности в нашей инфраструктуре, а также снижение затрат. Иногда для этого приходится идти на компромиссы. Один из компромиссов, на который мы пошли, заключается в том, что наши экземпляры API используют один и тот же поток для аутентификации/«обычных HTTP-запросов», а также для тяжелых/блокирующих вычислений, таких как запросы событий и преобразование больших ответов JSON в строки. Мы планируем абстрагировать аутентификацию от третьего микросервиса (например, «Почта» и «Геолокация»), что позволит нам ввести больше сервисов помимо «API», к которым можно будет публично перенаправляться. Первым из них будет служба поиска событий, возможно, даже не написанная на JavaScript! Впереди действительно захватывающие времена.