Чем занимается облачный разработчик и как им стать

Михаил Бараблин

директор практики облачных решений AT Consulting

Рынок облачных решений ежегодно растёт, а вместе с ним растёт и спрос на облачных специалистов, которые специализируются на построении и обслуживании виртуальной инфраструктуры. Я работаю с облачными технологиями уже 11 лет и все эти годы даже в среде разработчиков (особенно среди джунов) сталкиваюсь со стереотипом – «ой, да что там делать, развернул и пошёл». В реальности всё намного сложнее и увлекательнее. В этой статье я расскажу, чем на самом деле занимаются облачные айтишники и какие навыки им требуются.

Как все думают, что это устроено

Облака и всё, что с ними связано, окружены множеством стереотипов. Считается, что работать с ними легко, стоят они дешево, а после развёртывания всё само каким-то волшебным образом масштабируется. В сознании начинающих разработчиков такие проекты не выдерживают конкуренции с модными трендами типа нейросетей или голосовых помощников – облака кажутся чем-то очевидным и скучным.

Вот наиболее часто встречающиеся ложные утверждения про облака: они волшебно надёжные, работают всегда и сами по себе; не требуют больших затрат; можно поменять облачного провайдера в любой момент; о безопасности можно не думать – надо только применять шифрование при доступе к облачному сервису.

Как на самом деле это устроено

Мир облаков чрезвычайно богат разнообразными технологическими инструментами: контейнеры, средства автоматизации инфраструктуры, распределённые хранилища и базы данных, виртуальные сети и файерволы и многое другое. Участнику облачного проекта недостаточно знаний только одного или двух языков программирования или одного средства тестирования: от инженеров здесь ждут более широкого кругозора. При этом все современные продукты очень быстро обновляются, новые фичи появляются каждый месяц, каждые полгода выходят большие релизы. За этой гонкой нужно внимательно следить, чтобы эффективно использовать инструменты в работе и строить оптимальные архитектуры.

Ниже краткое описание того, что на самом деле происходит в облачном мире.

Надёжность

Мир облаков – это мир микросервисов и распараллеливания нагрузки, то есть все приложения пишутся как совокупность маленьких сервисов, которые можно запускать в любом количестве для обслуживания нужного числа пользователей. На словах выглядит легко, а на практике надо понимать, как работают распределённые системы, как организовать параллельную и отложенную обработку запросов, как организовать передачу сообщений между частями приложения, как осуществлять балансировку нагрузки между всеми запущенными элементами, как автоматически запускать и останавливать сервисы при росте нагрузки или сбоях инфраструктуры.

Масштабируемость

Облака предоставляют много возможностей для работы с большой нагрузкой, но все эти инструменты надо уметь применять. И более того, приложения нужно создавать так, чтобы эти инструменты работали.

Затраты

Облачные проекты – это всегда про расчёт и оптимизацию затрат. Вообще, вопрос расчёта затрат на инфраструктуру и другие сервисы на облачном рынке гораздо менее прозрачный, чем в обычных проектах. За каждый использованный сервис придётся платить. Виртуальные машины, дисковые операции, трафик, операции записи в базах данных, контейнеры – все это ресурсы, которые будут стоить денег, а под нагрузкой – больших денег. Поэтому всем участникам надо на ранних стадиях проекта думать о том, как сократить расходы. Если раньше это делалось при покупке сервера и в меньшей степени зависело от разработчиков и других участников проекта, то теперь об этом приходится задумываться каждому.

Ещё одно отличие – нужно задействовать максимум возможностей оплаты только использованных ресурсов. Если можно отключить услугу ночью и работать только днём, то надо это сделать, потому что это экономит деньги. Но такой подход требует большего уровня автоматизации, чем раньше.

Провайдеры

Сейчас облачные провайдеры предоставляют широкий спектр чрезвычайно удобных инструментов. В качестве примера часто приводят AWS: даже просто прочитать список сервисов этого провайдера – уже долгое дело. Российские провайдеры тоже быстро наращивают перечни услуг. Конечно, при создании приложения удобно использовать такие гибкие инструменты, но со временем возникает риск того, что приложение нужно будет перенести на мощности другого провайдера или развернуть на собственной инфраструктуре. Это может стать большой или даже не решаемой в разумные сроки проблемой. Даже похожие сервисы у разных провайдеров реализованы по-разному, не говоря уже об отличиях в перечне услуг. При проектировании приходится соблюдать баланс и в этом разрезе – как использовать сервисы так, чтобы не оказаться зависимым от провайдера, но при этом максимизировать выгоду от облачной архитектуры.

Безопасность

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

Надо отметить, что в любом (даже простом) облачном проекте используются десятки разных инструментов, программных продуктов и облачных сервисов. На плечи инженеров контроля качества и специалистов по безопасности ложится большая работа по отслеживанию возможных ошибок, ведущих к угрозе проникновения или утечки данных. Им нужно понимать основы подходов к разработке, которые помогают уменьшить риски в области безопасности, например, DevSecOps.

Состав команды на проекте

Основное изменение в структуре команды – это появление Cloud DevOps Engineer. Он отвечает за настройку инфраструктуры для нормального функционирования программного обеспечения, оценивает среды развёртывания приложений заказчика.

В таких проектах мы работаем с Kubernetes, Ansible, Terraform, поэтому часто требуется помощь высококвалифицированных администраторов, которые будут глубоко погружены в процесс разработки. Иногда такие спецы, познавшие тайны администрирования, берут на себя часть функций DevOps. В остальном структура вполне классическая: руководитель проекта, архитектор, аналитики, разработчики, тестировщики.

