Вроде как отдельную команду(ы) эксплуатации девопс не запрещает, различия с классикой — области ответственности с командой разработки пересекаются и качество коммуникаций выше.
Где об этом упоминается в презентациях об облаках для бизнеса? Наоборот продвигается мысль, что разберётся чуть ли не ребёнок со всем — администраторов можно вообще разогнать.
Очень не очевидная семантика — что в условии-то инициализировать обычно? Особенно без скобок, без определения области "видимости". Всегда воспринимал ее просто как два оператора, пускай и странных каких-то и писал их нормально, даже исправляя IDE, чтобы не вызывать у коллег, читающих мой код, это чувство странности. Ну да, с таким необходимым количеством if'ов без этого совсем плохо было бы. Хотя в большей части туториалов оно не употребляется, как и половине, наверное, кодовых баз куда я заглядывал
Я не представляю, что еще можно автоматизировать с помощью ЯП.
Сложные выгрузки и/или конвертации данных, работу с АПИ провайдеров типа облачных для создания и связи ресурсов, триггерные события типа получения смс или звонка по телефону на модем и их обработка
Очень разное понимание есть кто такой девопс и в чём его функции. Один раз встречал, что девы пишут код и манифесты для него, админы пишут плэйбуки и манифесты для инфры, а девопс коммитит и в репы девов, и в админов, чтобы код и манифесты первых работал на инфре вторых, принимая решения где пойти навстречу девам, а где админам, а где адаптер какой-то написать.
Как-то это не ясно из статьи. Да и термин "ошибка уровня Pro" какой-то расплывчатый. Будет ли ошибкой уровня Pro решение использовать имеющийся NFS, если на предложение купить пару-тройку серверов бизнес ответил отказом, сделав уточнение в SLA что файлы там могут быть недоступны сутки например?
P.S. Увидел апдейт, в общем ситуация кажется "как не сделать ошибок при неограниченных бюджетах"
Я больше не про docker-compose, а про docker swarm, а его логика к куберовской ближе.
А насчёт придётся доделывать, указывать и создавать — от задач зависит. Если в кубер переехали потому что "сворм умер" или "нам надо в облако, а там только кубер", а не за его фичами, то "придётся доделывать" плавно трансформируется в "захочется доделывать, но придётся бизнес убедить выделить на это дополнительные ресурсы"
Я к тому, что у меня впечатление, что Go неплох для задач типа "перекладывать json из http в amqp и обратно", но плох для "определение кредитного лимита на основании анкеты заемщика" или "учёт материальных активов"
Бизнесу в маркетинговых материалов облаков не объясняют же что им нужно разогнать существующую команду и набрать новую, с опытом в облаках. Админам что, им сказали переехать, они EC2 нашли, подобрали по характеристикам аналогичное имеющемуся, подняли, связали, в мир выставили, задеплоили, потестили — тормозит, потому что скорость дискового ио зависит от объёма — увеличили диски — работает, можно в прод.
Или просто не влезают в кубернетес )
А попробуйте забить на эффективность — может и другая логика обозначится
Ну как не отличаются, если аргументов не один? То, что одно можно привести к эквивалентному второму, не говорит о том, что отличий нет.
Вроде как отдельную команду(ы) эксплуатации девопс не запрещает, различия с классикой — области ответственности с командой разработки пересекаются и качество коммуникаций выше.
Не технологий, а практик. Практики не только и не столько в технологиях заключаются.
Где об этом упоминается в презентациях об облаках для бизнеса? Наоборот продвигается мысль, что разберётся чуть ли не ребёнок со всем — администраторов можно вообще разогнать.
Очень не очевидная семантика — что в условии-то инициализировать обычно? Особенно без скобок, без определения области "видимости". Всегда воспринимал ее просто как два оператора, пускай и странных каких-то и писал их нормально, даже исправляя IDE, чтобы не вызывать у коллег, читающих мой код, это чувство странности. Ну да, с таким необходимым количеством if'ов без этого совсем плохо было бы. Хотя в большей части туториалов оно не употребляется, как и половине, наверное, кодовых баз куда я заглядывал
Сложные выгрузки и/или конвертации данных, работу с АПИ провайдеров типа облачных для создания и связи ресурсов, триггерные события типа получения смс или звонка по телефону на модем и их обработка
Задача может быть написать "GoMyAdmin" )
Я про орган человеческий ) Его сломать можно, читая мой комментарий )
И это при том, что в математике функция нескольких аргументов вполне себе first class citizen.
Там ключевое "без опыта"
Ещё и два оператора в строке… Разрешено в принципе или для этого конкретного случая в строгом встроенном линтере Go исключение?
Очень разное понимание есть кто такой девопс и в чём его функции. Один раз встречал, что девы пишут код и манифесты для него, админы пишут плэйбуки и манифесты для инфры, а девопс коммитит и в репы девов, и в админов, чтобы код и манифесты первых работал на инфре вторых, принимая решения где пойти навстречу девам, а где админам, а где адаптер какой-то написать.
Возможно ещё для multi tenant
Как-то это не ясно из статьи. Да и термин "ошибка уровня Pro" какой-то расплывчатый. Будет ли ошибкой уровня Pro решение использовать имеющийся NFS, если на предложение купить пару-тройку серверов бизнес ответил отказом, сделав уточнение в SLA что файлы там могут быть недоступны сутки например?
P.S. Увидел апдейт, в общем ситуация кажется "как не сделать ошибок при неограниченных бюджетах"
А код пишут разработчики обычно...
Я больше не про docker-compose, а про docker swarm, а его логика к куберовской ближе.
А насчёт придётся доделывать, указывать и создавать — от задач зависит. Если в кубер переехали потому что "сворм умер" или "нам надо в облако, а там только кубер", а не за его фичами, то "придётся доделывать" плавно трансформируется в "захочется доделывать, но придётся бизнес убедить выделить на это дополнительные ресурсы"
А сколько лет надо читать Go код, чтоб мозг начал фильтровать if err != nil блоки через каждую значимую строку логики? )
Я к тому, что у меня впечатление, что Go неплох для задач типа "перекладывать json из http в amqp и обратно", но плох для "определение кредитного лимита на основании анкеты заемщика" или "учёт материальных активов"
Бизнесу в маркетинговых материалов облаков не объясняют же что им нужно разогнать существующую команду и набрать новую, с опытом в облаках. Админам что, им сказали переехать, они EC2 нашли, подобрали по характеристикам аналогичное имеющемуся, подняли, связали, в мир выставили, задеплоили, потестили — тормозит, потому что скорость дискового ио зависит от объёма — увеличили диски — работает, можно в прод.