Зарегистрировался на митап по Куберу в Амстердаме.

Цитирую название: Update from KubeCon Seattle & Management DC/OS & k8s & 70+ ways to deploy k8s.
Более 70 способов развернуть Куберенетес. Семидесяти, Карл!

Что мне нравится в современной open source тусовке - каждый имеет возможность придумать что-то свое. Что-то, что решает проблемы предшественника или расширяет его возможности.

Что не нравится - 70 разных (наверное) способов сделать одно и то же.

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

Год подходит к концу, и в ближайшие пару недель я не буду выходить на связь. После ожидайте еще одну серию длиннопостов, про жизнь в НЛ.

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

Во-первых про сам канал. Очень маленький круг людей знает, что я забросил канал в начале года из-за личных обстоятельств. Эти обстоятельства все еще со мной, и я не знаю сколько времени мне предстоит, чтобы дойти до стадии принятия.
Тем не менее спасибо моим друзьям и близким, что несут эту ношу. Я знаю, что других ударило гораздо сильнее, чем меня.
Отдельное спасибо тусовочке Дежурного DevOps’а, группе DevOps Moscow и в частности @servers , за то что мотивировал меня писать и дальше. Я начал этот год с 20 подписчиками, и для меня это взрывной рост.

Во-вторых, спасибо @count0ru , @SinTeZoiD , @mo1seev за веселые посиделки в Москве и за то, что приоткрыли мне дверь в мир увлекательных дивапс мемасиков (и за то, что методично и профессионально поджигают мою архитекторскую задницу).

В-третьих, спасибо @stekov_me за титаническую работу над сообществом aws_ru. Жду дальнейших продвижений в развитии школы и сообщества. Ты знаешь, что я всегда готов помочь.

В-четвертых, спасибо говорливому архитектору и его твиттеровской тусовке за то, что открыли мне не менее увлекательный мир беснующихся ИТ-пенсионеров. Всегда занятно взглянуть на “ту” сторону.

В-пятых, спасибо моим ученикам за терпение. Я знаю, что порой у меня скверный характер.

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

Всех с наступающим Новым Годом!

Теперь, когда каникулы закончились, можно вернуться в обычное русло.
Я все еще “отдыхаю” от ИТ (в частности, изучаю и коплю материал для дальнейшего постинга в канал), так что давайте расскажу о такой страшной штуке, как покупка дома/квартиры в Нидерландах.

В определенный момент человек, достаточно долго живущий за бугром, начинает задумываться о покупке жилья. Ипотечная ставка низкая до неприличия (до 3% максимум), а покупка даже ультра-дорогой квартиры все еще дешевле аренды. (За квартиру стоимостью в 350 000 евро, вы будете платить около 1300-1400 евро в месяц, в то время как аренда на севере Нидерландов стартует от 1500 (без коммуналки и налогов)).

Но отбросим математику и предположим, что человек решился купить жилье. Купить он его сможет, только прожив в стране хотя бы год (до года банки даже разговаривать не хотят) и имея на накопительном счету минимум 10 000 евро. Эти расходы далеко не на первоначальный взнос (его в Нидерландах пока не ввели), но на покрытие “трансферных” расходов - оплату ипотечных услуг (около 2к евро), налог на передачу имущества (2% от стоимости дома), оценщика, нотариуса, агента по недвижимости (если есть) и прочее.

Вариантов покупки два: либо покупаем проект (очень дорого), либо ищем вторичку. Те, кто обладает свободной покупательской способностью, берут жилье сразу в новых проектах (там ценник начинается в большинстве от полумиллиона евро), ну а просто люд умножает свою годовую зарплату до налогов на 5 (максимальная сумма ипотеки) и идет искать вторичку на Funda.

Итак, вы определились с районом, где хотите жить, прикинули приблизительно свой бюджет, скопили денег и пошли выбирать квартиру. Открываете Funda, находите полюбившийся вариант (ух ты, там есть полы!), звоните маклеру… и слышите, что дом уже продан. Смотрите на сайте - выложен в продажу неделю назад. Ок.

