Пара моих замечаний о тенденциях в IT в этом году.⁠⁠

В прошлом посте мне высказали что я решил постить свои мысли не на том ресурсе. Тем не менее сам пост не заминусили, а значит народу эта тема интересна. Тем более я не собираюсь писать тут туториалы "как накатить свой первый Debian и ворваться в мир красноглазиков" (c) @LegendNeverDie76 :)

Пафосная картинка из интернетов прилагается)

Примерно с середины весны, всё лето и по сей день, мой профиль на linkedin атакуют всевозможные рекрутеры. Из чего можно сделать два вывода, что IT отрасль у нас на подъёме, и, как сказал мне мой брат, люди наконец поняли что пора строить правильную инфраструктуру :) Что не может не радовать.
В общем, я походил по собеседованиям(в одной фирме даже пришлось пройти полиграф, незабываемые впечатления:) и данным постом хочу поделиться своими выводами. Возможно кому-то мой пост покажется очередным капитанством, а возможно поможет определиться в каком направлении развиваться дальше.

Но сперва, я хотел бы подвести итог по предложениям с linkedin и их географии.
Более 50% предложенных мне вакансий предполагали переезд. По большей части в восточную Европу: Польша, Чехия, Прибалтика. Единичные предложения в Шотландию, Кипр и Сингапур. Пара предложений с переездом в Питер. При этом большая часть всех предложений исходила от российских компаний, в том числе с предложениями переезда.
Естественно, не все вакансии подходили мне и не всем работодателям подходил я.

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

Картинка для наглядности:

Если говорить о микросервисах, то логичным продолжением этого вопроса является, как эти микросервсисы разворачивать, как ими управлять и масштабировать.
На данный момент, чаще всего, выбирают контейнеризацию, такую как Docker, LXC, rkt и системы управления кластерами контейнеров, такие как Kubernetes, основанный на нём OpenShift и, наверное в меньшей степени, Mesos Marathon.
Хоть я сам и скептически отношусь к повсеместной контейнеризации, считаю что не нужно создавать лишние прослойки там где они не обязательны, но есть области, где контейнеры вполне к месту. Например, в случаях когда требуется быстрое, горизонтальное масштабирование каких-то сервисов. Например, при повышении нагрузки на сервис, автоматически увеличить количество контейнеров с обработчиками запросов, при уменьшении так же сократить. Или, если хочется протестировать какой-то продукт, не захламляя им и его зависимостями свою машину.

Каждый проект, с представителями которого я общался, отличался языком разработки и подходами. Где-то это полностью web, где-то это числодробилки на кластерах с GPU и тэрабайтными хранилищами. Но все они хотят чтобы их код было легко собирать и выкатывать на тестовый стенд для проверки, желательно по каждому коммиту в хранилище кода. Чтобы так же легко было обновлять код на "боевой системе" и самое главное, чтобы его было легко откатить в случае возникающих проблем. В том числе откатывать изменения в базе данных.

Это то, что называют Continuous Delivery или непрерывная поставка ПО, и это основное, но не единственное, ради чего люди хотят в штат деовпса или инженера автоматизации.

Continuous Delivery тесно завязано на системы непрерывной интеграции, коих большое множество, лично я работаю с Gitlab CI и Jenkins. Которые, в свою очередь, являются частью процесса разработки ПО и дополняют друг друга с системами управления конфигурациями, такими как Puppet, Chef, Ansible, Saltstack. Сам я давно использую Ansible и немного Puppet.

Но об этих продуктах в следующий раз)

P.S. Я понимаю что для не подготовленного человека эти все термины как "птичий язык", но я старался писать наиболее понятно.