Pull to refresh
108
0
Настоящее Имя @artemlight

User

Send message

просто все данные бэкапятся в BackBlaze, за 2 терабайта около 10 евро в месяц.

Xiaomi Mi 16W Portable стоит 35 евро (2200 руб), и на первый взгляд лучше примерно всем).

думается мне, что за 100к в месяц там был далеко не десяток серверов.

мы считали как-то раз стоимость только compute instance без учета затрат на обслуживание-амортизацию-итд - и гугловый клауд по стоимости был эквивалентен примерно 4 годам владения.
а для того, что они там за 100к в месяц арендуют - боюсь, что пришлось бы собственный дц в подвале строить.

Остаётся только один вопрос - а где он брал уникальные номера карт для этих аккаунтов, и каким образом он их валидировал?

У меня триал GCP не принимает даже вполне себе валидный one-time Revolut Virtual - чует, что препейд, и просит "настоящую" карту. А их не напасешься, поэтому даже второй аккаунт не дали создать - пришлось отдавать честно заработанный доллар за поиграться. Миллион же таких аккаунтов, да с верификацией карт - стоит явно дороже запрошенных 50к.

В общем, похоже на байку.

Но люди ж не в вакууме живут.

Точнее сказать - не все люди живут в вакууме.

Так никто ж не рассуждает о том, кто лучшие, а кто худшие.

ЕМНИП РФ сама заявила о том, что взаимодействие с "недружественными государствами" больше не является для неё приоритетом. Ну не является - так не является, получите распишитесь.

И к международным договорам тоже можно было бы апеллировать, если бы они не были денонсированы - сюрприз - всё той же РФ.

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

Всё же наблюдаю некоторую непоследовательность со стороны разработчиков.

Как много восторгов было на тему технологического и прочего суверенитета. И вот вполне закономерный итог - "суверенные" патчи за пределами такой юрисдикции никому не нужны и не интересны, так как попросту неприменимы.

Ну Ваш персональный опыт ничего не говорит о рынке труда в целом. А он - очень разный, и работают там люди с совершенно разными скиллами. С тем же успехом я могу рассказывать, что не знаю в bay area никого с доходом меньше, чем 300к в год - к рынку труда в США это будет примерно такое же отношение иметь.

Так что за неимением других цифр придётся верить этим.

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

Так вы сравниваете тёплое с мягким. MSSQL в продакшне - это а) ни разу не мейнстрим, market share MSSQL сервера около 15% всего (пруф), б) MS не планирует развивать это направление, упор идёт на cloud-native \ managed SQL, а onprem не растёт (с учетом инфляции - читай, падает - пруф).

А разгадка проста - нищий рынок труда. Средняя зарплата системного администратора в мск - 52 тысячи рублей (пруф), это меньше 5 долларов в час. И это в 8(!) раз меньше, чем в США (пруф), на чей рынок, собственно, и целятся крупные клауд провайдеры. Так что в среднем по больнице в РФ выгоднее нанять 10 администраторов, а в США - одного девопса и managed сервисы. Это, кстати, более-менее бьётся с моим собственным опытом.

И справедливости ради - не всё так однозначно (с). Низкая стоимость фонда оплаты труда разработчиков в РФ позволяет делать недорогие и качественные сервисы. Но формально это экстенсивный путь развития, со всеми свойственными ему ограничениями.

Я думаю, что он там не только в докере, а ещё и в виртуалке поверх этого самого докера.

Уже прошли те времена, когда виртуализация\контейнеризация оказывала какое-то существенное влияние на производительность. У докера оверхеда практически нет, у виртуализации - в пределах погрешности (а применительно к БД иногда и напротив выигрыш бывает - потому что кеширование дисковых операций работает чуть интереснее, чем на bare metal). В любом случае, жертвовать 1% производительности ради потери управляемости - нонсенс, железо стоит значительно дешевле времени людей, которые его обслуживают.

Просто гляньте, как на крупных платформах (GCP, Azure, AWS) работает Managed SQL.

Всё с DevOps в порядке. Не нужно путать макро- и микроуровень, и всё станет на свои места.

Если у Вас управление релизным циклом существует только в виде "нескольких команд cp", а в качестве среды выполнения крутится десяток (ну пускай даже сотня) виртуалок, то оно вам и в самом деле не надо.

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

Но вот есть, например, такой комплайнс - в определенном продукте нужно создавать изолированные среды для каждого заказчика, мультитенант не катит. Говоря проще - провайжнить продукт тысячами отдельных инстансов, и менеджить всё это. Скриптами будем делать, или возьмем всё же готовое?

