— Доктор, у меня болит нога. — Странно, у меня такая же нога, а ничего не болит.
Коллеги решают свои насущные задачи. Обесценивать это – выглядит странным. Если можно меньше тратить время на рутинные вещи, упростить инфру, почему бы не сделать?
Этот курс создавался с нашим участием. Задача была – сделать именно обучающий материал. Там он собран в том числе после консультаций с нашими инженерами.
Обучающий курс по системе балансировке (Angie ADC), будет уже и с обучением, и с сертификатом, и, надеюсь, с лабораторными стендами для потрогать руками.
Делать "сертификат от вендора" для Angie PRO – пока не востребовано. Для ADC – другое дело
Компания Cloudflare предоставляет пользователям сервис, на базе ряда ПО. То есть у них есть физическая инфраструктура, которая обрабатывает пользовательские запросы, в некоторых сценариях, пропуская запросы через свои системы балансировки.
У нас веб-сервер, это ПО, которое может быть использовано в таких сервисах как Cloudflare, Yandex Cloud, RU-Center hosting, и тд
Мы, как компания, пока планируем остаться вендором ПО, заниматься только разработкой приложений в области сетевого стека. Собственно благодаря встроенным инструментам, или сторонним модулям (тот же mod security), часть запрашиваемых задач уже можно решать
Поддержка же инфраструктуры, SAAS сервисов, пока не в планах. Хотя мы не скрываем, что думаем про это.
Пока кажется, что бизнес план не сойдется, если делать сервис.
Мотивация очень простая: платежеспособные клиенты предпочитают приватные облака, развернутые на своих площадках таким сервисам.
Если совсем коротко – то благодаря вам. Тем, кто про нас узнает, рассказывает коллегам.
После этого к нам приходят познакомиться, попробовать на пилотных проектах, и уже далее масштабируемся. Сарафанное радио.
Клиенты в поисках продуктов, которые решают задачи в инфраструктуре.
Есть еще целый пласт задач балансировки, который закрывался западными вендорами (так называемые системы балансировки, ADC). Прямой замены нет, но есть возможность уже сегодня решать часть задач. Соответсвенно приходят, спрашивают. Мы что-то кладем в дорожную карту, оно появляется оперативно – народ это ценит и мы переходим к коммерческой части.
Совсем копьё – это замещение Nginx Plus. Даже смешно.
Холодными продажами не занимаемся.
Клиенты уровня big tech компаний – сами себе инженеры. Свои свечные заводики (ну ок).
Выступаем на конференциях. В этом году два доклада на HighLoad:
В том то и дело, что не структуру БД. Подход к описанию контракта в статически типизированном виде предпочтительнее работы с моделями базы данных, это типичная практика. Например потому что ответ от базы не всегда соответствует таблицам в базе.
Во-первых правильнее будет тогда уж делать не удаление из кэша, а обновление.
Во-вторых реализация такой системы немного сложнее. Необходимо формировать очередь на события обновления материалов. И в фоне уже делать запросы на обновление. Тут надо смотреть, на чьей стороне реализован кэш, в каком формате данные, как формируется ключ.
В-третьих есть риск слишком частого обновления страницы (например главной). Тогда надо либо делать таймауты, либо разбивать страницу на SSI инклуды, либо… В общем некая логика, которая забоится о достойном соотношении «отдать из кэша/заново сформировать контент».
Итого имеем: простая система с временем обновления до минуты; сложная система, с обновлением за секунды. Так как минуты – допустимое значение даже для сверх срочных новостей, то рациональным решением является выбор первого варианта.
Одно из преимуществ wiki на GitHub – возможность редактировать файлы локально на компьютере, работая как с репозиторием. Так как менеджеры с терминалом работать не умеют, на помощь приходят настольные приложения для git. В частности, можно скачать GitHub for Mac. Репозиторий с wiki для проекта лежит по адресу git@github.com/username/reponame.wiki.git. То есть к адресу обычного репозитория добавляется суффикс .wiki. Один раз настраиваем, показываем как делать коммиты, кликая вон ту зелёненькую кнопку. И все довольны.
А эти структуры никак не связаны с масштабированием. Массив служит для упрощения организации ассоциативных связей. hstore удобен для динамических атрибутов объекта. А json для кэшированных структур данных. Валидации на уровне обработчиков в приложении. Разумеется триггеры и хранимые процедуры не используем, всё концентрируется в приложении.
А глобально проблемы с масштабированием в такого рода проекта просто нет. Нет такого объёма данных, который не уместится на одном сервере. Нет такого кол-ва запросов, которые нельзя размазать по мастер-слейв.
Подробности про передачу аргументов, выделение памяти и все нюансы тут: https://github.com/WebAssembly/component-model/blob/main/design/mvp/CanonicalABI.md
Подробно про каждую из функций описание от руководителя разработки, @VBart: http://habr.com/p/900672/
Эмоции уйдут, статья останется. Наша задача рассказывать про технологии. Вздохнули, отряхнулись, побежали дальше :)
— Доктор, у меня болит нога.
— Странно, у меня такая же нога, а ничего не болит.
Коллеги решают свои насущные задачи. Обесценивать это – выглядит странным. Если можно меньше тратить время на рутинные вещи, упростить инфру, почему бы не сделать?
Этот курс создавался с нашим участием. Задача была – сделать именно обучающий материал. Там он собран в том числе после консультаций с нашими инженерами.
Обучающий курс по системе балансировке (Angie ADC), будет уже и с обучением, и с сертификатом, и, надеюсь, с лабораторными стендами для потрогать руками.
Делать "сертификат от вендора" для Angie PRO – пока не востребовано. Для ADC – другое дело
Компания Cloudflare предоставляет пользователям сервис, на базе ряда ПО. То есть у них есть физическая инфраструктура, которая обрабатывает пользовательские запросы, в некоторых сценариях, пропуская запросы через свои системы балансировки.
У нас веб-сервер, это ПО, которое может быть использовано в таких сервисах как Cloudflare, Yandex Cloud, RU-Center hosting, и тд
Мы, как компания, пока планируем остаться вендором ПО, заниматься только разработкой приложений в области сетевого стека. Собственно благодаря встроенным инструментам, или сторонним модулям (тот же mod security), часть запрашиваемых задач уже можно решать
Поддержка же инфраструктуры, SAAS сервисов, пока не в планах. Хотя мы не скрываем, что думаем про это.
Пока кажется, что бизнес план не сойдется, если делать сервис.
Мотивация очень простая: платежеспособные клиенты предпочитают приватные облака, развернутые на своих площадках таким сервисам.
Курс на Otus уже запущен https://otus.ru/lessons/angie/
@VBartсейчас по полочкам разложит. А я скажу просто: у нас все релизы - стабильные
Если совсем коротко – то благодаря вам. Тем, кто про нас узнает, рассказывает коллегам.
После этого к нам приходят познакомиться, попробовать на пилотных проектах, и уже далее масштабируемся. Сарафанное радио.
Клиенты в поисках продуктов, которые решают задачи в инфраструктуре.
Есть еще целый пласт задач балансировки, который закрывался западными вендорами (так называемые системы балансировки, ADC). Прямой замены нет, но есть возможность уже сегодня решать часть задач. Соответсвенно приходят, спрашивают. Мы что-то кладем в дорожную карту, оно появляется оперативно – народ это ценит и мы переходим к коммерческой части.
Совсем копьё – это замещение Nginx Plus. Даже смешно.
Холодными продажами не занимаемся.
Клиенты уровня big tech компаний – сами себе инженеры. Свои свечные заводики (ну ок).
Выступаем на конференциях. В этом году два доклада на HighLoad:
Запуск приложений из Angie https://highload.ru/moscow/2024/abstracts/13181
Поддержка WASM https://highload.ru/moscow/2024/abstracts/13031
В общем по старинке – если инженеру заходит – тогда есть интерес.
https://habr.com/en/articles/774274/
Было бы интересно обзорно посмотреть еще на решения в таком ключе:
Как давно компания на рынке и развивает своё решение
Где действительно есть уникальная разработка, где это красиво собранное решение
Кто какой вклад привнес в open source (вклад в проекты на базе которых собрали, публикация своего решения)
Есть ли у проектов точки пересечения, потенциал на объединение, или они "развелись" недавно.
Все это интересно именно обзорно в сравнении, а не только "в одной статье описать одно решение"(условно)
Спасибо за труд, может получиться интересное исследование.
Можно.
Не принципиально.
Во-вторых реализация такой системы немного сложнее. Необходимо формировать очередь на события обновления материалов. И в фоне уже делать запросы на обновление. Тут надо смотреть, на чьей стороне реализован кэш, в каком формате данные, как формируется ключ.
В-третьих есть риск слишком частого обновления страницы (например главной). Тогда надо либо делать таймауты, либо разбивать страницу на SSI инклуды, либо… В общем некая логика, которая забоится о достойном соотношении «отдать из кэша/заново сформировать контент».
Итого имеем: простая система с временем обновления до минуты; сложная система, с обновлением за секунды. Так как минуты – допустимое значение даже для сверх срочных новостей, то рациональным решением является выбор первого варианта.
git@github.com/username/reponame.wiki.git. То есть к адресу обычного репозитория добавляется суффикс.wiki. Один раз настраиваем, показываем как делать коммиты, кликая вон ту зелёненькую кнопку. И все довольны.А глобально проблемы с масштабированием в такого рода проекта просто нет. Нет такого объёма данных, который не уместится на одном сервере. Нет такого кол-ва запросов, которые нельзя размазать по мастер-слейв.