Какой именно архитектор? их несколько, у всех чёткая функция

Например golang software architect...

Это как Ruby On Rails Software Architect ? :)

Хз, если в рубях нужно понимать как раскидать проект по папкам, то почему-бы и нет? 😁

В общем если разраб понимает что нет единого шаблона как раскидать по папкам, он уже архитект? :)

Ну, паттерны знает и хватит. 😁

Софтваре акитект это что-то из мира монолитов

Или микросервисов. Тот бородатый дядька который понимает как оно все вместе работает как правило. Когда нужен кубер а когда не нужен и тп

Это уже не софтваре, а клауд архитект

А если в ИС часть в облаке а часть на железе?

Вы путаете облачного провайдера и облако

Часть системы в GCP другая часть на Селектеле на железе. Облачный провайдер тут Goolge, облако здесь GCP. Как в данном случае зовется архитект который понимает всю систему?

Облачный архитектор

По моей информации это подмножество в рамках профессии Software Architect

Нет, потому что это взаимодействие микросервисов, баз данных, очередей и т.д. это про инфраструктуру, а не про код. Так что обычно это люди с SRE-бекграундом

Значит у нас разные источники информации о предмете. Не говоря уже о том, что SRE бэкграунд есть только у SRE инженеров, а SRE инженеры есть только в Google.

Кубер, опенстэк и т. д. 😁

Не только

Прочтение 2 книг об SRE и применение оттуда частичных рекомандаций на выбор не считается. Но если считается тогда безусловно не только.

Я говорю SRE не только в гугле есть

Зависит от определения того что такое SRE. Называться можно конечно кем угодно, но это не всегда соответсвует реальности. В IT таких примеров куча

Существует вполне конкретное определение SRE

Какое?

Почему только?

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

https://sre.google/sre-book/preface/ со второго абзаца

Мое допущение. Формально не верное. Но нормальные SRE мне кажется они или выходцы из Google или работают там на соотв. позиции. Просто потому что термин оттуда пошел и сам подход. Те кто учился у первоисточника и создателя зачастую более компетентны imho

Не очень формальное определение я бы сказал

Есть короче: SRE is what you get when you treat operations as if it’s a software problem.

Но есть несколько книг с описанием подходов и опыта

Да, и если подход внедрен, там есть SRE, если на пол шишечки, нету :) imho конечно же

Как минимум по ссылке такого нет и префаза там немного другую конструкцию описывает все же

Дело в том, что копипаста 1-в-1 как минимум вредна :)

https://sre.google первая строка после заголовка :)

А потом смотрим на вакансии Гугла и видим что типов два - syseng и swe и оба sre

Чтобы что-то сделать свое, сначала неплохо скопипастить (приобретя при этом опыт и понимание принципов). Дальше можно уже адаптировать и что-то добавлять, а другое выбрасывать. Копипаста частично чего-то не имея опыта вредна еще больше imho. Т.е. опыта нет, целостного понимания проблемы и решения нет, но мы сразу изобратем свой велосипед хватая рандомную инфу по верхам.

Если пособеседоваться в гугл, то набор на вакансии состоит из двух tracks: SWE и SysOps. Эти два разных трека существуют, чтобы брать людей и с Ops и c SWE экспириенсом. В итоге, после буткемпов и всех тренингов уровень оказывается примерно одинаков

Тоже спорный вопрос :)

Тоже не совсем так

Спорный, но примеров фейлов кажется больше чем примеров успехов. Можно конечно переизобрести колесо особо не вникая, но как правило получится так себе. А чтобы сделать прорыв, лучше сначала изучить и попробовать то что уже есть.

Что именно не совсем так?

Про причины существования такого разделения

Мне так объясняли во время буткемпа. ¯\_(ツ)_/¯

Ты сейчас в Гугле работаешь?

Нет, боженька уберег.

Ну это вопрос вкусовщины, уберёг или нет :) Но разница некоторая есть, пусть и зависит от команды. Но про это достаточно мало информации в публичном доступе (по сути кроме того что разница есть я ничего не встречал)

В зависимости от команды разница есть в любой большой организации, будь то GOOG, AMZN, MSFT, YNDX, SBER

Ну вот да.

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