Технические знания для работы в облаках

· 3 мин

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

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

Один из моих продуктов - Google Cloud Run for Anthos. Разберём пошагово, что он делает, и заодно посмотрим на требования к знаниям.

  1. Всё начинается с кода, который клиенты запускают на облачной платформе Google Cloud. Мой продукт помогает разработчикам быть более эффективными. Чтобы понимать пользователей, мне нужно разбираться в процессах создания ПО в локальной среде: кодинг, управление зависимостями, сборка, отладка, git.

  2. По старинке код заливают на сервер, но это вчерашний день. Последние годы в тренде “бессерверные” технологии (разработчикам не нужно управлять инфраструктурой) и контейнеризация (код упаковывается в “контейнер” со всеми зависимостями). Мой продукт объединяет обе технологии и, чтобы разработчикам не нужно было думать об инфраструктуре, он берёт на себя задачу “упрощения” технологий. Мне нужно немного разбираться в контейнерах.

  3. Продукт построен на опен-сорс платформе Kubernetes, которую создали внутри Гугла. Тут начинается самое сложное. Kubernetes даёт много свободы администраторам (они - моя вторая категория пользователей), но чересчур сложный для разработчиков. Задача нашего продукта - дать админам гибкость в настройке, но скрыть всё это от кодеров. Мне приходится разбираться в деталях Kubernetes.

  4. Чтобы упростить жизнь разработчикам и создать иллюзию “бессерверности”, моя команда создала опен-сорс проект Knative. Скажу лишь, что он сложный и пока ещё не достиг версии 1.0, поэтому там много подвижных частей. Он - ядро продукта и его мне нужно понимать достаточно глубоко.

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

    Для сети (network layer) используется гугловский опен-сорс проект Istio, который добавляет к контейнерам в Kubernetes так называемые “sidecars” - дополнительные контейнеры, которые работают рядом с пользовательскими и отвечают за регулировку трафика, мониторинг и соблюдение политики безопасности внутри системы. Нужно разбираться в сетевых протоколах, DNS и информационной безопасности в целом.

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

  7. Интерфейсы продукта: командная строка, графический UI и платформа автоматизации инфраструктуры Terraform. Нужно разбираться в UX дизайне и как он помогает пользователям достигать их целей (UX - это не только то, что можно кликать, а всё, с чем взаимодействует пользователь). Также нужно понимать основы DevOps (infrastructure as code, CI/CD, GitOps).

  8. И напоследок - приложениям пользователей нужно делать запросы к другим продуктам Google Cloud. Эта задача не всегда тривиальная, потому что между приложением и API этих сервисов стоит Kubernetes. Нужно разбираться в платформе Google Cloud и авторизации запросов из Кубернетиса.

Когда я пришёл в Google, я не разбирался в контейнерах и всём, что связано с Kubernetes, Knative и Istio. Мне также не хватало знаний по сетевым протоколам. Чтобы почувствовать себя относительно уверенно, ушло полгода, но мне далеко до комфорта, который я испытываю в области, где у меня есть глубокая экспертиза. Идеальный кандидат на такую работу был бы разработчиком из Гугла, перешедший в продакт менеджмент. Такие есть, но их мало.

Большинство продакт менеджеров в Google Cloud, что я знаю лично — бывшие разработчики, которых тянуло к бизнесу, стратегии и более масштабному мышлению. Если кто-то из вас разработчик, задумывающийся о переходе в продакт менеджмент, вас оторвут с руками на продукты с технической пользовательской базой при наличии сильных продуктовых скиллов. Дерзайте!

# Продакт менеджмент # Google