Микросервисы → Монолит

Статья от Amazon Prime Video, где рассказывается, как удалось уменьшить расходы в десять раз после перехода с микросервисов на монолитную архитектуру:

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

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

v.0.0.0

— Привет, Дмитро. Тут задача срочная прилетела — клиенту нужно запилить сервис по проверке качества роликов. А вы, помню, уже как-то что-то делали для тестирования видео?
— Было дело, накрапали костылик для внутренних нужд, чтобы отчёты слать аналитикам.
— Вот и отлично, приступайте.
— А какая нагрузка планируется?
— Подробностей не знаю, если что, чего-нибудь помощней поставим.
— Не, мы ж на Лямбдах всё написали.
— О, отлично, передам маркетингу — у нас будет Serverless-решение!

v.0.1.0

— Макс, что по нагрузке?
— Всё должно работать рилтайм и в перспективе держать тысячи параллельных задач на обработку.
— <censored>! Мы ж никогда пробовали на таких объёмах.
— Поздно, уже всё продано, продолжайте делать.
— А денег у клиента хватит?
— Деньги не проблема, главное сделать быстро!

v.1.0.0

— Дмитро, у нас проблемы. Клиент увидел счёт за прошлый месяц и офигел.
— Я предупреждал. И это лишь 5% от полной нагрузки.
— А почему так дорого?
— Так мы ж каждый кадр видео на S3 гоняем Лямбдами по несколько раз с помощью дорогущих Step Functions.
— И как это исправить?
— Никак, нужно всё переделывать. Проанализировать результаты под нагрузкой, попробовать различные варианты, спроектировать...
— ...А если нужно вчера?
— Ну, можно всё тупо засунуть в один контейнер и масштабировать как монолит с помощью ECS. Ещё и дешевле получится.
— О, супер, так и сделаем. И продадим как версию 2.0. А я напишу маркетингу, пусть они статейку накатают, как мы сэкономили клиенту кучу денег, перейдя на монолит с микросервисов. Все будут обсуждать только это и никто не вспомнит, как мы облажались с первой версией.

#serverless #monolith #design

Анализ статьи Amazon Prime Video

Во-первых, мои поздравления команде маркетинга Amazon — браво, великолепная работа! Кратко, минимум информации, точно в больное место и в результате каждый может сделать для себя (не)правильные выводы.

Во-вторых, если у вас есть сомнения в компетенциях управляющих процессом разработки в Amazon, то сначала спросите, что по этому поводу думает Google ChatGPT или просто посмотрите список самых успешных IT компаний.

Целью команды Amazon Prime Video было максимально быстро получить рабочий вариант. С отлаженным процессом разработки на Serverless можно выдавать готовые решения за несколько спринтов, в том числе для сложных и нагруженных систем.

Главный плюс Serverless — не условная "бесплатность", это уже побочный эффект. Главный плюс — скорость разработки и возможность справляться с неизвестной или непрогнозируемой нагрузкой.

Анализ статьи с цитатами из текста

1️⃣ Была задача получить решение максимально быстро и они сделали это. Serverless прекрасно вписывается в этот подход и команда имеет опыт разработки Serverless решений.

«We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly.»

2️⃣ Они получили опыт эксплуатации первой тестовой версии и реальные данные по нагрузке. Выяснилось, что быстро разработанное Serverless-решение имеет ограничения по масштабированию да при этом ещё и дорогое.

«In theory, this would allow us to scale each service component independently. However, the way we used some components caused us to hit a hard scaling limit at around 5% of the expected load. Also, the overall cost of all the building blocks was too high to accept the solution at a large scale.»

3️⃣ На основе полученных данных они получили возможность сформировать конкретные требования как по масштабированию, так и по стоимости. В результате чего переработали решение, выбрав монолитную архитектуру вместо распределённой.

«We initially considered fixing problems separately to reduce cost and increase scaling capabilities. We experimented and took a bold decision: we decided to rearchitect our infrastructure.
We realized that distributed approach wasn’t bringing a lot of benefits in our specific use case, so we packed all of the components into a single process. This eliminated the need for the S3 bucket as the intermediate storage for video frames because our data transfer now happened in the memory. We also implemented orchestration that controls components within a single instance.»

4️⃣ Изменения затронули лишь исполнительную часть, общая схема не изменилась, поэтому переход Serverless → ECS был быстрым.

«Conceptually, the high-level architecture remained the same. We still have exactly the same components as we had in the initial design (media conversion, detectors, or orchestration). This allowed us to reuse a lot of code and quickly migrate to a new architecture.»

