#books #computerscience
Вот, кстати, крутая книжка по сабжу. Не профессор Фортран, конечно, но тоже интересно)

...И большие, и маленькие компании применяли методологию «аджайла» и «скрама», позволившую некомпетентным менеджерам дисциплинировать и контролировать инженеров, чью работу они не способны ни выполнить самостоятельно, ни оценить...
Виладж, аххаха, прекрати

Выложили доклады с SeleniumConf 2019 - Tokyo

https://www.youtube.com/playlist?list=PLItJNH7uWaWDm7saQ9xXDYn4msTARDI-M

Тут чет опять начался холивар про то, что DevOps -- просто хайп и это просто очередной алиас для одмена(как и sre). Щас может обидно будет, так что заранее сорян.
Кароч мое мнение, что парни правы. DevOps и SRE по большому счету просто позволило поменять тайтл в резюме и хайпануть на конфах и медиуме, но, основная телега в том, что подкачала не идея, а реализация. Проблема была изначально такая: большая часть operations не очень понимала чем они собственно оперируют. Они не знали(да и не очень интересовались) тем как их софт работает, как он должен работать, какие есть проблемы и как их можно порешать. Все это традиционно летело через забор на сторону разрабов, которые тоже были не очень в восторге от такого jira-пинг-понга. В итоге парни посидели, подумали и решили, что тикета а-ля поменять входные параметры в коде, что-то выкинуть в конфиг, подружить софт с CI и другие консерны operations к софту может реализовывать сам operations.
Google пошли дальше и решили отдать (почти)все НФТ на откуп специальной команде(sre).
Понятно, что для успешного решения таких задач не достаточно просто админских компетенций и нужно еще и уметь в разработку в той или иной степени. Упрощая все до нельзя получаем:
Админ + codding skills = DevOps
Админ + software development skills = SRE

Но т.к. это толком нигде не формализовано, то просеять тех кто реально нужен кампании среди админов почти невозможная задача. Мы частично решили ее, добавив в вакансию пункт а-ля "знание одного из менстримовых ЯП на уровне Junior". Кол-во откликов уменьшилось в разы, но и шлаковых собеседований стало сильно меньше(хозяюшке на заметку)

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

Но вчера небезызвестный @SinTeZoiD скинул в группу ссылку на совместный подкаст с LinkMeUp, где обсуждали такие животрепещущие темы, как Kubernetes, Docker, DevOps и SRE. Шел 2019-ый год.

За 3 часа подкаста (я успел приготовить ужин, съесть ужин, переварить ужин, помыть посуду и узнать внезапно, что Service Mesh это хипстерский Enterprise Service Bus (Миша, серьезно?)), ближе уже к концу начался настоящий замес - почему DevOps инженеров не существует.

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

Если вы в индустрии уже достаточно давно и следите за трендами, которые задают смузихлебы из креативных коворкингов, то вы знаете, что DevOps расшифровывается очень просто: Development and Operations. Такой расшифровки достаточно, чтобы все понять.

Отсюда же появляется осознание, что DevOps инженеров не может быть в природе. Если мы берем за правило, что DevOps это культура, то откуда возьмется Культура Инженер?

Если же мы берем простой акроним, то тем более не может быть Разработка и Операции инженер.

Топящие за существование DevOps инженеров любят применять следующий прием: дескать DevOps инженер занимается настройкой работы CI/CD (кто тогда Release Engineer?), работать и настраивать Kubernetes/Mesos/Nomad (кто тогда системный администратор?) и работать напрямую с разработкой (а кто этим занимался раньше?).

Не ведитесь на это. Существование DevOps инженеров обусловлено лишь тем, что вместе с культурой пришел набор практик, а за набором практик пришел инструментарий. Ищущие DevOps инженеров, на самом деле ищут специалистов, которые знают этот инструментарий.

Что мешает текущему персоналу освоить этот инструментарий - для меня загадка.

А вот и альтернативная точка зрения

