Проблема, с которой столкнулся наш отдел, заключалась в следующем. У нас было несколько десятков микросервисов, и их число продолжало расти. При этом, как это часто бывает, в Go разработку люди пришли из других языков и принесли с собой различные практики. Всё бы ничего, но когда один сервис написан так, как привыкли писать на PHP, другой вдохновлен Ruby, а третий и вовсе отдаёт плюсами, то становится жутко. С таким зоопарком подходов переключаться от сервиса к сервису очень сложно и трудозатратно, а главное, чревато большим количеством ошибок в разработке. Тут тебе и стабильность продукта страдать может и тайм ту маркет расти. Решением сперва стал шаблонный сервис, на который стали ориентироваться при создании новых сервисов и рефакторинге старых, а потом и cli-утилита, которая занималась кодогенерацией скелета проекта и основных его компонентов. Также общие элементы, как, например, клиент к бд или grpc dialer, были вынесены в отдельный репозиторий с целью переиспользования во всех сервисах. Польза такого подхода дала о себе знать. Создание новых сервисов и поддержка старых ускорились, а влияние человеческого фактора в рутинных операциях снизилось. Да и разрабы стали счастливее, потому что уже не нужно было писать однообразный код, а он сам генерился.

Если что-нибудь может пойти не так, оно пойдёт не так (закон Мерфи).
В докладе мы намеренно станем программистами-параноиками.
Потребитель вашего кода (в первую очередь ты сам) может и будет его использовать неправильно.
А значит баги закладываются еще на этапе дизайна публичного API.
Контракты, заложенные в сигнатурах функций и интерфейсах, определяют сколько родится багов при использовании вашего кода.
В твоей власти спроектировать контракты так, чтобы не допускать ошибок при их использовании.
На нескольких примерах мы пройдем путь от ненадежных контрактов к надежным.
На всех этапах дизайна кода будем исходить из того, что кодом будут пользоваться самые "одаренные" программисты.

Для кого доклад:

• небольшие команды
• для тех, кто планирует или начал переход на микросервисы
• для тех, кто уже перешёл, но страдает от высокой стоимости поддержки

Тезисы:

• Какие проблемы поможет решить PaaS? (сокращаем порог входа и человеческий фактор, увеличиваем унификацию)
• PaaS - необязательно сложно и дорого (нет небоходимости всё кастомить, можно брать готовые решения и со временем тюнить их под себя)
• С чего начать? (базовый фреймворк, конфигурация, лейаут сервиса, observability, CI и деплой, автоматизация)
• Архитектура компонентов (минимальный набор необходимых фич, как что устроено)
• Как организовать миграцию старых сервисов на новые рельсы
• С какими проблемами столкнулись лично мы (разные виды сервисов, тулинг)
• Дальнейшее развитие (разные типы сервисов, генерация чего-либо для уже готового сервиса)

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