Если в проекте используется стороннее облачное решение, то состав команды дополняется специалистом по конкретному облачному продукту, например VMware, или даже командой со стороны провайдера. В таком случае работа технически становится проще (не нужно ничего изобретать, используем готовый продукт), но усложняется реализация – решение накладывает ограничения на то, как его можно использовать.

Что нужно знать, чтобы стать облачным разработчиком?

Так или иначе, большая часть разработки связана с предоставлением сервисов через облако – это можно назвать мейнстримом разработки. До облачной «лихорадки» IT-проект выглядел так: написали программу, купили сервер или несколько, установили программу на сервер, подключили интернет и работаем, всё что дальше – эксплуатация. Такие классические проекты постепенно становятся редкостью либо относятся к специализированным областям из разряда программирования микроконтроллеров или САПР.

Если вы облачный разработчик, то вот с чем, скорее всего, вам придётся столкнуться в работе:

• вы пишете веб-приложение, руководствуясь концепцией наподобие 12 factor app;
• вы разрабатываете микросервисы, то есть весь ваш проект разделён на небольшие приложения, работающие параллельно и запускаемые в любом количестве;
• ваш микросервис может запускаться множество раз параллельно, и вызовы функций выполняются в любой последовательности;
• вы должны сделать всё, чтобы ваше приложение было максимально stateless;
• информация, приходящая в ваше приложение, может быть неполной, пришедшей не вовремя или вообще сфабрикованной злоумышленником;
• информация между сервисами может не дойти до адресата;
• вы взаимодействуете с множеством сервисов по различным API, часто сервисы вам не отвечают или недоступны;
• часто используются очереди сообщений и другие виды асинхронного взаимодействия, в общем случае все задачи в смежных сервисах выполнятся когда-то во времени, а не прямо сейчас.

Основываясь на этом описании типичных задач и проблем разработчика, я могу выделить следующие области знаний, которые вам очень пригодятся, если вы решите попробовать силы в таком проекте:

• умение работать с API;
• навыки системного администрирования, понимание концепций CI/CD;
• умение работать с контейнерами;
• понимание микросервисной архитектуры;
• знание паттернов разработки для отложенной обработки задач.

Сейчас есть бесконечное множество способов получить знания: даже беглый поиск по запросу «книги/курсы + облачные системы/масштабирование систем/DevOps, DevSecOps» даст тысячи результатов. Из книг могу выделить Ивана Портянкина «Программирование Cloud Native. Микросервисы, Docker и Kubernetes» – отлично подойдёт начинающим. Затем можно продолжить книгой Ли Атчисона «Масштабирование приложений. Выращивание сложных систем» – это уже более основательное произведение.

Не забывайте про Coursera, я рекомендую три курса: Continuous Delivery & DevOps (The University of Virginia), Cloud Computing Concepts, Part 1 (The University of Illinois at Urbana-Champaign), Cloud Computing Security (The University of Colorado).

Для тренировки вы можете просто взять облако любого из провайдеров (лучше российского, так как это более актуально для нашего рынка) – «Яндекс.Облако», Mail.Ru Cloud Solutions, Selectel, «Ростелеком» – и с помощью его инструментов попробовать развернуть небольшой сайт, взяв за основу какую-либо CMS. Задачка со звёздочкой: написать набор скриптов, которые будут заказывать виртуальные машины и разворачивать сайт автоматически в выбранном облаке. Такое упражнение даст много очков на любом собеседовании.

Чему можно научиться на облачных проектах?

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

Работа с облачными технологиями неизбежно приведёт вас к росту экспертизы в автоматизации, CI/CD (непрерывная интеграция и доставка), к росту знаний конкретных облачных продуктов, в части решения интеграционных задач.

Обычно новички приходят на какую-то из этих должностей – разработчик, системный администратор, тестировщик – и начинают изучать одну из областей ремесла. Чем быстрее человек расширяет кругозор в смежных областях, тем быстрее идёт профессиональный рост. Например, разработчик Java может начать с доработки некоторых функций в конкретно выбранных местах исходного кода проекта. Постепенно разработчик учится работать с базами данных, реализовывать API, запускать Java-приложения в контейнерах и на серверах, создавать автотесты, автоматизировать развёртывание в Jenkins или Gitlab CI и т. д. Постепенно можно стать старшим разработчиком и впоследствии архитектором.

Те специалисты, у которых хорошо получается общаться с заказчиками систем, могут вырасти в руководителей команд или проектов. Но без сильной технической базы руководить облачными проектами невозможно.

Где работать – у вендора или интегратора?

Облачные разработчики, как и любые другие, по разные стороны отвечают за разные аспекты одного и того же.

Разработчик на стороне вендора решает задачи по развитию продукта: ищет способы оптимизировать алгоритмы и сделать его лучше от версии к версии. Часто для этого нужны узкоспециализированные знания, понимание архитектуры ПО конкретной компании. Другими словами, рост на стороне вендора обычно идёт в сторону узкой специализации и часто медленнее, чем на стороне интегратора. Но и темп работы обычно более спокойный.

Разработчик интегратора решает комплексные задачи заказчика при помощи своего кода и облачных сервисов – для этого ему нужен широкий кругозор и знание продуктов разных вендоров. На таких проектах часто приходится мыслить нестандартно и уметь быть гибким, подстраиваться под изменения условий задачи и смену архитектуры.