Крутая статья про Code Complexity. Особенно шикарна метафора с парадоксом Зенона

Тут статья подъехала про будущее и эволюцию atomic design от изобретателя сабжа: http://bradfrost.com/blog/post/extending-atomic-design/

Observability на конкретном примере одного проекта https://dzone.com/articles/microservices-observability - очень доступно #observability #tracing #msa

#sql
Должен признаться, что я очень не люблю Sql Server(да-да, ниосилятора пост). За долгие годы работы с ним скопилось много претензий: тут и неработающие хинты и наркоманские уровни изоляций, убогий MVCC и еще куча всего. Перечислять можно долго, но в топе, безусловно, params sniffing! Кто не в курсе скуль сервер строит план вызова хранимой процедуры опираясь на предыдущее выполнение. И его не очень волнует, что параметры могли поменяться и план, соответственно, было бы не плохо подкорректировать.
Для тех кто тоже страдает, вот цикл статей почему так и как с этим жить: https://www.brentozar.com/sql/parameter-sniffing/

ELK + syslog http://devconnected.com/monitoring-linux-logs-with-kibana-and-rsyslog/ #elk #syslog

И третья точка зрения на девОпс(и все разные)! Коллекция растет)

Не пользы ради, а флейма для

Хм, я всегда считал, что девопсы это такие ж разрабы(омг), просто дальше от фич приложения и пользователей(поэтому больше скилов администва, ведь работаю около инфры).

А пихать все в одну должность - прост грузить сотрудников.
(Комбо с названием канала отлично доставляет)

Конечно все зависит от размера фирмы и навыков разрабов. Хотя и тут можно много мегабайт текста наспорить.

https://news.1rj.ru/str/overtimehate/489
(Там след пост - инициатор темы)

(Если скучно - можете мне в свои отношение высказать-выплакать @olegkovalov)

#coroutines #java
Еще один крутой видос про асинхронщину и детерменизм, на этот раз в java: https://youtu.be/9vupFNsND6o

k14s — тулсет для работы с Kubernetes от Pivotal (нейминг от бога)

Включает в себя:
- ytt — утилиту для YAML темлпейтов
- kbld — утилиту для сборки образов
- kapp — утилиту для деплоя приложений

+ в статье есть пример с хеллоуворлдом

#kubernetes

#k8s
Еще одна деплой-тулза для k8s. Интересна тем, что в отличие от хельма умеет не сносить приложения которых нет в "umbrella-чарте"(только обновлять указанные). Для хельма нам пришлось для этого навернуть целую систему костылей. И еще это не один большой комбайн, а набор single purpose утилит. Кароч я бы присмотрелся.

Production readiness

Советы от инженера Google Cloud на что стоит обратить внимание при запуске нового сервиса в продакшен.

https://jbd.dev/prod-readiness

https://medium.com/google-cloud/production-guideline-9d5d10c8f1e

#dotnet #mongodb
Как-то так повелось, что мы активно используем монгу(и любим ее всем сердцем). У монги есть 2 api. Не вдаваясь в детали, первое покрывает большинство кейсов по выборке документов и все CUD-операции, второе, а именно, aggregation framework, нужно для аналитических выборок и прочих сложных "селектов"(еще есть map-reduce, но это отдельная история). Исторически считается, что AF тормозит и предпочтение всегда отдавалось первому api.
Тут как-то выдалась свободная минутка и я полез разобраться как же в c# драйвере парни linq в монго-запросы транслируют и ушел с неприятным, но довольно логичным, инсайтом: linq транслируется в af-пайплайн. Вроде бы можно и закончить на этом, но чет меня дернуло сходить в коммьюнити с вопросом че щас по перфомансу af. Кароч, парни, щас движок AF сильно потюнили(курсоры-то всегда были одни и те же) и, если для простых выборок выигрыш у простого api еще какой-то есть, то более сложные запросы и удобнее и быстрее делать через AF
Кстати, если кто не знал, в вики монги на гитхабе много статей про кишки