Сразу скажу, что информация на Фунде обновляется с огромным лагом, так что если уж решили обзавестись недвижимостью в стране тюльпанов, то сразу фильтруйте дома, выложенные более чем 10 дней назад. Они уже “проданы” с вероятностью в 80%, но даже если вы найдете квартиру, которую за месяц никто не купил, отнеситесь к этому с подозрением - благодаря тоннам британских мигрантов, квартиры в НЛ распродаются как пирожки, а низкая ставка стимулирует людей покупать квартиры пачками, чтобы сдавать их экспатам втридорога (Покупаем халупу за 200 с лишним килоевро (ипотека будет макс. 900 евро в месяц), впихиваем туда мебель из икеи, дешевый ламинат, оставляем кухню и ванную комнату как есть и сдаем за 1.5к евро, профит).

ОК, нашли квартиру, которая все еще доступна к просмотрам. Связались с агентом, назначили встречу, приехали смотреть, понравилось, отправили предложение по покупке (по цене, что на сайте), через 3 дня получаете письмо от маклера, что квартира продана другому.

Пожали плечами (не очень-то она вам и понравилась, да?), нашли другой вариант, приехали, сделали предложение, через 3 дня снова отказ.
Спустя пару-тройку “проигранных” предложений спрашиваете у знакомых и друзей, почему так?

Оказывается большинство цен, которые вы видите на сайтах покупки недвиги показывают “стартовую” цену, от которой и надо делать предложение.
То есть, если цена квартиры 250к евро, и вы сделали предложение на 250к евро, то всегда есть тот, кто сделал предложение за 260к. Или 270… Или вообще 300.

У моих знакомых были ситуации, когда за дома предлагали больше 20% СВЕРХ изначальной цены (речь шла о домах по 300к евро), причем некоторые делали предложение за “нал” (то есть им не нужна ипотека, деньги есть). На некоторые дома продавцы получали от 30 до 75 предложений о покупке, а в других кейсах “приоритет” по продаже давался покупателям от знакомых агентов.

Так что вдоволь намучившись с поисками сами, вы решаете нанять агента (который будет стоить от 1500 до 4000 евро).

Нанимать агента стоит именно в том регионе, где он “работает”. То есть, если вы хотите купить квартиру в Хаарлеме, то нанимайте агента оттуда, хотя бы потому что у него в Хаарлеме много “друзей”, и он может показать вам варианты, которые еще не попали на Фунду, а то и в принципе договориться с продающей стороной и закрыть сделку втихую. Ну и готовьтесь предлагать минимум 10-15к сверх цены.

Вообще, могу сказать, что сколько бы ни стоил агент, его ценник в большинстве случаев реально оправдан. Лучше отдать 3 килоевро спустя 3-4 месяца (столько в среднем уходит с момента, как вы начали искать квартиру, до момента, когда вам отдали ключи), чем мотать себе нервы и брать отгулы, чтобы делать по 2-3 просмотра квартир в день.

Другое дело ипотечные офисы. Когда время наступит, ни в коем случае не идите в конторы типа expat mortgages - эти вурдалаки берут за свои услуги в 2-3 раза больше, чем маленькие конторки где-нибудь в Schagen’е (жопа мира, так вам скажу), а надбавка только за то, что у них сайт на английском.

Когда вы таки “выигрываете” сделку (то есть вас “выбрали” в качестве покупателя), с нее все еще можно соскочить.
Не смотря на то, что отосланные письма и устные переговоры имеют юридическую силу, до момента подписи предварительного договора купли-продажи ни вы, ни продавец ничего друг другу не должны.

Мало того, по закону у вас есть 3 рабочих дня (или 5, точно не скажу), на cooldown - типа переспать с мыслью, подумать хорошенько, и, если что, соскочить.
Но вот после этого соскочить можно будет только в случае, если не было одобрено финансирование (и это при том условии, что вы открыто говорите, что будете брать дом в ипотеку). Ежели вы, весь из себя такой распальцованный, сказали, что ипотека вам не нужна (и все равно за ней пошли, так тоже можно), а банк вам дал от ворот поворот, то вы попадаете на неустойку в 10% от сделки. Точно так же попадает продавец, если в какой-то момент передумал продавать дом.
Откуда берется гарантия, что участники сделки не киданут друг друга? В игру вступает страшное существо под названием Нотариус.

Нотариус не только следит за законностью сделки (чтобы вам, например, не продали заложенное или арестованное имущество), но и выступает арбитром и проводит все платежи со всеми контр-агентами, проверяет документы, включая идентификацию людей по обе стороны сделки, платежеспособность и прочее.
Когда предварительная сделка подписана, а вы обиваете пороги ипотечников, нотариус попросит вас предоставит сумму в 10% от сделки, из которой потом и будут произведены все выплаты по налогам и прочим расходам. Если такой суммы у вас не завалялось, то покупается банковская гарантия (стоит около 200 евро) - дескать, банк за вас “вписался”.
Продавцу в этом плане немного проще, его “гарантией” выступает само имущество. Так что, продавец, срывая сделку с большой долей вероятности либо потеряет дом, либо наскребет неустойку.

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

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

Что также удобно - все контрагенты (маклеры с обеих сторон, нотариус, ипотечный консультант, банк) общаются между собой и в вас вообще не нуждаются. Это на самом деле очень круто.

Финалом будет встреча у нотариуса. До этого вы в последний раз приезжаете в квартиру/дом не в качестве владельца, проводите “финальную инспекцию”, снимаете показатели счетчиков, и едете к нотариусу.
На встрече нотариус чуть больше часа зачитывает акт передачи имущества вслух, переводчик (а он обязан быть по закону, если вы иностранец) переводит его слова на приятный вашему уху язык, вы (покупатель) ждете не дождетесь, когда получите ключи, а продавец ждет не дождется, пока получит денежки (хотя он получит их неделей позже, когда внесутся изменения в кадастр).

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

Можно долго рассказывать про нюансы покупки недвижимости, но пора бы уже вернутся в основную тематику.

Сегодня в меню - «прохладные» истории.

Миф 1, мой самый любимый: «Покупаем мощности у AWS, облако-шмоблако, можно увольнять сетевика.»
Этот миф часто толкают малограмотные амазонщики-консультанты (таких можно встретить на Youtube) или, того хуже, разработчики, знающие компьютерные сети чуть меньше, чем никак.

Амазон забирает у вас необходимость обладать опытом тонкой настройки сетевого оборудования - настраивать вам никто ничего не даст - но в «ядре» вашей инфраструктуры (VPC) есть очень много тонких моментов, таких как организация подсетей, маршрутизации между ними, NACL и Security Groups, VPN, VPC peering и коммуникации между endpoint’ами ваших VPC (а если у вас большой проект, у вас как минимум 4-5 VPC).

Тот, кто считает, что все это делается за 5 минут в пару кликов, ничего сложнее default VPC, с NACL’ами в настройках по умолчанию, SG с правилами на входящий порт с 0.0.0.0/0 и маршрутизацией в WAN через IGW и NAT GW не делал (А в амазоновской тусовке и за меньше бьют).

Я уже не говорю про troubleshooting сети, когда вроде все настроено правильно, а приложение начинает тупить.

Все это может и не требует сетевиков уровня CCIE, но не нивелирует их полезность.

Если в вашей конторе есть адепты «да че там делать, пару кликов»: гоните их, насмехайтесь над ними.

Коллегам-сетевикам, которые в соцсетях ноют, что “тупые амазонщики забирают их хлеб, ололо, девопс говно, нихрена не понимают в ИТ, петушары, лузеры”, тоже незачем бояться за свою работу.

Во-первых, AWS подходит очень малому количеству бизнесов хотя бы из-за требований законодательства и инфобеза.
Во-вторых, кто-то же строит ЦОДы Амазона м других облачных провайдеров.
В-третьих, есть целый пласт бизнесов, таких как CDN, интернет и хостинг провайдеры - там тоже все свое и этим надо управлять.

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

DocumentDB - на мой взгляд лучший бизнес-лещ, который Амазон отвесил open-source коммьюнити.

А вы, должно быть, думаете, что я Амазон только хвалить умею.

Работаю сейчас с Fargate. Задача: собрать CFN-стек с необходимыми ресурсами (кластер, task definition, сервисы, балансировщик и прочее), а также настроить CI/CD под это дело.
Работы на самом деле не то, чтобы много -  на сам стек у меня ушло где-то часа полтора + минут 40 чтобы настроить pipeline. Веселье началось, когда я начал продумывать, как мне подавать TaskDefinition template ECS’у.
Вариантов тут два: либо ставить и использовать ecs-cli, либо awscli. Не желая тратить время на первое, я пошел “проверенным” путем.

TaskDefinition template - JSON-документ в котором описываются параметры контейнеров (которых может быть больше одного), а также параметры самого task, т.е. роли, кол-во ЦПУ и памяти, конфигурация сети и прочее.

Первое, на что поругался awscli, были null значения ключей. Например в healthcheck.

Invalid type for parameter containerDefinitions[0].healthCheck, value: None, type: <type 'NoneType'>, valid types: <type 'dict'>

Если вы в документе прописываете ключ, но не присваиваете ему значение (т.е. null), то валидатор поругается. Он ожидает увидеть строку, число, список или словарь, но никак не null. Делаем ход конем и подсовываем “пустые” значения (например “hostname”: “”).

Дальше круче - пошла ругань на то, что параметры аутентификации для Docker репозитория несовместимы с ECR репозиториями, и это при том, что в repositoryCredentials.credentialsParameter у меня была пустая строка).
Ну и совсем мясо - при использовании “networkMode”: “awsvpc” (которого кстати в документации CFN нету, есть только host и bridge) и ключа “hostname” Амазон снова поругается на несовместимость этих двух параметров.

An error occurred (ClientException) when calling the RegisterTaskDefinition operation: hostname is not supported on container when networkMode=awsvpc.

Каким же сюрпризом для меня стало то, что подавая параметры в шаблоне, register-task-definition автоматом пытается применить все ключи, даже если их значения пусты. (DCOS к примеру будет игнорировать ключ с пустым значением).
Валидатор это дело пропускает, он проверяет только тип данных в значениях, и ругаться начнет только API, получив некорректный шаблон.

Решение было простым до неприличия - удаление ключей из шаблона.

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

