![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
System administrators considered harmful
Nov. 11th, 2021 09:19 pmНе Дийкстра я ни разу, но хоть примажусь.
В 2016 году к нам прибежал наш внутренний идеолог Амазона и заявил, что еще полгода, и админы будут не нужны. Мы его обсмеяли, а он сейчас большой начальник; я вообще не понимаю, как он сделал карьеру на завале двух эпических проектов, продолбавших шести-, если не семизначную сумму, но вот поэтому он Бенцион Крик, а у меня в душе осень.
Ну кагбе пять лет прошло, воз миграции в Амазон и ныне там, хотя есть шанс, что он с непередаваемым скрипом таки поедет если не в этом, так в начале следующего года.
Но я не об этом. Амазон продвигает свой концепт, что надо убрать undifferentiated heavy lifting и сосредоточиться на бизнес-логике. Естественно, за помянутый heavy lifting надо немного отстегнуть Амазону, что логично. И опять же, суть не в этом, а суть в том, что разработчик в кои-то веки можно полностью контролировать стек. И это прямо-таки офигенно.
Вот я подумал за свой приклад. Да, там, конечно, внизу сервер, пицот лет конфигурять. А если вдуматься, то докерфайл будет не такой и развесистый, особливо если его собирать поэтажно, как доктор прописал. И если у меня есть докер-инфраструктура, которую не я собираю (AWS ECS/Fargate, EKS), то на докерфайле заканчивается моя зона ответственности и начинается зона... сервис-провайдера.
То же самое со всякими файрволами и балансерами (в кубиках это контролируется прямо из кубиков, в ванильном AWS - хоть терраформом, хоть CloudFormation). То же самое даже с мониторилками и логособиралками и далее по тексту.
База... ну формально я к этому постгресу рутовый доступ имею. В реальности катаешь миграции, смотришь диагностику и все такое, так что можно сказать, что и постгрес мне сгодится "как сервис". Туда же пойдет и модный редис, и любые Kafka/RabbitMQ и так далее.
То есть суть в том, что граница ответственности разраба почти везде сомкнулась с границей ответственности сервис-провайдера. Для админа, который жил как раз между этими границами, места нет. Окей, скажете вы, но ведь все эти жабаскрипт-мидлы и решетка-сеньоры ни черта не понимают в архитектуре. Ну, во-первых, понимают порой очень немало, во-вторых, можно вспомнить, что во времена оны человек, подозрительно похожий на современных SRE, назывался системным программистом и на сисопа или админа мог заслуженно оскорбиться.
Конечно, тут можно сказать, что cloud is just other people's servers, но суть в том, что в этом самом Амазоне, к примеру, классической админской работы, мне думается, мало. А за пределами Больших и Толстых провайдеров, мне думается, грядет плавное вымирание мелких и тонких.
Короче, то ли товарисч реально зрил в корень, то ли это был тот самый случай, когда стоящие часы правильное время показывают. Ну и надо понимать, что при всей своей апокалиптичности прогноз очень длинный. Классические админы за 50, а то и за 40, могут успеть уйти на пенсию до того, как прозвонит колокол. А вот тем, кто помоложе, как мне кажется, надо вспомнить про необходимость, которая понимающего ведет, а непонимающего тащит.
В 2016 году к нам прибежал наш внутренний идеолог Амазона и заявил, что еще полгода, и админы будут не нужны. Мы его обсмеяли, а он сейчас большой начальник; я вообще не понимаю, как он сделал карьеру на завале двух эпических проектов, продолбавших шести-, если не семизначную сумму, но вот поэтому он Бенцион Крик, а у меня в душе осень.
Ну кагбе пять лет прошло, воз миграции в Амазон и ныне там, хотя есть шанс, что он с непередаваемым скрипом таки поедет если не в этом, так в начале следующего года.
Но я не об этом. Амазон продвигает свой концепт, что надо убрать undifferentiated heavy lifting и сосредоточиться на бизнес-логике. Естественно, за помянутый heavy lifting надо немного отстегнуть Амазону, что логично. И опять же, суть не в этом, а суть в том, что разработчик в кои-то веки можно полностью контролировать стек. И это прямо-таки офигенно.
Вот я подумал за свой приклад. Да, там, конечно, внизу сервер, пицот лет конфигурять. А если вдуматься, то докерфайл будет не такой и развесистый, особливо если его собирать поэтажно, как доктор прописал. И если у меня есть докер-инфраструктура, которую не я собираю (AWS ECS/Fargate, EKS), то на докерфайле заканчивается моя зона ответственности и начинается зона... сервис-провайдера.
То же самое со всякими файрволами и балансерами (в кубиках это контролируется прямо из кубиков, в ванильном AWS - хоть терраформом, хоть CloudFormation). То же самое даже с мониторилками и логособиралками и далее по тексту.
База... ну формально я к этому постгресу рутовый доступ имею. В реальности катаешь миграции, смотришь диагностику и все такое, так что можно сказать, что и постгрес мне сгодится "как сервис". Туда же пойдет и модный редис, и любые Kafka/RabbitMQ и так далее.
То есть суть в том, что граница ответственности разраба почти везде сомкнулась с границей ответственности сервис-провайдера. Для админа, который жил как раз между этими границами, места нет. Окей, скажете вы, но ведь все эти жабаскрипт-мидлы и решетка-сеньоры ни черта не понимают в архитектуре. Ну, во-первых, понимают порой очень немало, во-вторых, можно вспомнить, что во времена оны человек, подозрительно похожий на современных SRE, назывался системным программистом и на сисопа или админа мог заслуженно оскорбиться.
Конечно, тут можно сказать, что cloud is just other people's servers, но суть в том, что в этом самом Амазоне, к примеру, классической админской работы, мне думается, мало. А за пределами Больших и Толстых провайдеров, мне думается, грядет плавное вымирание мелких и тонких.
Короче, то ли товарисч реально зрил в корень, то ли это был тот самый случай, когда стоящие часы правильное время показывают. Ну и надо понимать, что при всей своей апокалиптичности прогноз очень длинный. Классические админы за 50, а то и за 40, могут успеть уйти на пенсию до того, как прозвонит колокол. А вот тем, кто помоложе, как мне кажется, надо вспомнить про необходимость, которая понимающего ведет, а непонимающего тащит.
