Вернуться к фондам

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

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

  • Код работоспособности
  • Обработка ошибок
  • Расширяемость
  • Масштабируемость

Прежде чем мы углубимся в это:

  1. В этом году на RedisConf в Сан-Франциско я сделаю небольшой доклад об использовании Redis в Spinnaker. Приходи, поздоровайся, если собираешься! У меня может быть хабар (стикеры, книги).
  2. Если вы проводите конференцию и хотите что-нибудь на Spinnaker, свяжитесь со мной: я, может быть, приду и сделаю что-нибудь или найму кого-нибудь из своей команды.

Код здоровья

Как я уже сказал, Спинакеру 5 лет! Что касается кодовых баз, это хорошая долговечность, но теперь нам нужно улучшить извлеченные уроки, убрать мусор и решить проблему технического долга. В Spinnaker есть много областей, которые не вызывают радости. Это естественно для проекта, который подвергается быстрой итерации и экспериментированию - теперь мы извлекли уроки и должны применять их в более широком смысле!

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

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

Еще пара примеров, оба в стадии разработки.

  • Обновление Spring Boot 2. Спинакер по-прежнему на 1.5! Это означает, что мы отстаем в исправлении критических ошибок, и Spring Boot 1.x в этом году завершен.
  • Рефакторинг Echo Scheduler. Это всего лишь один случай упрощения, которое должно произойти в наших сервисах. Это не только упростит кодовую базу, но и значительно улучшит операционную историю Echo.

Нам также необходимо повторить нашу историю RPC (gRPC), продолжить постепенное удаление Groovy и улучшить наши инструменты разработчика. Множество вещей, которые созрело сообщество, чтобы откусить (если вы того пожелаете).

Спасибо, старый код, за все, что вы для нас сделали.

Обработка ошибок

Stage failed (No reason provided).

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

Нам нужен более стандартизированный способ распространения ошибок через границы сервисов и понимание разницы между ошибками оператора и пользователя. Кроме того, нам нужна лучшая история для различения: 1) системных ошибок, 2) ошибок интеграции и 3) ошибок пользователя в коде. Системные ошибки - это ошибки, в которых Spinnaker сделал что-то плохое из-за ошибок (вероятно, по моей вине). Ошибками интеграции могут быть сторонние службы и плагины, для конечного пользователя это обычно проявляется как системная ошибка, но операторы нуждаются в этом дополнительном измерении.

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

Расширяемость

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

Однако не у всех есть время, опыт или ресурсы для создания собственных сборок Spinnaker. Нам нужна лучшая система ввода: предварительно настроенный этап Docker - это шаг в правильном направлении: он позволяет вам писать произвольный код в контейнере и запускать его как собственный этап. Для этого нужна лучшая документация, и нам нужно открыть другие области, где это имеет смысл для аналогичных точек расширения.

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

Масштабируемость

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

Мы очень много внимания уделяли этому фундаменту в течение последних 6–8 месяцев, и он по-прежнему будет моим основным приоритетом. Из месяца в месяц мы становились все надежнее и быстрее, но что я могу сказать, для меня этого еще недостаточно.

Помощь!

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

Заинтересованы? Присоединяйтесь к каналу #dev в Spinnaker team Slack!