Рубрика «devops» - 21

Прогресс shell-operator и addon-operator: хуки как admission webhooks, Helm 3, OpenAPI, хуки на Go и многое другое - 1

Shell-operator и addon-operatorЧитать полностью »

Читать полностью »

Мотивом для написания данной статьи послужил тот факт, что на habr.com участилось появление материалов маркетингового характера про Apache Kafka. А также тот факт, что из статей складывается впечатление что пишут их немного далекие от реального использования люди — это конечно же только впечатление, но почему-то в большинстве своем статьи обязательно содержат сравнение Apache Kafka с RabbitMQ, причем не в пользу последнего. Что самое интересное — читая подобные статьи управленцы без технического бэкграунда начинают тратить деньги на внутренние исследования, чтобы ведущие разработчики и технические директора выбрали одно из решений. Так как я очень жадный/домовитый, а также так как я сторонник тезиса "В споре НЕ рождается истина" предлагаю вам ознакомится с другим подходом — почти без сравнения разных брокеров.

Читать полностью »

Вы думаете, что выбираете технологию потому, что она подходит требованиям? Вы можете ошибаться.

Давайте начнём с примера, который, возможно, вдохновлён реальной ситуацией. Команде необходимо подобрать брокера событий. Претендента два — Kafka и Pulsar.

Разработчик А имеет значительный опыт с Kafka в реальных ситуациях. Упоминают сложность при масштабировании Kafka и поручаются Pulsar. Разработчик B — сторонник Kafka, так как технология стала стандартом индустрии и имеет сильную поддержку в целом. Но у команды мало опыта работы с ней. Оба согласны в том, что в обозримом будущем изменений рабочей нагрузки нет и два этих решения соответствуют требованиям. Но остальные члены команды не так самоуверенны.

После проведённых на встрече часов и сравнения с сеткой технических критериев пункт за пунктом команда выбрала Kafka. Все согласились с тем, что принятие этого решения вполне обоснованно, обоснование задокументировали, и команда приступила к внедрению.

Но раскрыты ли истинные мотивы выбора?

Человеческое эго и стремления — движущие силы инженерных решений - 1


Читать полностью »

Аварии как опыт #1. Как сломать два кластера ClickHouse, не уточнив один нюанс - 1

Про некоторые свои failure stories мы уже писали и раньшеЧитать полностью »

Прим. перев.: эта статья — опыт миграции на Kubernetes одного из крупнейших в Индии онлайн-магазинов продуктов. В ней Vaidik Kapoor, software engineer из Grofers, рассказывает о главных ошибках и препятствиях этого долгого путешествия, а также делится своими мыслями о целесообразности и плюсах подобного переезда в целом.

Почти два года назад мы решили отказаться от развертывания приложений на EC2 с конфигурациями, управляемыми через Ansible, и перейти к контейнеризации и оркестровке приложений с помощью Kubernetes. За это время большую часть инфраструктуры уже перенесли в Kubernetes. Миграция была сопряжена со своими вызовами: от технических, связанных с необходимостью обеспечивать работу гибридной инфраструктуры до завершения миграции, до обучения всей команды совершенно новой парадигме работы.

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

Технология Serverless: снова привет, 1970-е - 1

Я проработал с «Облаком» уже достаточно долго для того, чтобы убедиться, что ему предстоит пройти ещё долгий путь, прежде чем оно станет лучше старой доброй аренды пары серверов и запуска своего ПО на них. Сейчас в моде Serverless-решения, из-за которых у меня ощущение, что мы снова вернулись в 1970 год.

Когда-то давным-давно я притворялся, что учусь менеджменту, а на самом деле изучал кодинг на C. Наш университет находился в двух мирах: в нём существовала лаборатория с «персональными компьютерами», но в то же время имелись терминалы мини-компьютера, и в зависимости от предпочтений профессоров задания нужно было выполнять в одном из этих миров. Но обе эти системы были, по крайней мере, интерактивными и обеспечивали мгновенную обратную связь. Моему другу повезло не так сильно: на одном из курсов по технологии строительства ему дали задание, которое нужно было выполнить на Pascal и сдать в виде распечатки с университетского мейнфрейма.
Читать полностью »

Был уже вечер, когда ко мне обратился разработчик. Из мастер-ветки пропал патч — коммит deadbeef.

История потерянного коммита - 1

Мне показали доказательства: вывод двух команд. Первая из них —

 git show deadbeef 

— показывала изменения файла, назовём его Page.php. В него добавились метод canBeEdited и его использование.

А в выводе второй команды —

 git log -p Page.php 

— коммита deadbeef не было. Да и в текущей версии файла Page.php не было метода canBeEdited.

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

Как избежать гниения ПО - 1

Недавно я наткнулся на историю столь же удивительную, сколь и ужасную:

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

Написавший её человек умер уже 15 лет назад, да и ушёл из компании много десятков лет назад. Программа была не такой большой, однако оказалась непостижимой. Её писали в стиле, отдававшем приоритет вычислительной эффективности, а не простоте чтения. И, разумеется, у неё не было никаких тестов.

Как назло, днём ранее запушили изменение порядка выполнения скриптов, работающих в этом окружении. Все решили, что виновато это изменение. Инженеры откатили всё к предыдущему релизу. К сожалению, это только усугубило проблему.

Ещё одна программа, занимающаяся переводом прибыли, должна была уведомлять пользователей, что их вкладов недостаточно для прогнозирования дохода. Заметив, что из первой программы из-за её вылета нет выходных данных, она восприняла эту ситуацию как «все вклады равны 0». Разумеется, она должна была вести себя совершенно иначе. Но никто не знал, что она будет действовать так, поскольку первая программа никогда не вылетала.

Я получил от ИТ-директора неожиданное текстовое сообщение. «Простите за беспокойство, у нас огромная проблема. s1X. Можете прилететь сегодня во второй половине дня?» В их терминологии S1X обозначает «хуже, чем уровень серьёзности 1, потому что проблема распространилась на несвязанные с ней части бизнеса».

К счастью, все пенсии были спасены и история окончилась хэппи-эндом. Но нам вряд ли покажется нормальным, что критически важные финансовые системы зависят от древнего ПО, в котором не разбирается никто из ныне живущих людей.
Читать полностью »

Прим. перев.: эта небольшая статья Lin Sun из IBM в блоге CNCF — занятная иллюстрация тех сложностей, над преодолением которых сейчас трудятся инженеры популярных реализаций service mesh. С ними становится понятным, почему порог вхождения у этих продуктов остаётся довольно большим.

В августе этого года на конференции ServiceMeshCon EU мы с William Morgan из Linkerd выступили с совместным докладом под названием «Service mesh is still hard». William рассказал об инновациях в Linkerd, в то время как я затронула нововведения в Istio. Оба проекта, очевидно, активно работают над тем, чтобы упростить переход обычных пользователей на service mesh.

Service mesh — это всё ещё сложно - 1
Этот слайд (из видео с недавним выступлением William Morgan и Lin Sun) лаконично подытоживает актуальные плюсы и минусы сервисных сеток

Сегодня service mesh стали более зрелыми, чем были год или пару лет назад. Однако они по-прежнему сложны для понимания большинства пользователей.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js