инфраструктура

Длинная и годная статья. Тезисно:
1. осторожнее с облаками, иногда железо и админ дешевле в несколько раз (наверное всем уже надоел с этим утверждением!);
2. cloud provider lock-in = ☠;
3. нет блидинг эдж тулзам (они называют hipster tools всё, что моложе 18 месяцев).

http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/

Короткая (14 страниц A4) и познавательная статья про безопасность в гугле: https://cloud.google.com/security/security-design/
Проходится «по верхам» обеспечения безопасности такого монстра, как Google.

Мне было особенно интересно про аутентификацию/авторизацию на уровне общения сервисов друг с другом (внутри есть больше подробностей про это):

Each service that runs on the infrastructure has an associated service account identity. A service is provided cryptographic credentials that it can use to prove its identity when making or receiving remote procedure calls (RPCs) to other services. These identities are used by clients to ensure that they are talking to the correct intended server, and by servers to limit access to methods and data to particular clients.

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

На немецком ЖД-реддите ходят слухи, что причина в кривом обновлении софта.

Я и не знал, что у поездов есть своя сотовая сеть из 90-х. У нас уже 5G, а поезда на 2G.

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

P. S. Недавно узнал, как работали римские акведуки. Там, оказывается, вода становилась чистая за счет точно рассчитанного наклона трубы; вода течет медленно и вся грязь оседает, но и не слишком медленно, чтобы не застаивалась. 🪄

Подробная и полезная статья, как один стартап боролся с мощной DDoS атакой.

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

Практическое: они жили на AWS и подключили услугу AWS Shield Advanced — это когда anti-DDoS специалисты амазона помогают разобраться с вашей конкретной атакой. Стоит 3k$ в месяц, договор на год. Чувакам очень понравилось, и я возьму на заметку.

Небольшой рассказ, как дидосили Медузу 2 недели назад и пара советов для медиа в мире дидоса: https://dev.meduza.io/ddos-ab63424e595e

Вспомнил, как именно сломался сервер с первой версией. Мы удалили его в админке хостера, перепутав один сервер с другим.

Такие дела.

Прямо сейчас часть корневых серверов .io вместо правильных NS-ответов (списка серверов, на которых вы хостите свои DNS-записи) возвращает тыкву.

Из-за этого могут не открываться сайты в зоне .io, например, meduza.io

Всего два месяца назад у них обнаружили уязвимость, через которую можно было сделать MitM атаку на все домены зоны, а теперь вот это. Руки бы поотрывать и передать зону в управление Verisign.

Обсуждение вот тут https://news.ycombinator.com/item?id=15293578

Эти три поста — мини-ода серверу Nginx и его создателю Игорю Сысоеву. Я не написал о покупке компании NGINX американским гигантом F5 за 670 миллионов долларов в феврале (профайл в Ведомостях и в Форбсе), исправляюсь.

Nginx — это скотч веб-разработчика. Вы ведь знаете, что именно с помощью скотча астронавты починили свой автомобиль на луне? С помощью Nginx можно скрепить разные части сайта между собой (микросервисы, ау), ускорить сайт с помощью кеширования (скорость работы Медузы и RAWG), серьезно сэкономить на хостинге и даже защититься от DDoS-атак. Nginx поддерживает и простейшие одностраничные сайты и гигантские корпорации. Это сервер, который вобрал в себя лучшее от таможни, DHL и завода.

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

В контексте падения облаков, чем они лучше/хуже собственного железа?

Можно подумать, что я буду сейчас писать про отказоустойчивость. На самом деле, если ваш проект будет лежать, когда лежит весь GCP или AWS, — то для 99% проектов это абсолютно нормально, такие события происходят раз в несколько лет и длятся не больше пары часов. Мы ведь не кислородными масками управляем, верно?

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

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

Главное преимущество облаков в сравнении с «реальными серверами» — возможность быстро масштабироваться, то есть сегодня у тебя один сервер обрабатывает 1000 пользователей, завтра проект завирусился на миллионы, и ты за пару минут запускаешь десятки, сотни серверов.

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

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

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

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

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

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

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

Пример: классно наблюдать, как последние 3 года создатель важного фреймворка Ruby on Rails и культовой системы управления проектами Basecamp Дэвид Хейнемейер Ханссон (DHH) планомерно перевозит свои продукты с миллионами пользователей из облаков на собственные серверы.

Они объявили о планах выхода из Амазоновского облака AWS ещё в октябре 2022. На тот момент, они платили за Амазону 1,5 млн долларов в год! Для начала, они купили себе физических серверов на полмиллиона долларов (всего треть годового чека за облака!)

В июне 2023 объявили об успешном перевозе всех вычислений, а недавно купили специализированное железо для хранения данных и мае наконец перевезли хранилище файлов из AWS S3.

Другой яркий пример, с которым я сталкивался лично, — это стоимость трафика для медиа-проектов. Трафик в облаках для популярного медиа может стоить десятки тысяч долларов, и такой же объем можно обработать десятком арендованных серверов по 40 баксов каждый. Экономия в 100 раз. Но это всё имеет смысл только на масштабе. Так выпьем же за то, чтобы было на чем экономить!