Выводы

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

Однако каждый может сделать и свои выводы — ещё раз респект маркетингу Amazon. Кстати, им точно стоит развить успех и помочь коллегам из AWS с придумыванием адекватных названий для сервисов.

P.S. Самая уместная (из немногих) статья по данной теме:

https://adrianco.medium.com/so-many-bad-takes-what-is-there-to-learn-from-the-prime-video-microservices-to-monolith-story-4bd0970423d4

#design #development #marketing

​​🔢 «Evolutionary Architectures» is a four-part blog series that shows how solution designs and decisions evolve as companies go through the different stages of the startups lifecycle.

1️⃣ «I’ve got this great idea!» — MVP:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-1/

2️⃣ «I think we may be onto something» — evolving technical solution:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-2/

3️⃣ «To the moon 🚀» — evolving architecture:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-3/

4️⃣ «Would you like coffee with that?» — formalizing security and backup posture to meet various compliance standards:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-4/

#design

Универсальные ответы для собесов по DevOps

... Что ...?

— «Docker» (40%)
— «Kubernetes» (40%)
— «Зависит от контекста» (20%)


... Почему?

— «Так исторически сложилось» (100%)

#devops #design

​​THE FRUGAL ARCHITECT

https://thefrugalarchitect.com/

#architecture #design

📚 Два главных документа которые должен знать каждый грамотный AWS DevOps Engineer:

1️⃣ AWS CAF (AWS Cloud Adoption Framework)
2️⃣ AWS WAF (Well-Architected Framework)

Это немалый объём и в реальности не два документа. Но это база. © Настоящая база, которая не про айноды. 😁

Можно спорить про применимость это для начинающих, хотя WAF (не который firewall) точно показан с самого начала и в режиме pocket book на все случаи.

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

#design #CAF #WAF #devops

AWS Cloud Adoption Framework на русском.

https://d1.awsstatic.com/whitepapers/ru_RU/aws-cloud-adoption-framework.pdf

#design

MVP

Обычная беда — нужно сделать MVP вчера и без требований. Причём требования появятся примерно никогда.

Как же быть? Пока ведь всё на одной виртуалке. Настраивать автоскелинг? Ведь в будущем придут пользователи, а мы не готовы. И по бест практисам ведь рекомендуется.

И споты бы хорошо прикрутить, чтобы экономить. Допилим бэкенд для этого за пару месяцев и всё, теперь готовы.

Хотя нет, ещё же мониторинг. Графана сейчас лютует. А нормальные люди её ставят только в кубернетес. Так что вместе со спотами ещё сразу переделаем всё под кубер, чтобы два раза не вставать. Максимум плюс полгодика получится.

Тесты и безопасность потом сделаем, а то вдруг не взлетит.

А, ещё логи. Их ведь нужно собрать. Разрабы сказали, что их будет "хер его знает, но точно много". Спасибо, родные, очень помогло. Короче, нужно сделать с запасом. И чтобы хранились дёшево и вечно, потому что может аудит появится по требованиям.

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

Так, вроде всё продумали, годика за полтора запилим. Но это не точно.

MVP is not a result, it's a process.

#design #MVP

​​Microfrontends on AWS

https://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/introduction.html

• Foundational concepts
• Alternative architectures
• Architectural decisions
• Frameworks and tools
• API integration ‒ BFF
• Styling and CSS
• Organization
• Governance
• Platform team

#design

Постоянно обсуждать факап CrowdStrike — это норм.

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

#design

Новый The Frugal Architect — теперь с блогами и подкастами:

https://thefrugalarchitect.com/

#design

Try again — the tools and techniques behind resilient systems

https://www.youtube.com/watch?v=rvHd4Y76-fs

You learn the most from your worst days.

Don't make availability worse trying to make it better.

There's any good reason not to Jitter if you're gonna do retries.

Avoid binary on/off circuit breakers — they can make system problems worse.

Don't kick your services when they're down — systems under stress need help, not more load.

Instead of sleeping for N seconds, sleep for a random number between zero and two N seconds.

Retries are like telling your overworked boss you need time off, and they give you 4x more work instead.

#design #video

Настоящие проблемы начинаются, когда не доложили палок.

#design #пятничное

The Twelve-Factor App on AWS

https://aws.amazon.com/blogs/architecture/realizing-twelve-factors-with-the-aws-well-architected-framework/

#WAF #design