Отчет о состоянии DevOps в России 2020

Компания Экспресс 42, совместно с конференциями Олега Бунина (Онтико), провели первое исследование состояния DevOps в России. Мы давно вынашивали эту идею, так как понимали, что исследования других компаний не дают ответов на вопросы, как DevOps развивается у нас в России. 

В течении августа 2020 мы опросили 889 специалистов и руководителей из разных регионов, отраслей и компаний.  В результате получили срез по текущему состоянию инженерных практик и инструментов, проверили гипотезы, как DevOps влияет на производительность и показатели компаний, сравнили результаты с предыдущими исследованиями, выявили тренды развития.

В отчете за 2020 год вы узнаете про следующие темы:

1. Использование ключевых DevOps метрик;
2. Сравнение ключевых метрик с показателями эффективности компаний;
3. Планы компаний на следующий год;
4. Популярные DevOps инструменты;
5. Применение DevOps практик:
1. Платформа как сервис;
2. Инфраструктура как код;
3. Непрерывная поставка и интеграция;
6. Как внедрять и развивать DevOps практики и инструменты;
7. Как связаны Agile и DevOps.
 

Скачайте отчет о состоянии DevOps в России 2020 прямо сейчас!

Набрел в ФБ на еще одну дискуссию о том, нужен ли корпоративный архитектор и, в случае положительного ответа, зачем он нужен. И в который раз наивно удивился тому, что в таких разговорах речь всегда идет о каких-то очень абстрактных предприятиях. Даже отраслевая принадлежность не дает ответа на вопрос: впишется ли в текущее устройство конкретной компании функция корпоративной архитектуры, есть ли зазор между реализациями других capabilities для архитектуры предприятия, есть ли потребности, не закрываемые имеющими функциональными подразделениями. Можно чётко обрисовать место архитектуры на business capabilities map: между операциями и стратегией, чуть в стороне от ИТ и неподалеку от основных заказчиков. А вот наличие потребности и возможности в том, чтоб занять это место, да еще и в данный конкретный момент времени – свойство каждого частного случая

Подарок для методиста https://microservice-api-patterns.org/ Обратите внимание на вводное слайд-шоу в верхнем правом углу

Или же многобукв для тех, кому это нравится https://microservice-api-patterns.org/introduction

Поясню почему я задал вопрос относительно этой книжки. На мой взгляд, в наше время недостаточно актуализирована тема моделирования данных. DDD подходит для разработчиков, но вряд ли годится для аналитиков и тем более специалистов предметной области. Они, если и принимают участие в сессия типа Event Storming, то делают это, как-бы вслепую. Отвечают на вопросы разработчиков, но не строят собственную и самодостаточную модель предметной области. Неявно предполагается, что она у них уже есть. Но даже в тех предметках, где наличие такой модели декларируется на поверку оказывается, что это не так. Не работают предметники с BDW, BIAN, SID и пр. за редким исключением. Раньше предполагалось, что старательный заказчик должен сесть и с помощь грамотного аналитика нарисовать UML диаграмму классов или модель сущность-связь. Реально, если кто-то этим и занимался, то высокооплачиваемые консультанты с весьма условным знанием предметной области, но большими понтами и голословными заявлениями о том, что модель у них есть. Сегодня роль данных стала ещё выше, а вовлеченность предметников в игру со стрелочками и квадратиками еще меньше. В общем, хочется иметь простую историю для людей из-за границы ИТ или же наших пограничников о том, как моделировать данные в конце второй декады XXI века

Возможно, аргументация автора статьи покажется вам банальной (мне она такой показалась), но нельзя не согласиться с тем, что бессерверные вычисления подбуксовывают https://www.infoq.com/articles/serverless-stalled/ Да и вообще, если функция вызывается крайне редко, можно и без разного рода платформ отдельный процесс застартовать (было же ведь так во времена CGI), а если не так уж и редко, то держите запущенный микросервис

Талант Кента Бека - автора экстремального программирования (XP), заключается в формулировании едва осознаваемых вещей понятными и простыми словами. Его очередная заметка: https://medium.com/@kentbeck_7670/monolith-services-theory-practice-617e4546a879

Гартнеровский Hype Cycle по архитектуре предприятия от сентября 2020 https://www.gartner.com/doc/reprints?id=1-24EE6K3G&ct=201019&st=sb&fbclid=IwAR3fOfPWeRNf10dyrHdIVCFYfvtg_hJaIjkFel4QBYMLIRNcSFYvyxlCFoA

Вот всё у нас так. Если API, то без спецификации в Open API, но зато с толстыми документами, в которых написано
(Цитата из одного из стандартов: 2.3 Принципы архитектуры. Архитектура среды Открытых банковских интерфейсов соответствует концепции RESTful ... В случаях, когда следование принципам RESTful является сложным,
принципы не соблюдаются. )
http://www.cbr.ru/press/event/?id=8223

PS. А вот и первоисточник: https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/read-write-data-api-profile.html

А вот эта картинка достойна отдельного консилиума с обсуждением методов излечения от UML

PS: Основная проблема этих документов не в том, что там что-то не так написано, а в том, что перед публикацией их никто не читал

Simon Brown с новой историей почему архитектурные диаграммы надо представлять как код (на придумываемом им языке описания архитектуры Structurizr DSL) https://dev.to/simonbrown/diagrams-as-code-20eo

ИТ-архитекторы люди разносторонние. Я раньше уже делился ссылкой на видео "Практика архитектурного проектирования ИТ решений" с YouTube-канала Евгения Никонорова - активного участника наших архитектурных обсуждений. С того времени у него появилось несколько роликов-размышлений и потому сегодня поделюсь ссылкой на сам канал https://www.youtube.com/channel/UC0fCSuasoxqJHoMSsZ-IHUg

А здесь у нас второй день проходит анонимный опрос о зарплатах ИТ-архитекторов: https://tttttt.me/itarchitect/72733

Уже послезавтра вебинар по Open Agile Architecture. Добавил ссылку на регистрацию: https://us02web.zoom.us/meeting/register/tZYod-2urDIvGNQM8CzEBbYnkH5rdi_stasc