Игорь Никифоров о будущем методологии DevOps и её особенностях - "DevOps-специалисты нужны будут всем"
С развитием продуктовых IT-разработок всё большему числу компаний становится очевидно, что модель, в которой программисты работают отдельно от администраторов, теряет свою актуальность и не приводит к желаемым результатам. В связи с этим появилась необходимость создания нового подхода, который позволит сократить жизненный цикл разработки систем и обеспечит высокое качество программного обеспечения. Решением стала методология DevOps.
Благодаря новой модели, компании получили бесшовный цикл разработки, где все отделы и специалисты, работающие над проектом, действуют вместе и понимают суть задач друг друга. Сегодня всё больше организаций по всему миру внедряют методологию DevOps и инструменты автоматизации в бизнес-процессы, а значит потребность в специалистах в этом направлении непрерывно растёт.
Чтобы разобраться, какими компетенциями должен обладать сотрудник, выполняющий роли инженера, разработчика, и менеджера, мы поговорили с ведущим DevOps-инженером крупной компании. В интервью Игорь Никифоров поделился своим взглядом на методологию, дал советы начинающим специалистам и рассказал о своём пути. Также нам удалось обсудить вопросы, связанные с популярностью контейнеризации и Kubernetes в целом.
Кто же такой девопс инженер и какие обязанности он выполняет в компании?
Сегодня в это понятие вкладывают разные смыслы и какой-то общий профиль DevOps-специалиста выделить сложно. Во многом требования к представителям этой профессии будут меняться от компании к компании, также играет роль, о каком рынке идёт речь — европейском или американском. Поэтому каждый специалист будет отличаться определенной долей технической экспертизы или опытом в конкретных технологиях.
Расскажите, как вы пришли к этой профессии?
Я исходил из своих увлечений. С детства интересовался компьютерами, поступив в вуз, активно "ударился" в программирование на C++ и проходил практику в качестве программиста. После окончания университета разрабатывал программное обеспечение для крупной компании. Мне всегда хотелось расти и двигаться дальше, однако реалии рынка не позволяли это сделать, и я решил попробовать себя как инженер. Полноценно определился, в какую сторону хочу двигаться, работая в японской компании, занимающейся производством печатной техники. Опять же свою роль сыграл интерес: уже тогда я активно начал изучать облачные технологии, контейнеризацию, сначала Docker, а позже и Kubernetes, тогда он только набирал свою популярность.
На сегодняшний день работаю ведущим DevOps-инженером в IT-компании, занимающейся разработкой облачной платформы для помощи онкологам в подборе терапии для пациентов.
Какие обязанности выполняете?
Я занимаюсь IT-инфраструктурой и всем, что с ней связано. Моими непосредственными задачами являются прототипирование архитектуры, автоматизация внедряемых решений из различных кластеров баз данных, сбор логов сообщений как приложений, так и самой инфраструктуры, Kubernetes. Безусловно, на всех этапах приходится тесно работать с другими инженерами и разработчиками и консультировать их по возникающим вопросам.
Какими качествами, на ваш взгляд, должен обладать хороший специалист?
Первое – знание базового стека и навыки работы с сетями. Без этого в нашей сфере никак. Ещё одно – готовность постоянно учиться и следить за всеми изменениями в сфере. DevOps меняется с невероятной скоростью, поэтому важно быть в курсе последних тенденций и технологий. Третье – умение работать в команде. Пожалуй, без этого качества невозможна сама методология, где важно слаженное взаимодействие и понимание между коллегами.
В последние пару лет резко возросла популярность контейнеризации, хотя сама технология контейнеризации не нова и появилась достаточно давно. Можете ли вы выделить какие-то преимущества данной технологии?
Сам контейнер — это, по сути, экземпляр вашего приложения, которое упаковано вместе со всеми его зависимостями, в т.ч. библиотеками, конфигурационными файлами и средой выполнения, поэтому приложение, которое было отлажено и запущено в контейнере на одном хосте, можно без проблем запустить на другом. Основное преимущество заключается в том, что контейнер абстрагируется от операционной системы, на которой выполняется, т.е. не включает в себя её образ, за счёт чего его легко перенести с одного хоста на другой. Контейнеры также используют системное ядро операционной системы (в т.ч. kernel), следовательно, запуск контейнера не требует отдельного запуска экземпляра ОС.
Ещё одним преимуществом является тот факт, что контейнер в полной мере позволяет использовать ресурс и функции основной системы. Например, вы можете использовать контейнеризацию не только для изоляции приложений, но и для контролироля ресурсов, которые они используют, к примеру, количество ядер процессора или объем оперативной памяти. За счёт своей легковесности и портативности, контейнеры позволяют очень эффективно развёртывать приложения и горизонтально их масштабировать. Они также являются отличным способом для управления версиями, так как с помощью них очень удобно отслеживать версионность и следить за различиями между ними.
Можете ли объяснить в каких случаях подходит контейнеризация и какие риски могут быть с ней связаны?
В первую очередь, контейнеры прежде всего очень хорошо подходят для микросервисной архитектуры - для компонент приложения которые можно обновлять в независимости от других приложений, а также горизонтально масштабировать, т.е. увеличивать количество копий одного и того же приложения для распределения нагрузки. Так же это очень удобный способ не только для локальной сборки и отладки Вашего приложения, но и для упрощения самого процесса развертывания и последующего сопровождения. Проще говоря это следующий уровень абстракции, который необходим для более быстрой разработки и доставки ваших приложений.
Несмотря на все эти преимущества, которую можно получить от контейнеризации, есть также ряд рисков, связанных с безопасностью, которые нужно учитывать при ее внедрении. Самый распространенный из них, это сборка и последующее развертывание контейнера из уязвимого образа, который может содержать какие-то уязвимые пакеты или софт. Поэтому вы должны всегда проверять какие образы вы используете в качестве основы для упаковки своего приложения в контейнер. Еще один момент, который так же нужно иметь ввиду, это то что помимо самого образа контейнера, источником уязвимости может быть и сам контейнер который развернут на хосте. Так как наличие уязвимостей в установленных пакетах, наличие вредоносного кода, а также наличие привилегированных прав под которыми может быть запущен такой контейнер, несет в себе большие риски, что появится большая вероятность компрометации такого контейнера, например, использование его с повышенными привилегиями с возможностью получение доступа к хостовой операционной системе, ну и в последующем уже запуск сторонних вредоносных процессов и распространение атаки на соседние контейнеры или даже хосты.
Говоря о популярности контейнеризации нельзя не упомянуть про Kubernetes. Подскажите, когда компании стоит по-настоящему задуматься о его внедрении?
Это довольно сложный вопрос и порождает достаточно много обсуждений в индустрии. К примеру, в больших компаниях только начинают приходить к пониманию, насколько он может упростить все процессы, связанные с жизненным циклом приложений. Особенно в их масштабах когда речь может идти о сотне или тысяче различных сервисов. Недостаточно просто иметь Kubernetes, важно, чтобы приложения умели хорошо работать в контейнеризованной среде, сейчас это называется cloud-native приложениями. Нужно понимать, что при наличии 10 микросервисов Kubernetes добавит еще несколько десятков. Мне кажется, весь хайп, связанный с ним, уже прошёл, и маленькие компании постепенно осознают, что бремя поддержки кластера не стоит всех связанных с ним затрат.
Вы успели поработать и в больших компаниях, и в стартапах. Можете рассказать, в чём отличия в культуре разработки и взаимодействия между командами?
В действительно маленьких компаниях все делают всё. Когда вы начинаете работать в компании из 30–50 человек, DevOps возникает почти естественным образом. Разработчикам приходится взаимодействовать друг с другом, потому что нет исторических знаний. По мере роста компании становится важно внедрять автоматизацию в каждый аспект, и наступает момент, когда фокус внимания на надёжности и клиентах становится более важным, чем предоставление новой функциональности в продукте.
Также нужно понимать, что стартапы прежде всего сосредоточены на разработке, ориентированной на прибыль и привлечение новых пользователей, потому что обычно у них есть некоторое финансирование и определенное количество денег, чтобы разработать какой-то продукт или сделать proof-of-concept. Поэтому им нужно либо показать, что они достойны получать больше денег, либо стать прибыльными. На начальном этапе, вероятнее всего, вы не сможете позволить себе выделенного инженера. По сути, это и не нужно: небольшое количество пользователей не заставит волноваться о таких вещах как надежность и доступность продукта.
Говоря о будущем IT, утверждает, что "DevOps-специалисты нужны будут всем", а значит, ещё не поздно начать развиваться в этом направлении и стать востребованным специалистом.
