Выпуск №34 — DevOps и Full Stack

Не так давно я принял участие в записи подкаста Девшахта, выпуск 45, с темой «Когда фронтендер становится девопс». Но некоторые вопросы и мысли, которыми хотел бы поделиться, остались за кадром: про понимание термина «DevOps» и может ли Full Stack разработчик быть эффективным?

https://soundcloud.com/devschacht/devschacht-45
https://ru.wikipedia.org/wiki/DevOps
https://ru.atlassian.com/devops

Не так давно я принял участие в записи подкаста Девшахта, выпуск 45, с темой «Когда фронтендер становится девопс».
Немного про фронтенд и немного про DevOps. Но некоторые вопросы и мысли, которыми хотел бы поделиться, остались за кадром.

Про DevOps.

Разные люди вкладывают в этот термин разные смыслы.
Давайте посмотрим, что написано в Wikipedia. Несколько коротких выдержек:
DevOps (акроним от англ. development и operations) — набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга.

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

Термин «DevOps» был популяризован серией встреч «DevOps Days», которые начали проходить в 2009 году в Бельгии.

Иными словами: «DevOps» — это набор практик, некая философия и методология, подкреплённые инструментами автоматизации. Но DevOps — это не специальность и не должность человека. Не название отдела. И вовсе не Continues Integration сервер в облаке.

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

Более того, такая народная трансформация термина DevOps стала на столько широко применимой, что иногда выходит реальная практическая польза. Приведу хороший фрагмент из обсуждения в телеграм канале @devops_ru:

В последние пару лет созрели куча годных продуктов для CI, CD, контейнеров, оркестрации и вот это все. Конторам оказался нужен админ, который умеет настраивать именно это, а не apache/squid/почту/win/принтеры/сервера таскать. Услышали слово девопс, вписали в вакансию — нашли нужного человека, профит. Остальные подхватили. И всем наплевать, что это еще и методология/философия/…

Это мне напоминает историю со словом Ксерокс, которым частенько называют любую копировальную машину, но формально не верно, но всем понятно.

Вторая тема для этого небольшого выпуска подкаста: вопрос о Full Stack разработчиках.

Может ли Full Stack разработчик быть эффективным? Ведь приходится знать много и в разных областях: и фронтенд писать и бэкенд, и всё это в Docker заворачивать а потом ещё как-то осмысленно выбирать куда деплоить: в Amazon Elastic Container Service, в Amazon Fargate или по старинке вручную поставить Docker демон на виртуалки? А может ну его этот Docker, да здравствуют лямбды и Serverless? Короче, вопросов много.

Но тут для приведу такую аналогию: представим себе чемпиона мира по триатлону (это вид спорта, где бегут, плывут и едут на велосипеде). Может ли он соревноваться в беге с чемпионом мира по бегу? А в плавании с чемпионом мира по плаванию? Спортсмен сосредоточенный на конкретном виде спорта, думаю, победит. Но обесценивает ли это триатлон и его чемпионов в наших глазах? Они тоже круты, они тоже заслуживают уважения! Причём, крутой триатлонист и в беге и в плавании и в велогонке даст фору любителю или начинающему бегуну, пловцу или велосипедисту.

Но исходный вопрос был не про уважение или какую-то оценку в глазах профессионального сообщества, а про эффективность.

Эффективность — это отношение полезного результата к затраченным ресурсам. Может ли Full Stack разработчик быть эффективным? Смотря в какой ситуации. Зависит от проекта, от конкретного бизнеса.

Если делаем большой продукт большой командой, например, почтовый сервис Gmail — нам нужна целая куча специалистов в разных областях, и по фронтенду и по бэкенду и по безопасности и по производительности (отдельно по производительности фронтенда и бэкенда, соответственно) и специалисты по поиску и антиспаму и много кого ещё. В данном случае профессионалы сосредоточенные на своей области будут более эффективны, чем абстрактные Full Stack разработчики.

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

Короче, на рынке труда востребованы все. Как узкие специалисты, так и разработчики с широкого профиля. Как Senior разработчики, так и Middle и Junior разработчики. Нельзя в общем случае утверждать, что одни эффективнее других, всё по обстоятельствам, в каждом конкретном случае, в каждом конкретном проекте, в каждом конкретном бизнесе.

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

А как завещает нам философия DevOps — понимание смежных областей и интеграция рабочих процессов разных отделов ещё и помогает выпускать продукты быстрее и качественнее.

Так что всем развития и успехов, чем бы вы не занимались — фронтендом, бэкендом или всем сразу!

Источник: 5minphp.ru

 

5 минутка PHP

Подкаст о PHP, DBA, архитектуре, DevOps. Авторское мнение о современных трендах в веб-разработке и интересные беседы с гостями. Помимо PHP поднимаем темы про инфраструктуру, администрирование Linux и DevOps подходы, сравниваем PHP с другими языками программирования, например с Go, Rust и даже Erlang.

Добавить комментарий

%d такие блоггеры, как: