Pull to refresh
96
0
Максим @maxout

Инженер DevOps

Send message

на "плоскости управления" в первом предложении пытаться читать можно заканчивать %)

Качество перевода, традиционно, взрыв мозга %)

Новосибирск, подземный паркинг сдаётся зимой за 5, летом за 3 (и то, желающих маловато). Коммуналка 1.5-2 в месяц. Окупаемость сей "инвестиции" эти вводные отодвигают на неопределённый срок :)
Какая-то инвестстратегия возможна, если приобретать паркоместа скопом на стадии котлована / со скидками / впридачу к квартирам, чтобы их во-первых было много (читай как возможность влиять на формирование стоимости аренды), а во-вторых снизить первоначальную стоимость (получить хоть сколько-нибудь приемлемый срок окупаемости)

смешались в кучу кони, люди, ноды, узлы и поды.

подумал, может и в оригинале сумбур, но нет, там всё нормально.

читайте оригинал :)

Актуально ещё и для геймеров, которые подумали "Игровые 4к видюха не тянет, но всё равно возьму 4k монитор и в винде буду сидеть в нативном, а в полноэкранных играх включать FullHD, будет масштабироваться 2 к 1 по красоте".

Не будет.

На самом деле это конечно дичь дикая, вся ситуация с "умными" скалерами. По сути адекватное скалирование сейчас есть только у Eve, который ещё попробуй купи в РФ.. Мне мой едет уже месяца три и не факт что приедет в этом году. А альтернатив нет.

А где в очередь-то вставать? Или уже поздно?

Справедливости ради, reg.ru ведёт себя точно так же, занимаясь по сути вымогательством. Я даже несколько раз перечитывал пост, чтобы убедиться, точно ли руцентр :) Потому что ситуация с регру повторяет вышеописанную практически слово в слово.

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

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

но при этом нельзя сказать, что расчёт некорректный, как пытается представить автор поста.

вот здесь человек расписал ВСË, добавить уже нечего https://habr.com/ru/company/itsoft/blog/569098/comments/#comment_23287912

вот здесь человек расписал ВСË, добавить уже нечего https://habr.com/ru/company/itsoft/blog/569098/comments/#comment_23287912

как по мне, так в ипотеке там просто меньшие суммы страховок/комиссий. "нечестность" калькулятора только в том, что он не разбивает платёж на проценты и доп.платежи.

Все платежи одинаковые. Это ваша придумка про последний платёж. Если платежи разные, то это уже дифференцированные платежи.

вы хоть раз брали кредит? )

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

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

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

если учесть стоимость услуг, процент за пользование кредитом вырастёт, а процентная ставка по кредиту - нет.

это вам уже несколько раз в комментах пытались объяснить, и я потерпел неудачу как и все остальные)

мне кажется, в договоре всё будет по вашему сценарию, как всегда и было. либо там в этих 70к участвуют страховки/комиссии и в калькуляторе это опять же реализовано в угоду простоте формы, а в договоре будет расписано математически верно.

что не отменяет, конечно, несомненное зло в виде всяких страховок и комиссий

вы заплатите 193504.

вы хоть в одном банке из опробованных видели посчитанный график платежей, а не форму калькулятора с одним числом?

последний платеж всегда меньше ежемесячного, это очевидно, и никому наверное даже в голову не приходило писать в калькуляторе "ежемесячный платёж 263759р, а вот в последний месяц 193504!!"

вряд ли нужно родиться до 1930 года.
вероятнее всего триггер на начале эпохи, то есть 1970 год, когда unix timestamp становится отрицательным. и в переводе отрицательного timestamp в человекочитаемую дату скорее всего и зарыта собака в Safari.
да, ещё забыл, если вы в своём приложении имеете разветвлённые зависимости от сторонних чартов или контейнеров с докерхаба — тушите свет :)
перепиливать самостоятельно придётся 90% оных.
если изначально на это закладываться, то не так страшно.
как минимум, не запускать контейнеры под root, не использовать в контейнерах привилегированные порты, заложиться на разнообразие ingress-контроллеров, не использовать volume с типом emptyDir, корректно работать с limits/requests.
если соблюдать эти базовые вещи, то переточить приложение под ограничения (их может быть много самых извращённых, и опеншифт этому потакает :)) конкретной большой конторы — будет уже сильно проще. ну и это всё больше про крупные приложения, если у вас в чарте десяток файликов и пара-тройка контейнеров, то переход делается за день
так что, если планируется выкат в openshift, будет очень разумно либо разрабатывать сразу под него (на бесплатном okd), либо накрутить все полиси на ванильном k8s максимально близко к опеншифту.
И вопрос по теме: если мы будем делать проект в нормальном кубере и толкнем его большой конторе — оно у них там заработает без возни?


нет, нет и ещё раз нет. переход с ванильного k8s на openshift лежит через страдания, как devops, так и разработчиков.

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity

Specialization

DevOps
Senior
Kubernetes
AWS