Впрочем, не мне судить разработчиков AWS, особенно учитывая те скотские (на основе отзывов в интернетах) условия, в которых они работают (https://www.nytimes.com/2015/08/16/technology/inside-amazon-wrestling-big-ideas-in-a-bruising-workplace.html).

Когда посидел в крипто- и ит- твиттере.

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

Если вкратце - встал вопрос о создании внутреннего dedicated tenancy для наших Tier 1 клиентов.
Что это означает: у каждого клиента будет свой экземпляр базы данных, набор приложений, и возможно даже инфраструктура (отдельный кластер Fargate, VPC и т.д.).

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

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

Однако ответ на мой любимый вопрос “Какую проблему мы решаем?” поверг меня в ступор.
Оказывается, лид хочется застраховаться от ошибки разработчика, где из-за неправильного where в SQL запросе, клиент может получить доступ к данным, относящимся к другому клиенту.

Человеческий фактор в наше время это, конечно, бич (если не bitch). Вне зависимости от вашего опыта, вы можете руками и глазами в мыле наделать таких дел, что восстановление будет настолько болезненным, что вы задумаетесь о смене профессии или присоединении к FIRE (https://www.investopedia.com/terms/f/financial-independence-retire-early-fire.asp).
За примерами и далеко ходить не надо: чего стоят Gitlab (https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/) и AWS S3 (https://aws.amazon.com/message/41926/)

Во избежание таких ситуаций в индустрии присутствуют такие прекрасные практики как Code Review, Pull request, Pair programming (тут я лукавлю, применение этой практики немного иное конечно).
Но нет, мы будем решать проблему топорно - ты не вытащишь чужие данные, есл в базе их нет.
О том, как деградируют компетенции разработчиков и понизится качество разработки продукта, я даже думать не хочу.

Я уже молчу про то, что даже работая с изолированными окружениями можно накосячить. Что если я (тот кто пишет стек CFN) опечатаюсь в url базы и направлю приложение клиента 1 в базу клиента 2?

Читаю сейчас «Теорию игр» за авторством Авинаша Диксита и Барри Нейлбаффа.

В конце первой главы читателю предлагается ответить на вопрос, выбрав один из 5 вариантов ответа.
Есть только одна загвоздка - самого вопроса нет, есть только варианты, и читателю нужно определить правильный, руководствуясь Теорией Игр.

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

Впрочем, оставим философию в стороне. Ожидайте пост на тему так называемого Foundation и способов его реализации с помощью Infra-as-Code.

По поводу вот этого (https://news.1rj.ru/str/manandthemachine/380) дабы не возникало мыслей, что я очередной ИТшник, который все на свете знает и окружен некомпетентными управленцами.

У каждой коммерческой компании есть т.н. Миссия. Миссия коммерческой компании - заработать как можно больше денег (либо для самой компании, либо для акционеров).

Если предположить, что у вас утопическая контора, производящая некий продукт, то может быть как по книжке.

Например, поставили себе цель - продать миллион единиц товара. В таком случае, топ-менеджер по продажам поставит себе целью найти клиентов под миллион товара, топ-менеджер по производству - произвести миллион товара, топ-менеджер по ИТ - обеспечить ИС под это дело, директор по человеческим ресурсам - нанять необходимое количество людей, логист - отгрузить этот миллион товара, ну и так далее.

В реальности же дела обстоят немного иначе, в дело идет бессмысленная политика, директора по производству подкупил откатами поставщик материалов, у директора по HR дополнительно стоит цель держать счетчик FTE (full time employee) как можно ниже, а у ИТ директора еще есть цель снизить косты на свой “домен”, директора по продажам так вообще “поставили”, потому что он чей-то родственник или тренер по единоборствам.
Отсюда и идут все эти байки про “некомпетентный менеджмент”, о которых все знают, но предпочитают не говорить открыто.

Конечно, так не везде. У некоторых контор целью стоит не рост прибыли, но рост компании как таковой (этим особенно страдают стартапы, финансируемые венчурными фондами), то есть нужно сделать компанию как можно “дороже”, чтобы потом ее по максимальной цене толкнуть.

Но какими бы ни были root cause’ы, в итоге мы имеем то, что имеем. “Сделайте нам круто.”

ОК, по поводу Foundation - оно же Основа, Фундамент, называйте, как хотите (далее Ф.).

Само понятие Foundation существовало задолго до появления и популяризации облачных вычислений.
Отличие в том, что помимо сетевой и серверной инфраструктуры, нужно было также проектировать и строить ЦОДы, продумывать в них вентиляцию, электричество, резервы и прочее. В публичных же облаках нужно “всего-лишь” правильно организовать структуру ресурсов, а так же политику управления оными.

Надо понимать, что фундаментом это все называется неспроста - ошибись вы в самом начале, вы рискуете заработать целый ворох проблем и технического долга, от которого вас спасет только катарсис.
Именно поэтому Ф. занимает львиную долю человеческих ресурсов и нуждается в доскональном проектировании. Дело тут даже не правильно организации VPC и сетевого стека - нужно обеспечить грамотное управление доступом, разбивку ресурсов по аккаунтам и взаимодействие между ними, а также “песочницу” для нужд разработчиков.

Если вы проектируете Ф. в облаке Амазона, советую ознакомиться с материалом Well Architected Framework (https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf) - это поможет разобраться со структурой как будущей инфраструктуры, так и приложений.

Причем тут, спрашивается, Infra-as-Code? Когда вы создаете ресурсы через GUI консоль, Амазон под капотом создает разный набор ресурсов, о которых вы не знаете.
К примеру создавая ALB, вы создаете следующие ресурсы: сам балансировщик, listener, правила listener, target group’ы, объединяете их между собой.
Если создаются managed ресурсы (типа SQS, SNS) то с ними же создаются IAM роли, необходимые для их работы.

Делая все это через консоль, вы рискуете наплодить много мусора и не приобретаете понимания, как устроены сервисы в AWS’е и связи между ними.

Более того, допустим, вы создали Ф. через консоль. Руками прописали тэги, создали аккаунты и группы ресурсов для учета расходов и разграничения доступов. В момент когда вы захотите использовать IaC инструменты (например Cloudformation или Terraform), вам придется ссылаться на физические идентификаторы ресурсов.
И если в Terraform есть оператор data, который вытащит необходимые метаданные из существующих ресурсов, то в Cloudformation придется декларировать эти ссылки вручную, прописывая их в параметрах или вообще hardcoded (что приведет не очень неприятным последствиям, когда вы начнете дорабатывать Ф.).

Во избежание всего этого, имеет смысл задействовать IaC сразу на старте, применяя best practices в виде Pull Request’ов, Code Review и CI/CD с правилами Linter’а и каким-либо тестированием. Заодно идеально опишете, что именно вы создаете и как вы это связываете между собой.
Тут же вы ответите на много вопросов, таких как: держать ли управление конфигурацией на текущем инструменте (Salt, Ansible, Puppet, etc.) или делать инфраструктуру целиком иммутабельной и декларативной, зашивая все настройки в CFN/TF; разворачивать приложения через IaC или только ресурсы; и т.д.

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

В ответ на это - https://news.1rj.ru/str/catops/945

Посмотрите вот этот прекрасный доклад: https://www.youtube.com/watch?v=kSGiUGGu1aQ

Uptime ваших приложений и систем принадлежит вам, а не хостинг провайдеру.

На обеде с коллегой обсуждали годовые цели для нашего департамента (их выполнение прямо влияет на бонус).

Из года в год цели выставляются практически одинаковые. Две основные - uptime (в многочисленных девятках) и список “фич”, которые мы должны “доставить”.
Не смотря на то, что цели выставляются по модели S.M.A.R.T., они не всегда таковыми являются. Я не хочу вдаваться в подробности внутренней кухни - просто приметим, что достижение обеих целей (uptime и feature delivery) одновременно практически невозможно, либо требует титанического труда всех департаментов (бизнесовых в том числе).

На выходе имеем, что наш департамент либо “доставит” нужное количество “фич” (которые в течение года могут, конечно же, меняться, ведь у нас “Agile”), либо бросит бОльшую часть сил на добавление лишней девятки в наш uptime.
В то время, как что downtime, что разработанный функционал лишь косвенно влияют на корпоративные цели (продать товара побольше, потратить денег поменьше), а новые “фичи” носят больше внутренний характер и очень редко удовлетворяют “хотелки” больших клиентов.
Downtime же практически не влияет на наш business continuity: можно было бы приплести его к удовлетворенности клиентов, но они гораздо больше расстраиваются, вися на телефоне с техподдержкой, нежели когда наш money printer отрабатывает транзакции с часовой задержкой. Ну а бизнес-системы созданы таким образом, что их падение на недлительный срок никак не влияет на доход фирмы.

О чем нам стоит волноваться совсем не uptime, но RPO (recovery point objective). “Лежащая” база - нестрашно. “Лежащая” база, потерявшая транзакций на сутки - вот это это уже проблема. Но таких целей нам не ставят.

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

Поступок Splunk Inc. низок и бьет в первую очередь по доверию к большинству западных вендоров (если это доверие вообще осталось).
Так же глупо, как выход некоторых азиатских компаний с европейского рынка из-за GDPR.

Чем разобраться в вопросе и найти решение - включаем “РКН” и лочим все подряд.

Добавим к этому, что некоторые ИТ продукты русского производства на порядок лучше заграничных конкурентов (русский инженер всегда сильнее, не забываем) и просто ждем, пока крупнякам типа Яндекса и ко надоест монополизировать сектор России и СНГ и захочется двинуться “налево” по географической карте.

Вопрос не 10 лет, но тем не менее огорчает, как ИТ управленцы не заглядывают чуть дальше своего годового бонуса.

Кто будет в Москве и хочет послушать много интересного про AWS - зарезервируйте время, поскольку трансляции не будет. (А вот AWS в регионе Россия обязательно будет)

DC/OS в версии 1.11 добавил поддержку Kubernetes.

Для тех кто не в курсе - DC/OS это уровень абстракции над Mesos, и в качестве контейнерной оркестрации там используется Marathon.
Разумеется, DC/OS проигрывает в битве с Kubernetes, и не важно почему: хайп, Google, you name it - причин там очень много.

Поняв, что конкурировать с кубером в поле контейнерной оркестрации нельзя, Mesosphere сделала следующее. Выпустила распрекрасный блог пост о том, что “Кубер нам не конкурент, мы вон, смотрите, даже внедрили его поддержку”. (https://mesosphere.com/blog/the-docker-vs-kubernetes-vs-apache-mesos-myth/)

Любой куберовод задастся вполне логичным вопросом: зачем мне поднимать кластер DC/OS и ставить на него Kubernetes, когда я могу сразу поставить Kubernetes? Вопрос вполне себе валидный.

В свою очередь DC/OS помимо оркестрации предлагает запуск различных сервисов. То есть непосредственно на фреймворке Mesos вы можете запустить кластер Kafka, балансировщики, ElasticSearch, Jenkins, Cassandra… Да в целом много всего. Самое смешное, что это все еще контейнеры запущенные на уровне Marathon’а, но пользователь видит их как отдельные сервисы.

Штука, на самом деле прикольная. Ну а что? Получается такой себе cloud provider на коленке. Хочешь какой-то сервис (будь он stateful или stateless) - выбери из каталога, да установи. Если его в каталоге нет, то запакуй его в “правильном” формате да и выкати. Удобно.

Вот только у Кубера есть операторы, которые (как я понял из документации) делают ровно тоже самое.
Посему вопрос остается прежним. Зачем нужен DC/OS?