Роман Долин

Если вы хоть немного следите за IT, то наверняка встречали выражение Cloud Native. Звучит так, будто речь просто о приложениях, которые работают в облаке. Но это не совсем так. Я бы объяснил Cloud Native гораздо проще: это подход к созданию программ, при котором приложение изначально проектируют так, чтобы оно хорошо жило в современной облачной инфраструктуре - масштабировалось, переживало сбои и быстро обновлялось. И вот здесь начинается самое интересное. Представим обычное приложение. Разработчик написал его, установил на сервер, настроил базу данных и сказал: "Ну всё, работает". Пока пользователей немного, действительно работает...

Первый релиз - это всегда волнительно, постоянно возникает мысль, что движешься не в том направлении. Главная задача - не давать архитектурной сложности сожрать проект. Всё начинается с фиксации API-контактов между фронтендом и бэкендом и жёсткого Feature Freeze. На этом этапе нужно вырезать всю избыточную инфраструктуру. Никаких микросервисов, если можно обойтись простым монолитом, и никаких сложных схем авторизации, когда достаточно базового JWT. Как только скоуп зафиксирован, проект упаковывается в Docker - это единственный надёжный способ закрыть вечный спор о том, что на локальной машине всё работало идеально...

Я часто смотрю на выбор хелпдеска совсем под другим углом, чем менеджеры или маркетологи. Пока все выбирают красивые дашборды и сочные графики, мы думаем о том, как вся эта махина будет уживаться с нашим кодом, базами данных и релизами. Для меня идеальный хелпдеск - это тот, который не пытается быть изолированной экосистемой, а бесшовно встраивается в уже существующий технический стек. Если у системы закрытый или кривой API, это сразу приговор, ведь нам придется тратить недели на то, чтобы просто подружить форму отправки багов на сайте с тикет-системой. Хорошая платформа должна иметь понятную документацию,...