10 лет — срок, за который успеваешь пройти путь от восторженного первооткрывателя до усталого прагматика, а затем, если повезёт, вернуться к чему-то вроде осознанного энтузиазма. Именно столько я живу бок о бок с микросервисной архитектурой, и почти всё это время меня преследует один и тот же вопрос: почему ни один API Gateway не делает всё так, как хотелось бы?
Всё начиналось с Ocelot — .NET-овского решения, которое в своё время казалось откровением. Отличный конструктор с декларативная конфигурацией и понятной маршрутизацией. Но стоило выйти за рамки типовых сценариев — и приходилось лезть в код, дописывать middleware, мириться с ограничениями или искать обходные пути. Потом был KrakenD — быстрый, написанный на Go, с красивой идеей агрегации бэкендов. Lura, лежащая в его основе, обещала расширяемость, но на практике каждая дополительная нетривиальная задача значительно увеличивала время ответа и даже реализация gRPC Unary требовала «костыля».
Отдельная боль, которую я испытывал годами — управление секретами и сертификатами. Пароли в конфигах. API-ключи в environment variables. Сертификаты, которые забывают обновить и сервис падает в три часа ночи. Ротация credentials, которая требует рестарта.
Я модифицировал, патчил, оборачивал в прокси-слои, писал плагины. Решал частные задачи — и каждый раз ловил себя на мысли: «Вот бы это уже было из коробки».
Годы шли, проекты менялись, технологии эволюционировали — а мечта оставалась. Создать свой opensource API Gateway. Не очередной «ещё один прокси», а инструмент, спроектированный с учётом всего того опыта, который накопился за эти годы. Инструмент, где каждая функция — это ответ на реальную боль, а не галочка в маркетинговом чеклисте.