Опять же, деливери - это всегда контейнеры. Нравится, не нравится - ну вот такое оно, сегодняшнее настоящее. Если привыкли править на проде - будет мешаться, а если выстроены процессы быстрой доставки в этот самый прод - будет помогать обеспечивать SLA.

TL;DR: как и любой другой инструмент, DevOps методологию нужно оценивать не для абстрактного, а конкретно для вашего проекта. Экстраполировать же свои проекты на других - плохое хобби.

Так вот увеличение размера пакета пропорционально снижает оверхед от операций декапсуляции TCP и в общем-то позволяет возвращать нормальную логику работы приложений (с прыжками в ядро за свежей информацией от сетевой карты). Насчет увеличения пропускной способности на 50% - мне сложно сказать, что они там меряли, но явно не в bandwidth упирались.

Ну это маленько устаревшее видение.

Как правило, нарезка на сегменты "окончательного" размера происходит в самом конце, уже после SSL offload. До этого внутри приватных сетей может быть что хочешь и с каким угодно размером мту, лишь бы L1 позволял. А оно виртуальное процентов на 90 нынче, так что позволит хоть гигабайт, хоть три.

Когда я работал с 25\40G аплинками - мы решали достаточно очевидную, и в то же время сложную задачу. Банально - процессору не хватает гигагерц, чтобы индивидуально обрабатывать каждый приходящий пакет, насыщенный 25г линк может бодро кинуть вам на дата плейн 40 миллионов пакетов в секунду, и на их софтовый разбор останется около 100 процессорных тактов на пакет (и это - оптимистичный вариант). Приходится по-всякому кроить время - сначала ПЛИСина на сетевой карте занимается коннтрекингом и отправляет каждое соединение на конкретный TX\RX чейн (который привязан к определенному физическому ядру), потом через DMA все эти штуки попадают в кольцевые буфера - таким образом не нужно генерировать прерывание на каждый пакет и отрабатывать какое-то определенное количество пакетов за один чих.

А дальше начинается тёмная материя - например, чтобы сократить количество context switch из режима ядра в режим пользователя, стек TCP\IP выносится в юзерспейс целиком в контекст обслуживающего процесса, для него через mmap() из ядра вытаскивается тот самый кольцевой буфер сетевой карты, и всё это бодро крутится в юзерспейсе без дорогостоящих прыжков в ядро за новыми пакетами от сетевухи. Люто и весело, в общем.

И это 40г, а что там на 100г - я даже подумать боюсь. Но подозреваю, что там без балансировщика на входе делать нечего.

Да можно и /dev/urandom по кругу гонять, и даже /dev/zero

Трунасы\медиаволты\тдтп это конечно хорошо, но ничего из этого не требует даже jumbo frames. Чтобы почувствовать какой-то буст, Вам как минимум понадобится какой-то кластер, low-latency свитч, FCoE\RoCE\RDMA\bla-bla-bla-capable сетевухи ну и некий ингресс, чтобы всё это в массы отдавать. Суммарная стоимость такого барахлишка выскочит по цене примерно как полторы-две квартиры, в которых снимались фоточки и видосики, так что целесообразность под вопросом.

Про нагрузку забыл. Гигабитный зырнет сейчас даже трехкопеечный арм в полку уводит, так что придётся либо делать кат6 вайринг, либо оптику кидать. Но самое забавное то, что обычный nvme ssd, зацепленный к usb4\thunderbolt положит всё это дело на лопатки в сценариях использования одним пользователем.

Рискну предположить, что существует ряд принципиальных ограничений. И самое главное - запрет фрагментации TCP-сегментов, означающий, что нижестоящие уровни модели OSI позволят надежно обмениваться сегментами такой длины.

В домашних условиях редкий свич умеет MTU выше 1600, так что будет по-старинке MSS 1460 без всякого вот этого. Да и скажем честно - ну вот даже 9к фреймы взять дома особо не откуда, разве что если у Вас только нет выделенного SAN сегмента для какой-нибудь лабы.

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

Powershell смотрит с недоумением на "нормальный" кли. Видали мы башовские портянки, там соотношение костылей к полезной нагрузке превышает все разумные пределы. Это так, к слову об ущербности тулинга.

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

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

обычный i7-1185G7 легко работает полный рабочий день (9+ часов) в 13-дюймовом ультрабуке.

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

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

И чем плох ирис? В сегменте бизнес-ноутбуков его за глаза вообще хватает, а игрушки играть на ноутбуке нужно далеко не всем.

Мы же про джуна говорим.

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity