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

Ну и хорошая короткая статья - мужчина сделал классный сервис на aws lambda, за который платит всего 21 цент в месяц. Дёшево, быстро и элегантно - всё как мы любим.

Никогда не использовал сложные функции aws, видимо стоит внимательно присмотреться к этому совершено адовому списку (в админке весь экран заполнен мелким шрифтом названиями сервисов). https://fmlnerd.com/2016/08/16/30k-page-views-for-0-21-a-serverless-story

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

Страница со статусом инфраструктуры ФБ тоже работает через раз — видимо, что-то серьезное.

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

Длинная и годная статья. Тезисно:
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.

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

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

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

Прямо сейчас часть корневых серверов .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 две необычные вещи, которыми я хочу поделиться.

Во-первых, перевели один очень старый сайт с http на https (это улучшает позиции в гугле), по пути убрали www из всех адресов и добавили кеширование, так что сайт стал открываться раз в 10 быстрее.

Интересная часть в том, что на сайте было много хардкод-адресов http://www..., и поменять исходный код было решительно невозможно (старый perl), так что мы использовали модуль ngx_http_sub_module, который позволяет переписать содержимое ответа на лету.

Мы не поменяли ни одной строки кода в движке сайта, все изменения — через настройки nginx.

Во-вторых, добавили щепотку динамического контента в кешированные nginx'ом страницы. Под нагрузкой наш django + react сервер отвечает не очень быстро. Для того, чтобы сайт отвечал мгновенно — мы кешируем странички для анонимов, то есть регулярно пересчитываем их, а при запросах мгновенно отдаем последнюю сохраненную версию.

Для проверки одной SEO-гипотезы нам потребовалось добавить несколько случайных ссылок на каждую страницу. Казалось, nginx-кеширование и динамический контент не сочетаются. Но нет, выручил SSI — технология родом из 1993, когда писали статический html-код страниц, а динамику добавляли маааленькими кусочками. Мы добавили в код своих страниц <include>, так что основная страница кешируется как и раньше, а блок со ссылками быстро отдается отдельным быстрым микросервисом.

Да здравствует nginx и инженеры, умеющие с ним управляться!