📄 AWS Whitepaper — AWS Multi-Region Fundamentals:
https://docs.aws.amazon.com/pdfs/whitepapers/latest/aws-multi-region-fundamentals/aws-multi-region-fundamentals.pdf
🔹 This paper focuses on high availability and continuity of operations requirements, and helps you navigate the considerations for adopting a multi-Region architecture for a workload.
🔸 It describes fundamental concepts that apply to design, development, and deployment of a multi-Region workload, along with a prescriptive framework to help you determine whether a multi-Region architecture is the right choice for a particular workload.
🔹 You need to ensure a multi-Region architecture is the right choice for your workload, because these architectures are challenging, and it’s possible that, if not done correctly, the overall availability of the workload can decrease.
#design
https://docs.aws.amazon.com/pdfs/whitepapers/latest/aws-multi-region-fundamentals/aws-multi-region-fundamentals.pdf
🔹 This paper focuses on high availability and continuity of operations requirements, and helps you navigate the considerations for adopting a multi-Region architecture for a workload.
🔸 It describes fundamental concepts that apply to design, development, and deployment of a multi-Region workload, along with a prescriptive framework to help you determine whether a multi-Region architecture is the right choice for a particular workload.
🔹 You need to ensure a multi-Region architecture is the right choice for your workload, because these architectures are challenging, and it’s possible that, if not done correctly, the overall availability of the workload can decrease.
#design
📓 Choosing the right AWS service to deploy your website or web application in the AWS Cloud — AWS Prescriptive Guidance:
https://docs.aws.amazon.com/prescriptive-guidance/latest/website-deployment-services
▫️ Static: S3 + CloudFront
▫️ JS framework + CI/CD: Amplify
▫️ Serverless + low-cost: API Gateway + Lambda + S3
▫️ WordPress/Drupal/Joomla: LightSail
▫️ Containers: App Runner or ECS or Fargate
▫️ Kubernetes: EKS
▫️ On-premises: EKS Anywhere or ECS Anywhere
▫️ Old-style managed environment: Beanstalk
▫️ Self-managed: EC2
#design
https://docs.aws.amazon.com/prescriptive-guidance/latest/website-deployment-services
▫️ Static: S3 + CloudFront
▫️ JS framework + CI/CD: Amplify
▫️ Serverless + low-cost: API Gateway + Lambda + S3
▫️ WordPress/Drupal/Joomla: LightSail
▫️ Containers: App Runner or ECS or Fargate
▫️ Kubernetes: EKS
▫️ On-premises: EKS Anywhere or ECS Anywhere
▫️ Old-style managed environment: Beanstalk
▫️ Self-managed: EC2
#design
📘 AWS Reference Architecture — Invoking Asynchronous External APIs:
https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/invoking-asynchronous-external-apis-ra.pdf
1️⃣ Set up Step Functions
2️⃣ Send the task token and the request payload
3️⃣ Use Lambda to poll SQS and trigger an express Step Functions workflow
4️⃣ (Optionally) Add dynamic delay inside Lambda controlled by AppConfig
5️⃣ Step Function invokes an API Gateway HTTP proxy API
6️⃣ Invoke the external third-party asynchronous service API
7️⃣ Store the workflow’s task token and the received job ID in DynamoDB
8️⃣ Receive the completed job ID in a callback webhook endpoint
9️⃣ Transform the external callbacks with API Gateway
🔟 Use Lambda to poll the callback SQS
1️⃣1️⃣ Pass the job ID to the next step, and invoke a Step Function processor to fetch the job’s results
#design
https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/invoking-asynchronous-external-apis-ra.pdf
1️⃣ Set up Step Functions
2️⃣ Send the task token and the request payload
3️⃣ Use Lambda to poll SQS and trigger an express Step Functions workflow
4️⃣ (Optionally) Add dynamic delay inside Lambda controlled by AppConfig
5️⃣ Step Function invokes an API Gateway HTTP proxy API
6️⃣ Invoke the external third-party asynchronous service API
7️⃣ Store the workflow’s task token and the received job ID in DynamoDB
8️⃣ Receive the completed job ID in a callback webhook endpoint
9️⃣ Transform the external callbacks with API Gateway
🔟 Use Lambda to poll the callback SQS
1️⃣1️⃣ Pass the job ID to the next step, and invoke a Step Function processor to fetch the job’s results
#design
Микросервисы → Монолит
Статья от 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, где рассказывается, как удалось уменьшить расходы в десять раз после перехода с микросервисов на монолитную архитектуру:
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
Prime Video Tech
Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
Анализ статьи 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
Во-первых, мои поздравления команде маркетинга Amazon — браво, великолепная работа! Кратко, минимум информации, точно в больное место и в результате каждый может сделать для себя (не)правильные выводы.
Во-вторых, если у вас есть сомнения в компетенциях управляющих процессом разработки в Amazon, то сначала спросите, что по этому поводу думает
Целью команды 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
Medium
So many bad takes — What is there to learn from the Prime Video microservices to monolith story
The Prime Video team published this story: Scaling up the audio/video monitoring service and reducing costs by 90%, and the internet piled…
🔢 «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
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
📚 Два главных документа которые должен знать каждый грамотный AWS DevOps Engineer:
1️⃣ AWS CAF (AWS Cloud Adoption Framework)
2️⃣ AWS WAF (Well-Architected Framework)
Это немалый объём и в реальности не два документа. Но это база. © Настоящая база, которая не про айноды. 😁
Можно спорить про применимость это для начинающих, хотя WAF (не который firewall) точно показан с самого начала и в режиме pocket book на все случаи.
Обязательно рекомендуется продвинутым. Особенно, если нужно прокачаться в ширину, а не глубину.
#design #CAF #WAF #devops
1️⃣ AWS CAF (AWS Cloud Adoption Framework)
2️⃣ AWS WAF (Well-Architected Framework)
Это немалый объём и в реальности не два документа. Но это база. © Настоящая база, которая не про айноды. 😁
Можно спорить про применимость это для начинающих, хотя WAF (не который firewall) точно показан с самого начала и в режиме pocket book на все случаи.
Обязательно рекомендуется продвинутым. Особенно, если нужно прокачаться в ширину, а не глубину.
#design #CAF #WAF #devops
Amazon
AWS Cloud Adoption Framework
The AWS Cloud Adoption Framework helps enterprises effectively adopt the AWS cloud
AWS Notes
📚 Два главных документа которые должен знать каждый грамотный AWS DevOps Engineer: 1️⃣ AWS CAF (AWS Cloud Adoption Framework) 2️⃣ AWS WAF (Well-Architected Framework) Это немалый объём и в реальности не два документа. Но это база. © Настоящая база, которая…
AWS Cloud Adoption Framework на русском.
https://d1.awsstatic.com/whitepapers/ru_RU/aws-cloud-adoption-framework.pdf
#design
https://d1.awsstatic.com/whitepapers/ru_RU/aws-cloud-adoption-framework.pdf
#design
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
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
