Как стать автором
Обновить

Комментарии 12

Большие молодцы!


Я только с гитлаб CI месяца два игрался. Вам, кстати, дико повезло. Они сильно прокачались за последний год.


А транскодер амазоновский юзали? Тормознутый или дорогой?


Кстати, какой расклад по железу? Сколько процов и озушки на прод окружение потребовалось? И если не секрет, какие счета выставили облачные провайдеры? Такое ощущение, что 93% конечного чека составила плата за траффик.

Да, транскодер амазоновский. Что имеется ввиду под тормознутостью?
Прайс на амазоне есть, всё зависит от настроек и региона. Не дешёвый :) Но с ростом объёма смотрящих основные деньги конечно же уходят на трафик с cdn

По самому железу достаточно скромного упихано всё, k8s кластер так вообще маленький. Облачные провайдеры у нас yandex и amazon. Каждый для своего используется.
Если говорить про видео то с нашим объёмом раздачи контента выходит меньше 90% за cloudfrount

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

Николай Молчанов: У нас есть аналитик, дизайнер, тестировщик, три фронтендера, бэкендер. И, конечно, T-shaped специалист!


А кто разбирался с kubernetes, налаживал DevOps, например вот этот вот все кто делал:

У нас два кластера. Тестовый и продовский. Они абсолютно одинаковые с точки зрения железа, настроек. Имплементируем инфраструктуру как код. Все сервисы автоматическим пайплайном раскатываются в три среды из фичи-веток, из мастер-веток, из тестовых, из GitLab. Это максимально интегрировано в GitLab, максимально интегрировано с Elastic, Prometheus.


По затратам времени:

У нас изначально было требование с технической точки зрения к продукту максимально абстрагироваться от какого-либо вендора. Прийти в AWS делать Terraform-скрипты конкретно AWS-овские, или конкретно яндексовские, или Azure-овские и т.д. не очень подходило. Мы должны были в своё время куда-то съехать.

Первые недели три мы постоянно искали путь, как это лучше сделать. В итоге пришли к тому, что Kubernetes в данном случае — это наше всё, потому что позволяет делать автоматически-масштабируемые сервисы, автовыкатку и получить из коробки практически все сервисы.

За три месяца вы сделали 13 микросервисов, и подозреваю, что они написаны не только на Java.


Из трех месяцев один ушел на «поиск пути». Выходит, 13 микросервисов сделано за два месяца, по четыре рабочих дня на микросервис. Это один бэкендер все делал? Причем, вот с таким качеством:

Владимир: Поэтому большой успех, что, когда я эстимирую фичу, говорю, что мне нужно 4 дня на две простые ручки и 1 websocket, Коля разрешает. Он уже привык, что в эти 4 дня заложены 2 типа тестов, и потом, скорее всего, это будет работать

У меня тоже написано 140 тестов: компонентных + функциональных, которые делают то же самое. Все те же самые сценарии тестируются и на продакшене, на тесте и на деве. Также недавно у нас появились функциональные базовые UI-ные тесты. Так мы покрываем самые базовые функциональности, которые могут развалиться.

На данный момент у меня на борту примерно 70 компонентных тестов и около 40 интеграционных. Покрытие очень близко к 95%.


А кто разбирался с kubernetes, налаживал DevOps, например вот этот вот все кто делал:

Как писали выше, в команде есть T-shaped персонаж. Он и разбирался =)

Выходит, 13 микросервисов сделано за два месяца, по четыре рабочих дня на микросервис. Это один бэкендер все делал?

Сейчас коллеги придут в тред и напишут как так вышло.
Могу сказать, что в статье никто не наврал =)
Как писали выше, в команде есть T-shaped персонаж.

А, ну это все объясняет. Можно только добавить, что маг более высокого уровня — Tree Shaped — вообще все это в одиночку бы сделал, см. Why Tree-Shaped Employees are Worth 10 T-Shaped Employees :)
Привет!

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

Коля писал авторизационные сервисы, типа, BFF и бизнесовые на шарпе, а я — на жаве, так что я для себя считаю что беком все же занимались 2 человека. Секрет наверное в том что Коля работал как 3 или 4 человека по мощности и полезному выхлопу, в том числе и по линии девопс, а я фигачил до 18 часов в день тоже в довольно высоком, нехарактерном для себя темпе. Т е мы реально много и интенсивно работали.

Вот моя активность на нашем гитлабе:
image
Хорошо видно, что февраль был очень ровным, режим работы плотный, но «штатный», а потом в марте я перешел в режим ЧС на 3 месяца, потом месяц конференционный период и отпуск!
мы с самого начала собирали микросервисы в докере

А как же всякие «оркестровка», Ingress, Service Mesh и прочая?
Когда кубер был готов Коля приготовил самые базовые, в смысле только жизненно необходимые для начального развертывания, конфиги и компоненты для микросервисов: чистый кубер, ингресс — да, istio и helm — нет.
Я имею ввиду жизнь «до кубера». Вот вы «собирали микросервисы в докере» а дальше-то что? Как обеспечивалась их совместная работа? Или они друг от друга совершенно не зависят?
Те от которых зависели — захардкодили айпишки или в файлы пропертей прописали, потом уже ингресс и балансировщики подвезли, в общем это как раз не тормозит разработку, если по АПИ договориться
Зарегистрируйтесь на Хабре, чтобы оставить комментарий