Пятничное чтиво
На следующей неделе выступаю на митапе, расскажу о CQRS и почему паттерн на самом деле популярен, а разработчики не знают этого. А в среду будет стрим, доделаем библиотеку со стейт машиной и добавим ее в rubyjobs. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
How Netflix works: the (hugely simplified) complex stuff that happens every time you hit Play
Why You Can’t Talk About Microservices Without Mentioning Netflix
A Design Analysis of Cloud-based Microservices Architecture at Netflix
Сборник статей об архитектуре нетфликса.
В первой подробно описывается как и где компания разворачивает 700+ сервисов, а так же объясняет что подразумевает под сервисной архитектурой. Также, раскрываются интересные моменты из внутренней кухни, например - каждое устройство проигрывает специфичный формат видео, который сделан специально для этого устройства.
Вторая статья описывает причины, по которым нетфликс перешел на микросервисную архитектуру.
А третья статья больше рассказывает о самой архитектуре сервиса, объясняет playback и backend архитектуры. Так же, рассматривается каждый компонент отдельно, т.е. найдете информацию по работе клиента, API gateway, application API (это прослойка между gateway и сервисами), самих сервисов и баз данных, которые используются в компании. Также указываются трейдоффы такой архитектуры и цели (High Availability, Low Latency, scalability)
—————————————
Microservice Architecture at Medium
Статья описывает как медиум перешел на микросервисную архитектуру. Из причин - ботлнек в монолите в виде медленной разработки, перфоманса и скейла приложения. Также, указываются принципы, которым следовали инженеры медиума (7 штук). На что советую обратить внимание:
- Decouple “building a service” and “running services”;
- Not every new service needs to be built from scratch;
- Avoid “microservice syndromes” from day one;
Статья не расскажет о том, как переходить на сервисы, но поможет понять какие проблемы могут возникнуть и какие принципы сработали в компании (не факт, что принципы будут работать у других)
—————————————
Evolution of SoundCloud’s Architecture
Статья, без деталей, описывает эволюцию SoundCloud. Из не узнаете, как проект с
——— одной строкой ———
- Коллекция предложений переименовать термины в репозиториях;
На следующей неделе выступаю на митапе, расскажу о CQRS и почему паттерн на самом деле популярен, а разработчики не знают этого. А в среду будет стрим, доделаем библиотеку со стейт машиной и добавим ее в rubyjobs. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
How Netflix works: the (hugely simplified) complex stuff that happens every time you hit Play
Why You Can’t Talk About Microservices Without Mentioning Netflix
A Design Analysis of Cloud-based Microservices Architecture at Netflix
Сборник статей об архитектуре нетфликса.
В первой подробно описывается как и где компания разворачивает 700+ сервисов, а так же объясняет что подразумевает под сервисной архитектурой. Также, раскрываются интересные моменты из внутренней кухни, например - каждое устройство проигрывает специфичный формат видео, который сделан специально для этого устройства.
Вторая статья описывает причины, по которым нетфликс перешел на микросервисную архитектуру.
А третья статья больше рассказывает о самой архитектуре сервиса, объясняет playback и backend архитектуры. Так же, рассматривается каждый компонент отдельно, т.е. найдете информацию по работе клиента, API gateway, application API (это прослойка между gateway и сервисами), самих сервисов и баз данных, которые используются в компании. Также указываются трейдоффы такой архитектуры и цели (High Availability, Low Latency, scalability)
—————————————
Microservice Architecture at Medium
Статья описывает как медиум перешел на микросервисную архитектуру. Из причин - ботлнек в монолите в виде медленной разработки, перфоманса и скейла приложения. Также, указываются принципы, которым следовали инженеры медиума (7 штук). На что советую обратить внимание:
- Decouple “building a service” and “running services”;
- Not every new service needs to be built from scratch;
- Avoid “microservice syndromes” from day one;
Статья не расскажет о том, как переходить на сервисы, но поможет понять какие проблемы могут возникнуть и какие принципы сработали в компании (не факт, что принципы будут работать у других)
—————————————
Evolution of SoundCloud’s Architecture
Статья, без деталей, описывает эволюцию SoundCloud. Из не узнаете, как проект с
apache + rails + mysql развивался и превратился в систему с кешированием, search engine, брокером на RabbitMQ и большим количеством асинхронных фичей. Авторы описывают каждый переход и объясняют почему появился каждый новый переход. Нравится, что статья не перегружена деталями и расписывает каждый переход поверхностно, но при этом, объясняет почему и зачем это надо было.——— одной строкой ———
- Коллекция предложений переименовать термины в репозиториях;